tout d'abord, merci à tous pour ce newsgroup très instructif, c'est la
première fois que je poste, alors je vais essayer de ne pas me faire
incendier par Fabien ;) :p
Voila mon problème : j'ai un client qui souhaite que toutes les classes
définies dans le projet sur lequel je travaille soient sous la forme
canonique de Coplien (pour ceux qui ne connaissent pas : constructeur
par défaut, constructeur par copie, operateur d'affectation et
destructeur virtuel ou non). Pour que ce soit plus clean (selon eux), le
client demande que toutes les classes dérivent d'une classe de base...
Sauf que je ne vois pas du tout l'intéret de faire ca car je ne vois pas
en quoi ca force à respecter la forme canonique de Coplien.
Concernant l'operateur d'affectation, si je le met virtuel (est ce
quelque chose de propre ?!) comment puis je faire en sorte que les
classes filles utilisent un opérateur correct ? cast dynamique ?
Concernant l'operateur de recopie, là, je vois pas du tout du tout du
tout :)
Bref, je comprends pas du tout cette demande, si quelqu'un pense que
c'est raisonable ou explicable, je veux bien une précision sur l'utilité...
Pour terminer, il faut aussi déporter le code du constructeur et du
destructeur dans une fonction séparée, et là, je comprends plus du
tout... genre quelque chose comme ca :
T::T(void)
{
construct();
}
T::~T(void)
{
destruct();
}
void T::construct(void)
{
// ...
}
void T::destruct(void)
{
// ...
}
Voila voila, votre avis est le bienvenu :)
Merci d'avance,
Malheureusement, il l'a bien nommé « forme canonique », sans autres précisions.
Il l'a appele la forme canonique orthodoxe. Plus loin il y en au moins deux autres, une pour l'heritage, une pour les manipulations symboliques.
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
kanze@gabi-soft.fr writes:
Malheureusement, il l'a bien nommé « forme canonique », sans autres
précisions.
Il l'a appele la forme canonique orthodoxe. Plus loin il y en au
moins deux autres, une pour l'heritage, une pour les manipulations
symboliques.
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
Malheureusement, il l'a bien nommé « forme canonique », sans autres précisions.
Il l'a appele la forme canonique orthodoxe. Plus loin il y en au moins deux autres, une pour l'heritage, une pour les manipulations symboliques.
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
Laurent Deniau
Jean-Marc Bourguet wrote:
Laurent Deniau writes:
- que toutes les classes soient avec * constructeur par defaut, desole j'ai des classes qui n'en ont pas et je ne vois aucune raison d'en imposer un artificiel
Forcer le developpeur a reflechir a l'etat par defaut de son objet, ne pas se bloquer la possibilite de faire des tableaux de ses objets (pour optimiser ulterieurement des containeurs?).
Les containeurs de la bibliotheque standard sont utilisables sans constructeur par defaut. Il faut simplement fournir un objet a copier.
Oui et pour pouvoir faire ca, ils redefinissent operator new [] () a partir void* operator new [] (size_t) et de toute l'artillerie de <mem>: allocator et autre uninitialized_fill_n().
Ce n'est pas forcement le choix du client de se lancer dans cette aventure.
J'ai souvent vu des classes avec des constructeurs avec parametres mais pas de redefinition du constructeur par defaut sans qu'il soit qualifie protected (desactive),
et avec des methodes utilisant des ressources de l'objet sans verifier qu'elles avaient bien ete initialisees (pensant venir forcement d'un constructeur avec parametres).
J'ai l'impression que tu oublies que des qu'il y a un constructeur declare par le programmeur, le constructeur par defaut n'est pas declare implicitement.
Oui. Je voulais dire qu'au minimum, si le constructeur par defaut est (visiblement) declare, cela oblige le developpeur a savoir s'il veut le definir ou le declarer en private/protected. Jouer sur le fait qu'il est impliciement ecarte peut etre source d'oublis sur un gros projet.
- que toutes les classes derivent d'une classe de base * c'est impraticable (comment on fait pour imposer la classe de base de std::vector, de classes derivees a partir d'elements d'une bibliotheque tierce ?)
Je pense qu'il parle seulement des classes du projet.
Si on utilise des choses d'ailleurs (allez, on definit un streambuf) pourquoi s'imposer de l'heritage multiple? Je n'aime pas les regles trop absolues.
Je suis d'accord. Mais il faut peut-etre voir cela comme un standard de codage (tous les programmeurs C++ n'ont pas le meme niveau) et simplifier/optimiser plus tard, quand l'ensemble est bien etabli.
* si c'est pour imposer la forme canonique je ne vois pas comment faire (tiens sauf pour qqch du genre NotCopiable... mais avec une telle classe de base, definir l'assignement et le constructeur de copie, c'est de la perversite) * ca me fait plutot penser a quelqu'un qui a de l'experience d'un autre langage ou cette classe de base est presente d'office que du C++ (tiens bizarrement c'etait la mode au debut du C++ quand pour une partie des gens OO signifiait SmallTalk)
Apres reflexion et le bug de design sur construct et destruct, je crois que tu as raison. Ils viennent peut-etre de Java. Ce qui est etonnant, c'est que la forme Coplien n'a pas de sens en Java. Alors pourquoi la demande-t-ils?
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas compris grand chose au C++ et ont mal digere un bouquin ou des conseils - l'OP a mal compris les demandes.
pas mieux.
a+, ld.
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
- que toutes les classes soient avec * constructeur par defaut,
desole j'ai des classes qui n'en ont pas et je ne vois aucune
raison d'en imposer un artificiel
Forcer le developpeur a reflechir a l'etat par defaut de son objet,
ne pas se bloquer la possibilite de faire des tableaux de ses
objets (pour optimiser ulterieurement des containeurs?).
Les containeurs de la bibliotheque standard sont utilisables sans
constructeur par defaut. Il faut simplement fournir un objet a
copier.
Oui et pour pouvoir faire ca, ils redefinissent operator new [] () a
partir void* operator new [] (size_t) et de toute l'artillerie de <mem>:
allocator et autre uninitialized_fill_n().
Ce n'est pas forcement le choix du client de se lancer dans cette aventure.
J'ai souvent vu des classes avec des constructeurs avec parametres
mais pas de redefinition du constructeur par defaut sans qu'il soit
qualifie protected (desactive),
et avec des methodes utilisant des ressources de l'objet sans
verifier qu'elles avaient bien ete initialisees (pensant venir
forcement d'un constructeur avec parametres).
J'ai l'impression que tu oublies que des qu'il y a un constructeur
declare par le programmeur, le constructeur par defaut n'est pas
declare implicitement.
Oui. Je voulais dire qu'au minimum, si le constructeur par defaut est
(visiblement) declare, cela oblige le developpeur a savoir s'il veut le
definir ou le declarer en private/protected. Jouer sur le fait qu'il est
impliciement ecarte peut etre source d'oublis sur un gros projet.
- que toutes les classes derivent d'une classe de base * c'est
impraticable (comment on fait pour imposer la classe de base de
std::vector, de classes derivees a partir d'elements d'une
bibliotheque tierce ?)
Je pense qu'il parle seulement des classes du projet.
Si on utilise des choses d'ailleurs (allez, on definit un streambuf)
pourquoi s'imposer de l'heritage multiple? Je n'aime pas les regles
trop absolues.
Je suis d'accord. Mais il faut peut-etre voir cela comme un standard de
codage (tous les programmeurs C++ n'ont pas le meme niveau) et
simplifier/optimiser plus tard, quand l'ensemble est bien etabli.
* si c'est pour imposer la forme canonique je ne vois pas comment
faire (tiens sauf pour qqch du genre NotCopiable... mais avec
une telle classe de base, definir l'assignement et le
constructeur de copie, c'est de la perversite) * ca me fait
plutot penser a quelqu'un qui a de l'experience d'un autre
langage ou cette classe de base est presente d'office que du C++
(tiens bizarrement c'etait la mode au debut du C++ quand pour une
partie des gens OO signifiait SmallTalk)
Apres reflexion et le bug de design sur construct et destruct, je
crois que tu as raison. Ils viennent peut-etre de Java. Ce qui est
etonnant, c'est que la forme Coplien n'a pas de sens en Java.
Alors pourquoi la demande-t-ils?
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas
compris grand chose au C++ et ont mal digere un bouquin ou des
conseils - l'OP a mal compris les demandes.
- que toutes les classes soient avec * constructeur par defaut, desole j'ai des classes qui n'en ont pas et je ne vois aucune raison d'en imposer un artificiel
Forcer le developpeur a reflechir a l'etat par defaut de son objet, ne pas se bloquer la possibilite de faire des tableaux de ses objets (pour optimiser ulterieurement des containeurs?).
Les containeurs de la bibliotheque standard sont utilisables sans constructeur par defaut. Il faut simplement fournir un objet a copier.
Oui et pour pouvoir faire ca, ils redefinissent operator new [] () a partir void* operator new [] (size_t) et de toute l'artillerie de <mem>: allocator et autre uninitialized_fill_n().
Ce n'est pas forcement le choix du client de se lancer dans cette aventure.
J'ai souvent vu des classes avec des constructeurs avec parametres mais pas de redefinition du constructeur par defaut sans qu'il soit qualifie protected (desactive),
et avec des methodes utilisant des ressources de l'objet sans verifier qu'elles avaient bien ete initialisees (pensant venir forcement d'un constructeur avec parametres).
J'ai l'impression que tu oublies que des qu'il y a un constructeur declare par le programmeur, le constructeur par defaut n'est pas declare implicitement.
Oui. Je voulais dire qu'au minimum, si le constructeur par defaut est (visiblement) declare, cela oblige le developpeur a savoir s'il veut le definir ou le declarer en private/protected. Jouer sur le fait qu'il est impliciement ecarte peut etre source d'oublis sur un gros projet.
- que toutes les classes derivent d'une classe de base * c'est impraticable (comment on fait pour imposer la classe de base de std::vector, de classes derivees a partir d'elements d'une bibliotheque tierce ?)
Je pense qu'il parle seulement des classes du projet.
Si on utilise des choses d'ailleurs (allez, on definit un streambuf) pourquoi s'imposer de l'heritage multiple? Je n'aime pas les regles trop absolues.
Je suis d'accord. Mais il faut peut-etre voir cela comme un standard de codage (tous les programmeurs C++ n'ont pas le meme niveau) et simplifier/optimiser plus tard, quand l'ensemble est bien etabli.
* si c'est pour imposer la forme canonique je ne vois pas comment faire (tiens sauf pour qqch du genre NotCopiable... mais avec une telle classe de base, definir l'assignement et le constructeur de copie, c'est de la perversite) * ca me fait plutot penser a quelqu'un qui a de l'experience d'un autre langage ou cette classe de base est presente d'office que du C++ (tiens bizarrement c'etait la mode au debut du C++ quand pour une partie des gens OO signifiait SmallTalk)
Apres reflexion et le bug de design sur construct et destruct, je crois que tu as raison. Ils viennent peut-etre de Java. Ce qui est etonnant, c'est que la forme Coplien n'a pas de sens en Java. Alors pourquoi la demande-t-ils?
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas compris grand chose au C++ et ont mal digere un bouquin ou des conseils - l'OP a mal compris les demandes.
pas mieux.
a+, ld.
Laurent Deniau
Jean-Marc Bourguet wrote:
Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du type de la classe construite (et non de la classe la plus derivee).
Je savais pour les constructeurs (ce qui me fait penser que j'ai dit une betise dans l'autre post, le virtual de construct et destruct est inutile), mais je ne savais pas pour les destructeurs... Autant le premier me parait logique autant j'ai du mal a comprendre la raison du second.
Exactement les raisons symetriques. Par exemple lors de l'execution du constructeur, les membres des classes descendantes n'ont pas encore ete construit, pendant l'execution du destructeur ils ont deja ete detruits.
J'ai retrouve pourquoi j'etais reste avec l'idee que les destructeurs etaient virtuel.
C'est dans l'exemple de la redefinition de l'operateur membre void operator delete(void*, size_t) (TC++PL3 15.6 Free Store). Pour que le size_t soit correct et reflete bien la taille du type de la classe derivee meme si delete est applique sur un type de la classe de base tandis que l'objet pointe est du type derive, il faut que le destructeur de la classe de base soit virtuel.
J'ai fait un racourci en deduisant que le destructeur etait virtuel. Alors que le virtual n'est en fait utilise ici que pour obtenir un pointeur vers la vtbl et que les RTTI fonctionnent correctement pour recuperer la taille du type derive. D'ou ma confusion.
a+, ld.
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Pendant l'execution du constructeur et du destructeur, l'objet est
du type de la classe construite (et non de la classe la plus
derivee).
Je savais pour les constructeurs (ce qui me fait penser que j'ai dit
une betise dans l'autre post, le virtual de construct et destruct
est inutile), mais je ne savais pas pour les destructeurs... Autant
le premier me parait logique autant j'ai du mal a comprendre la
raison du second.
Exactement les raisons symetriques. Par exemple lors de l'execution
du constructeur, les membres des classes descendantes n'ont pas encore
ete construit, pendant l'execution du destructeur ils ont deja ete
detruits.
J'ai retrouve pourquoi j'etais reste avec l'idee que les destructeurs
etaient virtuel.
C'est dans l'exemple de la redefinition de l'operateur membre void
operator delete(void*, size_t) (TC++PL3 15.6 Free Store). Pour que le
size_t soit correct et reflete bien la taille du type de la classe
derivee meme si delete est applique sur un type de la classe de base
tandis que l'objet pointe est du type derive, il faut que le destructeur
de la classe de base soit virtuel.
J'ai fait un racourci en deduisant que le destructeur etait virtuel.
Alors que le virtual n'est en fait utilise ici que pour obtenir un
pointeur vers la vtbl et que les RTTI fonctionnent correctement pour
recuperer la taille du type derive. D'ou ma confusion.
Pendant l'execution du constructeur et du destructeur, l'objet est du type de la classe construite (et non de la classe la plus derivee).
Je savais pour les constructeurs (ce qui me fait penser que j'ai dit une betise dans l'autre post, le virtual de construct et destruct est inutile), mais je ne savais pas pour les destructeurs... Autant le premier me parait logique autant j'ai du mal a comprendre la raison du second.
Exactement les raisons symetriques. Par exemple lors de l'execution du constructeur, les membres des classes descendantes n'ont pas encore ete construit, pendant l'execution du destructeur ils ont deja ete detruits.
J'ai retrouve pourquoi j'etais reste avec l'idee que les destructeurs etaient virtuel.
C'est dans l'exemple de la redefinition de l'operateur membre void operator delete(void*, size_t) (TC++PL3 15.6 Free Store). Pour que le size_t soit correct et reflete bien la taille du type de la classe derivee meme si delete est applique sur un type de la classe de base tandis que l'objet pointe est du type derive, il faut que le destructeur de la classe de base soit virtuel.
J'ai fait un racourci en deduisant que le destructeur etait virtuel. Alors que le virtual n'est en fait utilise ici que pour obtenir un pointeur vers la vtbl et que les RTTI fonctionnent correctement pour recuperer la taille du type derive. D'ou ma confusion.
a+, ld.
Laurent Deniau
Christophe Lephay wrote:
Laurent Deniau wrote:
Jean-Marc Bourguet wrote:
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas compris grand chose au C++ et ont mal digere un bouquin ou des conseils - l'OP a mal compris les demandes.
pas mieux.
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni moins des pointeurs intelligents (je le dis dans un autre post qui semble bizarrement avoir été supprimé).
Ta reponse a James n'a pas ete supprime sur mon serveur.
a+, ld.
Christophe Lephay wrote:
Laurent Deniau wrote:
Jean-Marc Bourguet wrote:
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas
compris grand chose au C++ et ont mal digere un bouquin ou des
conseils - l'OP a mal compris les demandes.
pas mieux.
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni moins
des pointeurs intelligents (je le dis dans un autre post qui semble
bizarrement avoir été supprimé).
Ta reponse a James n'a pas ete supprime sur mon serveur.
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas compris grand chose au C++ et ont mal digere un bouquin ou des conseils - l'OP a mal compris les demandes.
pas mieux.
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni moins des pointeurs intelligents (je le dis dans un autre post qui semble bizarrement avoir été supprimé).
Ta reponse a James n'a pas ete supprime sur mon serveur.
a+, ld.
Christophe Lephay
Laurent Deniau wrote:
Jean-Marc Bourguet wrote:
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas compris grand chose au C++ et ont mal digere un bouquin ou des conseils - l'OP a mal compris les demandes.
pas mieux.
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni moins des pointeurs intelligents (je le dis dans un autre post qui semble bizarrement avoir été supprimé).
Chris
Laurent Deniau wrote:
Jean-Marc Bourguet wrote:
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas
compris grand chose au C++ et ont mal digere un bouquin ou des
conseils - l'OP a mal compris les demandes.
pas mieux.
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni moins
des pointeurs intelligents (je le dis dans un autre post qui semble
bizarrement avoir été supprimé).
Ma boule de cristal est en panne. Deux possibilites: - ils n'ont pas compris grand chose au C++ et ont mal digere un bouquin ou des conseils - l'OP a mal compris les demandes.
pas mieux.
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni moins des pointeurs intelligents (je le dis dans un autre post qui semble bizarrement avoir été supprimé).
Chris
Christophe Lephay
Christophe Lephay wrote:
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni moins des pointeurs intelligents
Précision...pas dans le sens que l'operateur de déréférencement est redéfini mais que les allocations/désallocations sont complètement transparentes.
Chris
Christophe Lephay wrote:
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni
moins des pointeurs intelligents
Précision...pas dans le sens que l'operateur de déréférencement est redéfini
mais que les allocations/désallocations sont complètement transparentes.
Ma boule de crital me dit que ce que veut le client, c'est ni plus ni moins des pointeurs intelligents
Précision...pas dans le sens que l'operateur de déréférencement est redéfini mais que les allocations/désallocations sont complètement transparentes.
Chris
drkm
Laurent Deniau writes:
drkm wrote:
Mais il ne s'agit pas de vtable. Il s'agit d'objets.
Ce que tu explique, je le savais (heureusement).
Je l'esprère ;-). Je n'ai d'ailleurs pas la prétention de t'en apprendre sur le modèle objet du C++ ;-). Je profitais de cette réponse pour clarifier ce dont on avait parlé de manière un peu confuse, et lever d'éventuelles confusions que la discussion avait pu semer.
--drkm
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
drkm wrote:
Mais il ne s'agit pas de vtable. Il s'agit d'objets.
Ce que tu explique, je le savais (heureusement).
Je l'esprère ;-). Je n'ai d'ailleurs pas la prétention de t'en
apprendre sur le modèle objet du C++ ;-). Je profitais de cette
réponse pour clarifier ce dont on avait parlé de manière un peu
confuse, et lever d'éventuelles confusions que la discussion avait pu
semer.
Mais il ne s'agit pas de vtable. Il s'agit d'objets.
Ce que tu explique, je le savais (heureusement).
Je l'esprère ;-). Je n'ai d'ailleurs pas la prétention de t'en apprendre sur le modèle objet du C++ ;-). Je profitais de cette réponse pour clarifier ce dont on avait parlé de manière un peu confuse, et lever d'éventuelles confusions que la discussion avait pu semer.
--drkm
drkm
Laurent Deniau writes:
C'est dans l'exemple de la redefinition de l'operateur membre void operator delete(void*, size_t) (TC++PL3 15.6 Free Store). Pour que le size_t soit correct et reflete bien la taille du type de la classe derivee meme si delete est applique sur un type de la classe de base tandis que l'objet pointe est du type derive, il faut que le destructeur de la classe de base soit virtuel.
Au fait, y a-t-il des cas où une classe possédant des membres virtuels peut légitimement ne pas déclarer son destructeur virtuel ? En d'autres termes, y a-t-il des raisons s'opposant à la virtualité automatique du destructeur dès qu'une classe possède un membre virtuel ?
--drkm
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
C'est dans l'exemple de la redefinition de l'operateur membre void
operator delete(void*, size_t) (TC++PL3 15.6 Free Store). Pour que le
size_t soit correct et reflete bien la taille du type de la classe
derivee meme si delete est applique sur un type de la classe de base
tandis que l'objet pointe est du type derive, il faut que le destructeur
de la classe de base soit virtuel.
Au fait, y a-t-il des cas où une classe possédant des membres
virtuels peut légitimement ne pas déclarer son destructeur virtuel ?
En d'autres termes, y a-t-il des raisons s'opposant à la virtualité
automatique du destructeur dès qu'une classe possède un membre
virtuel ?
C'est dans l'exemple de la redefinition de l'operateur membre void operator delete(void*, size_t) (TC++PL3 15.6 Free Store). Pour que le size_t soit correct et reflete bien la taille du type de la classe derivee meme si delete est applique sur un type de la classe de base tandis que l'objet pointe est du type derive, il faut que le destructeur de la classe de base soit virtuel.
Au fait, y a-t-il des cas où une classe possédant des membres virtuels peut légitimement ne pas déclarer son destructeur virtuel ? En d'autres termes, y a-t-il des raisons s'opposant à la virtualité automatique du destructeur dès qu'une classe possède un membre virtuel ?
--drkm
Jean-Marc Bourguet
drkm writes:
Au fait, y a-t-il des cas où une classe possédant des membres virtuels peut légitimement ne pas déclarer son destructeur virtuel ?
Oui. Si elle n'est jamais détruite que dans des situations où on connait son type. Le destructeur est généralement privé dans ces cas là.
En d'autres termes, y a-t-il des raisons s'opposant à la virtualité automatique du destructeur dès qu'une classe possède un membre virtuel ?
Les deux formulations me semblent dire des choses différentes. À part pour des raisons de performances, je ne vois pas de bonnes raisons pour ne pas le faire systématiquement.
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
drkm <usenet.fclcxx@fgeorges.org> writes:
Au fait, y a-t-il des cas où une classe possédant des
membres virtuels peut légitimement ne pas déclarer son
destructeur virtuel ?
Oui. Si elle n'est jamais détruite que dans des situations
où on connait son type. Le destructeur est généralement
privé dans ces cas là.
En d'autres termes, y a-t-il des raisons s'opposant à la
virtualité automatique du destructeur dès qu'une classe
possède un membre virtuel ?
Les deux formulations me semblent dire des choses
différentes. À part pour des raisons de performances, je ne
vois pas de bonnes raisons pour ne pas le faire
systématiquement.
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
Au fait, y a-t-il des cas où une classe possédant des membres virtuels peut légitimement ne pas déclarer son destructeur virtuel ?
Oui. Si elle n'est jamais détruite que dans des situations où on connait son type. Le destructeur est généralement privé dans ces cas là.
En d'autres termes, y a-t-il des raisons s'opposant à la virtualité automatique du destructeur dès qu'une classe possède un membre virtuel ?
Les deux formulations me semblent dire des choses différentes. À part pour des raisons de performances, je ne vois pas de bonnes raisons pour ne pas le faire systématiquement.
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
drkm
Jean-Marc Bourguet writes:
drkm writes:
Au fait, y a-t-il des cas où une classe possédant des membres virtuels peut légitimement ne pas déclarer son destructeur virtuel ?
Oui. Si elle n'est jamais détruite que dans des situations où on connait son type. Le destructeur est généralement privé dans ces cas là.
En d'autres termes, y a-t-il des raisons s'opposant à la virtualité automatique du destructeur dès qu'une classe possède un membre virtuel ?
Les deux formulations me semblent dire des choses différentes. À part pour des raisons de performances, je ne vois pas de bonnes raisons pour ne pas le faire systématiquement.
En fait, je pensais au fait de normaliser le fait que lorsqu'une classe définit une fonction membre virtuelle, le compilo déclare automatiquement virtuel le destructeur. Cela me semblerait intéressant. Ne serait-ce que pour le destructeur généré par défaut.
Comme il me semble que c'est presqu'obligatoire, sauf cas très particuliers, je trouve que ce devrait être le comportement par défaut. Cette proposition a-t-elle déjà été faite ? Et si oui, quels arguments ont-ils joué contre ?
--drkm
Jean-Marc Bourguet <jm@bourguet.org> writes:
drkm <usenet.fclcxx@fgeorges.org> writes:
Au fait, y a-t-il des cas où une classe possédant des
membres virtuels peut légitimement ne pas déclarer son
destructeur virtuel ?
Oui. Si elle n'est jamais détruite que dans des situations
où on connait son type. Le destructeur est généralement
privé dans ces cas là.
En d'autres termes, y a-t-il des raisons s'opposant à la
virtualité automatique du destructeur dès qu'une classe
possède un membre virtuel ?
Les deux formulations me semblent dire des choses
différentes. À part pour des raisons de performances, je ne
vois pas de bonnes raisons pour ne pas le faire
systématiquement.
En fait, je pensais au fait de normaliser le fait que lorsqu'une
classe définit une fonction membre virtuelle, le compilo déclare
automatiquement virtuel le destructeur. Cela me semblerait
intéressant. Ne serait-ce que pour le destructeur généré par défaut.
Comme il me semble que c'est presqu'obligatoire, sauf cas très
particuliers, je trouve que ce devrait être le comportement par
défaut. Cette proposition a-t-elle déjà été faite ? Et si oui, quels
arguments ont-ils joué contre ?
Au fait, y a-t-il des cas où une classe possédant des membres virtuels peut légitimement ne pas déclarer son destructeur virtuel ?
Oui. Si elle n'est jamais détruite que dans des situations où on connait son type. Le destructeur est généralement privé dans ces cas là.
En d'autres termes, y a-t-il des raisons s'opposant à la virtualité automatique du destructeur dès qu'une classe possède un membre virtuel ?
Les deux formulations me semblent dire des choses différentes. À part pour des raisons de performances, je ne vois pas de bonnes raisons pour ne pas le faire systématiquement.
En fait, je pensais au fait de normaliser le fait que lorsqu'une classe définit une fonction membre virtuelle, le compilo déclare automatiquement virtuel le destructeur. Cela me semblerait intéressant. Ne serait-ce que pour le destructeur généré par défaut.
Comme il me semble que c'est presqu'obligatoire, sauf cas très particuliers, je trouve que ce devrait être le comportement par défaut. Cette proposition a-t-elle déjà été faite ? Et si oui, quels arguments ont-ils joué contre ?
