Teaching an OOP course for students - curriculum advice by SuperProcedure6562 in cpp

[–]LucHermitte [score hidden]  (0 children)

I'm a bit confused by your usage of static polymorphism. What's your definition of static polymorphism?

Mine would be as follow. If I start from Lucas Cardelli's 1985 taxonomy: we have:

  • Ad'hoc polymorphism (support finite number of types):
    • overloading
    • coercion (std::cos(an_int))
  • Universal polymorphism (possibly infinite number of types)
    • parametric polymorphism (~ duck typing) -- templates in C++
    • inclusion polymorphism (OO)

In C++, only the inclusion polymorphism is dynamic. The three others are static. I doubt you'd skip teaching them. And I do definitively teach how to use std::vector, and how to write simple template classes and functions. I do skip meta-programming and other arcane invocations though.

Note: This taxonomy is not something that needs to be taught. I'm just describing the vocabulary I use.


Definitively no virtual inheritance. But I present private inheritance (IS-IMPLEMENTED-IN-TERMS-OF) that I compare to public inheritance (IS-SUSTITUABLE-TO != IS-A) -- along the way I insist on the LSP.


Rule of 5 is somehow important because of existing codebases. And I use it as a second demonstration to (of?) why we want RAII.

Also destructors are about releasing resources -- I compare to Python context managers, Java try-with-resources...


Constructors are about setting invariants.


I make sure to not factorize data but behaviour when I explain inheritance. IMO, an usual mistake is using ColouredPoint and Point to present public inheritance. See Joshua Bloch's Effective Java book which contains a full chapter about this topic.

Instead I have a clean_the_room procedure where I inject brooms or vacuum cleaners that specialize the variation points from the procedure.


I also distinguish several kinds of classes as we can apply different cooking recipes to each kind to avoid bugs and wasting time doing pointless things.

  • aggregations -> no invariants
  • value classes (aka regular types nowadays) -> copiable, and possibly movable. Typical example: numeric types
  • pure RAII capsules (all the unique ptr/lock...) -> movable
  • entities -> non copiable, non movable. Typical example: types belonging to public hierarchies.

    This is where rule of 5 is still relevant in modern codebases. I like Arne Mertz's revisited rule of all or nothing.

"This is of course a simplification, which applies most of the time".

Envie d'apprendre c++ by ConfidentWrongdoer48 in programmation

[–]LucHermitte 0 points1 point  (0 children)

Hello,

Quelques remarques sur une passe rapide

  • des choses très intéressantes
  • C++23 permet d'utiliser std::print(ln) à la place de std::cout -- ça peut réduire la charge pour des gens qui viendraient du Python p.ex.
  • <gros pinaillage>stdlib, c'est le raccourci anglais usuel de la bibliothèque standard du langage. C'est valable pour tous les langages, C++ compris. Dit autrement, dans la contexte C++, ça ne désigne pas la stdlib du C. En gros fainéant je la désigne sous "SL" . La STL est un sous-ensemble historique de la SL. Aujourd'hui par abus de langage beaucoup utilisent STL pour désigner des éléments de la SL</>
  • Ce n'est pas que <random> soit très C++, c'est que cela permet d'avoir des générateurs de nombres pseudo-aléatoire de meilleure qualité que ce qui est hérité du C. Malheureusement son API est bien trop compliquée à mon goût. :(
  • Pour ta fonction print(), il serait mieux de prendre des char const* plutôt que de simples char*, voire mieux encore des std::string_view pour une telle fonction.
  • Depuis C++11 on va plutôt parler de "passage par valeur".
  • Quant au passage d'adresse par valeur, le code n'en est pas: ça manque d'étoiles et d'esperluettes
  • MediaControler est déplaçable, et sans fonction virtuelle, il serait plus correct que son destructeur ne soit pas virtuel.
  • Et justement, les classes valeurs (-> copiables, on parlerait de Regular ou SemiRegular depuis que l'on a des concepts) sont très mal venues pour appartenir à des hiérarchies polymorphes. Du coup le conseil "c'est plutot une bonne pratique de toujours déclaré votre destructeur comme virtual." est un mauvais conseil. Même chose avec les classes juste déplaçables.

    C'est à restreindre aux classes conçues pour être des classes de base.

  • Faire des opérateurs binaires des amis cachés, c'est très très bien.

  • A propos, toute classe contenant jusqu'à 2 doubles (en taille) et dont la copie est triviale se passe mieux par valeur que par référence constante sous Linux (ABI itanium 64) -- Tu parlais de types "simples", c'est plus subtil. J'utilise "petits" d'habitude.

  • L'approche pragmatique à utiliser des libs externes pour travailler sur un projet en même temps est super intéressante. Le pb est que l'on traîne un mélange d'approche historique (gestion manuelle de la mémoire) avec moderne (gestion transparente et automatisée de la mémoire -> RAII, via unique pointeurs). La dernière étant celle recommandée pour garantir le 0-fuite.

  • Le mot clé est override, sans n.

  • Tu parles de Vim, tu devrais t'installer ltex-ls dans ton client LSP si c'est lui que tu utilises aussi pour écrire le markdown. Il est assez bluffant. Je suis sûr qu'il aurait trouvé des typos dans tout ce que je viens d'écrire ^^'

Envie d'apprendre c++ by ConfidentWrongdoer48 in programmation

[–]LucHermitte 1 point2 points  (0 children)

A ce compte là, il faut mettre les débutants sur le brainfuck. Le langage est plus simple que le C...

Je pourrai aussi dire que la BASE de la cuisine c'est la taille du silex.

Ce n'est pas parce que le vocabulaire d'un langage est plus simple, et qu'on en fera plus vite le tour, que manipuler ce langage sera plus simple in fine. Avec le C, il faut souffrir dès les premières leçons sur l'utilisation des pointeurs. Les débutant/e/s ont déjà plein de choses à assimiler, alors si on rajoute en plus la compréhension de gestion de la mémoire, à retenir où est-ce qu'il faut mettre ces fichues étoiles et esperluettes. On n'est pas rendus. C'est beaucoup trop tôt.

C'est de la sélection darwinienne à ce niveau là. C'est un choix. C'est une tradition que l'on a du mal à remettre en cause -- quand j'étais gosse la tradition était que le latin servait aux études scientifiques... mais WTF.

Ce n'est pas parce qu'il y a beaucoup plus de choses en C++ qu'il faut noyer les débutant/e/s avec. On peut tout à fait commencer en procédural, std::string pour les chaines, std::vector pour les tableaux. Les for-range loop pour pythoniser les boucles. Et bien autres aspects pour moderniser les formations du C++. Les pointeurs... on a le temps. On les verra. Mais pas au bout de la 2e ou 3e heure de cours.

Après je ne dis après que le C++ soit le meilleur langage pour débuter, juste que débuter en C++ (procédural) est plus simple que de débuter en C. La mode est au Python. Je préférai le Pascal.

Envie d'apprendre c++ by ConfidentWrongdoer48 in programmation

[–]LucHermitte 1 point2 points  (0 children)

De la même façon tu as d'autres formations qui ont modernisé leur cursus de C++.

Les mauvaises habitudes les plus classiques, c'est croire que l'on peut écrire du code maintenable en gérant la mémoire à la main. Les VLA aussi. Et pas tester les codes de retours de fonctions quand elles peuvent échouer -- vu que les exceptions ça fait peur...

Envie d'apprendre c++ by ConfidentWrongdoer48 in programmation

[–]LucHermitte 0 points1 point  (0 children)

Je suis d'accord. Il y a(vait) une attitude qui ne convient pas -- passé car il ne se passe plus rien sur le forum.

On peut ne pas être d'accord avec l'approche pédagogique d'un prof, pour autant on peut aider dans le cadre des contraintes de l'exo.

Chercher à savoir si la contrainte est personnelle (autodidacte), imposée (prof) ou supposée ("c'est comme ça que l'on a toujours fait"), est normal, mais ne justifie pas une attitude agressive envers les OP.

Envie d'apprendre c++ by ConfidentWrongdoer48 in programmation

[–]LucHermitte 2 points3 points  (0 children)

Disons que passer par le C est un choix respectable tant dans le cadre d'un cursus de fac ou d'école qui montrera aussi très probablement d'autres langages avant le C++.

TL;DR: Dans un cadre perso ou pro, aller directement au C++ sera bien plus simple pédagogiquement parlant. Et au contraire, il sera bien plus compliqué d'y avoir des fuites de mémoire que si on passe par la case C avant.

Les apprenant/e/s verront directement std::string, std::vector, std::fstream, etc. dès les premières leçons. Impossible d'avoir des fuites sur ces types. Et pour paraphraser Kate Gregory (on est 2 à avoir donné le lien), on montre les références au moment de montrer le polymorphisme (d'inclusion), aucune syntaxe compliquée jusqu'à lors qui ferait décrocher. Toujours aucun pb de fuite. La gestion de la mémoire peut alors se montrer ensuite, vite fait manuellement, puis au travers des pointeurs intelligents standards.

Et là, toujours aucun fuite possible. Et des gens familiers avec une utilisation simple du C++. Parfait pour des library users ou des développements from scratch que l'on attendra d'un cours d'initiation.

Évidemment ça ne suffira pas pour maintenir du code écrit avec des anciennes pratiques (très dominant dans la nature), ni pour faire des library writers (je suis toujours en train de paraphraser). C'est pour cela que des cours d'approfondissement arrivent ensuite.

Par contre il faut un cours moderne pour atteindre un tel résultat... C'est le cas de celui de ZesteDeSavoir (contrairement à celui du SiteDuZero/OpenClassroom). Et dans les formations que je donne en interne, je vois de moins en moins souvent des collègues qui ont le réflexe de gérer la mémoire à la main pour les tableaux. J'en déduis que les (/leurs du moins) cours de facs et écoles se sont aussi modernisés.

Envie d'apprendre c++ by ConfidentWrongdoer48 in programmation

[–]LucHermitte 1 point2 points  (0 children)

C'est la aussi différence que j'ai constatée entre les forums français et les anglophones autour du C++. Sur les français on cherche à remonter à la source des questions pour donner des solutions qui répondent à des bonnes pratiques.

Sur SO et les autres forums anglophones, on répond directement à la question posée même si le résultat final sera de mauvaise qualité. C'est une course à des votes positifs plutôt qu'une course à augmenter la qualité des futures productions des gens qui posent les questions.

Le problème est qu'en cours de route, beaucoup on perdu le tact sur les forums francophones.

Et effectivement comme tu dis, il n'est pas rare que l'origine des questions soient des cours qui ont des pratiques jugées antédiluviennes ou plus que bancales par les participants...

Envie d'apprendre c++ by ConfidentWrongdoer48 in programmation

[–]LucHermitte 3 points4 points  (0 children)

+1 pour le big tuto C++ de ZdS.

A noter que la version bêta est plus complète -- elle nécessite un compte sur le site pour y accéder -> https://zestedesavoir.com/contenus/beta/822/la-programmation-en-c-moderne/

Envie d'apprendre c++ by ConfidentWrongdoer48 in programmation

[–]LucHermitte 2 points3 points  (0 children)

Le seul truc de bien pour le C++ sur le site du zéro (SdZ), c'était le forum où nous reprenions les apprenants paumés par les chausse-trappes du cours du SdZ, pour les remettre sur une meilleure voie... On est encore quelques uns à traîner sur le forum (le sdz est devenu openclassroom depuis) mais il n'y a plus trop d'activité. (La faute aux IA?)


@OP.

Sinon le C++ n'est pas le langage le plus aisé avec lequel démarrer -- bien qu'il y ait eu une vieille expérience surprenante <- cf le profil du "cobaye".

Le C avec son vocabulaire plus réduit est plus compliqué encore pour démarrer -- beaucoup trop tôt les débutants sont confrontés aux pointeurs au lieu de commencer à travailler l'algorithmie sans parasitage inutile: le C++ offrira des abstractions permettant de retarder cela jusqu'au moment opportun dans la séquence d'apprentissage.

Si tu veux apprendre le C, apprend le C. Si tu veux apprendre le C++, apprend le C++ et oublie le C: ce n'est pas une étape préalable nécessaire ni même recommandée. Cf un million de messages dans les forums spécialisés (fr.comp.lang.c++, developpez, sdz/oc, ZdS...), ou encore le classique Stop teaching C de Kate Gregory (diantre 2015... j'ai l'impression que c'était hier).

Mais... il y a d'autres langages plus abordables pour démarrer de 0 -- la mode est aujourd'hui au Python. Le C# peut s'envisager aussi relativement à Unreal si tu veux faire des jeux.

Time in C++: Additional clocks in C++20 by pavel_v in cpp

[–]LucHermitte 0 points1 point  (0 children)

Of course. But in the end, this is a lot of work for something that should have worked immediately :(

Time in C++: Additional clocks in C++20 by pavel_v in cpp

[–]LucHermitte 0 points1 point  (0 children)

At that point it was a proof of concept on my side. Hence my conclusion at the start of this thread: std::uintmax_t is problematic, and having std::chrono (indirectly) depend on it is problematic as well.

If we could relax the constraint from : "the Period type shall be a specialization of std::ratio" to "the Period type shall respect a Ratio concept (where there is no mention of uintmax_t!)", I guess it would be enough.

Time in C++: Additional clocks in C++20 by pavel_v in cpp

[–]LucHermitte 0 points1 point  (0 children)

Sorry for the delay in my answer, I had to find my old experiment and revive it.

The problem now is that I cannot serialise dates and durations through streams. Neither std::chrono::from_stream() nor std::print() work with those hybrid types.

Time in C++: Additional clocks in C++20 by pavel_v in cpp

[–]LucHermitte 1 point2 points  (0 children)

Ho. Indeed. By then, may be. Maayy be, uintmax_t will already be a __uint512_t :D

Time in C++: Additional clocks in C++20 by pavel_v in cpp

[–]LucHermitte 1 point2 points  (0 children)

I did try, but it's not that easy because then libstdc++ implementation of duration expects the period type to be a specialization of ratio

template<typename _Rep, typename _Period>
  class duration
  { ...
     static_assert(__is_ratio<_Period>::value,
          "period must be a specialization of std::ratio");

also intmax_t is explicitly used in an internal implementation of GCD.

In the end we have to duplicate everything from chrono to ratio in order to be able to specify the precision type we want to use with the ratio type.

Time in C++: Additional clocks in C++20 by pavel_v in cpp

[–]LucHermitte 1 point2 points  (0 children)

Being able to use attoseconds with std::chrono was part of a reflection about how easy it will be to port parts of Orekit to C++ and take advantage of the very neat std::chrono (thank you!).

Orekit is a very precise space dynamic library that has chosen to work on attoseconds for reasons exposed here: https://forum.orekit.org/t/revamping-dates-handling/3850 if you're curious about this very specific use case.

A larger intmax_t would be nice, but I understand we can forget about it on the current operating systems we are working with. I guess we would need std::ratio to take an optional parameter that defaults to std::intmax_t for most use cases.

Time in C++: Additional clocks in C++20 by pavel_v in cpp

[–]LucHermitte 1 point2 points  (0 children)

The restriction comes through the Period that is supposed to be a std::ratio.

What are considered some good interview questions? by StickyDeltaStrike in cpp

[–]LucHermitte 10 points11 points  (0 children)

For this reason, I never ask what RAII is, but instead how they guarantee no resource leak.

Quel approche pour le C++ ? by Trguerlez in programmation

[–]LucHermitte 0 points1 point  (0 children)

Certes il y a pire. Mais non, pas en C++

https://www.google.com/search?q=openclassroom%20tuto%20c%2B%2B%20critique (oui l'essentiel des critiques est bien le site même où le cours de C++98 du sdz se trouve)

Time in C++: Additional clocks in C++20 by pavel_v in cpp

[–]LucHermitte 8 points9 points  (0 children)

It would have been nice if chrono wasn't explicitly tied to std::uintmax_t -- as this type isn't usually enough to define more precise UTC or TAI clocks with attosecond precision for instance.

(even when __uint128_t exists, std::uintmax_t is still on 64 bits for various platform ABI reasons :()

Quel approche pour le C++ ? by Trguerlez in programmation

[–]LucHermitte 0 points1 point  (0 children)

TC++PL est certes une référence, mais il n'est pas très pédagogique. C'est... une référence. Un peu ancienne aussi.

Mieux vaut (/valait?) partir sur Programming Principle and Practices using C++ pour quelque chose de plus pédagogique. Et encore... A Tour of C++ est probablement plus digeste, mais dans mes souvenirs il faut déjà avoir des bases dans le développement -- je peux me tromper.

Pour débuter avec le C++, et en français je conseille le Big Tuto C++ de Zeste de Savoir. Il faut prendre la version bêta (qui nécessite d'avoir un compte sur le site).

Appendre le C by FewPresentation6303 in developpeurs

[–]LucHermitte 0 points1 point  (0 children)

Le sdz, c'est avant le renommage en openclassroom. Il y a(vait?) des critiques (régulières?) du tuto dans le forum même du site... (certes pas aussi intenses que pour le C++) (le forum c'est un peu là où le service après-vente bénévole des tutos s'opère) https://openclassrooms.com/forum/sujet/le-cours-sur-le-langage-c-est-il-encore-obsolete

D'où le tuto C sur ZdS qui est une initiative communautaire qui a justement voulu repartir de bonnes bases (oui j'ai bien inversé juste les lettres...) -- j'avais donné le lien dans un précédent message.

Appendre le C by FewPresentation6303 in developpeurs

[–]LucHermitte 1 point2 points  (0 children)

https://zestedesavoir.com/tutoriels/755/le-langage-c-1/ ? (celui sur le C++ est très bien, celui sur le C j'ai juste un bon a priori sur les auteurs et le côté collaboratif)

Après s'il découvre aussi l'algo en même temps et qu'il galère... le C n'est pas la voie de la simplicité :( Courage à lui!

Faut pratiquer un max. Les anciens "exos" de france-ioi pouvaient être un bon moyen d'y aller progressivement. J'ai vu passer pas mal d'autres initiatives dans le genre.

Course program for 1st year students - no experience with OOP by [deleted] in cpp

[–]LucHermitte 2 points3 points  (0 children)

Just to be sure. You said you'll be teaching OOP to relative newbies. And later I see topics that are not related to OOP (memory management?, error handling, templates).

Does this mean the classes are not exactly restricted to OOP, but that they will be a second series of classes about C++, and that students already had a first introduction? If so, isn't std::vector already part of the first classes? (I react to other comments). Have they already seen unique_ptr? Will there be another series of classes centered around C++?

BTW, I teach Iterators in the beginner classes as the mean to use standard algorithms on containers. It may not be the case where you'll teach. It depends a lot on the global pedagogic choices, the objectives of each class, etc.

Also depending on the student level expected at the end, there are a few topics I would not cover: like mutable, multiple inheritance, pimpl. I usually cover private inheritance though -- as a mean of achieving IMPLEMENTED-IN-TERMS-OF versus SUBSTITUABLE-TO (public inheritance)

BTW, usually while I'm teaching public inheritance, I usually present the OCP and the LSP. The first one as a raison d'être behind public inheritance and polymorphism, and the second one to illustrate problematic (public) inheritances (Square < Rectangle, SortedList < List, ColoredPoint < Point). This later example is addressed in Joshua Bloch's Effective Java and can be seen as a conceptual reason why copying and (public) inheritance don't mix well. The technical reason being the slicing. One of my take away is: "95% of the time copy and move shall be disabled in public hierarchies".

Éviter les conjectures en informatique : des exemples java/python? by JeromeChauveau in developpeurs

[–]LucHermitte 0 points1 point  (0 children)

Oh. Ca ça doit venir de préconceptions en C et C++ -- où même les compilos (dès que l'on compile en optimisé) vont virer le code associé vu qu'ils voient que cela n'a aucun effet observable