Pourquoi la communauté C++ s'intéresse plus à la technique et ignore la conception?

Il y a tellement de chose a éviter en c++ que de pratiques a conseiller, finalement il faut apprendre aussi bien les anti pattern que les design pattern et ça devient lourd.

malheureusement les experts n'ont pas forcement le temps de passer leur expertise d'une part et d'autre part ils se convertissent a faire autre chose que le développement.


on a beau a dire aux développeurs de ne pas faire les choses qu'ils ont appris a l'école , tôt ou tard on aura des débordements, donc il faut que l'environnement dans lequel il travaille l'interdit a faire ce qu'on ne veut pas faire pour un projet.

a mon avis il faut chercher aussi une solution coté compilateur, pour avoir un fichier de configuration dans le but de creer un sandbox pour éviter les dérapages a cause de l'utilisation classique.

par exemple pour dotnet ils ont commencer a explorer cette approche avec les projects templates pour créer un sandbox et encadrer les développeurs.

alors ma question est: a quel point les compilateurs C++ sont custumizables, dans le but par exemple d'ajouter des warnings personnalisés au cas d'utilisation de char* ou de pointeur non intelligent?

a mon avis ça sera bien que chaque responsable de projet puisse configurer l'environnement pour éviter au moins les problèmes les plus connus.

Citation:

---

Envoyé par Issam_Lahlali

alors ma question est: a quel point les compilateurs C++ sont custumizables, dans le but par exemple d'ajouter des warnings personnalisés au cas d'utilisation de char* ou de pointeur non intelligent?

---

Les compilateurs? Ce n'est pas trop leur boulot. Il y a des outils comme QAC++ pour cela.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Les compilateurs? Ce n'est pas trop leur boulot. Il y a des outils comme QAC++ pour cela.

---

avec les outils on revient au même probléme, c'est a dire que le code a déjà compiler c'est qu'après qu'on passe l'outil mais malheureusement ce qui est fait et fait.

le but est que ça compile même pas, si l'outil s'intègre bien dans l'environnement ou dés la compilation on sort des erreurs c'est très bien, sinon on tombera dans le même piège, et vu que l'audit avec ces outils n'est pas exécuté chaque jour on aura le même résultat.

par exemple imaginant que je ne veux pas de variables globales ni de fonctions globales dans le code, je configure le compilateur pour qu'il n'accepte pas une telle pratique.

finalement c'est comme si j'ai un nouveau langage qui réduit les possibilités en dépend de la façon avec laquelle je veux bosser.

a mon avis il faut un sandbox quelque part pas un outil juste pour assister mais pour interdire.

fcharton > Non plus. J'ai déjà eu a bosser avec un dévelopeur C qui bossait depuis 10 ans sur les mêmes types d'applications, toujours a réécrire le même code a chaque fois (copier, coller, modifier). Il disait ne pas comprendre comment faire de la P.O.O et ne voulait tout simplement pas apprendre de nouvelles choses vu que ce n'était pas du tout nécessaire pour la boite.

L'experience, a mon sens, ça ne s'aquiert qu'avec la variétée des expériences, quel que soit l'age ou le temps passé. (ce qui fait qu'on comprends plus vite quand on s'attaque a des tas de petits projets dans différents domaines)

Issam_Lahlali> Il va falloir que tu précises ce qu'est l'elitisme pour toi car je ne vois pas ce qu'il il y a d'elitiste dans le fait qu'un débutant puisse faire une grosse application qui marche globalement bien juste en ne connaissant que 10% du language.
Pour les autres choses relativent à la maintenance du code, effectivement c'est important mais les notions nécessaires dans ces domaines ne sont propres a aucun language et ne sont aquise qu'avec de l'expérience. Donc ça n'a pas de rapport direct avec le C++.

En revanche, la couche gestion de mémoire, effectivement ça c'est ce qui rebutte pas mal de monde.

Citation:

---

Envoyé par Issam_Lahlali

avec les outils on revient au même probléme, c'est a dire que le code a déjà compiler c'est qu'après qu'on passe l'outil mais malheureusement ce qui est fait et fait.

---

Pas forcément. Il existe de nombreux outils qui travaillent directement sur le code source.

Citation:

---

Envoyé par Issam_Lahlali

a mon avis il faut un sandbox quelque part pas un outil juste pour assister mais pour interdire.

---

Quel probleme y a-t'il a faire tourner un outil QAC++ periodiquement comme on fait avec les tests?

Citation:

---

Envoyé par Klaim

Issam_Lahlali> Il va falloir que tu précises ce qu'est l'elitisme pour toi car je ne vois pas ce qu'il il y a d'elitiste dans le fait qu'un débutant puisse faire une grosse application qui marche globalement bien juste en ne connaissant que 10% du language.

---

pour répondre a ça il faut faire une expérience, tu donne a deux débutants le premier en C++ et le 2eme en dotnet et tu leur demande de faire une petite application graphique et tu verra qui terminera le premier.

le débutant en C++ passe plus son temps a configurer son projet avec les includepath,libpath ainsi de suite, et croie moi il passera un temps fou pour chercher quel .h inclure et aussi sur d'autres détails qu'un developpeur expérimente ne fait même pas attention.

donc il faut prendre aussi le temps en compte, oui un developpeur débutant C++ va faire une grosse application mais en combien de temps et pire s'il maitrise que 10% du langage il passera son temps a faire la maintenance.

et pour cet aspect d'élitiste , beaucoup avant moi ont donner pas mal d'arguments et ce constat l'a fait le créateur de c++ lui même.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Quel probleme y a-t'il a faire tourner un outil QAC++ periodiquement comme on fait avec les tests?

---

t'a raison a condition que la boite s'intéresse a l'industrialisation,ou avant tout commit pas mal d'outil sont lancés pour s'assurer de la qualité du code mais c'est un autre sujet ou il faut une discussion a part :)

Citation:

---

Envoyé par Issam_Lahlali

t'a raison a condition que la boite s'intéresse a l'industrialisation,ou avant tout commit pas mal d'outil sont lancés pour s'assurer de la qualité du code mais c'est un autre sujet ou il faut une discussion a part :)

---

Si une boite n'est pas capable de mettre en place ca avec un outils separe, tu la crois assez interessee par le sujet pour le mettre en place si c'est fournit par le compilateur?

Citation:

---

Envoyé par Issam_Lahlali

alors ma question est: a quel point les compilateurs C++ sont custumizables, dans le but par exemple d'ajouter des warnings personnalisés au cas d'utilisation de char* ou de pointeur non intelligent?

---

ils le sont autant que les compilateurs C# ou Java. C'est à dire pas du tout. Le compilateur ne s'occupe que du respect de la syntaxe/grammaire.

Ce dont tu parles est le respect de "style" de codage. Comme l'on dit plusieurs intervenants avant moi, ce n'est pas le boulot du compilo mais d'outils spécialisés (CodeWizard, Vera++, ...).

Citation:

---

le débutant en C++ passe plus son temps a configurer son projet avec les includepath,libpath ainsi de suite, et croie moi il passera un temps fou pour chercher quel .h inclure et aussi sur d'autres détails qu'un developpeur expérimente ne fait même pas attention.

---

Avec un bon IDE, comme QtCreator ?

Sinon, à propos de temps perdu, en .Net, j'ai passé un temps fou à chercher quel module (plus sûr du nom, ça commence à dater) inclure dans le projet pour avoir accès à System.Configuration.[rajouter ici le nom d'une classe] qui n'est pas dans le même module que System.Configuration.[autre nom] que j'avais déjà, ce qui est d'une logique implacable :). Tous les langages/compilateurs ont leurs travers, différents, mais de là à dire que certains sont pires (bon, les messages d'erreur sur les template sont une des choses les plus imbitables qui soient, c'est peu contestable, et les erreurs de link sont ardues à comprendre)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Si une boite n'est pas capable de mettre en place ca avec un outils separe, tu la crois assez interessee par le sujet pour le mettre en place si c'est fournit par le compilateur?

---

en fait le but est de ne pas avoir un outil d'analyse statistique, mais genre des modèles de programmations ou on aura des templates par exemple un template pour objet pur.

et on aura plusieurs templates fournis et surtout celui qui encourage pour le C++ moderne.

c'est dans la même optique que les projects templates de DotNet.

Citation:

---

Envoyé par white_tentacle

Avec un bon IDE, comme QtCreator ?

Sinon, à propos de temps perdu, en .Net, j'ai passé un temps fou à chercher quel module (plus sûr du nom, ça commence à dater) inclure dans le projet pour avoir accès à System.Configuration.[rajouter ici le nom d'une classe] qui n'est pas dans le même module que System.Configuration.[autre nom] que j'avais déjà, ce qui est d'une logique implacable :). Tous les langages/compilateurs ont leurs travers, différents, mais de là à dire que certains sont pires (bon, les messages d'erreur sur les template sont une des choses les plus imbitables qui soient, c'est peu contestable, et les erreurs de link sont ardues à comprendre)

---

c'est normal que tu peux passer un temps fou sur un truc mais pas sur plusieurs, je me rappelle mes débuts en c++ je galérais juste avec la configuration du projet , et quoi dire de ceux qui utilisent toujours makefile et qui le changent a la main, c'est vrai il y a des outils CMake et autre mais dans pas mal de boites on utilisent le makefile encore.

toujours on a cet argument que maintenant c'est mieux tout est devenu facile, mais la majorité du code C++ date il y a des années.

donc si j'intègre une équipe et il me demande de faire une evolution sur un interface graphique, je ne peux pas leur dire je vais utiliser QtCreator, il faut s'adapter avec ce qu'ils ont et ca peut être WTL,MFC,WxWidgets,ou autre.

dans un monde idéal ou on commence un nouveau projet c'est très bien , a condition d'être bien encadré mais dans le monde réel c'est autre chose, on doit raisoner avec ce qui existe pas ce qu'on espère comme Qt ou Boost.

et dans ce contexte le C++ est plus difficile que d'autre parce que son passé n'est pas glorieux vu les anti pattern qui étaient utiliser.

Citation:

---

Envoyé par Issam_Lahlali

c'est dans la même optique que les projects templates de DotNet.

---

On va partir sur le troll^H^H^H^H^Hsujet sur les EDI par rapport aux outils separes.

Citation:

---

Envoyé par Issam_Lahlali

c'est normal que tu peux passer un temps fou sur un truc mais pas sur plusieurs, je me rappelle mes débuts en c++ je galérais juste avec la configuration du projet , et quoi dire de ceux qui utilisent toujours makefile et qui le changent a la main, c'est vrai il y a des outils CMake et autre mais dans pas mal de boites on utilisent le makefile encore.

toujours on a cet argument que maintenant c'est mieux tout est devenu facile, mais la majorité du code C++ date il y a des années.

---

A mon avis, tu compares deux choses différentes:

- "C++" : le langage de programmation. C'est à dire une spécification.

- "Java" ou ".Net" : les technologies. Qui incluent (au minimum) le langage de programmation (la spec), les outils de développement (compilo, debug, ...), les librairies standards et les guides (doc, tuto, bonnes pratiques).

En "C++" tu dois commencer par construire ton propre kit de développement (outils, docs, coding-style, librairies, ...). C'est certes une étape supplémentaire par rapport a Java/.Net mais la puissance/souplesse du C++ est à ce prix.

Citation:

---

Envoyé par pseudocode

la puissance/souplesse du C++ est à ce prix.

---

on a tendance a oublier que C++ a un passé de 20 ans , et il a fallu des années pour ce rendre compte qu'il était mal utilisé, ce qui est normal vu que le C++ est parmi les premiers langages a prendre en compte l'approche objet, et l'approche objet elle même a mis du temps pour devenir mature.

en gros la majorité du code c++ existant est non moderne, ce qui est encore normal, et un developpeur qui doit intégrer une boite va être confronter a ce code d'où l'elitisme dont on parle parce qu'il faut une expérience pour comprendre les problématiques du code d'avant et ce qu'il faut éviter de faire.

par contre si on commence depuis le debut un projet en c++ et on utilise ce qui est conseillé , on peut s'en sortir mieux qu'avant , mais malheureusement en réalité on est beaucoup confronté au passé de C++.

Citation:

---

Envoyé par fcharton

Dans quelle mesure, le C++ n'est il pas un exemple que "le mieux est l'ennemi du bien". Je veux dire, en C++, il y a plein de façons, toutes plus abstraites ou plus compliquées les unes que les autres, de résoudre un problème (avec souvent, caché derrière, une mesure un peu ridicule de l'efficacité : la concision du code produit). Du coup, on passe son temps à réfléchir et tergiverser, là ou des développeurs "normaux" se mettent au boulot.

---

Je ne remet absolument pas en cause l'utilité des pointeurs en C et je suis bien conscient de tous les bénéfices qu'ils ont apportés au langage.

Mais, d'un autre coté, les seuls fait de changer la syntaxe d'accès au champs d'une structure, de devoir accéder à "l'adresse de quelque chose" ou au contraire "à ce qui est pointé" par un pointeur, voire, de devoir vérifier systématiquement qu'il n'est pas nul rend déjà leur utilisation inutilement complexe (si du moins il existait une alternative pour disposer de leurs avantages)

Le C++ dispose des références, et il faut avouer qu'elles présentent des avantages réels par rapport aux pointeurs dans ces utilisations particulières (pas de changement de syntaxe, inutile d'accéder "à l'adresse de" ou à "ce qui est pointé par", impossibilité d'être null, et donc absence de vérification supplémentaire,...)

Vient ensuite le problème de la gestion dynamique de la mémoire...

En C, lorsque l'on veut créer une liste d'objets (le terme objet étant à prendre ici sous son acception tout à fait générale, et non sous son acception OO ;)), nous devrons travailler sous une forme proche de :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

typedef struct Object_ { /* les champs nécessaires */ } Object;   typedef struct Element_ { Object data; struct Element_ * next; /* struct Element_ * previous; */ }Element; typedef struct ListObject_ { Element* first; /* Element * last; */ }ListObject;

---

Et nous remarquons que:

• Le cadre d'utilisation de Element est finalement fort proche du std::list<T>::iterator
• nous devrons recourir à la gestion dynamique de la mémoire manuelle pour gérer la liste

Je n'ai, à titre personnel pas de problème avec la gestion dynamique de la mémoire, mais je ne connais personne qui, même habitué, ne s'est pas une fois "fourvoyé" par fatigue ou par lassitude dans sa gestion ;)

Si, grâce aux mécanismes mis en oeuvre par C++ (les références et les différents containers de la STL), il est possible de s'éviter les écueils des pointeurs, mon avis est réellement qu'il est des plus intéressant de le faire;)

Au final, il ne reste plus qu'une situation dans laquelle le recours au pointeur (et à la gestion dynamique manuelle de la mémoire) devient nécessaire:

Le cadre de la gestion (d'une collection ) d'objets polymorphes.

Citation:

---

On pourrait dire que cela garantit que tous les programmes C++ sont excellents, maintenables et évolutifs (et que tous les autres ne le sont pas), mais quelque chose me dit que ce n'est pas tout à fait le cas...

Francois

---

La maintenabilité et l'évolutivité d'un programme ne peut être garantie (et encore) que par la compétance du programmeur, quel que soit le langage envisagé.

Par contre, l'utilisation des mécanismes proposés par le C++ (qu'il s'agisse d'utiliser les références ou les containers de la STL) est de nature à garantir le fait qu'il n'y aura pas d'erreur idiotes dues à la gestion des pointeurs en générale, et à la gestion dynamique de la mémoire en particulier, ce qui aura pour corollaire

• d'assurer un niveau minimal de qualité
• de "libérer l'esprit" du développeur de tout un pan des problèmes auxquels il devrait être particulièrement attentif, ce qui lui permet de s'intéresser en priorité aux problèmes réels auxquels il est confrontés plutôt qu'à des problèmes purement induits par les inconvénients d'une technique particulière

En ce sens, on ne peut réellement pas dire que le mieux est l'ennemi du bien ;)

Citation:

---

Envoyé par Klaim

Non plus. J'ai déjà eu a bosser avec un dévelopeur C qui bossait depuis 10 ans sur les mêmes types d'applications, toujours a réécrire le même code a chaque fois (copier, coller, modifier). Il disait ne pas comprendre comment faire de la P.O.O et ne voulait tout simplement pas apprendre de nouvelles choses vu que ce n'était pas du tout nécessaire pour la boite.

---

En informatique, comme dans pas mal de domaines, certaines choses ne s'acquièrent qu'en faisant des erreurs. Les livres, les cours, les bonnes pratiques, ca ne sert que jusqu'à un certain point. Et pour faire des erreurs, il faut du temps... Il n'y a pas de secret.

Maintenant, ca ne veut pas dire que passer du temps en entreprise, ou faire plein de bêtises, suffit pour avoir de l'expérience... Mais c'est quand même nécessaire.

Mais bien sur, on a tous été persuadés du contraire à 20 ans, et on s'est tous sentis super pros à 25. C'est comme ça...

Francois

Tout à fait.

Encore une glorification de l'âge et de l'expérience accumulée par le temps...

Oui, j'ai entre 20 et 25 ans, je n'ai aucune expérience du travail en entreprise, et oui, je pense être un expert, du moins au moins sur le plan du langage en lui-même et de ses utilisations modernes, mais je suis persuadé que c'est un jugement de moi-même honnête et non pas une crise de mégalomanie juvénile.

Ce que l'on apprend vraiment en entreprise, c'est gérer la charge de travail et faire des compromis avec le code existant qui est pourri mais avec lequel il faut savoir travailler.
Choses qu'on peut apprendre tout aussi bien en dehors de l'entreprise.