La programmation en C++ moderne

Commentaires de ce que j'ai pu lire (et lien avec les commentaire de @artragis :

• C++ est un langage extrèmement rapide" <- préciser "lors de l'exécution"

Je serai encore plus radical. Il faut être hyper prudent sur ce genre d'assertions au risque de colporter de fausses rumeurs : C++ ne donne pas de performances. Il donne du contrôle sur ces performances, et ce n'est pas gratuit.

• Hello World
  • Explications du hello world -> même remarques qu'@artragis.
  • Commentaires : "Par exemple, la ligne int main() est une définition de fonction", mérite d'être surtout plus précis. La définition de la fonction main, c'est int main() plus tout ce qui vient derrière jusqu'à son accolade fermante. Donc la phrase, dans son imprécision, n'est pas juste.
  • Commentaires : "vous avez sans doute remarqué que, malgré qu'elle" GRAOU ! ON NE DIT PAS MALGRÉ QUE !
  • Commentaires : "il ne faut pas abuser des commentaires, car ils alourdissent le code tendent, lorsqu'ils sont " problème de placement de virgules.
• Littérales
  • Il faudra penser à uniformiser le nous/on,
  • Nombre réels -> j'aurai une préférence pour nombre à virgule mais c'est très imprécis aussi
  • sinon même remarques qu'@artragis.
• Les variables
  • Plus ça va et moins j'aime l'idée de "je veux utiliser la mémoire". La variable c'est finalement un concept abstrait. Je n'ai pas d'idée sur le moment mais à mon avis, ça mérite réflexion
  • Même remarque que précédemment pour le "nombre réel"
  • La remarque la plus importante pour les double et les floats est à mon sens surtout que ce ne sont pas des décimaux
  • Pour les bonnes pratiques de nommage, je dirai que le plus important est de leur signaler ce qui est ultra casse gueule (underscore en début de mot). L'utilisation du caml-case n'est à mon sens pas une convention de nommage qui devrait rentre dans la case "bonne pratique". L'utilisation d'une convention de nommage (lien vers ce qui existe ?) pour un projet donné est une bonne pratique.
  • Pour le const je serai partisan d'expliquer immédiatement la subtilité de son placement. Voir de commencer par le paragraphe principal de la règle et pas par son cas exceptionnel.
• Conteneurs:
  • "définir la taille par un const int" -> le type c'est std::size_t, au bas mot ça devrait être unsigned. Le bon type au bon endroit, n'inculquez pas ce truc stupide qui consiste à stocker des tailles dans des int, ça n'a aucun sens. Quand on a une littérale, ce n'est pas gênant en soi, le contrôle de négativité est visual, le reste du temps, c'est une plaie.

Nota finale : faire configurer l'IDE immédiatement avec un maximum de warnings serait à mon avis une bonne idée pour que les débutants ait un maximum de feedback sur leur code.

Ciao.

Commentaires mis à jour :

• Intro

  • "Dans notre vue", typo,
  • il manque un découpage dans la formulation à la fin du premier paragraphe, et l'expression finale est un peu étrange,
  • Tour d'horizon :
    • il y a un finalement au milieu d'un ensemble de paragraphe liés, c'est pas très logique (je croyais que c'était l'idée finale ?)
    • "Un ordinateur ne comprend que son langage, le langage machine. Il faut donc utiliser un compilateur pour traduire le C++ en langage machine" -> ça ne fait plus partie de cette intro

• Hello World

  • ", car on aura besoin de choses qui sont définies dans ce fichier" -> plutôt que "choses", le mot "fonctionnalités" serait préférable, il y a que dans mes exemples qu'on met des machins et des bidules,
  • Tous les commentaires du post précédent sur hello world.
• Littérales
  • Toutes les remarques d'avant,
  • "Sans oublier le return 0" -> cela dit la norme autorise explicitement cette fonction à ne pas contenir de return.
  • le mot "ça", je n'y ai pas fait attention depuis le début, mais attention.
• Les variables
  • typo au début avec le "c'_est",
  • je chipoterai bien en disant "composé de pleins de mémoires" pour l'ordinateur,
  • "… qui ne sont pris en charge directement …"
  • à propos de unsigned "il peut donc représenter un nombre deux fois plus grand", pas si direct pour le lecteur débutant,
  • règle obligatoire de nommage -> le "1" est plutôt mal choisi …
  • "tous les trucs" -> tous les éléments, toutes les fonctionnalités, …
  • bonne pratique de nommage : il doit exister un inventaire quelque part, celle-ci se nomme le Caml-Case, de mémoire.
  • feignant -> même remarque que @artragis précédemment.
  • const -> même remarque que précédemment
  • référence -> explication cyclique, c'est problématique. J'ai pas d'idée directe mais je préfère généralement parler de point d'accès à une variable.
  • subtilité soit à éviter (mais prenez garde dans votre paragraphe final !) soit à expliquer :

1

int const& ref{42}; //valide.

• • inférence de type, tout début -> majuscule qui traîne en milieu de phrase,
  • "tous les cv-qualifier sont effacés" -> trop tôt pour des trucs pareils, d'autant qu'il y des règles qui en gardent :

1
2
3
4

  int const i = 5;
  auto& r(i);

  r = 42; //error -> r is read-only reference

• Les chaînes de caractères : il va falloir être sélectif, std::string est un monstre à 12 pattes qui n'est franchement pas un bel exemple de conception, faudrait pas donner l'impression qu'une classe se doit d'être riche.
• Complexifions :
  • l'enchaînement de bloc "warning", "info", "question" est un poil lourd, les deux premiers sont justifiés mais pas le dernier.
  • "ou jamais dans le second" -> s/ou/et
  • "ne sont pas égales" -> "sont différentes ?"
  • à propos de l'exemple if(condition){}if(!condition){}, dans les inconvénients vous pouvez ajouter qu'on se planterait systématiquement en modifiant le code parce qu'on en oublierait un.
  • symboles &&/||/ … -> il serait utile de parler des "or", "and", "not" etc, même s'ils ont été initialement créés pour être compatible avec les encodages 7 bits, ils ne retirent aucune clarté, c'est même parfois l'inverse. (Cela fait partie du regroupement plus large des syntaxes alternatives ).
  • exercice : "il n'existe pas NAND, NOR, XOR" -> ni l'implication, et l'équivalence, et d'autres. Il doit bien y avoir un lien pour les répertorier .
• Conteneurs:
  • Général : ajoutez des liens vers les documentations.
  • "définir la taille par std::size_t" -> const malgré tout.
  • "et comment ça se crée ce machin ?" en question -> quand c'est bien amené, ça peut passer mais là c'est pas top quand même, on a l'impression que le lecteur est un neuneu.
  • "nous allons voir des tableaux dont la taille peut varier au cours du programme, en commençant par le plus utilisé, j'ai nommé std::vector" c'est actuellement le seul.

Note importante : pour faciliter la relecture ce serait bien d'avoir des diffs des changements.

Ciao.