Почему не стандартные C++ 14 литералы в глобальном пространстве имен по умолчанию?

C++ 14 включает стандартизированные литералы, среди прочего, std::string и различные временные промежутки от заголовка <chrono>.Почему не стандартные C++ 14 литералы в глобальном пространстве имен по умолчанию?

Для их использования вы должны указать using namespace std::literals; (или некоторые варианты в зависимости от того, какие именно литералы вы хотите, так как они находятся во множестве встроенных пространств имен).

Все это хорошо, но мне любопытно, почему требуется декларация using. UDL без лидирующего подчеркивания зарезервированы для реализации, поэтому нет никакой возможности, что "hello world"s может когда-либо означать что-либо еще в стандартной программе.

Так почему же нет #include <string>, достаточного для того, чтобы преобразовать литерную функцию преобразования в объем? Почему я должен явно включать литеральное пространство имен?

EDIT:N3531 самая последняя версия этого предложения я мог бы найти - к сожалению, это не обсуждается мотивация для сдачи вещей в пространстве имен, но только говорит:

можно суммировать требования [Портленд] обсуждение следующим образом:

использование инлайн пространства имен для группы (связанной) UDL оператора (ов)

источник

2014-10-27 Tristan Brindle

Возможно, по той же причине пользовательские литералы должны начинаться с '_': [forward compatibility] (http://en.wikipedia.org/wiki/Forward_compatibility). Они ожидают добавить больше литералов в какой-то момент в будущем, и я думаю, они помещают их в разные пространства имен, чтобы избежать конфликтов имен. – Cornstalks

@ Закрыть сообщение: Я очень сомневаюсь, что это мнение основано. Комитет по стандартам принял решение. Это спрашивает * почему * они приняли решение, которое они сделали. Это не основано на мнении.Это основано на исторических дискуссиях и решениях в комитете, которые на самом деле. – Cornstalks

«UDL без лидирующего подчеркивания зарезервированы для реализации» Где и в какой версии? –

Существует уже два UDL с именем s: один для строк и один для seconds. Из-за понятных кратковременных имен суффиксов они хронически страдают от конфликтов имен, поэтому выливание всех их в одно пространство имен не может продолжаться долго. Поэтому было решено, что они будут помещены в встроенные пространства имен, что позволяет как однозначно (using namespace std::literals::chrono_literals), так и простые директивы using (using namespace std).

источник

2014-10-27 14:58:51 Columbo

В глобальном пространстве имен никогда не может быть другого '' 'суффикса, потому что все нестандартные UDL должны начинаться с символа подчеркивания. –

@TristanBrindle ... представьте себе ради этого аргумента, что сам стандартный комитет хотел ввести второй «оператор» «s». – Columbo

@TristanBrindle: здесь есть три заинтересованные стороны: стандарт, платформа/реализация/системные библиотеки и конечный разработчик. Только последнему из них запрещено использовать суффиксы UDL без предварительного подчеркивания. –

Посмотрите на бумагу N2765. UDL подключаются к обычным процессам поиска имен. Поскольку строковые литералы имеют общие типы строк, существует большая вероятность столкновения, если вы проигнорировали пространства имен.

источник

2014-10-27 14:57:55 MSalters

стандартная библиотека уже определяет несколько версий того, что s может означать:

Он может быть использован для определения строкового литерала.
Его можно использовать для определения литерала chrono::seconds.

Один из них основан на шнурке буквальном, один основан на целое число или double буквальным, конечно, то есть, они действительно могут сосуществовать. Тем не менее, я ожидаю, что в будущем может быть больше использования s. Таким образом, выбор того, какие пространства имён импортированы, а не наложение на вас, кажется разумным.

источник

2014-10-27 15:00:08

Почему не стандартные C++ 14 литералы в глобальном пространстве имен по умолчанию?

ответ

Смежные вопросы