A primera vista, parece ser un azúcar sintáctico simple.
Pero cuando miramos más profundamente, vemos que es más que azúcar sintáctica, ya que amplía las opciones del usuario de C ++ para crear tipos definidos por el usuario que se comportan exactamente como los distintos tipos integrados. En esto, este pequeño "bonus" es una adición muy interesante de C ++ 11 a C ++.
¿Realmente lo necesitamos en C ++?
Veo pocos usos en el código que escribí en los últimos años, pero solo porque no lo use en C ++ no significa que no sea interesante para otro desarrollador de C ++ .
Habíamos usado en C ++ (y en C, supongo), literales definidos por el compilador, para escribir números enteros como enteros cortos o largos, números reales como flotante o doble (o incluso doble largo) y cadenas de caracteres como caracteres normales o anchos. .
En C ++, teníamos la posibilidad de crear nuestros propios tipos (es decir, clases), potencialmente sin sobrecarga (en línea, etc.). Tuvimos la posibilidad de agregar operadores a sus tipos, para que se comporten como tipos incorporados similares, lo que permite a los desarrolladores de C ++ usar matrices y números complejos tan naturalmente como lo harían si se hubieran agregado al lenguaje en sí. Incluso podemos agregar operadores de conversión (que generalmente es una mala idea, pero a veces, es la solución correcta).
Todavía nos faltó una cosa para que los tipos de usuario se comporten como tipos incorporados: literales definidos por el usuario.
Por lo tanto, supongo que es una evolución natural para el lenguaje, pero para ser lo más completo posible: " Si desea crear un tipo, y desea que se comporte lo más posible que los tipos incorporados, aquí están las herramientas. .. "
Supongo que es muy similar a la decisión de .NET de hacer que cada primitiva sea una estructura, incluidos booleanos, enteros, etc., y que todas las estructuras se deriven de Object. Esta decisión por sí sola pone a .NET mucho más allá del alcance de Java cuando se trabaja con primitivas, sin importar la cantidad de hacks de boxeo / unboxing que Java agregará a su especificación.
¿Realmente lo necesitas en C ++?
Esta pregunta es para USTED contestar. No Bjarne Stroustrup. No Herb Sutter. No es el miembro del comité estándar de C ++. Es por eso que tiene la opción en C ++ , y no restringirán una notación útil solo a los tipos integrados.
Si lo necesita, entonces es una adición bienvenida. Si no lo haces, bueno ... No lo uses. No te costará nada.
Bienvenido a C ++, el lenguaje donde las características son opcionales.
¿¿¿Hinchado??? Muéstrame tus complejos !!!
Hay una diferencia entre hinchado y complejo (juego de palabras).
Como lo muestra Niels en ¿Qué nuevas capacidades agregan los literales definidos por el usuario a C ++? , poder escribir un número complejo es una de las dos características agregadas "recientemente" a C y 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 ;
Ahora, tanto el tipo "doble complejo" C99 como el tipo "std :: complex" de C ++ pueden multiplicarse, sumarse, restarse, etc., utilizando la sobrecarga del operador.
Pero en C99, simplemente agregaron otro tipo como un tipo incorporado y soporte de sobrecarga del operador incorporado. Y agregaron otra característica literal incorporada.
En C ++, solo usaron las características existentes del lenguaje, vieron que la característica literal era una evolución natural del lenguaje y, por lo tanto, la agregaron.
En C, si necesita la misma mejora de notación para otro tipo, no tiene suerte hasta su cabildeo para agregar sus funciones de onda cuántica (o puntos 3D, o cualquier tipo básico que esté usando en su campo de trabajo) al El estándar C como tipo incorporado tiene éxito.
En C ++ 11, puedes hacerlo tú mismo:
Point p = 25_x + 13_y + 3_z ; // 3D point
¿Está hinchado? No , la necesidad está ahí, como se muestra por cómo los complejos C y C ++ necesitan una forma de representar sus valores complejos literales.
¿Está mal diseñado? No , está diseñado como cualquier otra característica de C ++, teniendo en cuenta la extensibilidad.
¿Es solo para fines de notación? No , ya que incluso puede agregar seguridad de tipo a su código.
Por ejemplo, imaginemos un 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 !
Entonces es muy fácil imponer un tipeo fuerte a la asignación de valores.
¿Es peligroso?
Buena pregunta. ¿Pueden estas funciones tener espacios de nombres? Si es así, entonces Jackpot!
De todos modos, como todo, puedes matarte si una herramienta se usa incorrectamente . C es poderoso, y puedes dispararte si usas mal la pistola C. C ++ tiene la pistola C, pero también el bisturí, la pistola y cualquier otra herramienta que encuentres en el kit de herramientas. Puedes usar mal el bisturí y desangrarte hasta morir. O puede crear un código muy elegante y robusto.
Entonces, como todas las funciones de C ++, ¿realmente lo necesita? Es la pregunta que debe responder antes de usarlo en C ++. Si no lo hace, no le costará nada. Pero si realmente lo necesita, al menos, el idioma no lo defraudará.
El ejemplo de la fecha?
Me parece que su error es que está mezclando operadores:
1974/01/06AD
^ ^ ^
Esto no se puede evitar, porque / siendo un operador, el compilador debe interpretarlo. Y, AFAIK, es algo bueno.
Para encontrar una solución a su problema, escribiría el literal de alguna otra manera. Por ejemplo:
"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
Personalmente, elegiría el entero y las fechas ISO, pero depende de SUS necesidades. Cuál es el objetivo de dejar que el usuario defina sus propios nombres literales.