Discussion :

[tr1v1al]

Bonjour,

Je suis en cours de formation en C++, j'apprends le langage et j'aimerai des informations pour créer un livre sur le langage.
Voila comme source du livre j'utilise les cours:
- C++ Moderne de Zeste du savoir
- Learn C++ de Code cademy
- Learn C++ in 31h de freecodecamp

J'aimerai développer selon ces sources le livre et j'ai quelques difficultés pour l'instant à trouver des points à développer dans l'héritage et le polymorphisme que je maitrise moins.
Votre avis sur mon approche du langage selon la première ébauche du sommaire du livre (en accès libre). Il y a t-ils des points essentiels que je loupe pour un débutant?

Merci

[koala01]

Salut,

De mon avis personnel:

• "Tableau: introduction" et "que peut on faire avec des tableaux?" n'ont de sens que si tu aborde la notion d'un point de vue strictement théorique, et j'irais même jusqu'à dire : totalement agnostique du langage
• Tu devrais aussi parler de std::array lorsque tu aborde l'utilisation des tableaux en C++
• Les containers : Encore une fois, une approche purement théorique, mais plus précise (qu'est ce qu'une pile / une file / une liste / un arbre binaire, d'un point de vue agnostique du langage) suivie de l'évocation des containers équivalent en C++ serait intéressante à envisager
• "Pointeurs et références": parler des référence à ce moment là du livre, oui (le plus tôt sera le mieux), parler des pointeurs ... beaucoup plus tard uniquement (après avoir abordé la notion d'héritage), le principe étant que l'on ne commence vraiment à avoir besoin des pointeurs qu'une fois que l'on fait joujou avec des hiérarchies de classes (et donc avec l'héritage)
• "C-string" n'a rien à voir ici: c'est une pratique issue du C, ce n'est pas du C++. Si tu tiens vraiment à en parler, cela ne doit se faire qu'une fois que tu as fini tout le reste
• "classes et méthodes" : "classes" oui, "méthodes" on parlera plutôt de "fonctions membres", car "l'imaginaire collectif" associe le terme méthode à une fonction dont le comportement peut forcément être redéfini dans les classes dérivée. Or, ce n'est pas forcément le cas
• "fonctions", "surcharge" et "lambda" sont des notions qui mériteraient d'être abordée avant la notion de classes, car ces trois notions ne sont pas limitées à l'utilisation des classes. A voir si tu préfères aborder la notion de référence avant ou après ces trois notions (peut être le faire dans l'ordre: fonction, surcharge, références et lambda).
• A noter d'ailleurs que les notions de "structures (de données)" et de "classes" sont suffisamment proches que pour être abordées ensembles . Mais, as tu compris ce qui les sépare
• "Template": cela mériterait sans doute un chapitre séparé, vu qu'il n'y a aucune obligation à utiliser des classes (et leurs fonctions membres)
• "classes et objets" --> ne serait-ce pas plutôt "type définis par l'utilisateur et instances de données
• "l'encapsulation": oui, à partir du moment où tu as compris la loi de Demeter. cela mériterait d'ailleurs aussi de se retrouver dans un chapitre séparé, vu que la structure FILE du C est là pour nous prouver que le principe était connu et maitrisé bien avant que l'idée de faire de "l'orienté objets" ne fasse son apparition
• Pareil pour "l'abstraction", qui arrive dans la droite ligne des structures de données
• "spécificateur du contrôle d'accès"... C'est là que les choses deviennent drôles, parce que l'on peut parfaitement l'utiliser avec les structures. L'accès utilisé par défaut (lorsque rien n'est indiqué) étant justement la seule différence qui existe entre une classe et un structure en C++
• "constructeur et destructeur", oui, si tu parle également du constructeur de copie, de l'opérateur d'affectation (forme canonique de Coplien inside), et que tu fais la distinction entre la sémantique de valeur et la sémantique d'entité
• "getters et setters": Getters, oui, Setters, en aucun cas (cf loi de Déméter / encapsulation) peut être insister sur la nécessité d'avoir une approche "orientée vers les services" (et ce, dés l'approche de la notion d'abstraction a été abordée)au lieu d'avoir une approche "orientée vers les données" qui s'avère, au final, transmettre une bien piètre idée de "l'orienté objets"
• "Pointeurs intelligents" à vrai dire, ce devrait être la toute première manière dont tu devrais envisager le recours à l'allocation dynamique de la mémoire: tu peux aborder la notion de pointeur d'un point de vue théorique, mais dés qu'il s'agit de passer à la pratique, il ne faut parler en priorité des pointeurs intelligents. Au moins le temps d'aborder les notions de "propriétaire" et "d'utilisateur" de la ressource pointée
• STL et bibliothèque standard (pas forcément template ) de manière générale: son introduction "logique" devrait arriver avant même que tu ne parle de "saisie de l'utilisateur", et chaque élément qui en fait partie devrait être clairement indiqué comme tel

j'ai quelques difficultés pour l'instant à trouver des points à développer dans l'héritage et le polymorphisme que je maitrise moins.

As tu déjà lu mon livre (lien en signature) Il Pourrait peut-être t'apporter quelques réponses (et même aborder bien d'autres points qui t'aideront dans ta démarche

Bonne chance et bon courrage

[Bousk]

Je comprends mal le concept d'écrire quelque chose sur un truc qu'on est en train d'apprendre et donc ne maîtrise pas.
C'est ta façon d'apprendre ? Écrire des programmes serait plus efficace imo.
C'est pour publier ? Penses-tu que ce soit pertinent sans maîtriser le sujet ?

l'ordre des trucs est discutable imo
opérateurs après affectation ? mais l'affectation est un opérateur
mot-clés dans variables ? et les mot-clés qui n'ont rien à voir avec les variables ? (namespace, using, class, struct, template, delete, default, ...)
introduction à la logique après les conditions ?
les tableaux dynamiques sont les seuls containers ? (unordered_)map ? list ? queue ? dequeue ? (unordered_)set ? array ?
classes et méthodes ? méthode n'est pas dans le standard du C++; puis les méthodes/fonctions libres, non ?
la surcharge (overload) de fonction est orthogonale aux classes, à ne pas confondre avec override
le concept de lambda est orthogonal aux classes
le concept de template est orthogonal aux classes
le concept de programmation modulaire est orthogonal aux classes
getter & setter sont des utilisations particulières voire secondaires/négligeables d'une classe
un pointeur intelligent est nettement plus simple qu'un pointeur nu et n'a rien d'avancée mais est/devrait être la norme
la STL et plus globalement la SL ne sont pas des notions avancées
pourquoi considérer c++20 comme avancée ? ça a bientôt 2 ans et on parle déjà de c++23

en vrac qui manquent imo : do while, ranged-based for loop, literals, variadic template, liste d'initialisation, std::initializer_list, =default, =delete, virtual =0, in-class initializer (ou default member initializer), bitset, enum, enum class, namespace, structured binding, delegate/signal/slot/notifications, POD, ranges/views/spans, constexpr, if constexpr, consteval, union, try catch, throw, static_cast, dynamic_cast, reinterpret_cast, const_cast, assert, static_assert, allocateurs, thread, concurrence, mutex, semaphores
et y'en a sûrement un paquet d'autres auxquels je ne pense pas

[Mat.M]

pas mieux que Bousk et Koala01 des livres sur le C++ il en existe déjà

[Bktero]

Mettre un petit chapitre "Template" dans la partie "Classes et méthodes" me semble indiquer une totale sous-estimation de l'ampleur des templates en C++.

Quand je vois qu'on parle de pointeur avant de parler de référence, je m'inquiètes de voir C++ présenté d'un point de vue C. De voir qu'on parle de tableaux (que je suppose être des C arrays), et de C strings avant std::string, renforce cette crainte.

[tr1v1al]

Je prends note de vos réponses.

Pour savoir pourquoi penser à écrire un livre quand on apprend un langage informatique, à mon sens pour exceller il faut enseigner. On est plus rigoureux quand on écrit un livre tout en apprenant que des notes, on fait une recherche documentaire pour approfondir des points, il y a un travail de synthèse à faire sur les sources. Rien que le fait de recopiez des notions améliore l'apprentissage, c'est donc on peut dire une méthode.

De plus j'aimerai lancer mon entreprise SS2I/ESN et avoir des documents de formation en informatique en C, Arduino, C++ comme vecteur de soft power par la diffusion de reference.

J'essaye de penser en amont au livre, même si des points sont encore flou, cela me boost pour travailler plus.

[Mat.M]

De plus j'aimerai lancer mon entreprise SS2I/ESN et avoir des documents de formation en informatique en C,

trouver des clients et faire tourner une entreprise c'est une chose bien plus difficile que d'apprendre le C++ mais ça c'est un autre sujet
parce que si vous voulez apprendre le C++ soit ça fonctionne soit ça fonctionne pas et après on cherche ce qui ne fonctionne pas

Sinon une introduction au Design Patterns est une bonne idée également

[koala01]

Je prends note de vos réponses.

Pour savoir pourquoi penser à écrire un livre quand on apprend un langage informatique, à mon sens pour exceller il faut enseigner.

C'est une manière de voir intéressante, certes, qui pose cependant un petit problème:

Pour enseigner quelque chose qui "tienne la route", il faut d'abord et avant tout connaitre suffisamment ce que l'on enseigne que pour ne pas commencer à raconter des c...ries.

Si on peut se dire que quelques mois (aller, un an tout au plus) suffit pour des langages comme java ou Python, c'est -- malheureusement -- très loin d'être le cas du C++, qui compte très clairement parmi les langages les plus complexes que l'on puisse trouver.

Si bien qu'il faut compter entre trois et cinq ans d'expérience avant même de pouvoir considérer que "l'on se débrouille pas mal en C++ et qu'on en connait les principaux rouages". Alors, quant à exceller dans le domaine, disons juste que je pratique le C++ depuis près de vingt ans maintenant, et que, malgré une veille technologique réelle, malgré un livre que j'ai écrit, je peux t'assurer que je n'en ai pas encore fait le tour.

On est plus rigoureux quand on écrit un livre tout en apprenant que des notes, on fait une recherche documentaire pour approfondir des points, il y a un travail de synthèse à faire sur les sources. Rien que le fait de recopiez des notions améliore l'apprentissage, c'est donc on peut dire une méthode.

Si je ne peux te donner tort sur le principe, il reste un autre problème à surmonter: lorsque tu apprends un langage comme le C++, tu n'as, purement et simplement, pas le recul nécessaire pour distinguer "la bonne source" de la "mauvaise".

Même si tu venais du monde java et que tu maitrisais parfaitement ce langage, il apporte une vision tellement biaisée (et basée sur des mensonges fait par les développeurs du langage à ses utilisateurs) que l'on ne pourrait toujours pas considérer que "tu aies le recul nécessaire", car la "transposition" du mode de pensée n'est pas forcément automatique ni adaptée à l'ensemble des points auxquels tu devras réfléchir.

Bien sur, certains aspects comme les desing patterns restent applicables. Cependant, la compréhension d'un principe comme le LSP frole des profondeurs abyssales chez de nombreux développeurs java, qui restent persuadés qu'il existe réellement une différence conceptuelle entre le fait qu'une classe hérite d'une autre et le fait qu'une classe implémente une interface.

[tr1v1al]

En faite j'ai commencé la programmation par le langage C il y a quelques années, mais j'en suis qu'au début de l'apprentissage du C++ avec quelques réflexes du C sur les pointeurs et les structs. J'avais commencé à aborder le C++ en lisant le cours d'open classroom qui n'est plus à jours. Puis j'ai switché sur le cours de Zeste de Savoir. Je me doute que C++ est difficile à apprendre, je le fais en parti pour l'appliquer dans les moteurs de jeux-vidéos et les noyaux de modélisation géométrique qui m'intéresse particulièrement. J'ai aussi une préférence pour développer avec des outils GNU au niveau compilateur.
J'ai à peine survolé les possibilités de la STL qui sont pour moi une innovation intéressante par rapport au langage C. Je dois prendre un cours sur les structures de données et algorithmes, je cherche quelques chose d'a jours en C++ moderne. Je ne sais pas si c'est une bonne stratégie d'écrire un livre seulement qu'en on a de l'expérience au bout de quelques années, et je pense bien qu'il faut 3 à 4 ans pour une bonne maitrise du C++. Juste qu'écrire plus tôt , la peur d'écrire des conneries, j'en suis assez conscient ce qui m'oblige a demander quelques renseignements.

[koala01]

et je pense bien qu'il faut 3 à 4 ans pour une bonne maitrise du C++.

Non, non, tu n'y es pas du tout: il faut 3 à 4 ans de pratique assidue pour pouvoir estimer que "tu commences (à peine) à savoir ce que tu fais"...

Tu peux facilement en rajouter entre quatre et six pour pouvoir estimer en atteindre un "début de maîtrise"

[mintho carmo]

à mon sens pour exceller il faut enseigner.

En soi, l'idée de vouloir transmettre n'est pas mauvaise. C'est effectivement une bonne méthode pour approfondir et clarifier ses connaissances.

Cependant, il ne faut pas brûler les étapes. Pour que le travail que représente l'écriture d'un livre soit efficace en termes de clarification et d'approfondissement des connaissances, il faut déjà avoir ces connaissances. Il faut avoir une vue d'ensemble du sujet, il faut savoir quels questions peuvent se poser lors de l'apprentissage, il faut savoir où aller chercher les détails techniques approfondis qui justifient les choix techniques et pédagogiques pour les débutants.

En plus, l'écriture d'un livre est un énorme projet. Même pour un développeur expérimenté.

Je te conseille de commencer petit et d'y aller progressivement. Commence par ecrire un simple tuto, sur le sujet de ton choix. Peu importe si c'est un sujet qui a déjà été fait, il y a souvent des nouvelles choses à dire ou une nouvelle approche possible. Ca peut peut être aussi une vue d'ensemble d'un concept connu, mais qui a des mises à jour dans les dernières versions sur C++. Ou présenter un projet d'exemple qui détail un concept dans la pratique. Ca peut être sur de la syntaxe C++ pure ou sur un concept plus général (design pattern, conception, gestion des erreurs, management de projet, outils pour les devs, etc). Propose un sujet, peut être quelques lignes pour expliquer l'approche que tu veux suivre et propose ton tuto sur ce site (ou autre). Et pendant la rédaction, demande des avis et relectures de devs avancés, qui pourront te faire des retours constructifs avec du recul. Et finalise ce tuto avant de commencer le second. Ensuite, progressivement, tu fais des tutos de plus en plus complexe et de taille important, jusqu'a arriver a avoir les compétences pour écrire un livre.