La programmation en C++ moderne

Au fait, il y a un lien vers mon ancien cours C++ dans l’intro. Le lien n’est plus valide, il faudrait le supprimer.

Je suis en train de bosser sur des exos pour le cours et donc je relis rapidement le cours. Quelques remarques.

Pour la partie histoire, culture general, le comite et choix de design du C++, il y a un excellent (et tres long) article de Stroustrup: "Histoire du C++ : Thriving in a Crowded and Changing World: C++ 2006–2020". Il est a jour (publie cet ete) et gratuit. Ca serait bien de l’ajouter dans le cours quelque part. https://www.stroustrup.com/hopl20main-p5-p-bfc9cd4—final.pdf

Chapitre 1

Au contraire, le C++ continue d’évoluer à tel point qu’on décide au début des années 1990 de le normaliser, c’est-à-dire d’en établir les règles officielles.

Peut être préciser ? Les règles des autres langages sont "officiels" aussi, dans le sens où il y a une instance qui décide des règles pour tout le monde.

Peut etre que ca serait pas mal de juste mentionner qu’il s’agit de l’Organisation Internationale de Normalisation (ISO). Et peut être utiliser le terme "norme" que "règle".

EDIT : je vois que vous en parlez ensuite. A mon sens, ce n’est pas nécessaire d’en dire plus, mais peut être juste citer l’ISO plus tôt.

Note : a la lecture, on peut penser qu’il y a causalité, c’est a dire que le C++ a été normalisé à l’ISO parce qu’il continue d’évoluer.

Enfin, sachez qu’il existe une référence ultime appelée la norme, produit par un organisme de validation international appelé l’ISO, qui explique tous les détails et les règles du C++ mais qui est un document complexe et très largement hors de portée pour vous.

Si on ne connaît pas l’ISO, on pourrait peut être penser que c’est une organisation spécifique au C++.

Proposition pour la première partie :

Finalement, en 1983, son créateur, estimant que le nom de son langage était trop réducteur aux vues de tous les ajouts faits par rapport au C, décida de le renommer C++. Mais l’histoire ne s’arrête pas là. Au contraire, le C++ continue d’évoluer à tel point qu’on décide au début des années 1990 de le normaliser, c’est-à-dire d’en établir les règles officielles. Ce travail de longue haleine s’acheva en 1998 ; cette version est ainsi souvent nommée C++98. Ensuite, en 2003, des corrections ont été apportées et l’on obtint C++03.

Par :

Finalement, en 1983, son créateur, estimant que le nom de son langage était trop réducteur aux vues de tous les ajouts faits par rapport au C, décida de le renommer C++. Mais l’histoire ne s’arrête pas là et le C++ a continué d’évoluer depuis les années 90.

Pour garantir la qualité et la pérennité du C++, le langage a été proposé à l’Organisation Internationale de Normalisation (ISO). Cela a abouti à publication d’une première version officielle du C++ en 1998, corrigée et complétée en 2003. Ces normes sont appelées C++98 et C++03.

Pour la seconde partie :

Enfin, sachez qu’il existe une référence ultime appelée la norme, produit par un organisme de validation international appelé l’ISO, qui explique tous les détails et les règles du C++ mais qui est un document complexe et très largement hors de portée pour vous.

par :

Enfin, sachez qu’il est possible de consulter la norme officielle publiée par l’ISO, qui explique tous les détails et les règles du C++. Mais ce document est complexe et très largement hors de portée pour vous.

Chapitre 2

Les explications qui suivent seront peut-être périmées ou inexactes. Nous en sommes désolé, mais cela demande beaucoup de travail que de les maintenir constamment à jour. Vous pourrez néanmoins trouver un tutoriel français ici, sur le site de @gbdivers, un spécialiste de Qt.

J’ai commencé à mettre a jour mon tuto sur l’installation de Qt pour Qt6. Le nouveau lien est : http://guillaumebelz.github.io/qt6/installation

Le point d’entrée

Peut être préciser (puisque la question revient régulièrement sur les forums) que la fonction main :

• est obligatoire
• sa signature est imposée
• est unique
• ne peut pas être appelée

Bonjour,

En relisant les premiers chapitres, je constate qu’a la fin de ce chapitre, le lien sur la blague de "l’humour polonais" affiche :

"Vidéo non disponible Cette vidéo inclut du contenu de Studio Filmowe Kadr, qui l’a bloquée pour des raisons de droits d’auteur."

Dans le chapitre https://zestedesavoir.com/contenus/beta/822/la-programmation-en-c-moderne/le-debut-du-voyage/le-conditionnel-conjuge-en-c/#3-else-sinon, quand je clique sur "Image originale tirée du tutoriel sur le langage C.", j’ai l’erreur

"Erreur 403 Vous n’avez pas les droits suffisants pour accéder à cette page."

Cordialement.

Je pose ça, là, comme ça…

:clap:

Salut à tous.

Je suis en train de mettre à jour le chapitre sur le découpage en fichiers pour y intégrer les modules, mais je me rend compte qu’il y a encore assez peu de ressource sur Internet. La question qui me turlupine est de savoir si on doit séparer l’interface de l’implémentation, un peu comme avec le système hérité du C, ou si on peut tout mettre dans le même fichier.

Je n’arrive pas à trouver de ressources là-dessus, à part ceci, mais qui ne répond pas à la question de savoir quels sont les avantages et inconvénients des deux façons de faire.

Salut à tous.

Un très gros morceau arrive avec cette mise à jour.

• J’ai commencé à intégrer les nouveautés de C++20. Pour les ranges c’est bon, les lambdas templates c’est bon, pour les modules, je suis un peu bloqué par l’état des implémentations actuelles, pour les concepts, dans le chapitre introductif aux templates, il n’y a pas encore beaucoup d’intérêt à les introduire, je pense plutôt au chapitre sur les classes templates.
• J’ai écrit l’énoncé du Javaquarium ainsi qu’une correction. Y’a des choses qui ne vont pas et qui sont à améliorer, mais gardez à l’esprit que c’est une correction pour lecteurs, donc y’a des choses qu’on pourrait changer ou améliorer avec des connaissances plus avancées en C++ (notamment les classes templates, pour faire des politiques). Il y a notamment l’utilisation de final et les déclarations anticipées de classes dont je n’ai pas parlé dans le cours jusqu’à maintenant.
• J’ai finalement décidé de parler de la sémantique de mouvement après les handles, mais sans aborder les optimisations qu’elle permet, puisque c’est un sujet avancé.
• Je compte faire une repasse sur Boost et SFML pour mettre à jour les instructions d’installation, ainsi que sur CMake, pour utiliser des fonctionnalités plus modernes (avec @G’k).

Merci à tous pour vos conseils et votre aide, on approche de la fin !

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Salut à tous.

Petite mise à jour pour parler de l’opérateur <=>.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Salut à tous.

J’ai commencé à parler des principes SOLID, j’ai déjà écrit le S, n’hésitez pas à relire ou à proposer d’autres exemples qui vous semblent bien pour illustrer ces principes.

Merci d’avance à tous.

informaticienzero

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Hello.

§ Oh le bel héritage

Notons quand même que la granularité n’est pas très fine, car on est obligé d’écrire notre code supplémentaire soit avant, soit après. On ne peut pas, avec cette méthode, contrôler plus finement l’appel au code parent.

+1

Quid d’ajouter un lien/ une référence vers le design pattern template method qui est AMA bien plus flexible et propre que l’appel aux fonctions supplantées. Ce qui ne lève rien au besoin de l’aborder

Non Virtual Idiom

NVI, c’est Non Virtual Interface.

Une des visions du NVI, c’est que les utilisateurs s’intéresseront à l’interface publique, et non virtuelle. Et que les gens qui offriront des spécialisations s’intéresseront aux fonctions virtuelles privées à supplanter. EDIT: je n’ai rien dit, ça y est plus loin.

Là où le NVI rejoint le DP template method, c’est qu’historiquement il a été avancé pour faire de la PpC avec une façon qui n’est pas sans rappeler le DP template method: les contrats sont vérifiés dans la partie immuable. Ainsi les spécialisations ne pourront pas virer les assertions contrairement à l’exemple présenté ici. Il y a un exemple tordu dans mon 3e billet sur le sujet dans mon blog.

Pourtant, on ne peut pas la lancer, au contraire d’une lance justement.

Ah ah. J’adore. Super exemple. D’autant qu’il existe des haches de lancer.

SOLID

Ils ont été définis par Robert C. Martin,

Alors historiquement j’ai été corrigé il y a peu. Il me semble que c’est dans un CppCon récent sur le sujet où l’historique entre qui regroupe et qui acronymise (ça n’existe pas, mais ça devrait!) que j’ai vu qu’il y avait un autre intervenant.

Les exemples présentés dans la conf étaient très intéressants.

Les handles

En pratique, nous connaissons au moins deux types de handle.

Je ne sais comment interpréter cette phrase. On peut comprendre "nous avons déjà vu", ou "en gros ils appartiennent à une de ces deux familles".

Le second cas me parait faux car un handle sera un identifiant qui permet d’opérer des opérations sur la donnée identifiée par cet identifiant. Un service dédié saura quoi faire de l’identifiant quand on lui présentera avec une requête associée. Ainsi, p.ex. on peut ouvrir, ou fermer une socket, échanger des informations dessus. On peut ouvrir/fermer un fichier et lire/écrire des données dessus. On peut réserver/libérer un espace en mémoire vive où stocker/consulter des informations… Quasi toujours le handle sera juste un bête nombre entier (parce que plus rapide à manipuler pour le service), auquel on donnera un sens (=> sémantique) supplémentaire: handle de socket, adresse en mémoire, mutex…

Certaines opérations demandent une constante vigilance: ne pas manipuler sans acquérir. Ne pas oublier de restituer. Ne pas restituer plusieurs fois. Ne pas manipuler après avoir restituer. Bref, on voit un invariant se dégager. Et le C++11&+ fait de son mieux pour nous fournir des outils qui vont nous aider à gérer ces problématiques de gestion de la vie des handles, et encapsulation+abstraction aidant, on ne voit même plus l’entier. Certains langages font d’autres choix techniques. Certains nous laissent même à poil dans la jungle.

Les notions de slicing, je n’en parlerai qu’au moment de l’héritage.

Bonne idée, je peux ajouter ce lien quelque part. Éventuellement après la partie NVI, sachant que les deux se ressemblent quand même beaucoup ?

Merci pour la correction.

Tu parles de l’exemple Serializer, c’est bien ça ? Comment les assertions peuvent être virées ?

Rendons les choses de César à César, je ne suis pas l’auteur de cette exemple, je l’ai lu sur OpenClassrooms, mais je ne sais plus qui est l’auteur, ni où je l’ai lu. Peut-être Ksass Peuk.

Au pire, j’enlève ce passage, qui n’est pas très important.

Je vais y jeter un œil et éventuellement les reprendre, si la licence me le permet.

Je voulais dire dans le sens "Nous avons déjà vu deux types de handles dans ce cours".

NVI & TM DP

Bonne idée, je peux ajouter ce lien quelque part. Éventuellement après la partie NVI, sachant que les deux se ressemblent quand même beaucoup ?

C’est effectivement une difficulté dans la ressemblance entre ces deux choses malgré des finalités différentes. De plus, il n’y a pas vraiment de § sur les DP. Et ce DP, c’est un peu la conséquence de l’OCP/commonalities VS variabilities qui a été illustrée avec l’exemple des balais&aspi

Là où le NVI rejoint le DP template method, c’est qu’historiquement il a été avancé pour faire de la PpC avec une façon qui n’est pas sans rappeler le DP template method: les contrats sont vérifiés dans la partie immuable. Ainsi les spécialisations ne pourront pas virer les assertions contrairement à l’exemple présenté ici. Il y a un exemple tordu dans mon 3e billet sur le sujet dans mon blog. Tu parles de l’exemple Serializer, c’est bien ça ? Comment les assertions peuvent être virées ?

Zut au temps pour moi, j’avais zappé la transitions NVI -> LSP, et j’étais sur l’exemple de la compagnie. … Du coup, je me demande. Quid d’inverser l’ordre entre les deux? Montrer d’abord qu’il y a des règles à respecter, et ensuite montrer le NVI vu que c’est une solution pour assurer un minimum sur le sujet.

D’ailleurs le fait que le contrat soit dans une fonction privée et virtuelle me perturbe. Le contrat devrait plutôt être adressé au client — même si rien n’empêche des contrats internes, mais il ne faudrait pas laisser la possibilité aux enfants de les saboter.

Suite a une discussion sur le discord.

Une personne ne comprenait pas l’utilité des itérateurs par rapport à parcourir un tableau avec [].

1. peut être introduire d’autres collections en plus de vector et array, pour montrer l’intérêt des itérateurs
2. proposer un "exo" a faire, pour montrer l’intérêt des itérateurs en termes de généricité du code :

Un code simple pour parcourir une collection (pour afficher les elements):

vector<int> v = { 1, 2, 3, 4, 5 };
for (size_t i = 0; i < size(v); ++i)
    cout << v[i] << endl

La version avec iterateur :

vector<int> v = { 1, 2, 3, 4, 5 };
for (auto it = begin(v); it != end(v); ++it)
    cout << (*it) << endl

Dans chacun de ces codes, remplace vector par list et corriger le code pour que cela fonctionne.

Ca permet a la personne de comprendre que la seconde version est plus générique (ie moins de choses a modifier pour que ca fonctionne).

Parenthèse, std::erase(_if) remplace avantageusement l’idiome erase-remove depuis le C++20 https://en.cppreference.com/w/cpp/container/vector/erase2

Salut à tous

Au programme de cette bêta, plusieurs choses.

• J’ai pris en compte la suggestion de @gbdivers pour illustrer l’intérêt des itérateurs.
• J’ai supprimé la partie sur protected, puisque je ne vois pas de situation claire et à la portée d’un débutant où l’utiliser. De plus, comme le dit @lmghs mieux vaut ne pas avoir les contrats que les enfants peuvent péter car protected.
• J’ai continué sur le chapitre SOLID, n’hésitez pas à faire des remarques dessus.
• Le chapitre "Oh, le bel héritage" est un peu léger désormais, sans doute vais-je le retravailler. Peut-être y ajouter un peu d’héritage multiple, dont j’ai besoin dans l’exemple du ISP.
• Le Javaquarium n’attend que vos remarques pour rendre le code meilleur, tout en n’utilisant que les connaissances qu’est sensé avoir le lecteur à cet instant.

@Arius s’occupera de la validation. C’est la dernière ligne droite, il ne reste plus beaucoup de choses à écrire avant la fin de ce tutoriel.

Encore un grand merci à tous, si on en est arrivé là, c’est aussi grâce à vos remarques, vos suggestions et votre aide. Merci !

informaticienzero

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Salut à tous.

Au programme, la fin du chapitre SOLID.

On avance !

Merci à tous d’avance.

informaticienzero.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

C’est pas le genre de retour le plus utile, mais :

Vous pouvez consulter une liste non-exclusive

une liste non-exhaustive

C’est amusant ton exemple de voiture qui doit connaître l’état de l’intérieur du moteur, parce que dans la vraie vie beaucoup d’équipements automobiles renvoient des diagnostics sur l’état de leurs composants internes (donc ce qui n’a pas d’importance pour l’équipement qui reçoit cette info en général), plutôt que sur leur état de fonctionnement (ce qui compte du point de vue extérieur, et évidemment la panne des composants entraîne la panne des fonctions). Ça complique les interfaces de communication et crée des signaux du genre "température composant X" qui ne veut plus rien dire parce qu’il n’y a plus de mesure physique du composant X dans cette version du produit… alors que le véritable besoin "connaître l’état thermique du produit" est toujours existant.

Des liens bidirectionnels ce serait bien aussi non? De pouvoir cliquer sur un titre dans le sommaire, d’y accéder et de revenir au sommaire par ce même titre. Ou de jeter un coup d’œil à un contenu masqué et de revenir à la section de texte précédente. Et tous les autres cas où cela serait pertinent(je n’ai pas d’exemple dans le cour. Mais il y a moyen qu’il soit justifiable de faire des allez-retour entre deux notions qui s’entremêlent).

Salut à tous.

J’ai ajouté plusieurs points au chapitre avancé sur l’héritage. Ce sont des choix d’écriture qui peuvent en étonner plus d’un, notamment sur l’héritage multiple, mais je pense que c’est une bonne chose.

J’ai commencé le chapitre d’annexes pour aller plus loin, avec des liens de livres, sites et ressources. Si vous en avez d’autres, n’hésitez pas à les suggérer.

Il reste donc la correction du Javaquarium à écrire et le chapitre sur les classes templates, où je pense notamment parler de la syntaxe, des particularités et du fait que mixer templates et héritage peut être compliqué.

Merci à tous pour votre aide.

@mougnolribama : je n’ai pas compris ce que tu voulais dire par "liens bidirectionnels". Peux-tu développer s’il-te-plaît ?

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

@mougnolribama : je n’ai pas compris ce que tu voulais dire par "liens bidirectionnels". Peux-tu développer s’il-te-plaît ?

Certains sites ont un sommaire qui envoient vers le titre d’une section. Et cliquer sur ce titre renvoie sur l’entrée du sommaire. C’est un truc auquel je n’ai jamais trouvé l’intérêt vu que j’utilise régulièrement ALT + left, ou un clic droit maintenu vers la gauche (mouse gesture), ou encore… home mais visiblement certains s’en servent… Probablement fort utile sur machines sans clavier ni souris genre des tablettes ou sous forme d’ebook. Si cela peut être automatisé… foncez

Oh, le bel héritage

Je fais une passe très rapide (sans diff, c’est difficile de savoir ce que l’on a déjà lu ou pas ;))

comme tout bon exemple introductif, nous n’avons aucun invariant

C’est une vision assez personnelle, mais j’ai tendance à considérer qu’un objet a toujours un invariant invisible: est utilisable. Pour les appareils de nettoyage, on pourrait p.ex. avoir: "est dans un pièce qui existe".

[Débat autour du MI]

Je soupçonne que beaucoup de problèmes et de critiques autour de l’héritage multiple prennent leur source qu’un héritage qui ne respecte pas le LSP est vite un soucis, alors quand on multiple les origines, si le LSP n’est pas respecté sur tous les parents, on augmente de façon non linéaire les problèmes.

Il n’y a pas que le non respect du "ne pas hériter de classes concrète" qui pose soucis avec le MI.

Je pense aussi qu’il n’y a pas besoin de rentrer dans les détails pour l’instant. Mais un renvoi vers un chapitre ultérieur sur l’héritage virtuel, ou juste un mot comme quoi nous ne verrons pas l’héritage virtuel peut être le bien venu. Donner le terme pour ceux qui veulent creuser la piste.

+1 Pour la suite sur la conception d’armes & cie. Perso avant les ECS j’avais tendance à voir la solution comme une combinaison de traits (sortes de template method + strategy).

Le résumé final

• Il reste un "NV idiom" au lieu d’Interface.

SOLID

DIP

Un grand intérêt classique du DIP: pour l’écriture de tests unitaires. Quand le service que l’on veut tester dépend intimement d’un autre un peu plus complexe, il est intéressant d’injecter une version fake/mokée de la dépendance ce qui permet de tester notre code client sans dépendre d’aléas d’implémentation de la dépendance. Exemple pondu à la va vite: un protocole d’échange d’informations entre composants par requêtes http. On veut tester le comportement d’un des deux autres composants sans échanger par http ni en dialoguant avec un tiers composant potentiellement buggué.

Avec le DIP, on injecte donc la version moquée qui renvoie exactement ce que l’on attend pour le test unitaire.

Déméter

J’ai tendance à rapprocher cette loi avec le tell don’t ask

Autre

Dans mes formations, j’ai tendance à rajouter un disclaimer à propos de ces règles.

• Non respect du LSP == bug. Le reste, est un indicateur de soucis en devenir de maintenance (risque de bugs, facilité à faire évoluer…)

• DIP et ISP et LSP ne sont applicables qu’aux entités. Pas aux valeurs. Enfin, en version avec héritage ce n’est pas applicable, si on étend aux concepts du C++20, c’est de nouveau applicable.

• L’abus de tous ces principes conduit vite au FizzBuzzEnterprise, et le C++, je ne sais pourquoi, est resté un langage de pragmatiques.

Aller plus loin

Là, @lmghs démonte cinq mythes courants sur le C++

Euh… non, c’est Loic qui traduit un article de Bjarne Stroustrup.

Un autre livre un peu ancien mais dont les principes restent valables s’appelle Design Patterns - Tête la première, par Eric Freeman, Elisabeth Freeman, Kathy Sierra et Bert Bates, connus sous le nom de Gang of four

Le Gang of Four, c’est (Eric?) Gamma, (John?) Vlisside et deux autres que j’ai honteusement oublié. Leur livre qui est le point de départ du terme design pattern, est Design Pattern, Elements of reusable code(/technology?) (je crois), aka GoF par référence aux 4 auteurs, sorti en 95 avez Addisson Wesley (AW est l’éditeur de référence en matière d’ouvrages consacrés aux C++98/03, mais pas que; je n’ai pas fait attention pour la suite).

Le Design Pattern head first (?) est un autre ouvrage, très pédagogique et non typé "de référence" comme le GoF peut l’être.

Après de nombreuses critiques sont applicables aux formes de certains DP dans le contexte C++

• singleton == variable globale en smoking
• pattern command => comble l’absence de support de fonctionnel/lambda
• itérateurs du C++ qui ont une autre forme
• std::visit, plus aussi autres solutions pour le double dispatch

Salut à tous.

Merci @lmghs, j’ai pris la majeure partie de tes retours en compte. J’ai aussi mis des images pour illustrer le chapitre d’annexe, le rendant ainsi plus agréable. D’ailleurs, ta liste de bons livres C++, que tu as sur Openclassrooms dans ton profil, donne une 404.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.