Каковы правила использования подчеркивания в идентификаторе C ++?

Question

Каковы правила использования подчеркивания в идентификаторе C ++?

838

В С++ часто называют имена переменных-членов с каким-то префиксом, чтобы обозначать тот факт, что они являются переменными-членами, а не локальными переменными или параметрами. Если вы пришли из фона MFC, вы, вероятно, используете m_foo. Иногда я видел myFoo.

С# (или, возможно, просто .NET), похоже, рекомендует использовать только подчеркивание, как в _foo. Это разрешено стандартом С++?

Roger Lipscombe 23 окт. 2008, в 06:47

Источник

3

Страницу руководства glibc об этом можно найти по адресу gnu.org/software/libc/manual/html_node/Reserved-Names.html Редактировать: см. Также opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html
CesarB 23 окт. 2008, в 10:59
5

Просто отметим, что незнание этих правил не обязательно означает, что ваш код не будет компилироваться или выполняться, но вполне вероятно, что ваш код не будет переносимым на разные компиляторы и версию, поскольку нельзя гарантировать, что не будет имени столкновения Чтобы подкрепить это, я знаю об определенной реализации важной системы, которая повсеместно использовала в качестве соглашения об именах _ заглавную букву. Там, где нет ошибок из-за этого. Конечно, это плохая практика.
g24l 16 нояб. 2015, в 22:32

Теги:

c++

standards

underscores

c++-faq

5 ответов

170

Правила, позволяющие избежать столкновения имен, находятся в стандарте С++ (см. книгу Stroustrup) и упомянуты гуру С++ (Sutter и т.д.).

Персональное правило

Поскольку я не хотел разбираться с делами и хотел простое правило, я разработал личный, который является простым и правильным:

При присвоении имени символу вы избегаете столкновения с библиотеками компилятора/ОС/стандарта, если вы:

никогда не начинайте символ с подчеркивания
никогда не называйте символ с двумя последовательными символами подчеркивания внутри.

Конечно, помещение вашего кода в уникальное пространство имен также помогает избежать столкновения (но не защитит от злых макросов)

Некоторые примеры

(Я использую макросы, потому что они больше загрязняют код символами C/С++, но это может быть что угодно: от имени переменной до имени класса)

#define _WRONG
#define __WRONG_AGAIN
#define RIGHT_
#define WRONG__WRONG
#define RIGHT_RIGHT
#define RIGHT_x_RIGHT

Выдержки из С++ 0x черновик

Из файла n3242.pdf (я ожидаю, что окончательный стандартный текст будет похож):

17.6.3.3.2 Глобальные имена [global.names]

Определенные наборы имен и сигнатур функций всегда зарезервированы для реализации:

- Каждое имя, содержащее двойное подчеркивание _ _ или начинающееся с символа подчеркивания, за которым следует заглавная буква (2.12), зарезервировано для реализации для любого использования.

- Каждое имя, начинающееся с символа подчеркивания, зарезервировано для реализации для использования в качестве имени в глобальном пространстве имен.

Но также:

17.6.3.3.5 Пользовательские суффиксы литерала [usrlit.suffix]

Литеральные идентификаторы суффиксов, которые не начинаются с подчеркивания, зарезервированы для будущей стандартизации.

Это последнее предложение сбивает с толку, если вы не считаете, что имя, начинающееся с одного подчеркивания и сопровождаемое строчной буквой, будет ОК, если not определено в глобальном пространстве имен...

paercebal 23 окт. 2008, в 07:52

6

Что насчет #define __WRONG_AGAIN__ ? это тоже неправильно?
Meysam 18 янв. 2012, в 06:16
9

@Meysam: __WRONG_AGAIN__ содержит два последовательных подчеркивания (два в начале и два в конце), так что это неправильно в соответствии со стандартом.
paercebal 18 янв. 2012, в 13:49
3

почему #define WRONG__WRONG не так?
BЈовић 04 дек. 2013, в 16:22
7

@ BЈовић: WRONG__WRONG содержит два последовательных подчеркивания (два в середине), так что это неправильно в соответствии со стандартом
paercebal 04 дек. 2013, в 17:30
2

помещение вашего кода в уникальное пространство имен также помогает избежать коллизий : но этого все же недостаточно, поскольку идентификатор может конфликтовать с ключевым словом независимо от области действия (например, __attribute__ для GCC).
Ruslan 06 сен. 2016, в 09:53
1

Почему существует проблема с двумя последовательными подчеркиваниями в середине в соответствии со стандартом? Пользовательские литеральные суффиксы применяются к литеральным значениям, таким как 1234567L или 4.0f ; IIRC это относится к ohttp: //en.cppreference.com/w/cpp/language/user_literal
Jason S 12 сен. 2017, в 16:42
0

Why is there any problem of having two consecutive underscores in the middle according to the standard? Потому что стандарт говорит, что они зарезервированы. Это не совет о хорошем или плохом стиле. Это решение от стандарта. Почему они решили это? Я думаю, что первые компиляторы уже использовали такие соглашения неофициально до стандартизации.
paercebal 13 сен. 2017, в 17:54
0

Мне не удалось найти предложение [global.names] или что-то подобное в текущем проекте стандарта ( eel.is/c++draft ). Кажется, он был удален.
Henri Menke 03 май 2018, в 11:16

Показать ещё 6 комментариев

35

От MSDN:

Использование двух последовательных символов подчеркивания (__) в начале идентификатора или одного ведущего подчеркивания, за которым следует заглавная буква, зарезервировано для реализаций С++ во всех областях. Вам следует избегать использования одного ведущего подчеркивания, за которым следует строчная буква для имен с областью файлов из-за возможных конфликтов с текущими или будущими зарезервированными идентификаторами.

Это означает, что вы можете использовать одно подчеркивание в качестве префикса переменной-члена, если оно следует за строчной буквой.

Это, очевидно, взято из раздела 17.4.3.1.2 стандарта С++, но я не могу найти исходный источник для полного стандартного онлайн.

См. также этот вопрос.

Roger Lipscombe 23 окт. 2008, в 07:18

2

Я нашел похожий текст в n3092.pdf (проект стандарта C ++ 0x) в разделе: «17.6.3.3.2 Глобальные имена»
paercebal 27 июнь 2011, в 19:49
6

Интересно, что это, кажется, единственный ответ, который имеет прямой, краткий ответ на вопрос.
hyde 03 окт. 2014, в 16:08
9

@hyde: На самом деле это не так, так как оно пропускает правило, чтобы не иметь идентификаторов с ведущим подчеркиванием в глобальном пространстве имен. Смотрите ответ Роджера . Я бы очень осторожно относился к документам MS VC как к авторитету по стандарту C ++.
sbi 09 июль 2015, в 13:37
0

@sbi Я имел в виду «вы можете использовать одно подчеркивание в качестве префикса переменной-члена, если за ним следует строчная буква» в этом ответе, который отвечает на вопрос по тексту вопроса прямо и кратко, без утопления в стене текста.
hyde 10 июль 2015, в 06:53
5

Во-первых, я все еще считаю отсутствие какого-либо намека на то, что это правило не применяется к глобальному пространству имен, как сбой. Что еще хуже, так это то, что соседние символы подчеркивания запрещены не только в начале, но и в любом месте идентификатора. Таким образом, этот ответ не просто опускает факт, но фактически делает по крайней мере одно активно неправильное утверждение. Как я уже сказал, ссылаться на документы MSVC я бы не стал, если бы не вопрос только о VC.
sbi 12 июль 2015, в 18:48
0

@sbi: Правило внутреннего двойного подчеркивания было разработано для того, чтобы зарезервировать такие идентификаторы для имен с искаженным типом, но я думаю, что имена с двойным подчеркиванием можно было бы учесть, сказав, что любые вхождения __, сгенерированные при искажении на основе типов, будут __x и затем говорят, что любые вхождения __ в указанном имени будут заменены на __y до такого искажения.
supercat 17 авг. 2016, в 14:29
0

А как насчет подчеркивания как полного имени переменной-члена?
PSkocik 21 дек. 2016, в 22:08
0

@sbi Ирония в том, что VC соответствует ISO C ++, который также резервирует имена с одним подчеркиванием, переименовывая некоторые функции posix одновременно, например, _dup () вместо dup ()
Swift - Friday Pie 02 фев. 2017, в 13:35

Показать ещё 6 комментариев

23

Что касается другой части вопроса, то обычно стоит поставить знак подчеркивания в конце имени переменной, чтобы не столкнуться с чем-либо внутренним.

Я делаю это даже внутри классов и пространств имен, потому что мне нужно запомнить только одно правило (по сравнению с "в конце имени в глобальной области видимости и началом имени везде" ).

Max Lybbert 14 нояб. 2008, в 21:24

3

Да, символы подчеркивания могут использоваться в любом месте идентификатора. Я считаю, что правила: любой из a-z, A-Z, _ в первом символе и те + 0-9 для следующих символов.

Префикс подчеркивания распространен в коде C - одно подчеркивание означает "private", а двойные символы подчеркивания обычно зарезервированы для использования компилятором.

John Millikin 23 окт. 2008, в 07:10

3

Они распространены в библиотеках. Они не должны быть общими в пользовательском коде.
Martin York 23 окт. 2008, в 07:12
0

Я согласен с Мартином в этом деле.
paercebal 23 окт. 2008, в 07:42
40

Люди пишут библиотеки в C, вы знаете.
John Millikin 23 окт. 2008, в 17:51
5

«Да, подчеркивания могут использоваться где угодно в идентификаторе». Это неправильно для глобальных идентификаторов. Смотрите ответ Роджера .
sbi 09 июль 2015, в 13:39
0

-1 «Да, подчеркивания могут использоваться где угодно в идентификаторе». Нет.
Cheers and hth. - Alf 03 май 2018, в 20:17

Показать ещё 3 комментария

Ещё вопросы

Страницу руководства glibc об этом можно найти по адресу gnu.org/software/libc/manual/html_node/Reserved-Names.html Редактировать: см. Также opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html
Просто отметим, что незнание этих правил не обязательно означает, что ваш код не будет компилироваться или выполняться, но вполне вероятно, что ваш код не будет переносимым на разные компиляторы и версию, поскольку нельзя гарантировать, что не будет имени столкновения Чтобы подкрепить это, я знаю об определенной реализации важной системы, которая повсеместно использовала в качестве соглашения об именах _ заглавную букву. Там, где нет ошибок из-за этого. Конечно, это плохая практика.
Что насчет #define __WRONG_AGAIN__ ? это тоже неправильно?
@Meysam: __WRONG_AGAIN__ содержит два последовательных подчеркивания (два в начале и два в конце), так что это неправильно в соответствии со стандартом.
@ BЈовић: WRONG__WRONG содержит два последовательных подчеркивания (два в середине), так что это неправильно в соответствии со стандартом
помещение вашего кода в уникальное пространство имен также помогает избежать коллизий : но этого все же недостаточно, поскольку идентификатор может конфликтовать с ключевым словом независимо от области действия (например, __attribute__ для GCC).
Почему существует проблема с двумя последовательными подчеркиваниями в середине в соответствии со стандартом? Пользовательские литеральные суффиксы применяются к литеральным значениям, таким как 1234567L или 4.0f ; IIRC это относится к ohttp: //en.cppreference.com/w/cpp/language/user_literal
Why is there any problem of having two consecutive underscores in the middle according to the standard? Потому что стандарт говорит, что они зарезервированы. Это не совет о хорошем или плохом стиле. Это решение от стандарта. Почему они решили это? Я думаю, что первые компиляторы уже использовали такие соглашения неофициально до стандартизации.
Мне не удалось найти предложение [global.names] или что-то подобное в текущем проекте стандарта ( eel.is/c++draft ). Кажется, он был удален.
Я нашел похожий текст в n3092.pdf (проект стандарта C ++ 0x) в разделе: «17.6.3.3.2 Глобальные имена»
Интересно, что это, кажется, единственный ответ, который имеет прямой, краткий ответ на вопрос.
@hyde: На самом деле это не так, так как оно пропускает правило, чтобы не иметь идентификаторов с ведущим подчеркиванием в глобальном пространстве имен. Смотрите ответ Роджера . Я бы очень осторожно относился к документам MS VC как к авторитету по стандарту C ++.
@sbi Я имел в виду «вы можете использовать одно подчеркивание в качестве префикса переменной-члена, если за ним следует строчная буква» в этом ответе, который отвечает на вопрос по тексту вопроса прямо и кратко, без утопления в стене текста.
Во-первых, я все еще считаю отсутствие какого-либо намека на то, что это правило не применяется к глобальному пространству имен, как сбой. Что еще хуже, так это то, что соседние символы подчеркивания запрещены не только в начале, но и в любом месте идентификатора. Таким образом, этот ответ не просто опускает факт, но фактически делает по крайней мере одно активно неправильное утверждение. Как я уже сказал, ссылаться на документы MSVC я бы не стал, если бы не вопрос только о VC.
@sbi: Правило внутреннего двойного подчеркивания было разработано для того, чтобы зарезервировать такие идентификаторы для имен с искаженным типом, но я думаю, что имена с двойным подчеркиванием можно было бы учесть, сказав, что любые вхождения __, сгенерированные при искажении на основе типов, будут __x и затем говорят, что любые вхождения __ в указанном имени будут заменены на __y до такого искажения.
А как насчет подчеркивания как полного имени переменной-члена?
@sbi Ирония в том, что VC соответствует ISO C ++, который также резервирует имена с одним подчеркиванием, переименовывая некоторые функции posix одновременно, например, _dup () вместо dup ()
Они распространены в библиотеках. Они не должны быть общими в пользовательском коде.
Я согласен с Мартином в этом деле.
Люди пишут библиотеки в C, вы знаете.
«Да, подчеркивания могут использоваться где угодно в идентификаторе». Это неправильно для глобальных идентификаторов. Смотрите ответ Роджера .
-1 «Да, подчеркивания могут использоваться где угодно в идентификаторе». Нет.

Martin York · Accepted Answer · 2008-10-23T08-23-00.000Z

Правила (которые не изменились в C++ 11):

Зарезервировано в любой области, в том числе для использования в качестве макросов реализации:
- идентификаторы, начинающиеся со знака подчеркивания, за которыми сразу следует заглавная буква
- идентификаторы, содержащие соседние подчеркивания (или "двойное подчеркивание")
Зарезервировано в глобальном пространстве имен:
- идентификаторы, начинающиеся с подчеркивания
Кроме того, все в пространстве имен std зарезервировано. (Вы можете добавить шаблонные специализации, хотя.)

Из стандарта 2003 C++:

17.4.3.1.2 Глобальные имена [lib.global.names]

Определенные наборы имен и сигнатур функций всегда зарезервированы для реализации:

Каждое имя, которое содержит двойное подчеркивание (__) или начинается с подчеркивания, за которым следует заглавная буква (2.11), зарезервировано для реализации для любого использования.

Каждое имя, которое начинается со знака подчеркивания, зарезервировано для реализации для использования в качестве имени в глобальном пространстве имен. ¹⁶⁵
¹⁶⁵⁾ Такие имена также зарезервированы в пространстве имен ::std (17.4.3.1).

Поскольку C++ основан на стандарте C (1.1/2, C++ 03), а C99 является нормативным справочным документом (1.2/1, C++ 03), они также применяются в стандарте C 1999 года:

7.1.3 Зарезервированные идентификаторы

Каждый заголовок объявляет или определяет все идентификаторы, перечисленные в связанном с ним подпункте, и, необязательно, объявляет или определяет идентификаторы, перечисленные в соответствующем подпункте будущих направлений библиотеки, и идентификаторы, которые всегда зарезервированы либо для любого использования, либо для использования в качестве идентификаторов области файла.

Все идентификаторы, которые начинаются со знака подчеркивания, а также заглавной буквы или другого знака подчеркивания, всегда зарезервированы для любого использования.

Все идентификаторы, которые начинаются с подчеркивания, всегда зарезервированы для использования в качестве идентификаторов с областью действия файла как в обычном пространстве, так и в пространстве имен тега.

Каждое имя макроса в любом из следующих подпунктов (включая будущие направления библиотеки) зарезервировано для использования, как указано, если включен какой-либо из связанных с ним заголовков; если прямо не указано иное (см. 7.1.4).

Все идентификаторы с внешней связью в любом из следующих подпунктов (включая будущие направления библиотеки) всегда зарезервированы для использования в качестве идентификаторов с внешней связью. ¹⁵⁴

Каждый идентификатор с областью файла, указанной в любом из следующих подпунктов (включая будущие направления библиотеки), зарезервирован для использования в качестве имени макроса и в качестве идентификатора с областью файла в том же пространстве имен, если включен какой-либо из связанных с ним заголовков.
Другие идентификаторы не зарезервированы. Если программа объявляет или определяет идентификатор в контексте, в котором она зарезервирована (за исключением случаев, разрешенных в 7.1.4), или определяет зарезервированный идентификатор как имя макроса, поведение не определено.

Если программа удаляет (с помощью #undef) любое макроопределение идентификатора в первой группе, указанной выше, поведение не определено.

¹⁵⁴⁾ Список зарезервированных идентификаторов с внешней связью включает в себя errno, math_errhandling, setjmp и va_end.

Другие ограничения могут применяться. Например, стандарт POSIX резервирует множество идентификаторов, которые могут отображаться в обычном коде:

Имена, начинающиеся с заглавной буквы E после цифры или заглавной буквы:
- может использоваться для дополнительных имен кодов ошибок.
Имена, начинающиеся с is или to за которыми следует строчная буква
- может использоваться для дополнительного тестирования символов и функций преобразования.
Имена, которые начинаются с LC_ за которым следует заглавная буква
- может использоваться для дополнительных макросов, определяющих атрибуты локали.
Имена всех существующих математических функций с суффиксом f или l зарезервированы
- для соответствующих функций, которые работают с плавающими и длинными двойными аргументами, соответственно.
Имена, которые начинаются с SIG за которым следует заглавная буква, зарезервированы
- для дополнительных имен сигналов.
Имена, которые начинаются с SIG_ за которым следует заглавная буква, зарезервированы
- для дополнительных сигнальных действий.
Имена, начинающиеся с str, mem или wcs за которыми следует строчная буква, зарезервированы
- для дополнительных строковых и массивных функций.
Имена, начинающиеся с PRI или SCN за которыми следует любая строчная буква или X, зарезервированы
- для дополнительных макросов спецификатора формата
Имена, заканчивающиеся на _t, зарезервированы
- для дополнительных имен типов.

Хотя использование этих имен в ваших собственных целях в настоящее время может не вызывать проблем, они повышают вероятность конфликта с будущими версиями этого стандарта.

Лично я просто не начинаю идентификаторы с подчеркивания. Новое дополнение к моему правилу: нигде не используйте двойные подчеркивания, что легко, так как я редко использую подчеркивание.

После исследования этой статьи я больше не заканчиваю свои идентификаторы _t поскольку это зарезервировано стандартом POSIX.

Правило о любом идентификаторе, оканчивающемся на _t меня очень удивило. Я думаю, что это стандарт POSIX (пока не уверен), требующий пояснений, официальных главы и стиха. Это из руководства по GNU libtool, в котором перечислены зарезервированные имена.

CesarB предоставил следующую ссылку на зарезервированные символы POSIX 2004 и отмечает, что "там можно найти много других зарезервированных префиксов и суффиксов...". Зарезервированные символы POSIX 2008 определены здесь. Ограничения несколько более нюансированы, чем указанные выше.

Просто примечание - за исключением нумерации, то, что процитировал Мартин из проекта стандарта, в точности соответствует стандарту C ++ 03 (17.4.3.1.2).
Ваше резюме не говорит то же самое, что цитата из стандарта
глобальные имена отличаются от "любого идентификатора"
@ Adam Mitz: Глобальные имена также охватывают MACROS. Который будет разбрызгивать ваши идентификаторы в кашу. Это то, что я пытался передать.
Вот официальная глава и стих, пожалуйста, добавьте к своему и без того отличному ответу: opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html (и обратите внимание, что там можно найти много других зарезервированных префиксов и суффиксов, которые вы не упомянули).
Стандарт C ++ не «импортирует» стандарт C, не так ли? Насколько я знаю, они импортируют определенные заголовки, но не язык в целом или правила именования. Но да, этот тоже меня удивил. Но так как это C, он может применяться только к глобальным ns. Должно быть безопасно использовать _t внутри классов, как я прочитал
@jalf: Стандарт C ++ определен в терминах стандарта C. В основном это говорит о том, что C ++ - это C с этими различиями и дополнениями.
Мартин, в ответ вы говорите: «Это, по крайней мере, означает, что они не являются макросами ...», которые я читаю как «глобальные имена не являются макросами», и я также думаю, что это не так. макросы не являются членами :: и поэтому не являются глобальными. но в комментарии вы говорите, что «глобальные имена также охватывают MACROS».
каково ваше окончательное мнение по этому поводу? Я видел, что вы добавили эту вещь в ответ после того, как вы сделали свой комментарий. так что у вас такое же мнение, что и у меня, что макросы не являются глобальными именами?
Где стандарт C ++ различает вещи, зарезервированные «для компилятора» и вещи, зарезервированные «для ОС и библиотек», пожалуйста? Я видел, где он резервирует имена для реализации, но не там, где указывается какое-либо различие между «компилятором», «ОС» и «библиотеками» как компонентами реализации.
Стандарт C ++ не «импортирует» Стандарт C. Он ссылается на стандарт Си. Введение в библиотеку C ++ гласит: «Библиотека также предоставляет возможности стандартной библиотеки C». Это достигается путем включения заголовков библиотеки C Standard с соответствующими изменениями, но не путем «импорта». Стандарт C ++ имеет собственный набор правил, который описывает зарезервированные имена. Если имя, зарезервированное в C, должно быть зарезервировано в C ++, это место, чтобы сказать это. Но стандарт C ++ так не говорит. Так что я не верю, что вещи, зарезервированные в C, зарезервированы в C ++ - но я вполне могу ошибаться.
Вот что я обнаружил в проблеме «_t»: n1256 (C99 TC3) говорит: «Имена Typedef, начинающиеся с int или uint и заканчивающиеся _t», зарезервированы. Я думаю, что это все еще позволяет использовать имена типа "foo_t" - но я думаю, что они зарезервированы POSIX.
Из стандарта C ++ 1.1. <quote> C ++ - это язык программирования общего назначения, основанный на языке программирования C, как описано в ISO / IEC 9899: 1990 Языки программирования - C (1.2). В дополнение к возможностям, предоставляемым C, C ++ предоставляет дополнительные типы данных </ quote>. Насколько я понимаю, все, что зарезервировано в C, также зарезервировано в C ++, если иное не указано явно.
Как отмечено в основной статье, суффикс '_t' зарезервирован только стандартом POSIX, а не стандартом C.
Таким образом, «допуск» зарезервирован POSIX, поскольку начинается с «to» + строчная буква? Бьюсь об заклад, много кода нарушает это правило!
@Sjoerd: Возможно. Хотя я уверен, что с тобой все будет в порядке, пока lerance не станет настоящим глаголом, который можно применять к персонажам. Также обратите внимание, что он зарезервирован только в глобальной области видимости (C) _ или стандартном пространстве имен (C ++), поэтому вы можете иметь переменные функции с этим именем без нарушения правила.
@ ReubenMorais: Нет. Прочитайте документацию Posix.
GNU getopt_long() является правонарушителем всех правил: она определяет макросы no_argument , required_argument и optional_argument .
@MaximYegorushkin: Правила не нарушены. Эти идентификаторы зарезервированы для реализации. getopt_long () является частью реализации GNU компиляторов и стандартных библиотек.
@LokiAstari, « Стандарт C ++ определен в терминах стандарта C. По сути, он говорит, что C ++ - это C с этими различиями и дополнениями. » Чепуха! C ++ ссылается только на стандарт C в [basic.fundamental] и библиотеке. Если то, что вы говорите, правда, где C ++ говорит, что _Bool и _Imaginary не существуют в C ++? Язык C ++ определяется явно, а не в терминах «правок» в C, в противном случае стандарт может быть намного короче!
@JonathanWakely: я имел в виду второй абзац в стандарте: <quote> C ++ - это язык программирования общего назначения, основанный на языке программирования C, как описано в ISO / IEC 9899: 1999 Языки программирования - C (в дальнейшем именуемый C стандарт) . В дополнение к возможностям, предоставляемым C, C ++ предоставляет дополнительные типы данных, классы, шаблоны, исключения, пространства имен, перегрузку операторов, перегрузку имен функций, ссылки, бесплатные операторы управления хранилищем и дополнительные библиотечные средства. </ Quote>
Если вы интерпретируете приведенное выше утверждение как означающее что-то другое, я прошу прощения за то, что не совсем верно.
@LokiAstari, это очень общее утверждение, описывающее область применения языка, это не означает, что все в C импортируется в C ++. Язык C ++ (не библиотека) точно определяется своим собственным стандартом, а не ссылкой на другой, за исключением одной ссылки в [basic.fundamental].
@JonathanWakely: <quote> В дополнение к возможностям, предоставляемым C, C ++ предоставляет дополнительные .... </ quote>. Но вы также должны принять комментарий в контексте обсуждения в целом. Мы говорим о «зарезервированных именах» или, более конкретно, «подчеркиваниях». Таким образом, я пытался передать, что зарезервированные имена в C также зарезервированы в C ++. Литб не согласен с этой интерпретацией, и я знаю, что он очень внимательно читает стандарт. Но это разговор, решенный более года назад.
В C ++ я вижу только [lex.name] и глобальные имена [global.names]. Можете ли вы объяснить, как тот факт, что C ++ основан на стандарте C, а C99 является нормативной ссылкой, заставляет правила C99 применяться к C ++. Спасибо
см. [intro.refs] из стандарта, в котором описано, что это значит. Смотрите здесь, чтобы получить копию
@LokiAstari: Я думаю, что ваше утверждение отсталое. Одним из преимуществ C является то, что вы можете использовать идентификаторы, которые он не резервирует; поэтому, если мы собираемся считать буквально уместным, что C ++ включает в себя «средства, предоставляемые C», то идентификаторы, зарезервированные C ++, на самом деле должны быть (самое большее) подмножеством идентификаторов, зарезервированных C, а не надмножеством . (Но на самом деле вы и я оба знаем, что C ++ резервирует некоторые идентификаторы, которых нет в C, так что, очевидно, выражение «средства, предоставляемые C» буквально не уместно.)
@ruakh: я приведу выше цитату из стандарта C 7.1.3 Reserved identifiers . Пожалуйста, перечитайте.
@LokiAstari: Проблема в том, каким будет вопрос? "Оставляет ли C ++ все неопределенное, что оставляет C неопределенным?" слишком тенденциозно (я предполагаю , что вы не можете идти так далеко), в то время как «Все идентификаторы зарезервированы в C, зарезервировали в C ++?» будет закрыт как обман этого. Должен ли я просто процитировать раздел спецификации C ++, который вы цитируете, и спросить, каковы его нормативные последствия?
Может быть полезно знать, что большинство зарезервированных символов POSIX зарезервированы только при включении соответствующего файла включения, т.е. "int stringptr" является "допустимым", пока вы не включите <string.h>.
@LokiAstari Я понимаю, что такого рода стандарты необходимы для C ++. Но, например, в Java есть только несколько зарезервированных имен полей (например, serialVersionUID ), и, конечно, никакие стандарты, такие как переменные, оканчивающиеся на _t не зарезервированы, потому что язык был спроектирован так, что все находится в пространстве имен. Вы говорите, что любой язык, который можно скомпилировать в машинный код на нескольких платформах, должен иметь эти стандарты зарезервированных имен переменных?
Интересно, возникнет ли какая-либо проблема, указав, что определенный префикс был зарезервирован для макросов, определенных в будущих языковых версиях, при условии, что реализации должны либо обрабатывать их в соответствии со стандартом C, либо оставлять их неопределенными. Это позволило бы коду, использующему определенные новые функции, работать на старых компиляторах, определяя макросы для их эмуляции. Например, если __CPP_EITHER (x, y) взял два выражения или оператора и позволил компилятору выбирать между ними произвольным образом (надеюсь, в зависимости от того, что может быть скомпилировано более эффективно), тогда ...
... код, использующий эту директиву, может работать с существующими реализациями, просто #ifndef __CPP_EITHER / #define __CPP_EITHER(x,y) x / #endif , но реализация, которая понимает директиву, может использовать ее для улучшения генерации кода в тех случаях, когда она может скажите, что y будет более эффективным, чем x (в тех случаях, когда он не может сказать, он может просто использовать x ).
@ Грустно, да. Это говорит о том, что любая реализация может определить новую функцию ctype tofoo для любого идентификатора foo начинающегося с буквы, включая lerance . Если это произойдет, и это вызовет конфликт с вашим собственным глобальным, вы были предупреждены. Практический эффект для вас невелик, но он дает POSIX и разработчикам передышку, чтобы добавлять вещи без бесконечных шуток.
Правила могут быть лучше обновлены, чтобы отразить тот факт, что правила зарезервированных имен перемещены из библиотеки (пункт 17) в основной язык (пункт 2) в текущем рабочем проекте стандарта C ++.
Следует отметить, что компиляторы не будут проверять, нарушены ли какие-либо из этих правил резервирования, поэтому, если они используются в коде, они могут работать сегодня, но сломаться (возможно, неуловимым образом) в следующий раз, когда будет применено какое-то безобидное кажущееся обновление или исправление.