Big-tuto C++

Je confirme, on est trois à écrire un gros tuto sur les différents paradigmes de programmation et tous les concepts et le vocabulaire lié à chacun. Je vous conseillerais de ne pas perdre votre temps à réexpliquer ce qu'est une variable, une boucle, un bloc conditionnel ou une méthode : on s'en charge pour vous. Concentrez-vous sur ce qui est spécifique au langage. D'autant qu'on mettra des exemples en C++…

Il y aurait-il moyen d'en voir une bêta ? J'aimerais beaucoup le relire.

Sinon effectivement, autant combiner nos efforts. Pourquoi ne pas faire un tutoriel qui serait plus "Comment programmer proprement en C++ moderne ?", où l'on suppose que le lecteur a déjà des bases en C++ et où on va lui montrer quelles sont les bonnes pratiques du C++, ses spécificités, comment bien appliquer les conseils lus dans le tutoriel sur la POO, etc.

Le problème de ce genre d'approche, c'est le moque de cohérence rédactionnelle et pédagogique. Si tu prends chaque article de cppreference, tu auras tous les concepts du C++ qui seront expliqués. Mais cela n'en fera pas un cours.

Effectivement c'est vrai. Du coup, on est un peu face à un dilemme : faire un tutoriel complet sur C++ et du coup être un peu redondant sur la partie POO, ou faire ce que j'ai proposé en dernier mais n'être qu'un cppreference ?

Sinon, on peut faire un tutoriel C++ complet, où, pour chaque chapitre de POO, on envera d'abord le lecteur lire le chapitre correspondant du tutoriel sur la POO. Pour le chapitre sur l'héritage, on demandera au lecteur de d'abord savoir les notions générales.

Il y aurait-il moyen d'en voir une bêta ? J'aimerais beaucoup le relire.

Pas encore. Mes deux collègues étaient en pleins concours ces dernières semaines, donc le cours n'a pas avancé. Si aucun obstacle ne se met sur notre route, on devrait pouvoir proposer une bêta vers fin juillet.

Sinon, on peut faire un tutoriel C++ complet, où, pour chaque chapitre de POO, on envera d'abord le lecteur lire le chapitre correspondant du tutoriel sur la POO. Pour le chapitre sur l'héritage, on demandera au lecteur de d'abord savoir les notions générales.

C'est bien comme ça que nous avons conçu notre tuto. Pour que les tutos spécifiques renvoient vers lui quand ils abordent un concept donné.

Si qqn veut apprendre le c++ je ne pense pas que ce soit bon qu'il ait a chercher des tutoriels à droite à gauche mais qu'il ait un tuto qui explique tout de A à Z.

Alors c'est parfait. Mais du coup, pour la partie sur la POO, on va être obligé de vous attendre.

Il y a probablement la place pour toutes les approches. A vous de voir l'orientation que vous voulez donner à votre tuto.

Par exemple, je ne suis pas fan de l'approche qui consiste à renvoyer le lecteur vers un cours POO "théorique" (ie indépendant du langage). Premièrement, c'est souvent rébarbatif (selon son background. Comme je n'ai pas suivi une formation de dev, tout ce qui est théorie des langages de programmation me gonfle assez rapidement. J'ai attendu de ne plus être débutant en C++ pour approfondir cela. J'imagine que ça sera le cas aussi pour un débutant qui commence la programmation en autodidacte). Deuxièmement, cela "casse" le rythme de lecture. Et troisièmement, cela ne me semble pas gênant de répéter ce qui a déjà été dit dans un autre tuto (enseigner, c'est répéter).

Pour cppreference, il y a une version partielle en français : http://fr.cppreference.com/w/cpp/language. C'est de la traduction automatique et c'est incomplet. Mais ça serait clairement une bonne chose que la traduction fr soit améliorée (mais ce n'est plus réellement un tuto)

Je pense que ce genre de tutos sont intéressants pour compléter un apprentissage, mais un big tuto est irremplaçable pour débuter. Mais c'est un avis personnel.

EDIT : grillé, je n'avais pas vu la troisième page.

Sinon, tout à fait d'accord avec gbdivers, je ne vois pas où est le problème de répéter des principes théoriques. Et c'est vrai que pour un débutant, les cours de pure théorie sont un peu ennuyeux.

Alors c'est parfait. Mais du coup, pour la partie sur la POO, on va être obligé de vous attendre.

Par expérience, il va vous falloir un bon bout de temps avant d'avoir écrit de manière satisfaisante tout ce dont vous comptez parler avant la POO, donc vous ne devriez pas avoir trop besoin de nous attendre.

Par exemple, je ne suis pas fan de l'approche qui consiste à renvoyer le lecteur vers un cours POO "théorique" (ie indépendant du langage).

Alors, pour que les choses soient claires, nous avons l'intention de mettre des exemples dans plusieurs langages différents pour chacun des concepts suffisamment généraux pour le permettre. Donc stricto sensu, ce sera en effet de la théorie, mais largement appuyée sur des exemples concrets.

Cependant :

De A à Z, ce n'est pas possible. Il faut se fixer des limites, le C++ étant un domaine beaucoup trop large. C'est pour ça que je t'ai tout de suite arrêté dans ton idée d'aborder la sfml et gtkmm, ça aurait été n'importe quoi.

EDIT : gbdivers, j'aimerais bien avoir ton avis sur le fait de présenter la gestion des erreurs vers la fin du tutoriel : est-ce tropt tard ou est-ce acceptable ? (si d'autres ont un avis sur la question, je suis preneur )

Trop tard probablement… Plus tu parles tôt de quelque chose, plus tu auras de temps pour l'appliquer dans les chapitres suivants. Mettre la gestion des erreurs à la fin fait que tu ne peux pas passer tout ton temps à parler encore et encore des erreurs. Du coup, le lecteur peut voir cela comme une notion annexe. Si tu présentes cela tôt et que fait une remarque dessus dans les chapitres suivants, les lecteurs intégreront cela comme une notion de base applicable partout.

A vous de voir quelle notion est importante à transmettre et quelle notion ne l'est pas. Et mettre les notions importantes au début, pour pouvoir les répéter souvent

Très bien, merci. On va voir comment on peut faire pour placer la gestion des erreurs plus tôt. (au minimum avant la P.O.O)

Je suis d'accord avec gbdivers sur toute la ligne !

Je propose qu'on se concentre tout d'abord sur la première partie, savoir ce qu'on met dedans, l'ordre des chapitres, etc. Comme l'a dit notre docteur es torture, le temps qu'on écrive tout ça proprement, on a bien le temps de réfléchir à ce qu'on mettra dans la suite.

Par contre, pour les erreurs, ça implique bien de parler des assertions, des exceptions et d'autres choses que j'aurai pu oublier ?

Mes avis sur les différents points dans la discussion depuis le début dans le désordre.

Oui, les erreurs doivent traitées assez tôt mais dans un premier temps sans parler des implications en terme de gestion de ressources. On veut juste savoir que ça brise le flot d'exécution (donc que ça introduit de nouvelles sorties de bloc sur le plan logique) et que la fin de bloc implique toujours la disparition de nos ressources.

Personnellement, j'insisterais également sur le fait que toute la mécanique des exceptions est hyper importante pour avoir une vraie séparation des préoccupations (détection erreur, traitement d'erreur et traitement réel sont trois tâches séparées).

L'assertion doit être également traitée dans cette partie du cours. Cf l'article de @lmghs sur la PpC pour l'explication entre erreur runtime et rupture de contrat.

Pour moi la vraie question de ce point de vue c'est : doit-on aborder succinctement la gestion des erreurs à la C qui rencontre encore ses cas d'utilisation parfois ? En ce qui me concerne, je le mettrais plutôt dans une partie parlant de la création de code noexcept mais la question se pose quand même.

Autre point : j'ai lu quelque part un avis disant qu'il vaut mieux avoir vu les classes avant d'entamer l'utilisation de la STL. Je ne peux que me porter contre. L'utilisation et la création d'une classe sont deux processus très différents et je pense que l'utilisation est la partie de l'apprentissage qui doit venir en premier :

• on comprend mieux comment designer une classe quand on a soit même utilisé des classes bien foutues,
• bien designer une classe est clairement plus difficile qu'utiliser des classes déjà faites,
• on utilise déjà pleins de classes dès le "hello world" .

Si on suit la logique d'apprendre à faire des classes avant d'utiliser la STL, alors en C on doit apprendre à fabriquer malloc avant de l'utiliser .

Concernant le plan, quitte à faire un énorme point sur les tous types de pointeurs/références, etc. Autant parler tout de suite des raw_pointers. Cela n'induit pas forcément que l'on doive parler d'allocation dynamique manuelle et ils ont leurs cas d'utilisation assez tôt. J'ajouterai également un point sur la programmation fonctionnelle.

Ah et insistez sur le fait de lire la documentation.

Hello,

J'envisageais aussi d'écrire sur le C++, et je suis plutôt pour organiser un parcours dans le même esprit que pour Python, étant donné la complexité et la diversité du langage.

Je pense aussi que ça permet de mieux répartir les efforts entre les différents sujets, et d'avoir des résultats intermédiaires concluants (tel tuto est définitivement terminé), plutôt qu'un énorme big-tuto-qui-déchire jamais terminé (et de débattre trop longtemps sur le plan).

Je pensais au plan suivant pour un tuto d'introduction (dans les grandes lignes) :

1. Introduction : présentation, installation d'outils, hello world
2. Bases du langage : types de base (sans pointeurs), boucles, fonctions
3. Structurer ses données : POO côté utilisateur avec la STL
   • introduction à la notion de classe avec std::string [l'utilisateur s'affranchit de la représentation interne d'une chaîne, des problèmes d'allocation, etc]
   • les conteneurs de la STL, couteau-suisse qui permet de structurer les données [+ range-for]
   • partager des données [références, smart pointers, pas de raw pointers]
4. POO côté programmeur : classes, méthodes, surcharge d'opérateurs, sémantiques de classe, polymorphisme

D'autres parties pourraient faire l'objet de tutoriels séparés (je n'ai pas vu d'ordre évident entre elles, et le lecteur n'a pas forcément besoin d'approfondir toutes les notions). On pourrait en regrouper certaines sous "C++ avancé".

• Notions de compilation (commun C/C++) : compilation séparée des classes, comment linker une bibliothèque (et comment en écrire une)
• Gestion des erreurs : exceptions, principe RAII (+ parler des pointeurs nus et de new/delete)
• Bibliothèque standard (hors conteneurs) : streams, chrono, random, math, regex
• std::algorithm : notion d'itérateur, présenter les lambdas (+ std::function, std::bind & cie)
• Créer ses propres templates : introduction, variadic templates + des notions plus poussées sur ce qu'on peut faire avec les constexpr et la SFINAE
• Programmation parallèle : std::thread, mutex, condition_variable, atomic

Autres notions en vrac :

• user-defined literals

Et des tutoriels qui dépassent le langage à proprement parler :

• Qt (introduction, notions avancées, etc)
• Boost
• SFML
• Tests unitaires en C++
• etc

Pour résumer, sur le début du cours, je suis plutôt d'accord avec le plan de plan de mehdidou99, mais je trouve plus logique de séparer la STL (indispensable pour structurer ses données) du reste de la bibliothèque standard (qui définit des fonctions pour interagir avec le monde extérieur).

Et je ne sais pas trop quoi faire de la partie std::algorithm, qui risque peut-être d'être un peu complexe à aborder au début. C'est une notion utile qui doit être connue (pour éviter de re-coder soi-même std::sort et cie), mais il est AMHA important d'approfondir ce qui se cache derrière itérateur et lambdas, pour éviter des erreurs d'itérateurs invalides (qui peuvent être dramatiques au niveau mémoire), et comprendre ce qu'on capture vraiment dans les lambdas (avec le foncteur sous-jacent).

Pour les exceptions, je vois mal en parler avant de savoir hériter une classe. Et en parler trop tôt pourrait encourager à les utiliser dans ses algorithmes comme des "super-break", ce qui n'est pas forcément le plus adapté/performant. Au passage on peut reprendre les idées de Jon Kalb sur le sujet (partie 1, partie 2, partie 3).

Oui, les erreurs doivent traitées assez tôt mais dans un premier temps sans parler des implications en terme de gestion de ressources. On veut juste savoir que ça brise le flot d'exécution (donc que ça introduit de nouvelles sorties de bloc sur le plan logique) et que la fin de bloc implique toujours la disparition de nos ressources.

Tout à fait d'accord.

Personnellement, j'insisterais également sur le fait que toute la mécanique des exceptions est hyper importante pour avoir une vraie séparation des préoccupations (détection erreur, traitement d'erreur et traitement réel sont trois tâches séparées).

D'accord aussi

L'assertion doit être également traitée dans cette partie du cours. Cf l'article de @lmghs sur la PpC pour l'explication entre erreur runtime et rupture de contrat.

D'accord pour traiter l'assertion.

Pour moi la vraie question de ce point de vue c'est : doit-on aborder succinctement la gestion des erreurs à la C qui rencontre encore ses cas d'utilisation parfois ? En ce qui me concerne, je le mettrais plutôt dans une partie parlant de la création de code noexcept mais la question se pose quand même.

Pas d'accord la gestion d'erreur "à la C" n'a rien à faire dans un cours sur le C++.

Autre point : j'ai lu quelque part un avis disant qu'il vaut mieux avoir vu les classes avant d'entamer l'utilisation de la STL.

C'est moi !

(_{pas d'insulte pas de coups})

JE re-pose ma question : "std::string, std::chrono, std::ofstream… On les présente comment on dit que c'est des types avec des méthodes ?"

Si on suit la logique d'apprendre à faire des classes avant d'utiliser la STL, alors en C on > doit apprendre à fabriquer malloc avant de l'utiliser

Je n'ai jamais dit qu'on devait apprendre les classes avant tout le reste tu l'as dit toi même dès le "Hello world" on utilise la classe ostream mais ce n'est pas pour ça qu'on devrait leurs apprendre toutes les classes de la STL (c'est une image) avant qu'il sache ce que c'est.

std::string peut servir à introduire la notion de classe justement, en disant qu'une chaîne est soit un tableau de caractères avec NULL à la fin, soit une paire longueur-contenu, mais que c'est compliqué et que std::string gère ça pour nous. C'est l'esprit même d'une classe, et ça n'est pas trop compliqué (contrairement aux conteneurs qui utilisent les templates).

Pour std::chrono, std::ofstream, c'est moins essentiel que les conteneurs je pense (tout le monde ne va pas manipuler le temps ou les fichiers), d'où l'idée de faire une partie séparée pour la SL.

Ma plateforme ne supporte pas les exceptions, ou l'overhead des exceptions est trop élevé pour que je puisse me le permettre, ou bien plus simplement je suis dans une portion critique de mon code que je veux prouver et j'ai besoin d'avoir un flot d'exécution qui soit très simple.

Je suis dans un cas où je veux écrire du code noexcept. Mais je ne suis pas dans le monde des bisounours, il peut y avoir des erreurs, et il faut que je les traite. Il ne me reste que la gestion "à la C".

A mon sens, un big-tuto devrait aborder le noexcept.

Je pense que je présenterai tous les types comme … des types, en disant que certains peuvent être utilisés par l'intermédiaire de fonctions qui leur sont associées (d'ailleurs, dans un tutoriel sur le C++, je pense qu'il vaut mieux s'attacher à la terminologie "fonction membre" de la norme, plutôt que "méthode").

Sur un plan logique, je trouve que la distinction variable/objet est complètement hors de propos. La différence entre les deux est devenue tellement ténue qu'elle ne donne aucune information. EDIT : c'est d'ailleurs en grande partie dû à la présence des classes à sémantique de valeur, une instance d'une telle classe n'est clairement pas un fournisseur de service.

J'abonde dans le sens de KsassPeuk, on peut présenter les classes comme std::string` comme des types au même titre que les types de base, avec simplement des fonctions spécifiques "qui leur appartiennent".