Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
Je suis pas sûr que la présence ou l'absence du destructeur virtuel soit la cause première de la réaction de Gaby.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ?
D'une manière générale, oui. Il y a des exceptions. Le CRTP, par exemple, introduit facilement des cas où on a une classe de base publique sans jamais vouloir utiliser des pointeurs vers cette classe de base.
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Pourquoi l'imposer s'il n'y a pas de destruction via un pointeur sur la classe de base? On pourrait penser que le message implicite quand on met le destructeur virtuel, c'est que les destructions de ce type sont autorisées.
En général, oui c'est une bonne idée pour les classes de base d'avoir leur destructeur virtuel. Mais il y a des exceptions. On peut préciser pour essayer de ne pas avoir autant de faux positifs (par exemple en disant "pour les classes de base ayant un membre virtuel"), mais il en restera. On peut aussi commencer à contester la justification des exceptions en disant que le respect de la règle est plus important (par exemple pour l'évolution) que les raisons invoquées pour justifier les exceptions.
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
David Fleury <dfleury2@libertysurf.fr> writes:
Je ne suis pas sûr de comprendre le débat sur la présence ou absence
du destructeur virtuel.
Je suis pas sûr que la présence ou l'absence du destructeur virtuel soit la
cause première de la réaction de Gaby.
De manière générale, un héritage publique n'est pas censé être
une façon de dire "est un", et le principe de substitution ne
devrait-il pas être de mise ?
D'une manière générale, oui. Il y a des exceptions. Le CRTP, par exemple,
introduit facilement des cas où on a une classe de base publique sans
jamais vouloir utiliser des pointeurs vers cette classe de base.
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne
devrait-il pas être présent dans la classe mère ?
Pourquoi l'imposer s'il n'y a pas de destruction via un pointeur sur la
classe de base? On pourrait penser que le message implicite quand on met
le destructeur virtuel, c'est que les destructions de ce type sont
autorisées.
En général, oui c'est une bonne idée pour les classes de base d'avoir leur
destructeur virtuel. Mais il y a des exceptions. On peut préciser pour
essayer de ne pas avoir autant de faux positifs (par exemple en disant
"pour les classes de base ayant un membre virtuel"), mais il en restera.
On peut aussi commencer à contester la justification des exceptions en
disant que le respect de la règle est plus important (par exemple pour
l'évolution) que les raisons invoquées pour justifier les exceptions.
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
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
Je suis pas sûr que la présence ou l'absence du destructeur virtuel soit la cause première de la réaction de Gaby.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ?
D'une manière générale, oui. Il y a des exceptions. Le CRTP, par exemple, introduit facilement des cas où on a une classe de base publique sans jamais vouloir utiliser des pointeurs vers cette classe de base.
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Pourquoi l'imposer s'il n'y a pas de destruction via un pointeur sur la classe de base? On pourrait penser que le message implicite quand on met le destructeur virtuel, c'est que les destructions de ce type sont autorisées.
En général, oui c'est une bonne idée pour les classes de base d'avoir leur destructeur virtuel. Mais il y a des exceptions. On peut préciser pour essayer de ne pas avoir autant de faux positifs (par exemple en disant "pour les classes de base ayant un membre virtuel"), mais il en restera. On peut aussi commencer à contester la justification des exceptions en disant que le respect de la règle est plus important (par exemple pour l'évolution) que les raisons invoquées pour justifier les exceptions.
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
Sylvain
David Fleury wrote on 28/08/2007 20:07:
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
ditto.
[...] Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
je ne suis pas sur non plus de comprendre où le mode de déclaration de l'instance devrait être un facteur déterminant; et en effet l'usage naturel (la vocation même) de la classe me semble plus pertinente.
de fait, mes instances locales (en pile) sont à 99% des classes utilitaires non virtuelles tandis que les classes "de stockage" et "de traitement avancé" sont à 99% virtuelles et allouées - la présence d'un destructeur virtuel est alors une simple évidence.
Sylvain.
David Fleury wrote on 28/08/2007 20:07:
Je ne suis pas sûr de comprendre le débat sur la présence ou absence
du destructeur virtuel.
ditto.
[...]
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel
ne devrait-il pas être présent dans la classe mère ?
je ne suis pas sur non plus de comprendre où le mode de déclaration de
l'instance devrait être un facteur déterminant; et en effet l'usage
naturel (la vocation même) de la classe me semble plus pertinente.
de fait, mes instances locales (en pile) sont à 99% des classes
utilitaires non virtuelles tandis que les classes "de stockage" et "de
traitement avancé" sont à 99% virtuelles et allouées - la présence d'un
destructeur virtuel est alors une simple évidence.
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
ditto.
[...] Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
je ne suis pas sur non plus de comprendre où le mode de déclaration de l'instance devrait être un facteur déterminant; et en effet l'usage naturel (la vocation même) de la classe me semble plus pertinente.
de fait, mes instances locales (en pile) sont à 99% des classes utilitaires non virtuelles tandis que les classes "de stockage" et "de traitement avancé" sont à 99% virtuelles et allouées - la présence d'un destructeur virtuel est alors une simple évidence.
Sylvain.
Gabriel Dos Reis
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools.
| > On Mon, 27 Aug 2007, Sylvain wrote: | > | > | 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. | > | > contre vents et marees ? | > | | Je ne suis pas sûr de comprendre le débat sur la présence ou absence | du destructeur virtuel. | | De manière générale, un héritage publique n'est pas censé être | une façon de dire "est un",
Non, pas forcement. Du moins, pas dans le sens rigide de LSP.
-- Gaby --8323584-677897512-1188353259=:17711--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
| > On Mon, 27 Aug 2007, Sylvain wrote:
| >
| > | 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.
| >
| > contre vents et marees ?
| >
|
| Je ne suis pas sûr de comprendre le débat sur la présence ou absence
| du destructeur virtuel.
|
| De manière générale, un héritage publique n'est pas censé être
| une façon de dire "est un",
Non, pas forcement. Du moins, pas dans le sens rigide de LSP.
| > On Mon, 27 Aug 2007, Sylvain wrote: | > | > | 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. | > | > contre vents et marees ? | > | | Je ne suis pas sûr de comprendre le débat sur la présence ou absence | du destructeur virtuel. | | De manière générale, un héritage publique n'est pas censé être | une façon de dire "est un",
Non, pas forcement. Du moins, pas dans le sens rigide de LSP.
-- Gaby --8323584-677897512-1188353259=:17711--
David Fleury
David Fleury wrote on 28/08/2007 20:07:
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
ditto.
[...] Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
je ne suis pas sur non plus de comprendre où le mode de déclaration de l'instance devrait être un facteur déterminant; et en effet l'usage naturel (la vocation même) de la classe me semble plus pertinente.
de fait, mes instances locales (en pile) sont à 99% des classes utilitaires non virtuelles tandis que les classes "de stockage" et "de traitement avancé" sont à 99% virtuelles et allouées - la présence d'un destructeur virtuel est alors une simple évidence.
Sylvain.
Je crois que j'ai aussi cette expérience là dans le code que j'écris en effet.
David Fleury wrote on 28/08/2007 20:07:
Je ne suis pas sûr de comprendre le débat sur la présence ou absence
du destructeur virtuel.
ditto.
[...]
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel
ne devrait-il pas être présent dans la classe mère ?
je ne suis pas sur non plus de comprendre où le mode de déclaration de
l'instance devrait être un facteur déterminant; et en effet l'usage
naturel (la vocation même) de la classe me semble plus pertinente.
de fait, mes instances locales (en pile) sont à 99% des classes
utilitaires non virtuelles tandis que les classes "de stockage" et "de
traitement avancé" sont à 99% virtuelles et allouées - la présence d'un
destructeur virtuel est alors une simple évidence.
Sylvain.
Je crois que j'ai aussi cette expérience là dans le code que j'écris
en effet.
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
ditto.
[...] Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
je ne suis pas sur non plus de comprendre où le mode de déclaration de l'instance devrait être un facteur déterminant; et en effet l'usage naturel (la vocation même) de la classe me semble plus pertinente.
de fait, mes instances locales (en pile) sont à 99% des classes utilitaires non virtuelles tandis que les classes "de stockage" et "de traitement avancé" sont à 99% virtuelles et allouées - la présence d'un destructeur virtuel est alors une simple évidence.
Sylvain.
Je crois que j'ai aussi cette expérience là dans le code que j'écris en effet.
David Fleury
On Mon, 27 Aug 2007, Sylvain wrote:
| 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.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ?
L'héritage peut être utilisée pour signifier "Est un" (public) ou "Est implémenté en terme de" (privé).
Oui oui j'entends bien. même si j'utilise aussi (et plutôt) la composition pour "implémenté en terme de".
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Pas stricto-sensus dans le norme actuelle, le destructeur virtuel est surtout utilise en cas d'appel explicite à delete comme par exemple:
class A {...}; class B: public A {...};
A* a = new B();
delete a;
Si le destructeur de A n'est pas virtuel, le destructeur de B ne sera pas appelé.
Mais si l'objet est dans la pile, c'est le bon destructeur qui sera appelé.
Mais bon, en cas d'héritage le destructeur devrait être virtuel pour éviter ces problèmes et gcc émet un warning, je crois, si ce n'est pas le cas.
Michael
Ok. Merci
On Mon, 27 Aug 2007, Sylvain wrote:
| 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.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence
du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être
une façon de dire "est un", et le principe de substitution ne
devrait-il pas être de mise ?
L'héritage peut être utilisée pour signifier "Est un" (public) ou "Est
implémenté en terme de" (privé).
Oui oui j'entends bien.
même si j'utilise aussi (et plutôt) la composition pour "implémenté
en terme de".
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel
ne devrait-il pas être présent dans la classe mère ?
Pas stricto-sensus dans le norme actuelle, le destructeur virtuel est
surtout utilise en cas d'appel explicite à delete comme par exemple:
class A {...};
class B: public A {...};
A* a = new B();
delete a;
Si le destructeur de A n'est pas virtuel, le destructeur de B ne sera
pas appelé.
Mais si l'objet est dans la pile, c'est le bon destructeur qui sera appelé.
Mais bon, en cas d'héritage le destructeur devrait être virtuel pour
éviter ces problèmes et gcc émet un warning, je crois, si ce n'est pas
le cas.
| 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.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ?
L'héritage peut être utilisée pour signifier "Est un" (public) ou "Est implémenté en terme de" (privé).
Oui oui j'entends bien. même si j'utilise aussi (et plutôt) la composition pour "implémenté en terme de".
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Pas stricto-sensus dans le norme actuelle, le destructeur virtuel est surtout utilise en cas d'appel explicite à delete comme par exemple:
class A {...}; class B: public A {...};
A* a = new B();
delete a;
Si le destructeur de A n'est pas virtuel, le destructeur de B ne sera pas appelé.
Mais si l'objet est dans la pile, c'est le bon destructeur qui sera appelé.
Mais bon, en cas d'héritage le destructeur devrait être virtuel pour éviter ces problèmes et gcc émet un warning, je crois, si ce n'est pas le cas.
Michael
Ok. Merci
David Fleury
David Fleury writes:
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
Je suis pas sûr que la présence ou l'absence du destructeur virtuel soit la cause première de la réaction de Gaby.
Au vue de sa réponse j'avais. Si ce n'est pas le cas, j'ai juste mal compris. désolé.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ?
D'une manière générale, oui. Il y a des exceptions. Le CRTP, par exemple, introduit facilement des cas où on a une classe de base publique sans jamais vouloir utiliser des pointeurs vers cette classe de base.
CRTP est quand même en cas rare et avancé (peut être les 1% ...) Perso, je ne l'ai essayé qu'une fois et malgré l'aide demandée ici, visual studio n'a pas voulu me le compiler ;)
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Pourquoi l'imposer s'il n'y a pas de destruction via un pointeur sur la classe de base? On pourrait penser que le message implicite quand on met le destructeur virtuel, c'est que les destructions de ce type sont autorisées.
En général, oui c'est une bonne idée pour les classes de base d'avoir leur destructeur virtuel. Mais il y a des exceptions. On peut préciser pour essayer de ne pas avoir autant de faux positifs (par exemple en disant "pour les classes de base ayant un membre virtuel"), mais il en restera. On peut aussi commencer à contester la justification des exceptions en disant que le respect de la règle est plus important (par exemple pour l'évolution) que les raisons invoquées pour justifier les exceptions.
C'est vrai que décrit comme cela, ma façon de voir laisse sous-entendre des suppositions sur le code. La principale étant que héritage <-> fonctions virtuelles
Merci.
David Fleury <dfleury2@libertysurf.fr> writes:
Je ne suis pas sûr de comprendre le débat sur la présence ou absence
du destructeur virtuel.
Je suis pas sûr que la présence ou l'absence du destructeur virtuel soit la
cause première de la réaction de Gaby.
Au vue de sa réponse j'avais.
Si ce n'est pas le cas, j'ai juste mal compris. désolé.
De manière générale, un héritage publique n'est pas censé être
une façon de dire "est un", et le principe de substitution ne
devrait-il pas être de mise ?
D'une manière générale, oui. Il y a des exceptions. Le CRTP, par exemple,
introduit facilement des cas où on a une classe de base publique sans
jamais vouloir utiliser des pointeurs vers cette classe de base.
CRTP est quand même en cas rare et avancé (peut être les 1% ...)
Perso, je ne l'ai essayé qu'une fois et malgré l'aide demandée ici,
visual studio n'a pas voulu me le compiler ;)
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne
devrait-il pas être présent dans la classe mère ?
Pourquoi l'imposer s'il n'y a pas de destruction via un pointeur sur la
classe de base? On pourrait penser que le message implicite quand on met
le destructeur virtuel, c'est que les destructions de ce type sont
autorisées.
En général, oui c'est une bonne idée pour les classes de base d'avoir leur
destructeur virtuel. Mais il y a des exceptions. On peut préciser pour
essayer de ne pas avoir autant de faux positifs (par exemple en disant
"pour les classes de base ayant un membre virtuel"), mais il en restera.
On peut aussi commencer à contester la justification des exceptions en
disant que le respect de la règle est plus important (par exemple pour
l'évolution) que les raisons invoquées pour justifier les exceptions.
C'est vrai que décrit comme cela, ma façon de voir laisse sous-entendre
des suppositions sur le code.
La principale étant que héritage <-> fonctions virtuelles
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
Je suis pas sûr que la présence ou l'absence du destructeur virtuel soit la cause première de la réaction de Gaby.
Au vue de sa réponse j'avais. Si ce n'est pas le cas, j'ai juste mal compris. désolé.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ?
D'une manière générale, oui. Il y a des exceptions. Le CRTP, par exemple, introduit facilement des cas où on a une classe de base publique sans jamais vouloir utiliser des pointeurs vers cette classe de base.
CRTP est quand même en cas rare et avancé (peut être les 1% ...) Perso, je ne l'ai essayé qu'une fois et malgré l'aide demandée ici, visual studio n'a pas voulu me le compiler ;)
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Pourquoi l'imposer s'il n'y a pas de destruction via un pointeur sur la classe de base? On pourrait penser que le message implicite quand on met le destructeur virtuel, c'est que les destructions de ce type sont autorisées.
En général, oui c'est une bonne idée pour les classes de base d'avoir leur destructeur virtuel. Mais il y a des exceptions. On peut préciser pour essayer de ne pas avoir autant de faux positifs (par exemple en disant "pour les classes de base ayant un membre virtuel"), mais il en restera. On peut aussi commencer à contester la justification des exceptions en disant que le respect de la règle est plus important (par exemple pour l'évolution) que les raisons invoquées pour justifier les exceptions.
C'est vrai que décrit comme cela, ma façon de voir laisse sous-entendre des suppositions sur le code. La principale étant que héritage <-> fonctions virtuelles
