На первый взгляд, это простой синтаксический сахар.
Но если заглянуть глубже, мы увидим, что это больше, чем синтаксический сахар, поскольку он расширяет возможности пользователя C ++ для создания пользовательских типов, которые ведут себя точно так же, как отдельные встроенные типы. В этом небольшом «бонусе» является очень интересное дополнение C ++ 11 к C ++.
А действительно ли это нужно в C ++?
Я вижу мало применений в коде, который я написал в последние годы, но то, что я не использовал его в C ++, не означает, что он не интересен для другого разработчика C ++ .
Мы использовали в C ++ (и, как мне кажется, в C) литералы, определенные компилятором, для ввода целых чисел как коротких или длинных целых чисел, вещественных чисел как чисел с плавающей запятой или двойных (или даже длинных двойных) и символьных строк как обычных или широких символов. .
В C ++ у нас была возможность создавать наши собственные типы (то есть классы), потенциально без накладных расходов (встраивание и т. Д.). У нас была возможность добавлять операторы к их типам, чтобы они вели себя как похожие встроенные типы, что позволяет разработчикам C ++ использовать матрицы и комплексные числа так же естественно, как если бы они были добавлены в сам язык. Мы даже можем добавить операторы приведения (обычно это плохая идея, но иногда это просто правильное решение).
Мы все еще упускаем одну вещь, чтобы пользовательские типы вели себя как встроенные типы: определяемые пользователем литералы.
Итак, я полагаю, что это естественная эволюция языка, но должна быть как можно более полной: « Если вы хотите создать тип, и вы хотите, чтобы он вел себя как можно больше как встроенные типы, вот инструменты. .. "
Я предполагаю, что это очень похоже на решение .NET сделать каждый примитив структурой, включая логические, целые числа и т. Д., И унаследовать все структуры от Object. Одно только это решение выводит .NET далеко за пределы возможностей Java при работе с примитивами, независимо от того, сколько хаков для упаковки / распаковки Java добавит в свою спецификацию.
ВАМ это действительно нужно на C ++?
На этот вопрос ВЫ должны ответить. Только не Бьярн Страуструп. Только не Херб Саттер. Ни один член комитета по стандартизации C ++. Вот почему у вас есть выбор в C ++ , и они не ограничивают полезную нотацию только встроенными типами.
Если вам это нужно, то это долгожданное дополнение. Если нет, что ж ... Не используйте это. Это вам ничего не будет стоить.
Добро пожаловать в C ++, язык, в котором функции не являются обязательными.
Вздутие ??? Покажи мне свои комплексы !!!
Есть разница между раздутым и сложным (каламбур).
Как показано Нильсом на сайте Какие новые возможности пользовательские литералы добавляют в C ++? , возможность писать комплексное число - одна из двух функций, добавленных «недавно» в C и C ++:
MyComplex z1 = { 1, 2 } ;
double complex z1 = 1 + 2*I;
std::complex<double> z1(1, 2) ;
std::complex<double> z1 = 1 + 2_i ;
Теперь и тип «двойной комплекс» в C99, и тип «std :: complex» в C ++ можно умножать, складывать, вычитать и т. Д. С помощью перегрузки оператора.
Но в C99 они просто добавили еще один тип как встроенный тип и встроенную поддержку перегрузки операторов. И они добавили еще одну встроенную буквальную функцию.
В C ++ они просто использовали существующие функции языка, увидели, что буквальная функция является естественным развитием языка, и поэтому добавили ее.
В C, если вам нужно такое же улучшение обозначений для другого типа, вам не повезет, пока вы не начнете лоббировать добавление ваших квантовых волновых функций (или трехмерных точек, или любого другого базового типа, который вы используете в своей области работы) в Стандарт C как встроенный тип преуспевает.
В C ++ 11 это можно сделать самостоятельно:
Point p = 25_x + 13_y + 3_z ;
Он раздут? Нет , необходимость в этом есть, как показывает то, как комплексы C и C ++ нуждаются в способе представления своих буквальных комплексных значений.
Это неправильно спроектировано? Нет , он разработан, как и любая другая функция C ++, с учетом расширяемости.
Это только для обозначений? Нет , так как это может даже добавить в код безопасность типов.
Например, представим код, ориентированный на CSS:
css::Font::Size p0 = 12_pt ;
css::Font::Size p1 = 50_percent ;
css::Font::Size p2 = 15_px ;
css::Font::Size p3 = 10_em ;
css::Font::Size p4 = 15 ;
Тогда очень легко обеспечить строгую типизацию для присвоения значений.
Это опасно?
Хороший вопрос. Можно ли разместить эти функции в пространстве имен? Если да, то Джекпот!
В любом случае, как и все, вы можете убить себя, если использовать инструмент неправильно . C мощный, и вы можете выстрелить себе в голову, если неправильно воспользуетесь пистолетом C. В C ++ есть пистолет C, а также скальпель, электрошокер и другие инструменты, которые вы найдете в наборе инструментов. Вы можете злоупотребить скальпелем и истечь кровью до смерти. Или вы можете создать очень элегантный и надежный код.
Итак, как и любая функция C ++, действительно ли она вам нужна? Это вопрос, на который вы должны ответить, прежде чем использовать его в C ++. Если вы этого не сделаете, это вам ничего не будет стоить. Но если это действительно нужно, по крайней мере, язык вас не подведет.
Пример даты?
Ваша ошибка, как мне кажется, в том, что вы смешиваете операторы:
1974/01/06AD
^ ^ ^
Этого нельзя избежать, потому что /, будучи оператором, компилятор должен его интерпретировать. И, AFAIK, это хорошо.
Чтобы найти решение вашей проблемы, я бы написал литерал по-другому. Например:
"1974-01-06"_AD ;
"06/01/1974"_AD ;
"jan 06 1974"_AD ;
19740106_AD ;
Лично я бы выбрал целое число и даты ISO, но это зависит от ВАШИХ потребностей. В этом весь смысл позволить пользователю определять свои собственные буквальные имена.