Discussion :

[JolyLoic]

Bonjour à tous,

Je viens de publier une traduction d'un article de Bjarne Stroustrup discutant de Cinq mythes courants sur le C++.

Je trouve que cet article est intéressant non seulement pour ceux qui débutent en C++, mais aussi pour ceux qui connaissent un langage qui fait partie de la même famille (C, C#, Java...) et qui voudraient avoir une idée de ce qui caractérise le C++, de ce qui lui est spécifique.

N'hésitez pas à laisser vos commentaires !

PS : Suite à l'article et aux nombreuses remarques qu'il a suscitées, Bjarne a aussi publié une postface (pas encore traduite).

[Tawane]

Bonjour et merci pour cette traduction, l'article est intéressant.

Je n'ai pas fini de le lire mais je pose une question. A plusieurs reprise les exemples de code donnés utilisent des accolades {} là où j'aurais naturellement mis des parenthèses ().

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
void user2()
{
  Filter flt {"books","authors"};
  unique_ptr<Filter> p {new Filter{"novels","favorites"}};
  // on utilise flt et *p
}

Dans cet exemple, je pensais qu'il était impossible d'utiliser des accolades pour passer les 2 arguments au constructeur de Filter. S'agit-il d'un des standard de C++ ou d'une erreur de recopie/traduction ?

[bacelar]

Il s'agit de "nouvelles" notations introduites avec le C++11, en 2011.

[JolyLoic]

C'est possible à partir du C++11, et ça permet une syntaxe d'initialisation plus uniforme dans les différents cas (même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas). Une des nouveautés appréciables apportées par cette syntaxe est la capacité d'initialiser des collections :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

map<string, string> m {{"Hello", "Bonjour"}, {"World", "Monde"}};

En tant que promoteur principale de cette syntaxe, Bjarne l'utilise systématiquement dans ses articles. Et l'idée est que si on souhaite n'apprendre qu'une seule syntaxe à quelqu'un, autant apprendre celle là.

[Tawane]

Ok, je connaissais la nouvelle syntaxe pour initialiser un liste en passant toutes les valeurs séparées par des virgules, le tout entre accolades. Mais la possibilité d'utiliser cette syntaxe pour initialiser un objet classique m'avait complètement échappé. Je m'en vais trouver un peu de doc là dessus.
Merci

[ternel]

Un point d'entrée comme un autre, list initialization sur cppreference.com.

[bouye]

Mouai, intéressant mais surtout destinés a ceux qui commencent le C++ aujourd'hui et en utilisant des bibliothèques modernes et non pas des vieux machins legacy d'il y a 20+ ans.

Pour les vieux fossiles comme moi, a l’époque le char* était plus courant que le string, la lib standard C++ était peanuts, et la majorité des libs externes étaient écrites en C ou en C++ C-like. Donc oui ça avait beaucoup beaucoup plus de sens de commencer par C a l'epoque. Mais cela concernait les versions de C++ circa 96-98-01. Évidement c'est moins évident que de commencer directement en C++ '11. Porter l’intégralité d'un programme ou d'un framework pre-existant (donc écrit a l'ancienne) demande des investissements (entre autre dans mon cas la formation de scientifiques et mathématiciens qui développent des modèles) qu'on ne peut pas tout le temps se permettre (ou ne veut pas dans leur cas).

Pour le reste non, bien que The C++ Programming Language ~ Special Edition de Stroustrup (livre qui, a nouveau, concerne des anciennes versions de C++) trône sur mes étagères derrière moi depuis plus de 10 ans bien que je fasse du C++ assez régulièrement, j'ai toujours une réaction de rejet quand j'essaie de lire la doc d'une classe ou d'une méthode de fonction a 45 (j’exagère) arguments génériques imbriquées dont ni le nom ni la doc ne m'explique clairement ce a quoi ils ou elle servent. Probablement une déformation de faire du Java (que d'aucun trouvent trop verbeux justement a cause des noms trop long et trop explicites). Ceci dit les dernières évolutions de Java 8 font que désormais on peut retrouver cette même complexité de compréhension en utilisant trop de génériques et de lambda pour reduire un bloc de code a une instruction d'une seule ligne donc en gros on a atteint le même niveau.

Ensuite, n'essaie-t-il pas de prêcher des convertis ? Je veux dire, prenons les sessions vidéo de la dernière conf C++ qui ont été publié ici sur Developpez. Rien que les sessions présentées par Ubisoft sont quand même parlantes : si on veut de la perf brute (et dans le cas d'Ubi de la portabilité sur les plateformes de jeux via leurs framework maison), on fait du C++. Pour eux le C# ne sert que pour les outils middleware qu'ils utilisent en interne ; le produit qui sera publié et vendu sera lui écrit en C++ principalement.

[Neckara]

Bonjour,

C'est possible à partir du C++11, et ça permet une syntaxe d'initialisation plus uniforme dans les différents cas (même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas). Une des nouveautés appréciables apportées par cette syntaxe est la capacité d'initialiser des collections :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

map<string, string> m {{"Hello", "Bonjour"}, {"World", "Monde"}};

En tant que promoteur principale de cette syntaxe, Bjarne l'utilise systématiquement dans ses articles. Et l'idée est que si on souhaite n'apprendre qu'une seule syntaxe à quelqu'un, autant apprendre celle là.

J'avoue que je ne comprend pas vraiment son raisonnement. Comme tu l'as dit :

même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas

En effet, si on a :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class C{
     C( std::initializer_list<int>() values ); // (1)
     C(int taille, int default value = int() ); // (2)
};

Alors :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
C(5,5)
C{5,5}
 
C(4)
C{4}

Ne font pas du tout la même chose, c'est donc, de mon avis, un hérésie de mélanger les deux.
En effet, si on n'utilise que {}, il y a de fortes chances qu'on ne fasse pas la distinction entre {} et () ce qui sera très préjudiciable par la suite.
Autant se dire tout de suite : () = constructeur normal et {} = constructeur par liste d'initialisation.

Imaginons qu'on ai uniquement le constructeur (2) et qu'on utilise des accolades. On décide ensuite d'ajouter le constructeur (1) quelques mois plus tard. Que fait-on par la suite ? On réécrit tout notre code ? On oublie certaines partie et on laisse des {} là où il faudrait maintenant des () ?

De plus, je ne comprend pas l'argument d'uniformisation, pour moi, c'est encore moins uniforme !
Pour les initialiseurs, {}
Pour les autres constructeurs, {} ou () si un initialiseur d'arguments "similaire" existe.

[jblecanard]

De plus, je ne comprend pas l'argument d'uniformisation, pour moi, c'est encore moins uniforme !

C'est plus uniforme car la même syntaxe est utilisée pour constructeurs par initializer_list et les constructeurs classiques. C'est le seul moyen pour écrire des constructions de collections imbriquées. L'ancienne syntaxe doit être conservée car la rétro-compatibilité est une feature en C++.

Imaginons qu'on ai uniquement le constructeur (2) et qu'on utilise des accolades. On décide ensuite d'ajouter le constructeur (1) quelques mois plus tard. Que fait-on par la suite ? On réécrit tout notre code ? On oublie certaines partie et on laisse des {} là où il faudrait maintenant des () ?

Pour cette même raison, si tu conçois ton code de sorte à ce que n'utiliser que la notation {} donne un code valide, le problème ne se posera pas. Et s'il se pose, si tu utilises la différence ce notation pour lever l'ambiguité, il y a un risque de mal utiliser le code car les deux syntaxes sont quand même disponibles. Oui, ça peut introduire des confusions, c'est un défaut notable, mais que perso je considère acceptable au regard du gain.

[Neckara]

C'est plus uniforme car la même syntaxe est utilisée pour constructeurs par initializer_list et les constructeurs classiques.

Sauf dans le cas où on a les deux (initializer_list et les constructeurs classiques) possibles pour les même arguments.
Imagine aussi, tu veux appeler C(int, int).
Tu vas mettre des {} par habitude. Grossière erreur, il faut au préalable et systématiquement vérifier si ta classe C ne possède pas de constructeur avec initializer_list pouvant "matcher".
Je ne pense pas que ce soit vraiment pratique pour l'utilisateur, et pire encore pour le débutant.
Le pauvre qui n'arrivera pas à comprendre pourquoi sa classe n'est pas initialisée comme il le souhaiterait .

Je trouve qu'il est plus simple de lui dire "utilise ()".
Puis plus tard, quand on voit les initializer_list, lui dire "utilise {} pour les initializer_list".

Plutôt que de lui dire "utilise {}" et quand il a pris l'habitude d'utiliser les {}, on lui montre les initializer_list et on lui dit, "on t'as menti, en fait c'est pas toujours {}, parfois faut utiliser ()".
Ou alors travailler en C++90 sur des projets et en C++11 sur d'autres, passer de () à {} et inversement, cela peut vite devenir soûlant.

Je ne parle pas de la configuration des IDE pour les auto-complétion et extraits de codes…

Et s'il se pose, si tu utilises la différence ce notation pour lever l'ambiguité

Donc on doit modifier tout code qui utilise notre classe ?
Cela va à l'encontre des bon principes de programmations.

Encore pire si notre classe fait partie d'une bibliothèque utilisée par d'autres…

perso je considère acceptable au regard du gain.

J'ai, personnellement du mal à voir le gain apporté par l'utilisation de {} pour le constructeur au lieu de ().