Quel est pour vous le défaut le plus gênant du C++ ?
Un développeur chevronné fait la liste des faiblesses de son langage préféré

Le , par Idelways, Expert éminent sénior
Les critiques qui mettent en relief les défauts des langages de programmations viennent en général de la part des développeurs qui utilisent des technologies autres, voir concurrentes.

C'est pour cette raison que la critique qu'on vous propose pour ce débat nous semble intéressante, elle est signée du pseudo « razvanpetru » derrière lequel se cache un développeur C++ aux 10 années d'expérience.

L'article présente les défauts en deux parties. Parmi ceux qui gênent l'auteur, on trouve:

Le temps de compilation et la gestion des dépendances
La bibliothèque standard, qu'il juge réduite.
Le manque de réflexivité et la déduction des types
Les messages d'erreurs des templates
Le support de l'internationalisation sur la bibliothèque standard

Parmi les défauts souvent pointés du doigt et qui ne le gênent pas, il cite :

La gestion et la corruption de la mémoire
La gestion du multitâche
Le support des chaines de caractères
Les exceptions
STL, Boost et les templates en général

Mais que l'on ne s'y trompe pas. Pour « razvanpetru », il s'agit juste du prix à payer, pas de défauts qui décrédibiliseraient le C++.

Car comme dit le proverbe : « personne n'est parfait ».

Et pour vous, quel est le défaut le plus gênant du C++ ?

Source : lire l'article: What's wrong with C++

Lire aussi :

Le moc (meta-object compiler) a-t-il toujours une raison d'exister, maintenant que les compilateurs ont évolué ?
Microsoft découvre une faille dans MFC qui pourrait aboutir à des dépassements de tampon
Microsoft Visual C++ 2010 Express : Téléchargement, installation et configuration par 3DArchi

Les rubriques (actu, forums, tutos) de Développez :

C++
Qt
Langages

En collaboration avec Gordon Fowler


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 01/08/2010 à 13:51
Vu qu'il y a une bibliothèque de boost consacrée au sujet, je suppose que oui.

Sinon personellement je préfère ne pas drésser de liste parceque je ne sais pas encore clairement a quel point la nouvelle norme simplifie les choses. Cela dit, la standardisation d'un système de module (entre autre pour accélérer les compilations) et le problème du temps trop long pour implémenter le standard seraient dans le haut de ma liste des problèmes.
J'ajouterais aussi l'absence des Concepts mais bon c'est un sujet un peu difficile a discuter actuellement, tant qu'il n'y aura pas une nouvelle tentative d'implémentation.
Avatar de Florian Goo Florian Goo - Membre éclairé https://www.developpez.com
le 01/08/2010 à 23:19
Citation Envoyé par Pierre Dolez  Voir le message
Réponse à Florian.
Bien sûr qu'on écrit des programmes en ligne de commande. Ma question, à propos de la dernière fois que c'est arrivé, j'aurais pu la poser de cette façon : Quel pourcentage de lignes de code cela représente-t-il ? Traduction : est-ce un défaut du C++ pour que cela vaille le coup d'en parler ici?
Personnellement, j'adore la technique qui consiste à trouver une objection à un interlocuteur pour être sûr de pouvoir éviter d'aborder le sujet principal.

Ah non, y'a méprise. Pas de tentative de manipulation de ma part, je me suis juste laissé emporté par le hors-sujet.

Pour moi, la raison d'existence du main C-style est surtout historique, la STL était apparue plus tard dans l'évolution du C++.
Autrement je ne trouve pas que ce soit un énorme problème. Au contraire, c'est même mieux comme ça : pas de création d'objets donc pas d'overhead si ce n'est pas désiré. Et si on le souhaite, une petite ligne de code suffit à créer un vector de strings.
C'est dans l'esprit du C++ : on ne paie pas pour ce qu'on n'utilise pas et on peut redescendre aussi bas niveau qu'on en a envie/besoin.
Avatar de davcha davcha - Membre expérimenté https://www.developpez.com
le 02/08/2010 à 10:56
A noter que strnlen existe et a pour principale utilité de produire un code sûr, comme toutes les fonctions strn*.

Sinon, y'a que moi qui trouve que l'un des grands défauts du C++ est d'être semblable aux navigateurs web il y a quelques années ?
D'ailleurs, la discussion sur les strings vs tableaux de byte en témoigne : c'est un véritable bourbier où la sémantique est totalement maltraitée, battue, voire même ignorée.

Sérieusement, qui n'a jamais connu un gamin sorti d'école qui se prend pour un programmeur super-cool super-balaise, tout en produisant du code C/C++ (surtout C++) illisible ?

Pour moi, c'est ça LE gros défaut de C++ : c'est un langage qui a le cul entre deux chaises. Proche de la machine, mais abstrait quand même...
Faut savoir ce qu'on veut. Soit on manipule des concepts, soit on manipule des bits. Mais on mélange pas tout sans arrêt, sinon, bonjour la prise de tête.
Avatar de ac_wingless ac_wingless - Membre confirmé https://www.developpez.com
le 02/08/2010 à 11:23
Les défauts qui me (je reconnais le biais induit par mon domaine de travail, l'embarqué industriel) gênent le plus sont, dans l'ordre:

1 - la difficulté de compilation du langage, qui a pour conséquences:
1a) les petites différences entre comportements des compilateurs, d'où l'impossibilité de généraliser dans des grands projets les techniques avancées du C++ ou de Boost
1b) le manque de réactivité/qualité des outils IDE de traitement du code (exploration de classe, refactoring, etc.)
1c) les temps de compilation

2 - la coexistence des chaines destinées aux humains (Unicode) et aux API (char *) n'est pas bien gérée par la bibliothèque standard. On y arrive, mais c'est loin d'être aussi propre que dans d'autres environnements.

3 - les exceptions ne sont pas acceptés dans les projets industriels embarqués, et il faut admettre que c'est pour de bonnes raisons. Il faut vraiment que le standard explore d'autres possibilités. Malheureusement il faut aussi reconnaitre que les solutions industrielles alternatives sont très loin d'être unifiées.

4 - la méta-programmation trop complexe. Ce sont des béquilles indispensables pour boucher les trous du standard et les retards par rapport aux langages modernes. Mais outre ce que j'ai évoqué en 1a, j'ai constaté un manque de productivité net pour les programmeurs non-experts lorsqu'ils découvrent ces techniques. Je dois me battre sur les check-ins de certains pour interdire la recherche de l'élégance pour l'élégance, qui est parfois bénéfique dans la plupart des portions de code mais PAS dans la méta-programmation complexe.

Les faux défauts pour moi:
1 - le mauvais diagnostic des erreurs de méta programmation. C'est plus rigolo que gênant. Les stagiaires se la pètent à celui qui fera la plus grosse, mais dans la vraie vie ce n'est pas une source perceptible de perte de temps.

2 - les erreurs de pointeurs. Ça fait des années que nous n'avons pas eu de retour client sur ce genre de bug. Et pourtant, nous travaillons dans l'embarqué, on est loin d'avoir les Go de matelas des applications PC.

3 - la bibliothèque standard réduite ne gêne pas dans l'embarqué.
Avatar de gl gl - Rédacteur https://www.developpez.com
le 02/08/2010 à 18:36
Citation Envoyé par davcha  Voir le message
A noter que strnlen existe et a pour principale utilité de produire un code sûr, comme toutes les fonctions strn*.

Ce n'est pas du C++ standard (ni du C ou Posix) mais une extension GNU.

Citation Envoyé par davcha  Voir le message
Pour moi, c'est ça LE gros défaut de C++ : c'est un langage qui a le cul entre deux chaises. Proche de la machine, mais abstrait quand même...
Faut savoir ce qu'on veut. Soit on manipule des concepts, soit on manipule des bits. Mais on mélange pas tout sans arrêt, sinon, bonjour la prise de tête.

Et pourtant, cette caractéristique du C++ (pouvoir choisir le niveau d'abstraction utilisé ou mixer les niveaux d'abstraction) est assez souvent vu plutôt comme un avantage que comme un inconvénient.

Citation Envoyé par ac_wingless  Voir le message
Ce sont des béquilles indispensables pour boucher les trous du standard et les retards par rapport aux langages modernes.

A quoi fais-tu allusion ici ?
Avatar de davcha davcha - Membre expérimenté https://www.developpez.com
le 02/08/2010 à 21:28
Citation Envoyé par gl  Voir le message
Et pourtant, cette caractéristique du C++ (pouvoir choisir le niveau d'abstraction utilisé ou mixer les niveaux d'abstraction) est assez souvent vu plutôt comme un avantage que comme un inconvénient.

En temps normal, je dirais que c'est un avantage, en effet. Mais dans le cas présent... Trop de mauvais devs, sûrement.
Avatar de ®om ®om - Membre expert https://www.developpez.com
le 02/08/2010 à 21:47
Le plus gênant dans le C++, c'est qu'il soit utilisé par les terroristes

http://www.numerama.com/magazine/163...mmation-c.html
http://www.numerama.com/magazine/163...-et-signe.html

Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 02/08/2010 à 21:53
Je vois aussi cela comme un avantage mais effectivement coté éducation/adoption des dévelopeurs, ça aide pas. La plupart des développeurs ont tendance à penser qu'ils agissent quasimment toujours à au niveau sauf si le besoin d'en fait ressentir. Seulement on leur apprend souvent le C with classes qui est encore loin du C++ "moderne". Enfin c'est une discussion qu'on a déjà eu dans le coin.

C'est assez difficile de faire comprendre a quelqu'un que ce n'est pas parcequ'une feature de language existe qu'elle est là pour être utilisé de manière systématique. Du coup expliquer que l'orienté objet n'est qu'une petite partie de la solution a un problème est loin d'être une partie de plaisir.

Il me semble que Stroustrup a dit que son plus grand regret était qu'il n'y a pas vraiment de communauté centrale autour de C++ et c'est vrai : la connaissance du language est sacrément diluée sur le net, même si ça tend globalement a aller vers le correcte. Je me souviens avoir appris les bases du C with classes sur des tutoriaux sur le net et aujourd'hui je déconseil fortement cette aproche. Les livres sont souvent bien mieux.

Tout ça pour dire que le problème d'education est en grande partie responsable de la vision négative d'avoir un language qui permet d'ecrire du code "à tous les niveaux"...
Si on se contente à un moment donné du niveau requis pour le problème immédiat à résoudre, il n'y a aucun souci avec ça. On a même l'avantage de ne pas avoir a changer de langage.
Avatar de alexis b alexis b - Membre à l'essai https://www.developpez.com
le 03/08/2010 à 17:32
Citation Envoyé par davcha  Voir le message
Pour moi, c'est ça LE gros défaut de C++ : c'est un langage qui a le cul entre deux chaises. Proche de la machine, mais abstrait quand même...
Faut savoir ce qu'on veut. Soit on manipule des concepts, soit on manipule des bits.

Je dirais que c'est un langage un peu schizophrène (mais vous avez votre propre façon de dire les choses ^^).

C'est un langage qui a tous les avantages du C, plus les avantages qui lui sont propres . Finalement, que demander de plus ?

Citation Envoyé par Klaim  Voir le message
Du coup expliquer que l'orienté objet n'est qu'une petite partie de la solution a un problème est loin d'être une partie de plaisir.

Parce que c'est faux tout simplement, la programmation orientée objet, même en C++ (qui permet de faire des programmes optimisés), est un élément assez omni-présent (théoriquement).
Avatar de CAMIC CAMIC - Membre régulier https://www.developpez.com
le 16/08/2010 à 9:39
Citation Envoyé par pseudocode  Voir le message
Le fait qu'on est jamais sûr de ce que fait une ligne de code... merci les #define, la surcharge d'opérateur, les transtypages implicites, ...

Selon le créateur du C++, Bjarne Stroustrup, le #define ne devrait servir que pour des options pour le préprocesseur, donc pas de macro mais des inlines.

Avec Visual studio 2005 et plus pas de problème pour voir le code qui est actif et non actif entre des #ifdef, #else et #endif.
Avatar de koala01 koala01 - Expert éminent sénior https://www.developpez.com
le 16/08/2010 à 13:22
Citation Envoyé par alexis b  Voir le message
JParce que c'est faux tout simplement, la programmation orientée objet, même en C++ (qui permet de faire des programmes optimisés), est un élément assez omni-présent (théoriquement).

Tu ne semble pas encore avoir assez manipulé la STL ou boost, pour avoir une telle réaction.

Dans les deux cas que je cite, on a affaire bien plus souvent à une approche générique qu'à une approche OO, même si l'orienté objet n'est souvent pas très loin.

De plus, c'est un argument que l'on a très difficile à faire passer auprès des javaistes ou des C#istes, même si l'orienté objet présente de très sérieux avantages, il ne faut pas en oublier les limites.

L'approche purement séquentielle, basée sur des fonctions libres permet dans bien des cas au développeur d'écrire un code moins verbeux mais tout aussi compréhensible.

L'approche générique quant à elle permet de créer des hiérarchies de classe bien moins complexes et donc... beaucoup plus flexibles en évitant d'introduire dans une hiérarchie des branches entières qui n'auraient sans doute rien à y faire.

Il ne s'agit pas de remettre en cause les bienfaits de l'orienté objet, comprenons nous bien, il s'agit simplement de faire prendre conscience que l'orienté objet n'est pas forcément la panacée pour laquelle on essaye de le faire passer.

De tous temps, il s'est trouvé des charlatans pour essayer de nous vendre des remèdes prétendant tout soigner, du simple rhume au cancer, en passant par la goutte ou les morpions, et soit-disant totalement exempts d'effets secondaires mais tous en avaient effectivement, et très peu étaient réellement efficaces.

L'orienté objet apporte certes un grand nombre de solutions à certains problème, mais, comme tout remède, il faut être conscient des effets secondaires qu'il entraine.

Les autres paradigmes permettent d'atténuer ces effets secondaires lorsqu'ils sont utilisés à bon escient, et c'est de cela que le C++istes essayent de faire prendre conscience aux autres
Offres d'emploi IT
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil