Я попытался скомпилировать это:
enum class conditional_operator { plus, or, not };
Но, по-видимому, GCC (4.6) считает их особенными, хотя я не могу найти стандарт, в котором говорится, что это так (ни C++0x n3290, ни C99 n2794). Я компилирую с помощью g++ -pedantic -std=c++0x. Это удобство компилятора? Как отключить? Не следует ли -std=c++0x отключить эту "функцию"?
PS: Хммм, видимо, форматирование кода MarkDown тоже так думает...
Смотри 2.5. Это альтернативные токены для || и !.
Кстати, есть куча других альтернативных токенов.
Изменить: причина их включения такая же, как и у триграфов: разрешить использование наборов символов, отличных от ASCII. Комитет пытался избавиться от них (по крайней мере, от триграфов, я не помню альтернативных токенов) и встретил сопротивление людей (в основном пользователей мейнфреймов IBM), которые их используют.
Отредактируйте для полноты: поскольку другие сделали замечания, плюс не входит в этот класс и не должен быть проблемой, если вы не using namespace std.
На самом деле они определены как альтернативные токены (и зарезервированы), как ни странно, как альтернативные представления для операторов. Я полагаю, что изначально это было сделано для того, чтобы помочь людям, которые использовали клавиатуры, которые затрудняли создание соответствующих символов, хотя это кажется довольно плохой причиной для добавления дополнительных ключевых слов в язык :(
может компилятор GCC отключает их, но я не уверен.
(Как упоминалось в комментариях, plus должно быть хорошо, если вы не используете пространство имен std.)
or и not являются альтернативными представлениями || и ! соответственно. Вы не можете отключить их, и вы не можете использовать эти токены ни для чего другого, они являются частью языка (текущий C++, даже не просто C++0x). (См. ISO/IEC 14882:2003 2.5 [lex.digraph] и 2.11 [lex.key]/2.)
Вы должны быть в безопасности с plus, если только вы не используете using namespace std; или using std::plus;.
plus должен быть в безопасности.
- person rubenvb; 06.06.2011
Стандарт перечисляет ключевые слова в 2.11. Существует также список альтернативных представлений, отдельный от списка ключевых слов, который зарезервирован и не может использоваться иначе, но не является ключевым словом. and и or находятся в этом списке. Раздел 17.4.3 описывает ограничения для программ, использующих библиотеки, а 17.4.3.1.3 описывает, что имена, объявленные с внешней ссылкой в заголовке, зарезервированы как в std::, так и в глобальном пространстве имен.
Другими словами, вам не нужно переходить на C++0x, чтобы иметь эти проблемы. and и or уже зарезервированы, а заголовок <functional> содержит plus в качестве шаблонного типа структуры, и поэтому plus является недопустимым, если <functional> прямо или косвенно является #included.
Я не уверен, что сбрасывать столько всего в глобальное пространство имен было действительно разумно, но так говорит стандарт.
:s. Я также не знал о проблеме plus. Думаю, мне придется прибегнуть к plus_op, or_op и not_op...
- person rubenvb; 06.06.2011
plus нельзя, это немного сильно. Он надежно встроен в пространство имен std.
- person CB Bailey; 06.06.2011
cout, cerr, clog, cin, errno, а не к классам и шаблонам. Я не могу думать ни о каких других, но я уверен, что есть и другие.
- person CB Bailey; 06.06.2011
Это поправка 1995 года к стандарту C90. Вероятно, компилятор может выбрать, как вести себя в этом случае. GCC, вероятно, включает заголовок как часть стандартной библиотеки. С Microsoft это не так, и вы должны включить iso646.h.
Вот ссылка на википедию по этому поводу.
orиnotкак зарезервированные, но отделяетplus:) Лично я бы предпочел отказаться от использования||и&&в пользуorиand(соответственно), гораздо меньше путаницы с побитовыми операторами. - person Matthieu M. schedule 06.06.2011orиandв качестве имен функций-членов. Я с нетерпением жду, когда он попробует и громко заплачет. - person Johannes Schaub - litb schedule 06.06.2011