Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Alors, avec quoi est-ce que tu proposes de la remplacer,
Alors, avec quoi est-ce que tu proposes de la remplacer,
Alors, avec quoi est-ce que tu proposes de la remplacer,
Jean-Marc Bourguet wrote:Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Jean-Marc Bourguet wrote:Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
writes:Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
#incluse <iostream>
| >
kanze@gabi-soft.fr writes:
Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
#incluse <iostream>
| >
writes:Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
#incluse <iostream>
| >
Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
"Jean-Marc Bourguet" a écrit dans le message de
news:writes:Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
Cela parait limpide.
Mais, pardonner de revenir sur le sujet, la formulation de Gabriel
Dos Reis : "la fonction est *définie*, mais le code invoque un
fonctionnement indéfini", n'est, alors, pas fondée.
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
news:pxbis7u48dp.fsf@news.bourguet.org...
kanze@gabi-soft.fr writes:
Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
Cela parait limpide.
Mais, pardonner de revenir sur le sujet, la formulation de Gabriel
Dos Reis : "la fonction est *définie*, mais le code invoque un
fonctionnement indéfini", n'est, alors, pas fondée.
"Jean-Marc Bourguet" a écrit dans le message de
news:writes:Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
Cela parait limpide.
Mais, pardonner de revenir sur le sujet, la formulation de Gabriel
Dos Reis : "la fonction est *définie*, mais le code invoque un
fonctionnement indéfini", n'est, alors, pas fondée.
Jean-Marc Bourguet wrote:Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
Pourquoi? p dans B::B() est de type effectif F* (mais this est de type
B*). p->f() vas donc invoquer legalement D_A::f() sur un this de type
F*. Ou vois-tu un alias de this en tant que B*?
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
Pourquoi? p dans B::B() est de type effectif F* (mais this est de type
B*). p->f() vas donc invoquer legalement D_A::f() sur un this de type
F*. Ou vois-tu un alias de this en tant que B*?
Jean-Marc Bourguet wrote:Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
Pourquoi? p dans B::B() est de type effectif F* (mais this est de type
B*). p->f() vas donc invoquer legalement D_A::f() sur un this de type
F*. Ou vois-tu un alias de this en tant que B*?
"Jean-Marc Bourguet" a écrit dans le message de
news:writes:Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
Cela parait limpide.
Mais, pardonner de revenir sur le sujet, la formulation de Gabriel Dos Reis
: "la fonction est *définie*, mais le code
invoque un fonctionnement indéfini", n'est, alors, pas fondée.
PS : je reviens sur le sujet car je ne prendrais pas à la légère une
réflexion provenant de Gabriel Dos Reis.
Même si je pense qu'il s'est
trompé, la valeur du personnage fait que, un doute subsiste.
<CITATION POST PRECEDENT>#incluse <iostream>
| >
| > struct A {
| > virtual void f() = 0;
| > virtual ~A() { f(); }
| > };
| >
| > void A::f() { std::cout << "coucou !n"; }
|
Non. Je n'ai pas raison : la fonction est *définie*, mais le code
invoque un fonctionnement indéfini (la plupart des compilateurs
l'accepteront sur la base du méchanisme d'appel).
</CITATION POST PRECEDENT>
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
news:pxbis7u48dp.fsf@news.bourguet.org...
kanze@gabi-soft.fr writes:
Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
Cela parait limpide.
Mais, pardonner de revenir sur le sujet, la formulation de Gabriel Dos Reis
: "la fonction est *définie*, mais le code
invoque un fonctionnement indéfini", n'est, alors, pas fondée.
PS : je reviens sur le sujet car je ne prendrais pas à la légère une
réflexion provenant de Gabriel Dos Reis.
Même si je pense qu'il s'est
trompé, la valeur du personnage fait que, un doute subsiste.
<CITATION POST PRECEDENT>
#incluse <iostream>
| >
| > struct A {
| > virtual void f() = 0;
| > virtual ~A() { f(); }
| > };
| >
| > void A::f() { std::cout << "coucou !n"; }
|
Non. Je n'ai pas raison : la fonction est *définie*, mais le code
invoque un fonctionnement indéfini (la plupart des compilateurs
l'accepteront sur la base du méchanisme d'appel).
</CITATION POST PRECEDENT>
"Jean-Marc Bourguet" a écrit dans le message de
news:writes:Alors, avec quoi est-ce que tu proposes de la remplacer,
Les fonctions virtuelles pures sont des fonctions virtuelles comme les
autres sauf qu'on n'est pas oblige de les definir et qu'elles
empechent l'instanciation des classent qui en comportent. C'est un
comportement indefini si elles devraient etre executees mais qu'elles
n'ont pas ete definies. Ca me semble simple, pas de regles
particulieres, pas de changement bizarres dans la recherche quand on
passe de virtuel pur a non pur.
Cela parait limpide.
Mais, pardonner de revenir sur le sujet, la formulation de Gabriel Dos Reis
: "la fonction est *définie*, mais le code
invoque un fonctionnement indéfini", n'est, alors, pas fondée.
PS : je reviens sur le sujet car je ne prendrais pas à la légère une
réflexion provenant de Gabriel Dos Reis.
Même si je pense qu'il s'est
trompé, la valeur du personnage fait que, un doute subsiste.
<CITATION POST PRECEDENT>#incluse <iostream>
| >
| > struct A {
| > virtual void f() = 0;
| > virtual ~A() { f(); }
| > };
| >
| > void A::f() { std::cout << "coucou !n"; }
|
Non. Je n'ai pas raison : la fonction est *définie*, mais le code
invoque un fonctionnement indéfini (la plupart des compilateurs
l'accepteront sur la base du méchanisme d'appel).
</CITATION POST PRECEDENT>
Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
Pourquoi? p dans B::B() est de type effectif F* (mais this est de type
B*). p->f() vas donc invoquer legalement D_A::f() sur un this de type
F*. Ou vois-tu un alias de this en tant que B*?
p et this designent le meme objet (le F en cours de construction)
p n'est pas un B (ou une de ses bases)
c'est donc un comportement indefini.
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
Pourquoi? p dans B::B() est de type effectif F* (mais this est de type
B*). p->f() vas donc invoquer legalement D_A::f() sur un this de type
F*. Ou vois-tu un alias de this en tant que B*?
p et this designent le meme objet (le F en cours de construction)
p n'est pas un B (ou une de ses bases)
c'est donc un comportement indefini.
Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:
Pendant l'execution du constructeur et du destructeur, l'objet est du
type de la classe construite (et non de la classe la plus derivee).
Appeler un membre virtuel sur this a un comportement defini: la
fonction sera celle de la classe construite ou de l'ancetre la
fournissant (donc c'est un probleme si elle est pure).
Appeler un membre virtuel a travers d'un alias de this qui n'est pas
du type construit ou d'un de ses descendants est indefini.
Ok.
Pour obtenir cet alias, il faut jouer a l'appenti sorcier avec des
reinterpret_cast, d'ou UB. Ni static_cast, ni dynamic_cast ne permettent
d'obtenir cet d'alias derive de this.
Les alias peuvent provenir de l'appelant. Avec de l'heritage
multiple, ce peut un pointeur sur une base deja contruite passe en
parametre. Pas d'UB ni de jeux dangereux, mais bien qqch qu'on peut
vouloir faire raisonnablement:
struct A {
virtual void f();
};
struct D_A {
virtual void f();
};
struct B {
B(A*p) { p->f(); }
};
struct F: public D_A, B {
F(): B(this) {} // this comme D_A est valide car construit avant
};
Eh non, l'appel virtuel dans B::B() est indefini!
Pourquoi? p dans B::B() est de type effectif F* (mais this est de type
B*). p->f() vas donc invoquer legalement D_A::f() sur un this de type
F*. Ou vois-tu un alias de this en tant que B*?
p et this designent le meme objet (le F en cours de construction)
p n'est pas un B (ou une de ses bases)
c'est donc un comportement indefini.
c'est dans F::F() que tu crees l'alias en appellant B::B() avec deux
this avec deux types statiques differents mais le meme type
effectif. Donc p->f() invoque un B::f() qui n'exite pas. Bien vu,
ceci dit tu n'as pas besoin de l'heritage multiple pour avoir le UB:
struct A {
A(A*p) { p->f(); } // invoque A::f(p), Ok mais pas voulu
virtual void f();
};
struct D : A {
D(): A(this) {} // alias
virtual void f();
};
Ce code marchera (contraitement a ton exemple qui met bien les point
sur les 'i' ;-), mais je pense que la norme lui attribue quand meme
un UB, p etant un alias sur D* mais de type effectif A* au meme
titre que this...
c'est dans F::F() que tu crees l'alias en appellant B::B() avec deux
this avec deux types statiques differents mais le meme type
effectif. Donc p->f() invoque un B::f() qui n'exite pas. Bien vu,
ceci dit tu n'as pas besoin de l'heritage multiple pour avoir le UB:
struct A {
A(A*p) { p->f(); } // invoque A::f(p), Ok mais pas voulu
virtual void f();
};
struct D : A {
D(): A(this) {} // alias
virtual void f();
};
Ce code marchera (contraitement a ton exemple qui met bien les point
sur les 'i' ;-), mais je pense que la norme lui attribue quand meme
un UB, p etant un alias sur D* mais de type effectif A* au meme
titre que this...
c'est dans F::F() que tu crees l'alias en appellant B::B() avec deux
this avec deux types statiques differents mais le meme type
effectif. Donc p->f() invoque un B::f() qui n'exite pas. Bien vu,
ceci dit tu n'as pas besoin de l'heritage multiple pour avoir le UB:
struct A {
A(A*p) { p->f(); } // invoque A::f(p), Ok mais pas voulu
virtual void f();
};
struct D : A {
D(): A(this) {} // alias
virtual void f();
};
Ce code marchera (contraitement a ton exemple qui met bien les point
sur les 'i' ;-), mais je pense que la norme lui attribue quand meme
un UB, p etant un alias sur D* mais de type effectif A* au meme
titre que this...
