Marc Boyer wrote on 07/03/2007 20:46:
Oui, ça je sais. Puis Laurent m'a dit "Probleme ici. Il ne faut pas
utiliser des references mais des copies.", et c'est pour cela que j'ai
évoqué la perte du polymorphisme.
aurait-il du préciser "copie statique pouvant réellement exister" ??
utiliser des réf., des pointeurs ou des statiques ne change rien au
polymorphisme des instances et n'a en fait rien à voir avec lui !!
ayant:
struct A {
virtual foo() {}
};
struct B : A {
};
struct C : B {
virtual foo() {}
};
A a;
B b;
C c;
A& ra = a; // ou ra = b; ou ra = c;
B& rb = b; // ou rb = c;
C& rc = c;
A* pa = &a; // ou pa = &b; ou pa = &c;
B* pb = &b; // ou pb = &c;
C* pc = &c;
tous les appels:
a.foo(); b.foo(); c.foo();
ra.foo(); rb.foo(); rc.foo();
pa->foo(); pb->foo(); pc->foo();
sont résolus virtuellement et tiennent compte du polymorphisme.
tu sembles faire une distinction comme:
void bar(A& a) { a.foo(); }
bar(c); // ohhh du polymorphisme
vs
B b;
b.foo(); // ne serait pas polymorphe
une telle définition serait un non sens
- et à ce titre on parle de
polymorphisme plus volontiers pour des types containers construits sur
le type de base de la famille de classes polymorphes (Cf "ma belle
listée chainée polymorphique", parutions diverses, 1988-1990).
Google sait retrouver un post à partir d'un ID si tu veux.
s'il a été indéxé, tu sais ce n'est pas tout à fait immédiat.
Sauf que dans l'ECM que je viens de poster, c'est
struct Fonction {
virtual double operator()(double x) const { assert(false); return 0;};
// La fonction virtuelle pure remplacee par une fct reelle pour
// que ça compile
peut être cela commençait à être un peu trop noyé de "et si" pour que je
note cette variation ...
le proto de () (pour ne parler que de lui) serait également non élégant,
ici Fonction /est/ virtuelle pure par essence;
Oui, comme on tourne autour d'une solution, il y a diverses versions,
mais le post auquel tu viens de repondre possède un ECM ou Fonction
n'est pas virtuelle pure.
cette variante n'est pas une solution, seulement une machine à produire
des assert de manière certaine (cf "dans un "Fonction" on ne stocke
qu'un "Fonction");
Tient, il garantie pas de n'appeller les destructeur qu'à la fin
du bloc courant ?
pour autant que l'on puisse définir bloc courant, si; mais jouer ainsi
avec des définitions variantes est risqué - je préfère franchement
définir /son/ bloc courant à sa portée d'utilisation (et elle s'arrête
dans le constructeur).
ces instances jamais détruites.
Quel est le risque ?
aucun si tes codes ne tournent qu'une fois, mais c'est juste une très
mauvaise habitude / attitude.
Marc Boyer wrote on 07/03/2007 20:46:
Oui, ça je sais. Puis Laurent m'a dit "Probleme ici. Il ne faut pas
utiliser des references mais des copies.", et c'est pour cela que j'ai
évoqué la perte du polymorphisme.
aurait-il du préciser "copie statique pouvant réellement exister" ??
utiliser des réf., des pointeurs ou des statiques ne change rien au
polymorphisme des instances et n'a en fait rien à voir avec lui !!
ayant:
struct A {
virtual foo() {}
};
struct B : A {
};
struct C : B {
virtual foo() {}
};
A a;
B b;
C c;
A& ra = a; // ou ra = b; ou ra = c;
B& rb = b; // ou rb = c;
C& rc = c;
A* pa = &a; // ou pa = &b; ou pa = &c;
B* pb = &b; // ou pb = &c;
C* pc = &c;
tous les appels:
a.foo(); b.foo(); c.foo();
ra.foo(); rb.foo(); rc.foo();
pa->foo(); pb->foo(); pc->foo();
sont résolus virtuellement et tiennent compte du polymorphisme.
tu sembles faire une distinction comme:
void bar(A& a) { a.foo(); }
bar(c); // ohhh du polymorphisme
vs
B b;
b.foo(); // ne serait pas polymorphe
une telle définition serait un non sens
- et à ce titre on parle de
polymorphisme plus volontiers pour des types containers construits sur
le type de base de la famille de classes polymorphes (Cf "ma belle
listée chainée polymorphique", parutions diverses, 1988-1990).
Google sait retrouver un post à partir d'un ID si tu veux.
s'il a été indéxé, tu sais ce n'est pas tout à fait immédiat.
Sauf que dans l'ECM que je viens de poster, c'est
struct Fonction {
virtual double operator()(double x) const { assert(false); return 0;};
// La fonction virtuelle pure remplacee par une fct reelle pour
// que ça compile
peut être cela commençait à être un peu trop noyé de "et si" pour que je
note cette variation ...
le proto de () (pour ne parler que de lui) serait également non élégant,
ici Fonction /est/ virtuelle pure par essence;
Oui, comme on tourne autour d'une solution, il y a diverses versions,
mais le post auquel tu viens de repondre possède un ECM ou Fonction
n'est pas virtuelle pure.
cette variante n'est pas une solution, seulement une machine à produire
des assert de manière certaine (cf "dans un "Fonction" on ne stocke
qu'un "Fonction");
Tient, il garantie pas de n'appeller les destructeur qu'à la fin
du bloc courant ?
pour autant que l'on puisse définir bloc courant, si; mais jouer ainsi
avec des définitions variantes est risqué - je préfère franchement
définir /son/ bloc courant à sa portée d'utilisation (et elle s'arrête
dans le constructeur).
ces instances jamais détruites.
Quel est le risque ?
aucun si tes codes ne tournent qu'une fois, mais c'est juste une très
mauvaise habitude / attitude.
Marc Boyer wrote on 07/03/2007 20:46:
Oui, ça je sais. Puis Laurent m'a dit "Probleme ici. Il ne faut pas
utiliser des references mais des copies.", et c'est pour cela que j'ai
évoqué la perte du polymorphisme.
aurait-il du préciser "copie statique pouvant réellement exister" ??
utiliser des réf., des pointeurs ou des statiques ne change rien au
polymorphisme des instances et n'a en fait rien à voir avec lui !!
ayant:
struct A {
virtual foo() {}
};
struct B : A {
};
struct C : B {
virtual foo() {}
};
A a;
B b;
C c;
A& ra = a; // ou ra = b; ou ra = c;
B& rb = b; // ou rb = c;
C& rc = c;
A* pa = &a; // ou pa = &b; ou pa = &c;
B* pb = &b; // ou pb = &c;
C* pc = &c;
tous les appels:
a.foo(); b.foo(); c.foo();
ra.foo(); rb.foo(); rc.foo();
pa->foo(); pb->foo(); pc->foo();
sont résolus virtuellement et tiennent compte du polymorphisme.
tu sembles faire une distinction comme:
void bar(A& a) { a.foo(); }
bar(c); // ohhh du polymorphisme
vs
B b;
b.foo(); // ne serait pas polymorphe
une telle définition serait un non sens
- et à ce titre on parle de
polymorphisme plus volontiers pour des types containers construits sur
le type de base de la famille de classes polymorphes (Cf "ma belle
listée chainée polymorphique", parutions diverses, 1988-1990).
Google sait retrouver un post à partir d'un ID si tu veux.
s'il a été indéxé, tu sais ce n'est pas tout à fait immédiat.
Sauf que dans l'ECM que je viens de poster, c'est
struct Fonction {
virtual double operator()(double x) const { assert(false); return 0;};
// La fonction virtuelle pure remplacee par une fct reelle pour
// que ça compile
peut être cela commençait à être un peu trop noyé de "et si" pour que je
note cette variation ...
le proto de () (pour ne parler que de lui) serait également non élégant,
ici Fonction /est/ virtuelle pure par essence;
Oui, comme on tourne autour d'une solution, il y a diverses versions,
mais le post auquel tu viens de repondre possède un ECM ou Fonction
n'est pas virtuelle pure.
cette variante n'est pas une solution, seulement une machine à produire
des assert de manière certaine (cf "dans un "Fonction" on ne stocke
qu'un "Fonction");
Tient, il garantie pas de n'appeller les destructeur qu'à la fin
du bloc courant ?
pour autant que l'on puisse définir bloc courant, si; mais jouer ainsi
avec des définitions variantes est risqué - je préfère franchement
définir /son/ bloc courant à sa portée d'utilisation (et elle s'arrête
dans le constructeur).
ces instances jamais détruites.
Quel est le risque ?
aucun si tes codes ne tournent qu'une fois, mais c'est juste une très
mauvaise habitude / attitude.
Le 07-03-2007, Sylvain a écrit :Marc Boyer wrote on 07/03/2007 17:19:
[...]
class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Oui, ça je sais. Puis Laurent m'a dit "Probleme ici. Il ne faut pas
utiliser des references mais des copies.", et c'est pour cela que j'ai
évoqué la perte du polymorphisme.
Le 07-03-2007, Sylvain <noS...@mail.net> a écrit :
Marc Boyer wrote on 07/03/2007 17:19:
[...]
class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Oui, ça je sais. Puis Laurent m'a dit "Probleme ici. Il ne faut pas
utiliser des references mais des copies.", et c'est pour cela que j'ai
évoqué la perte du polymorphisme.
Le 07-03-2007, Sylvain a écrit :Marc Boyer wrote on 07/03/2007 17:19:
[...]
class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Oui, ça je sais. Puis Laurent m'a dit "Probleme ici. Il ne faut pas
utiliser des references mais des copies.", et c'est pour cela que j'ai
évoqué la perte du polymorphisme.
Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
des données membre pointeurs sont pourtant la bonne solution, leur
initialisation, utilisation peut selon le nombre d'occurrence être
doublonné avec des refs pour s'épargner qlq déréférencements.
Dans de tels cas, ça m'arrive souvent de faire que le paramètre
et la variable membre sont des std::auto_ptr. Quand je fais
vite, et que je n'ai pas le collecteur de Boehm sous la main,
évidemment. Si j'ai Boost installé, je pourrais aussi préférer
boost::shared_ptr dans ce cas précis. (Ce n'est pas une réponse
universelle à l'absence du GC, mais dans le cas des agents
polymorphe, il est tout à fait indiqué.)
Mais dans les deux cas, à l'appel, il faudrait faire un appel
avec un new, non ?
Min m( new Affine(2), new Affine(3));
Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
des données membre pointeurs sont pourtant la bonne solution, leur
initialisation, utilisation peut selon le nombre d'occurrence être
doublonné avec des refs pour s'épargner qlq déréférencements.
Dans de tels cas, ça m'arrive souvent de faire que le paramètre
et la variable membre sont des std::auto_ptr. Quand je fais
vite, et que je n'ai pas le collecteur de Boehm sous la main,
évidemment. Si j'ai Boost installé, je pourrais aussi préférer
boost::shared_ptr dans ce cas précis. (Ce n'est pas une réponse
universelle à l'absence du GC, mais dans le cas des agents
polymorphe, il est tout à fait indiqué.)
Mais dans les deux cas, à l'appel, il faudrait faire un appel
avec un new, non ?
Min m( new Affine(2), new Affine(3));
Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
des données membre pointeurs sont pourtant la bonne solution, leur
initialisation, utilisation peut selon le nombre d'occurrence être
doublonné avec des refs pour s'épargner qlq déréférencements.
Dans de tels cas, ça m'arrive souvent de faire que le paramètre
et la variable membre sont des std::auto_ptr. Quand je fais
vite, et que je n'ai pas le collecteur de Boehm sous la main,
évidemment. Si j'ai Boost installé, je pourrais aussi préférer
boost::shared_ptr dans ce cas précis. (Ce n'est pas une réponse
universelle à l'absence du GC, mais dans le cas des agents
polymorphe, il est tout à fait indiqué.)
Mais dans les deux cas, à l'appel, il faudrait faire un appel
avec un new, non ?
Min m( new Affine(2), new Affine(3));
pourquoi pas, je n'ai jamais utilisé ces auto ou shared ptr, ni jamais
regretter l'absence d'un GC, mais pour qui ne veut/sait pas gérer
correctement un pointeur, c'est sûrement bien.
pourquoi pas, je n'ai jamais utilisé ces auto ou shared ptr, ni jamais
regretter l'absence d'un GC, mais pour qui ne veut/sait pas gérer
correctement un pointeur, c'est sûrement bien.
pourquoi pas, je n'ai jamais utilisé ces auto ou shared ptr, ni jamais
regretter l'absence d'un GC, mais pour qui ne veut/sait pas gérer
correctement un pointeur, c'est sûrement bien.
On Mar 7, 5:28 pm, Marc Boyer
wrote:Mais dans les deux cas, à l'appel, il faudrait faire un appel
avec un new, non ?
Min m( new Affine(2), new Affine(3));
Certes. Je crois même qu'il faut écrire :
Min m( std::auto_ptr< Function >( new Affine( 2 ) ),
std::auto_ptr< Function >( new Affine( 3 ) ) ) ;
parce qu'il n'y a pas de conversion implicite.
C'est précisement ce genre de problème qui m'a motivé à utiliser
le collecteur de Boehm (qui ferait probablement partie de la
prochaine version du C++ standard).
On Mar 7, 5:28 pm, Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid>
wrote:
Mais dans les deux cas, à l'appel, il faudrait faire un appel
avec un new, non ?
Min m( new Affine(2), new Affine(3));
Certes. Je crois même qu'il faut écrire :
Min m( std::auto_ptr< Function >( new Affine( 2 ) ),
std::auto_ptr< Function >( new Affine( 3 ) ) ) ;
parce qu'il n'y a pas de conversion implicite.
C'est précisement ce genre de problème qui m'a motivé à utiliser
le collecteur de Boehm (qui ferait probablement partie de la
prochaine version du C++ standard).
On Mar 7, 5:28 pm, Marc Boyer
wrote:Mais dans les deux cas, à l'appel, il faudrait faire un appel
avec un new, non ?
Min m( new Affine(2), new Affine(3));
Certes. Je crois même qu'il faut écrire :
Min m( std::auto_ptr< Function >( new Affine( 2 ) ),
std::auto_ptr< Function >( new Affine( 3 ) ) ) ;
parce qu'il n'y a pas de conversion implicite.
C'est précisement ce genre de problème qui m'a motivé à utiliser
le collecteur de Boehm (qui ferait probablement partie de la
prochaine version du C++ standard).
B b;
b.foo(); // ne serait pas polymorphe
Oui.une telle définition serait un non sens
C'est là que je demande des précisions.- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
B b;
b.foo(); // ne serait pas polymorphe
Oui.
une telle définition serait un non sens
C'est là que je demande des précisions.
- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
B b;
b.foo(); // ne serait pas polymorphe
Oui.une telle définition serait un non sens
C'est là que je demande des précisions.- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
Marc Boyer wrote on 08/03/2007 09:03:- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
soit, mais ? et ? je ne sais pas répondre à "je ne comprends pas" qui
n'est pas une question ...
si tu comprends polymorphisme seulement par "dynamic binding" alors
(comme sûrement présent dans la FAQ) stricto sensus cela ne concerne
qu'un pointeur (ou une réf.) pas une var. statique;
pour autant ce qui
permet cet appel polymorphe est évidemment également présent dans cette
variable statique;
d'où mon point: le langage est polymorphe, pas telle
ou telle variable selon la façon dont j'y accède.
Marc Boyer wrote on 08/03/2007 09:03:
- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
soit, mais ? et ? je ne sais pas répondre à "je ne comprends pas" qui
n'est pas une question ...
si tu comprends polymorphisme seulement par "dynamic binding" alors
(comme sûrement présent dans la FAQ) stricto sensus cela ne concerne
qu'un pointeur (ou une réf.) pas une var. statique;
pour autant ce qui
permet cet appel polymorphe est évidemment également présent dans cette
variable statique;
d'où mon point: le langage est polymorphe, pas telle
ou telle variable selon la façon dont j'y accède.
Marc Boyer wrote on 08/03/2007 09:03:- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
soit, mais ? et ? je ne sais pas répondre à "je ne comprends pas" qui
n'est pas une question ...
si tu comprends polymorphisme seulement par "dynamic binding" alors
(comme sûrement présent dans la FAQ) stricto sensus cela ne concerne
qu'un pointeur (ou une réf.) pas une var. statique;
pour autant ce qui
permet cet appel polymorphe est évidemment également présent dans cette
variable statique;
d'où mon point: le langage est polymorphe, pas telle
ou telle variable selon la façon dont j'y accède.
Marc Boyer wrote on 08/03/2007 09:03:- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
soit, mais ? et ? je ne sais pas répondre à "je ne comprends pas" qui
n'est pas une question ...
:-)si tu comprends polymorphisme seulement par "dynamic binding" alors
(comme sûrement présent dans la FAQ) stricto sensus cela ne concerne
qu'un pointeur (ou une réf.) pas une var. statique;
Bien. Le terme polymorphisme n'apparaît pas dans la FAQ. Ceci dit,
oui, il me semble qu'il existe un consensus dans la communauté C++
pour associer polymorphisme (dynamique) à "dynamic binding", et,
peut-être de façon moins claire, polymorphisme statique à "template",
et comme je postais sur fclc++, et que je contexte écartait clairement
les templates, je me suis servis de "polymorphisme".
Et dans ma version (française) de TC++PL, oui (§12.2), le
mot polymorphisme est utilisé pour parler du dynamic binding.
Marc Boyer wrote on 08/03/2007 09:03:
- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
soit, mais ? et ? je ne sais pas répondre à "je ne comprends pas" qui
n'est pas une question ...
:-)
si tu comprends polymorphisme seulement par "dynamic binding" alors
(comme sûrement présent dans la FAQ) stricto sensus cela ne concerne
qu'un pointeur (ou une réf.) pas une var. statique;
Bien. Le terme polymorphisme n'apparaît pas dans la FAQ. Ceci dit,
oui, il me semble qu'il existe un consensus dans la communauté C++
pour associer polymorphisme (dynamique) à "dynamic binding", et,
peut-être de façon moins claire, polymorphisme statique à "template",
et comme je postais sur fclc++, et que je contexte écartait clairement
les templates, je me suis servis de "polymorphisme".
Et dans ma version (française) de TC++PL, oui (§12.2), le
mot polymorphisme est utilisé pour parler du dynamic binding.
Marc Boyer wrote on 08/03/2007 09:03:- et à ce titre on parle de
polymorphisme [] pour des types containers
Là, je ne comprends pas.
soit, mais ? et ? je ne sais pas répondre à "je ne comprends pas" qui
n'est pas une question ...
:-)si tu comprends polymorphisme seulement par "dynamic binding" alors
(comme sûrement présent dans la FAQ) stricto sensus cela ne concerne
qu'un pointeur (ou une réf.) pas une var. statique;
Bien. Le terme polymorphisme n'apparaît pas dans la FAQ. Ceci dit,
oui, il me semble qu'il existe un consensus dans la communauté C++
pour associer polymorphisme (dynamique) à "dynamic binding", et,
peut-être de façon moins claire, polymorphisme statique à "template",
et comme je postais sur fclc++, et que je contexte écartait clairement
les templates, je me suis servis de "polymorphisme".
Et dans ma version (française) de TC++PL, oui (§12.2), le
mot polymorphisme est utilisé pour parler du dynamic binding.
