Discussion :

[Issam_Lahlali]

On se demande ce que font toutes ces clauses "Preconditions" et "Postconditions" dans la norme.

Encore une fois c'est pas du tout un problème du langage ou de la norme.

En fait lorsqu'on a un langage puissant comme c++ vu l'existence de concepts non existantes dans d'autres langages il faut être doublement vigilant avec la conception.

voici un cas que j'ai vu passer devant mes yeux plusieurs fois:

des classes sont implémentés , et on se rend compte qu'il ya un bug de conception qui fait que deux classes ne communiquent pas comme on veut, alors la solution simple est d'ajouter le mot clé friend sans refaire d'itération sur la conception.

et bien sur si les autres langages proposaient le concept Friend on aura les mêmes dérives.

Donc la puissance de C++ est a double tranchant , il faut être plus vigilant au niveau conception.

[loufoque]

Le truc avec la conception en C++, c'est qu'elle est quand même très différente de la conception dans les autres langages à objets.
Tout simplement parce qu'en C++ le paradigme objet n'est qu'un paradigme parmi tant d'autres, et bien souvent pas vraiment celui qui est recommandé pour résoudre un problème.

Tout comme concevoir du code Haskell à partir de données UML est une mauvaisée idée, concevoir du code C++ à partir de ce genre de données l'est aussi.
Pour concevoir du code vraiment de qualité dans un langage de programmation, il faut savoir faire fi de ces générateurs de code à la UML et se plonger dans l'univers associé au langage, à savoir comment est conçu sa bibliothèque standard, ses bibliothèques populaires, le travail similaire effectué, les ouvrages, la communauté etc., tout en gardant bien entendu un regard critique en comparant avec les univers d'autres langages.

[Issam_Lahlali]

Pour concevoir du code vraiment de qualité dans un langage de programmation, il faut savoir faire fi de ces générateurs de code à la UML et se plonger dans l'univers associé au langage, à savoir comment est conçu sa bibliothèque standard, ses bibliothèques populaires, le travail similaire effectué, les ouvrages, la communauté etc., tout en gardant bien entendu un regard critique en comparant avec les univers d'autres langages.

Tout a fait d'accord, le seul souci c'est que ça demande une expérience en c++ pour avoir une telle vision et ce profil peut bien guider les developpeurs dans leur demarche de conception par contre est ce que vous n'avez pas remarquer qu'en france tout le monde veut devenir Chef de projet dés qu'il commence comme développeur? et surtout le plutot possible et cette remarque est valable quelque soit le développeur (C++ ou autre)

rare ceux qui veulent être architectes ou concepteurs donc malheureusement on perd la compétence de ceux capable de bien orienter la conception et l'architecture, un chef de projet passe malheureusement plus de temps a gérer le planning et les ressources.

peut être je suis hors sujet mais j'essaye de faire l'inventaire de tout ce que j'ai rencontrer dans la réalité qui influencent sur la conception.

[teddyalbina]

Oui, c'est ce que je leur reproche. Je veux pouvoir avoir un minimum de sucre dans mon code, quand je fais mes bibliothèques, et je n'en ai pas, car les règles du langage supposent que l'aspartame est mieux pour tous (sauf les développeurs internes).

Et le sucre syntaxique de classe définie à moitié en C#, à moitié en .XAML ? D'ailleurs, tout XAML peut être vu comme un énorme sucre syntaxique, de la taille d'un iceberg, au dessus de C#.

Tu peux tout faire en C# pur, mais en pratique, WPF sans XAML du tout, je ne crois pas que ce soit courant...

Tu n'es pas obligé d'utiliser le sucre pour faire du linq . Des fois j'utilise le sucre quand je fais une requête très complexe car la synthaxe proche de sql éclaircie les choses pour le reste j'utilise les méthodes directement

Pour XAML faut pas confonfre XAML c'est une grammaire, derriere on fait du binding etc... mais sa ne donne pas du code GDI ce n'est pas un sucre.

Pour les classes partiel je ne les utilisent que pour les gui de toutes façon c'est conçu comme ça alors...

Sinon je ne les utilises jamais

[teddyalbina]

Tout a fait d'accord, le seul souci c'est que ça demande une expérience en c++ pour avoir une telle vision et ce profil peut bien guider les developpeurs dans leur demarche de conception par contre est ce que vous n'avez pas remarquer qu'en france tout le monde veut devenir Chef de projet dés qu'il commence comme développeur? et surtout le plutot possible et cette remarque est valable quelque soit le développeur (C++ ou autre)

rare ceux qui veulent être architectes ou concepteurs donc malheureusement on perd la compétence de ceux capable de bien orienter la conception et l'architecture, un chef de projet passe malheureusement plus de temps a gérer le planning et les ressources.

peut être je suis hors sujet mais j'essaye de faire l'inventaire de tout ce que j'ai rencontrer dans la réalité qui influencent sur la conception.

Je te rejoins la, j'utilsie UML etc. pour modélier l'application mais jamais je n'en utilise le code qui en général est mal foutut mais bon.

[Jean-Marc.Bourguet]

Donc la puissance de C++ est a double tranchant, il faut être plus vigilant au niveau conception.

Mais je ne vois pas comment tu passes le pas pour dire que la communauté C++ ne s'intéresse pas à la conception...

En passant, les discussions de conception sur les forums me laissent souvent songeur; le questionneur pose sa question dans des termes vagues et pour un contexte mal identifié et les répondeurs formulent des réponses définitives en fonction d'hypothèses non spécifiées. Si c'est ce genre de discussions qui te manque, leur absence est peut-être un signe de maturité. Un bonne conception est un compromis entre des contraintes techniques et non techniques.

[Issam_Lahlali]

Mais je ne vois pas comment tu passes le pas pour dire que la communauté C++ ne s'intéresse pas à la conception...

En passant, les discussions de conception sur les forums me laissent souvent songeur; le questionneur pose sa question dans des termes vagues et pour un contexte mal identifié et les répondeurs formulent des réponses définitives en fonction d'hypothèses non spécifiées. Si c'est ce genre de discussions qui te manque, leur absence est peut-être un signe de maturité. Un bonne conception est un compromis entre des contraintes techniques et non techniques.

Tout a fait d'accord qu'il faut être concret et si tu revois toute la discussion j'essaye a chaque fois de donner des exemples concrets que j'ai rencontrer dans ma vie professionnelle.

et le fait que la conception n'a pas sa vrai place dans le monde c++ c'est un fait , tu n'a qu'a regarder comment c'est fait la libraire la plus utilisée en C++ a savoir MFC ou son design et même son utilisation montre une negligence au niveau conception.

et pour rester dans le concret combien d'articles sur le WEB nous enseignent de ne jamais utiliser CDocument comme model pour le pattern MVC mais juste comme contrôleur, par contre a l'inverse toute la littérature autour de MFC encourage l'utilisation de CDocument comme model.

l'accumulation de détails comme ça font qu'en pratique on s'éloigne de la bonne conception.

peut être dans le monde idéal de livres et de normes tout a l'air nickel mais dans le monde réel c'est loin d'être le cas, il y a de plus en plus de dérive qui font que de jour en jour c++ devient de plus en plus compliqué.

et pour s'en rendre compte il suffit de voire les tendances actuels , on commence a ignorer c++ de plus en plus dans le monde d'entreprise.

[Luc Hermitte]

Ouais. L'amiente c'est pareil. Dans les années 60-70 on en mettait partout.

[Alp]

Tout a fait d'accord qu'il faut être concret et si tu revois toute la discussion j'essaye a chaque fois de donner des exemples concrets que j'ai rencontrer dans ma vie professionnelle.

et le fait que la conception n'a pas sa vrai place dans le monde c++ c'est un fait , tu n'a qu'a regarder comment c'est fait la libraire la plus utilisée en C++ a savoir MFC ou son design et même son utilisation montre une negligence au niveau conception.

et pour rester dans le concret combien d'articles sur le WEB nous enseignent de ne jamais utiliser CDocument comme model pour le pattern MVC mais juste comme contrôleur, par contre a l'inverse toute la littérature autour de MFC encourage l'utilisation de CDocument comme model.

l'accumulation de détails comme ça font qu'en pratique on s'éloigne de la bonne conception.

peut être dans le monde idéal de livres et de normes tout a l'air nickel mais dans le monde réel c'est loin d'être le cas, il y a de plus en plus de dérive qui font que de jour en jour c++ devient de plus en plus compliqué.

et pour s'en rendre compte il suffit de voire les tendances actuels , on commence a ignorer c++ de plus en plus dans le monde d'entreprise.

Depuis le début tu raisonnes par induction :
"Tiens, j'ai vu des gars qui font comme ça, alors forcément c'est que c'est comme ça partout".

Déjà, les MFC ne sont pas la bibliothèque la plus utilisée en C++. C'est la bibliothèque standard la plus utilisée

Ensuite, les MFC sont les Microsoft Foundation Classes, donc absolument pas standard. Là on peut accuser une minorité de programmeurs C++ (ceux qui ont conçu les MFC) de s'y être mal pris, si tu veux. Donc mettre tout le C++ derrière les MFC, c'est faux, absurde, impensable. Les MFC ne respectent pas l'esprit C++.

Mais les bibliothèques que nous conseillons aux membres aujourd'hui sont de bonnes bibliothèques, bien pensées, portables, etc (Boost, Qt, ASL, etc, cf la page bibliothèques C++).

Aujourd'hui, pour faire de l'IHM, du réseau, du multi-threading/parallèle, du xml, du traitement d'images, du jeu, etc, en C++, tu disposes de bibliothèques full C++, à fond dans l'esprit C++ moderne, portables, bien pensées (conception bien faite, quoi) et qui pour certaines sont presque au sommet de ce qui se fait de mieux au niveau techniques utilisées (je pense notamment à Vigra pour le traitement d'images qui utilise pas mal de métaprogrammation à l'intérieur) -- Boost étant LA référence à ce niveau-là.

Bref, tu es quelqu'un qui n'a pas mis à jour ses connaissances sur le C++ depuis quelques années. Suis l'actualité sur l'index C++ de Developpez, et tu verras que le C++ que tu décris n'est plus le C++ actuel. Le fait que bien d'autres personnes en entreprise soient dans la même situation, c'est un autre problème. Mais les vraies communautés font de leur mieux pour répandre les pratiques sûres, bonnes, reconnues et modernes utilisées de nos jours en C++.

Par exemple, MFC est à oublier. Qt est l'un des meilleurs choix pour faire de l'IHM en C++ (et même plus), en attendant qu'Adobe Adam&Eve soit plus facile à installer et soit plus documentée.

Bon je vais m'arrêter là, sinon j'en aurais pour des heures encore.

[Issam_Lahlali]

Bref, tu es quelqu'un qui n'a pas mis à jour ses connaissances sur le C++ depuis quelques années.

j'aime bien les discutions par accusation on se croient dans un local de police

Nier que MFC est très très répandu c'est un choix ou je ne vois pas comment te prouver le contraire.

Et juste pour te rassurer j'ai travailler pendant des années dans une grande boite internationale en france qui code majoritairement avec C++ et qui utilise la majorité des librairies que tu viens de citer.

et par rapport a ca justement tu ne t'est jamais poser la question d'homogénéité des librairies ou juste tu les utilisent comme tel sans se poser de questions, et pour etre terre a terre voila ce que je veux dire d'homogénéité:


en STL on a std::string mais en QT on a QString , imaginant que tu veux utiliser les 2 librairies , est ce normal qu'a chaque fois lorsque tu passe les paramètres d'une librairie a l'autre il faut que tu pense aux différences de types même si ça représente finalement une chaine de caractère.

d'ailleurs pour les chaines de caractères c'est une boucherie on a autant de types les représentant que de librairies.

et cette remarque peut s'appliquer a d'autres types comme File ou smart_ptr ou autre.

Mais comme d'habitude on va trouver une explication logique a ça et on passe a autre chose, mais n'oublions pas que ce genre de détail qui de plus en plus complique l'utilisation du langage.

et encore une fois je parle toujours dans le concret et si tu revois mes posts j'essaye toujours de donner un exemple réel et comme tu remarque j'évite les attaques personnelles pour ne pas entrer dans un piège qui ne sert a personne.

[Alp]

En fait, on n'arrive pas à tomber sur un point d'accord parce que tu considères que la communauté C++ est l'ensemble des boîtes qui l'utilise. Personnellement, je considère la communauté C++ comme l'ensemble des personnes qui utilisent le C++ et qui suivent son actualité, voire qui y participent, bref les gens "proches" du C++.

Parce que, effectivement, les boîtes qui utilisent C++, y'en a de différents types. Je suis dans une qui utilise Boost, Vigra, Qt, et pas mal de code fait maison mais à la façon moderne. Je connais des gens qui bossent dans des boîtes ou l'on fait du C++ comme il y a 10 ou 15 ans : pas de RAII, les templates ils ne connaissent/aiment pas, héritage à tout va même quand il ne faut pas, j'en passe et des meilleures.

Mais toujours est-il que je ne vois pas pourquoi la communauté C++ en particulier ignorerait la conception... J'ai bien envie de dire bien au contraire, vu que la possibilité nous est offerte d'utiliser plusieurs paradigmes, nous sommes conscients (plus que les langages mono-paradigme) des aspects essentiels de la bonne conception.

[Issam_Lahlali]

En fait, on n'arrive pas à tomber sur un point d'accord parce que tu considères que la communauté C++ est l'ensemble des boîtes qui l'utilise.

je pense que la on peut tomber d'accord

en aucun moment je parle de la communauté c++ comme les gens proches et motivés par le c++ ou peut être je me suis mal exprimé.

je cible surtout ce qui se fait en entreprise donc je parle de la communauté C++ en entreprise, c'est pour cela que je parle a chaque fois de décideurs parce que c'est eux qui prennent la décision au sein de l'entreprise d'oublier c++ parce que c'est compliqué.

mais si comme tu le mentionne il y a des profils compétents au sein des entreprises ils vont prendre les bonnes décisions de conception et le bon choix de librairies et peut être on aura moins le rejet de C++.

et revenant a mon expérience personnel dans un éditeur de logiciel de finance ou on a des centaines de clients partout dans le monde , la majorité d'entre eux nous imposaient a fournir des api C# au lieu de c++ et la raison c'est que c++ est compliqué et des fois lorsqu'on leur demandent comment ils ont implémenté leur application qui se base sur nos API je t'assure que c'est un massacre au niveau conception donc forcement pour eux le c++ devient compliqué.

tout l'objet de cette discussion fait parti d'un vécu, et bien sur je ne peux avoir un jugement que sur ce que j'ai déjà vu, peut être il yen a ceux qui ont une grande chance de travailler dans des boites ou il n y a pas ce type de problème.

[Jean-Marc.Bourguet]

en aucun moment je parle de la communauté c++ comme les gens proches et motivés par le c++

Il te reste à nous donner ta définition "d'expert".

(Sincèrement, j'ai du mal à savoir si tu trolles ou pas. Sortir les MFC comme un exemple de ce que la communauté C++ aime en manière de conception c'est très gros, quelque soit ta définition de communauté. La première fois que j'ai entendu parler des MFC, il y a bien des années, c'était en tant que catastrophe du point de vue conception -- sur le ton "ils ont fait toutes les erreurs à ne pas faire, à un moment où on savait déjà que c'étaient à éviter" --, dans le seul projet auquel j'ai participé qui a envisagé de les utiliser, l'équipe responsable a laisser tomber l'idée très rapidement et celà fait quatre ou cinq ans que je n'entends plus personne les utiliser pour autre chose que le support d'appli qu'on ne peut pas réécrire mais qu'on aimerait vraiment bien pouvoir).

[Issam_Lahlali]

Sortir les MFC comme un exemple de ce que la communauté C++ aime en manière de conception c'est très gros,

a quel moment j'ai dis ça?

lorsque j'ai parler de MFC c'était justement dans le cadre des développeurs qui s'en foutent de la conception mais non ceux qui croient que c'est la bonne manière de concevoir.

et c'est l'objet justement de la discussion cad de ceux qui ignorent la conception et prennent les mauvais choix.

et sincèrement si depuis le depart t'est convaincu que je troll je ne vois pas comment te prouver le contraire , le seul conseil que je peux te donner est essaye d'ignorer cette discussion pour ne pas perdre ton temps.

et si au moins un seul développeur sort convaincu de cette discussion qu'il faut donner plus d'importance a la conception surtout pour un langage comme C++ je serais très très satisfait

[JolyLoic]

Par rapport aux MFC, tout le monde est conscient que c'est une catastrophe en terme de design, même Microsoft (j'ai personnellement comme avis que c'était le premier programme en C++ fait par une équipe qui ne connaissait que le C). Mais elle continue à vivre et à avoir des adeptes à cause de la base installée phénoménales, et du fait qu'elle est livrée avec le compilateur Microsoft.

Une personne de chez Microsoft me disait un jour que si quelqu'un proposait un redesign des MFC qui les rende mieux foutus tout en restant compatible avec le code existant, ils sauteraient dessus à pieds joints.

Pour les multiples strings, je suis bien d'accord avec toi. std::string est arrivé trop tard, et incomplète, ce qui fait que des alternatives plus ou moins bien foutues prolifèrent. Mais je sais que Qt par exemple a fait pas mal d'efforts pour que les std::basic_string soient intégrées de manière relativement transparente avec QString.

Pour les pointeurs intelligents, c'est déjà un peu moins vrai. Boost a eu un effet unificateur très positif à mon sens. Et leur normalisation va accentuer ça. Et de toute façon, l'interface d'un pointeurs intelligents contient très peu de fonctions au nom libre, mais plus des opérateurs, ce qui fait que, à sémantique équivalente, remplacer un pointeur intelligent par un autre dans du code source peu se faire à coût assez réduit. Je l'ai fait récemment, et en un typedef + quelques dynamic_pointer_cast, c'était réglé.

Pour les choses autour du filesystem, ce sont AMA des types qui ont moins vocation à faire partie d'une interface (on passera plus souvent par une représentation textuelle), et donc avoir des systèmes disparates est probablement moins gênant.

D'un certain point de vue, Java et C#, c'est Disneyland. C'est joli, c'est propre, il y a un plan d'ensemble, un gamin de 5 ans n'y risque rien. C++, c'est plus la vraie vie, c'est le bordel, il y a des guerres de religion ou autres, des épidémies, de la misère, des ruines d'une autre époque, insalubres mais qui sont encore utilisées, mais aussi des richesses insoupçonnées, une liberté bénéfique. Et des gens compétents peuvent y bâtir une tour Eiffel, un viaduc de Millau, des jardins suspendus à Babylone.

[Luc Hermitte]

s/conception/professionnalisme ?

Je crois qu'il y a une confusion dans le fond du débat.
Le professionnalisme est tout un ensemble de choses qui sont critiques pour développer correctement. Cela inclut la conception, mais pas que.

Si tu trouves qu'il y a un manque côté C++, c'est vrai, mais les gens qui vont migrer ne seront pas plus professionnels ailleurs. Par contre, il n'est pas impossible qu'un langage d'assemblage de briques/prototypage leur suffise à remplir les objectifs qui leur ont été fixés par leur N+1/N+2.

J'avais lu un truc comme ça : avant qu'un langage ne devienne hype, des curieux à tendance expérimentés vont jouer avec et y font des choses sympas. La masse et autres décideurs sont emballés par la balle en argent qui vient d'être découverte, et plein de gens s'y ruent. Et les mauvaises pratiques naissent.

De plus il y a un truc qui cloche dans ton argumentation, tu viens reprocher que la communauté n'y connaisse rien en conception, et argumentes avec les 150 types de chaines (soit un problème d'interopérabilité/NIH entre des frameworks écrits par des concurrents). Le genre de truc qui en ce qui me concerne ne relève en rien de la conception. C'est un détail d'implémentation et rien d'autre. Une chaine reste une chaine. Que l'une soit standard ou que l'autre soit COW est un détail qui n'intervient jamais dans mes conceptions.

A ce sujet, d'ici 12 ans (le temps que les pratiques évoluent), QString pourra enfin disparaitre au profit d'une chaine standard non-COW qui ne coute rien à retourner par valeur. Du moins je l'espère. Quant à savoir comment on implémente une classe de chaine, c'est vaguement de la conception, mais elle n'intéresse pas l'assembleur de briques.

Pour en revenir aux MFC, si seule l'expérience personnelle comptait, j'en déduirais que plus personne ne les utilise depuis 10 ans, voire que tout le monde est passé à Linux ou Solaris...
Bien sûr que des trucs sont mal faits. Même dans les langages plus en vogue il y en a, non ? Java n'aurait pas autant de frameworks concurrents pour faire la même chose sinon, dont des frameworks graphiques.

PS: là où "tu" mets friend à l'arrache (cf la méthode de conception éponyme), d'autres mettent des accesseurs, et c'est au fond bien pire.

[Jean-Marc.Bourguet]

a quel moment j'ai dis ça?

Quand je critique quelque chose, j'essaie de prendre des exemples pertinents. Tu prends les MFC comme exemple, je suppose que tu les considères comme représentatives. Or pour moi, elles ne le sont pas, personne ne les considère comme étant un modèle.

lorsque j'ai parler de MFC c'était justement dans le cadre des développeurs qui s'en foutent de la conception

Il n'y a pas en Java ou en C# de développeurs qui se foutent de la conception ou qui sont surcontraints par leur management? Allez, j'accepte qu'il y en ait moins qui ont à vivre avec des choix faits il y a 20 ans...

[Issam_Lahlali]

Il n'y a pas en Java ou en C# de développeurs qui se foutent de la conception ou qui sont surcontraints par leur management? Allez, j'accepte qu'il y en ait moins qui ont à vivre avec des choix faits il y a 20 ans...

Bien sur le problème de conception est générale mais la différence est bien illustré par Joly Loic

D'un certain point de vue, Java et C#, c'est Disneyland. C'est joli, c'est propre, il y a un plan d'ensemble, un gamin de 5 ans n'y risque rien. C++, c'est plus la vraie vie, c'est le bordel, il y a des guerres de religion ou autres, des épidémies, de la misère, des ruines d'une autre époque, insalubres mais qui sont encore utilisées, mais aussi des richesses insoupçonnées, une liberté bénéfique. Et des gens compétents peuvent y bâtir une tour Eiffel, un viaduc de Millau, des jardins suspendus à Babylone.

Les autres développeurs sont bien cadrés par leur langage et framework mais pour C++ il faut être doublement vigilant a tout erreur de conception ou de choix de librairie ça peut couter très très cher.

[Issam_Lahlali]

tu viens reprocher que la communauté n'y connaisse rien en conception

je pense que j'aurais pas mal de copains C++ avec cette affirmation

c'est vrai que je critique la non valorisation de la conception pour lui donner ça vrai place mais pas a un stade de dire que la communauté n'y connaisse rien a la conception ,en tout cas je ne suis pas bien placé pour l'affirmer.


Et d'un autre coté je crois fortement a c++ et qui a de l'avenir devant lui et mon souhait et qu'il redevient numéro 1, mais pour cela il faut que la communauté critique tout ce qu'elle considére compliqué , finalement c'est eux les vrais utilisateurs et de ne pas laisser quelques boites ou équipes décident de l'avenir de C++ et de ces librairies.

Je suis contre la culpabilisation des développeurs pour leur expliquer que c'est de leur faute s'ils n'arrivent pas a utiliser simplement un langage ou une librairie, s'ils n'arrivent pas c'est qu'ils n'arrivent pas ,nous sommes pas tous des experts ou des gurus.

il faut aussi se mettre en tête qu'un mathématicien, un physicien ou un financier aimeraient bien aussi faire quelques développement et ils n'ont pas le temps a consacrer a un langage pour devenir expert.

donc critiquer , remettre en question l'existant et bien sur dans le but d'évolution est quelque chose qu'on a vraiment besoin en C++, et si des fois je donne l'impression de provoquer la communauté j'espère que ça soit compris dans le bon sens

[jabbounet]

je pense que j'aurais pas mal de copains C++ avec cette affirmation

C'est clair, tout dépend de la façon dont tu amène les chose, mais la démarche intelletuelle de conception n'est pas lié a un langage.

c'est vrai que je critique la non valorisation de la conception pour lui donner ça vrai place mais pas a un stade de dire que la communauté n'y connaisse rien a la conception ,en tout cas je ne suis pas bien placé pour l'affirmer.

peu etre pas assez de phase de conception dans ta boite.

Et d'un autre coté je crois fortement a c++ et qui a de l'avenir devant lui et mon souhait et qu'il redevient numéro 1, mais pour cela il faut que la communauté critique tout ce qu'elle considére compliqué , finalement c'est eux les vrais utilisateurs et de ne pas laisser quelques boites ou équipes décident de l'avenir de C++ et de ces librairies.

lisp, fortran et cobol sont encore utilisé, donc pourquoi pas C/C++

Je suis contre la culpabilisation des développeurs pour leur expliquer que c'est de leur faute s'ils n'arrivent pas a utiliser simplement un langage ou une librairie, s'ils n'arrivent pas c'est qu'ils n'arrivent pas ,nous sommes pas tous des experts ou des gurus.

il faut voir comment sont faites les formation aussi...

il faut aussi se mettre en tête qu'un mathématicien, un physicien ou un financier aimeraient bien aussi faire quelques développement et ils n'ont pas le temps a consacrer a un langage pour devenir expert.

matlab, java, VB, ... y'a plein de langage qui ne sont pas orienté developpeur (pur et dure), mais ce n'est pas le cas de c++

donc critiquer , remettre en question l'existant et bien sur dans le but d'évolution est quelque chose qu'on a vraiment besoin en C++, et si des fois je donne l'impression de provoquer la communauté j'espère que ça soit compris dans le bon sens

il faut toujours remettre en cause tout un tas de chose c'est qui permet de les faire avancer.

maintenant il ne faut pas non plus asséner de fausses vérités, en disant que les développeurs C++ sont des crétins et ne font pas de conception.

il vaudrait mieux apporter des proposition pour faire avancer les choses.