À primeira vista, parece ser um simples açúcar sintático.
Mas, olhando mais fundo, vemos que é mais do que açúcar sintático, pois estende as opções do usuário do C ++ para criar tipos definidos pelo usuário que se comportam exatamente como tipos internos distintos. Nisso, esse pequeno "bônus" é uma adição muito interessante do C ++ 11 ao C ++.
Nós realmente precisamos dele em C ++?
Vejo poucos usos no código que escrevi nos últimos anos, mas só porque não o usei em C ++ não significa que não seja interessante para outro desenvolvedor de C ++ .
Tínhamos usado no C ++ (e no C, eu acho), literais definidos pelo compilador, para digitar números inteiros como inteiros curtos ou longos, números reais como float ou double (ou mesmo long double) e seqüências de caracteres como caracteres normais ou largos .
Em C ++, tivemos a possibilidade de criar nossos próprios tipos (ou seja, classes), potencialmente sem sobrecarga (embutidos, etc.). Tivemos a possibilidade de adicionar operadores aos seus tipos, para que eles se comportassem como tipos internos semelhantes, o que permite que os desenvolvedores de C ++ usem matrizes e números complexos tão naturalmente quanto teriam se eles fossem adicionados à própria linguagem. Podemos até adicionar operadores de conversão (o que geralmente é uma má idéia, mas às vezes é a solução certa).
Ainda perdemos uma coisa em que os tipos de usuário se comportam como tipos internos: literais definidos pelo usuário.
Então, acho que é uma evolução natural para a linguagem, mas para ser o mais completo possível: " Se você deseja criar um tipo e se comportar o máximo possível dos tipos internos, aqui estão as ferramentas. .. "
Eu acho que é muito semelhante à decisão do .NET de transformar todas as primitivas em uma estrutura, incluindo booleanos, números inteiros etc., e todas as estruturas derivam de Object. Essa decisão por si só coloca o .NET muito além do alcance do Java ao trabalhar com primitivos, independentemente de quanto hacks de boxe / unboxing o Java adicionará à sua especificação.
Você realmente precisa dele em C ++?
Esta pergunta é para você responder. Não Bjarne Stroustrup. Não Herb Sutter. Nenhum membro do comitê padrão de C ++. É por isso que você tem a opção em C ++ , e eles não restringem uma notação útil apenas aos tipos internos.
Se você precisar, é uma adição bem-vinda. Se você não fizer isso, bem ... não usá-lo. Não vai custar nada.
Bem-vindo ao C ++, o idioma em que os recursos são opcionais.
Inchado??? Mostre-me seus complexos !!!
Há uma diferença entre inchado e complexo (trocadilhos).
Como mostrado por Niels em Quais novos recursos os literais definidos pelo usuário adicionam ao C ++? , poder escrever um número complexo é um dos dois recursos adicionados "recentemente" a C e C ++:
// C89:
MyComplex z1 = { 1, 2 } ;
// C99: You'll note I is a macro, which can lead
// to very interesting situations...
double complex z1 = 1 + 2*I;
// C++:
std::complex<double> z1(1, 2) ;
// C++11: You'll note that "i" won't ever bother
// you elsewhere
std::complex<double> z1 = 1 + 2_i ;
Agora, o tipo C99 "duplo complexo" e o tipo C ++ "std :: complex" podem ser multiplicados, adicionados, subtraídos, etc., usando sobrecarga do operador.
Porém, no C99, eles acabaram de adicionar outro tipo como um tipo interno e suporte de sobrecarga de operador interno. E eles adicionaram outro recurso literal embutido.
Em C ++, eles apenas usaram recursos existentes da linguagem, viram que o recurso literal era uma evolução natural da linguagem e, portanto, a adicionaram.
Em C, se você precisar do mesmo aprimoramento de notação para outro tipo, ficará sem sorte até o lobby para adicionar suas funções de ondas quânticas (ou pontos 3D, ou qualquer tipo básico que esteja usando em seu campo de trabalho) ao O padrão C como um tipo interno é bem-sucedido.
No C ++ 11, você pode fazer isso sozinho:
Point p = 25_x + 13_y + 3_z ; // 3D point
Está inchado? Não , a necessidade existe, como mostra como os complexos C e C ++ precisam de uma maneira de representar seus valores complexos literais.
É projetado incorretamente? Não , ele foi projetado como qualquer outro recurso C ++, com extensibilidade em mente.
É apenas para fins de notação? Não , pois pode até adicionar segurança de tipo ao seu código.
Por exemplo, vamos imaginar um código orientado a CSS:
css::Font::Size p0 = 12_pt ; // Ok
css::Font::Size p1 = 50_percent ; // Ok
css::Font::Size p2 = 15_px ; // Ok
css::Font::Size p3 = 10_em ; // Ok
css::Font::Size p4 = 15 ; // ERROR : Won't compile !
É muito fácil impor uma forte digitação à atribuição de valores.
É perigoso?
Boa pergunta. Essas funções podem ter espaço para nome? Se sim, então Jackpot!
De qualquer forma, como tudo, você pode se matar se uma ferramenta for usada incorretamente . C é poderoso, e você pode atirar na cabeça se usar mal a pistola C. O C ++ possui a pistola C, mas também o bisturi, o taser e qualquer outra ferramenta que você encontrará no kit de ferramentas. Você pode usar mal o bisturi e sangrar até a morte. Ou você pode criar um código muito elegante e robusto.
Então, como todo recurso C ++, você realmente precisa dele? É a pergunta que você deve responder antes de usá-lo em C ++. Caso contrário, não lhe custará nada. Mas se você realmente precisa, pelo menos, o idioma não o decepcionará.
O exemplo da data?
Parece-me que seu erro é que você está misturando operadores:
1974/01/06AD
^ ^ ^
Isso não pode ser evitado, porque / como operador, o compilador deve interpretá-lo. E, AFAIK, é uma coisa boa.
Para encontrar uma solução para o seu problema, eu escreveria o literal de alguma outra maneira. Por exemplo:
"1974-01-06"_AD ; // ISO-like notation
"06/01/1974"_AD ; // french-date-like notation
"jan 06 1974"_AD ; // US-date-like notation
19740106_AD ; // integer-date-like notation
Pessoalmente, eu escolheria o número inteiro e as datas ISO, mas isso depende das SUAS necessidades. Qual é o objetivo de deixar o usuário definir seus próprios nomes literais.