Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

0PARTAGES

2  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de saad.hessane
Membre confirmé https://www.developpez.com
Le 19/07/2010 à 16:15
Deux défaut :
  • Les gens qui enseignent/pratiquent le C++ comme du C
  • Les différentes implémentations des compilateurs ...
17  1 
Avatar de metagoto
Membre éclairé https://www.developpez.com
Le 19/07/2010 à 16:34
- les écarts et omissions des différents compilos par rapport au standard
- pas d'ABI standard
- preprocesseur trop limité/archaïque
- grammaire très complexe (difficile à parser pour les IDE etc)
9  1 
Avatar de Luc Hermitte
Expert éminent sénior https://www.developpez.com
Le 19/07/2010 à 17:14
Citation Envoyé par psychadelic Voir le message
C'est marrant, j'ai pas l'héritage multiple dans la liste..

Pourtant c'est une "fonctionnalité" qu'on évite avec soin dans "les autres nouveaux langages objet" : Java, C#...
Il est nécessaire à la prog par contrat native.
Et quand on voit la source (*) des problèmes avec l'héritage multiple, c'est limite l'héritage qu'il faudrait interdire....
De plus tous les "nouveaux" langages à objets ne l'évitent pas, cf ruby qui je trouve a un modèle plus propre que les langages auxquels tu pensais.

(*) La compréhension même du LSP -- qui n'a rien de propre au C++.

Accessoirement, l'article original est plus intéressant que le résumé fort trollesque qui initie ce fil.

Et +1 à confusion entre C++ et "truc qui ressemble à du C" qui gangrène la pratique, et l'enseignement.
8  0 
Avatar de gl
Rédacteur https://www.developpez.com
Le 21/07/2010 à 11:26
Citation Envoyé par pseudocode Voir le message
C'est justement parce qu'il n'y a pas de moyen d'être d'accord sur la sémantique des opérateurs à moins de faire une revue exhaustive du code source. A partir du moment où il est permis de redéfinir un opérateur, voir un mot clé du langage, il n'y a pas possibilité de présupposer de ce que fait une simple comparaison.

Pour moi, la première forme (.equal()) peut renvoyer true, false, 0, -1, "hello world", voir lever une exception, afficher du texte, ou faire un exit(). Bref tout ce que peut faire un appel de méthode.

Mais en fait, la deuxième aussi. Sauf que c'est moins visible au premier coup d'oeil. Et donc le risque est plus grand de faire l'impasse sur toutes ces possibilités, et de se contenter de croire que le "==" est un opérateur du langage qui compare deux valeurs et renvoie un booléen.
Mais ce n'est ni plus ni moins que le même problème que celui du choix des noms (de méthodes, variables).

Si tu tombes sur une méthode equal() tu t'attends à ce qu'elle fasse un test d'égalité. Si finalement elle fait tout à fait autre chose, tu vas être surpris et estimer (à juste titre à mon avis) que celui qui l'a faite est un imbécile.
C'est pareil pour la surcharge d'un opérateur, si l'opérateur surchargé n'a pas une sémantique logique et s'éloigne du fonctionnement des opérateurs de base c'est que le choix de cet opérateur n'était clairement pas bon, mais cela ne remet pas, à mon sens, en cause la surcharge des opérateurs.

Et à titre personnel, je trouve bien plus logique d'utiliser les opérateurs de comparaison pour faire une comparaison, l'opérateur d'affectation pour faire une affectation, etc. que d'appeler une fonction quelconque.
8  0 
Avatar de jbb2811
Membre régulier https://www.developpez.com
Le 19/07/2010 à 17:19
Je rajouterais :
- la portabilité toute relative.
- le dédain de la STL par les librairies graphiques ( qui chacune redéfinissent les types de bases, chaînes, listes, tableaux...)
- la complexité à intégrer des modules développés par des moyens différents

JB
6  0 
Avatar de pseudocode
Rédacteur https://www.developpez.com
Le 19/07/2010 à 17:20
Et pour vous, quel est le défaut le plus gênant du C++ ?
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, ...
7  4 
Avatar de
https://www.developpez.com
Le 19/07/2010 à 19:54
C'est marrant car je suis hyper d'accord avec les réserves sur l'unicode mais quand j'ai commencé ce job, l'unicode n'existait pas et l'évenementiel n'était q'un futur caprice d'éditeur d'os acharné sur sa concurrence. Du coup ces réserves me seraient jamais venues à l'idée même si C# évolue dans une autre galaxie, je reste un "vieux" qui lançait sa makefile en ligne de commande sur cross-compilateurs ..

Reste que la lignée des compilos C et descendants C++ a gardé une authenticité d'un autre age que vous percevez comme des défauts mais je ne peux pas m'empêcher de penser que faire une telle infidélité à Kernigahn et Ritchie serait dénaturé C++ et son papa unix

Ce ne serait plus du C et donc il faudrait presque changer son nom, déjà que C++ était implémenté sous forme de préprocesseur à l'origine...

En me mettant à votre place,

Est-ce que le pire défaut du C++ ne serait pas cette parentée avec K&R justement ?

Ça semble complètement dépassé alors que la syntaxe du C a été adoptée par une bonne douzaine de languages de premier plan...

A mon avis , C++ est arrivé un peu trop tôt dans la généalogie des langages objets. La volonté de préserver à tout crin la logique du C est son péché originel. (bibliothèque arborescente, éditeur de liens statique, ...)

Seulement voilà : ces deux languages sont restés monopolistiques dans les systèmes d'exploitation ... Changer C ou C++ comme vous le dites, c'est renoncer à compiler Windows avec !!!!!!
Big problem !
C'est comme scier sa branche ...

Changer C++ dans ce sens me semble simplement impossible avant des décennies.......................... à supposer qu'un fou décide d'écrire un nouvel OS dans un autre language ... Y-A-T-IL DES CANDIDATS ?
3  0 
Avatar de Luc Hermitte
Expert éminent sénior https://www.developpez.com
Le 20/07/2010 à 11:47
Citation Envoyé par divxdede  Voir le message
a- Surcharge d'opérateur : Au début c'est magique, on adore... mais on adore pour soit !!! quand on se reprends un code source où la surcharge d'opérateur à été utilisée à profusion, ca devient complétement illisible. Avec du recul, c'est un mécanisme à éviter en POO même si c'est tentant (c'est un peu le champ de la siréne...)

b- Pour moi, le pire dans tout ca, concerne le polymorphisme désactivé par défaut (faut déclarer explicitement les méthodes polymorphes), ce qui va à l'encontre même de la POO...

a- Parfois j'ai l'impression que les gens critiquent les vélos parce qu'ils ne sont pas adaptés aux escaliers et que du coup il faudrait toujours se balader à pieds.
Oui, il y a aura toujours des garnements qui utiliseront de travers ce qu'ont leur met à disposition. Reste que c'est bien plus agréable à utiliser que les interfaces SAXPYiennes des BLAS, ou même de ce que l'on trouvera en Java.

b- Bien au contraire. Je me permets de copier-coller de la prose que j'avais écrite pour un doc de qualité:

3.7.8. Les fonctions membres d'une classe ne seront pas déclarées virtuelles par défaut. Elles le seront uniquement si cette fonction correspond à un point de variation prévu lors de la conception de classe.

Une école tend à définir toutes les fonctions en virtuel : « mettons la fonction en virtuel, quelqu'un pourrait vouloir la supplanter ». Seulement...

Si une fonction ne correspond pas à un point de variation [Coplien1998] prévu lors de la conception, il reste peu probable que l'on puisse étendre le système simplement parce que la fonction était virtuelle. Bien souvent, rajouter correctement un point de variation non initialement prévu demande un refactoring non trivial du code, c'est-à-dire bien plus qu'ajouter un simple "virtual".

Bien sûr, plus les fonctions d'une classe respectent la règle Section 3.1.3, « Une fonction doit faire une chose, et doit le faire bien. Ainsi, le nombre de lignes d'instructions efficaces (générant du code exécutable) d'une fonction doit être limité à 50 lignes, soit environ un demi écran moderne. On évitera également l'abondance de niveaux d'imbrications. », plus il est simple d'introduire des points de variations à la volée. Seulement si toutes sont virtuelles, cela veut aussi dire que toutes ces fonctions membre (en nombre plus ou moins important) peuvent être supplantées. Les classes filles auraient alors une visibilité complète de la classe mère. De cette rupture d'encapsulation inter-générations, il devient alors vite complexe de savoir ce qui peut être supplanté, et sous quelles conditions (contraintes).

De plus, les hiérarchies polymorphes ayant naturellement une sémantique d'entité, définir virtuelle une quelconque fonction membre d'une classe à sémantique de valeur n'a aucun sens. C'est aussi pour cela qu'aucun conteneur de la bibliothèque standard ne dispose de fonction membre virtuelle (voir la règle Section 3.7.7, « Éviter de dériver de classes non prévues pour être des classes de base. »).

Enfin, virtual introduit un sur-coût lors d'un appel de fonction où il n'était pas nécessaire. De fait, pour des raisons d'optimisation, on évite également de payer inutilement pour un service dont on n'a pas besoin : à savoir un branchement conditionnel déterminé à l'exécution (NB: il n'y aucune différence de rapidité, voire de meilleures performances sont à attendre de virtual par rapport à des if en chaîne, un switch-case, des tables d'indirection, etc.).

Références
[Meyers2002], [Hejlsberg2003].

Un petit exemple qui illustre cela : les listes et les listes triées. Quelqu'un d'un peu naïf pourra croire qu'il suffit de dériver une classe liste pour définir une classe listetriée après avoir redéfini la fonction d'insertion pour insérer au bon endroit. Sauf que cela sabotera complètement le contrat de la liste.

Accessoirement, la liaison tardive n'est qu'un des aspects du polymorphisme (d'inclusion -- mine de rien, le C++ en supporte 3 autres). virtual n'est pas nécessaire pour utiliser en place de.
3  0 
Avatar de bacelar
Expert éminent sénior https://www.developpez.com
Le 20/07/2010 à 13:39
J'interviens juste pour faire quelques remarques :

Ne prenez pas le C/C++ pour les Dieux des langages.
Beaucoup de firmeware utilisent des langages adhoc, beaucoup de BIOS (celui des Mac notamment) utilisent du Forth, qui est bien plus adapté pour faire du code compact et performent que le C.
Le problème du Forth, c'est qu'il est spécialisé et donc avec très peu de fonctions.
A la fin, code natif ou code interprété, c’est du code machine, qui est un langage, qui est exécuté. Sans compter le microcode dans les CPU.

C/C++ sont des langages polyvalents qui ont servi au début dans les OS, doit leur omniprésence dans ce domaine (plus le C que le C++). Mais les OS ont généralement besoin d'être polyvalents, mais rarement les applications. Le développeur, lui, aime être polyvalent donc un dédain/peur des langages spécialisés.

Il ne faut pas non plus se leurrer, un avantage indéniable pour l'acceptance du C++ était sa proximité supposé avec le C.
Maintenant, cela joue en sa défaveur mais on ne peut pas tous avoir.

Le fait de la multitude d'intervenant dans la norme C++ peut expliquer bien des choses que je voudrais souligner par un exemple.

Bon nombre de personnes n'aime pas le diptyque .H/.CPP. D'autres trouve cela indispensables pour une bonne organisation.
Les deux ont raison et le fait qu'il y ai un nombre très important d'intervenant dans C++, interdit de compenser des lourdeurs par de l'outillage.

Si l'on prend des langages comme C# ou Java, avec les IDE VS et Eclipse, les outils de refactoring influences directement le langage.

La qualité d'un langage tient, maintenant que la puissance CPU des stations des développeurs est "considérables", énormément dans son "écosystème".

Le C++, par son ouverture, ne dispose pas actuellement d'un écosystème aussi efficace au niveau productivité. Quantitativement, grâce à Intellisence par exemple, mais aussi qualitativement, par les outils de tests automatiques et d'analyse de code.
"lint" contre "Code Analysis" : au moins 20 ans d'écart.

Je pense que le fait que le C++ reste un langage "Notepade-aware" bride énormément son évolution.
Les fichiers d’en-tête ont été conçus pour accélérer la compilation. N’oubliez pas que C a été conçu au début des années 70, sur des PDP-11 je crois.
Avec un IDE, qu’il y est un fichier d’en-tête ou pas ne devrait être qu’un détail qui n’influence pas le langage.
Java qui début publiquement en 1995 sur Pentium Pro n’a pas les même contraintes.
Le fait de définir des interfaces avec les .h n’est qu’un effet de bord, vertueux je l’admets, mais ne remplace par la définition de vrais interfaces. Un IDE peut facilement faire l’extraire l’API d’une classe de manière automatique (facile aujourd’hui mais pas en 1971)

En résumé, le langage n’est pas le problème, c’est sont écosystème hétérogène qui bride son évolution aux besoins des années 2010 et non aux besoins de 1971 (C) ou de 1985 (C++).
3  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 20/07/2010 à 14:13
Salut,

Je crois qu'il faut commencer par rendre à Cesar ce qui appartient à Cesar, ou plutôt, par ne rendre C++ responsable que de... ce dont il est responsable.

J'ai en effet lu sur la première page de nombreuses interventions qui semblaient rendre C++ responsables de ce que les gens en font, parmi lesquelles (à peu près dans l'ordre dans lequel elles sont apparues) :

  1. Les gens qui enseignent/pratiquent le C++ comme du C
  2. Les différentes implémentations des compilateurs ...
  3. J'en pointerais un beaucoup plus simple: l'illisibilité...
  4. Pas d'éditeur aussi puissant qu'on peut en trouver dans le monde Java par exemple
  5. les écarts et omissions des différents compilos par rapport au standard

Comprenons ce sont les utilisateurs et / ou les gens qui implémentent le compilateur les vrais responsables de ces travers:

1 -Si les gens pratiquent et enseignent C++ comme du C, c'est peut être en partie du à sa filiation historique avec C, mais c'est surtout du au fait que de trop nombreux enseignants / développeurs n'ont pas encore jugé utile de... se remettre en question...

2 et 5 - Le respect et le support très inégale de la norme n'est du... qu'aux développeurs de compilateur, dont certains étaient connus à une époque pour leur habitude de faire fi des normes.

Notez cependant que les choses évoluent dans le bon sens, car la plupart des fournisseurs de compilateur dont je parle ont changé leur fusil d'épaule, et tendent à faire en sorte de suivre la norme par défaut.

Notez que l'utilisateur a aussi sa part de responsabilités, dans le sens où C et C++ sont sans doute les seuls langages pour lesquels il continue à utiliser des compilateurs vieux de plus de dix ans...

3 - L'illisibilité du code : Il est vrai que C++ permet de rendre un code illisible, mais, encore une fois, c'est un choix du programmeur que de le faire.

On ne peut reprocher un code illisible... qu'au programmeur qui l'a écrit.

De plus, il est tout à fait possible d'écrire du code illisible dans n'importe quel langage

4 - L'absence d'éditeurs "aussi puissant que ce que l'on trouve en java" est beaucoup plus du au fait qu'on ne trouve personne pour les créer qu' au langage lui-même

Vous me direz sans doute que, si C++ ne laissait pas la porte ouverte à tous ces problèmes, ils (ces problèmes) n'existeraient pas.

Mais bon, le code de la route interdit aussi de rouler à plus de 120 ou 130 (selon le pays) sur l'autoroute, ce n'est pas pour cela que personne ne le fait
3  0