Quels sont les différents cas dans lequel le c'est le constructeur de copie de la classe qui est appelé ?
J'ai une question que je peux éventuellement placer dans cette discussion :) Si je passe un objet par valeur à une fonction, est-ce que la copie locale temporaire sur laquelle va travailler ma fonction va être créée avec le constructeur de copie de l'objet en question ?
O.
-- Pas de promo perso à la con dans ma signature... avouez que ça fait du bien dans ce monde de pubs...
"Nicolas Aunai" avait écrit le 11/10/2003 :
Quels sont les différents cas dans lequel le c'est le constructeur
de copie de la classe qui est appelé ?
J'ai une question que je peux éventuellement placer dans cette
discussion :) Si je passe un objet par valeur à une fonction, est-ce
que la copie locale temporaire sur laquelle va travailler ma fonction
va être créée avec le constructeur de copie de l'objet en question ?
O.
--
Pas de promo perso à la con dans ma signature... avouez que ça fait du
bien dans ce monde de pubs...
Quels sont les différents cas dans lequel le c'est le constructeur de copie de la classe qui est appelé ?
J'ai une question que je peux éventuellement placer dans cette discussion :) Si je passe un objet par valeur à une fonction, est-ce que la copie locale temporaire sur laquelle va travailler ma fonction va être créée avec le constructeur de copie de l'objet en question ?
O.
-- Pas de promo perso à la con dans ma signature... avouez que ça fait du bien dans ce monde de pubs...
Michel Michaud
Dans news:,
J'ai une question que je peux éventuellement placer dans cette discussion :) Si je passe un objet par valeur à une fonction, est-ce que la copie locale temporaire sur laquelle va travailler ma fonction va être créée avec le constructeur de copie de l'objet en question ?
Oui. (en fait le c de c de la classe de l'objet)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:mesnews.69ba7d3a.9a1a4611.18.2397@hotmail.com,
J'ai une question que je peux éventuellement placer dans cette
discussion :) Si je passe un objet par valeur à une fonction, est-ce
que la copie locale temporaire sur laquelle va travailler ma
fonction va être créée avec le constructeur de copie de l'objet en
question ?
Oui. (en fait le c de c de la classe de l'objet)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
J'ai une question que je peux éventuellement placer dans cette discussion :) Si je passe un objet par valeur à une fonction, est-ce que la copie locale temporaire sur laquelle va travailler ma fonction va être créée avec le constructeur de copie de l'objet en question ?
Oui. (en fait le c de c de la classe de l'objet)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
"Alexandre" wrote in message news:<3f89a5f5$0$2802$...
Objet& operator = (Objet& o) { this->~Objet(); this->Objet(o); ????? return *this; } C'est légal, ça ?
Non. L'idiome (ou anti-idiome, si on préfère), c'est :
Objet& Objet::operator=( Objet const& other ) { if ( this != &other ) { this->~Objet() ; new ( this ) Objet( other ) ; } return *this ; }
C'est tout à fait légal, mais ne va pas sans poser un certain nombre de problèmes.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Alexandre" <alex.g@netcourrier.com> wrote in message
news:<3f89a5f5$0$2802$626a54ce@news.free.fr>...
Objet& operator = (Objet& o)
{
this->~Objet();
this->Objet(o); ?????
return *this;
}
C'est légal, ça ?
Non. L'idiome (ou anti-idiome, si on préfère), c'est :
Objet&
Objet::operator=( Objet const& other )
{
if ( this != &other ) {
this->~Objet() ;
new ( this ) Objet( other ) ;
}
return *this ;
}
C'est tout à fait légal, mais ne va pas sans poser un certain nombre de
problèmes.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Alexandre" wrote in message news:<3f89a5f5$0$2802$...
Objet& operator = (Objet& o) { this->~Objet(); this->Objet(o); ????? return *this; } C'est légal, ça ?
Non. L'idiome (ou anti-idiome, si on préfère), c'est :
Objet& Objet::operator=( Objet const& other ) { if ( this != &other ) { this->~Objet() ; new ( this ) Objet( other ) ; } return *this ; }
C'est tout à fait légal, mais ne va pas sans poser un certain nombre de problèmes.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gourgouilloult
wrote:
Non. L'idiome (ou anti-idiome, si on préfère), c'est :
Objet& Objet::operator=( Objet const& other ) { if ( this != &other ) { this->~Objet() ; new ( this ) Objet( other ) ; } return *this ; }
C'est tout à fait légal, mais ne va pas sans poser un certain nombre de problèmes.
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en vogue ? Je crois que la discussion avait déjà eu lieu il y a quelques mois, mais je ne me souviens plus des arguments (ni de la solution... oui, traitez moi de boulet si vous voulez ;-{ )
Par contre, l'auto-appel au destructeur avec passage par un placement new, c'est pour simplifier, ou c'est sérieux ? Ca ne risque pas d'avoir plus d'implications que ça, en particulier si on commence à toucher aux op new() quelque chose ? Je ne suis pas fortiche en la matière, mais j'ai une légère idée de pourquoi (ie de pourquoi je ne suis pas fort)...
Gourgouilloult du Clapotis Désolé si je raconte des bêtises...
kanze@gabi-soft.fr wrote:
Non. L'idiome (ou anti-idiome, si on préfère), c'est :
Objet&
Objet::operator=( Objet const& other )
{
if ( this != &other ) {
this->~Objet() ;
new ( this ) Objet( other ) ;
}
return *this ;
}
C'est tout à fait légal, mais ne va pas sans poser un certain nombre de
problèmes.
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en
vogue ? Je crois que la discussion avait déjà eu lieu il y a quelques
mois, mais je ne me souviens plus des arguments (ni de la solution...
oui, traitez moi de boulet si vous voulez ;-{ )
Par contre, l'auto-appel au destructeur avec passage par un placement
new, c'est pour simplifier, ou c'est sérieux ? Ca ne risque pas d'avoir
plus d'implications que ça, en particulier si on commence à toucher aux
op new() quelque chose ? Je ne suis pas fortiche en la matière, mais
j'ai une légère idée de pourquoi (ie de pourquoi je ne suis pas fort)...
Gourgouilloult du Clapotis
Désolé si je raconte des bêtises...
Non. L'idiome (ou anti-idiome, si on préfère), c'est :
Objet& Objet::operator=( Objet const& other ) { if ( this != &other ) { this->~Objet() ; new ( this ) Objet( other ) ; } return *this ; }
C'est tout à fait légal, mais ne va pas sans poser un certain nombre de problèmes.
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en vogue ? Je crois que la discussion avait déjà eu lieu il y a quelques mois, mais je ne me souviens plus des arguments (ni de la solution... oui, traitez moi de boulet si vous voulez ;-{ )
Par contre, l'auto-appel au destructeur avec passage par un placement new, c'est pour simplifier, ou c'est sérieux ? Ca ne risque pas d'avoir plus d'implications que ça, en particulier si on commence à toucher aux op new() quelque chose ? Je ne suis pas fortiche en la matière, mais j'ai une légère idée de pourquoi (ie de pourquoi je ne suis pas fort)...
Gourgouilloult du Clapotis Désolé si je raconte des bêtises...
Fabien LE LEZ
On Tue, 14 Oct 2003 21:10:10 +0200, Gourgouilloult <gourgou_at_club-internet_point_fr> wrote:
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en vogue ?
Disons qu'un operator= bien fait n'a pas besoin de ce "if (this ! &other)", sauf pour des questions d'optimisation. Mais bon, c'est un détail par rapport au reste.
Par contre, l'auto-appel au destructeur avec passage par un placement new, c'est pour simplifier, ou c'est sérieux ?
Non, non, c'est sérieux. C'est d'ailleurs AMHA la principale raison pour appeler ça un "anti-idiome". J'ai l'impression que cette façon de faire date du temps où les exceptions n'existaient pas. Je te laisse imaginer le résultat si le constructeur (appelé via le "placement new") lance une exception...
On Tue, 14 Oct 2003 21:10:10 +0200, Gourgouilloult
<gourgou_at_club-internet_point_fr> wrote:
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en
vogue ?
Disons qu'un operator= bien fait n'a pas besoin de ce "if (this ! &other)", sauf pour des questions d'optimisation.
Mais bon, c'est un détail par rapport au reste.
Par contre, l'auto-appel au destructeur avec passage par un placement
new, c'est pour simplifier, ou c'est sérieux ?
Non, non, c'est sérieux. C'est d'ailleurs AMHA la principale raison
pour appeler ça un "anti-idiome". J'ai l'impression que cette façon de
faire date du temps où les exceptions n'existaient pas. Je te laisse
imaginer le résultat si le constructeur (appelé via le "placement
new") lance une exception...
On Tue, 14 Oct 2003 21:10:10 +0200, Gourgouilloult <gourgou_at_club-internet_point_fr> wrote:
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en vogue ?
Disons qu'un operator= bien fait n'a pas besoin de ce "if (this ! &other)", sauf pour des questions d'optimisation. Mais bon, c'est un détail par rapport au reste.
Par contre, l'auto-appel au destructeur avec passage par un placement new, c'est pour simplifier, ou c'est sérieux ?
Non, non, c'est sérieux. C'est d'ailleurs AMHA la principale raison pour appeler ça un "anti-idiome". J'ai l'impression que cette façon de faire date du temps où les exceptions n'existaient pas. Je te laisse imaginer le résultat si le constructeur (appelé via le "placement new") lance une exception...
On Tue, 14 Oct 2003 21:10:10 +0200, Gourgouilloult <gourgou_at_club-internet_point_fr> wrote:
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en vogue ?
Non. Mais en général, c'est une mauvaise signe en face des exceptions.
Disons qu'un operator= bien fait n'a pas besoin de ce "if (this ! > &other)", sauf pour des questions d'optimisation. Mais bon, c'est un détail par rapport au reste.
Par contre, l'auto-appel au destructeur avec passage par un placement new, c'est pour simplifier, ou c'est sérieux ?
Non, non, c'est sérieux. C'est d'ailleurs AMHA la principale raison pour appeler ça un "anti-idiome". J'ai l'impression que cette façon de faire date du temps où les exceptions n'existaient pas. Je te laisse imaginer le résultat si le constructeur (appelé via le "placement new") lance une exception...
Il date surtout d'une époque où on explorait même les idiomes de base de C++. Les exceptions en sont certes un problème, et de taille. Mais aussi, imagine ce qui se passe si on dérive de la classe, et que la classe dérivée utilise une forme plus classique de l'opérateur d'affectation, en appelant l'opérateur d'affectation de la classe de base.
Moi-même, j'avais conçu l'idiome pour traiter les cas de l'héritage virtuel -- où c'est à charge du programmeur d'éviter que la classe de base se trouve affectée plusiurs fois. Il n'y a malheureusement pas de bonnes solutions à ce problème. Mais c'est précisement dans le cas de l'héritage que l'idiome se trouve le plus fragile, et qu'il faut absolument l'éviter. Et depuis, je me suis rendu compte que l'affectation et la polymorphisme se marient mal de toute façon, et qu'il faut chercher d'autres solutions.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<d4joov02hf4he1dgtcjb6dljbrlcomfadc@4ax.com>...
On Tue, 14 Oct 2003 21:10:10 +0200, Gourgouilloult
<gourgou_at_club-internet_point_fr> wrote:
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en
vogue ?
Non. Mais en général, c'est une mauvaise signe en face des exceptions.
Disons qu'un operator= bien fait n'a pas besoin de ce "if (this ! > &other)", sauf pour des questions d'optimisation. Mais bon, c'est un
détail par rapport au reste.
Par contre, l'auto-appel au destructeur avec passage par un placement
new, c'est pour simplifier, ou c'est sérieux ?
Non, non, c'est sérieux. C'est d'ailleurs AMHA la principale raison
pour appeler ça un "anti-idiome". J'ai l'impression que cette façon de
faire date du temps où les exceptions n'existaient pas. Je te laisse
imaginer le résultat si le constructeur (appelé via le "placement
new") lance une exception...
Il date surtout d'une époque où on explorait même les idiomes de base de
C++. Les exceptions en sont certes un problème, et de taille. Mais
aussi, imagine ce qui se passe si on dérive de la classe, et que la
classe dérivée utilise une forme plus classique de l'opérateur
d'affectation, en appelant l'opérateur d'affectation de la classe de
base.
Moi-même, j'avais conçu l'idiome pour traiter les cas de l'héritage
virtuel -- où c'est à charge du programmeur d'éviter que la classe de
base se trouve affectée plusiurs fois. Il n'y a malheureusement pas de
bonnes solutions à ce problème. Mais c'est précisement dans le cas de
l'héritage que l'idiome se trouve le plus fragile, et qu'il faut
absolument l'éviter. Et depuis, je me suis rendu compte que
l'affectation et la polymorphisme se marient mal de toute façon, et
qu'il faut chercher d'autres solutions.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
On Tue, 14 Oct 2003 21:10:10 +0200, Gourgouilloult <gourgou_at_club-internet_point_fr> wrote:
Tu dis anti-idiome parce que le « if (this != &other) » n'est plus en vogue ?
Non. Mais en général, c'est une mauvaise signe en face des exceptions.
Disons qu'un operator= bien fait n'a pas besoin de ce "if (this ! > &other)", sauf pour des questions d'optimisation. Mais bon, c'est un détail par rapport au reste.
Par contre, l'auto-appel au destructeur avec passage par un placement new, c'est pour simplifier, ou c'est sérieux ?
Non, non, c'est sérieux. C'est d'ailleurs AMHA la principale raison pour appeler ça un "anti-idiome". J'ai l'impression que cette façon de faire date du temps où les exceptions n'existaient pas. Je te laisse imaginer le résultat si le constructeur (appelé via le "placement new") lance une exception...
Il date surtout d'une époque où on explorait même les idiomes de base de C++. Les exceptions en sont certes un problème, et de taille. Mais aussi, imagine ce qui se passe si on dérive de la classe, et que la classe dérivée utilise une forme plus classique de l'opérateur d'affectation, en appelant l'opérateur d'affectation de la classe de base.
Moi-même, j'avais conçu l'idiome pour traiter les cas de l'héritage virtuel -- où c'est à charge du programmeur d'éviter que la classe de base se trouve affectée plusiurs fois. Il n'y a malheureusement pas de bonnes solutions à ce problème. Mais c'est précisement dans le cas de l'héritage que l'idiome se trouve le plus fragile, et qu'il faut absolument l'éviter. Et depuis, je me suis rendu compte que l'affectation et la polymorphisme se marient mal de toute façon, et qu'il faut chercher d'autres solutions.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
