Aller, j'en ajoute (C++ est mon outil de travail 8h par jour depuis plus de 10 ans) en me focalisant sur les problèmes qui m’embêtent vraiment au quotidien et pour lesquels il n'y a pas de solution simple. J'essaye de rester objectif ;)
Les casts implicites. Plus particulièrement le fait que les flottants, les ints, les bools, les enums, et j'en passe, c'est la même chose. Le downcast implicite d'une classe vers une autre. Je sais que c'est la philosophie du langage. Combien de fois je me suis fais manger par un int négatif convertit en unsigned...
L'absence de programmation générique. J'aimerais c'est pouvoir automatiquement dériver des comportements pour mes classes. À la louche, l'itération, l'affichage, la sérialisation, la comparaison, les relations d'ordre, le hash, l'enumeration, ... Je recode ces trucs là pour presque chaque classe et c'est du temps perdu, du code en plus, des tests en plus, des bugs en plus, de la maintenance en plus.
L'absence de types algébriques (i.e. des union typés). Je dirais à la louche que 99% des choses que je traite avec de l'héritage (ou des gros hacks degeux) sont des problématique de types algébriques. L'héritage virtuel sera ici trop verbeux et impose des allocations sur le tas (on peut s'en sortir autrement, mais c'est tordu). La solution à base d'union et de flag est un piège dans lequel on ne tombe qu'un fois tellement c'est l'horreur à maintenir après.
Pas de pattern matching.
Pas de concepts ;)
Un système de type limité et hyper verbeux ce qui fait que on essaye de ne pas créer de nouveau type parce que c'est complexe. Je le retrouve tous les jours au travail ou en formation, un développeur C++ est heureux quand il a une classe suffisamment générique pour traiter tous ses cas, alors que moi je serais heureux quand j'aurais 100 classes suffisamment spécifiques pour traiter tous mes cas avec une bonne sécurité. Mais je ne le fais pas parce que maintenir 100 classes en C++ versus une, c'est l'horreur. Faire de la délégation en C++ c'est lourd.
Les valeurs par défaut. Beaucoup de classes de la STL imposent que votre type soit default constructible, comme par exemple le deleter de std::unique_ptr. Cela force à mettre des constructeur par défaut complètement abscons à beaucoup d'endroits.
Une absence totale de système de gestion de descendances, librairies, packaging. C'est l'horreur de taper à la main la compilation / installation de 25 librairies tierces.
Tout est mutable par défaut ;( Là c'est clairement un point subjectif de ma part, mais je n'aime pas.
La communauté. N'allez surtout pas sur IRC si vous n’êtes pas un dieu du C++, vous vous ferez allumer et traiter d’incompétent. Expérience personnelle que j'ai mal vécue : je suis aller sur #C++ sur irc.freenode.net pour discuter une subtilité du langage qui m'avait étonnée et on m'a envoyer paître en me traitant d’incompétent qui ne comprenait pas la philosophie du langage. J'ai fais l'erreur dans mon texte de dire que j'avais rencontré cette subtilité pendant le cours de compilation que je donne à l'université et ils m'ont descendu en expliquant que soit j’étais un troll, soit j'étais un mauvais enseignant, mais qu'il n'était pas possible d'être aussi mauvais et que je ferais mieux de me pendre ou de lire un livre de C++ pour débutant.
Alors pourquoi C++ est-il mon outil de travail si ce langage est si mauvais ? Parce qu'en premier lieu, tous les langages du monde sont mauvais, en second lieu, c'est le seul à l'heure actuel qui m'apporte plusieurs choses :
a) Les performances, qui sont vraiment critiques dans mon métier.
b) Les librairies. Toutes les libraires utiles dans mon métier sont écrites en C++, sans interface C.
c) L'historique, l'outil actuel est écrit en C++ et on ne peut pas tout réécrire from scratch.
d) Les gens formés. Trouver quelqu'un qui sait aligner deux lignes de C++, c'est facile (même si il le fait sans doute mal, il le fera). Trouver quelqu'un qui sait aligner deux lignes de Rust / Haskell / OCaml / ..., c'est bien plus dur.
Mais clairement, sur un projet neuf, où il n'y a pas autant de librairies métier à gérer et où les performances ne sont pas autant un problème, j'aimerais faire un autre outil.
Sinon il y a quand même un truc que j'aime en C++, c'est les "int" dans les templates. Cela permet de faire un tout petit peu de typage dépendant et ça c'est marrant ;)
[^] # Re: Donc pour résumer...
Posté par Guillaum (site web personnel) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 10.
Aller, j'en ajoute (C++ est mon outil de travail 8h par jour depuis plus de 10 ans) en me focalisant sur les problèmes qui m’embêtent vraiment au quotidien et pour lesquels il n'y a pas de solution simple. J'essaye de rester objectif ;)
std::unique_ptr. Cela force à mettre des constructeur par défaut complètement abscons à beaucoup d'endroits.Alors pourquoi C++ est-il mon outil de travail si ce langage est si mauvais ? Parce qu'en premier lieu, tous les langages du monde sont mauvais, en second lieu, c'est le seul à l'heure actuel qui m'apporte plusieurs choses :
a) Les performances, qui sont vraiment critiques dans mon métier.
b) Les librairies. Toutes les libraires utiles dans mon métier sont écrites en C++, sans interface C.
c) L'historique, l'outil actuel est écrit en C++ et on ne peut pas tout réécrire from scratch.
d) Les gens formés. Trouver quelqu'un qui sait aligner deux lignes de C++, c'est facile (même si il le fait sans doute mal, il le fera). Trouver quelqu'un qui sait aligner deux lignes de Rust / Haskell / OCaml / ..., c'est bien plus dur.
Mais clairement, sur un projet neuf, où il n'y a pas autant de librairies métier à gérer et où les performances ne sont pas autant un problème, j'aimerais faire un autre outil.
Sinon il y a quand même un truc que j'aime en C++, c'est les "int" dans les templates. Cela permet de faire un tout petit peu de typage dépendant et ça c'est marrant ;)