La programmation en C++ moderne

Apprenez la programmation de zéro jusqu'à l'infini !

a marqué ce sujet comme résolu.

Qu’en penses-tu ?

Après, les deux idées ne sont pas incompatibles, on peut quand-même commencer à en parler au début du cours et entrer plus dans les détails une fois arrivés à l’interlude.

mehdidou99

Oui, tout est possible, c’est a vous de voir comment vous voulez structurer votre cours. Ce qui est important, je pense, est que le lecteur a conscience que le cours fait des choix pédagogique, et qu’il verra plus tard les autres choix possibles et les arguments pour/contre chacun de ces choix.

(Dans mon cours, a plusieurs reprises, je dis explicitement "dans ce cours, on fait tel choix").

+1 -0

J’aime de moins en moins la CamelCase car elle n’est pas amicale avec les mots d’une lettre, ni avec les acronymes, au hasard pour forcer le trait -> db_raii_capsule.

lmghs

Personnellement, je ne mets que la première lettre en majuscule, même pour les Db, Ok, No et compagnie. Ici, ça donne DbRaiiCapsule. Bon après, les goûts et les couleurs… ^^

Bonjour les agrumes !

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

Au programme : encore des corrections par rapport aux remarques précédentes, l’ajout d’une explication de ce qu’est l’initialisation par défaut dans le chapitre "De nouvelles structures de données", et enfin l’ajout d’un chapitre-TP. Pour l’instant, j’y ai mis uniquement l’énoncé et un corrigé possible, pour que vous puissiez à la fois faire des remarques/suggestions sur l’énoncé ainsi que sur le corrigé.

Merci d’avance pour vos commentaires.

+0 -0

Bonjour les agrumes !

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

Au programme : principalement la rédaction d’un guide de résolution pour le chapitre-TP. Ce guide était assez difficile à écrire, du coup je ne sais pas trop ce que vaut le résultat. Qu’en pensez-vous ?

Merci d’avance pour vos commentaires.

+0 -0

Bonjour les agrumes !

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

Au programme : ajout d’un paragraphe sur les prototypes de fonctions (dernier maillon manquant pour le TP-chapitre) et corrections mineures.

Merci d’avance pour vos commentaires.

+0 -0

Bonjour les agrumes !

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

Au programme :

  • Ajout d’un chapitre à part entière pour aborder quelques points de sucre syntaxique (structured bindings et surcharge d’opérateurs).
  • Ajout de sections sur les conteneurs std::unordered_set et std::unordered_map dans le chapitre sur les nouvelles structures de données.
  • Ajout de la version d’informaticienzero du corrigé du chapitre-TP. Ainsi, le lecteur a deux points de vue différents, ce qui lui montre qu’il n’y a jamais une unique solution à un problème donné.
  • Diverses petites modifications.

Merci d’avance pour vos commentaires.

+0 -0

Signalé sur le discord :

.RymAujourd’hui à 14:46

Hello, je suis en train de jeter un coup d’oeil sur le cours du zeste du savoir et en survolant les 1ere parties, je suis tombe la dessus:

####include <iostream>

on est bien d’accord que ca compile pas ca? :thinking:

Probablement un problème de markdown ?

+3 -0

II-

§5

a- Dans leur grande originalité, les concepteurs du langage l’ont appelée structure.

Euh… Du langage C, pas du C++.

b- L’identifiant de la structure suit les mêmes règles de nommage que les identifiants de variable et de fonction.

Il ne faut pas mettre variable et fonction au pluriel?

c- Vu la complexité d’utilisation des tuple, je me demande, s’il est bien juste de présenter ça dans les premiers chapitres? Je vois ça un peu comme la lambda des structures de données: On a la flemme de pondre un type nommé, de l’isoler, etc, etc. Résultat on sort un tuple. Autant avec les lambdas, il y a un intérêt à les avoir pour les algos de la lib standard, autant pour les tuples, le besoin me parait bien moins critique — pour que cela soit présenter tôt dans un cursus pédagogique. auto [x,y] = f(); sauve les tuples, mais ce n’est pas encore suffisant.

Je ne sais ce qu’en pensent les autres.


§6

d- Sur la surcharge des opérateurs. Il y a des éléments complexes qui sont occultés et qui posent régulièrement des problèmes.

De mon observation de mon exo de TP où je demande de faire en sorte de cout << (matrice1 + m2 + + m3) compile

  • j’ai beau expliquer et montrer le code où je dis que la définition doit être libre, il y en a toujours qui cherchent à définir les opérateurs en membre. Je me retrouve donc à expliquer

    • le paramètre invisible *this,
    • que A ¤ B sera résolu en A.operator¤(B), puis en operator¤(A,B)
    • et que définir operator¤(A,B) en membre revient à le définir à trois paramètres, ce qui n’est pas possible
  • je montre aussi les opérateurs composés +=, etc et comment ils peuvent simplifier l’écriture des versions non-composées
  • le retour doit être par valeur pour les nouvelles valeurs, mais par référence pour les composés
  • il est important que les paramètres soient const-correct pour accepter des rvalues. Là je fais expérimenter avec des références non constantes, et j’explique bien que l’on n’a pas envie de copier 1 millions d’éléments.
  • Je montre comment friend peut déguiser un opérateur membre en libre, mais je n’aborde pas comment cela améliore la résolution de noms.
  • Je montre la différence entre un opérateur libre et un membre en situation de conversion implicite sur c + 1 et 1 + c.

Le sujet des opérateurs est en fait assez complexe, et au final assez peu nécessaire dans notre quotidien.

PS: on ne peut pas changer les priorités relatives non plus.


§ 7

e- Le plus difficile lorsqu’on conçoit un programme

Je suis gêné car on part des données et non des cas d’utilisation.

f- Dans un vraie BD, l’artiste d’un morceau on va pouvoir l’éditer. Ce n’est pas un truc figé comme on peut l’avoir dans des systèmes métiers où les identifiants ne changent jamais. Là on est sur de la BD.

g- Mettre des relations sur des entités me perturbe. Pour moi il y a des critères différent pour les tris: par artiste, par titre, par année, par longueur, par BPM — c’est les BPM et mon appréciation que j’utilise le plus pour le tri :) avant de sélectionner ce que je passe dans quel ordre.

Pour les filtres, tout champ est bon, et on fait des tests d’égalité sur les valeurs des champs.

h- Pas sûr que l’on ait besoin d’un énuméré des actions. Je partirai tout simplement sur une table chaine -> fonction. Avec pour paramètre unique, la chaîne de caractère à finir de décoder — ici.

Merci pour tes retours. :)

Je réponds à certains en particulier, mais je prends note de tous les points.

c- Vu la complexité d’utilisation des tuple, je me demande, s’il est bien juste de présenter ça dans les premiers chapitres? Je vois ça un peu comme la lambda des structures de données: On a la flemme de pondre un type nommé, de l’isoler, etc, etc. Résultat on sort un tuple. Autant avec les lambdas, il y a un intérêt à les avoir pour les algos de la lib standard, autant pour les tuples, le besoin me parait bien moins critique — pour que cela soit présenter tôt dans un cursus pédagogique. auto [x,y] = f(); sauve les tuples, mais ce n’est pas encore suffisant.

Je ne sais ce qu’en pensent les autres.

lmghs

C’est un point de vue qui se comprend. Je pensais pareil au début, puis je me suis dit que ça serait bien, puisque ce n’est pas si compliqué que ça et que ça rend des services. À voir, comme tu dis, ce qu’en dises les autres.

d- Sur la surcharge des opérateurs. Il y a des éléments complexes qui sont occultés et qui posent régulièrement des problèmes.

De mon observation de mon exo de TP où je demande de faire en sorte de cout << (matrice1 + m2 + + m3) compile

  • j’ai beau expliquer et montrer le code où je dis que la définition doit être libre, il y en a toujours qui cherchent à définir les opérateurs en membre. Je me retrouve donc à expliquer

    • le paramètre invisible *this,
    • que A ¤ B sera résolu en A.operator¤(B), puis en operator¤(A,B)
    • et que définir operator¤(A,B) en membre revient à le définir à trois paramètres, ce qui n’est pas possible
  • je montre aussi les opérateurs composés +=, etc et comment ils peuvent simplifier l’écriture des versions non-composées
  • le retour doit être par valeur pour les nouvelles valeurs, mais par référence pour les composés
  • il est important que les paramètres soient const-correct pour accepter des rvalues. Là je fais expérimenter avec des références non constantes, et j’explique bien que l’on n’a pas envie de copier 1 millions d’éléments.
  • Je montre comment friend peut déguiser un opérateur membre en libre, mais je n’aborde pas comment cela améliore la résolution de noms.
  • Je montre la différence entre un opérateur libre et un membre en situation de conversion implicite sur c + 1 et 1 + c.

Le sujet des opérateurs est en fait assez complexe, et au final assez peu nécessaire dans notre quotidien.

PS: on ne peut pas changer les priorités relatives non plus.

lmghs

Je sais, il manque de nombreuses choses dans ce chapitre. En fait, c’est plus une introduction à la surcharge qu’un guide complet. On reviendra plus en détails dessus dans la quatrième partie.

Après, des points que tu abordes, il faut noter que la plupart ne nous concernent pas dans ce cas, puisque le lecteur ne sait pas qu’une structure peut contenir des fonctions. Il n’a aucune idée de ce qu’est l’encapsulation, des fonctions membres vs libres, this, etc.

Par contre, au moment où on reviendra dessus, oui, il faudra tenir compte de ce que tu as dit.

g- Mettre des relations sur des entités me perturbe. Pour moi il y a des critères différent pour les tris: par artiste, par titre, par année, par longueur, par BPM — c’est les BPM et mon appréciation que j’utilise le plus pour le tri :) avant de sélectionner ce que je passe dans quel ordre.

lmghs

Peux-tu détailler ta pensée ici ? Je ne pense pas avoir compris correctement.

h- Pas sûr que l’on ait besoin d’un énuméré des actions. Je partirai tout simplement sur une table chaine -> fonction. Avec pour paramètre unique, la chaîne de caractère à finir de décoder — ici.

lmghs

Là, tu parles sans doute de mon code. C’est vrai. Je me suis dit que ça ferait un cas plus concret d’utilisation des énumérations, mais dans le fond, tu as raison.

Encore merci pour tes commentaires !

g- Je fais référence au code du TP. En proposant des opérateurs de comparaison standards, tu (/vous?) pousses les objets vers la famille des réguliers. Si on reprend le vieil article de Henney (http://www.two-sdg.demon.co.uk/curbralan/papers/ObjectsOfValue.pdf), la sémantique de valeur, c’est la copie et la comparaison. Bref, ici nous sommes avec des données qui ont clairement l’équivalent de clés primaires pour les identifier, i.e. des entités.

D’ailleurs, la modélisation proposée est réductrice: l’ordre pour comparer deux musiques est toujours le même. En vrai, l’ordre est "multiple". Il n’y en n’a pas qu’un possible. On peut trier selon les titres, selon les artistes, selon les BPM (Beats per minute), etc. La modélisation type ici est de proposer autant de fonctions de comparaison (voire lambdas) que de champs.

Les opérateurs sont donc doublement inadaptés: Ils limitent donc le champs des possibles, et ils donnent le signal valeur à des données qui sont définitivement des entités. Pour le deuxième point, je préfère le signaler en avance, car je me souviens d’armes copiées dans tous les sens. J’aurai dû plus insister dans le passé que cela n’allait pas.

Salut à tous,

Au programme, la fin du chapitre sur la séparation en fichier. Il ne nous reste maintenant qu’à corriger le T.P, suite aux remarques de @lmghs, et par conséquent la section qui y est consacrée dans le chapitre sur le découpage. Nous attendons aussi toute autre remarque et vous remercions de ce que vous faites pour aider à améliorer ce cours. :)

Merci d’avance pour vos commentaires.

Bonjour les agrumes !

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

Au programme : après les remarques de @lmghs, nous avons choisi de garder uniquement le corrigé de TP de @informaticienzero, car il était plus facilement adaptable sans trop compliquer les choses. Il a été modifié en conséquence.

Sur le chapitre-TP, reste à réécrire le guide de résolution en partant des besoins pour aller vers les problèmes atomiques, et pas le contraire. J’aurai appris une chose : c’est plus dur qu’il n’y paraît de coucher sur papier la manière dont on réfléchit à un programme de sorte que ça reste pédagogique !

Merci d’avance pour vos commentaires.

+1 -0

Bonjour les agrumes !

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

Modification du chapitre sur le découpage en fichiers pour le rendre cohérent avec le nouveau corrigé de TP.

Il reste à réécrire le guide de résolution de TP et à faire une relecture générale du cours pour pouvoir publier les deux premières parties en intégralité !

Merci d’avance pour vos commentaires.

+1 -0

Salut,

Quelqu’un a une idée d’étude de cas pour la quatrième partie (juste après l’interlude "Etre un développeur") ? Je pensais faire un petit RPG, mais si vous avez des idées ludiques un peu plus originales, je suis preneur !

Pour rappel, le lecteur n’aura à sa disposition à ce moment du cours que ce qui est abordé dans les deux premières parties : pas de POO, etc.

Merci d’avance ! :)

+0 -0

Un petit Pokemon (ou similaire) textuel, ça peut être sympa. Dans le fond, ça reste un genre de RPG, mais ça change des classiques de la fantasy. On peut imaginer faire des phases d’exploration et d’autres de combat. Ça implique des concepts autour des conditions et des boucles. La gestion de l’équipe de pokemons fait intervenir des structures de données plus ou moins complexes.

Un petit jeu tactique au tour par tour sur un grille carrée peut être amusant (à la XCOM). On dispose ses bonshommes, ils ont des points d’actions pour se déplacer ou attaquer, on peut avoir différentes classes et introduire plein d’autres choses.

Ça peut être assez fun, parce que ça montre que les "vrais" jeux ne sont pas incroyablement compliqués à programmer (du moins la logique) et que la preuve de concept est accessible aux débutants.

Oui je pensais à remplacer par un petit Pokémon justement, ça me botte plus qu’un RPG classique. C’est une super idée, merci.

Niveau légal, j’ai le droit de réutiliser les mêmes noms que Nintendo ?

EDIT : Je préfère le Pokémon à ton autre idée parce que c’est plus ambitieux, c’est mieux pour l’échelle d’une étude de cas.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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