Le cours de C++ de gbdivers

Une annexe du sujet sur OC...

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

Bonjour,

J'ouvre ce topic (en espérant être au bon endroit pour ça) pour discuter du cours en cours de rédaction de Gbdivers sur le C++ moderne. Il suggère dans le cours de faire des remarques sur OC ou ZdS, mais je n'ai pas trouvé de sujet correspondant ici, seulement sur OC. Du coup je l'ouvre, et si j'ai simplement pas trouvé le sujet, j'espère qu'on pourra me l'indiquer.

Je viens de parcourir le cours (j'ai une petite expérience en C++ 11, mais je ne suis pas dev professionnel, loin de là). Dans l'ensemble, je le trouve bien structuré et très complet. Je trouve particulièrement intelligent de mêler aussi intimement l'apprentissage de la syntaxe et des sémantiques.

Il y a un aspect que je trouve étrange : l'apprentissage des structures basiques de programmation (for, if, while, fonctions) arrive très tardivement. Introduire ar exemple les foncteurs avant (et au passage les lambdas) me semble un choix très étrange.

Personnellement, j'aurais vu la partie "Créer ses algorithmes" (peut-être pas intitulée comme ça du coup) avant la partie sur les conteneurs. Ça permettrait :

  1. d'avoir plus de choses intéressantes à pratiquer (même si très basiques)

  2. d'avoir une meilleure vue d'ensemble d'un programme simple

  3. d'avoir introduit les exceptions plus tôt, et donc de les illustrer avec la std en expliquant quelles exceptions les conteneurs peuvent lever et pourquoi (ce qui permettrait un apprentissage continu de la prise en considération des exceptions, qui est souvent laissé de côté comme un élément avancé alors qu'il faut toujours raisonner avec)

Je comprends bien que l'idée est d'apprendre très tôt la structure de la bibliothèque standard et la notion de ne pas réinventer la roue. Cependant, je trouve étrange de manipuler des foncteurs quand on a jamais écrit une fonction basique. De même, je trouve l'apprentissage des regexp avant les boucles / conditions un peu étrange. Bref, j'imagine qu'il y a des raisons pédagogiques bien réfléchies que je ne vois pas derrière ce choix, et du coup j'aimerais bien que tu m'expliques ce choix (si tu as le temps).

Merci d'avance pour tout éclaircissement :)

+1 -0
  1. il y a déjà beaucoup beaucoup de choses a pratiquer avec les conteneurs + algos de la STL. (En fait, on pourrait presque n'utiliser que cela dans 90% du code)

  2. je ne suis pas sur de voir le rapport

  3. c'est vrai que c'est mieux d'introduire le plus tôt possible la gestion des erreurs. Avec le plan choisi, comme la STL n'utilise pas trop les exceptions (dans des codes aussi simple), je ne peux pas les introduire naturellement. Seul la vérification des pré-conditions sont faite (via assert), les exceptions sont abordées plus tard (mais pas trop tard, cela vient juste après).

Je comprends bien que l'idée est d'apprendre très tôt la structure de la bibliothèque standard et la notion de ne pas réinventer la roue. Cependant, je trouve étrange de manipuler des foncteurs quand on a jamais écrit une fonction basique. De même, je trouve l'apprentissage des regexp avant les boucles / conditions un peu étrange. Bref, j'imagine qu'il y a des raisons pédagogiques bien réfléchies que je ne vois pas derrière ce choix, et du coup j'aimerais bien que tu m'expliques ce choix (si tu as le temps).

Le but n'est pas uniquement d'apprendre le plus tôt possible la STL (bien que ce soit important. Quand on veut faire quelque chose, le premier réflexe devrait être de voir en premier si cela existe déjà). Le but est aussi d'apprendre une certain façon de concevoir les choses.

  • étudier l'existant pour le comprendre et le copier
  • penser en premier en termes d'interfaces ("comment ma fonction sera utilisée ?") que d’implémentation ("comment ça fonctionne dedans ?")
  • et au final, si le cours n'est pas trop mauvais, prendre l'habitude de penser en termes d’abstractions.

Pour les regex… random placement :) Plus sérieusement, je me suis pose la question des pré-requis pour cela… et il n'y en avait pas trop (a part les string). C'est une fonctionnalité intéressante a connaitre (donc pas envie que cela arrive trop tard).

(note : https://openclassrooms.com/forum/sujet/nouveau-cours-c-moderne pour la precedente discussion. Mais on peut continuer ici)

Édité par gbdivers

+0 -0
Auteur du sujet

Merci pour ta réponse !

(pour le sujet sur OC, je le connaissais, mais j'ai pas envie de reprendre mon compte là-bas, je préfère ici).

Malgré tout, je continue à être suspicieux du fait que les structures de code impératif basiques arrivent si tard. Même si je comprends bien les arguments, c'est très bizarre.

Pour le 2., c'est simplement

  • la structure d'un programme qui appelle des fonctions qui appellent des fonctions qui appellent…

  • le fait qu'une même fonction soit réutilisée par plusieurs autres dans des contextes différents

Je n'ai pas l'impression que cette structure apparaisse clairement quand on n'appelle que des fonctions de la STL, parce qu'on a pas encore vu le concept de fonction, et que du coup on ne pense pas ces fonctionnalités comme des fonctions. Bref, je pense que faire le lien entre la notion de fonction et celle des algorithmes de la STL sera plus compliqué dans ce sens, plutôt que de dire "voilà ce qu'est une fonction, jouez avec vos fonctions simples le temps d'un exo ou deux, et puis maintenant on va voir des exemples de fonctions bien pensées à travers leur interface".

Après, je suis conscient que tu fais là quelque chose de simplement différent de tous les autres cours du monde, et que c'est peut-être aussi ça qui me gêne inconsciemment (alors que ce n'est en rien une raison rationnelle d'être en désaccord).

  • étudier l'existant pour le comprendre et le copier
  • penser en premier en termes d'interfaces ("comment ma fonction sera utilisée ?") que d’implémentation ("comment ça fonctionne dedans ?")
  • et au final, si le cours n'est pas trop mauvais, prendre l'habitude de penser en termes d’abstractions.

Je pense que ces trois objectifs seraient encore plus clairs pour le lecteur s'ils arrivaient juste après une explication de ce qu'est une fonction et en quoi elle se décompose ultimement en instructions simples. Ne pas savoir ce qui se passe sous le capot laisse la question ouverte et peut distraire l'étudiant (suis-je condamné à être limité par la STL ?), alors que l'avoir montré (même rapidement) et dire "Bon, maintenant on va pas se demander comment écrire une fonction, mais se poser la question : qu'est-ce qu'une fonction bien conçue ?" et entrer en profondeur dans la STL pour illustrer ça me semble plus logique pour un débutant. Après ça reste un avis personnel.

Après, si j'ai bien compris tu as déjà fait des formations de C++ alors que personnellement, je n'ai enseigné que Python à un niveau très basique et débutant. J'imagine que tu as donc déjà testé cette approche et eu des bons retours dessus. Mais ce choix me laisse donc toujours un peu perplexe, et vu que tu invites à la critique constructive, je me suis dit que j'allais me lancer :)

Sinon, j'ai croisé une ou deux erreurs de typo dans les chapitres en cours de rédaction. Si je les re-survole et que je les retrouve, veux-tu que je te les signales dans ce topic ?

+0 -0

Après, si j'ai bien compris tu as déjà fait des formations de C++ alors que personnellement, je n'ai enseigné que Python à un niveau très basique et débutant. J'imagine que tu as donc déjà testé cette approche et eu des bons retours dessus. Mais ce choix me laisse donc toujours un peu perplexe, et vu que tu invites à la critique constructive, je me suis dit que j'allais me lancer :)

Non, je n'ai jamais testé cette approche. Je n'enseigne pas, je m'occupe plutôt de mises a jour C++11/14, de Qt5, de qualité du code, etc. Donc avec des personnes qui connaissent déjà C++ (et qui généralement de bonnes bases).

Du coup, sur les autres remarques…

Je n'ai pas l'impression que cette structure apparaisse clairement quand on n'appelle que des fonctions de la STL, parce qu'on a pas encore vu le concept de fonction, et que du coup on ne pense pas ces fonctionnalités comme des fonctions. Bref, je pense que faire le lien entre la notion de fonction et celle des algorithmes de la STL sera plus compliqué dans ce sens, plutôt que de dire "voilà ce qu'est une fonction, jouez avec vos fonctions simples le temps d'un exo ou deux, et puis maintenant on va voir des exemples de fonctions bien pensées à travers leur interface". Après, je suis conscient que tu fais là quelque chose de simplement différent de tous les autres cours du monde, et que c'est peut-être aussi ça qui me gêne inconsciemment (alors que ce n'est en rien une raison rationnelle d'être en désaccord).

Il serait prétentieux de dire que ce cours permet d'apprendre cela correctement. Pour le moment, c'est un objectif, mais sans recul et sans retour des débutants sur le moyen termes (probablement 2-3 ans après que le cours sera fini d’être rédigée), il n'est pas possible de savoir si ce choix est correct.

Par contre, j'ai réalisé en progressant dans la rédaction qu'il est difficile d'attendre le chapitre sur les fonctions pour introduire ce que c'est. J'en parle donc avant, mais il faut peut être que je fasse une petite partie d'intro sur les fonctions et comment les appeler au début du cours. Idem pour les classes.

Sinon, j'ai croisé une ou deux erreurs de typo dans les chapitres en cours de rédaction. Si je les re-survole et que je les retrouve, veux-tu que je te les signales dans ce topic ?

Tu peux même corriger directement si tu veux.

Édité par gbdivers

+0 -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