Apprendre correctement le C++

Parce que c'est mieux quand c'est bien fait

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour, Bonsoir :-)

Avant toute chose je tiens à préciser que je suis nouveau sur ce site (qu'au passage je trouve excellent), je m'en remet donc à votre clémence si je fais une bourde, du genre poster dans la mauvaise section.

Si je poste ce message aujourd'hui, c'est pour recueillir l'avis de programmeurs sur la question "Comment apprendre à bien programmer?". Réponse évidente me direz-vous? Pas tant que ça. Je m'explique:

Cela-fait un an que j'apprend le C++ (à comprendre, un an depuis le premier Hello World). Etant encore au lycée, j'ai débuté mon apprentissage à l'aide du tutoriel du feu siteduzero. Une fois celui-ci terminé, j'ai continué à progresser grâce à d'autres sites (je pense notamment à developpez.com, stackoverflow…). Bref, au petit bonheur la chance.

Et c'est bien ça le problème. Il existe tant de références, de blogs, de sites proposant des tutoriels de programmation que je ne sais plus vers quoi me tourner. Entre les différents standards du langage (C++98 / C++11), les différents points de vue sur les bonnes pratiques, dur de s'y retrouver..

De fait, j'ai souvent l'impression de mal programmer. Loin de moi l'envie de cracher sur mes codes, mais quand j'entend parler d'architecture, de design ou de conception et que je vois mes codes à côté, cela me trouble.

C'est pour ça que j'ouvre cette discussion, pour pouvoir en parler avec des gens plus expérimentés que moi sur ces questions (assez théoriques il faut bien le dire ;-) ), des gens qui s'y connaissent.

  • La formation autodidacte en programmation est elle selon vous une bonne idée?
  • Si oui, comment vous y prendriez-vous, s'il vous était nécessaire de reprendre l'apprentissage de la programmation?
  • Quelle(s) bibliothèque(s) conseillez vous pour compléter la STL?
  • De manière concrète, qu'est ce qu'un programme avec une bonne architecture?
  • Y'a t'il des pratiques mauvaises quel que soit le programme? Exemple : "Il ne faut jamais utiliser de pointeurs nus." Vrai ou Faux?
  • Au contraire, y'a t'il de bonnes habitudes à prendre pour programmer 'correctement'?
  • (bonus) Ai-je le droit de vous poser plus de questions? :-)

Je suis conscient que la manière de programmer est propre à chacun, mais je préfère éliminer les fausses bonnes idées une bonne fois pour toutes!

Je remercie par avance ceux & celles qui prendront le temps de me répondre :-P

Deathekirl'

Édité par firm1

Un jour j'irai vivre en Théorie, car en théorie tout se passe bien.

+0 -0

Cette réponse a aidé l'auteur du sujet

Coucou !

Je vais essayer de te répondre un peu point par point.

En ce qui concerne la formation en autodidacte, je suis convaincu que c'est la meilleure façon d'apprendre à programmer. Mais pour moi cela passe plus par de la pratique (beaucoup de pratique !), plutôt que de lire des blogs, cours ou tutoriels en s'attendant à ce qu'ils te fournissent une réponse pré-mâchée à toutes tes questions. L'outil réellement indispensable c'est bien sûr les documentations des langages et bibliothèques que tu utilises, et qu'il est très important de savoir lire correctement.

En ce qui concerne le procédé d'apprentissage, il ne faut pas penser "reprendre un apprentissage du début", en tout cas je ne pense pas. J'ai fait mes débuts en QBasic, un langage qui a plein de défauts, puis j'ai fait du PHP, c'était clairement mieux mais retrospectivement je n'en suis pas non plus si fier. J'ai ensuite évolué vers C, C++, puis maintenant OCaml. Je ne regrette absolument pas mes expériences passées avec des langages et outils pour le moins critiquables, au contraire je considère qu'ils font partie intégrante de ma formation et sans eux je ne serai jamais arrivé là où j'en suis maintenant.

En ce qui concerne le style de programmation, c'est vraiment très subjectif. Tant que tu es seul à programmer sur un projet, tu peux utiliser le style qui te convient - et c'est aussi après de nombreuses expériences que tu commenceras à mieux connaître tes outils et à pouvoir faire toi-même des décisions qui te paraissent solides.

Dès que tu dois travailler avec d'autres ça devient important de discuter et de se mettre d'accord sur les pratiques tolérées, mais évidemment il faut s'attendre à ce que tout le monde ait des avis un peu différents. Puisqu'il n'y a pas une seule bonne manière de programmer dans tel ou tel langage, je ne pense pas qu'il n'y ait non plus un cours/tutoriel qui puisse donner une réponse absolue à toutes les questions de style de programmation.

Pour ce qui est de généralités sur l'architecture de gros programme, encore une fois c'est par la pratique que tu peux en avoir une bonne vision. Pour ma part je me suis lancé plusieurs fois dans des projets clairement irréalisables, et même si ceux-ci n'ont jamais abouti je considère qu'ils ont été une expérience très formatrice en terme d'être capable de trouver la bonne architecture pour un gros projet.

Pour ce qui est des bibliothèques à utiliser en C++, ça dépend clairement des applications. De mon point de vue la STL reste néanmoins incontournable pour résoudre des problèmes d'algorithmique. Évidemment pour coder une application "généraliste" (typiquement avec une GUI) il faut d'autres outils. Je ne m'en suis jamais vraiment servi, mais on parle beaucoup de Qt, de Boost, etc.

Pour ce qui est des pointeurs nulls, je ne suis pas contre s'ils sont bien utilisés (mettre un petit commentaire pour spécifier ce que fait une fonction si son argument est un pointeur nul, par exemple). Évidemment d'autres personnes ne seront pas forcément du même avis.

J'espère t'avoir aidé ! N'hésite pas si tu as d'autres questions ;-)

À bientôt !

(。◕‿‿◕。)

+1 -0

Le post d'Alex est très bon, mais il y a une mésentente sur "pointeur nul" ou "pointeur nu". Si par le second tu parles de *T par opposition à blabla_ptr<T> (les "smart pointers"), alors la réponse est différente. Je ne connais pas bien C++ mais il me semble que se forcer à utiliser les smart pointers a l'avantage de te forcer à réfléchir à qui possède la mémoire, et que c'est donc une bonne discipline de s'y tenir. Une fois que tu as l'habitude (pour éviter les coûts de shared_ptr), ou pour communiquer avec des bibliothèques qui ne les utilisent pas, tu peux retourner aux pointeurs nus, mais c'est difficile à faire sans se planter quand on ne sait pas déjà raisonner sur la possession mémoire.

(Les gens qui font du C diront que ce n'est pas nécessaire, mais c'est subtil: soit ils savent déjà les utiliser (consciemment ou non), et c'est entre autres pour cela qu'ils font du C correctement, soit ils ne savent pas s'en servir et ils font du C incorrect.)

J'appuie sur la pratique : il faut coder, montrer ce que tu as fait sur des forums, et laisser les gens le critiquer. Ou alors (c'est complémentaire) regarder ce que font les autres, se demander pourquoi on trouve ça moche, et apprendre à critiquer – de façon constructive. Avec un peu d'habitude tu sauras critiquer ton code tout seul, c'est ça la "conception".

Édité par gasche

+2 -0

Cette réponse a aidé l'auteur du sujet

  • Si oui, comment vous y prendriez-vous, s'il vous était nécessaire de reprendre l'apprentissage de la programmation?

Je ne commencerais probablement pas par le C++. Le langage a tellement de fonctionnalité, qu'on se retrouve avec des redondances et des complexités syntaxiques. Cependant je n'ai pas assez de recul pour proposer une alternative.

Comme tu as commencé depuis un an et vu l'intitulé de ton sujet, je suppose que ta question est plutôt l’apprentissage plus spécifiquement du C++. Dans ce cas j'aurais tendance à te conseiller d'aller sur un bouquin (même pré C++11/C++14) dès que tu as des bases, même fébriles.

J'aime bien le style Meyers ou Sutter, c'est à dire un sélection d'un ensemble de problématiques adressées une à une. Des bases sont nécessaires pour comprendre les problématiques et les résolutions permettent d'aller plus loin dans le langage et de solidifier les bases.

  • Quelle(s) bibliothèque(s) conseillez vous pour compléter la STL?

Boost, tout du moins la partie headers only, boost est un ensemble de bibliothèques répondant à divers objetifs. Pour débuter, c'est boost.range qui me semble le plus intéressant.

  • De manière concrète, qu'est ce qu'un programme avec une bonne architecture?

Il me semble plus simple de te donner des critères concrets qui montrent que quelque chose ne va pas. Si lorsque tu dois ajouter une nouvelle fonctionnalité ou corriger un bug, tu dois refaire une part importante du code existant, c'est que quelque chose ne va pas. Un autre exemple est lorsque ton code fait ce que le compilateur pourrait faire tout seul.

  • Y'a t'il des pratiques mauvaises quel que soit le programme? Exemple : "Il ne faut jamais utiliser de pointeurs nus." Vrai ou Faux?

Quelques soit le programme, non probablement pas.

  • Au contraire, y'a t'il de bonnes habitudes à prendre pour programmer 'correctement'?

Il est plus important de comprendre pourquoi quelqu'un te conseil de faire d'un façon et pas d'une autre, de manière à savoir ce qu'il sera le mieux de faire quand une situation similaire se reproduira.

@gasche: Il y a une différence entre le C et le C++ qui a une impacte sur l'utilisation de pointeurs nus, en C++ le nombre de chemins d’exécution explose plus vite qu'en C (en cause des exceptions entre autres) ce qui rend très vite quasiment impossible la gestion manuel de la mémoire. Le pointeur intelligent que tu cites, shared_ptr, a en effet un coût, par contre on a un autre pointeur intelligent, unique_ptr, dont le coût est quasiment nul et donc idéal si le comptage de référence n'est pas nécessaire.

Édité par Freedom

Cette réponse a aidé l'auteur du sujet

La formation autodidacte en programmation est elle selon vous une bonne idée?

Quand on voit que ceux qui ont eu des cours C++ dans le cadre scolaire dire qu'ils ont tout appris par eux même à côté, on comprend vite le problème. Donc oui, tu peux apprendre par toi même. Le principal est de pratiquer, de préférence dans une équipe, avec des développeurs seniors qui review ton code.

Si oui, comment vous y prendriez-vous, s'il vous était nécessaire de reprendre l'apprentissage de la programmation?

Lire, pratiquer. Ca ne sert à rien de reprendre à zéro, il faut que tu identifies tes lacunes et bosse dessus.

Quelle(s) bibliothèque(s) conseillez vous pour compléter la STL?

Boost et Qt

De manière concrète, qu'est ce qu'un programme avec une bonne architecture?

Un programme évolutif, maintenable, fiable, etc. Une "bonne" architecture n'est pas juste pour faire joli. Une "bonne" architecture est celle qui te permet d'apporter un maximum de garanties sur la qualité de ton logiciel (recherche "software quality").

En pratiques, il y a des "aides" pour atteindre ces objectifs de qualités. Par exemple les principes de programmation (SOLID, à lire : "Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)" ) ou les design pattern. L'important n'est pas de les connaître par coeur (ie bêtement), mais de comprendre ce qui peut arriver si on ne les respecte pas, l'approche utiliser pour éviter les problèmes, les différentes approches possibles et leurs limitations, etc.

Y'a t'il des pratiques mauvaises quel que soit le programme? Exemple : "Il ne faut jamais utiliser de pointeurs nus." Vrai ou Faux?

Vrai. Sauf quand tu les utilises :)

Il faut bien comprendre qu'aucune "règle" n'est inviolable (en programmation). Par exemple, les débutants ne connaissent pas les problèmes posés par les pointeurs nus et pensent les utiliser sans faire d'erreur, ce qui n'est pas souvent le cas. Dans ce cas, la règle "pas de pointeurs nus" permet d'éviter ces erreurs. Surtout que les débutants n'auront pas de problématiques qui nécessitent l'utilisation des pointeurs nus (si c'est le cas, c'est qu'ils se lancent dans des problèmes hors de leur portée, ils vont généralement dans le mur).

Même plus tard, les pointeurs nus sont dangereux à utiliser. Un code sécurisé va utiliser le RAII pour sécuriser le code. Comme la STL propose déjà de nombreuses classe RAII (vector, string, smart ptr, etc) et que l'on aime pas réinventer ce qui existe déjà, on les utilise. C'est uniquement pour des cas d'utilisations spécifiques que l'on utilisera des pointeurs nus (wrapper vers une lib C, implémentation d'un RAII, etc)

Donc oui, il y a de mauvaises pratiques. Plus précisément, il y a des pratiques qui sont mauvaises dans un contexte donné, parce que pas sécurisée alors qu'il est possible d'écrire un code sécurisé équivalent, parce que pas correctement identifié comme étant une pratique dangereuse (et donc qu'un autre développeur pourra venir sur le code problématique et ne pas voir qu'il y a un danger potentiel)

Au contraire, y'a t'il de bonnes habitudes à prendre pour programmer 'correctement'?

En vrac. Lire le livre que j'ai cité ;) Egalement "Professional C++" et bien d'autres (cf Sélection de livres). Faire relire son code par un senior. Faire de l'intégration continue (gestionnaire de versions, tests unitaires, automatiser les tâches, etc)

Il existe tant de références, de blogs, de sites proposant des tutoriels de programmation que je ne sais plus vers quoi me tourner.

Concernant les blogs. Il est bien d'en suivre quelques uns (au moins http://isocpp.org/ je pense), pour avoir des idée des techniques de programmation lorsque l'on tombe sur un problème dans le futur. Mais le plus formateur est probablement de faire des recherches lorsque l'on a une problématique et lire suffisamment de sources d'informations différentes (blogs, articles, doc, etc) pour avoir une vision globale des solutions possibles (et bien comprendre les limites et avantages de chaque approche)

En tout cas, ces problématiques de conception sont des choses que j'essaie d'intégrer dans le cours de C++ que je suis entrain de rédiger (si ça t'intéresse : C++ moderne)

+1 -0
Auteur du sujet

Evidemment qu'il est presque impossible d'apprendre en ne faisant que lire de la théorie!

Depuis le début de mon apprentissage, j'ai dû réaliser une trentaine de projets différents, surtout pour m'initier puis m'améliorer dans l'utilisation d'une bibliothèque (Qt, SDL, SFML…) et quelques applications concrètes.

C'est justement à force d'accumuler ce genre de projets que je me suis rendu compte que je partais droit dans le mur: le projet qui devient inmaintenable rapidement, les bugs qui s'enchaînent, les problèmes de conception qui apparaissent en évidence.

plutôt que de lire des blogs, cours ou tutoriels en s'attendant à ce qu'ils te fournissent une réponse pré-mâchée à toutes tes questions. L'outil réellement indispensable c'est bien sûr les documentations des langages et bibliothèques que tu utilises, et qu'il est très important de savoir lire correctement.

Je suis conscient du côté formateur de la pratique, et du fait qu'il n'existe pas de formule magique pour tout connaître. Le problème ne vient pas de la compréhension des notions & du langage, mais plutôt de leur utilisation au sein d'un gros projet.

J'appuie sur la pratique : il faut coder, montrer ce que tu as fait sur des forums, et laisser les gens le critiquer. Ou alors (c'est complémentaire) regarder ce que font les autres, se demander pourquoi on trouve ça moche, et apprendre à critiquer – de façon constructive. Avec un peu d'habitude tu sauras critiquer ton code tout seul, c'est ça la "conception".

Je suis un peu mal à l'aise à l'idée de poster un projet entier sur un forum. Même si, comme tu le dis (et je pense comme toi) c'est un bon moyen d'obtenir des critiques & d'avoir d'autres regards sur sa conception, les forums me semblent plutôt faits pour répondre à des problèmes isolés, non pour analyser des codes sources entiers. Me trompe-je?

EDIT: J'ai à peine le temps de poster que de nouvelles réponses arrivent… Vous êtes formidables, merci :-)

Le principal est de pratiquer, de préférence dans une équipe, avec des développeurs seniors qui review ton code.

J'aimerais bien! Actuellement, je suis le seul qui lit mes codes, et je n'ai donc pas d'avis de "senior". Mais il me semble difficile d'en avoir un sans faire partie d'une équipe, et difficile de faire partie d'une équipe quand on est débutant (sauf cas IRL, mais les lycéens programmeurs ne sont pas monnaie courante ^^)

Dans ce cas j'aurais tendance à te conseiller d'aller sur un bouquin (même pré C++11/C++14) dès que tu as des bases, même fébriles. Lire le livre que j'ai cité ;) Egalement "Professional C++" et bien d'autres (cf Sélection de livres)

Ça tombe bien, j'adore lire :-P.

Faire de l'intégration continue (gestionnaire de versions, tests unitaires, automatiser les tâches, etc)

Qu'est ce que l'intégration continue (et les tests unitaires, pendant qu'on y est)?

En tout cas, ces problématiques de conception sont des choses que j'essaie d'intégrer dans le cours de C++ que je suis entrain de rédiger (si ça t'intéresse : C++ moderne)

J'irait jeter un oeil, ça m'a l'air super intéressant ;).

Édité par Deathekirl

Un jour j'irai vivre en Théorie, car en théorie tout se passe bien.

+0 -0

(Les gens qui font du C diront que ce n'est pas nécessaire, mais c'est subtil: soit ils savent déjà les utiliser (consciemment ou non), et c'est entre autres pour cela qu'ils font du C correctement, soit ils ne savent pas s'en servir et ils font du C incorrect.)

gasche

C'est surtout qu'en C, il n'y a pas d'exceptions comme en C++ et qu'un code correcte en C ne l'ai pas en C++. Cela fait justement parti des risques d'erreurs que l'on ne voit pas directement

Je suis un peu mal à l'aise à l'idée de poster un projet entier sur un forum. Même si, comme tu le dis (et je pense comme toi) c'est un bon moyen d'obtenir des critiques & d'avoir d'autres regards sur sa conception, les forums me semblent plutôt faits pour répondre à des problèmes isolés, non pour analyser des codes sources entiers. Me trompe-je?

Oui. Tu ne peux pas poster un projet complet sur le forum. Mais si tu mets ton projet sur github (par exemple) et il y a des forums pour présenter ses projets (sur ZdS, sur SdZ, sur Dvp, etc)

Édité par gbdivers

+0 -0
Auteur du sujet

Ah oui tiens, je n'avais pas vu cette section du forum de Zds!

On ne risque pas de me lyncher si je poste un projet non pas dans le but de le présenter, mais pour recueillir des avis sur sa conception?

Un jour j'irai vivre en Théorie, car en théorie tout se passe bien.

+0 -0
Staff

Cette réponse a aidé l'auteur du sujet

Je vais donner mon avis sur les questions un peu comme je peux :

La formation autodidacte en programmation est elle selon vous une bonne idée? Si oui, comment vous y prendriez-vous, s'il vous était nécessaire de reprendre l'apprentissage de la programmation?

Je ne vois pas trop de problème à ça. D'autant qu'ici ça doit être le cas pour la majorité des personnes. Cependant je pense que le C++ est un mauvais langage pour débuter. Il est beaucoup trop compliqué et possède tellement de subtilités qui font que je ne le conseillerais pas. Maintenant si tu es dessus, pourquoi pas mais je te conseillerais alors de faire du C++ moderne (c'est à dire au moins C++11). Mine de rien cette norme a fait beaucoup de bien.

Le plus gros problème est alors de trouver de bonnes ressources d'apprentissages. Il y a de trop nombreux cours qui te présentent le "C with class" plutôt que le C++. Un bon cours de C++ devrait te faire utiliser massivement la STL et reléguer l'utilisation des pointeurs très tard.

Ensuite il faut surtout pratiquer. C'est très important. Une autre bonne formation est de participer à des projets Open-Sources qui sont généralement bien architecturés et qui aident les nouveaux venu à se mettre dans le bain.

Quelle(s) bibliothèque(s) conseillez vous pour compléter la STL?

Boost qui sert de "stl++" (et d'ailleurs est l'anti-chambre de la stl, beaucoup de choses introduites dans la stl en c++11 ou 14 étaient présents dans Boost avant).

Si tu veux faire des interface graphique, QT mais je déconseille globalement Qt en dehors de la partie GUI.

Après il y a tout un tas de lib très bien mais specifique, ça dépend de ce que tu veux faire (je pense par exemple à Poco pour le réseau).

De manière concrète, qu'est ce qu'un programme avec une bonne architecture?

Ce n'est pas facile dans le cas général et très dépendant de ton application.

Y'a t'il des pratiques mauvaises quel que soit le programme? Exemple : "Il ne faut jamais utiliser de pointeurs nus." Vrai ou Faux?

Il ne faut jamais dire jamais mais normalement, surtout en C++11, tu ne devrais jamais utiliser les pointeurs nu a part dans des codes localisés et temporairement (par ex si tu fais un traitement sur une image, la fonction qui le fait peut utiliser des pointeurs pour des questions de perfs, mais son interface devrait prendre une référence ou un pointeur "intelligent". C'est d'autant plus vrai avec le C++11 qui rajoute les smart_ptr et les unique_ptr. D'ailleurs un bon code devrait surtout utilisé ces derniers. En effet les smart_ptr, lié au comptage de références, rendent ces ressources difficiles à maîtriser et tu peux te retrouver avec des cycles de références qui empêchent la libération de la mémoire. Les unique_ptr ne posent pas se problème : il y a toujours un et un seul propriétaire de la ressource. C'est clair net et précis, tu ne peux pas te tromper. La ressource est alors passer d'un objet à l'autre en fonction des besoin et tu évite les cas tordus.

Au contraire, y'a t'il de bonnes habitudes à prendre pour programmer 'correctement'?

Utiliser l'existant me semble la plus importante : il ne faut pas ré-inventer la roue. Tu as à ta disposition la STL et une myriade de libs très bien faite. Sauf si bien sûrs ton but est de te former sur certaines techniques mais ça c'est un cas particulier.

(bonus) Ai-je le droit de vous poser plus de questions? :-)

Vas y, le forum est fait pour ça

+1 -0

Le pointeur intelligent que tu cites, shared_ptr, a en effet un coût, par contre on a un autre pointeur intelligent, unique_ptr, dont le coût est quasiment nul et donc idéal si le comptage de référence n'est pas nécessaire.

Freedom

C'est d'autant plus vrai avec le C++11 qui rajoute les smart_ptr et les unique_ptr. D'ailleurs un bon code devrait surtout utiliser ces derniers. […] La ressource est passée d'un objet à l'autre en fonction des besoin et tu évite les cas tordus.

Kje

Oui enfin c'est bien comme idée mais en pratique, comme le sous-entend Freedom, il y a plein de situations où on a besoin de partager la possession des données. unique_ptr n'est utilisable que dans certains cas, ou alors on fait tout en passage par valeur, et adieu les performances.

+0 -0
Staff

Il reste les référence et/ou les weak_ptr. De toute façon je ne suis pas sur qu'un déréférencement de temps en temps soit si coûteux que ça pour 99% des applications. Ce qui me gène surtout avec les shared_ptr c'est pas tant le surcoût que la propriété de la ressource qui est indéfinie.

+0 -0
Auteur du sujet

Ok. Je me permet de faire une petite synthèse de vos réponses (hormis en ce qui concerne les pointeurs, je n'y comprend pas grand chose ^^ ):

  • De nos jours, il est plus judicieux d'apprendre et d'utiliser le C++ moderne (C++11)
  • STL + Boost permettent de couvrir la plupart des besoins tant qu'ils ne sont pas trop spécifiques (réseau, gui…)
  • Il faut de la pratique, de la pratique et encore de la pratique
  • Montrer ses codes pour obtenir des avis de seniors dessus est bénéfique pour à la longue éviter de refaire les mêmes erreurs
  • Il n'existe pas d'architecture parfaite & universelle, chaque projet est différent et a donc la sienne, la pratique permet de prendre du recul et d'arriver plus facilement à distinguer une bonne conception

Un jour j'irai vivre en Théorie, car en théorie tout se passe bien.

+0 -0

Je voudrais tout de même modérer un point sur l'auto-didacte. Il est vrai que la qualité des cours sur le C++ dans le milieu de l'enseignement n'est pas souvent à la hauteur des documents qu'on peut retrouver sur internet. En cela, il est plus intéressant de se tourner vers cette source que celle de l'enseignement.

Cependant, il y a quelque chose dans l'enseignement que tu retrouveras difficilement sur internet, c'est le mec derrière qui te note. En effet, il est AMHA nécessaire d'avoir une personne qui puisse critiquer ton code (dire que ceci est une convention, qu'on essaye d'éviter d'utiliser cela, qu'il est préférable d'architecturer ton code de cette manière, etc.). Ce point n'est pas incompatible avec l'auto-didacte puisque ici même, tu peux partager ton code et avoir des retours mais c'est cependant un aspect qu'on n'inclut pas souvent dans l'auto-didacte.

Face à toi même, tu auras du mal à avoir un esprit critique sur ce que tu viens de faire. Et considérer qu'il n'est pas nécessaire de poster ton code pour recevoir des critiques peut t'amener à avoir de mauvais automatismes. La structure du langage C++ à elle seule ne suffit pas à devenir un bon programmeur C++, il s'agit aussi d'acquérir de l'expérience par le biais des autres ;) ! Voilà.

Pas "indéfinie", mais "partagée". Même si unique_ptr force à réfléchir à qui possède la responsabilité d'un pointeur, on peut faire du n'importe quoi sur la gestion des responsabilités. 0 l'inverse, on peut avoir un politique très forte de gestion des responsabilités et utiliser shared_ptr (ou un pointeur nu)

C++ moderne (C++11)

Le C++ "moderne" est plus une façon de penser la conception des applications, cela ne se limite pas à une syntaxe spécifique du C++. Mais le C++11 (et le C++1y) aide à mieux penser cette conception

Cependant, il y a quelque chose dans l'enseignement que tu retrouveras difficilement sur internet, c'est le mec derrière qui te note. En effet, il est AMHA nécessaire d'avoir une personne qui puisse critiquer ton code (dire que ceci est une convention, qu'on essaye d'éviter d'utiliser cela, qu'il est préférable d'architecturer ton code de cette manière, etc.). Ce point n'est pas incompatible avec l'auto-didacte puisque ici même, tu peux partager ton code et avoir des retours mais c'est cependant un aspect qu'on n'inclut pas souvent dans l'auto-didacte.

Dans l'absolu, je suis d'accord. Pour apprendre, il faut aussi évaluer si on a correctement appris

Par contre, ce qui me gène, c'est que si le cours est mauvais, l'évaluation le sera probablement aussi. Quelqu'un qui n'a pas mis à jour ses connaissances aura de mauvaises pratiques et la transmettra à ses étudiants. Et si l'enseignant est un universitaire, il pourra (peut être) avoir une vision très académique du code, ce qui est parfois très différent des critères utilisés en entreprise.

Dans ce sens, partager son code permet d'avoir des avis de personnes différentes (universitaires, entreprises, etc). Les discussions entre experts sur des points techniques particuliers permettent d'avoir une vision plus large des problèmes et solutions

+1 -0
Auteur du sujet

Bonsoir,

Je tiens à tous vous remercier pour vos réponses ^^ Vous avez répondu à toutes mes interrogations, et maintenant je sais ce qu'il me reste à faire!

Sujet résolu, à bientôt ;)

Un jour j'irai vivre en Théorie, car en théorie tout se passe bien.

+0 -0

Je coinche, personne n'est assez fou pour utiliser les exceptions en C++.

gasche

Malheureusement trop sont encore assez fous pour croire faire mieux sans les exceptions. Avec des ifs, quand on veut écrire un programme robuste (et pas un programme qui vit au pays magique où les erreurs n'existent pas), il faut faire remonter à la main toutes les erreurs possibles sur tous les chemins d'exécution. Si on n'en oublie pas (et ça, ce n'est pas trivial dans un langage qui descend du C qui n'impose pas de rattraper toute valeur retournée), on voit tout. Mais le problème est justement que l'on voit tout : le code nominal est noyé au milieu du code de traitement des cas exceptionnels.

Certains qui critiquaient en aveugles attaquaient aussi les perfs. C'était valable sur les anciennes générations de compilateurs, ou sur certaines plateformes (PS3, IIRC) qui avaient une gestion bugguée des exceptions. Bref, vu qu'un code robuste en C++ n'a pas à avoir un if toutes les deux lignes sur 10 niveaux de profondeur pour traiter les cas exceptionnels, les exceptions ont de bonnes chances d'offrir des programmes (robustes) plus rapides. (J'insiste sur le côté robuste, il est idiot de comparer les perfs d'un code employant des exceptions avec celles d'une code écrit au pays magique où les erreurs n'existent pas).

Bref. Il faut apprendre à manipuler le C++ moderne pour commencer. Un fois le RAII acquis, le passage aux exceptions se fera sans soucis.

+5 -0

Le sujet semble résolu si l'on en croit l'OP, mais je voudrais tout de même apporter mes deux centimes et évoquer quelque chose à côté duquel mes voisins du dessus (même si leurs contributions contiennent d'excellent conseils) sont passés, ou plutôt quelque chose qui a affleuré sans éclore : la pertinence de bosser dans un projet qui n'est pas le sien, sous la houlette de quelqu'un de meilleur que soi.

Je m'explique, et ça rejoint l'idée de Dinosaure de "quelqu'un derrière toi qui te note", tout en étant plus proche de l'autodidaxie. Mon parcours en informatique a été pour le moins hiératique ; il a commencé il y a environ 6 ans dans le domaine du web (PHP et consorts, qui ont bien évolué depuis) pendant quelques années au terme desquelles je pressentais à peine l'importance de bonnes pratiques, d'une architecture et d'une réelle conception d'un code. Tout ce qu'on pourrait qualifier de philosophie, d'esthétique de la programmation (ouais, carrément) m'était à peu près étranger, même si je commençais à avoir des idées en la matière. Et là, j'ai intégré un projet monstrueusement massif (en gros, un MMORPG, et qui a abouti, réellement), mené par un mec incroyablement plus talentueux que moi. Sous sa direction, j'ai appris Python et surtout, surtout, j'ai énormément progressé en capacités de réflexion sur ce que je produisais au niveau code.

D'ailleurs, j'ai lu ça y'a pas longtemps dans un papier que j'ai la flemme de retrouver, qui parle justement de "comment apprendre à programmer". L'auteur y mentionne l'utilité de participer à un projet véritable, et je ne saurais trop être d'accord avec lui. Grâce à ce gros projet que j'ai mentionné, j'ai acquis des réflexes de conception, de convention, de programmation en général qui me servent à chaque fois que je code. Bon, évidemment, c'est pas évident d'intégrer un projet et on peut trouver sur la toile pas mal de daubes qui recrutent et ne t'apprendront pas grand-chose… Mais il n'empêche que si tu en as l'occasion, ça me semble vraiment un des meilleurs moyens de progresser en programmation. (En fait, ça répond plus ou moins à tes points 1, 4, 5 et 6. :D )

ZdS : un palimpzeste pour le savoir. | Les codes correcteurs, c'est bien.

+0 -0

Ce que tu décris rejoint une partie de ce (vieux) document célèbre: How To Become A Hacker d'Eric Raymond. C'est avec des forums que j'ai beaucoup appris pour ma part: on suit des forums techniques ; arrive un moment où l'on essaie de répondre ; si notre réponse à des erreurs ; des gens plus compétents viennent la corriger ; Parfois ils complètent et pinaillent, ce qui est tout aussi instructif ; et puis on passe de l'autre côté : celui de ceux qui corrigent/complètent/pinaillent.

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte