Bonjour a tous,
ça fait 5 jours que j'ai posté ce message et je ne le vois pas sur le
forum problement un problème!
J'ai trouvé le code suivant pour l'orérateur =:
const Maclass& Maclass::operator=(const Maclass&right)
{
if (&right!=this)
{
this->Maclass::~CCSOUtilSurfaceECGBuffer();
::new(this) Maclass(right);
}
return *this;
}
question :
::new(this) Maclass(right); : je ne comprends pas le sens de cette
ligne et si c'est bien de faire comme sa?
moi j'aurai suggéré de faire une fonction commune qui sera appelée par
le constructeur de copie et l'opérateur = "pour la lisibilité"
Les intérets : * pimp peut varier de manière dynamique (pour peu que fonction soit virtuelle, notemment) * en cas de modification de la classe imp, seule celle-ci doit être recompilée * l'implémentation n'est pas seulement encapsulée (comme ce serait le cas avec juste des données private), elle est masquée dans la classe imp (il suffit d'en fournir le fichier objet). C'est ce point, je pense, qui justifie l'appelation "compiler firewall", peut-être aussi le point précédent.
J'ai oublié les inconvénients : * il faut recréer l'interface de imp dans la classe proxy (quitte à la changer, mais on change alors de Design Pattern(*)), ce qui est un peu lourd et répétitif. * un niveau d'indirection est rajouté, ce qui peut avoir un impact sur les performances (même si cet impact sera insignifiant dans la plupart des cas)
(*) DPs Pont ou Façade, notemment...
Au passage, cet idiôme permet aussi d'offir une sémantique de valeur, via proxy, à une hiérarchie polymorphe (avec imp comme classe de base). Je crois que James l'utilise souvent pour celà, même si je trouve l'idiôme enveloppe-lettre plus élégant (mais qui ne permet pas d'offir une telle sémantique *à postériori*, contrairement à une classe proxy comme ci-dessus).
Les intérets :
* pimp peut varier de manière dynamique (pour peu que fonction soit
virtuelle, notemment)
* en cas de modification de la classe imp, seule celle-ci doit être
recompilée
* l'implémentation n'est pas seulement encapsulée (comme ce serait le
cas avec juste des données private), elle est masquée dans la classe
imp (il suffit d'en fournir le fichier objet). C'est ce point, je
pense, qui justifie l'appelation "compiler firewall", peut-être aussi
le point précédent.
J'ai oublié les inconvénients :
* il faut recréer l'interface de imp dans la classe proxy (quitte à la
changer, mais on change alors de Design Pattern(*)), ce qui est un peu lourd
et répétitif.
* un niveau d'indirection est rajouté, ce qui peut avoir un impact sur les
performances (même si cet impact sera insignifiant dans la plupart des cas)
(*) DPs Pont ou Façade, notemment...
Au passage, cet idiôme permet aussi d'offir une sémantique de valeur, via
proxy, à une hiérarchie polymorphe (avec imp comme classe de base). Je crois
que James l'utilise souvent pour celà, même si je trouve l'idiôme
enveloppe-lettre plus élégant (mais qui ne permet pas d'offir une telle
sémantique *à postériori*, contrairement à une classe proxy comme
ci-dessus).
Les intérets : * pimp peut varier de manière dynamique (pour peu que fonction soit virtuelle, notemment) * en cas de modification de la classe imp, seule celle-ci doit être recompilée * l'implémentation n'est pas seulement encapsulée (comme ce serait le cas avec juste des données private), elle est masquée dans la classe imp (il suffit d'en fournir le fichier objet). C'est ce point, je pense, qui justifie l'appelation "compiler firewall", peut-être aussi le point précédent.
J'ai oublié les inconvénients : * il faut recréer l'interface de imp dans la classe proxy (quitte à la changer, mais on change alors de Design Pattern(*)), ce qui est un peu lourd et répétitif. * un niveau d'indirection est rajouté, ce qui peut avoir un impact sur les performances (même si cet impact sera insignifiant dans la plupart des cas)
(*) DPs Pont ou Façade, notemment...
Au passage, cet idiôme permet aussi d'offir une sémantique de valeur, via proxy, à une hiérarchie polymorphe (avec imp comme classe de base). Je crois que James l'utilise souvent pour celà, même si je trouve l'idiôme enveloppe-lettre plus élégant (mais qui ne permet pas d'offir une telle sémantique *à postériori*, contrairement à une classe proxy comme ci-dessus).
Je crois que "compiler firewall" est synonyme de classe proxy, de pimple ou pimp ("pointeur sur implémentation") et de cheschire cat...
Pas tout a fait. proxy c'est un DP, ou un objet agit a la place d'un autre. Le pare-feu de compilation est plus un idiome qui utilise un proxy pour eviter la recompilation quand l'implementation change.
Oui, j'ai failli dire quelque chose du même genre (des moyens identiques pour une finalité différente).
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Je crois que "compiler firewall" est synonyme de classe proxy, de
pimple ou pimp ("pointeur sur implémentation") et de cheschire cat...
Pas tout a fait. proxy c'est un DP, ou un objet agit a la place d'un
autre. Le pare-feu de compilation est plus un idiome qui utilise un
proxy pour eviter la recompilation quand l'implementation change.
Oui, j'ai failli dire quelque chose du même genre (des moyens identiques
pour une finalité différente).
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas
du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Je crois que "compiler firewall" est synonyme de classe proxy, de pimple ou pimp ("pointeur sur implémentation") et de cheschire cat...
Pas tout a fait. proxy c'est un DP, ou un objet agit a la place d'un autre. Le pare-feu de compilation est plus un idiome qui utilise un proxy pour eviter la recompilation quand l'implementation change.
Oui, j'ai failli dire quelque chose du même genre (des moyens identiques pour une finalité différente).
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Chris
Christophe Lephay
Christophe Lephay wrote:
Jean-Marc Bourguet wrote:
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Je me réponds à moi-même : il faut recompiler si imp::fonction() change de nom ou de signature...
Chris
Christophe Lephay wrote:
Jean-Marc Bourguet wrote:
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est
pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Je me réponds à moi-même : il faut recompiler si imp::fonction() change de
nom ou de signature...
Le Tue, 28 Oct 2003 09:37:21 +0100, Benoit Dejean a écrit :
:oD
mince, le Chat du Cheshire, on ne voit que son sourire
D
Laurent DELEPINE
mourad wrote:
Benoit Dejean wrote in message news:...
est que la zone mémoire de this t'appartient ? si c'est quelque chose en pile, ça va saigner ?
c'est pas très beau tout ça. pour quoi ne pas faire une fonction clear() (également appelé dans le destructeur) ? d'autre par, tu peux aussi faire une fonction assign que tu appelles également dans ton constructeur par recopie. en tous cas ta version n'est pas très performante (ou désalloue pour réallouer)
personnellement, moi je définirais une fonction membre swap et operator >>se résume à un simple swap avec une copie.
est ce que tu peux s.t.p donner un exemple avec un petit code simple? c'est quoi une fonction swape et une fonction assign."juste une petite indication dans l'ésprit du sujet je sais qu'il ya de la doc sur sa" merci à tous.
Désolé, j'ai manqué de precision.
Une fonction "swap" est une fonction qui echange les valeurs des membres de deux instances de la meme classe.
En utilisant cet idiome, l'operateur d'affectation ressemble a ceci :
Benoit Dejean <bnet@ifrance.com> wrote in message news:<pan.2003.10.27.12.42.03.687864@ifrance.com>...
est que la zone mémoire de this t'appartient ? si c'est quelque chose en
pile, ça va saigner ?
c'est pas très beau tout ça. pour quoi ne pas faire une fonction clear()
(également appelé dans le destructeur) ? d'autre par, tu peux aussi
faire une fonction assign que tu appelles également dans ton constructeur
par recopie. en tous cas ta version n'est pas très performante (ou
désalloue pour réallouer)
personnellement, moi je définirais une fonction membre swap et operator >>se résume à un simple swap avec une copie.
est ce que tu peux s.t.p donner un exemple avec un petit code simple?
c'est quoi une fonction swape et une fonction assign."juste une petite
indication dans l'ésprit du sujet je sais qu'il ya de la doc sur sa"
merci à tous.
Désolé, j'ai manqué de precision.
Une fonction "swap" est une fonction qui echange les valeurs des membres
de deux instances de la meme classe.
En utilisant cet idiome, l'operateur d'affectation ressemble a ceci :
est que la zone mémoire de this t'appartient ? si c'est quelque chose en pile, ça va saigner ?
c'est pas très beau tout ça. pour quoi ne pas faire une fonction clear() (également appelé dans le destructeur) ? d'autre par, tu peux aussi faire une fonction assign que tu appelles également dans ton constructeur par recopie. en tous cas ta version n'est pas très performante (ou désalloue pour réallouer)
personnellement, moi je définirais une fonction membre swap et operator >>se résume à un simple swap avec une copie.
est ce que tu peux s.t.p donner un exemple avec un petit code simple? c'est quoi une fonction swape et une fonction assign."juste une petite indication dans l'ésprit du sujet je sais qu'il ya de la doc sur sa" merci à tous.
Désolé, j'ai manqué de precision.
Une fonction "swap" est une fonction qui echange les valeurs des membres de deux instances de la meme classe.
En utilisant cet idiome, l'operateur d'affectation ressemble a ceci :
Les intérets : * pimp peut varier de manière dynamique (pour peu que fonction soit virtuelle, notemment) * en cas de modification de la classe imp, seule celle-ci doit être recompilée * l'implémentation n'est pas seulement encapsulée (comme ce serait le cas avec juste des données private), elle est masquée dans la classe imp (il suffit d'en fournir le fichier objet). C'est ce point, je pense, qui justifie l'appelation "compiler firewall", peut-être aussi le point précédent.
J'ajoute un intérêt :
* pimp est un nom de variable qui fait sourire intérieurement les anglophones et les fidèles de Franck Zappa.
Christophe Lephay a écrit.
Les intérets :
* pimp peut varier de manière dynamique (pour peu que fonction soit
virtuelle, notemment)
* en cas de modification de la classe imp, seule celle-ci doit être
recompilée
* l'implémentation n'est pas seulement encapsulée (comme ce serait le cas
avec juste des données private), elle est masquée dans la classe imp (il
suffit d'en fournir le fichier objet). C'est ce point, je pense, qui
justifie l'appelation "compiler firewall", peut-être aussi le point
précédent.
J'ajoute un intérêt :
* pimp est un nom de variable qui fait sourire intérieurement les
anglophones et les fidèles de Franck Zappa.
Les intérets : * pimp peut varier de manière dynamique (pour peu que fonction soit virtuelle, notemment) * en cas de modification de la classe imp, seule celle-ci doit être recompilée * l'implémentation n'est pas seulement encapsulée (comme ce serait le cas avec juste des données private), elle est masquée dans la classe imp (il suffit d'en fournir le fichier objet). C'est ce point, je pense, qui justifie l'appelation "compiler firewall", peut-être aussi le point précédent.
J'ajoute un intérêt :
* pimp est un nom de variable qui fait sourire intérieurement les anglophones et les fidèles de Franck Zappa.
Laurent DELEPINE
wrote:
(Mais dans ce cas-là, j'utilise prèsque toujours l'idiome du pare-feu de compilation, ce qui fait que la classe même ne contient qu'un seul pointeur, et l'idiome de swap marche.)
En quoi consiste cet idiome du pare-feu de compilation
A+
LD
kanze@gabi-soft.fr wrote:
(Mais
dans ce cas-là, j'utilise prèsque toujours l'idiome du pare-feu de
compilation, ce qui fait que la classe même ne contient qu'un seul
pointeur, et l'idiome de swap marche.)
En quoi consiste cet idiome du pare-feu de compilation
(Mais dans ce cas-là, j'utilise prèsque toujours l'idiome du pare-feu de compilation, ce qui fait que la classe même ne contient qu'un seul pointeur, et l'idiome de swap marche.)
En quoi consiste cet idiome du pare-feu de compilation
A+
LD
Christophe Lephay
Laurent DELEPINE wrote:
Je connaissais la technique mais j'ignorais son nom. C'est certainement le cas de la suivante aussi : c'est quoi l'idiome enveloppe-lettre.
classe enveloppe { // ou enveloppe * lettre; selon... lettre * la_lettre;
virtual void do_somehing() = 0;
public:
void something() { la_lettre->do_something(); }
enveloppe();
// l'objectif étant d'offrir une sémantique de valeur : enveloppe( const enveloppe& ); enveloppe& operator=( const enveloppe& ); virtual ~enveloppe(); };
classe lettre : public enveloppe { void do_something() { /* ... */ } ... };
On définit les comportements polymorphiques dans lettre et dérivées, mais on n'utilise que enveloppe dans le code utilisateur, qui offre une sémantique de valeur via le constructeur copie et l'opérateur d'affectation.
Celà permet de faire des vector< enveloppe >, par exemple, bien que l'appel something() soit résolu dynamiquement.
Chris
Laurent DELEPINE wrote:
Je connaissais la technique mais j'ignorais son nom. C'est
certainement le cas de la suivante aussi : c'est quoi l'idiome
enveloppe-lettre.
classe enveloppe
{
// ou enveloppe * lettre; selon...
lettre * la_lettre;
virtual void do_somehing() = 0;
public:
void something() { la_lettre->do_something(); }
enveloppe();
// l'objectif étant d'offrir une sémantique de valeur :
enveloppe( const enveloppe& );
enveloppe& operator=( const enveloppe& );
virtual ~enveloppe();
};
classe lettre : public enveloppe
{
void do_something() { /* ... */ }
...
};
On définit les comportements polymorphiques dans lettre et dérivées, mais on
n'utilise que enveloppe dans le code utilisateur, qui offre une sémantique
de valeur via le constructeur copie et l'opérateur d'affectation.
Celà permet de faire des vector< enveloppe >, par exemple, bien que l'appel
something() soit résolu dynamiquement.
Je connaissais la technique mais j'ignorais son nom. C'est certainement le cas de la suivante aussi : c'est quoi l'idiome enveloppe-lettre.
classe enveloppe { // ou enveloppe * lettre; selon... lettre * la_lettre;
virtual void do_somehing() = 0;
public:
void something() { la_lettre->do_something(); }
enveloppe();
// l'objectif étant d'offrir une sémantique de valeur : enveloppe( const enveloppe& ); enveloppe& operator=( const enveloppe& ); virtual ~enveloppe(); };
classe lettre : public enveloppe { void do_something() { /* ... */ } ... };
On définit les comportements polymorphiques dans lettre et dérivées, mais on n'utilise que enveloppe dans le code utilisateur, qui offre une sémantique de valeur via le constructeur copie et l'opérateur d'affectation.
Celà permet de faire des vector< enveloppe >, par exemple, bien que l'appel something() soit résolu dynamiquement.
Je crois que "compiler firewall" est synonyme de classe proxy, de pimple ou pimp ("pointeur sur implémentation") et de cheschire cat...
Pas tout a fait. proxy c'est un DP, ou un objet agit a la place d'un autre. Le pare-feu de compilation est plus un idiome qui utilise un proxy pour eviter la recompilation quand l'implementation change.
Oui, j'ai failli dire quelque chose du même genre (des moyens identiques pour une finalité différente).
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Pour savoir que imp::fonction existe et est accessible, il faut voir la definition de la classe imp -- hors ce qu'on veut cacher, c'est justement les membres prives de cette classe.
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 crois que "compiler firewall" est synonyme de classe proxy, de
pimple ou pimp ("pointeur sur implémentation") et de cheschire cat...
Pas tout a fait. proxy c'est un DP, ou un objet agit a la place d'un
autre. Le pare-feu de compilation est plus un idiome qui utilise un
proxy pour eviter la recompilation quand l'implementation change.
Oui, j'ai failli dire quelque chose du même genre (des moyens identiques
pour une finalité différente).
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas
du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Pour savoir que imp::fonction existe et est accessible, il faut voir
la definition de la classe imp -- hors ce qu'on veut cacher, c'est
justement les membres prives de cette classe.
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 crois que "compiler firewall" est synonyme de classe proxy, de pimple ou pimp ("pointeur sur implémentation") et de cheschire cat...
Pas tout a fait. proxy c'est un DP, ou un objet agit a la place d'un autre. Le pare-feu de compilation est plus un idiome qui utilise un proxy pour eviter la recompilation quand l'implementation change.
Oui, j'ai failli dire quelque chose du même genre (des moyens identiques pour une finalité différente).
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Pour savoir que imp::fonction existe et est accessible, il faut voir la definition de la classe imp -- hors ce qu'on veut cacher, c'est justement les membres prives de cette classe.
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
Jean-Marc Bourguet
"Christophe Lephay" writes:
Christophe Lephay wrote:
Jean-Marc Bourguet wrote:
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Je me réponds à moi-même : il faut recompiler si imp::fonction() change de nom ou de signature...
A priori, dans ce cas il faut recompiler aussi car dans cet idiome au sens pur, les deux classes ont les memes membres publics. Apres naturellement il y a des variations sur le theme.
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
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est
pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Je me réponds à moi-même : il faut recompiler si imp::fonction() change de
nom ou de signature...
A priori, dans ce cas il faut recompiler aussi car dans cet idiome au
sens pur, les deux classes ont les memes membres publics. Apres
naturellement il y a des variations sur le theme.
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
Donc, mettre proxy::fonction en inline ci-dessus fait que ce n'est pas du tout un bon exemple.
Où est le problème, tant que imp::fonction n'est pas, elle, inline ?
Je me réponds à moi-même : il faut recompiler si imp::fonction() change de nom ou de signature...
A priori, dans ce cas il faut recompiler aussi car dans cet idiome au sens pur, les deux classes ont les memes membres publics. Apres naturellement il y a des variations sur le theme.
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
