Discussion :

[Idelways]

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é


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

[stardeath]

ce qui me gêne le plus dans le c++, je l'ai souligné dans un autre topic, c'est le manque de cohérence entre toutes les briques;

du genre la nomenclature comme dans setw, setprecision, des fois en abrégé, des fois non, difficile de comprendre pourquoi mais ce n'est le plus dramatique.

un autre que je trouve plus problématique s'admire sur la signature du main standard : int main(int argc, char **argv) et ses dérivés avec le char* argv[], on a une bibliothèque standard avec quand même pas mal de choses MAIS pour l'entrée d'un programme on régresse du c++ vers le c; pour rester dans le c++ quelque chose du style de int main(vector<string> args) aurait été plus approprié selon moi.

[saad.hessane]

Deux défaut :

• Les gens qui enseignent/pratiquent le C++ comme du C
• Les différentes implémentations des compilateurs ...

[Oussapik]

• Le manque de réflexivité
• Les messages d'erreurs parfois trop verbeux, on obtient pas l'information que l'on souhaite rapidement je trouve
• La bibliothèque standard trop pauvre
• Sur une note plus légère : ce qui me gêne c'est qu'il ne soit pas plus utilisé
  
  
  

[Neko]

J'en pointerais un beaucoup plus simple: l'illisibilité...

[Jbx 2.0b]

Pas d'éditeur aussi puissant qu'on peut en trouver dans le monde Java par exemple, donc on se retrouve à faire énormément de copier-coller et à retaper beaucoup de chose ( déjà rien que les doublons .h/.cpp, limite ça donne parfois envie de faire que de l'inline...).

[metagoto]

- 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)

[Invité]

Pour :
-Rapidité d'exécution
-interface avec l'os/hardware sans intermédiaire permettant de bypasser tous les automatismes
-Capacité à tout gérer de multiples manières
-Possibilités d'optimisation hallucinantes
-Possibilité de faire du C (vitesse, types natifs, portabilité)

Contre :
-Redondance des déclarations
-Long à programmer, à débugger
-Risque de crash système
-Lisibilité aléatoire (dépendant de tierces parties inégales)
-Syntaxe objet ébouriffante, compliquée
-Héritage multiple, surcharge opérateurs peuvent rendre un code vraiment énigmatique
-> Record du code tordu partagé avec les expressions régulières kilométrique de perl !

[vg-matrix]

Deux défaut :

• Les gens qui enseignent/pratiquent le C++ comme du C
• Les différentes implémentations des compilateurs ...

Ce sont des défauts qui me gênent énormément !

[Luc Hermitte]

* Les gens qui enseignent/pratiquent le C++ comme du C
* Les différentes implémentations des compilateurs ...

Autant je suis on ne peut plus d'accord sur le premier, autant sur le second, ce n'est pas un véritable problème.
Les problèmes de compatibilité des compilos surgissent surtout quand on commence à faire de la voltige à coup de templates. Et du coup ... on se retrouve à écrire à la place le même genre de code que celui que l'on aurait écrit avec les autres langages de la même famille. (non parce que ... les extérieurs qui nous regardent râler, ne percuteront jamais que c'est relativement à des fonctionnalités dont ils ne peuvent même pas rêver avec leur langage mainstream)

Un problème connexe, mais plus ennuyeux à mon gout : l'inertie relative aux montées de versions. Dans nos processus industriels, on ne peut pas monter de version quand cela nous chante et comme cela nous chante. Du coup on se retrouve vite bloqué avec des outils (compilos, libs, OS, cartes graphiques) désuets et limités quand on les compare à l'état de l'art. Mais cela n'est pas propre au C++. C'est valable avec les autres langages qui évoluent (et avec les autres fameworks également).

[raphamil]

un autre que je trouve plus problématique s'admire sur la signature du main standard : int main(int argc, char **argv) et ses dérivés avec le char* argv[], on a une bibliothèque standard avec quand même pas mal de choses MAIS pour l'entrée d'un programme on régresse du c++ vers le c; pour rester dans le c++ quelque chose du style de int main(vector<string> args) aurait été plus approprié selon moi.

Code :

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

std::vector<std::string> args(argv, argv + argc);

[Invité]

Oui, effectivement, d'ailleurs, pourquoi continuer à faire simple alors qu'on pourrait faire compliqué?
Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramètres? Moi, ça fait bien une vingtaine d'années que je ne travaille plus qu'avec des fenêtres
Donc, mon avis, laissez le C++ comme il est. Il y une quantité d'autres langages et pour tous les goûts. Au moins, celui-là, il a fait ses preuves.

[hiura]

Oui, effectivement, d'ailleurs, pourquoi continuer à faire simple alors qu'on pourrait faire compliqué?
Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramètres? Moi, ça fait bien une vingtaine d'années que je ne travaille plus qu'avec des fenêtres
Donc, mon avis, laissez le C++ comme il est. Il y une quantité d'autres langages et pour tous les goûts. Au moins, celui-là, il a fait ses preuves.

ça m'est arrivé il y a pas si longtemps que ça. Du coup un petit coup de boost et c'est goal.

[Klaim]

Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramètres? Moi, ça fait bien une vingtaine d'années que je ne travaille plus qu'avec des fenêtres

C'est orthogonal : quasiment tous les jeux vidéos sur PC/windows que je fais (donc fenetrés) ont des paramettres d'execution.

C'est un peu naif de supposer que ce n'est pas utile parceque toi tu n'en as plus besoin. Même la plupart des applications windows ont des paramètres, c'est juste que toi tu n'as jamais eu a les utiliser.
Ne serait-ce que les compilateurs. Et les solutions de control de source. (les gui qui vont avec sont construits par dessus - si ces solutions n'étaient pas en ligne de commande de base, ça aurait compliqué les choses)
Et je te parle même pas des applications sous unix-like.

[hegros]

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

1/ Pas d'accord sur le temps de compilation et d'accord avec la gestion des dépendances. D'une part parce que bien que certains programment nécessitent près de 24H pour compiler (KDE ? Gnome ? Seven ?) cela me semble normal et il serait difficile de faire mieux avec un gain important avec autre chose. Et d'autre part, la gestion des dépendances je la trouve lourde probablement à cause du manque d'outil de fichiers qu'il faut trimballer dû au mode un fichier de déclaration et un fichier d'implémentation.

2/D'accord, l'exemple le plus frappant est sur la couche UI et accès aux données (SGBD par exemple, pas un simple fichier texte) il n'y a toujours rien de standardisé à ce que je sache.

3/Plutôt d'accord, d'ailleurs je me demande si le c++ est un langage à typage fort ou qu'il n'existerait justement pas un niveau typage très fort lorsqu'il est possible de faire de la réflexivité, de l'inférence ou autre chose de plus avancé concernant la gestion des types de données (comme la sérialisation/désérialisation de type en xml par exemple)

4/Plutôt d'accord, n'étant pas un praticien assidu en C++ pour les rares occasions où j'ai utilisé ou repris des templates les messages d'erreurs ne sont pas forcément explicite. J'aurai tendance à vouloir les isoler dans un projet séparemment avec en sortie un composant comme une lib ou une dll rien que pour isoler les messages erreurs

5/Pas d'accord. Par rapport à ce qui existe autour comme langage le c++ doit resté dans la moyenne. Les moulinettes maisons pour l'internationalisation marche assez bien aussi.

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

1/Cela est un peu gênant
2/Cela n'est pas gênant
3/Pour l'internationalisation oui cela pourrait être gênant
4/Cela n'est pas gênant plus que cela.
5/Cela ne me gêne pas ce sont des composants très riche de ce que l'on peux attendre d'un framework

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

Un aspect mythique et mystique avec le C

Ensuite 1/une bibliothèque standard trop réduite 2/Une utilisation abusive ou centrale du pré-processeur 3/La séparation entre fichier d'interface et d'implémentation 4/ Un manque dans la gestion des types 5/un manque de sécurité exécution et mémoire

[Invité]

1/une bibliothèque standard trop réduite 2/Une utilisation abusive ou centrale du pré-processeur 3/La séparation entre fichier d'interface et d'implémentation 4/ Un manque dans la gestion des types 5/un manque de sécurité exécution et mémoire

le preprocesseur était un enfer sous MFC
Pourtant sous audacity , le préprocesseur est minimal

Donc à ce stade plus concret , si on ne définit pas un ensemble de projets open-source de référence, les arguments vont de oui à non sans prévenir !

J'ai codeBlocks et visualStudio installés.
Y-a-til un projet qu'on peut downloader pour illustrer ?

[hegros]

le preprocesseur était un enfer sous MFC
Pourtant sous audacity , le préprocesseur est minimal

Donc à ce stade plus concret , si on ne définit pas un ensemble de projets open-source de référence, les arguments vont de oui à non sans prévenir !

J'ai codeBlocks et visualStudio installés.
Y-a-til un projet qu'on peut downloader pour illustrer ?

Quel critères et quelle valuation à chacun pour mesurer la non-qualité du pré processeur ? C'était un enfer sous quel aspect ?

Ma remarque sur le pré-processeur c'est plutôt parce qu'il me semble d'une part que les templates l'utilisent tout le temps et d'autres part que la stl soit fondée sur les templates. C'est là plus un défaut d'architecture de bibliothèque qu'un défaut de performances.

Il faut des critères de référence avant de choisir des projets à comparer pourquoi ne pas prendre un arbre qualimètrique ISO c'est plutôt un échange sur les +/- du langage il doit exister quelques sources de comparaison sur le pré-processeur par langage ou par environnement de développement

[Invité]

Quel critères et quelle valuation à chacun pour mesurer la non-qualité du pré processeur ? C'était un enfer sous quel aspect ?

Ma remarque sur le pré-processeur c'est plutôt parce qu'il me semble d'une part que les templates l'utilisent tout le temps et d'autres part que la stl soit fondée sur les templates. C'est là plus un défaut d'architecture de bibliothèque qu'un défaut de performances.

Il faut des critères de référence avant de choisir des projets à comparer pourquoi ne pas prendre un arbre qualimètrique ISO c'est plutôt un échange sur les +/- du langage il doit exister quelques sources de comparaison sur le pré-processeur par langage ou par environnement de développement

MFC 6 décrivait les controles de forms dans des constantes. L'ancien activeX nécessitait un clsID, les propriétés de controles et les events stockés dans un .hpp précompilé. Celui-ci devenait énorme et instable (plusieurs dizaines de mb)

ok , une urgence en C# qui vient de tomber , je vais me raréfier sur les vieux langages mystiques (15 ans de boulot pour demain matin ) bonne chance

[atttchoum]

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

d'abord une bibliothèque standard vraiment trop réduite mais surtout une documentation tout simplement misérable pour une librairie qui sera utilisé par tout les développeur c++ a un moment ou à un autre.

sinon l'ajout de librairies extérieurs est parfois vraiment complexe.