Столкновение имен пространств имен в смешанном регистре

Question

Пространства имен C ++ предотвращают конфликты, но что, если имя самого пространства имен конфликтует? Пример:

#include <cstdlib>

namespace atoi {
    int foo() {return 42;}
}

Вопрос: могу ли я надежно избежать столкновения по namespace Atoi? То есть, защищает ли C ++ мое использование имени пространства имен в смешанном регистре, например Atoi? Или это имя пространства имен в смешанном регистре, например Atoi, которое может быть вытеснено будущим стандартом C ++, технической спецификацией (TS), библиотекой Boost, компилятором, цепочкой инструментов и т. Д .?

Конечно, я на самом деле не намерен namespace atoi или namespace Atoi для практического кода. Это просто для иллюстрации (поскольку atoi - это имя, которое использует стандартная библиотека C). То, что я действительно намереваюсь, это namespace my, предпочтительно в нижнем регистре, но при необходимости в смешанном регистре как namespace My Ваш ответ относительно atoi и Atoi может повлиять на мой выбор между my и My. Вот почему я спрашиваю.

Я заметил, что Страуструп предпочитает имена пространства имен в смешанном регистре. Я также заметил, что примеры в секте. 10.3 стандарта C ++ 17 (черновик здесь ), избегайте строчных имен пространств имен.

См. Также этот связанный вопрос.

Answer 1

могу ли я надежно избежать столкновения по пространству имен Atoi?

Достоверно надежно. В стандартной библиотеке языка C нет идентификатора с таким именем.

Или это имя пространства имен в смешанном регистре, такое как Atoi, которое может быть растоптано будущим стандартом C ++, технической спецификацией (TS), библиотекой Boost, компилятором, цепочкой инструментов и т. Д .?

Весьма маловероятно.

Расширения компилятора должны использовать зарезервированные идентификаторы.

Новые идентификаторы стандартной библиотеки (включая TS) добавляются в пространство имен std (или пространство имен, вложенное в std). Boost должен добавить свои идентификаторы в пространство имен boost.

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

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

Немного более проблематичными являются стандартные заголовки POSIX, которые добавляют довольно много идентификаторов, которые не зарезервированы стандартом C в глобальном пространстве имен. Он добавляет довольно много зарезервированных префиксов и суффиксов в зависимости от того, какие заголовки POSIX включены.

Используя заглавную букву, за которой следует строчная буква, например, Atoi, вы избегаете конфликтов с большинством резервирований POSIX и большинством стандартных имен, которые строго следуют условию всех строчных или прописных букв (обычно для макросов).

---

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

• Никогда не используйте идентификаторы, зарезервированные стандартом, даже в пространствах имен.
• Избегайте макросов.
  • Используйте постоянный префикс при именовании макросов.
• Объявите только одно пространство имен в глобальном масштабе, и никаких других глобальных идентификаторов.
  • Объявите все остальное в этом пространстве имен.
• Совместное использование общего пространства имен для всех ваших проектов.
  • Не обязательно подходит для универсальных, многократно используемых библиотек.
  • Используйте подпространства имен, чтобы избежать коллизий между вашими проектами.
  • Используйте вложенные пространства имен, чтобы избежать коллизий в ваших проектах.
• При именовании глобального идентификатора (то есть глобального пространства имен или макроса) избегайте имен, зарезервированных стандартом POSIX.

Answer 2

Посмотрите: Рекомендации по совместимости стандартной библиотеки . В этом видео от Titus Winters указано, на что оставляет за собой право комитет по стандартам, и на что не следует полагаться в стандартной библиотеке.

Этот должен быть официальным документом. Я нашел это в описании видео. Это то, что нас волнует:

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

● Добавление новых имен в пространство имен std

● Добавление новых функций-членов к типам в пространстве имен std

● Добавление новых перегрузок к существующим функциям

● Добавить новые аргументы по умолчанию для функций и шаблонов

● Изменение типов возвращаемых функций совместимыми способами (от все, числовые типы в расширяющемся порядке и т. д.).

● Вносить изменения в существующие интерфейсы таким образом, чтобы обратная совместимость, если эти интерфейсы используются исключительно для создания экземпляров типы и функции вызова. Детали реализации (основное имя тип, детали реализации для вызываемой функции) могут не зависит от.

○ Например, мы можем изменить детали реализации для стандарта Шаблоны функций так, что они становятся вызываемыми объектами функций. Если Пользовательский код только вызывает, который можно вызвать, поведение остается неизменным.