il y a quelque mois, en parcourant le source
d'un programme j'ai not=E9 que l'op=E9rateur "->"
avait =E9t=E9 red=E9fini pour mettre en place une
d=E9l=E9gation.
Je n'avais pas trouv=E9 l'id=E9e tr=E8s judicieuse;
or r=E9cemment en lisant un ouvrage de J. Coplien
j'ai not=E9 l'existence de cette pratique ( par forc=E9ment encourag=E9
d'ailleurs ).
L'avez vous utilis=E9e ou rencontr=E9e dans des projets ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Wykaaa
Stan a écrit :
bonjour,
il y a quelque mois, en parcourant le source d'un programme j'ai noté que l'opérateur "->" avait été redéfini pour mettre en place une délégation. Je n'avais pas trouvé l'idée très judicieuse; or récemment en lisant un ouvrage de J. Coplien j'ai noté l'existence de cette pratique ( par forcément encouragé d'ailleurs ).
L'avez vous utilisée ou rencontrée dans des projets ?
-- -Stan
Bien sûr que c'est utilisé dans des projets. J'ai souvent utilisé cette construction.
il y a quelque mois, en parcourant le source
d'un programme j'ai noté que l'opérateur "->"
avait été redéfini pour mettre en place une
délégation.
Je n'avais pas trouvé l'idée très judicieuse;
or récemment en lisant un ouvrage de J. Coplien
j'ai noté l'existence de cette pratique ( par forcément encouragé
d'ailleurs ).
L'avez vous utilisée ou rencontrée dans des projets ?
--
-Stan
Bien sûr que c'est utilisé dans des projets. J'ai souvent utilisé cette
construction.
il y a quelque mois, en parcourant le source d'un programme j'ai noté que l'opérateur "->" avait été redéfini pour mettre en place une délégation. Je n'avais pas trouvé l'idée très judicieuse; or récemment en lisant un ouvrage de J. Coplien j'ai noté l'existence de cette pratique ( par forcément encouragé d'ailleurs ).
L'avez vous utilisée ou rencontrée dans des projets ?
-- -Stan
Bien sûr que c'est utilisé dans des projets. J'ai souvent utilisé cette construction.
J'aurais peut être dû le préciser, mais je parlais de son utilisation en dehors des smart pointers. Dans le cas des SP, la sémantique correspond parfaitement à ce qu'on souhaite faire. Mais à part cet exemple canonique, j'ai dû mal à justifier son utilisation.
-- -Stan
On 13 jan, 14:31, Wykaaa <wyk...@yahoo.fr> wrote:
Bien sûr que c'est utilisé dans des projets. J'ai souvent utilisé c ette
construction.
J'aurais peut être dû le préciser, mais je parlais de son utilisation
en dehors des smart pointers.
Dans le cas des SP, la sémantique correspond parfaitement à ce qu'on
souhaite faire.
Mais à part cet exemple canonique, j'ai dû mal à justifier son
utilisation.
J'aurais peut être dû le préciser, mais je parlais de son utilisation en dehors des smart pointers. Dans le cas des SP, la sémantique correspond parfaitement à ce qu'on souhaite faire. Mais à part cet exemple canonique, j'ai dû mal à justifier son utilisation.
-- -Stan
ld
On 13 jan, 15:17, Stan wrote:
On 13 jan, 14:31, Wykaaa wrote:
> Bien sûr que c'est utilisé dans des projets. J'ai souvent utilisé cette > construction.
J'aurais peut être dû le préciser, mais je parlais de son utilisati on en dehors des smart pointers. Dans le cas des SP, la sémantique correspond parfaitement à ce qu'on souhaite faire. Mais à part cet exemple canonique, j'ai dû mal à justifier son utilisation.
Dans la mesure ou l'operator-> ne marche que sur des pointeurs, ca sera toujours une "sorte" de smart pointer. Si l'operateur '.' pouvait etre overloade avec la meme semantique (de propagation), alors il aurait ete utile pour des patterns comme le Pimpl ou l'enveloppe/ lettre (operator-> peut aussi jouer ce role au prix de double indirections et allocations). De plus cette "delegation" reste "statique" (template), les possibilibites restent donc moindre qu'avec la delegation dynamique. Sans doute que combine astucieusement au SFINAE, il y a des possibilites interessantes pour d'autres applications (jamais regarde ce cote la).
a+, ld.
On 13 jan, 15:17, Stan <t...@neuf.fr> wrote:
On 13 jan, 14:31, Wykaaa <wyk...@yahoo.fr> wrote:
> Bien sûr que c'est utilisé dans des projets. J'ai souvent utilisé cette
> construction.
J'aurais peut être dû le préciser, mais je parlais de son utilisati on
en dehors des smart pointers.
Dans le cas des SP, la sémantique correspond parfaitement à ce qu'on
souhaite faire.
Mais à part cet exemple canonique, j'ai dû mal à justifier son
utilisation.
Dans la mesure ou l'operator-> ne marche que sur des pointeurs, ca
sera toujours une "sorte" de smart pointer. Si l'operateur '.' pouvait
etre overloade avec la meme semantique (de propagation), alors il
aurait ete utile pour des patterns comme le Pimpl ou l'enveloppe/
lettre (operator-> peut aussi jouer ce role au prix de double
indirections et allocations). De plus cette "delegation" reste
"statique" (template), les possibilibites restent donc moindre qu'avec
la delegation dynamique. Sans doute que combine astucieusement au
SFINAE, il y a des possibilites interessantes pour d'autres
applications (jamais regarde ce cote la).
J'aurais peut être dû le préciser, mais je parlais de son utilisati on en dehors des smart pointers. Dans le cas des SP, la sémantique correspond parfaitement à ce qu'on souhaite faire. Mais à part cet exemple canonique, j'ai dû mal à justifier son utilisation.
Dans la mesure ou l'operator-> ne marche que sur des pointeurs, ca sera toujours une "sorte" de smart pointer. Si l'operateur '.' pouvait etre overloade avec la meme semantique (de propagation), alors il aurait ete utile pour des patterns comme le Pimpl ou l'enveloppe/ lettre (operator-> peut aussi jouer ce role au prix de double indirections et allocations). De plus cette "delegation" reste "statique" (template), les possibilibites restent donc moindre qu'avec la delegation dynamique. Sans doute que combine astucieusement au SFINAE, il y a des possibilites interessantes pour d'autres applications (jamais regarde ce cote la).
a+, ld.
ld
On 13 jan, 16:51, ld wrote:
On 13 jan, 15:17, Stan wrote:
> On 13 jan, 14:31, Wykaaa wrote:
> > Bien sûr que c'est utilisé dans des projets. J'ai souvent utilis é cette > > construction.
> J'aurais peut être dû le préciser, mais je parlais de son utilisa tion > en dehors des smart pointers. > Dans le cas des SP, la sémantique correspond parfaitement à ce qu'o n > souhaite faire. > Mais à part cet exemple canonique, j'ai dû mal à justifier son > utilisation.
Dans la mesure ou l'operator-> ne marche que sur des pointeurs, ca sera toujours une "sorte" de smart pointer. Si l'operateur '.' pouvait etre overloade avec la meme semantique (de propagation), alors il aurait ete utile pour des patterns comme le Pimpl ou l'enveloppe/ lettre (operator-> peut aussi jouer ce role au prix de double indirections et allocations).
Je ne sais pas pourquoi j'ai dit ca. En fait, l'overload de operator-> est tout a fait adapte au pattern Pimpl et Enveloppe/Lettre sans double indirection ou allocation... En revanche on aura toujours l'impression d'utiliser une sorte smart pointer.
De plus cette "delegation" reste "statique" (template), les possibilibites restent donc moindre qu'avec la delegation dynamique. Sans doute que combine astucieusement au SFINAE, il y a des possibilites interessantes pour d'autres applications (jamais regarde ce cote la).
a+, ld.
On 13 jan, 16:51, ld <laurent.den...@gmail.com> wrote:
On 13 jan, 15:17, Stan <t...@neuf.fr> wrote:
> On 13 jan, 14:31, Wykaaa <wyk...@yahoo.fr> wrote:
> > Bien sûr que c'est utilisé dans des projets. J'ai souvent utilis é cette
> > construction.
> J'aurais peut être dû le préciser, mais je parlais de son utilisa tion
> en dehors des smart pointers.
> Dans le cas des SP, la sémantique correspond parfaitement à ce qu'o n
> souhaite faire.
> Mais à part cet exemple canonique, j'ai dû mal à justifier son
> utilisation.
Dans la mesure ou l'operator-> ne marche que sur des pointeurs, ca
sera toujours une "sorte" de smart pointer. Si l'operateur '.' pouvait
etre overloade avec la meme semantique (de propagation), alors il
aurait ete utile pour des patterns comme le Pimpl ou l'enveloppe/
lettre (operator-> peut aussi jouer ce role au prix de double
indirections et allocations).
Je ne sais pas pourquoi j'ai dit ca. En fait, l'overload de operator->
est tout a fait adapte au pattern Pimpl et Enveloppe/Lettre sans
double indirection ou allocation... En revanche on aura toujours
l'impression d'utiliser une sorte smart pointer.
De plus cette "delegation" reste
"statique" (template), les possibilibites restent donc moindre qu'avec
la delegation dynamique. Sans doute que combine astucieusement au
SFINAE, il y a des possibilites interessantes pour d'autres
applications (jamais regarde ce cote la).
> J'aurais peut être dû le préciser, mais je parlais de son utilisa tion > en dehors des smart pointers. > Dans le cas des SP, la sémantique correspond parfaitement à ce qu'o n > souhaite faire. > Mais à part cet exemple canonique, j'ai dû mal à justifier son > utilisation.
Dans la mesure ou l'operator-> ne marche que sur des pointeurs, ca sera toujours une "sorte" de smart pointer. Si l'operateur '.' pouvait etre overloade avec la meme semantique (de propagation), alors il aurait ete utile pour des patterns comme le Pimpl ou l'enveloppe/ lettre (operator-> peut aussi jouer ce role au prix de double indirections et allocations).
Je ne sais pas pourquoi j'ai dit ca. En fait, l'overload de operator-> est tout a fait adapte au pattern Pimpl et Enveloppe/Lettre sans double indirection ou allocation... En revanche on aura toujours l'impression d'utiliser une sorte smart pointer.
De plus cette "delegation" reste "statique" (template), les possibilibites restent donc moindre qu'avec la delegation dynamique. Sans doute que combine astucieusement au SFINAE, il y a des possibilites interessantes pour d'autres applications (jamais regarde ce cote la).
a+, ld.
Jean-Marc Bourguet
Stan writes:
On 13 jan, 14:31, Wykaaa wrote:
Bien sûr que c'est utilisé dans des projets. J'ai souvent utilisé cette construction.
J'aurais peut être dû le préciser, mais je parlais de son utilisation en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une classe qui définit un opérateur ->"
A+
-- Jean-Marc FAQ de fclc++: http://web.archive.org/web/*/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
Stan <tmp@neuf.fr> writes:
On 13 jan, 14:31, Wykaaa <wyk...@yahoo.fr> wrote:
Bien sûr que c'est utilisé dans des projets. J'ai souvent utilisé cette
construction.
J'aurais peut être dû le préciser, mais je parlais de son utilisation
en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une classe qui
définit un opérateur ->"
A+
--
Jean-Marc
FAQ de fclc++: http://web.archive.org/web/*/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
J'aurais peut être dû le préciser, mais je parlais de son utilisation en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une classe qui définit un opérateur ->"
A+
-- Jean-Marc FAQ de fclc++: http://web.archive.org/web/*/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
James Kanze
On Jan 13, 6:25 pm, Jean-Marc Bourguet wrote:
Stan writes: > On 13 jan, 14:31, Wykaaa wrote:
>> Bien sûr que c'est utilis dans des projets. J'ai souvent >> utilis cette construction.
> J'aurais peut-être dû le préciser, mais je parlais de son utilisa tion > en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une classe qui définit un opérateur ->"
C'est une définition possible, mais certainement pas la seule.
Quand j'ai commencé en C++, une technique dont on parlait (et qui est encore utile parfois), c'était des proxys. Classiquement, le proxy supporte l'affectation et la conversion en rvalue du type voulue, mais on pourrait vouloir plus. Si, par exemple, mon proxy, c'est la valeur de retour d'un operator[], et que dans la collection, j'ai des struct, je pourrais vouloir supporter quelque chose comme container[index].element. Seulement, je ne peux pas surcharger l'opérateur . ; la solution conseillée, parfois, c'était d'utiliser l'operator-> à la place. Ça expose un peu trop le fait qu'on utilise un proxy, mais faute d'autres alternatifs...
Or, j'aurais du mal à considérer un tel proxy comme un smart pointer.
-- James Kanze
On Jan 13, 6:25 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Stan <t...@neuf.fr> writes:
> On 13 jan, 14:31, Wykaaa <wyk...@yahoo.fr> wrote:
>> Bien sûr que c'est utilis dans des projets. J'ai souvent
>> utilis cette construction.
> J'aurais peut-être dû le préciser, mais je parlais de son utilisa tion
> en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une
classe qui définit un opérateur ->"
C'est une définition possible, mais certainement pas la seule.
Quand j'ai commencé en C++, une technique dont on parlait (et
qui est encore utile parfois), c'était des proxys.
Classiquement, le proxy supporte l'affectation et la conversion
en rvalue du type voulue, mais on pourrait vouloir plus. Si, par
exemple, mon proxy, c'est la valeur de retour d'un operator[],
et que dans la collection, j'ai des struct, je pourrais vouloir
supporter quelque chose comme container[index].element.
Seulement, je ne peux pas surcharger l'opérateur . ; la solution
conseillée, parfois, c'était d'utiliser l'operator-> à la place.
Ça expose un peu trop le fait qu'on utilise un proxy, mais faute
d'autres alternatifs...
Or, j'aurais du mal à considérer un tel proxy comme un smart
pointer.
> J'aurais peut-être dû le préciser, mais je parlais de son utilisa tion > en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une classe qui définit un opérateur ->"
C'est une définition possible, mais certainement pas la seule.
Quand j'ai commencé en C++, une technique dont on parlait (et qui est encore utile parfois), c'était des proxys. Classiquement, le proxy supporte l'affectation et la conversion en rvalue du type voulue, mais on pourrait vouloir plus. Si, par exemple, mon proxy, c'est la valeur de retour d'un operator[], et que dans la collection, j'ai des struct, je pourrais vouloir supporter quelque chose comme container[index].element. Seulement, je ne peux pas surcharger l'opérateur . ; la solution conseillée, parfois, c'était d'utiliser l'operator-> à la place. Ça expose un peu trop le fait qu'on utilise un proxy, mais faute d'autres alternatifs...
Or, j'aurais du mal à considérer un tel proxy comme un smart pointer.
-- James Kanze
Wykaaa
James Kanze a écrit :
On Jan 13, 6:25 pm, Jean-Marc Bourguet wrote:
Stan writes:
On 13 jan, 14:31, Wykaaa wrote:
Bien sûr que c'est utilis dans des projets. J'ai souvent utilis cette construction. Voir :http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Smart_Pointer
J'aurais peut-être dû le préciser, mais je parlais de son utilisation en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une classe qui définit un opérateur ->"
C'est une définition possible, mais certainement pas la seule.
Quand j'ai commencé en C++, une technique dont on parlait (et qui est encore utile parfois), c'était des proxys. Classiquement, le proxy supporte l'affectation et la conversion en rvalue du type voulue, mais on pourrait vouloir plus. Si, par exemple, mon proxy, c'est la valeur de retour d'un operator[], et que dans la collection, j'ai des struct, je pourrais vouloir supporter quelque chose comme container[index].element. Seulement, je ne peux pas surcharger l'opérateur . ; la solution conseillée, parfois, c'était d'utiliser l'operator-> à la place. Ça expose un peu trop le fait qu'on utilise un proxy, mais faute d'autres alternatifs...
Or, j'aurais du mal à considérer un tel proxy comme un smart pointer.
-- James Kanze
Tu as tout à fait raison et j'ai utilisé la surcharge de l'opérateur -> aussi pour ce pattern. Il me semble cependant difficile de trouver, sur le Net, des utilisations de la surcharge de -> en dehors des smart pointers alors qu'il en existe et ton exemple de proxy en est un. J'ai aussi utilisé la surcharge de -> dans l'implémentation d'un mini tableur pour déclencher les calculs dans des cellules qui contenaient des formules faisant référence à d'autres cellules quand la valeur de celles-ci changeaient.
James Kanze a écrit :
On Jan 13, 6:25 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Stan <t...@neuf.fr> writes:
On 13 jan, 14:31, Wykaaa <wyk...@yahoo.fr> wrote:
Bien sûr que c'est utilis dans des projets. J'ai souvent
utilis cette construction.
Voir :http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Smart_Pointer
J'aurais peut-être dû le préciser, mais je parlais de son utilisation
en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une
classe qui définit un opérateur ->"
C'est une définition possible, mais certainement pas la seule.
Quand j'ai commencé en C++, une technique dont on parlait (et
qui est encore utile parfois), c'était des proxys.
Classiquement, le proxy supporte l'affectation et la conversion
en rvalue du type voulue, mais on pourrait vouloir plus. Si, par
exemple, mon proxy, c'est la valeur de retour d'un operator[],
et que dans la collection, j'ai des struct, je pourrais vouloir
supporter quelque chose comme container[index].element.
Seulement, je ne peux pas surcharger l'opérateur . ; la solution
conseillée, parfois, c'était d'utiliser l'operator-> à la place.
Ça expose un peu trop le fait qu'on utilise un proxy, mais faute
d'autres alternatifs...
Or, j'aurais du mal à considérer un tel proxy comme un smart
pointer.
--
James Kanze
Tu as tout à fait raison et j'ai utilisé la surcharge de l'opérateur ->
aussi pour ce pattern.
Il me semble cependant difficile de trouver, sur le Net, des
utilisations de la surcharge de -> en dehors des smart pointers alors
qu'il en existe et ton exemple de proxy en est un.
J'ai aussi utilisé la surcharge de -> dans l'implémentation d'un mini
tableur pour déclencher les calculs dans des cellules qui contenaient
des formules faisant référence à d'autres cellules quand la valeur de
celles-ci changeaient.
Bien sûr que c'est utilis dans des projets. J'ai souvent utilis cette construction. Voir :http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Smart_Pointer
J'aurais peut-être dû le préciser, mais je parlais de son utilisation en dehors des smart pointers.
Difficile, une définition possible de smart pointer, est "une classe qui définit un opérateur ->"
C'est une définition possible, mais certainement pas la seule.
Quand j'ai commencé en C++, une technique dont on parlait (et qui est encore utile parfois), c'était des proxys. Classiquement, le proxy supporte l'affectation et la conversion en rvalue du type voulue, mais on pourrait vouloir plus. Si, par exemple, mon proxy, c'est la valeur de retour d'un operator[], et que dans la collection, j'ai des struct, je pourrais vouloir supporter quelque chose comme container[index].element. Seulement, je ne peux pas surcharger l'opérateur . ; la solution conseillée, parfois, c'était d'utiliser l'operator-> à la place. Ça expose un peu trop le fait qu'on utilise un proxy, mais faute d'autres alternatifs...
Or, j'aurais du mal à considérer un tel proxy comme un smart pointer.
-- James Kanze
Tu as tout à fait raison et j'ai utilisé la surcharge de l'opérateur -> aussi pour ce pattern. Il me semble cependant difficile de trouver, sur le Net, des utilisations de la surcharge de -> en dehors des smart pointers alors qu'il en existe et ton exemple de proxy en est un. J'ai aussi utilisé la surcharge de -> dans l'implémentation d'un mini tableur pour déclencher les calculs dans des cellules qui contenaient des formules faisant référence à d'autres cellules quand la valeur de celles-ci changeaient.
