Discussion :

[Klaim]

Effectivement, pour un language "élitiste" il est étonnant que des tas de jeunes (j'entends non-majeurs) arrivent a en faire quelque chose (certes en ignorant une grande partie du language). J'ai vu récemment des collegiens s'y mettre parcequ'ils avaient envie de faire du jeu vidéo. Moi même je suis passé par là (vers 17/18 ans j'ai fais mon premier "gros" jeu en apprenant les bases du C++ - pas le moderne a l'époque malheureusement, mais bon j'étais pas guidé), et je ne me suis servi que d'internet au début, puis de livres.
Et je suis loin d'être un génie - je le prouve tous les jours

Ca n'a rien d'élitiste.

[Issam_Lahlali]

Effectivement, pour un language "élitiste" il est étonnant que des tas de jeunes (j'entends non-majeurs) arrivent a en faire quelque chose (certes en ignorant une grande partie du language). J'ai vu récemment des collegiens s'y mettre parcequ'ils avaient envie de faire du jeu vidéo. Moi même je suis passé par là (vers 17/18 ans j'ai fais mon premier "gros" jeu en apprenant les bases du C++ - pas le moderne a l'époque malheureusement, mais bon j'étais pas guidé), et je ne me suis servi que d'internet au début, puis de livres.
Et je suis loin d'être un génie - je le prouve tous les jours

Ca n'a rien d'élitiste.

a mon avis il faut différencier ce qu'on fait comme projets en école ou chez soi et ce qui se passe en entreprise ou en open source.

le premier type de projet on le fini , il n'est quasiment utilisé par personne, juste peut être une demo devant le prof et le projet est clos, pas de maintenance et pas d'évolution, et surtout on s'en fout des fuites mémoires, de l'optimisation,ect....

et dans ce contexte tout devient facile, même si le projet est très mal conçu c'est pas grave.

dans le contexte d'entreprise ou open source il y a d'autres contraintes qui font que si on maitrise pas bien les mécanismes d'un langage comme C++, on passe notre temps a corriger des bugs pour en introduire d'autres et ça se termine pas.

alors est ce que c++ est aussi simple que les autres langages, comme beaucoup qui ont intervenu avant je crois pas, même le créateur de c++ dit qu'il est devenu "expert friendly".

mais je suis d'accord que si on passe quelques années sur C++ on maitrise un langage très puissant , mais a condition de ne pas tomber dans le piège de toujours penser technique, parce qu'au départ chaque nouveau developpeur C++ passe beaucoup de temps sur la technique ce qui est normal vu la richesse de C++.

mais a un moment donné il faut faire la bascule et ne pas rester focaliser sur la technique, il y en a ceux qui arrivent et ceux qui tombent dans le piège, et pour ces derniers même s'ils ont des années d'expérience ils vont toujours concevoir des projets d'une manière très compliquée.

Ce constat est certes vrai pour les autres langages mais la nature riche de C++ fait qu'au départ on ce concentre plus sur la technique que d'autres langages et on prend les habitudes pro technique.

Et peut être la question qui se pose est : quels sont les facteurs qui aide le plus a basculer d'une approche technique pur a une approche guidée par la conception?

[yan]

dans le contexte d'entreprise ou open source il y a d'autres contraintes qui font que si on maitrise pas bien les mécanismes d'un langage comme C++, on passe notre temps a corriger des bugs pour en introduire d'autres et ça se termine pas.

ben pareil pour tout langage. Temps que l'on ne sait pas utiliser un debuggeur, on n'avance pas beaucoup.
D'ailleurs, il me semble que le debuggeur C/C++ sont bien plus puissant que ceux des autres langages. Ceux de .net commence à être très bien aussi.

alors est ce que c++ est aussi simple que les autres langages

En C# et en java tout est référence. Le = ne fait que modifier la référence et le == teste la valeur des références et non l'objet. C'est pas super logique pour moi.
Pour gérer des ressources système, il est préférable d'utiliser le using en C# pour leur libération. En C++ le RAII le fait pour toi.
Le C++ est complexe parce que les gens le pense. Une fois enlevé l'utilisation des pointeurs, utiliser la S(T)l au lien de gérer la mémoire "à la main",de ce dire que c'est compliqué et que la personne arrête d'optimiser toute les deux lignes de code et qu'il optimise plutôt l'algorithmique avant d'aller plus loin si nécessaire . Le c++ n'est pas plus compliqué qu'un autre. D'ailleurs la S(T)L permet déjà de faire en majorité du code C++ sans écrire un seul delete. De plus, une boucle c'est une boucle, un itérateur c'est un itérateur, une fonction une fonction, un objet un objet... En quoi ça devrais être plus compliqué en C++?

Et peut être la question qui se pose est : quels sont les facteurs qui aide le plus a basculer d'une approche technique pur a une approche guidée par la conception?

l'expérience? Comprendre que le C++ n'est pas plus difficile?

C'est drôle j'ai l'impression qu'avec les langages type java et C# c'est le phénomène inverse. On commence par l'approche conception et on fini par l'approche technique en oubliant de plus en plus la conception.

[Aurelien.Regat-Barrel]

Le C++ est complexe parce que c'est la complexité de la gestion mémoire. Grosso modo, la simplicité de Java ou .Net vient du fait que ces langages soulagent énormément le programmeur sur cet aspet. Je me souviens quand je découvrais .Net d'être assez épaté par ce genre de syntaxe :

Code :

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

1
2
int n = 10;
string s = n.ToString();

Le débutant .Net ne se rend pas du tout compte de tout ce que cela implique derrière. Le programmeur C++ y est confronté.

Une développeur Java/.Net tombe de haut quand il découvre que C++ ne dispose pas de type string "natif". D'ailleurs, bien des bugs et problèmes en C++ viennent de la gestion des chaines de caractères, et puis les tableaux... Le concept de chaine null terminal implique un langage beaucoup plus "bas niveau". Un débutant doit rapidement se frotter à ce qui relève en fait du détail d'implémenttaion, sauf que c'est loin d'être un simple détail, c'est la base.

Ca nous semble évident, mais pour beaucoup de monde ça ne l'est pas. Il y a les programmeurs qui arrivent à saisir ces concepts de gestion mémoire etc... et il y en a qui n'y arrivent tout simplement pas. Pour eux, le C++ fait partie des langages innaccessibles.

Le C++ éclate aussi le code en .h et .cpp. Ca n'a l'air de rien, mais ça demande du temps avant d'acquérir la faculté d'aller regarder dans un .h. Java et .Net suppriment les contraintes le linkage, alors qu'en C++ ce sont des erreurs très obscures.

Pour ces raisons et beaucoup d'autres, C++ est bien plus long à maîtriser. Une fois que c'est fait, ben c'est fait. Mais faut le faire, et ça saoule beaucoup de monde, car ce genre de contraintes donne l'impression d'être issue d'un autre âge.

[gl]

Une développeur Java/.Net tombe de haut quand il découvre que C++ ne dispose pas de type string "natif".

Qu'entends-tu exactement par "natif" ?

Car bien que n'étant pas un type primitif, std::string fait bel et bien partie du C++.

D'ailleurs, bien des bugs et problèmes en C++ viennent de la gestion des chaines de caractères, et puis les tableaux... Le concept de chaine null terminal implique un langage beaucoup plus "bas niveau". Un débutant doit rapidement se frotter à ce qui relève en fait du détail d'implémenttaion, sauf que c'est loin d'être un simple détail, c'est la base.

Ça fait quand même bien longtemps que l'on n'a plus à se préoccuper du 0 terminal ou de la gestion de la mémoire des chaines de caractères et des tableaux en C++.
std::string et les containers de la STL (std::vector notamment), se charge très bien de ces soucis pour nous.

[yan]

Je me souviens quand je découvrais .Net d'être assez épaté par ce genre de syntaxe :

Code :

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

1
2
int n = 10;
string s = n.ToString();

Ceci, tu l'utilisera uniquement en cas d'école et utilisera plutôt StringFormat pour créer tes chaines. Tout comme tu utilisera stringstream.

[Aurelien.Regat-Barrel]

Qu'entends-tu exactement par "natif" ?

Qui ne soit pas une classe que l'on doit inclure, mais un build-in type au même type que int ou float. Exemple de problème tout simple :

Code :

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

std::string s = "Hello" + " World!";

Note que je ne cherche pas à dire que c'est bien ou mal, je constate simplement. Dans les autres langages ce n'est pas comme ça, et les débutants ne comprennent pas pourquoi c'est "si compliqué" en C++.

Ça fait quand même bien longtemps que l'on n'a plus à se préoccuper du 0 terminal ou de la gestion de la mémoire des chaines de caractères et des tableaux en C++.
std::string et les containers de la STL (std::vector notamment), se charge très bien de ces soucis pour nous.

Tu n'as pas à t'en préoccuper certainement, ne pas à savoir que ça fonctionne ainsi je sais pas. Comme je l'ai dit, une fois qu'on le sait, ben on le sait et on sait faire avec sans problème.

Le problème c'est le temps et la difficulté d'acquérir toute cette connaissance quasi-indispensable, qui bien souvent s'acquiert à coups de bugs et de crash, ce qui coûte cher à plusieurs niveaux. C'est simple : le C++ ça plante, voilà en gros l'image de base.

Mon sentiment, c'est que les entreprises apprécient beaucoup les développeurs C++ expérimentés, mais qu'elles ne veulent pas les former.

[Issam_Lahlali]

Ça fait quand même bien longtemps que l'on n'a plus à se préoccuper du 0 terminal ou de la gestion de la mémoire des chaines de caractères et des tableaux en C++.
std::string et les containers de la STL (std::vector notamment), se charge très bien de ces soucis pour nous.

lorsqu'un developpeur C++ intègre un projet il ne trouve pas le monde idéal de C++ loin de la , a cause de l'historique des applications qui ont des années d'existence.

donc forcement il doit connaitre comment travailler avec les char*, les pointeurs et les doubles pointeurs.

et rare sont ceux qui entame un refactoring pour avoir un code moderne, ceux que j'ai connu qui ont fait cette démarche ils ont changer de langage et il migre vers C#, et comment les convaincre que c'est la manière classique du C++ qui était la cause de la complexité et qu'il existe une manière moderne aussi simple que C#.

pour un décideur il donne une seule chance , et il ne joue pas a faire la même chose 2fois , pour lui il y a un investissement en jeu.

donc oui le C++ actuellement propose des solutions plus simple qu'avant mais malheureusement c'est pas ce qu'on trouve dans des projets qui ont des années d'existence donc entrer dans le détail et connaitre les rouages du bas niveau est une nécessité pour tout developpeur C++.

[gl]

donc oui le C++ actuellement propose des solutions plus simple qu'avant mais malheureusement c'est pas ce qu'on trouve dans des projets qui ont des années d'existence donc entrer dans le détail et connaitre les rouages du bas niveau est une nécessité pour tout developpeur C++.

Je le sais parfaitement, mais est-ce une raison pour continuer à écrire ce genre de code ?

Entre continuer de travailler ainsi et tout refactorer de A à Z (ce qui est, nous sommes d'accord, généralement irréaliste), je vois une autre alternative, celle qui consiste à utiliser, dans la mesure du possible, les pratiques modernes lors de l'écriture de nouveau code et de la correction du code existant.

[Issam_Lahlali]

Entre continuer de travailler ainsi et tout refactorer de A à Z (ce qui est, nous sommes d'accord, généralement irréaliste), je vois une autre alternative, celle qui consiste à utiliser, dans la mesure du possible, les pratiques modernes lors de l'écriture de nouveau code et de la correction du code existant.

tout a fait d'accord mais le developpeur doit aussi s'en soucier de ce qui est bas niveau aussi vu qu'il aura une maintenance a faire sur le code existant.

ce que je veux dire c'est qu'on peut pas dire au developpeur c++ tu n'a qu'a te soucier de la manière moderne et oublie les char*, pointeur et autre complexité parce que dans le monde de travail il aura besoin de ça.

finalement c'est pas la manière moderne de C++ qui va le soulager de connaitre la manière classique,il faut qu'il maitrise les 2 manières d'où la difficulté, une pour pouvoir maintenir sans introduire d'autres bugs et l'autre pour les évolutions et les nouveaux devs.

[Aurelien.Regat-Barrel]

Je le sais parfaitement, mais est-ce une raison pour continuer à écrire ce genre de code ?

Entre continuer de travailler ainsi et tout refactorer de A à Z (ce qui est, nous sommes d'accord, généralement irréaliste), je vois une autre alternative, celle qui consiste à utiliser, dans la mesure du possible, les pratiques modernes lors de l'écriture de nouveau code et de la correction du code existant.

Quand il s'agit de gestion mémoire, il est difficile de mixer plusieurs pratiques.

Dans mon ancien taf, rien que migrer d'un type string maison au type QString a demandé plusieurs mois / homme, et quand même causé quelques regressions... chez le client bien sûr.

Pour ce qui est d'utiliser des pointeurs intelligents... c'est tout ou rien, tu ne peux pas utiliser les shared_ptr dans une partie du code et pas le reste. Ca revient à effectuer des centaines / milliers de changements qui ont de fortes chances d'être testés tous ensemble d'un seul coup après plusieurs semaines de refactoring... effrayant. Refactorer l'usage des pointeurs dans une appli de +1 million de lignes de code c'est vraiment galère, car quand une appli est mal développée, elle l'est jusqu'au bout (couplage fort, structuration monolithique...). Alors les mecs préfèrent continuer comme ça, et tans pis pour les fuites et corruptions de mémoire qui trainent.

Cette constation de combien le C++ mal employé peut être merdique m'avait carrément fait douter de la pertinence de ce langage, alors que je me suis beaucoup investi dans ce langage et sa communauté. Devoir coder ainsi en C++, c'est vraiment à te dégouter du langage. Et que faire quand le simple mot "pointeur intelligent" fait frémir l'équipe de dev et même son chef de projet ?

[metagoto]

Et que faire quand le simple mot "pointeur intelligent" fait frémir l'équipe de dev et même son chef de projet ?

Tout refaire en... C

A ce propos, on parle souvent de l'utilisation catastrophique des pointers en C++, mais on n'en parle jamais vraiment pour le C. Est-ce parce que très peu de "nouveaux" projets sont démarrés en C ? Mais qu'en est-il de la maintenance des milliers d'applis en C ?

[Luc Hermitte]

Vous vous souvenez de ce troll sur la ML de git (je crois) quand Linus Torvald avait réfuté l'idée de (re)faire git en C++ ?
Ma libre interprétation depuis mes souvenirs est que que j'avais retenu de sa vision que ceux qui restent à faire du C savent ce qu'ils font. Ceux qui ont migré vers le C++, il en est heureux, ne peuvent (ou veulent?) plus faire de dégâts en C. Raison de plus pour lui de rester à développer ses applis en C.

On en revient à cette vision de migrations de populations pas vraiment faites pour une chose et qui sont en perpétuelle course après la balle en argent. On pourrait presque croire que quand ils arrivent, la balle est déjà repartie.

[Jean-Marc.Bourguet]

Cette constation de combien le C++ mal employé peut être merdique

Les seuls langages pour lesquels on n'a pas d'exemples de code merdique sont ceux qui n'ont jamais servi.

A ce propos, on parle souvent de l'utilisation catastrophique des pointers en C++, mais on n'en parle jamais vraiment pour le C. Est-ce parce que très peu de "nouveaux" projets sont démarrés en C ?

C'est parce que tu n'écoutes pas aux bons endroits.

On en revient à cette vision de migrations de populations pas vraiment faites pour une chose et qui sont en perpétuelle course après la balle en argent. On pourrait presque croire que quand ils arrivent, la balle est déjà repartie.

There is no silver bullet (Brooks)

[koala01]

Tout refaire en... C

A ce propos, on parle souvent de l'utilisation catastrophique des pointers en C++, mais on n'en parle jamais vraiment pour le C. Est-ce parce que très peu de "nouveaux" projets sont démarrés en C ? Mais qu'en est-il de la maintenance des milliers d'applis en C ?

Dans quelle mesure n'est-ce pas, simplement, parce que, une fois que l'on a constaté en C que les pointeurs (voire, pire encore les pointeurs sur void) sont dangereux et à manipuler "avec prudence", il n'y a aucune alternative pour arriver à s'en passer

En C++, on en arrive, fatalement, à la même constatation, mais, comme il existe des alternatives pour s'en passer, on insiste peut être d'avantage sur le fait et on fait plus facilement la "publicité" de l'alternative

[Invité]

Mon sentiment, c'est que les entreprises apprécient beaucoup les développeurs C++ expérimentés, mais qu'elles ne veulent pas les former.

C'est vrai, et c'est malheureusement logique. Pour une entreprise, investir dans la formation d'un développeur n'est presque jamais rentable (à l'exception des petites formations de quelques jours prévues au contrat, qui n'engagent à rien, et généralement ne servent pas à grand chose non plus). Le développeur, une fois formé, quittera l'entreprise dans la plupart des cas.

En C++, on en arrive, fatalement, à la même constatation, mais, comme il existe des alternatives pour s'en passer, on insiste peut être d'avantage sur le fait et on fait plus facilement la "publicité" de l'alternative

Une question se pose alors...

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.

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

[loufoque]

Dans adobe.ASL ils ont un parseur ~SAX qui travaille avec des vues. Les chaines ne sont jamais copiées, à la place il ont un type chaine qui va pointer dans un buffer de caractères.

Et comment ils gèrent les entités d'échappement, les commentaires au milieu du texte, etc?
Une solution serait une transformation appliquée de manière paresseuse.

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.

C'est un argument classique en faveur du C plutôt que le C++.
Linus Torvalds, en particulier, dit que la capacité de créer des abstractions en C++ est trop dangereuse et que c'est pour ça qu'il pense que le C est cent fois mieux.

[white_tentacle]

Mon sentiment, c'est que les entreprises apprécient beaucoup les développeurs C++ expérimentés, mais qu'elles ne veulent pas les former.

Ça résume bien la politique des SSII, c'est un peu moins vrai dans des PME.

Mais dans tous les cas, c'est surtout à nous, développeurs plus expérimentés, de passer du temps à former les développeurs plus jeunes, même si la hiérarachie ne veut pas entendre parler de formations. Certes, ça prend du temps qu'on n'a pas toujours, qu'on aimerait passer à autre chose, mais je pense qu'au final on y est vraiment gagnant.

[loufoque]

L'âge et l'expertise ne sont pas forcément corrélés.

[Invité]

L'âge et l'expertise ne sont pas forcément corrélés.

L'expertise, pas forcément, l'expérience, en revanche...

Francois