Voici les modifications que j'ai apportée. Pour l'instant tout est hors-ligne. Ce sera publié en même temps que la nouvelle version de la partie II.

1. Suppression de la présentation des bornes pour les types.
2. Changement de la tournure de phrase visant à ne pas encourager la déclaration de plusieurs variables sur une seule ligne.
3. Suppression du mot "allocation" pour le stockage des variables sur la pile.
4. Ajout d'une remarque pour bien insister sur l'absence de parenthèses lors d'une déclaration sans initialisation.
5. Ajout de la présentation des constantes non-connues à la compilation.
6. Ajout d'un commentaire sur l'importance du const.
7. Modification des codes en ajoutant les const nécessaires.
8. Ajout de la présentation de la pré-incrémentation.
9. Ajout d'une remarque pour appuyer l'utilisation du for avec la variable déclarée à l'intérieur et pas avant.
10. Ajout d'une mention de doxygen pour la documentation des fonctions.
11. Correction de la phrase qui indiquait que les tableaux ne pouvaient pas être renvoyés par une fonction.
12. Remplacement des déclaration puis affectation par des initialisation là où c'était nécessaire.

Ce qu'il reste principalement à faire c'est de modifier en profondeur le chapitre sur les fichiers.

Merci pour tous vos commentaires dans ce thread, par MP et dans les alertes.

N'oubliez pas les nombreux "T v;\n v = foobar(42);" à fusionner à en "T v(foobar(42));".

C'est fait aussi, je l'ai juste oublié dans ma liste.

Bonjour à tous,

J'arrive un peu après la bataille, mon emploi du temps ne m'a hélas pas permis de regarder la nouvelle mouture du tuto C++ en détail avant aujourd'hui. J'ai donc pris cet après midi le temps de regarder tout ça en détail (j'en suis aux pointeurs). J'ai aussi lu ce fil, aussi j'ai zappé les remarques qui ont déjà été faites, ce qui fait qu'il ne me reste plus grand chose à dire

lmghs a parlé des formes prefix/postfix, et je voudrais revenir là dessus, comme lui je souhaiterai plus de cohérence. Vous présentez la forme postfix, puis vous utilisez la prefix ou la postfix "au petit bonheur", la cohérence voudrait que vous vous teniez à la version présentée quoi qu'il arrive. Ensuite toujours là dessus, vous présentez la version postfix, ce qui à mon sens est une erreur pédagogique, au delà des considérations d'experts, la version postfix induit un effet de bord pas du tout évident à voir et qui peut avoir des conséquences catastrophiques sur les performances du programme. Personnellement j'aurais présenté le prefix et je n'utiliserai que lui (quitte éventuellement à mentionner l'existence du postfix parce qu'il est souvent utilisé tout en préconisant l'emploi du prefix en priorité sans s'étendre sur les différences entre les deux, différence que je traiterais plus en détails dans une partie consacrée à la surcharge d'opérateurs).

Une autre remarque sur la partie concernant les fonctions, et plus particulièrement sur le passage par référence. L'exemple qui illustre la modification de la valeur d'un paramètre passé par référence n'est pas bien choisi. Une fonction qui ne retourne rien aurait été plus parlante.

Au dela de ces quelques remarques vous avez fait du bon boulot

Edit petit oubli: dans la partie sur les tableaux et comment on les passe en paramètres à des fonctions, c'est peut être le moment de parler de passage par référence constante.

Si vous avez des commentaires sur la nouvelle version de la partie II, n'hésitez pas !

Super! J'y jette un premier coup d'oeil (très) rapide.

II.1- string
a- ce chapitre me fait un peu bizarre. Il me semblait qu'il y avait déjà quelque chose sur les chaines. Mais passons.
Reste que j'aurais d'abord parlé de string avant de char[N]

b- Maintenant je sais pourquoi je voyais parfois substr être utilisé pour extraire une seul caractères.
Il faudrait introduire operator[] aussi.

c- Je n'aime pas le terme méthode, mais vous le savez déjà


II- classes 1
a- :-/
Je suis dubitatif.
Je ne considère pas l'abstraction comme un principe majeur. J'ai un vague souvenir d'un chapitre qui parlait de l'abstraction. Du coup refaisant une lecture en diagonale je n'ai pas d'avis sur l'encapsulation.

Sauf que mal compris: "tous les attributs d'une classe doivent toujours être privés" on se retrouve à violer encapsulation et Déméter à coup d'accesseurs dans tous les sens.
Quand j'aurais plus de temps je relirai mes anciens commentaire (des fois que), et les nouveaux chapitres.
D'ailleurs, vous auriez un diff ?

III- classes 2
a- si les références constantes ont bien été introduites, fonçons!
Sinon, elle seraient bienvenues avant.

b- if (condition) return true; else return false;
Euh ... return condition, c'est bien.

c- je me souviens de problèmes avec les Armes qui sont possédées et par valeur.

plus plus tard.

Wow, rapide.

II.1

a) Oui. On en parle un peu partout. Ici, on l'utilise comme premier exemple d'objet pour le côté utilisateur de la classe.

b) On l'a déjà fait dans le chapitre sur les tableaux. Tu as néanmoins raison, je viens d'ajouter un rappel allant dans ce sens. On utilise substr() que si l'on a besoin de plus d'un caractère. Merci.

D'autres réponses plus tard.

Quelques réponses supplémentaires:

II.
a. Il est clair que en pratique tout déclarer en privé n'est pas la bonne solution. Il y a toujours des cas où exposer l'attribut est la meilleure chose à faire. Néanmoins, pour quelqu'un qui débute, les cas spéciaux sont trop complexes à expliquer.
On viole la règle de Déméter. Oui. Mais je préfère la violer ici quite à revenir plus tard sur cette règle. Et on ne pousse pas non plus les gens à mettre des set/get partout. On mentionne que si le besoin se fait sentir d'accéder à cette valeur, alors c'est la manière de faire.
Par exemple, dans le TP sur les fractions, je propose de mettre le numérateur et le dénominateur en privé. Mais je ne fournis aucun getter ni setter pour y accéder.

III.
a. Elles apparaissent un peu plus loin explicitement.

b. Oui. On a juste pas introduit cette notation plus tôt dans le cours. Et je sais d'expérience que c'est une version parfois peu intuitive. On a préféré ici la clarté sur ces points là pour que les gens se concentrent sur les nouvelles notions qu'on leur présente.
A nouveau, dans le TP (version avancée), la version courte est privilégiée. Et ce sera aussi le cas dans la partie III sur Qt. Elle présente moins de notion de théorie, on peut donc en profiter pour lisser un peu les choses sur lesquelles on a pas insisté avant.

c. C'est-à-dire ? J'ai cherché dans les vieux commentaires, mais je n'ai rien trouvé.

II-a- J'étais gêné par la formulation, qui gravée dans le marbre sera source de mauvaises interprétation si mal comprise/formulée au départ

III-a On ne voit pas les références constantes dans la nouvelle première partie ? (et donc avant ?)

III-b- Ce genre d'écriture sur les booléens me choque systématiquement j'avoue
(et je la soupçonne d'être le premier pas de certains règle idiotes du genre "il faut toujours tester p/r vrai/faux, ex: "if (estEnVie() == true)".

III-c- Ce n'était pas dans les commentaires, mais dans les questions posées dans les forums.
Régulièrement j'avais pu voir des débutants batailler avec des problèmes inhérents à la copie d'entités. Ce qui de mon point de vu est du gaspillage d'énergie humaine, et propice à : "pfff, c'est trop compliqué le C++".

Mais là, c'est un problème de choix pédagogique plus général et plus complexe : l'exemple est sympa, mais il est prématuré pour parler d'entités. Du coup ... on leur montre un truc bâtard mi-entité/mi-copiable. (NB: je n'ai pas de solution clé en main à proposer)

OK, c'est reparti plus tranquillement.

Je ne reviens pas sur les points qui sont supers (comme la boite opaque, etc), ou ce que j'ai déjà signalé (arg "méthode")

II-1- strings, la vérité

d- "Mais mais... comment on fait pour différencier les objets des variables ?"
Hum ... :/ Quelle est la pertinence de la question ? Après tout, tout cela est sensé être opaque.

Pourquoi je soulève ce point ? Parce que je viens de refactorer du code qui suivait une vilaine notation hongroise sys et nommait les classes en "C_". De plus, il y a un problème de cohérence : généralement ceux qui font commencer leur noms de classes par une majuscule le font aussi pour tous les autres types (ex: "typedef unsigned char Byte;").
Alors que franchement ... variable non objet ou objet (qui est une variable), on s'en moque totalement. Ce qui est important est souvent ailleurs.
(sans parler des PODs qui deviennent objets et vice-versa au fil des refactorings)

e- le flux du dernier exemple est construit via open. La gestion des fichiers ayant été simplifiée, il serait mieux d'harmoniser cet exemple.

a- J'avais effectivement zappé que le type avait été abordé plutôt.
Plus qu'à espérer que des débutants venant du C ne vont débarquer directement à ce chapitre en croyant ne pas avoir besoin de se mettre à jour.

f- À propos de cette population ... Quitte à parler des détails internes, faudrait-il (question ouverte) laisser une mini-annexe du genre "Eh! Mais est la mémoire ? On n'alloue ni ne libère rien ? Et on ne risque pas de dépasser?". Surtout qu'il y a un @warning concernant l'utilisation des tableaux C, et il ne me semble pas avoir vu l'équivalent qui dit : "et voilà, plus besoin de se prendre le chou!". J'ai peut-être lu trop vite.

Plus, plus tard.

EDIT: (je hais les règles anti-flood)

II-2- (les classes 1/2)

b- Vous citez d'abord attributs, puis les fonctions membres. C'est une vision très data-oriented, et peu OO je trouve. Je mettrais d'abord les fonctions vu qu'elles correspondent à ce qui se rapproche le plus des services fournis par les objets.
Ah. Je vois ensuite d'où ça vient.
Justement, c'est parce que le Personnage sait attaquer que l'on a besoin de connaitre la côte de dmg de l'arme. Sinon, comment pourrait-on penser à un tel attribut ?

c- s/string/std::string/

d- estVivant() n'est pas const-correct.

e- "Par défaut, tous les éléments d'un objet sont private."
s/objet/classe/

a- Je reviens sur sujet de l'encapsulation (pour moi le principe majeur est l'abstraction, l'encapsulation n'est qu'un des comments en OO -- j'avais écrit une bourde dans mon premier message).
Ce qui me gêne, c'est la force de la règle : "ne jamais mettre des attributs en public", "engueulez ceux qui font", alors qu'il ne s'agit que de la simplification d'autres règles. Aller leur faire comprendre que ce qu'il tiennent pour règle d'or, ben ... qu'il faudrait qu'ils prennent un peu de recul.

f- les string sont copiées.
Le § I-7 était le bon endroit pour montrer la bonne syntaxe.

g- Il me semble que j'en avais parlé dans mes commentaires de la première édition.
La séparation attaquer/recevoirDegat ne permet pas de montrer la force de l'approche OO (enfin abstraction, tout ça)
Ils peuvent très bien se dire: "Pfff, ridicule, je n'ai qu'à modifier directement cible.m_vie.".
Et ils auraient raison quelque part. Donc montrons leur pourquoi c'est pas pareil de penser OO (/en terme de services).

En complexifiant un chouilla, en introduisant des aspects usuels des jdrs, on démontre facilement pourquoi c'est vraiment pas pareil.
L'attaque a un type : contondante, perçante, tranchante, enflammée, empoisonnée, magique, etc.
Le port d'une armure, la race de la cible, etc va faire que l'on a des immunités et autres ristournes.
Et là, ce sera recevoirDegat qui va se charger d'appliquer la véritable réduction des PV (points de vie -- en fait on va plutôt dire m_PV ou m_HP plutôt que m_vie, sémantiquement, il s'agit de points de vie) en fonction des protections portées. Dans un premier temps on peut se contenter de dire que l'on ne sait pas ce que porte la cible pour appliquer les effets de sa protection depuis l'attaquant. Et on peut suggérer pour un second temps que des types particuliers de Personnage auront des réductions que l'on ne peut pas prévoir au niveau de l'attaquant (ou encore dit autrement: "on y reviendra au chapitre sur l'héritage").

Hello,

Je n'ai pas trop le temps de continuer cette semaine, en attendant dans la thématique voici un article intéressant de Koenig: http://drdobbs.com/blogs/cpp/229401975

PS: Au cas où, j'avais édité mon précédent post plusieurs fois (à cause de l'anti-flood en place)

Et avec l'anti-flood, je n'avais pas vu les nouveaux commentaires ! Je vais regarder tout ça tranquillement.

Sinon, pour ton lien, que cherches tu à dire ? Enseigner l'utilisation des vector me semble essentiel et c'est ce qu'on a fait.

Zut, je croyais avoir répondu, mais je ne vois rien.

Non, c'était juste du partage d'idées intéressantes sur un sujet connexe. Vu que j'estime qu'il est toujours intéressant de confronter nos idées (qu'elles soient identiques ou pas), j'avais partagé. Voilà, c'est tout.

J'ai fait un saut : je parcours le nouveau chapitre sur la SL.
J'aime bien!

SL-1- J'ai vu un schéma relatif au choix des conteneurs qui me rappelle comme quelque chose. Je n'ai pas vérifié s'il était identique à celui que je connaissais, si oui, attention aux problèmes de licences.

SL-2- Attention aux fonctions à états, si utilisés dans les algos standards, on peut parfois observer des effets de bord car les foncteurs sont toujours copiés, et que parfois l'implémentation de notre compilo va réaliser des copies que l'on ne soupçonnait pas.

SL-4- Des parenthèses en vrac, peut-être prévues pour les prochains chapitres.

Il pourrait être intéressant de rappeler que std::string est à sa façon un conteneur de char ; exemple possible std::reverse (qui permet d'ouvrir une parenthèse sur les reverse iterators)

Mais aussi qu'un tableau (C) est aussi un conteneur (où son itérateur == pointeurs ; itérateurs triviaux, etc) sur lequel on peut appliquer std::sort.

Autre parenthèse possible, dire que la généricité a ses limites, et que donc certains algo sont directement associés à des conteneurs -> std::list::sort ; cf doc, tout ça.

J'aurai bien été tenté de couper l'herbe sous le pied de l'argument comme quoi les foncteurs c'est long et compliqué (ce qui est vrai) en parlant des lambda C++11, mais j'ai peur que cela fasse trop

Salut,
dans le chapitre sur les conditions, pourquoi ne pas présenter les mots-clés or, and et not à la place de ||, && et ! ?

Cela permettrait d’éviter des erreurs dures à trouver quand il y a utilisation erronée de & à la place de && dans une condition.

En outre, c’est plus clair d’utiliser des mots que des symboles.

Autre point :
vous montrez à utiliser la forme suivante pour déclarer et initialiser une variable :

int nombre(10);

mais, vous utilisez l’autre façon par la suite :

bool ok = false;

dans le chapitre sur les boîtes de dialogue (et sûrement dans d’autres étant donné que cette façon était montrée avant).

Enfin, pourquoi montrer à faire un truc du genre :

bool fonction() {
    if(condition) {
        return true;
    }
    else {
        return false;
    }
}

au lieu de :

bool fonction() {
    return condition;
}

Par exemple, dans le chapitre sur la surcharge d’opérateur :

bool operator!=(Duree const& a, Duree const& b)
{
    if(a == b)         //On utilise l'opérateur == qu'on a défini précédemment !
        return false;  //Si ils sont égaux, alors ils ne sont pas différents
    else
        return true;   //Et si ils ne sont pas égaux, c'est qu'ils sont différents ;-)
}

pourrait être écrit :

bool operator!=(Duree const& a, Duree const& b)
{
    return !(a == b);
}

Il serait bien également de vérifier le texte écrit par exemple la conclusion sur le polymorphisme.
En effet, il n'y a pas de TP en fin de partie.
Je crois qu'il y a d'autres endroits où il y a ce genre d'erreurs.

À plus !

lmghs ---------------------------

SL-1
C'est effectivement le même schéma que l'on trouve partout sur le web. Refait à la sauce maison pour utiliser le même vocabulaire que dans le reste du cours.

SL-2
Mmmmh. En effet. Dans les cas présentés le constructeur de copie est trivial donc la version générée par le compilateur est suffisante. Mais il est vrai que dans le cas général, cela peut poser problème. Je vais mettre une remarque allant dans ce sens.

SL-4
Oui. Il y aura des chapitres supplémentaires sur le sujet (dans le livre). Notamment ce qui a trait à string, les itérateurs de flux et les tableaux "à la C" sera présenté.

Pour ce qui est des lambda, ce serait évidemment l'extension naturelle, mais je pense que cela nous emmènerait trop loin.


antoyo .....................................................

1) or, and et not ne sont que très rarement utilisés. Honnêtement, je n'ai presque jamais vu de code qui utilisaient ces mots-clés.
Mais il est vrai que l'on pourrait ajouter une remarque allant dans ce sens. A voir.

2) On présente les deux notations. Et on dit préférer la première sans expliquer pourquoi. C.f. les premiers messages de ce topic. Il est vrai que nous utilisons les deux notations dans la suite. C'est souvent une question de préférence. La notation avec le = est parfois plus lisible puisqu'elle n'ajoute pas deux parenthèses supplémentaires. C'est par exemple le cas lorsque une variable est initialisée avec la valeur de retour d'une fonction.
Si tu as des exemples précis dans le cours, j'y jette volontiers un oeil.

3) Tout à fait. Sauf que cette notation n'est pas toujours très intuitive pour les débutants. Tu peux voir des messages allant dans ce sens dans les forums ou dans les commentaires. Tu remarqueras cependant que cette notation est progressivement remplacée par celle que tu préconises. Par exemple la correction de la version avancée du TP sur les fractions utilise ta version. C'est un choix pédagogique en somme.

4) Concernant le TP qui suit le polymorphisme, il n'est pas présent pour le moment, mais il est prévu qu'il fasse son apparition. De même pour les références pour l'instant fausses qui parlent de ce que contiendra la partie V du cours.

Merci à vous deux !

3)

Bravo à M@teo21 & Nanoc!

Salut! Si vous le pouvez, donnez nous une vue d'ensemble sur le reste de la partie sur la SL et le genre de TP qu'elle peut comporter. Merci

Nous venons de publier la partie V du cours :

http://www.siteduzero.com/tutoriel-3-1 [...] l#part_480729

Elle reprend les chapitres sur les exceptions et les templates de mon ancien cours avancé. On y parle en plus des assertions.
Le dernier chapitre est consacré à présenter rapidement quelques notions supplémentaires (enum, typedef, namespace) et on y présente également quelques bibliothèques couramment utilisées en C++.

Bonne lecture !

Des exceptions:

a- "on peut alors traiter ces erreurs et reprendre l'exécution du programme là où elle s'était arrêtée."
Mon expérience me fait dire que cet argument est totalement fallacieux.
Déjà, on ne reprend pas où cela s'est arrêté.
On commence par prendre note de la situation exceptionnelle, et très probablement anormale dans laquelle nous nous trouvons. Et possiblement, nous replaçons l'utilisateur à un carrefour qui lui permettra de continuer à travailler avec l'outil qu'on lui a développé.
Ce continuer peut consister à "unlocker un fichier/rebrancher un cable/... et recommencer le précédent scénario refusé", ou encore "positionner dans lieu où la sauvegarde du contexte est possible avant un redémarrage". Le nombre de possibilités est infinies.
Dire que l'on va reprendre l'exécution au lieu de l'arrêt ? Ca ne veut rien dire de vrai.
On retourne en amont du lieu de l'arrêt, on y traite la notification de problème, et on permet à l'utilisateur de repartir dans certaines directions.

b- "Un autre type de problèmes peut survenir si le programme est écrit"
Mal dit. "syntaxiquement correct" serait bien plus juste.

c- Je trouve "erreur d'implémentation" trop restrictif. Un algorithme peut être faux, et pourtant correctement implémenté.
En français je dis "de programmation", je ne sais plus comment ils disent en VO. implementation peut-être c'est vrai ?

d- "La gestion des exceptions permet, si elle est réalisée correctement, de corriger les erreurs d'implémentation en les prévoyant à l'avance"
Ca, ça ne me plait pas, vous le savez. Les exceptions c'est pas génial pour les erreurs de codage. On perd trop de contexte pour que cela soit vraiment utile à l'élaboration des programmes (ce que sous-entend la phrase). L'exception ne va pas corriger. Elle sera juste un garde-fou pour ne pas crasher en situation réelle pour les cas qui n'ont pas été suffisamment validés.

e- La division par 0, c'est plus compliqué.
À force de cogiter sur la PpC, j'en suis arrivé à la conclusion suivante.
div(a,b) a une précondition : b non nul.
D'un point de vue service, b null est une erreur de programmation => assertion.
D'un point de vue client : c'est au client d'assurer que b ne sera jamais nul. Le client est une calculatrice graphique/console ? Et alors ? Ca ne change rien. C'est au code client d'assurer que b est non null dans l'appel de div(). Ca veut dire que nous allons avoir plusieurs "couches" (pas exactement des couches) :
- le code métier qui expose très clairement son contrat
- la couche IHM où l'utilisateur peut saisir un 0 pour le futur b
- la couche intermédiaire de validation des I/O. C'est à elle qu'incombe la responsabilité que l'utilisateur ait saisi un truc compatible avec le contrat de div(). C'est cette couche qui va balancer une exception à destination de l'IHM pour que l'utilisateur sache qu'il a demandé un truc qui n'est pas permis et qu'il puisse recommencer à saisir des opérations (pas forcément un truc avec lequel diviser -- cf mon a-)

f- Pour moi, un bien meilleur exemple des exceptions sera la validation du contenu d'un fichier comme p.ex. les high-scores d'un jeu qu'un petit malin voudrait bidouiller à la main sans voir le CRC -- pour rester dans le didactique "jeu". Et pas un truc à mi-chemin des erreurs de programmation.
Une fois un bon exemple montré, go pour les détails techniques.

g- de la différence "erreur"/"exception".
Ce n'est pas aussi trivial. Cf le C++ coding Standard de Sutter et Alexandrescu : ils y parlent de politique de gestion des erreurs (et pas que d'exceptions car ils incluent l'approche par retour de code d'erreur dans la discussion).

h- En fait les exceptions sont d'une famille de classes à la sémantique des plus étranges : copiable sur throw, LSP sur catch. ("bon exemple de polymorphisme" me fait un peu tiquer du coup)

i- Nouvelle remarque au sujet du C++11, throw() va être remplacé par nothrow. (vu que plusieurs choses vont sortir en même temps bouquin du sdz et norme)

j- attention à parler de at(), en pratique, on s'en sert très très peu -- jamais personnellement.

l- les assertions, c'est pas parce que try/catch est fastidieux.
C'est pour nous aider à élaborer des programmes. Nous n'avons pas plus d'équivalence entre exceptions et assertions, qu'entre de la crème solaire et de la lotion anti-moustiques.

m- le plus difficile pour les assertions, c'est de bien réfléchir au contrat de chaque chose que l'on définit. Ce n'est pas trivial.


------------------------------
Des Templates
n- en fait, le terme en vieux françois est http://fr.wiktionary.org/wiki/templet

o- class/tyename, la seule différence revendiquée que j'ai croisée est sémantique : vraiment réservé aux classes.

p- moyenne<T,S>, j'aurais inversé T et S car T peut être déduit automatiquement -- de souvenir

q- ne pas oublier qu'en meta-prog, il n'est pas rare que l'on préfère la surcharge à la spécialisation template.

r- Pour les classes templates, peut-être commencer par rappeler qu'ils en connaissent déjà : vector.

s- Je ne suis pas hyper emballé par le choix de Rectangle pour du template. Il me semble qu'il y avait déjà eu un exo avec des nombres rationnels. Autant en profiter.

Bonjour

J'espère qu'il y aura un chapitre sur QML
Merci.