Пользовательский суффикс литералов, с * _digit ... "?

Question

A пользовательский литеральный суффикс в C ++ 0x должен быть идентификатором , что

• начинается с _ (подчеркивание) (17.6.4.3.5)
• должен не начинаться с _, за которым следует заглавная буква (17.6.4.3.2)

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

Есть ли причина, по которой такой суффикс может не начинаться _ , за которым следует цифра ? И.Е. _4 или _3musketeers?

Musketeer dartagnan = "d'Artagnan"_3musketeers;
int num = 123123_4; // to be interpreted in base4 system?
string s = "gdDadndJdOhsl2"_64; // base64decoder

Answer 1

Я знал У меня было несколько работ на эту тему: Цифровые разделители описывает предложение использовать _ в качестве разделителя цифр в числовых литералах

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

Это выглядит не очень хорошо для разделителя цифр _.

У меня была идея: как насчет обратной косой черты или обратной косой черты для разделителя цифр? Это не так хорошо, как _, но я не думаю, что будет какое-либо столкновение, если обратный слеш находится внутри потока цифр. На данный момент у меня нет лексического использования, о котором я знаю.

i = 123\456\789;
j = 0xface\beef;

или

i = 123`456`789;
j = 0xface`beef;

Это оставит _123 буквальным суффиксом.

Answer 2

Прецедент для идентификаторов вида _<number> является механизмом объекта-заполнителя аргумента функции в std::placeholders (§20.8.9.1.3), который определяет число таких символов, определяемое реализацией.

Это хорошая вещь, потому что это означает, что пользователь не может #define любой идентификатор этой формы.§17.6.4.3.1 / 1:

Блок перевода, который включает стандартный заголовок библиотеки, не должен имен #define или #undef, объявленных в любом заголовке стандартной библиотеки.

Имя пользовательской литеральной функции - operator "" _123, а не просто _123, поэтому нет прямого конфликта между вашим именем и именем библиотеки, если присутствует using namespace std::placeholders;.

My 2¢ тем не менее, вам лучше использовать operator "" _baseconv и кодировать базу в литерале, "123123_4"_baseconv.

Редактировать: Глядя на Иоганнеса '(удалено) ответ, есть Может возникнуть опасение, что реализация может быть использована как макрос в качестве макроса *1026*.Это, безусловно, область теории, так как при таком использовании препроцессора реализация вряд ли выиграет.Кроме того, если я не ошибаюсь, причина скрытия этих символов в std::placeholders, а не std, заключается в том, что такие имена больше могут использоваться пользователем, например, путем включенияBoost Bind (который не скрывает их в именованном пространстве имен).

Токены не зарезервированы для использования реализацией глобально (17.6.4.3.2), и существует прецедентдля их использования, поэтому они по крайней мере так же безопасны, как, скажем, forward.

Answer 3

Подчеркивание, за которым следует цифра, является допустимым пользовательским буквенным суффиксом. Сигнатура функции будет: оператор "" _4 (); так что это не может быть съедено заполнителем. Литерал будет одиночным токеном препроцессора : 123123_4; поэтому _4 не будет засорен заполнителем или символом препроцессора.

Мое прочтение 17.6.4.3.5 состоит в том, что суффиксы, не содержащие основного риска подчеркивания, сталкиваются с реализацией или будущими дополнениями библиотеки. Они также сталкиваются с существующими суффиксами: F, L, ULL и т. Д. Одним из обоснований пользовательских литералов является то, что новый тип (например, десятичные) может быть определен как чистое расширение библиотеки, включающее литералы с суффиксами d, дф, дл.

Тогда возникает вопрос стиля и читабельности. Лично я думаю, что потерял бы из виду суффикс 1234_3; Может быть, а может и нет.

Наконец, была некоторая идея, которая не вошла в стандарт (но я вроде как) иметь _ буквальный разделитель для чисел, как в Ada и Ruby. Таким образом, вы можете иметь 123_456_789 для визуального разделения тысяч, например. Ваш суффикс сломался бы, если бы это когда-либо проходило.

Answer 4

"can" против "may" .
can обозначает способность, где may обозначает разрешение.

Есть ли причина, по которой вы бынет разрешения на запуск пользовательского литерального суффикса с _, за которым следует цифра?

Разрешение подразумевает стандарты кодирования или лучшие практики.Представленные вами примеры, по-видимому, показывают, что _\d подойдет для суффиксов при правильном использовании (для обозначения числовой базы).К сожалению, ваш вопрос не может иметь хорошо продуманный ответ, поскольку никто не имеет опыта работы с этой новой языковой функцией.

Просто чтобы прояснить ситуацию user-defined literal suffixes может начинаться с _\d.