J'ai class B:A;
je d=E9clare un list<B> et un list<A> et je veux joyeusement les
parcourir de conserve en factorisant un list<A>::iterator pour les
deux... Et je me fais crier par g++ !
On a pas naturellement (naivement ?) que list<B> h=E9rite de list<A> ?
Bon, je met l'étude des fonctions de cast sur la liste des trucs à faire rapidement...
On peut faire un résumé rapide :
Un cast "à la C" : à éviter, car il faut une lecture très attentive pour savoir à quoi il correspond.
La question est plus subtile que ça, parce qu'en C++, il y a en fait trois « notations » de cast : la notation fonctionnelle, la notation « cast », et les xxx_cast. Et il y a des « casts » qu'on ne considère pas vraiment des casts, quelque chose du genre « MaClasse( param1, param2 ) » (qui selon la norme est un cast en notation fonctionnelle).
Personellement, j'ai une tendance à regrouper les conversions en deux grandes catégories : celles qui servent à créer un nouvel objet, et celle qui servernt à accéder à un objet existant comme s'il avait un autre type. Le mot opératif ici est le verbe « servir ». La convertion d'un pointeur crée bien un nouveau pointeur, et un pointeur est un objet. Mais le but, en général, est d'accéder à l'objet pointé d'une autre manière. Tandis que quand je converti un int en double, il n'y a que le double, c-à-d le nouvel objet, qui m'intéresse.
En ce qui concerne la création des nouveaux objets, j'utilise la notation fonctionnelle la plupart du temps, mais il m'arrive aussi à utiliser la notation « cast » (le cast à la C) pour des types de bases, quand par exemple il ne s'écrit pas avec un seul token, p.e. « (unsigned char)ch ». (Mais je ne suis pas systèmatique. Il y a des cas où j'utilise static_cast pour ça, sans que j'arrive vraiment à expliquer pourquoi ou la motivation derrière mon choix.)
static_cast<> : cast au moment de la compilation. C'est le cast "normal".
À part le cas ci-dessus (où à mon avis, un cast à la C est aussi valable), je m'en sers surtout dans les templates. En dehors des templates, un static_cast sur une référence ou un pointeur est tout sauf normal ; c'est plutôt exceptionnel, et ne sert que dans le cas où le profiler dit qu'il le faut.
En supposant, évidemment, qu'on se sert de la notation fonctionnelle pour la création de l'objet (ce qui est obligatoire si la création n'a pas exactement un seul paramètre).
dynamic_cast<> : cast pendant l'exécution. Généralement, c'est pour dire au programme (si B dérive de A) qu'un A* pointe en fait vers un B :
A* ptr= new B; B* ptr_B= dynamic_cast<B*>(ptr);
C-à-d qu'il doit représenter 90% des casts du type xxx_cast au niveau applicatif, si on utilise la notation fonctionnelle pour la création des objets.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 6 Dec 2005 05:44:20 -0800, "meow" <ben@agat.net>:
Bon, je met l'étude des fonctions de cast sur la liste des
trucs à faire rapidement...
On peut faire un résumé rapide :
Un cast "à la C" : à éviter, car il faut une lecture très
attentive pour savoir à quoi il correspond.
La question est plus subtile que ça, parce qu'en C++, il y a en
fait trois « notations » de cast : la notation fonctionnelle, la
notation « cast », et les xxx_cast. Et il y a des « casts »
qu'on ne considère pas vraiment des casts, quelque chose du
genre « MaClasse( param1, param2 ) » (qui selon la norme est un
cast en notation fonctionnelle).
Personellement, j'ai une tendance à regrouper les conversions en
deux grandes catégories : celles qui servent à créer un nouvel
objet, et celle qui servernt à accéder à un objet existant comme
s'il avait un autre type. Le mot opératif ici est le verbe
« servir ». La convertion d'un pointeur crée bien un nouveau
pointeur, et un pointeur est un objet. Mais le but, en général,
est d'accéder à l'objet pointé d'une autre manière. Tandis que
quand je converti un int en double, il n'y a que le double,
c-à-d le nouvel objet, qui m'intéresse.
En ce qui concerne la création des nouveaux objets, j'utilise la
notation fonctionnelle la plupart du temps, mais il m'arrive
aussi à utiliser la notation « cast » (le cast à la C) pour des
types de bases, quand par exemple il ne s'écrit pas avec un seul
token, p.e. « (unsigned char)ch ». (Mais je ne suis pas
systèmatique. Il y a des cas où j'utilise static_cast pour ça,
sans que j'arrive vraiment à expliquer pourquoi ou la motivation
derrière mon choix.)
static_cast<> : cast au moment de la compilation. C'est le
cast "normal".
À part le cas ci-dessus (où à mon avis, un cast à la C est aussi
valable), je m'en sers surtout dans les templates. En dehors des
templates, un static_cast sur une référence ou un pointeur est
tout sauf normal ; c'est plutôt exceptionnel, et ne sert que
dans le cas où le profiler dit qu'il le faut.
En supposant, évidemment, qu'on se sert de la notation
fonctionnelle pour la création de l'objet (ce qui est
obligatoire si la création n'a pas exactement un seul
paramètre).
dynamic_cast<> : cast pendant l'exécution. Généralement, c'est
pour dire au programme (si B dérive de A) qu'un A* pointe en
fait vers un B :
A* ptr= new B;
B* ptr_B= dynamic_cast<B*>(ptr);
C-à-d qu'il doit représenter 90% des casts du type xxx_cast au
niveau applicatif, si on utilise la notation fonctionnelle pour
la création des objets.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Bon, je met l'étude des fonctions de cast sur la liste des trucs à faire rapidement...
On peut faire un résumé rapide :
Un cast "à la C" : à éviter, car il faut une lecture très attentive pour savoir à quoi il correspond.
La question est plus subtile que ça, parce qu'en C++, il y a en fait trois « notations » de cast : la notation fonctionnelle, la notation « cast », et les xxx_cast. Et il y a des « casts » qu'on ne considère pas vraiment des casts, quelque chose du genre « MaClasse( param1, param2 ) » (qui selon la norme est un cast en notation fonctionnelle).
Personellement, j'ai une tendance à regrouper les conversions en deux grandes catégories : celles qui servent à créer un nouvel objet, et celle qui servernt à accéder à un objet existant comme s'il avait un autre type. Le mot opératif ici est le verbe « servir ». La convertion d'un pointeur crée bien un nouveau pointeur, et un pointeur est un objet. Mais le but, en général, est d'accéder à l'objet pointé d'une autre manière. Tandis que quand je converti un int en double, il n'y a que le double, c-à-d le nouvel objet, qui m'intéresse.
En ce qui concerne la création des nouveaux objets, j'utilise la notation fonctionnelle la plupart du temps, mais il m'arrive aussi à utiliser la notation « cast » (le cast à la C) pour des types de bases, quand par exemple il ne s'écrit pas avec un seul token, p.e. « (unsigned char)ch ». (Mais je ne suis pas systèmatique. Il y a des cas où j'utilise static_cast pour ça, sans que j'arrive vraiment à expliquer pourquoi ou la motivation derrière mon choix.)
static_cast<> : cast au moment de la compilation. C'est le cast "normal".
À part le cas ci-dessus (où à mon avis, un cast à la C est aussi valable), je m'en sers surtout dans les templates. En dehors des templates, un static_cast sur une référence ou un pointeur est tout sauf normal ; c'est plutôt exceptionnel, et ne sert que dans le cas où le profiler dit qu'il le faut.
En supposant, évidemment, qu'on se sert de la notation fonctionnelle pour la création de l'objet (ce qui est obligatoire si la création n'a pas exactement un seul paramètre).
dynamic_cast<> : cast pendant l'exécution. Généralement, c'est pour dire au programme (si B dérive de A) qu'un A* pointe en fait vers un B :
A* ptr= new B; B* ptr_B= dynamic_cast<B*>(ptr);
C-à-d qu'il doit représenter 90% des casts du type xxx_cast au niveau applicatif, si on utilise la notation fonctionnelle pour la création des objets.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
