On Mon, 27 Aug 2007 10:41:04 +0200, "Bruno Causse" :
une_methode_qui_prends_un_B_en_Param(*iter);
Je ne suis pas sûr de ce que tu entends par "méthode". D'une manière générale, mieux vaut utiliser les termes "fonction", "fonction membre" et "fonction membre virtuelle", qui ont l'avantage d'avoir un sens bien défini en C++.
ou doit-on "caster" (si oui lequel "static", "reinterpret"?)
dynamic_cast
On Mon, 27 Aug 2007 10:41:04 +0200, "Bruno Causse" :
une_methode_qui_prends_un_B_en_Param(*iter);
Je ne suis pas sûr de ce que tu entends par "méthode". D'une manière
générale, mieux vaut utiliser les termes "fonction", "fonction membre"
et "fonction membre virtuelle", qui ont l'avantage d'avoir un sens
bien défini en C++.
ou doit-on "caster" (si oui lequel "static", "reinterpret"?)
On Mon, 27 Aug 2007 10:41:04 +0200, "Bruno Causse" :
une_methode_qui_prends_un_B_en_Param(*iter);
Je ne suis pas sûr de ce que tu entends par "méthode". D'une manière générale, mieux vaut utiliser les termes "fonction", "fonction membre" et "fonction membre virtuelle", qui ont l'avantage d'avoir un sens bien défini en C++.
ou doit-on "caster" (si oui lequel "static", "reinterpret"?)
dynamic_cast
Jean-Marc Bourguet
"Bruno Causse" writes:
bonjour,
class A { .../... A* next };
class B:public A { .../... };
puis je me servir de la variable next pour iterer une liste chainée de B, sans perdre les specificités du B?
list_b //liste chainée de B
for(A* iter = list_b->next; iter != null; iter = iter->next) une_methode_qui_prends_un_B_en_Param(*iter);
ou doit-on "caster" (si oui lequel "static", "reinterpret"?)
static_cast ou dynamic_cast.
static_cast necessite que tu sois sur par un autre moyen que le pointeur pointe bien vers un B (dynamic_cast retourne un pointeur nul si ce n'est pas le cas)
dynamic_cast necessite d'avoir une fonction virtuelle dans A
puis je me servir de la variable next pour iterer une liste chainée de B,
sans perdre les specificités du B?
list_b //liste chainée de B
for(A* iter = list_b->next; iter != null; iter = iter->next)
une_methode_qui_prends_un_B_en_Param(*iter);
ou doit-on "caster" (si oui lequel "static", "reinterpret"?)
static_cast ou dynamic_cast.
static_cast necessite que tu sois sur par un autre moyen que le pointeur
pointe bien vers un B (dynamic_cast retourne un pointeur nul si ce n'est
pas le cas)
dynamic_cast necessite d'avoir une fonction virtuelle dans A
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
puis je me servir de la variable next pour iterer une liste chainée de B, sans perdre les specificités du B?
list_b //liste chainée de B
for(A* iter = list_b->next; iter != null; iter = iter->next) une_methode_qui_prends_un_B_en_Param(*iter);
ou doit-on "caster" (si oui lequel "static", "reinterpret"?)
static_cast ou dynamic_cast.
static_cast necessite que tu sois sur par un autre moyen que le pointeur pointe bien vers un B (dynamic_cast retourne un pointeur nul si ce n'est pas le cas)
dynamic_cast necessite d'avoir une fonction virtuelle dans A
On 27 Aug 2007 11:24:47 +0200, Jean-Marc Bourguet :
dynamic_cast necessite d'avoir une fonction virtuelle dans A
Vu l'usage qui est fait de A, j'espère bien que son destructeur est virtuel...
Jean-Marc Bourguet
Fabien LE LEZ writes:
On 27 Aug 2007 11:24:47 +0200, Jean-Marc Bourguet :
dynamic_cast necessite d'avoir une fonction virtuelle dans A
Vu l'usage qui est fait de A, j'espère bien que son destructeur est virtuel...
Le code donne est insuffisant pour savoir si il detruit des descendant de A a partir de pointeurs vers A, ce qui est la seule raison de rendre le destructeur de A virtuel.
On 27 Aug 2007 11:24:47 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
dynamic_cast necessite d'avoir une fonction virtuelle dans A
Vu l'usage qui est fait de A, j'espère bien que son destructeur est
virtuel...
Le code donne est insuffisant pour savoir si il detruit des descendant de A
a partir de pointeurs vers A, ce qui est la seule raison de rendre le
destructeur de A virtuel.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
On 27 Aug 2007 11:24:47 +0200, Jean-Marc Bourguet :
dynamic_cast necessite d'avoir une fonction virtuelle dans A
Vu l'usage qui est fait de A, j'espère bien que son destructeur est virtuel...
Le code donne est insuffisant pour savoir si il detruit des descendant de A a partir de pointeurs vers A, ce qui est la seule raison de rendre le destructeur de A virtuel.
"Jean-Marc Bourguet" a écrit dans le message de news:
Le code donne est insuffisant pour savoir si il detruit des descendant de A a partir de pointeurs vers A, ce qui est la seule raison de rendre le destructeur de A virtuel.
Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de news:
pxbzm0dtinx.fsf@news.bourguet.org...
Le code donne est insuffisant pour savoir si il detruit des descendant de
A
a partir de pointeurs vers A, ce qui est la seule raison de rendre le
destructeur de A virtuel.
Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
"Jean-Marc Bourguet" a écrit dans le message de news:
Le code donne est insuffisant pour savoir si il detruit des descendant de A a partir de pointeurs vers A, ce qui est la seule raison de rendre le destructeur de A virtuel.
Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
Sylvain
Bruno Causse wrote on 27/08/2007 12:09:
Le code donne est insuffisant pour savoir si il detruit des descendant de A à partir de pointeurs vers A, ce qui est la seule raison de rendre le destructeur de A virtuel.
Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se générer des ennuis plus tard) avoir un destructeur virtuel.
elle pourrait également définir un service virtuel ce qui éviterait les questions du dynamic_cast et les constructions byzarres ou une fonction (peut être "à la C") prendra un B& ou B* en paramètre - il est généralement très préférable d'utiliser une méthode membre.
class A { private: A* _next public: virtual ~A(){} A* next() { return _next; } virtual type foo() = null; };
class B : public A { public: type foo() { ... } };
list_b //liste chainée de B
for (A* iter = list_b; iter != null; iter = iter->next()) iter->foo();
Sylvain.
Bruno Causse wrote on 27/08/2007 12:09:
Le code donne est insuffisant pour savoir si il detruit des descendant de
A à partir de pointeurs vers A, ce qui est la seule raison de rendre le
destructeur de A virtuel.
Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se
générer des ennuis plus tard) avoir un destructeur virtuel.
elle pourrait également définir un service virtuel ce qui éviterait les
questions du dynamic_cast et les constructions byzarres ou une fonction
(peut être "à la C") prendra un B& ou B* en paramètre - il est
généralement très préférable d'utiliser une méthode membre.
class A {
private:
A* _next
public:
virtual ~A(){}
A* next() { return _next; }
virtual type foo() = null;
};
class B : public A {
public:
type foo() { ... }
};
list_b //liste chainée de B
for (A* iter = list_b; iter != null; iter = iter->next())
iter->foo();
Le code donne est insuffisant pour savoir si il detruit des descendant de A à partir de pointeurs vers A, ce qui est la seule raison de rendre le destructeur de A virtuel.
Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se générer des ennuis plus tard) avoir un destructeur virtuel.
elle pourrait également définir un service virtuel ce qui éviterait les questions du dynamic_cast et les constructions byzarres ou une fonction (peut être "à la C") prendra un B& ou B* en paramètre - il est généralement très préférable d'utiliser une méthode membre.
class A { private: A* _next public: virtual ~A(){} A* next() { return _next; } virtual type foo() = null; };
class B : public A { public: type foo() { ... } };
list_b //liste chainée de B
for (A* iter = list_b; iter != null; iter = iter->next()) iter->foo();
Sylvain.
Jean-Marc Bourguet
Sylvain writes:
Bruno Causse wrote on 27/08/2007 12:09:
Le code donne est insuffisant pour savoir si il detruit des descendant de A à partir de pointeurs vers A, ce qui est la seule raison de rendre le destructeur de A virtuel. Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se générer des ennuis plus tard) avoir un destructeur virtuel.
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne vois par l'interet d'un destructeur virtuel.
Le code donne est insuffisant pour savoir si il detruit des descendant de
A à partir de pointeurs vers A, ce qui est la seule raison de rendre le
destructeur de A virtuel.
Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se
générer des ennuis plus tard) avoir un destructeur virtuel.
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne
vois par l'interet d'un destructeur virtuel.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Le code donne est insuffisant pour savoir si il detruit des descendant de A à partir de pointeurs vers A, ce qui est la seule raison de rendre le destructeur de A virtuel. Non, uniquement utilisé en variable "automatique", portée dans "scoop"
la class A ne possede que les constructeur/destructeur par defaut.
elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se générer des ennuis plus tard) avoir un destructeur virtuel.
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne vois par l'interet d'un destructeur virtuel.
On 27 Aug 2007 16:50:55 +0200, Jean-Marc Bourguet :
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne vois par l'interet d'un destructeur virtuel.
Dans le cas présent, on joue avec des A* qui pointent sur des B, et franchement, il faut réfléchir un petit moment pour se convaincre qu'une vtable est, par conception, inutile. Et dès qu'on a au moins une fonction virtuelle, autant déclarer le destructeur virtuel également, ça ne pénalise guère et ça évitera bien des problèmes dans le futur.
Par ailleurs, je veux bien qu'on m'explique comment implémenter proprement une liste chaînée en mettant tous les éléments sur la pile. Ça fleure bon les accès à des pointeurs invalidés.
Au fait, il y en a beaucoup, des classes qui, par conception, n'ont de sens qu'instanciées sur la pile ?
On 27 Aug 2007 16:50:55 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne
vois par l'interet d'un destructeur virtuel.
Dans le cas présent, on joue avec des A* qui pointent sur des B, et
franchement, il faut réfléchir un petit moment pour se convaincre
qu'une vtable est, par conception, inutile.
Et dès qu'on a au moins une fonction virtuelle, autant déclarer le
destructeur virtuel également, ça ne pénalise guère et ça évitera bien
des problèmes dans le futur.
Par ailleurs, je veux bien qu'on m'explique comment implémenter
proprement une liste chaînée en mettant tous les éléments sur la pile.
Ça fleure bon les accès à des pointeurs invalidés.
Au fait, il y en a beaucoup, des classes qui, par conception, n'ont de
sens qu'instanciées sur la pile ?
On 27 Aug 2007 16:50:55 +0200, Jean-Marc Bourguet :
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne vois par l'interet d'un destructeur virtuel.
Dans le cas présent, on joue avec des A* qui pointent sur des B, et franchement, il faut réfléchir un petit moment pour se convaincre qu'une vtable est, par conception, inutile. Et dès qu'on a au moins une fonction virtuelle, autant déclarer le destructeur virtuel également, ça ne pénalise guère et ça évitera bien des problèmes dans le futur.
Par ailleurs, je veux bien qu'on m'explique comment implémenter proprement une liste chaînée en mettant tous les éléments sur la pile. Ça fleure bon les accès à des pointeurs invalidés.
Au fait, il y en a beaucoup, des classes qui, par conception, n'ont de sens qu'instanciées sur la pile ?
Bruno Causse
"Fabien LE LEZ" a écrit dans le message de news:
Par ailleurs, je veux bien qu'on m'explique comment implémenter proprement une liste chaînée en mettant tous les éléments sur la pile. Ça fleure bon les accès à des pointeurs invalidés.
bah, les listes chainées sont les listes de coups valides sur un jeu de plateau, j'en examine 2 500 000 par seconde en mileu de partie et pres de 7 000 000 en fin de partie
pour info les A sont pour la fin de parties / les B pour le mileu (plus d'information sur la position)
le programme tourne depuis plusieurs année sans "trop" (parfois il perd :-( ) de probleme.
pour info: je reflechi aux modifications pour implementer un alpha beta parallele. l'instanciation sur la pile me fais gagner 15 % par rapport au tas (new/delete)
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
9gp5d3pgnqa8a0kvd3opkhcvjuk6h5qu50@4ax.com...
Par ailleurs, je veux bien qu'on m'explique comment implémenter
proprement une liste chaînée en mettant tous les éléments sur la pile.
Ça fleure bon les accès à des pointeurs invalidés.
bah, les listes chainées sont les listes de coups valides sur un jeu de
plateau, j'en examine 2 500 000 par seconde en mileu de partie et pres de 7
000 000 en fin de partie
pour info les A sont pour la fin de parties / les B pour le mileu (plus
d'information sur la position)
le programme tourne depuis plusieurs année sans "trop" (parfois il perd
:-( ) de probleme.
pour info: je reflechi aux modifications pour implementer un alpha beta
parallele. l'instanciation sur la pile me fais gagner 15 % par rapport au
tas (new/delete)
Par ailleurs, je veux bien qu'on m'explique comment implémenter proprement une liste chaînée en mettant tous les éléments sur la pile. Ça fleure bon les accès à des pointeurs invalidés.
bah, les listes chainées sont les listes de coups valides sur un jeu de plateau, j'en examine 2 500 000 par seconde en mileu de partie et pres de 7 000 000 en fin de partie
pour info les A sont pour la fin de parties / les B pour le mileu (plus d'information sur la position)
le programme tourne depuis plusieurs année sans "trop" (parfois il perd :-( ) de probleme.
pour info: je reflechi aux modifications pour implementer un alpha beta parallele. l'instanciation sur la pile me fais gagner 15 % par rapport au tas (new/delete)
Sylvain
Jean-Marc Bourguet wrote on 27/08/2007 16:50:
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne vois par l'interet d'un destructeur virtuel.
hmm, une liste chainée sur la pile ?!... mais Fabien a déjà répondu.
Sylvain.
Jean-Marc Bourguet wrote on 27/08/2007 16:50:
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne
vois par l'interet d'un destructeur virtuel.
hmm, une liste chainée sur la pile ?!...
mais Fabien a déjà répondu.