Discussion :

[Squisqui]

Il en va de même pour C++: il assume son héritage de C, il assume une certaine compatibilité avec celui-ci, mais il est totalement faut et restrictif de dire que C++ n'est "que du C amélioré".

C'est un langage totalement différent, qui apporte un grand nombre de possibilités totalement nouvelles par rapport au C et qui, surtout, est en mesure d'apporter une sécurisation beaucoup plus importante

+1 Mais on y est pas encore malheureusement.
Dans l'éducation, il est courant d'avoir des profs qui font apprendre le C avant d'aborder le C++ ou encore apprendre du C++ avec la libc et hop on se retrouve avec les deux directives pour inclure iostream et stdio.h et ça devient ni plus ni moins que du C avec un compilateur C++.
Ça fait bien longtemps que le synonyme C++ = "C with class" est obsolète et qu'il ne reste plus qu'un lien de parenté historique et une certaine compatibilité.
J'aimerais souligner que dans une filière scientifique, on aborde des aspects physiques en allant de modèles simples à complexes en retirant de nombreuses abstractions alors qu'en programmation on commence à aborder des aspects techniques bas-niveau avant d'en faire abstraction...
C'est du moins ce que j'ai pu constater durant ma scolarité scientifique (et non IT) et celles des autres.

En tout cas, mon avis est simple et stupide mais pas évident pour tout le monde :
Si tu veux faire du C, fait du C. Si tu veux faire du C++, fait du C++.
Faire du C pour faire du C++ a autant de sens que de faire du Java pour faire du C# (histoire de réveiller une fois encore une autre rivalité).

[jouana]

Juste pour dire merci, pour S.O.L.I.D je n'en avais pas entendu parler et il est vrai que ce type d'info est toujours bonne a prendre.

Bon article merci.

[koala01]

+1 Mais on y est pas encore malheureusement.
Dans l'éducation, il est courant d'avoir des profs qui font apprendre le C avant d'aborder le C++ ou encore apprendre du C++ avec la libc et hop on se retrouve avec les deux directives pour inclure iostream et stdio.h et ça devient ni plus ni moins que du C avec un compilateur C++.

En fait, c'est un combat que nous menons très régulièrement sur le forum (je suis sur que, si tu regarde dans l'historique du forum, cet aspect est abordé au moins une fois par mois )

On arrive tout doucement à faire changer les mentalités, mais on ne peut malheureusement convaincre que ceux qui acceptent de se remettre en cause

Ça fait bien longtemps que le synonyme C++ = "C with class" est obsolète et qu'il ne reste plus qu'un lien de parenté historique et une certaine compatibilité.

Oh que oui

J'aimerais souligner que dans une filière scientifique, on aborde des aspects physiques en allant de modèles simples à complexes en retirant de nombreuses abstractions alors qu'en programmation on commence à aborder des aspects techniques bas-niveau avant d'en faire abstraction...
C'est du moins ce que j'ai pu constater durant ma scolarité scientifique (et non IT) et celles des autres.

Tout à fait...

Cela montre à quel point le problème est important

Mais je te rassures, je sais pertinemment avoir été la cause de la remise en cause d'un prof au moins (le mien)...

On a bien conscience que c'est une bataille longue et répétitive que l'on est en train de mener, mais si chacun arrive à convaincre un prof, nous finirons bien par avoir un enseignement de qualité en C++

En tout cas, mon avis est simple et stupide mais pas évident pour tout le monde :
Si tu veux faire du C, fait du C. Si tu veux faire du C++, fait du C++.
Faire du C pour faire du C++ a autant de sens que de faire du Java pour faire du C# (histoire de réveiller une fois encore une autre rivalité).

En quoi tu as tout à fait raison

Ceci dit, l'envie n'est malheureusement qu'un aspect du problème: C++ est, déjà, un langage "de niche" (au regard des offres d'emplois qui le demandent), mais C l'est encore d'avantage (car, justement, C++, java et C# tiennent le haut du pavé).

Mais bon, outre le fait de ramener la bidoche du souper, l'envie est ce qui permet de former la culture générale

[jouana]

Le plus gros problème des formations vient bien des professeurs.

Le meilleur exemple que j'ai est ma formation Bac Pro MRIM, mon prof la trentaine passionné par l'informatique (docteur réseau informatique, ancien chercheur).

Cette personne était fan de linux et nous avons eu deux années très intéressantes a apprendre avec lui (50% de la formation sous linux et 50% sous windows).

En parallèle j'ai un pote (avec qui j'était en BEP) qui était dans une autre école et sa formation c'est limité a windows.

Ensuite après ça j'ai fais une formation en 5 ans dans une école privé plus orienté sur la pratique plutôt que la théorie et la encore je trouve que par rapport à d'autres école au fonctionnement inverse je suis plus souple dans mon travail, certes théoriquement je maitrise moins bien certains sujets mais j'ai plus de facilité a m'adapté au situation de la vie professionnelle.

Donc je pense que au-dela du langage à apprendre en premier, c'est le fonctionnement des formations qui est à revoir, ainsi que vérifier régulièrement la connaissance des profs dans un monde en mouvement continuel il est important de suivre ce mouvement afin de ne pas être à la bourre voir perdu.

[gbdivers]

Par pitié, éviter de citer shared_ptr à tout va comme ça...

Tu n'es pas le premier à faire la remarque sur shared_ptr, je vais donc préciser un point : je n'ai pas dit (bien qu'en me relisant, ce n'est pas être pas clair) qu'il fallait utiliser shared_ptr pour les pointeurs (tout comme vector n'est pas le seul conteneur de la stl). C'était des exemples d'application du RAII proposé par le STL, liste bien sur non exhaustive.

Pour le reste, c'est marrant de constater qu'a chaque fois que quelqu'un sort l'objet, il sort des principes dans tous les sens, et des acronymes à coucher dehors dont je n'ai jamais entendu parler.

Même remarque (un peu) que pour germinolegrand : est-ce que tu penses que ne pas les connaître fait de toi un meilleur développeur ou cela ne change rien ?

Il y a matière à dire sur les principes (et cela fera l'objet d'un article à part entière...), mais je vais préciser mon point de vue.

Première question, entre quelqu'un qui les connait pas et qui pense qu'ils ne servent à rien et quelqu'un qui les connaît et qui dit qu'il est important de les respecter, vous préférez croire qui ? Pour moi, la réponse est simple : on ne peut critiquer correctement que ce que l'on connait bien.
Le corollaire de cela, faut-il qu'un débutant respecte ces principes le temps d'apprendre à les connaître ou au contraire ne doit pas les respecter tant qu'il les connait pas ? La encore, ma position est claire, je fais confiance à ceux qui s'y connaissent.

Je suis d'accord avec vous sur le fait que les principes ne sont pas des dogmes, qu'il ne faut pas accepter en disant amen. Est-ce qu'il faut pour autant les rejeter ?
Revenons à la base : quelle est l'origine de ces principes ? Le processus est simple : il y a une difficulté, un problème récurrent ; on analyse l'origine ; on établie une règle pour minimiser le risque de refaire les mêmes erreurs.
Ne pas appliquer un principe (par choix ou par ignorance), c'est donc prendre le risque de faire des erreurs connues et évitables. Rejeter les principes sans les étudier, c'est se priver de la démarche consistant à identifier les problématiques qu'ils abordent, les solutions trouvées, leurs avantages et limites, le pourquoi de la règle.

Donc pour répondre à la question est-on un mauvais développeur si on ne connait pas ces principes, je crois que celui qui est entré dans la démarche de réflexion nécessaire pour comprendre ces principes à une plus grande maîtrise de ce qu'il fait que celui qui rejette en bloc ces principes (au moins, celui qui respecte ces principes sans les comprendre n'aura pas cette maîtrise, mais il prendra aussi moins de risques)

On peut se poser la question plus générale à quelle moment faut il apprendre ces principes. Pour moi, ils doivent faire partie intégrante de l'apprentissage de la programmation en C++

(EDIT : petite précision, sur la page d’accueil, il est indiqué "Analyse de ces langages par le Responsable C++ de Developpez". Le titre est un peu fort, ma prétention n'est pas l'analyse de ces langages, juste une réflexion partant de la comparaison de quelques points de difficultés entre ces deux langages)

[koala01]

Juste pour dire merci, pour S.O.L.I.D je n'en avais pas entendu parler et il est vrai que ce type d'info est toujours bonne a prendre.

Bon article merci.

Et pourtant, si tu fais une recherche sur le forum (mais je présumes que c'est ce que tu as fait ) le terme a été cité (essentiellement par moi d'ailleurs ) une bonne dizaine de fois rien que l'année passée

Le plus gros problème des formations vient bien des professeurs.

Le meilleur exemple que j'ai est ma formation Bac Pro MRIM, mon prof la trentaine passionné par l'informatique (docteur réseau informatique, ancien chercheur).

Cette personne était fan de linux et nous avons eu deux années très intéressantes a apprendre avec lui (50% de la formation sous linux et 50% sous windows).

En parallèle j'ai un pote (avec qui j'était en BEP) qui était dans une autre école et sa formation c'est limité a windows.

Ensuite après ça j'ai fais une formation en 5 ans dans une école privé plus orienté sur la pratique plutôt que la théorie et la encore je trouve que par rapport à d'autres école au fonctionnement inverse je suis plus souple dans mon travail, certes théoriquement je maitrise moins bien certains sujets mais j'ai plus de facilité a m'adapté au situation de la vie professionnelle.

Donc je pense que au-dela du langage à apprendre en premier, c'est le fonctionnement des formations qui est à revoir, ainsi que vérifier régulièrement la connaissance des profs dans un monde en mouvement continuel il est important de suivre ce mouvement afin de ne pas être à la bourre voir perdu.

C'est, malheureusement, tout le problème de l'enseignement

On a beau jeu de dire que l'enseignement doit vous apprendre à apprendre!!

Même si ce n'est pas tout à fait faux, il faut malgré tout que le prof serve un tout petit peu quand même de relais de la connaissance, mais, pour cela, on est souvent limité aux connaissances du relais

Ceci dit, il faut malgré tout garder en tête le fait que C++ est, décidément, un langage particulièrement complexe.

J'en fais maintenant à temps plein (ou peu s'en faut) depuis quelques années, et je ne suis pas encore tout à fait sur d'en avoir fait le tour

La question pourrait donc être de savoir ce qu'il faut enseigner du C++ et dans quel ordre, car seul l'étudiant qui voudra s'y intéresser personnellement aura une chance de le maîtriser

Où s'arrête l'étude "scolaire" du langage, et l'intérêt de l'étudiant prend il le relais ?

Ceci dit, l'intérêt de l'étudiant serait sans doute beaucoup plus motivé par une approche scolaire intéressante

[Squisqui]

Mais je te rassures, je sais pertinemment avoir été la cause de la remise en cause d'un prof au moins (le mien)...

On a bien conscience que c'est une bataille longue et répétitive que l'on est en train de mener, mais si chacun arrive à convaincre un prof, nous finirons bien par avoir un enseignement de qualité en C++ En quoi tu as tout à fait raison

Je n'y manque pas à chaque occasion en plus du troll sur les librairies

Ceci dit, l'envie n'est malheureusement qu'un aspect du problème: C++ est, déjà, un langage "de niche" (au regard des offres d'emplois qui le demandent), mais C l'est encore d'avantage (car, justement, C++, java et C# tiennent le haut du pavé).

Je ne suis pas tout à fait d'accord.
Il y a peut-être peu de jobs pour faire du C toute la journée, mais il y en a déjà plus dans d'autres domaines qui demande à faire du C de temps en temps. Par exemple dans le domaine de l'électronique, de l'instrumentation, etc... Où le C reste sans équivalent pour faire fonctionner un micro-contrôleur (à moins de devoir travailler avec le BASIC du constructeur ou pire, en ASM).
Je ne m'avance pas davantage pour le C++ qui est plus éloigné de mon cœur de métier, je ne suis pas renseigné.

[jouana]

Et pourtant, si tu fais une recherche sur le forum (mais je présumes que c'est ce que tu as fait ) le terme a été cité (essentiellement par moi d'ailleurs ) une bonne dizaine de fois rien que l'année passée

Je ne doute pas de ça, j'ai pu voir qlq une de tes interventions que je les trouve toujours intéressantes et constructives, mais je n'ai pas encore eu l'occasion de tomber la dessus, maintenant c'est fait ^^

Où s'arrête l'étude "scolaire" du langage, et l'intérêt de l'étudiant prend il le relais ?

Ceci dit, l'intérêt de l'étudiant serait sans doute beaucoup plus motivé par une approche scolaire intéressante

On critique souvent le système scolaire et ses acteurs, mais il ne faut pas négliger la sensibilité et l'intérêt des étudiants.

Je suis actuellement dans le passage du milieu scolaire au milieu pro et je peux dire qu'au-delà du système scolaire il y a beaucoup d'élèves qui ne s’investisse qu'un minimum dans leur apprentissage.

En 3eme années j'ai eu l'occasion d'avoir un projet sur les BNF et la translation de langage, j'ai trouvé ça très intéressant.
Malheureusement nous étions que 2 dans ma promo a être intéressés par ce sujet, les autres ne voyaient pas l’intérêt de le faire sous prétexte d'avoir le nb de crédit nécessaire pour passer à l'année supérieure.

je pense que l'intérêt des personnes commence quand ils n'ont pas le choix de maîtriser un sujet pour avancer dans leurs projets professionnels.

La vrai question c'est plutôt, les informaticiens sont-ils vraiment passionnés par leur travail?

Parce que j'ai l'impression que beaucoup se retrouve la par dépit

[koala01]

Je n'y manque pas à chaque occasion en plus du troll sur les librairies

Où vois tu un troll

Je sais que mon prof a décidé de se remettre en question sur le sujet, vu qu'il l'a fait devant moi, et que je lui ai d'ailleurs indiqué l'ordre dans lequel j'envisagerais les choses si j'étais lui...

Bon, faut dire aussi que c'était un prof de cours du soir et que j'avais à peu près son age, ce qui est généralement de nature à permettre des relations différentes de celles qui existent entre des profs de faq ou de collège et leurs élèves

Je ne suis pas tout à fait d'accord.
Il y a peut-être peu de jobs pour faire du C toute la journée, mais il y en a déjà plus dans d'autres domaines qui demande à faire du C de temps en temps. Par exemple dans le domaine de l'électronique, de l'instrumentation, etc... Où le C reste sans équivalent pour faire fonctionner un micro-contrôleur (à moins de devoir travailler avec le BASIC du constructeur ou pire, en ASM).
Je ne m'avance pas davantage pour le C++ qui est plus éloigné de mon cœur de métier, je ne suis pas renseigné.

C'est bien pour cela que je parlais de "métier de niche"...

Soit on trouve "la niche" dans laquelle il est encore utilisé, soit, il n'y a vraiment que l'envie, à titre perso, pour un projet perso, qui t'incitera à t'intéresser à C.

Si tu as, à titre plus ou moins perso, simplement l'idée de t'intéresser "au développement de manière générale", l'apprentissage de C++ t'apportera une courbe d'apprentissage plus facile

[Luc Hermitte]

a- Par contre, il y a une chose qui m'a fait sauter au plafond [...] "std::shared_ptr pour les pointeurs, etc." [...] ref croisée [...] unique_ptr

b- Pour le reste, c'est marrant de constater qu'a chaque fois que quelqu'un sort l'objet, il sort des principes dans tous les sens, et des acronymes à coucher dehors dont je n'ai jamais entendu parler.
Liskov? Euh, j'ai tenté de lire le truc sur wikipedia, j'ai rien compris... SOLID? J'ai eu la flemme de chercher un mot de ce genre... trop de risques de devoir fouiller 3H.
c- Cela dis, j'en connais quand même quelques uns aussi: GRASP, et le truc qui dit que si on implémente un Ctor, il faut faire d'autres implémentations... me rappelle jamais le nom...

a- Nous sommes entièrement d'accord. Maintenant, le but de cet article n'est pas forcément d'être exact à 100% mais de montrer pourquoi les a priori historiques doivent être balayés.

b- Si tu sais qu'il ne faut pas dériver un carré d'un rectangle (ou le contraire ; et même chose entre cercle et ellipse) , ou une liste triée d'une liste alors tu connais déjà le Principe de Substitution de Liskov (LSP). Mais comme pour les patterns, il est bon de disposer d'un terme qui identifie rapidement un principe. Dire "LSP" est toujours plus efficace que "le truc qui dit faut pas hériter quand la substituabilité ne peut être assurée en toute circonstance". On ne s'en sort pas sinon.
Plutôt que wikipédia, tu peux jeter un oeil dans nos archives (longues discussions sur le sujet avec exemples à l'appuie) ou la FAQ.

c- De nouveau la FAQ est ton amie. Celle de dvpz est une des plus riche que tu trouveras sur le net, toute langue confondue -- ce n'est plus une FAQ AMA, mais c'est une autre histoire. Cela s'appelle la Forme Canonique Othodoxe de Coplien, qui ne s'applique qu'aux classes à sémantique de valeur, et qui est une forme historique (la version modernisé qui prend en compte le RAII s'appelle Rule Of Big Two) -- et l'arrivé du C++11 change légèrement la donne encore (il y a tout un article en ligne sur le sujet). Dans le cas des entités, ce n'est plus définir qu'il faut dire mais spécifier (pour interdire copie et affectation).

[koala01]

Je ne doute pas de ça, j'ai pu voir qlq une de tes interventions que je les trouve toujours intéressantes et constructives, mais je n'ai pas encore eu l'occasion de tomber la dessus, maintenant c'est fait ^^

Quelque part, c'est la preuve que la répétition est souvent le meilleur moyen de transmettre la connaissance

On critique souvent le système scolaire et ses acteurs, mais il ne faut pas négliger la sensibilité et l'intérêt des étudiants.

Attention, je ne critique l'enseignant que pour ce qui dépend exclusivement de lui: pour transmettre correctement le savoir, il faut que le savoir soit juste, et donc, il faut que l'enseignement fasse une sorte de "veille technique" pour rester à jour.

Certains enseignants le font et donnent des cours intéressants, d'autres refusent de se remettre en question et continuent à donner les mêmes cours qu'il y a dix ans.

En informatique, dix ans, c'est long

Et quand, par malheur, tu tombes sur un prof de la deuxième catégorie, il ne faut pas s'étonner si le cours prend une mauvaise direction

Je suis actuellement dans le passage du milieu scolaire au milieu pro et je peux dire qu'au-delà du système scolaire il y a beaucoup d'élèves qui ne s’investisse qu'un minimum dans leur apprentissage.

En 3eme années j'ai eu l'occasion d'avoir un projet sur les BNF et la translation de langage, j'ai trouvé ça très intéressant.
Malheureusement nous étions que 2 dans ma promo a être intéressés par ce sujet, les autres ne voyaient pas l’intérêt de le faire sous prétexte d'avoir le nb de crédit nécessaire pour passer à l'année supérieure.

je pense que l'intérêt des personnes commence quand ils n'ont pas le choix de maîtriser un sujet pour avancer dans leurs projets professionnels.

La vrai question c'est plutôt, les informaticiens sont-ils vraiment passionnés par leur travail?

Parce que j'ai l'impression que beaucoup se retrouve la par dépit

C'est bel et bien un autre problème, pas exclusivement réservé à l'enseignement mais très certainement exacerbé dans celui ci étant donné la culture du "un bac + xxx à tout prix".

Il est clair que sans qu'il y ait un minimum de motivation, il est difficile de faire évoluer les choses.

Je ne peux donc parler que pour moi, mais je suis un passionné et j'adore avoir à m'intéresser à de nouvelles choses.

J'ai aussi eu "la chance" de passer par une filière qui assure sans doute un peu plus la motivation des étudiants, vu que j'ai fait mes études en cours du soir.

Pour les autres, que chacun se juge lui-même en son âme et conscience

[jouana]

Attention, je ne critique l'enseignant que pour ce qui dépend exclusivement de lui

Désolé le but n'était pas que tu te sente attaqué par mes propos, ce n'était pas une remarque mais plus un constat sur ce que l'on peux trouver sur divers post.

b- Pour le reste, c'est marrant de constater qu'a chaque fois que quelqu'un sort l'objet, il sort des principes dans tous les sens, et des acronymes à coucher dehors dont je n'ai jamais entendu parler.
Liskov? Euh, j'ai tenté de lire le truc sur wikipedia, j'ai rien compris... SOLID? J'ai eu la flemme de chercher un mot de ce genre... trop de risques de devoir fouiller 3H.

Je trouve ton approche un peu fermé, pour quelqu'un qui se dit autodidacte ton approche sur ce coup est un peu à contre sens.

Tout est bon à prendre pour évoluer dans notre art

Sinon pour revenir à l’apprentissage je pense que les stages sont une chose très importante dans ce processus.

Elle offre un position plus ou moins facile et si on à la chance de travailler avec des personnes compétentes qui aimes partager leur savoir et leurs expériences, cela permet d'avoir une belle expérience avant de rentrer dans le milieu professionnel, même si elle est petites.

[koala01]

Je tiens à préciser une chose concernant mon apparent extrémisme concernant les différents principes qui jalonnent le développement en général.

J'ai commencé le développement de manière strictement autodidacte, et même lorsque j'ai entrepris des études spécifiques, je n'ai jamais entendu parler, dans mes cours du moins, de la plupart de ces principes (à part le principe de responsabilité unique).

Et comme tout le monde, je me suis retrouvé "empêtré" dans certains projets qu'il m'était devenu impossible de faire évoluer dans le sens que je voulais.

A force d'"errer sur le forum", j'ai entendu parler de Liskov, et ca m'a intrigué.

En reprenant mes projets devenus impossibles à faire évoluer, j'ai pu me rendre compte qu'une bonne partie des problèmes d'évolution auxquels j'étais confronté venait du non respect de ce principe.

De LSP à SOLID et à déméter, il n'y a qu'un pas, qui fut, encore une fois, franchi grâce au forum.

Je me suis alors rendu compte que tous les problèmes d'évolutivité auxquels j'étais confronté avait pour origine le non respect de l'un de ces principes.

Depuis, j'avoue que je ne manque aucune occasion d'insister sur ces principes, uniquement parce que je sais ce que leur respect m'a apporté.

Maintenant, soyez sur d'une chose: je ne pourrai jamais faire plus que de vous inciter instamment à les respecter, libre à vous de le faire... ou non.

Mais, si vous décidez de ne pas les respecter, il ne faudra pas venir pleurer chez moi

[koala01]

Désolé le but n'était pas que tu te sente attaqué par mes propos, ce n'était pas une remarque mais plus un constat sur ce que l'on peux trouver sur divers post.

N'étant pas enseignant, je ne me sentais absolument pas attaqué, j'ai juste estimé qu'il fallait préciser ma pensée

[germinolegrand]

Si tu te balades dans les rues de paris et que tu décides de ne pas lire une carte, c'est pas pour autant que tu es dans un "vaste univers à peine effleuré, inexploré", non ?

L'univers s'arrête-t-il à Paris ? Peut-on prétendre connaître la carte complète de l'univers au point de pouvoir en faire une analogie si réductrice ?

Ne croyez-vous pas que depuis le temps qu'on m'en parle (et que koala me bassine avec, pour l'ignorer ce serait vraiment difficile ), je ne me suis pas renseigné ? Au contraire, je lis les articles et les pavés (sic!) de ce cher koala ^^.

Je ne suis tout simplement pas séduit, je n'aime pas, c'est tout. Et pour répondre à ce qui a été dit plus haut, croire que ce qui nous convient devrait convenir à tout le monde me semble être une éthique assez peu productrice.

Je ne vais certainement pas tenter de convaincre qui que ce soit que SOLID est mauvais : ce n'est pas le cas, koala l'a largement démontré et j'en suis également convaincu.

Conseiller, argumenter, présenter des approches, cela me semble indispensable. Imposer, à part dégoûter le lecteur d'entrée en lui faisant croire que le développeur n'est là que pour produire du code (je n'ai pas voulu employer d'expression plus vulgaire ) que n'importe qui d'autre aurait pu produire, cela me parait déjà plus critiquable.

Aussi, j'attends avec impatience le prochain "pavé" de ce fil de discussion tout à fait intéressant !

[gbdivers]

Tête de mule. Bon, tant que tu critiques pas Qt, je te pardonne...

[koala01]

Ne croyez-vous pas que depuis le temps qu'on m'en parle (et que koala me bassine avec, pour l'ignorer ce serait vraiment difficile ), je ne me suis pas renseigné ? Au contraire, je lis les articles et les pavés (sic!) de ce cher koala ^^.

Visiblement, pas assez longtemps vu que tu n'es toujours pas convaincu

Je ne suis tout simplement pas séduit, je n'aime pas, c'est tout. Et pour répondre à ce qui a été dit plus haut, croire que ce qui nous convient devrait convenir à tout le monde me semble être une éthique assez peu productrice.

Qu'est ce qui fait que tu n'es pas séduit le manque de liberté apparent des principes énoncés

Encore une fois, n'hésites pas à me présenter un ou des principes qui puissent être suivi "selon l'envie" ou de "manière assouplie" en apportant le même degré de certitude, et je serai le premier à changer mon fusil d'épaule.

Mais je ne transigerai jamais sur le degré de certitude

Je ne vais certainement pas tenter de convaincre qui que ce soit que SOLID est mauvais : ce n'est pas le cas, koala l'a largement démontré et j'en suis également convaincu.

Conseiller, argumenter, présenter des approches, cela me semble indispensable. Imposer, à part dégoûter le lecteur d'entrée en lui faisant croire que le développeur n'est là que pour produire du code (je n'ai pas voulu employer d'expression plus vulgaire ) que n'importe qui d'autre aurait pu produire, cela me parait déjà plus critiquable.

Aussi, j'attends avec impatience le prochain "pavé" de ce fil de discussion tout à fait intéressant !

Il semble, de toutes manières, impossible d'imposer quoi que ce soit sur un forum

Nous sommes tous bien conscient que, quoi que l'on dise, quoi que l'on fasse, celui qui vient poser une question sur le forum reste le seul maitre de ce qu'il fait des réponses qu'il reçoit.

Mais, encore une fois, si tu décides de ne pas écouter mes conseils, il ne servira à rien de venir pleurer chez moi, tout simplement

[Freem]

Tu n'es pas le premier à faire la remarque sur shared_ptr, je vais donc préciser un point : je n'ai pas dit (bien qu'en me relisant, ce n'est pas être pas clair) qu'il fallait utiliser shared_ptr pour les pointeurs

En effet, l'association me semble un peu trop rapidement faite par quelqu'un qui ne connaîtrait pas ces outils.

Même remarque (un peu) que pour germinolegrand : est-ce que tu penses que ne pas les connaître fait de toi un meilleur développeur ou cela ne change rien ?

Je dis simplement que connaître la (longue, très longue, tu en conviendras j'espère) liste des acronymes et autres principes ne me semble pas vital.

Tiens, pour le coup, rien que pour ne pas répondre à côté de la plaque, j'ai été voir.
3 liens préliminaires:
https://duckduckgo.com/?q=S.O.L.I.D&kp=1&kl=fr-fr
https://en.wikipedia.org/wiki/SOLID_...riented_design)
http://fr.wikipedia.org/wiki/Patron_...#Patrons_GRASP

1er constat, grâce à mon pote le canard, j'ai trouvé plus vite que je ne l'aurais cru. Grâce aux '.' je suppose.
2nd constat: sans connaître SOLID, je l'appliquais, car j'ai l'impression que c'est juste une grosse paraphrase de GRASP. Ou le contraire, pour ce que ça m'importe...

Ce que j'essayais de dire, c'est que d'estimer que connaître chaque élément de cette prolifération permet à quelqu'un d'être un bon dev est malsain.
Je suis aussi du genre à faire confiance à ceux qui montrent qu'ils s'y connaissent, mais j'ai aussi l'impression qu'en science de l'information, il y à beaucoup de copier/coller/renommer. Et comme le savent la plupart des dev, le copier/coller/renommer, c'est mal: ça embrouille l'esprit de celui qui passe derrière.

J'espère avoir clarifiée ma position

Donc pour répondre à la question est-on un mauvais développeur si on ne connait pas ces principes, je crois que celui qui est entré dans la démarche de réflexion nécessaire pour comprendre ces principes à une plus grande maîtrise de ce qu'il fait que celui qui rejette en bloc ces principes (au moins, celui qui respecte ces principes sans les comprendre n'aura pas cette maîtrise, mais il prendra aussi moins de risques)

Ceux qui appliquent un principe sans le comprendre mènent à la création d'anti-pattern, ou de mauvais usage de DP.
Ceux qui les rejettent en bloc pondent souvent du code dégueu qui tombe en marche.
J'ambitionne de ne faire partie ni des uns, ni des autres.
Et ce qui es sûr, c'est que ce n'est que l'expérience qui m'a fait comprendre des principes que l'on m'a enseigné (genre mettre au maximum les membres en private, quitte à y coller des accesseurs) parce qu'autant on peut faire admettre à quelqu'un qui n'a jamais touchée une ligne de code qu'il faut faire ainsi et c'est tout, autant à un autodidacte c'est moins évident.
D'ailleurs, rien que pour la POO, je considère avoir compris ce que c'est que bien après avoir arrêté l'école. Probablement en découvrant Linux et les outils en ligne de commande, d'ailleurs.

On peut se poser la question plus générale à quelle moment faut il apprendre ces principes. Pour moi, ils doivent faire partie intégrante de l'apprentissage de la programmation en C++

Je suis d'accord. Quelqu'un à fait la remarque que l'enseignement du développement logiciel prend les choses à l'inverse du développement scientifique habituel.
Quand je me rappelle mon lycée, et mes 2 ans de STI électronique, je constate qu'on avait 2 matières très proches (ou on faisait presque pareil):
_ physique appliquée
_ électronique (je passe le fait qu'il y avait des sous-matière dans celle-ci)

La première concernait la théorie, et n'avait que peu, voire pas, d'application pratique réelle. Je la comparerait à l'apprentissage des divers principes.
La seconde, dans laquelle tout le monde était plus doué d'ailleurs, concernait la pratique, la prise en compte des paramètres internes des composants.
On peut considérer qu'il s'agissait d'apprendre la syntaxe d'un langage.
La première était nécessaire à la seconde, et la seconde boostait les étudiants sur la première.

Je pense qu'avoir ces 2 enseignements en parallèle était une bonne chose. Et qu'on devrait faire pareil en développement, mais cesser de considérer que ces principes et ces théories parfaites doivent se retrouver mêlés au langage. Parce que c'est faux: il faut d'ailleurs les appliquer à tout programme utilisant le paradigme objet (pour ces principes précis. D'autres s'appliquent à d'autres paradigmes, j'imagine), peu importe le langage.

Et pourtant, si tu fais une recherche sur le forum

Pour être franc, je passe le plus clair de mon temps de DVP.com sur la section actualité, et il m'arrive quand je me frotte à un concept d'aller voir les faq & co, mais c'est plutôt peu fréquent. En général, c'est duckduckgo+implémentation de PoC. Et si ça rate, malgré la flopée de blogs&co, alors je me tourne vers le forum. C'est rare quand même, internet (et SO) étant une base de taille...

Ceci dit, il faut malgré tout garder en tête le fait que C++ est, décidément, un langage particulièrement complexe.

Je considère habituellement qu'il s'agit de l'un des plus complexes des langages que je pense les plus utilisés.
Je considère aussi que sa complexité à différents niveaux: il est simple d'utiliser des choses écrites par d'autres pour un programme simple, moyennement complexe d'écrire ses propres outils et très complexe d'écrire des outils destinés aux autres. Le dernier niveau ayant une tendance à mélanger les 3 paradigmes du langages et donc de nécessiter une vraie maîtrise d'une grosse part du langage ET de la conception logicielle.

J'en fais maintenant à temps plein (ou peu s'en faut) depuis quelques années, et je ne suis pas encore tout à fait sur d'en avoir fait le tour

Je suis jaloux de ton poste

Mais comme pour les patterns, il est bon de disposer d'un terme qui identifie rapidement un principe.
[...]
Cela s'appelle la Forme Canonique Othodoxe de Coplien
[...]et l'arrivé du C++11 change légèrement la donne encore (il y a tout un article en ligne sur le sujet). Dans le cas des entités, ce n'est plus définir qu'il faut dire mais spécifier (pour interdire copie et affectation).

a: oui, je suis d'accord. Maintenant, quand je compare SOLID et GRASP, je les trouve si proches que mon esprit va avoir du mal à retenir les deux.
b: merci, le nom me manquais... A coucher dehors, il faut dire
c: il me semble avoir croisé cet article, et il fait partie de la liste de choses qu'il me reste à lire. De la longue liste...

[Squisqui]

Soit on trouve "la niche" dans laquelle il est encore utilisé, soit, il n'y a vraiment que l'envie, à titre perso, pour un projet perso, qui t'incitera à t'intéresser à C.

Si tu as, à titre plus ou moins perso, simplement l'idée de t'intéresser "au développement de manière générale", l'apprentissage de C++ t'apportera une courbe d'apprentissage plus facile

Je n'avais pas visualisé la chose sous cet aspect précis.

En effet, la science du développement logiciel m'intéresse beaucoup à titre personnel. Le C++ me tâte et risque fortement d'y passer pour un projet qui se profile avec un groupe d'amis.

[Freem]

Désolé pour le double post, mais flemme d'éditer mon dernier post.... ([edit]et en plus c'est pas un double post... pas mal celle-la[/edit])

Je tiens à préciser une chose concernant mon apparent extrémisme concernant les différents principes qui jalonnent le développement en général.

Le pire, c'est que je te plussoie...

Je ne les ai pas découverts sur le forum, perso, mais en constatant de moi-même que plus mon code est gros et long, moins j'arrive à le comprendre. J'ai mis cette constatation avec un vague souvenir des profs qui disaient de tout mettre en private et créer getter/setter pour le tout, j'ai erré sur le net, suis tombé sur les DP et GRASP, ait découvert CCCC (par l'intermédiare de C::B)...

Et paf, ça à fait des chocapic.
Le déclic, j'ai compris que
1) les profs de mes souvenirs appliquaient bêtement un principe et le rendaient ainsi caduque, rendant le code plus lourd à manipuler (bah oui, des setter et getter qui ne font que lire ou écrire sans traitement un membre, c'est pire que le mettre en public pour moi). et écrire.
2) la solution, c'est de considérer que le nom des variables interne n'a absolument pas à être connu. "getName()"? Mais quelle horreur! Le nom "name()" est bien meilleur, pour moi. C'est un getter dans le rôle, mais plus dans le nom. Et le setter, c'est "rename(std::string const&)", pas "setName(...)".
3) conséquence de 2, j'ai compris que nombre de getter/setter peuvent juste renvoyer un résultat bâti en direct, sans nécessiter de stockage.
4) ces codes sont plus simples à écrire et maintenir si l'on évite de faire plus d'une chose par méthode/fonction. Conséquence: des fonctions de 20 lignes en moyenne.
5) quand on commence à discerner des jeux de fonctions utilisant des jeux de membres, c'est qu'il y a une classe à créer.

C'est malheureux, mais si j'appliquais bêtement le bourrage de crâne auquel j'ai assisté, plutôt que de merder à pondre du code dégueu un temps, mon code serait encore plus bourré d'anti-pattern et de doctrine qu'il ne l'est actuellement. Bon, ok, a l'heure actuelle, il n'est pas trop endoctriné, par contre je ne parierais pas au sujet des anti-pattern.