Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions membres publiques dans les classes concernées et les appeler pour faire le travail, mais si on veut limiter les fonctions membres publiques, alors c'est facile de trouver des exemples. Tu en veux encore ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bmttk5$1on$1@news-reader1.wanadoo.fr,
Quelqu'un pourrait-il me donner un exemple incontournable de friend
nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions
membres publiques dans les classes concernées et les appeler pour
faire le travail, mais si on veut limiter les fonctions membres
publiques, alors c'est facile de trouver des exemples. Tu en veux
encore ?
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions membres publiques dans les classes concernées et les appeler pour faire le travail, mais si on veut limiter les fonctions membres publiques, alors c'est facile de trouver des exemples. Tu en veux encore ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Christophe Lephay
Michel Michaud wrote:
Dans news:bmttk5$1on$,
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions membres publiques dans les classes concernées et les appeler pour faire le travail, mais si on veut limiter les fonctions membres publiques, alors c'est facile de trouver des exemples. Tu en veux encore ?
Mais le fait de rajouter des membres publiques peut, dans certains cas, aller à l'encontre de l'encapsulation, en offrant moins de restriction qu'une fonction libre friend...
Concernant les fonctions friends, la question pose plus sur l'intérêt d'une fonction libre par rapport à une fonction membre, étant évident que, pour fournir la même fonctionnalité, les deux doivent pouvoir accéder aux mêmes données (privées).
Chris
Michel Michaud wrote:
Dans news:bmttk5$1on$1@news-reader1.wanadoo.fr,
Quelqu'un pourrait-il me donner un exemple incontournable de friend
nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions
membres publiques dans les classes concernées et les appeler pour
faire le travail, mais si on veut limiter les fonctions membres
publiques, alors c'est facile de trouver des exemples. Tu en veux
encore ?
Mais le fait de rajouter des membres publiques peut, dans certains cas,
aller à l'encontre de l'encapsulation, en offrant moins de restriction
qu'une fonction libre friend...
Concernant les fonctions friends, la question pose plus sur l'intérêt d'une
fonction libre par rapport à une fonction membre, étant évident que, pour
fournir la même fonctionnalité, les deux doivent pouvoir accéder aux mêmes
données (privées).
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions membres publiques dans les classes concernées et les appeler pour faire le travail, mais si on veut limiter les fonctions membres publiques, alors c'est facile de trouver des exemples. Tu en veux encore ?
Mais le fait de rajouter des membres publiques peut, dans certains cas, aller à l'encontre de l'encapsulation, en offrant moins de restriction qu'une fonction libre friend...
Concernant les fonctions friends, la question pose plus sur l'intérêt d'une fonction libre par rapport à une fonction membre, étant évident que, pour fournir la même fonctionnalité, les deux doivent pouvoir accéder aux mêmes données (privées).
Chris
Yalbrieux
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
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
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
Patrick Mézard
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions membres publiques dans les classes concernées et les appeler pour faire le travail, mais si on veut limiter les fonctions membres publiques, alors c'est facile de trouver des exemples. Tu en veux encore ?
Quel est l'intérêt de limiter les méthodes publiques en leur substituant des fonctions friend ? D'accord ça allège l'interface "explicite" de la classe mais bon les déclarations friend apparaissent tout de même au même endroit non ?
La seule utilité que je vois pour le moment de déclarer des fonctions friend plutôt que des méthodes est de conserver les propriétés de commutativité pour le opérateurs qui l'ont dans la vie courante (operator+ et autres...) et d'autoriser des conversions implicites qu'une méthode ne permettrait pas.
Patrick Mézard
Quelqu'un pourrait-il me donner un exemple incontournable de friend
nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions
membres publiques dans les classes concernées et les appeler pour
faire le travail, mais si on veut limiter les fonctions membres
publiques, alors c'est facile de trouver des exemples. Tu en veux
encore ?
Quel est l'intérêt de limiter les méthodes publiques en leur substituant des
fonctions friend ? D'accord ça allège l'interface "explicite" de la classe
mais bon les déclarations friend apparaissent tout de même au même endroit
non ?
La seule utilité que je vois pour le moment de déclarer des fonctions friend
plutôt que des méthodes est de conserver les propriétés de commutativité
pour le opérateurs qui l'ont dans la vie courante (operator+ et autres...)
et d'autoriser des conversions implicites qu'une méthode ne permettrait pas.
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions membres publiques dans les classes concernées et les appeler pour faire le travail, mais si on veut limiter les fonctions membres publiques, alors c'est facile de trouver des exemples. Tu en veux encore ?
Quel est l'intérêt de limiter les méthodes publiques en leur substituant des fonctions friend ? D'accord ça allège l'interface "explicite" de la classe mais bon les déclarations friend apparaissent tout de même au même endroit non ?
La seule utilité que je vois pour le moment de déclarer des fonctions friend plutôt que des méthodes est de conserver les propriétés de commutativité pour le opérateurs qui l'ont dans la vie courante (operator+ et autres...) et d'autoriser des conversions implicites qu'une méthode ne permettrait pas.
Patrick Mézard
Benoit Rousseau
Patrick Mézard wrote:
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions membres publiques dans les classes concernées et les appeler pour faire le travail, mais si on veut limiter les fonctions membres publiques, alors c'est facile de trouver des exemples. Tu en veux encore ?
Quel est l'intérêt de limiter les méthodes publiques en leur substituant des fonctions friend ? D'accord ça allège l'interface "explicite" de la classe mais bon les déclarations friend apparaissent tout de même au même endroit non ?
La seule utilité que je vois pour le moment de déclarer des fonctions friend plutôt que des méthodes est de conserver les propriétés de commutativité pour le opérateurs qui l'ont dans la vie courante (operator+ et autres...) et d'autoriser des conversions implicites qu'une méthode ne permettrait pas.
Patrick Mézard
Je pense que ça permet d'empecher l'acces aux membres protected/private par toutes les classes sauf exceptions : J'ai, par exemple, une classe qui est 'controllée' par une autre classe. Seule cette autre classe à le droit d'appeler des fonctions qui sont déclarées en protected/private.
-------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
Patrick Mézard wrote:
Quelqu'un pourrait-il me donner un exemple incontournable de friend
nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions
membres publiques dans les classes concernées et les appeler pour
faire le travail, mais si on veut limiter les fonctions membres
publiques, alors c'est facile de trouver des exemples. Tu en veux
encore ?
Quel est l'intérêt de limiter les méthodes publiques en leur substituant des
fonctions friend ? D'accord ça allège l'interface "explicite" de la classe
mais bon les déclarations friend apparaissent tout de même au même endroit
non ?
La seule utilité que je vois pour le moment de déclarer des fonctions friend
plutôt que des méthodes est de conserver les propriétés de commutativité
pour le opérateurs qui l'ont dans la vie courante (operator+ et autres...)
et d'autoriser des conversions implicites qu'une méthode ne permettrait pas.
Patrick Mézard
Je pense que ça permet d'empecher l'acces aux membres protected/private
par toutes les classes sauf exceptions : J'ai, par exemple, une classe
qui est 'controllée' par une autre classe. Seule cette autre classe à le
droit d'appeler des fonctions qui sont déclarées en protected/private.
--------------------------------------------
Benoît Rousseau : roussebe at spray dot se
Jouez en programmant : http://realtimebattle.sourceforge.net/
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Ce n'est jamais nécessaire, car on peut ajouter des fonctions membres publiques dans les classes concernées et les appeler pour faire le travail, mais si on veut limiter les fonctions membres publiques, alors c'est facile de trouver des exemples. Tu en veux encore ?
Quel est l'intérêt de limiter les méthodes publiques en leur substituant des fonctions friend ? D'accord ça allège l'interface "explicite" de la classe mais bon les déclarations friend apparaissent tout de même au même endroit non ?
La seule utilité que je vois pour le moment de déclarer des fonctions friend plutôt que des méthodes est de conserver les propriétés de commutativité pour le opérateurs qui l'ont dans la vie courante (operator+ et autres...) et d'autoriser des conversions implicites qu'une méthode ne permettrait pas.
Patrick Mézard
Je pense que ça permet d'empecher l'acces aux membres protected/private par toutes les classes sauf exceptions : J'ai, par exemple, une classe qui est 'controllée' par une autre classe. Seule cette autre classe à le droit d'appeler des fonctions qui sont déclarées en protected/private.
-------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
Loïc Joly
Yalbrieux wrote:
Bonjour,
J'ouvre un autre fil car il me semble sortir de la question de David Romand sur ==.
Les remarques de Benoît Dejean m'intéressent. Perso je n'ai jamais ressenti le besoin, ni donc utilisé, friend.
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Incontournable, pas vraiment, mais bien utile, voici un exemple : Ta classe est destinée à être crée par une factory, et uniquement par elle. Tu mets ton constructeur en privé, et la factory en friend.
-- Loïc
Yalbrieux wrote:
Bonjour,
J'ouvre un autre fil car il me semble sortir de la question de David Romand
sur ==.
Les remarques de Benoît Dejean m'intéressent.
Perso je n'ai jamais ressenti le besoin, ni donc utilisé, friend.
Quelqu'un pourrait-il me donner un exemple incontournable de friend
nécessaire ?
Incontournable, pas vraiment, mais bien utile, voici un exemple : Ta
classe est destinée à être crée par une factory, et uniquement par elle.
Tu mets ton constructeur en privé, et la factory en friend.
J'ouvre un autre fil car il me semble sortir de la question de David Romand sur ==.
Les remarques de Benoît Dejean m'intéressent. Perso je n'ai jamais ressenti le besoin, ni donc utilisé, friend.
Quelqu'un pourrait-il me donner un exemple incontournable de friend nécessaire ?
Incontournable, pas vraiment, mais bien utile, voici un exemple : Ta classe est destinée à être crée par une factory, et uniquement par elle. Tu mets ton constructeur en privé, et la factory en friend.
-- Loïc
Christophe Lephay
Yalbrieux wrote:
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.
Je ne crois pas qu'on puisse qualifier friend de bricolage. Un fait est que, dans un système objet, un certain nombre de classes entretiennent des relations privilégiées, et que friend sert à spécifier ces privilèges.
C'est dur de donner *un* exemple précis, car l'utilisation de friend ne peut se justifier de manière évidente que par rapport à un système donné, un ensemble de classes et objets collaborant entre eux. On peut certainement toujours faire autrement, mais celà peut nécessiter une refonte complète du système.
Si tu veux des exemples, lis le GoF ou les headers de la STL (le problème si on donne un exemple, c'est que ça risque d'entrainer des polémiques du style "on aurait pu faire autrement").
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).
Chris
Yalbrieux wrote:
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.
Je ne crois pas qu'on puisse qualifier friend de bricolage. Un fait est que,
dans un système objet, un certain nombre de classes entretiennent des
relations privilégiées, et que friend sert à spécifier ces privilèges.
C'est dur de donner *un* exemple précis, car l'utilisation de friend ne peut
se justifier de manière évidente que par rapport à un système donné, un
ensemble de classes et objets collaborant entre eux. On peut certainement
toujours faire autrement, mais celà peut nécessiter une refonte complète du
système.
Si tu veux des exemples, lis le GoF ou les headers de la STL (le problème si
on donne un exemple, c'est que ça risque d'entrainer des polémiques du style
"on aurait pu faire autrement").
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).
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.
Je ne crois pas qu'on puisse qualifier friend de bricolage. Un fait est que, dans un système objet, un certain nombre de classes entretiennent des relations privilégiées, et que friend sert à spécifier ces privilèges.
C'est dur de donner *un* exemple précis, car l'utilisation de friend ne peut se justifier de manière évidente que par rapport à un système donné, un ensemble de classes et objets collaborant entre eux. On peut certainement toujours faire autrement, mais celà peut nécessiter une refonte complète du système.
Si tu veux des exemples, lis le GoF ou les headers de la STL (le problème si on donne un exemple, c'est que ça risque d'entrainer des polémiques du style "on aurait pu faire autrement").
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).
Chris
Jean-Marc Bourguet
"Yalbrieux" writes:
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.
friend n'est jamais incontournable. On peut toujours mettre des accesseurs ou rendre des membres publics.
Mais friend est souvent une meilleure solution que mettre des accesseurs ou rendre des membres publics, parce que tout le monde n'a pas a pourvoir a acceder a tout.
On peut parfois eviter friend en ajoutant un membre avec la meme fonctionnalite (et eventuellement en ecrivant une fonction libre qui se contente de renvoyer a ce membre, par exemble dans le cas des operateurs ou on veut avoir les memes conversions possibles a gauche et a droite; quand j'ai une relation d'ordre j'ai tendance a utiliser cette technique pour les operateurs de comparaisons avec un membre qui a le meme genre de retour que strcmp -- generalement ca permet d'eviter de dupliquer du code --, quand je n'ai pas de relation d'ordre, l'operateur d'egalite est generalement friend parce que je ne vois pas l'interet du membre a part eviter friend) mais il est des cas ou ce n'est pas possible: quand on fait une autre classe friend ou quand une fonction libre est friend de deux classes.
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
"Yalbrieux" <yalbrieux@wanadoo.fr> writes:
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.
friend n'est jamais incontournable. On peut toujours mettre des
accesseurs ou rendre des membres publics.
Mais friend est souvent une meilleure solution que mettre des
accesseurs ou rendre des membres publics, parce que tout le monde n'a
pas a pourvoir a acceder a tout.
On peut parfois eviter friend en ajoutant un membre avec la meme
fonctionnalite (et eventuellement en ecrivant une fonction libre qui
se contente de renvoyer a ce membre, par exemble dans le cas des
operateurs ou on veut avoir les memes conversions possibles a gauche
et a droite; quand j'ai une relation d'ordre j'ai tendance a utiliser
cette technique pour les operateurs de comparaisons avec un membre qui
a le meme genre de retour que strcmp -- generalement ca permet
d'eviter de dupliquer du code --, quand je n'ai pas de relation
d'ordre, l'operateur d'egalite est generalement friend parce que je ne
vois pas l'interet du membre a part eviter friend) mais il est des cas
ou ce n'est pas possible: quand on fait une autre classe friend ou
quand une fonction libre est friend de deux classes.
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
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.
friend n'est jamais incontournable. On peut toujours mettre des accesseurs ou rendre des membres publics.
Mais friend est souvent une meilleure solution que mettre des accesseurs ou rendre des membres publics, parce que tout le monde n'a pas a pourvoir a acceder a tout.
On peut parfois eviter friend en ajoutant un membre avec la meme fonctionnalite (et eventuellement en ecrivant une fonction libre qui se contente de renvoyer a ce membre, par exemble dans le cas des operateurs ou on veut avoir les memes conversions possibles a gauche et a droite; quand j'ai une relation d'ordre j'ai tendance a utiliser cette technique pour les operateurs de comparaisons avec un membre qui a le meme genre de retour que strcmp -- generalement ca permet d'eviter de dupliquer du code --, quand je n'ai pas de relation d'ordre, l'operateur d'egalite est generalement friend parce que je ne vois pas l'interet du membre a part eviter friend) mais il est des cas ou ce n'est pas possible: quand on fait une autre classe friend ou quand une fonction libre est friend de deux classes.
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
Yalbrieux
Bonsoir à tous et d'abords merci pour vos réponses très intéressantes.
Est-ce que je pourrais résumer en disant finalement que friend est une disposition de ''confort '', non pas incontournable mais bien utile ?
Yves
Bonsoir à tous et d'abords merci pour vos réponses très intéressantes.
Est-ce que je pourrais résumer en disant finalement que friend est une
disposition de ''confort '', non pas incontournable mais bien utile ?
