La programmation en C++ moderne

Merci de ton retour !

a- je pinaille juste sur le format du fichier. Dans un csv, j’aurai plutôt vu nom;prenom;age;sexe. Le format choisi me fait plus penser à un pseudo-YAML, ou .properties à cause du balisage.

Ah bon ? Je pensais que csv c’était Comma Separated Values. Je rectifierai.

b- s/InfosPersos/InfosPersonne ? -> Informations d’une personne. Ou alors InformationsPersonnelles

J’ai pas compris.

c-

La convention veut que l’on nomme les structures en commençant chaque mot composant l’identifiant par une majuscule.

-> La convention que nous avons choisie dans ce cours.

La SL fait tout son possible pour ne pas suivre cette convention, et Stroustrup râle déjà (si j’ai bien suivi ces dernières interventions) que les concepts soient en UpperCamelCase au lieu du snake_case.

En effet, je devrais préciser. Voire prendre la convention recommandée. Par curiosité, tu utilises quoi, toi, à titre personnel ?

d- La notion de saisie sécurisée ne me parait pas avoir de sens sur une chaîne de caractères. La seule invalidation possible survient sur un flux fermé, chose que la fonction ne teste pas.

C’est déjà prévu qu’on modifie la fonction entree_securisee pour qu’elle le teste.

e- + "."s -> + '.'?

Oui.

f- J’enchainerai de suite de

InfosPersos infos{};
demander_infos(infos);

à

auto infos = demander_infos();

qui est le style multiplement recommandé, et ce avant même de parler des tuples.

Oui évidemment. J’ai oublié de changer ça (c’est un artefact du fait que juste avant le lecteur n’avait pas d’agrégat de données hétérogènes dans sz boîte à outils.

On fait un cours pour débutant, mais qui a pour but la qualité logicielle. Pas au détriment de la pédagogie, mais en l’occurrence, le lecteur est tout à fait capable de taper quelques trucs en plus. Donc ça sera std::unordered_map. Voire les deux.

a- Pour les csv, coma, semi-colon, ou même tsv, ne change rien. Le truc est que je n’ai jamais vu de tabs dedans. En général, ce n’est jamais que des feuilles (à la excel) en version minimaliste

b- Après des années de JdR, quand je lis InfosPersos, jene lis pas informations personnelles, mais informations d’un personnage. Et ça sonnait bizarre.

a- Pour les csv, coma, semi-colon, ou même tsv, ne change rien. Le truc est que je n’ai jamais vu de tabs dedans. En général, ce n’est jamais que des feuilles (à la excel) en version minimaliste

C’est-à-dire de tabs ? J’ai pas mis de tabulations. J’ai vérifié sur Wikipédia, je respecte bien le format csv il me semble.

Ah oui d’accord.

EDIT : Je viens de comprendre le s/InfosPersos/InfosPersonne. J’avais oublié que je parlais à un fan de vimeries !

a- Stricto-sensu, tu respectes bien le format. Dans les faits, on ne verras jamais de fichiers csv remplis de

nom,Doe
prenom,John
age,42
nom,Doe
prenom,Jane
age,12

Ce que l’on verra, c’est

Doe,John,42
Doe,Jane,12

Ce qui est plus important, c’est la structuration du fichier.

Finalement, pour la convention de nommage, j’ai choisi de suivre celle de la lib standard pour le cours. J’ai bien précisé que c’était une convention, et pas la convention comme je l’avais maladroitement dit.

Oui exact, en relisant des exemples de csv j’ai compris ce que tu voulais dire. C’est noté.

Personnellement, je préfère CamelCase plutôt que snake_case pour les noms de classes et types. Influence de C# et Python je pense.

Moi c’est ce dont j’ai l’habitude aussi, mais pour le cours je trouve ça pas mal d’être cohérent avec un truc qu’ild connaissent, à savoir la lib standard.

C’est un bug de la lib standard !

Plus sérieusement, l’inconvénient, je trouve, est que la lib standard ne fait pas la distinction entre noms de variables, de fonctions, de classe. Ce qui n’est pas génant pour une lib (idem pour boost), puisqu’il n’a pas beaucoup de variable. Pour un programme, il peut etre intéressant de faire un choix différent.

Pour ca que je préfère le camelCase aussi (Qt powaaaaaaa !!!)

D’accord. Go pour le camelCase alors. Je trouve ça plus lisible aussi, donc c’est pas moi qui vais te contredire.

EDIT : Comme le snake_case est utilisé depuis le début du cours pour les noms de fonctions, je pense qu’on va laisser ça comme ça. J’utiliserai donc le CamelCase juste pour les types. De toute manière, en général, quand c’est une fonction ça saute aux yeux.

Bonjour les agrumes !

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

Au programme, la prise en compte des dernières remarques de @lmghs.

Merci d’avance pour vos commentaires.

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. Et puis, je lis mieux avec un espace entre chaque mot, aujourd’hui.

Dans tous les cas, c’est beaucoup juste une question d’habitude, l’essentiel est d’être consistent et d’accepter qu’il n’y a pas de vérité meilleure qu’une autre ici.

Oui, c’est vrai.

Du coup, histoire de trancher, je pense qu’on va rester sur du CamelCase vu que les deux auteurs en ont l’habitude (histoire d’éviter un manque de consistence). En plus c’est plutôt cohérent du point de vue pédagogique, pour les raisons évoquées par gbdivers (différenciation variables/types). Par contre, je ferai la remarque que d’autres conventions existent, en donnant l’exemple du snake_case.

@informaticienzero, ça te va ?

Oui, parfait.

Cela peut avoir du sens de faire un chapitre (a mettre au debut) pour expliquer toutes les infos méta : que le C++ est permissif, qu’il y a des bonnes et mauvaises façons de coder (basés sur des arguments techniques pas forcement accessibles aux débutants, donc le mieux est de les suivre même si on ne comprend pas), que ces pratiques sont dans ce qu’on appelle des guidelines, que chaque projet peut (doit ?) définir ses guidelines et être consistant, qu’il exite des guidelines "génériques" (celle a connaitre est au moins les C++ Core Guidelines), et que ces guidelines peuvent contenir toutes les règles que l’on veut (comment nommer ses variables, comment présenter son code, comment partager son code dans une équipe de dev, comment tester son code, comment documenter son code, les patterns/idioms à utiliser/interdit, l’architecture des projets, les modules, les libs, etc, etc, etc.)

Et finir par un "dans ce cours, on fait le choix xxx".

J’hésite. C’est une bonne idée, mais peut-être que dès le début du cours, c’est un peu tôt pour ça. Les deux premières parties n’ont peut-être pas besoin de ça, à voir.

Par contre, la troisième partie sera un interlude "Etre un développeur" et entrera plus en détails dans cet aspect méta, qui fait plus sens et va plus parler au lecteur si il a déjà expérimenté la programmation en C++. 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.

N.B : A titre d’information, le plan provisoire pour la suite est le suivant :

3. Interlude "Etre un développeur"
4. Etude de cas n°1
5. La Programmation Orientée Objet
6. Notions complémentaires/avancées
7. Etude de cas n°2

Les études de cas sont un projet guidé plus ambitieux que les exercices et TP, de manière à faire découvrir au lecteur ce que c’est que de gérer et développer un projet informatique (d’où le fait que la première étude soit juste après l’interlude "Etre un développeur"). Ce sera des projets assez ambitieux pour occuper toute une partie du cours. Pour ceux qui l’ont lu (je sais que c’est au moins le cas de @lmghs ^^), ça s’inscrit dans la même idée que l’étude de cas "Un jeu d’échecs en moins de 3000 lignes de code" du livre de koala_01. Je pense que ça serait une plus-value sympa pour le cours.

NB: pour la POO je suis très critique. Il est difficile de trouver des exemples OO pertinents et corrects qui ne sont pas trop métier je trouve. Le sdz/oc a fait un bon choix avec un jdr, mais il y a des erreurs de conception. Je me souviens avoir décris la démarche que j’ai prise dans 2–3 fils de discussions avec C.Delannoy dernièrement.

Aujourd’hui, je travaille essentiellement avec des matrices pour la partie valeur, le javaquarium pour la partie OO entités. Et si vous trouvez un bon exemple, je suis preneur. Et je critique gratuitement les gestions de stocks de pharmacie et le points colorés qui dérivent des points — je me fendrai d’un billet de blog un de ces quatre.

PS: j’aime beaucoup le disclaimer qui explique les notions de choix & cie.

NB: pour la POO je suis très critique.

Très critique sur le fait de le faire ou sur la manière dont ce sera fait ?

Il est difficile de trouver des exemples OO pertinents et corrects qui ne sont pas trop métier je trouve.

Exact, c’est un peu pour ça qu’une étude de cas derrière c’est pas mal.

Le sdz/oc a fait un bon choix avec un jdr, mais il y a des erreurs de conception.

C’est une catastrophe de conception plus précisément. On comprend principalement que l’auteur n’a rien compris à l’OO, sans vouloir lui manquer de respect.

Je me souviens avoir décris la démarche que j’ai prise dans 2–3 fils de discussions avec C.Delannoy dernièrement.

Aujourd’hui, je travaille essentiellement avec des matrices pour la partie valeur, le javaquarium pour la partie OO entités.

Oui, je pensais au Javaquarium pour les entités. Pour l’instant, je n’ai pas réfléchi à d’autres idées. Pour la partie valeurs, je ne sais pas encore, les matrices (ou tout autre construction d’objet mathématique plus ou moins complexe) ça m’a l’air bien.

C’est noté.

EDIT : La route est longue encore avant d’arriver à la POO, on aura largement le temps de réfléchir à des exemples.

Les objets mathématiques se prêtent bien aux valeurs oui. On peut aussi imaginer une classe Fraction, une classe de BigInt ou Decimal (en C# c’est son petit nom) pour manipulation de nombres de très grande taille, des manipulations de vecteurs, etc.

Je suis très critique envers les approches qui confondent OO avec Base de Données, ou qui héritent n’importe comment. — c’était mon disclaimer à moi pour vous préparer

Ah oui d’accord ! Ne t’inquiète pas, j’ai été biberonné à la philosophie de l’OO pendant mon apprentissage du C++ ; nous ne te décevrons pas !

En plus c’est pas compliqué, il suffit de faire exactement l’inverse que le cours d’OC.