Dans la partie sur les commentaires, je comprend le choix d'écrire un cartouche indépendant d'un générateur de doc en particulier, mais j'aurais préféré un exemple basé sur doxygen.
Le problème, c'est que si j'avais privilégié une syntaxe plutôt qu'une autre, on aurait fatalement trouvé quelqu'un pour me reprocher "et pourquoi doxygen et non XXX".
De plus, dans cette section, mon but est uniquement:
- d'expliquer la raison pour laquelle un cartouche (correct) fait exception à la règles
- d'expliquer aussi clairement que possible ce qui fait un *bon* cartouche.
L'aspect de la génération automatique de documentation n'entre ici absolument pas en ligne de compte :D
Pour la partie sur les effets de bord, j'aurais aimé un exemple de code évitant ces effets. Par exemple, en faisant une copie ou un swap (et du coup faire un petit clin d'oeil à la programmation fonctionnelle :
modifyCoordinate(coordinate, 5,300,410); -> coordinate = Coordinate(5,300,410);
ou
void modify(...) { ... } -> void modify(...) { Coordinate temp; ... ; coor = temp; }
J'aurais sans doute du me creuser la tête pour trouver un exemple "de ce qu'il faut faire".
Mais un clin d'oeil -- aussi petit soit il -- à la programmation fonctionnelle m'aurait sans doute fait beaucoup trop digresser. Et comme je le fais déjà à quelques occasions... :P
Pour la partie Pile et Tas, tu parles de la portée, qui correspond aux limites dans laquelle la variable est utilisable dans le code. Par contre, en terme de création et destruction, je ne sais pas si c'est nécessaire de préciser que toutes les variables d'une fonction sont créée lors de l'appel de fonction et détruite lors de la sortie, quelque soit leur portée.
D'autant plus que ce n'est pas le cas, pour la construction en tout cas.
La construction ne survient qu'une fois que l'on atteint la déclaration de la variable, et comme on tend à privilégier le fait de déclarer les variables au plus près de leur utilisation, la création de la variable peut se faire au beau milieu de la fonction.
Quoi qu'il en soit, je croyais avoir été clair sur ce point :P Apparemment, il n'en est rien.
Pour l'allocation dynamique, tu dis "vous n'avez pas eu recours à l'allocation dynamique de la mémoire". Cela pourrait faire penser qu'il n'y pas d'allocation dynamique implicite et qu'un code innocent comme : vector v(10); n'utilise pas l'allocation dynamique.
Le fait est qu'une classe comme std::vector utilise, effectivement, l'allocation dynamique de la mémoire en interne, mais qu'elle le fait de manière totalement transparente pour l'utilisateur. Et, comme elle a, a priori, sémantique de valeur et qu'elle est utilisée essentiellement par valeur (ou par référence, quand elle est transmise en argument), tout ce qui intéresse son utilisateur, c'est d'avoir la certitude que tous les éléments qu'il rajoute à sa collection sont disponible tant que la collection existe. La manière dont la collection s'y prend pour obtenir ce résultat, l'utilisateur de la collection n'a même pas à s'en inquiéter ;)
Autre remarque, quand on parle d'allocation dynamique et portée, les gens ont parfois du mal à comprendre que c'est l'objet créé qui n'a pas de portée, pas le pointeur qui pointe vers l'objet, qui est bien une variable sur la Pile. J'avais fait une série d'image pour expliquer ces histoires de portée et durée de vie :
Il me semblait pourtant aussi avoir été clair sur ce point :P