philippe-dunski

philippe-dunski

Remarques générales

0 appréciations
Hors-ligne
Je continue ma lecture... et plusieurs remarques :)

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.

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; }

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.

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.

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 : http://guillaumebelz.wordpress.com/2013/08/10/pile-tas-portee-et-duree-de-vie/

Je continues ma lecture ;)


Dernière modification le 22-02-2014 à 21:04:56

Derni?re modification le 22-02-2014 ? 21:08:44

0 appréciations
Hors-ligne
Pour Demeter, je mettrais quand même une exception : si on veut exposer une variable membre dans une interface non C++. Je pense en particulier à Qt, qui permet d'exposer ses membres en JavaScript ou en QML via Q_PROPERTY :

class MyClass : public QObject {
Q_OBJECT
Q_PROPERTY(QString name WRITE name READ setName NOTIFY nameChanged)
private:
QString m_name;
public:
QString name() const;
public slots:
void setName(QString);
signals:
void nameChanged();
};


(PS : ca serait bien des balises code sur le forum)


Derni?re modification le 23-02-2014 ? 18:49:38

0 appréciations
Hors-ligne
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

0 appréciations
Hors-ligne
Pour les exemples de code et l'utilisation d'un outil en particulier, je comprend ton argument. Mais cela ne me choque pas qu'en tant qu'auteur (et donc expert dans le domaine), tu puisses mettre en avant un outil spécifique.
Il faut avouer que mes remarques se basent aussi sur la façon dont j'utilise les livres (et mes articles et mes prises de note) : un peu comme un pense-bête, pour retrouver des syntaxes. Mais avoir un code spécifique, cela peut effectivement faire croire que les propos sont moins généraux qu'ils le sont en réalité.

Pour la construction/destruction, c'est ma faute, je n'ai pas utilisé les bons termes. Je parlais en fait de l'allocation mémoire. On est bien d'accord que les variables locales d'une fonction sont allouées en une seule fois lors de l'appel de la fonction et libéré en une seule fois (et pas allouée juste avant la construction et libéré après la destruction) ?

Pour la portée, tu sais bien que les débutants sont parfois très retord pour comprendre (souviens toi des explications que tu avais donné sur les énumérations sur le SdZ, la personne comprenait tout de travers). J'ai encore vu récemment une personne sur le forum ne pas comprendre les problèmes de portée, durée de vie, quels objets sont créé dans quelles conditions, etc.
On verra selon le test du "le débutant le plus idiot que l'on trouve" si tes explications sont suffisantes ou non :)

En tout cas, rassure toi, je trouve ton livre très bien dans le fond et la forme, en particulier très clair et agréable à lire pour les débutants. Je n'arrête pas de le conseiller sur le SdZ :) (j'avais un peu de remords quand je faisais de l'auto-promo avec mon livre, mais là pas de problème, je me lâche)

0 appréciations
Hors-ligne
Concernant les références, tu écris :
alors que la référence vous apportera justement une garantie de non-nullité.
. Je préfère parler d'une garantie plus forte plutôt que dire que c'est une garantie stricte, dans le sens où (avec du code bien crade) on peut rendre une référence invalide quand même. (je chipote, mais on m'a déjà sortie un code pour te dire "bah tiens, regarde, tu vois qu'il est possible qu'une référence soit invalide, donc ton argument de la non-nullité de la référence vs le pointeur n'est pas valide")
Vous ne disposez pas des permissions nécessaires pour répondre à un sujet de la catégorie L'étude de cas de Coder efficacement.

Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 8 autres membres