Почему VS не определяет альтернативные токены для логических операторов?

Альтернативные маркеры действительны С++ ключевые слова, но в Visual Studio 2013 следующее испускает ошибку компиляции (необъявленный идентификатор):

int main(int argc, const char* argv[])
{
    int k(1), l(2);
    if (k and l) cout << "both non zero\n";

    return 0;
}

Так как and or not существует довольно долгое время, есть причина для их неэффективности?

Ответ 1

Вы спрашиваете об этом. Здесь одна возможная причина, не обязательно та, которая больше всего повлияла на команду Visual C++:

Это действительные идентификаторы в C.
Рекомендация Microsoft уже давно должна использовать режим C++ для кода C и C++, а не для поддержки современного компилятора C.
Действительный код C, использующий эти как идентификаторы, будет безвозвратно ломаться, если они были скомпилированы как ключевые слова.
Люди, пытающиеся написать портативный C++, в основном используют /permissive- или /Za для максимальной согласованности, что приведет к тому, что они будут рассматриваться как ключевые слова.
Обходной путь, чтобы рассматривать их как ключевые слова в /Ze, включая заголовочный файл, прост и переносится. (G++ обходное решение -fno-operator-names тоже неплохо, но -fno-operator-names опции в исходный код, а не в систему сборки, несколько приятнее.)

Ответ 2

Формально эти ключевые слова реализованы и поддерживаются встроенным компилятором без включения заголовков. Однако для этого вам нужно скомпилировать исходный код в "более стандартном" режиме этого компилятора С++, что означает использование опции /Za.

По замыслу, параметр /Za должен "отключать расширения компилятора". Конечно, не поддерживать что-то, что должно быть там в совместимом компиляторе, не может быть формально квалифицировано как "расширение компилятора". Тем не менее, это то, что происходит в настоящее время.

Ответ 3

VS несоответствует. Это старые новости.

Чтобы использовать альтернативные маркеры, включите заголовок <ciso646>. Согласно стандарту, в том числе этот заголовок не должен иметь эффекта в С++. Однако вам это нужно в VS. Поэтому безопасно просто включать его всегда, всякий раз, когда есть вероятность, что вы можете компилировать с помощью VS.

Ответ 4

Так как

#include of <iso646.h> (или ciso646) заключается в том, как мы поддерживаем эти ключевые слова

И потому, что "никто" (передо мной) никогда не просил об этом. Неважно, что это было в 2007 году, и люди просят об этом в Интернете с тех пор.

Ответ 5

(современное обновление)

Я сделал небольшой тест: новый проект "Настольное приложение Windows". IDE (Visual Studio 2017 15.7.5) устанавливает по умолчанию следующие настройки соответствия языка C++: /permissive-/Zc: wchar_t/Zc: forScope/Zc: inline. Кроме того, я установил C++ Language Standard в ISO C++/Последний черновик (в настоящее время до C++ 17). Кроме того, я добавил в основном() следующие две строки:

bool a, b, c;

a = b and c;

Он успешно скомпилирует текстовые формы логических операторов. Но когда я изменил режим соответствия IDE на No (=> без /permissive-) и перекомпилировал компилятор, отметьте: "ошибка C2065: 'и': uneclared identifier".

По умолчанию параметр компилятора /permissive- установлен в новых проектах, созданных Visual Studio 2017 версии 15.5 (декабрь 2017 г.) и более поздних версиях. Он не задан по умолчанию в более ранних версиях. Поэтому, если кто-то создал проект до версии 15.5 и к моменту обновления IDE до последней версии, все же ему потребовалось вручную установить в проекте этот параметр компилятора.

Параметр /Ze компилятор, который включен по умолчанию, включает расширения Microsoft. Параметр /Ze устарел, поскольку его поведение по умолчанию включено. MSDN рекомендует использовать параметры компилятора /Zc (Conformance) для управления функциями расширения языка.