À première vue, il semble s'agir d'un simple sucre syntaxique.
Mais en regardant plus en profondeur, nous voyons que c'est plus que du sucre syntaxique, car il étend les options de l'utilisateur C ++ pour créer des types définis par l'utilisateur qui se comportent exactement comme des types intégrés distincts. En cela, ce petit "bonus" est un ajout très intéressant du C ++ 11 au C ++.
En avons-nous vraiment besoin en C ++?
Je vois peu d'utilisations dans le code que j'ai écrit ces dernières années, mais ce n'est pas parce que je ne l'ai pas utilisé en C ++ que ce n'est pas intéressant pour un autre développeur C ++ .
Nous avions utilisé en C ++ (et en C, je suppose), des littéraux définis par le compilateur, pour taper des nombres entiers comme des entiers courts ou longs, des nombres réels comme float ou double (ou même long double), et des chaînes de caractères comme des caractères normaux ou larges .
En C ++, nous avions la possibilité de créer nos propres types (ie classes), sans potentiellement aucun surcoût (inlining, etc.). Nous avons eu la possibilité d'ajouter des opérateurs à leurs types, de les faire se comporter comme des types intégrés similaires, ce qui permet aux développeurs C ++ d'utiliser des matrices et des nombres complexes aussi naturellement qu'ils l'auraient fait si ceux-ci avaient été ajoutés au langage lui-même. Nous pouvons même ajouter des opérateurs de cast (ce qui est généralement une mauvaise idée, mais parfois, c'est juste la bonne solution).
Nous avons encore manqué une chose pour que les types d'utilisateurs se comportent comme des types intégrés: les littéraux définis par l'utilisateur.
Donc, je suppose que c'est une évolution naturelle pour le langage, mais pour être aussi complète que possible: " Si vous voulez créer un type, et que vous voulez qu'il se comporte autant que possible comme un type intégré, voici les outils. .. "
Je suppose que c'est très similaire à la décision de .NET de faire de chaque primitive une structure, y compris les booléens, les entiers, etc., et que toutes les structures dérivent d'Object. Cette décision à elle seule place .NET bien au-delà de la portée de Java lorsqu'il travaille avec des primitives, quel que soit le nombre de hacks de boxe / déballage que Java ajoutera à sa spécification.
En avez-vous vraiment besoin en C ++?
C'est à VOUS de répondre à cette question. Pas Bjarne Stroustrup. Pas Herb Sutter. Pas n'importe quel membre du comité de normalisation C ++. C'est pourquoi vous avez le choix en C ++ , et ils ne limiteront pas une notation utile aux seuls types intégrés.
Si vous en avez besoin, c'est un ajout bienvenu. Si vous ne le faites pas, eh bien ... Ne l'utilisez pas. Cela ne vous coûtera rien.
Bienvenue dans C ++, le langage où les fonctionnalités sont facultatives.
Gonflé??? Montrez-moi vos complexes !!!
Il y a une différence entre gonflé et complexe (jeu de mots).
Comme montré par Niels à Quelles nouvelles fonctionnalités les littéraux définis par l'utilisateur ajoutent-ils au C ++? , être capable d'écrire un nombre complexe est l'une des deux fonctionnalités ajoutées "récemment" en C et 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 ;
Désormais, les types C99 "double complex" et C ++ "std :: complex" peuvent être multipliés, ajoutés, soustraits, etc., en utilisant la surcharge d'opérateurs.
Mais dans C99, ils ont simplement ajouté un autre type en tant que type intégré et une prise en charge intégrée de la surcharge des opérateurs. Et ils ont ajouté une autre fonctionnalité littérale intégrée.
En C ++, ils ont juste utilisé les fonctionnalités existantes du langage, ont vu que la fonctionnalité littérale était une évolution naturelle du langage, et l'ont donc ajoutée.
En C, si vous avez besoin de la même amélioration de notation pour un autre type, vous n'avez pas de chance jusqu'à ce que votre lobbying ajoute vos fonctions d'onde quantique (ou points 3D, ou tout autre type de base que vous utilisez dans votre domaine de travail) au La norme C en tant que type intégré réussit.
En C ++ 11, vous pouvez le faire vous-même:
Point p = 25_x + 13_y + 3_z ; // 3D point
Est-ce gonflé? Non , le besoin est là, comme le montre la façon dont les complexes C et C ++ ont besoin d'un moyen de représenter leurs valeurs complexes littérales.
Est-il mal conçu? Non , il est conçu comme toutes les autres fonctionnalités C ++, avec l'extensibilité à l'esprit.
Est-ce uniquement à des fins de notation? Non , car cela peut même ajouter une sécurité de type à votre code.
Par exemple, imaginons un code orienté 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 !
Il est alors très facile d'imposer un typage fort à l'attribution des valeurs.
Est-ce dangereux?
Bonne question. Ces fonctions peuvent-elles être espacées de noms? Si oui, alors Jackpot!
Quoi qu'il en soit, comme tout, vous pouvez vous tuer si un outil n'est pas utilisé correctement . C est puissant et vous pouvez vous tirer la tête si vous utilisez mal le pistolet C. C ++ a le pistolet C, mais aussi le scalpel, le taser et tout autre outil que vous trouverez dans la boîte à outils. Vous pouvez mal utiliser le scalpel et vous saigner à mort. Ou vous pouvez créer un code très élégant et robuste.
Alors, comme toute fonctionnalité C ++, en avez-vous vraiment besoin? C'est la question à laquelle vous devez répondre avant de l'utiliser en C ++. Sinon, cela ne vous coûtera rien. Mais si vous en avez vraiment besoin, au moins, la langue ne vous laissera pas tomber.
L'exemple de la date?
Votre erreur, il me semble, est que vous mélangez des opérateurs:
1974/01/06AD
^ ^ ^
Cela ne peut pas être évité, car / étant un opérateur, le compilateur doit l'interpréter. Et, AFAIK, c'est une bonne chose.
Pour trouver une solution à votre problème, j'écrirais le littéral d'une autre manière. Par exemple:
"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
Personnellement, je choisirais l'entier et les dates ISO, mais cela dépend de VOS besoins. C'est tout l'intérêt de laisser l'utilisateur définir ses propres noms littéraux.