Est-ce que je pourrais résumer en disant finalement que friend est une disposition de ''confort '', non pas incontournable mais bien utile ?
Non, car tout ce qui a été fait depuis l'assembleur peut être vu comme des dispositions de confort...
Pour être un peu plus clair, le fait de mettre quelque chose (fonction, classe) friend ou pas est une décision importante en terme de conception, qui peut avoir un impact majeur sur la façon dont les différentes hiérarchies coopèrent entre elles. C'est donc une erreur de le concevoir comme un compromis de confort du point de vue d'une certaine idéologie objet.
Chris
Christophe Lephay wrote:
Yalbrieux wrote:
Est-ce que je pourrais résumer en disant finalement que friend est
une disposition de ''confort '', non pas incontournable mais bien
utile ?
Non, car tout ce qui a été fait depuis l'assembleur peut être vu
comme des dispositions de confort...
Pour être un peu plus clair, le fait de mettre quelque chose (fonction,
classe) friend ou pas est une décision importante en terme de conception,
qui peut avoir un impact majeur sur la façon dont les différentes
hiérarchies coopèrent entre elles. C'est donc une erreur de le concevoir
comme un compromis de confort du point de vue d'une certaine idéologie
objet.
Est-ce que je pourrais résumer en disant finalement que friend est une disposition de ''confort '', non pas incontournable mais bien utile ?
Non, car tout ce qui a été fait depuis l'assembleur peut être vu comme des dispositions de confort...
Pour être un peu plus clair, le fait de mettre quelque chose (fonction, classe) friend ou pas est une décision importante en terme de conception, qui peut avoir un impact majeur sur la façon dont les différentes hiérarchies coopèrent entre elles. C'est donc une erreur de le concevoir comme un compromis de confort du point de vue d'une certaine idéologie objet.
Chris
Michel Michaud
Dans news:bn28fn$7gt$, Christophe
Des exemples de fonctions libres friend, notemment, tu en as dès qu'une classe doit pouvoir être utilisée avec les flux. Et dans ces cas précis, friend est incontournable si on veut en conserver une utilisation naturelle (au sens habituelle).
Vraiment ? Pourquoi tu n'aimes pas l'idiome classique qui permet en plus le polymorphisme :
class ClBase { ... // Publique : virtual void EcrireSur(ostream &); // = 0 le cas échéant... };
Il doit y avoir quelque chose qui m'échappe dans ton argument (encore une fois, tu as raison, et friend est nécessaire, si on ne veut pas ajouter la fonction membre publique à l'interface de la classe).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bn28fn$7gt$1@news-reader1.wanadoo.fr, Christophe
Des exemples de fonctions libres friend, notemment, tu en as dès
qu'une classe doit pouvoir être utilisée avec les flux. Et dans ces
cas précis, friend est incontournable si on veut en conserver une
utilisation naturelle (au sens habituelle).
Vraiment ? Pourquoi tu n'aimes pas l'idiome classique qui permet en
plus le polymorphisme :
class ClBase
{
...
// Publique :
virtual void EcrireSur(ostream &); // = 0 le cas échéant...
};
Il doit y avoir quelque chose qui m'échappe dans ton argument (encore
une fois, tu as raison, et friend est nécessaire, si on ne veut pas
ajouter la fonction membre publique à l'interface de la classe).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Des exemples de fonctions libres friend, notemment, tu en as dès qu'une classe doit pouvoir être utilisée avec les flux. Et dans ces cas précis, friend est incontournable si on veut en conserver une utilisation naturelle (au sens habituelle).
Vraiment ? Pourquoi tu n'aimes pas l'idiome classique qui permet en plus le polymorphisme :
class ClBase { ... // Publique : virtual void EcrireSur(ostream &); // = 0 le cas échéant... };
Il doit y avoir quelque chose qui m'échappe dans ton argument (encore une fois, tu as raison, et friend est nécessaire, si on ne veut pas ajouter la fonction membre publique à l'interface de la classe).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Jean-Marc Bourguet
"Yalbrieux" writes:
Est-ce que je pourrais résumer en disant finalement que friend est une disposition de ''confort '', non pas incontournable mais bien utile ?
Rien n'est incontournable. L'interet de pas mal de structures syntaxiques est qu'elles permettent d'exprimer l'intention en meme temps que l'effet. Entre rendre tout les membres publics et declarer une fonction friend, l'effet va etre le meme, l'intention est beaucoup plus clair dans le second cas.
-- 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
"Yalbrieux" <yalbrieux@wanadoo.fr> writes:
Est-ce que je pourrais résumer en disant finalement que friend est une
disposition de ''confort '', non pas incontournable mais bien utile ?
Rien n'est incontournable. L'interet de pas mal de structures
syntaxiques est qu'elles permettent d'exprimer l'intention en meme
temps que l'effet. Entre rendre tout les membres publics et declarer
une fonction friend, l'effet va etre le meme, l'intention est beaucoup
plus clair dans le second cas.
--
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
Est-ce que je pourrais résumer en disant finalement que friend est une disposition de ''confort '', non pas incontournable mais bien utile ?
Rien n'est incontournable. L'interet de pas mal de structures syntaxiques est qu'elles permettent d'exprimer l'intention en meme temps que l'effet. Entre rendre tout les membres publics et declarer une fonction friend, l'effet va etre le meme, l'intention est beaucoup plus clair dans le second cas.
-- 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
Christophe Lephay
Michel Michaud wrote:
Dans news:bn28fn$7gt$, Christophe
Des exemples de fonctions libres friend, notemment, tu en as dès qu'une classe doit pouvoir être utilisée avec les flux. Et dans ces cas précis, friend est incontournable si on veut en conserver une utilisation naturelle (au sens habituelle).
Vraiment ? Pourquoi tu n'aimes pas l'idiome classique qui permet en plus le polymorphisme :
Mais si, je l'aime cet idiôme...
Il doit y avoir quelque chose qui m'échappe dans ton argument (encore une fois, tu as raison, et friend est nécessaire, si on ne veut pas ajouter la fonction membre publique à l'interface de la classe).
J'avais en tête de la mettre protected, c'est pour celà que je parlais d'utilisation habituelle : dans le sens où EcrireSur( os ); n'est pas une "utilisation habituelle" des flux. Mais c'est vrai que la mettre public permet tout autant os << objet;
Chris
Michel Michaud wrote:
Dans news:bn28fn$7gt$1@news-reader1.wanadoo.fr, Christophe
Des exemples de fonctions libres friend, notemment, tu en as dès
qu'une classe doit pouvoir être utilisée avec les flux. Et dans ces
cas précis, friend est incontournable si on veut en conserver une
utilisation naturelle (au sens habituelle).
Vraiment ? Pourquoi tu n'aimes pas l'idiome classique qui permet en
plus le polymorphisme :
Mais si, je l'aime cet idiôme...
Il doit y avoir quelque chose qui m'échappe dans ton argument (encore
une fois, tu as raison, et friend est nécessaire, si on ne veut pas
ajouter la fonction membre publique à l'interface de la classe).
J'avais en tête de la mettre protected, c'est pour celà que je parlais
d'utilisation habituelle : dans le sens où EcrireSur( os ); n'est pas une
"utilisation habituelle" des flux. Mais c'est vrai que la mettre public
permet tout autant os << objet;
Des exemples de fonctions libres friend, notemment, tu en as dès qu'une classe doit pouvoir être utilisée avec les flux. Et dans ces cas précis, friend est incontournable si on veut en conserver une utilisation naturelle (au sens habituelle).
Vraiment ? Pourquoi tu n'aimes pas l'idiome classique qui permet en plus le polymorphisme :
Mais si, je l'aime cet idiôme...
Il doit y avoir quelque chose qui m'échappe dans ton argument (encore une fois, tu as raison, et friend est nécessaire, si on ne veut pas ajouter la fonction membre publique à l'interface de la classe).
J'avais en tête de la mettre protected, c'est pour celà que je parlais d'utilisation habituelle : dans le sens où EcrireSur( os ); n'est pas une "utilisation habituelle" des flux. Mais c'est vrai que la mettre public permet tout autant os << objet;
"Yalbrieux" a écrit dans le message de news:bn15sk$5qb$
Bonsoir, Merci pour cet avis. Je ne vois toujours pas d'exemple incontournable et il
me semble effectivement que friend n'est pas une disposition claire. Pour tout vous dire ça me semble à moi, pauvre codeur bas de gamme, du bricolage.
Donc oui, j'en veux encore car il y a sûrement une raison. Yves
je ne crois pas que friend soit incontournable. Mais après tout, l'héritage
ne l'est pas non plus ;-)
Un exemple où friend est interessant (pour une classe) : Tu crées une liste générique (bon, y'en a une en STL, mais c'est pour l'exemple). Tu as besoin d'une classe élément qui contient la valeur à stocker mais également l'adresse de l'élément suivant. Cette classe n'a besoin d'être utilisée que par la liste. Donc tu peux tout mettre privé dedans, et déclarer la liste comme amie. template <class Elt> class EltListe { Elt Valeur; EltListe *Suivant; EltListe(const Elt& V):Valeur(V){} friend class Liste<Elt>; };
template <class Elt> class Liste { EltListe *pPremier; etc... };
bon, on pourrait mettre EltListe DANS liste, on pourrait mettre le constructeur public et espérer que personne ne l'appelle, il y a plein de solutions. Friend en permet une élégante, à mon avis.
Deuxième exemple : la définition d'opérateurs. Si tu veux un opérateur (genre +) parfaitement commutatif, il sera + utile comme fonction amie que comme membre.
etc...
"Yalbrieux" <yalbrieux@wanadoo.fr> a écrit dans le message de
news:bn15sk$5qb$1@news-reader4.wanadoo.fr...
Bonsoir,
Merci pour cet avis. Je ne vois toujours pas d'exemple incontournable et
il
me semble effectivement que friend n'est pas une disposition claire. Pour
tout vous dire ça me semble à moi, pauvre codeur bas de gamme, du
bricolage.
Donc oui, j'en veux encore car il y a sûrement une raison.
Yves
je ne crois pas que friend soit incontournable. Mais après tout, l'héritage
ne l'est pas non plus ;-)
Un exemple où friend est interessant (pour une classe) :
Tu crées une liste générique (bon, y'en a une en STL, mais c'est pour
l'exemple).
Tu as besoin d'une classe élément qui contient la valeur à stocker mais
également l'adresse de l'élément suivant.
Cette classe n'a besoin d'être utilisée que par la liste.
Donc tu peux tout mettre privé dedans, et déclarer la liste comme amie.
template <class Elt>
class EltListe
{
Elt Valeur;
EltListe *Suivant;
EltListe(const Elt& V):Valeur(V){}
friend class Liste<Elt>;
};
template <class Elt>
class Liste
{
EltListe *pPremier;
etc...
};
bon, on pourrait mettre EltListe DANS liste, on pourrait mettre le
constructeur public et espérer que personne ne l'appelle, il y a plein de
solutions.
Friend en permet une élégante, à mon avis.
Deuxième exemple : la définition d'opérateurs.
Si tu veux un opérateur (genre +) parfaitement commutatif, il sera + utile
comme fonction amie que comme membre.
"Yalbrieux" a écrit dans le message de news:bn15sk$5qb$
Bonsoir, Merci pour cet avis. Je ne vois toujours pas d'exemple incontournable et il
me semble effectivement que friend n'est pas une disposition claire. Pour tout vous dire ça me semble à moi, pauvre codeur bas de gamme, du bricolage.
Donc oui, j'en veux encore car il y a sûrement une raison. Yves
je ne crois pas que friend soit incontournable. Mais après tout, l'héritage
ne l'est pas non plus ;-)
Un exemple où friend est interessant (pour une classe) : Tu crées une liste générique (bon, y'en a une en STL, mais c'est pour l'exemple). Tu as besoin d'une classe élément qui contient la valeur à stocker mais également l'adresse de l'élément suivant. Cette classe n'a besoin d'être utilisée que par la liste. Donc tu peux tout mettre privé dedans, et déclarer la liste comme amie. template <class Elt> class EltListe { Elt Valeur; EltListe *Suivant; EltListe(const Elt& V):Valeur(V){} friend class Liste<Elt>; };
template <class Elt> class Liste { EltListe *pPremier; etc... };
bon, on pourrait mettre EltListe DANS liste, on pourrait mettre le constructeur public et espérer que personne ne l'appelle, il y a plein de solutions. Friend en permet une élégante, à mon avis.
Deuxième exemple : la définition d'opérateurs. Si tu veux un opérateur (genre +) parfaitement commutatif, il sera + utile comme fonction amie que comme membre.
etc...
Alexandre
"Fabien LE LEZ" a écrit dans le message de news:
On Tue, 21 Oct 2003 20:42:41 +0200, "Christophe Lephay" wrote:
Non, car tout ce qui a été fait depuis l'assembleur peut être vu comme des
dispositions de confort...
Y compris l'assembleur, d'ailleurs ;-)
-- ben oui, y' a ka coder avec des fils qui se branchent...
Qqn regrette cette époque ?? ;-)
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:463bpvg74gm17qmkgt8c72cprkp3jqedh9@4ax.com...
On Tue, 21 Oct 2003 20:42:41 +0200, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
Non, car tout ce qui a été fait depuis l'assembleur peut être vu comme
des
dispositions de confort...
Y compris l'assembleur, d'ailleurs ;-)
--
ben oui, y' a ka coder avec des fils qui se branchent...
On Tue, 21 Oct 2003 20:42:41 +0200, "Christophe Lephay" wrote:
Non, car tout ce qui a été fait depuis l'assembleur peut être vu comme des
dispositions de confort...
Y compris l'assembleur, d'ailleurs ;-)
-- ben oui, y' a ka coder avec des fils qui se branchent...
Qqn regrette cette époque ?? ;-)
Fabien LE LEZ
On Sat, 25 Oct 2003 20:47:05 +0200, "Alexandre" wrote:
on pourrait mettre le constructeur public
et espérer que personne ne l'appelle
Pourquoi ? Je peux très bien trouver une autre utilisation pour cette classe, et l'utiliser indépendamment de la classe Liste -- ce qui ne casserait en rien l'encapsulation de Liste.
-- ;-)
On Sat, 25 Oct 2003 20:47:05 +0200, "Alexandre"
<alex.g@netcourrier.com> wrote:
on pourrait mettre le
constructeur public
et espérer que personne ne l'appelle
Pourquoi ? Je peux très bien trouver une autre utilisation pour cette
classe, et l'utiliser indépendamment de la classe Liste -- ce qui ne
casserait en rien l'encapsulation de Liste.
On Sat, 25 Oct 2003 20:47:05 +0200, "Alexandre" wrote:
on pourrait mettre le constructeur public
et espérer que personne ne l'appelle
Pourquoi ? Je peux très bien trouver une autre utilisation pour cette classe, et l'utiliser indépendamment de la classe Liste -- ce qui ne casserait en rien l'encapsulation de Liste.
