Опитах се да компилирам това:
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.
Ето връзка към wikipedia относно това.
or, така иnotкато запазени, но отделяplus:) Лично аз бих предпочел да се откажа от използването на||и&&в полза наorиand(съответно), много по-малко объркване с побитовите оператори. - person Matthieu M. schedule 06.06.2011orиandкато имена на членски функции. Чакам го с нетърпение да пробва и плача с глас. - person Johannes Schaub - litb schedule 06.06.2011