Discussion :

[ram-0000]

Bonjour,

Dans le code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
class CTest
{
public:
	CTest();
	~CTest();
	virtual void MaFonction(void) = 0;
};
 
CTest::CTest() { }
CTest::~CTest() { }
void CTest::MaFonction(void) { }

Je déclare la classe CTest avec une fonction virtuelle pure (la fonction MaFonction) mais le compilateur me laisse créer une implémentation de cette fonction. Par contre, lorsque j'essaye d'instancier cette classe de base, le compilateur génère une erreur normale "error C2259: 'CTest'*: impossible d'instancier une classe abstraite"

Quel sens cela peut-il avoir de déclarer dans la classe de base un fonction virtuelle pure ET d'avoir une implémentation de cette fonction aussi dans la classe de base.

Comment se comportent les autres compilateurs (je suis sur Visual Studio 2005 C++ en niveau de warning le plus élevé)

Merci de vos réponses

[Alp]

En principe, les autres se comporteront pareil je crois.

Par la création d'une fonction virtuelle _pure_, tu empêches la classe d'être instanciée.
En donnant une implémentation toutefois, tu fournis un comportement par défaut pour cette fonction utilisable dans les classes filles.

Il me semble que ça se passe comme ça.

[Florian Goo]

Bonjour,

Comportement identique avec GCC 4.4(svn), niveau de warning maximum.

Que je déclare (sans la définir) CTestFille::MaFonction() ou non, c'est soit undefined reference, soit impossible d'instancier car fonction virtuelle pure.
Par contre, si je fais ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#include <iostream>
 
class CTest
{
public:
	CTest();
	~CTest();
	virtual void MaFonction(void) = 0;
};
 
CTest::CTest() { }
CTest::~CTest() { }
void CTest::MaFonction(void)
{
	std::cout << "yeah" << std::endl;
}
 
 
 
struct CTest2: public CTest
{
	void MaFonction(void);
};
 
void CTest2::MaFonction(void)
{
	CTest::MaFonction();
}
 
 
int main()
{
	CTest2 t;
	t.MaFonction();
 
	return 0;
}

On a bien la sortie attendue

[3DArchi]

En principe, les autres se comporteront pareil je crois.

Par la création d'une fonction virtuelle _pure_, tu empêches la classe d'être instanciée.
En donnant une implémentation toutefois, tu fournis un comportement par défaut pour cette fonction utilisable dans les classes filles.

Il me semble que ça se passe comme ça.

C'est ça: ce sont deux notions séparées. Virtuelle pure implique que non instanciable et forcément redéfinie par une classe fille instanciable.
Par contre, rien n'empêche de fournir un comportement. Plutôt qu'un comportement par défaut qui laisserait entendre que la classe fille ne se contente que d'appeler la méthode parente, je dirais un comportement de base factorisé. Mais j'avoue que je ne vois pas trop d'exemple où cela se justifie et qui rendrait une autre solution moins appropriée.

[Alp]

C'est le genre de trucs qui peut servir lorsque l'on est amené à passer des tests lors d'un entretien... En pratique, je n'ai jamais vu un cas ou c'était la seule solution. Ca existe peut-être qui sait.

[Jean-Marc.Bourguet]

Alp, il y a presque toujours l'alternative de fournir un membre ayant le comportement qui aurait ete donne a l'implementation de la classe virtuelle pure. Mais il y a un cas ou c'est impossible: quand on veut rendre le destructeur virtuel pur. Ce cas est rare -- ca m'est arrive une fois me semble-t'il: la decision de la maniere dont il fallait disposer d'une ressource etait deleguee aux descendants de la classe de base. On ne pouvait pas utiliser une fonction virtuelle pure autre que le destructeur -- durant l'execution d'un destructeur le type dynamique est le type statique.

[3DArchi]

Mais il y a un cas ou c'est impossible: quand on veut rendre le destructeur virtuel pur.

++

[ram-0000]

C'est ça: ce sont deux notions séparées. Virtuelle pure implique que non instanciable et forcément redéfinie par une classe fille instanciable.
Par contre, rien n'empêche de fournir un comportement. Plutôt qu'un comportement par défaut qui laisserait entendre que la classe fille ne se contente que d'appeler la méthode parente, je dirais un comportement de base factorisé. Mais j'avoue que je ne vois pas trop d'exemple où cela se justifie et qui rendrait une autre solution moins appropriée.

Donc cela veut dire que la classe fille à la droit (et même doit) d'appeler la classe mère pour la gestion de certains "trucs" factorisés par la classe mère. Il faut alors bien indiquer dans la documentation classe mere que la fonction DOIT appeler la fonction de classe fille.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
class CMere
{
   public:
   virtual void MaFonction(void) = 0;  // fonction virtuelle pure mais définie. Cette fonction doit impérativement être appelée par la fonction MaFonction() de toute classe mère 
};
void CMere::MaFonction(void)
{
   // code de la classe CMere
   ...
}
 
class CFille : public CMere
{
   public:
   virtual void MaFonction(void);
};
 
void CFille::MaFonction(void)
{
   // code de la classe CFille
   ...
   CMere::MaFonction();
   ...
}

[3DArchi]

Donc cela veut dire que la classe fille à la droit (et même doit) d'appeler la classe mère pour la gestion de certains "trucs" factorisés par la classe mère. Il faut alors bien indiquer dans la documentation classe mere que la fonction DOIT appeler la fonction de classe fille.

C'est bien pour ça (en dehors du cas brillamment cité par Jean-Marc) lorsque tu fait ça, c'est que tu as un problème de conception.

Tu peux souvent remplacer ta fonction virtuelle (MaMethodeVirtuelle) pure par quelque chose comme ça:
MaMethode (non virtuelle):
1/Pre-condition (non virtuelle)
2/MaMethodeVirtuellePureSansCode
3/Post-condition (non virtuelle)

[bafman]

au boulot on a un cas d'utilisation ou c'est pratique pour verifier qu'une hierarchie d'appel est bien effectué.

de memoire, c'est un truc du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
class BaseClass
{
    bool BaseClassFonctionAppelee;
private:
    virtual void FonctionAppeleLorsDunChargement() = 0
    { 
        BaseClassFonctionAppelee = true;
    }
public:
    void chargement()
    {
        BaseClassFonctionAppelee  = false;
        FonctionAppeleLorsDunChargement();
        Assert(BaseClassFonctionAppelee );
    }
}
 
class SousClass : public BaseClass
{
private:
   virtual void FonctionAppeleLorsDunChargement() 
    { 
        BaseClass::FonctionAppeleLorsDunChargement();
        // initialise des donnée
    }
}

c'est pour une structure d'objets dynamiques qui a besoin d'être initialisé de la même façon qu'avec des constructeurs.
Avec ça, on peut vérifier que les sous classe appellent bien le "constructeur" de la classe parente, et en même temps, on la force à redéfinir ce constructeur...

bon, ce n'est pas le cas d'utilisation ultime de cette feature du C++, on aurait probablement pu l'implémenter sans, mais c'est bien pratique quand même

[3DArchi]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
class SousSousClass : public SousClass
{
private:
   virtual void FonctionAppeleLorsDunChargement() 
    { 
        BaseClass::FonctionAppeleLorsDunChargement();
        // initialise des donnée
       // Mais n'a pas appele SousClass::FonctionAppeleLorsDunChargement()
    }
}

[bafman]

en fait, on fait plutôt ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
class SousClass : public BaseClass
{
    typedef BaseClass parent_type;
    virtual void VirtualFunc()
    {
        parent_type::VirtualFunc();
    }
}
 
class SousSousClass : public SousClass
{
    typedef SousClass parent_type;
    virtual void VirtualFunc()
    {
        parent_type::VirtualFunc();
    }
}

mais bien entendu, tout ceci est géré automatiquement via des macro et autre qui nous permettent de définir le type RTTI dynamique de l'objet...

bref, ceci n'est pas le propos de ce post, c'était juste un exemple d'utilisation de l'implémentation d'une fonction virtuelle pure

[3DArchi]

En fait, ce que je voulais dire, c'est que rien n'empêche de trapper un étage en remontant les appels. Je pense que quelque chose comme ça

1/Pre-condition (non virtuelle)
2/MaMethodeVirtuellePureSansCode
3/Post-condition (non virtuelle)

c'est moins bancal. T'es assuré de toujours remonter à ta classe de base.

[stillman]

Dans le GotW #31, Herb Sutter évoque ce sujet. Pour résumer, il distingue trois cas où cela peut être utile :
- Destructeur virtuel pur : la classe doit être abstraite, mais aucune de ces méthodes ne peut être virtuelle pure (ça n'aurait pas de sens) --> on met le destructeur en virtuel pur, mais il doit tout de même être implémenté.

- Forcer l'explicitation de l'utilisation d'un comportement par défaut : on implémente une méthode virtuelle, afin de représenter un comportement par défaut, mais on oblige les classes dérivées à indiquer explicitement qu'elles utilisent ce comportement.
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
struct Base
{
    virtual void foo() const = 0;
};
 
void Base::foo() const { std::cout << "Comportement par défaut"; }
 
struct Derivee : public Base
{
    virtual void foo() const { Base::foo(); } //utilise le comportement par défaut
};

- Dernier cas, plus anecdotique : obtenir des messages d'erreurs plus significatifs lorsqu'on invoque par "accident" une méthode virtuelle pure