"Seb" a écrit >Je l'ai testé avec le compilateur Borland C++ 5.5. Le résultat est :
ABCAAA, puis ABCAAC
VC6 et VC7 donnent ABCAAC dans les deux cas , ce qui signifie que la
méthode de C herite de l'attribut "virtual", et sauf erreur c'est le
comportement prévu par le standard.
Ce qui m'étonne plus, c'est que B puisse définir une méthode du même
nom en static, je savais pas que c'était permis, et à mon avis très
ambigu...
"Seb" a écrit >
Je l'ai testé avec le compilateur Borland C++ 5.5. Le résultat est :
ABCAAA, puis ABCAAC
VC6 et VC7 donnent ABCAAC dans les deux cas , ce qui signifie que la
méthode de C herite de l'attribut "virtual", et sauf erreur c'est le
comportement prévu par le standard.
Ce qui m'étonne plus, c'est que B puisse définir une méthode du même
nom en static, je savais pas que c'était permis, et à mon avis très
ambigu...
"Seb" a écrit >Je l'ai testé avec le compilateur Borland C++ 5.5. Le résultat est :
ABCAAA, puis ABCAAC
VC6 et VC7 donnent ABCAAC dans les deux cas , ce qui signifie que la
méthode de C herite de l'attribut "virtual", et sauf erreur c'est le
comportement prévu par le standard.
Ce qui m'étonne plus, c'est que B puisse définir une méthode du même
nom en static, je savais pas que c'était permis, et à mon avis très
ambigu...
"Christophe Lephay" a écrit dans leJe pense qu'il y a des cas où le fait de rajouter virtual est utile,
notemment si la classe dont tu hérites (héritant elle même de la
classe de base déclarant les fonctions virtuelles) définit une
nouvelle interface (en rajoutant son lot de nouvelles fonctions
virtuelles, voire en en déplaçant certaines en private), mais je
pense que ce cas n'est pas suffisemment général pour imposer la
répétition du virtual dans toutes les classes dérivées...
class A {
public:
virtual void f() { cout << "Fonction de A" << endl; }
};
class B : public A
{
public:
static void f() { cout << "Fonction de B" << endl; }
};
class C : public B
{
public:
void f() { cout << "Fonction de C" << endl; }
};
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
Je pense qu'il y a des cas où le fait de rajouter virtual est utile,
notemment si la classe dont tu hérites (héritant elle même de la
classe de base déclarant les fonctions virtuelles) définit une
nouvelle interface (en rajoutant son lot de nouvelles fonctions
virtuelles, voire en en déplaçant certaines en private), mais je
pense que ce cas n'est pas suffisemment général pour imposer la
répétition du virtual dans toutes les classes dérivées...
class A {
public:
virtual void f() { cout << "Fonction de A" << endl; }
};
class B : public A
{
public:
static void f() { cout << "Fonction de B" << endl; }
};
class C : public B
{
public:
void f() { cout << "Fonction de C" << endl; }
};
"Christophe Lephay" a écrit dans leJe pense qu'il y a des cas où le fait de rajouter virtual est utile,
notemment si la classe dont tu hérites (héritant elle même de la
classe de base déclarant les fonctions virtuelles) définit une
nouvelle interface (en rajoutant son lot de nouvelles fonctions
virtuelles, voire en en déplaçant certaines en private), mais je
pense que ce cas n'est pas suffisemment général pour imposer la
répétition du virtual dans toutes les classes dérivées...
class A {
public:
virtual void f() { cout << "Fonction de A" << endl; }
};
class B : public A
{
public:
static void f() { cout << "Fonction de B" << endl; }
};
class C : public B
{
public:
void f() { cout << "Fonction de C" << endl; }
};
Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me disais
que
le static void f() générait "une autre méthode de même nom et de même
signature" (si tant est que cela signifie quelque chose) et que donc
lorsque
je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne fait
que
surcharger celle de B (compliqué mais ça semblait tenir la route).
Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me disais
que
le static void f() générait "une autre méthode de même nom et de même
signature" (si tant est que cela signifie quelque chose) et que donc
lorsque
je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne fait
que
surcharger celle de B (compliqué mais ça semblait tenir la route).
Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me disais
que
le static void f() générait "une autre méthode de même nom et de même
signature" (si tant est que cela signifie quelque chose) et que donc
lorsque
je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne fait
que
surcharger celle de B (compliqué mais ça semblait tenir la route).
"Seb" a écrit:Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me
disais que le static void f() générait "une autre méthode de même
nom et de même signature" (si tant est que cela signifie quelque
chose) et que donc lorsque je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne
fait que surcharger celle de B (compliqué mais ça semblait tenir la
route).
oui, ça tient la route si on considère qu'avec BC++5.1 le C::f
surcharge le B::f, ce qui fait que tous les accès via le pointeur
aboutissent sur A::f (résultat AAA), alors qu'avec VC6et7, le C::f
surcharge la méthode virtuelle A::f, ce qui fait que l'accès par les
pointeurs aboutit bien sur AAC. Je ne sais pas quel comportement est
le "bon"...
Essaie
1) d'enlever le "static" sur ton BC++ pour voir : sur VC6/7 on
obtient alors ABCABC ce qui serait à mon sens le comportement espéré.
2) d'enlever ensuite le "virtual" de la méthode A::f. Ici j'ai ABCAAA
ce qui est aussi logique
3) d'ajouter ensuite "virtual" à la méthode B::f. Ici j'ai encore
ABCAAA et ça me scie parce que j'étais persuadé que ça faisait une
erreur de compil de définir une fonction virtual de même prototype
qu'une fonction héritée pas virtuelle...
"Seb" a écrit:
Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me
disais que le static void f() générait "une autre méthode de même
nom et de même signature" (si tant est que cela signifie quelque
chose) et que donc lorsque je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne
fait que surcharger celle de B (compliqué mais ça semblait tenir la
route).
oui, ça tient la route si on considère qu'avec BC++5.1 le C::f
surcharge le B::f, ce qui fait que tous les accès via le pointeur
aboutissent sur A::f (résultat AAA), alors qu'avec VC6et7, le C::f
surcharge la méthode virtuelle A::f, ce qui fait que l'accès par les
pointeurs aboutit bien sur AAC. Je ne sais pas quel comportement est
le "bon"...
Essaie
1) d'enlever le "static" sur ton BC++ pour voir : sur VC6/7 on
obtient alors ABCABC ce qui serait à mon sens le comportement espéré.
2) d'enlever ensuite le "virtual" de la méthode A::f. Ici j'ai ABCAAA
ce qui est aussi logique
3) d'ajouter ensuite "virtual" à la méthode B::f. Ici j'ai encore
ABCAAA et ça me scie parce que j'étais persuadé que ça faisait une
erreur de compil de définir une fonction virtual de même prototype
qu'une fonction héritée pas virtuelle...
"Seb" a écrit:Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me
disais que le static void f() générait "une autre méthode de même
nom et de même signature" (si tant est que cela signifie quelque
chose) et que donc lorsque je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne
fait que surcharger celle de B (compliqué mais ça semblait tenir la
route).
oui, ça tient la route si on considère qu'avec BC++5.1 le C::f
surcharge le B::f, ce qui fait que tous les accès via le pointeur
aboutissent sur A::f (résultat AAA), alors qu'avec VC6et7, le C::f
surcharge la méthode virtuelle A::f, ce qui fait que l'accès par les
pointeurs aboutit bien sur AAC. Je ne sais pas quel comportement est
le "bon"...
Essaie
1) d'enlever le "static" sur ton BC++ pour voir : sur VC6/7 on
obtient alors ABCABC ce qui serait à mon sens le comportement espéré.
2) d'enlever ensuite le "virtual" de la méthode A::f. Ici j'ai ABCAAA
ce qui est aussi logique
3) d'ajouter ensuite "virtual" à la méthode B::f. Ici j'ai encore
ABCAAA et ça me scie parce que j'étais persuadé que ça faisait une
erreur de compil de définir une fonction virtual de même prototype
qu'une fonction héritée pas virtuelle...
"Seb" a écrit:Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me
disais que le static void f() générait "une autre méthode de même
nom et de même signature" (si tant est que cela signifie quelque
chose) et que donc lorsque je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne
fait que surcharger celle de B (compliqué mais ça semblait tenir la
route).
oui, ça tient la route si on considère qu'avec BC++5.1 le C::f
surcharge le B::f, ce qui fait que tous les accès via le pointeur
aboutissent sur A::f (résultat AAA), alors qu'avec VC6et7, le C::f
surcharge la méthode virtuelle A::f, ce qui fait que l'accès par les
pointeurs aboutit bien sur AAC. Je ne sais pas quel comportement est
le "bon"...
Essaie
1) d'enlever le "static" sur ton BC++ pour voir : sur VC6/7 on
obtient alors ABCABC ce qui serait à mon sens le comportement espéré.
2) d'enlever ensuite le "virtual" de la méthode A::f. Ici j'ai ABCAAA
ce qui est aussi logique
3) d'ajouter ensuite "virtual" à la méthode B::f. Ici j'ai encore
ABCAAA et ça me scie parce que j'étais persuadé que ça faisait une
erreur de compil de définir une fonction virtual de même prototype
qu'une fonction héritée pas virtuelle...
"Seb" a écrit:
Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me
disais que le static void f() générait "une autre méthode de même
nom et de même signature" (si tant est que cela signifie quelque
chose) et que donc lorsque je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne
fait que surcharger celle de B (compliqué mais ça semblait tenir la
route).
oui, ça tient la route si on considère qu'avec BC++5.1 le C::f
surcharge le B::f, ce qui fait que tous les accès via le pointeur
aboutissent sur A::f (résultat AAA), alors qu'avec VC6et7, le C::f
surcharge la méthode virtuelle A::f, ce qui fait que l'accès par les
pointeurs aboutit bien sur AAC. Je ne sais pas quel comportement est
le "bon"...
Essaie
1) d'enlever le "static" sur ton BC++ pour voir : sur VC6/7 on
obtient alors ABCABC ce qui serait à mon sens le comportement espéré.
2) d'enlever ensuite le "virtual" de la méthode A::f. Ici j'ai ABCAAA
ce qui est aussi logique
3) d'ajouter ensuite "virtual" à la méthode B::f. Ici j'ai encore
ABCAAA et ça me scie parce que j'étais persuadé que ça faisait une
erreur de compil de définir une fonction virtual de même prototype
qu'une fonction héritée pas virtuelle...
"Seb" a écrit:Alors là je suis perdu : Dans mon cas ou j'obtiens ABCAAA, je me
disais que le static void f() générait "une autre méthode de même
nom et de même signature" (si tant est que cela signifie quelque
chose) et que donc lorsque je fais
x = &c;
x->f();
J'appel f virtuel car le f de B est une "nouvelle fonction" et C ne
fait que surcharger celle de B (compliqué mais ça semblait tenir la
route).
oui, ça tient la route si on considère qu'avec BC++5.1 le C::f
surcharge le B::f, ce qui fait que tous les accès via le pointeur
aboutissent sur A::f (résultat AAA), alors qu'avec VC6et7, le C::f
surcharge la méthode virtuelle A::f, ce qui fait que l'accès par les
pointeurs aboutit bien sur AAC. Je ne sais pas quel comportement est
le "bon"...
Essaie
1) d'enlever le "static" sur ton BC++ pour voir : sur VC6/7 on
obtient alors ABCABC ce qui serait à mon sens le comportement espéré.
2) d'enlever ensuite le "virtual" de la méthode A::f. Ici j'ai ABCAAA
ce qui est aussi logique
3) d'ajouter ensuite "virtual" à la méthode B::f. Ici j'ai encore
ABCAAA et ça me scie parce que j'étais persuadé que ça faisait une
erreur de compil de définir une fonction virtual de même prototype
qu'une fonction héritée pas virtuelle...
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
--
Philippe Guglielmetti - www.dynabits.com
Look at these few lines of code:
class A { public: virtual void f() { cout << "A";}};
class B : public A{public: static void f() { cout << "B"; }};
class C : public B{public: void f() { cout << "C"; }}; // virtual or not ?
that's the question...
A* x; A a; B b; C c;
a.f(); b.f(); c.f();
x = &a; x->f(); x = &b; x->f(); x = &c; x->f();
Borland C++ 5.5 outputs "ABCAAA"
MS VC6 and 7 give "ABCAAC"
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
--
Philippe Guglielmetti - www.dynabits.com
Look at these few lines of code:
class A { public: virtual void f() { cout << "A";}};
class B : public A{public: static void f() { cout << "B"; }};
class C : public B{public: void f() { cout << "C"; }}; // virtual or not ?
that's the question...
A* x; A a; B b; C c;
a.f(); b.f(); c.f();
x = &a; x->f(); x = &b; x->f(); x = &c; x->f();
Borland C++ 5.5 outputs "ABCAAA"
MS VC6 and 7 give "ABCAAC"
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
--
Philippe Guglielmetti - www.dynabits.com
Look at these few lines of code:
class A { public: virtual void f() { cout << "A";}};
class B : public A{public: static void f() { cout << "B"; }};
class C : public B{public: void f() { cout << "C"; }}; // virtual or not ?
that's the question...
A* x; A a; B b; C c;
a.f(); b.f(); c.f();
x = &a; x->f(); x = &b; x->f(); x = &c; x->f();
Borland C++ 5.5 outputs "ABCAAA"
MS VC6 and 7 give "ABCAAC"
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
Philippe Guglielmetti wrote:J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
D'après ma compréhension de la norme, le code en question n'est pas
valide.
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
--
Loïc
Philippe Guglielmetti wrote:
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
D'après ma compréhension de la norme, le code en question n'est pas
valide.
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
--
Loïc
Philippe Guglielmetti wrote:J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
D'après ma compréhension de la norme, le code en question n'est pas
valide.
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
--
Loïc
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
n'est pas clair, car les méthodes non statiques ont un paramètre (this)
"Loïc Joly" a écrit dans le message news:
bn6g9j$gij$Philippe Guglielmetti wrote:J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
D'après ma compréhension de la norme, le code en question n'est pas
valide.
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
--
Loïc
Effectivement : Le code ne devrait pas être valide ...
Sébastien
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
n'est pas clair, car les méthodes non statiques ont un paramètre (this)
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
bn6g9j$gij$1@news-reader2.wanadoo.fr...
Philippe Guglielmetti wrote:
J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
D'après ma compréhension de la norme, le code en question n'est pas
valide.
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
--
Loïc
Effectivement : Le code ne devrait pas être valide ...
Sébastien
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
n'est pas clair, car les méthodes non statiques ont un paramètre (this)
"Loïc Joly" a écrit dans le message news:
bn6g9j$gij$Philippe Guglielmetti wrote:J'aimerais vraiment savoir ce que la norme dit à ce sujet ...
Moi aussi, alors j'ai posté la question sur comp.lang.c++,
copie ci-dessous pour ne pas heurter les toubonistes...
D'après ma compréhension de la norme, le code en question n'est pas
valide.
9.4.1 Static member functions
[...] A static member function shall not be virtual. There shall not be
a static and a nonstatic member function with the same name and the same
parameter types (13.1).
--
Loïc
Effectivement : Le code ne devrait pas être valide ...
Sébastien
