Discussion :

[oodini]

Bonjour,

Soit la classe suivante :

Code :

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

1
2
3
4
5
6
7
class A
{
    ....
    virtual void f();
    virtual void g() = 0;
    ....
};

Etant entendu que A n'est pas instanciable, est-il possible d'avoir :

Code :

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

1
2
3
4
5
6
void A::f()
{
    ....
    g();
    ....
}

La fonction f étant appelée par les classes dérivées de A, qui elles ont implémenté g.

Merci.

[dtrosset]

Oui

[stillman]

C'est tout à fait possible. Cela permet par exemple de définir un algorithme général dont certaines étapes sont définies par les classes dérivées (google Template Method Pattern).

[poukill]

+1.
Exact c'est la base du Template Method...
Le seul problème qu'il peut y avoir, c'est que tu ne peux pas appeler de fonctions virtuelles PURES dans ton constructeur. Sur une fonction membre comme dans ton exemple c'est OK...

EDIT : ajout du mot PURE

[3DArchi]

Le seul problème qu'il peut y avoir, c'est que tu ne peux pas appeler de fonctions virtuelles dans ton constructeur.

Pour la même raison, vaut mieux éviter aussi dans le destructeur.
P.S.: j'ai juste une question. Quand on se pose un pb comme celui là, le meilleur moyen de le résoudre n'est-il pas encore de faire une petite appli pour vérifier le comportement du compilo et l'exécution?

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
 
#include <iostream>
class A{
public:
 virtual void f()
   {
      g();
   }
   virtual void g()=0;
};
class B: public A
{
public:
  void g(){std::cout<<"B::g";}
};
int main()
{
 B b;
 b.f();
}

Ca prend 3 minutes et on a la réponse.

[oodini]

Merci à tous, notamment de m'avoir informé de l'existence du patron template method. Je suis à présent le nez dans le bouquin des GOF pour approndir la chose.

Faudrait que je le lise une bonne fois pour toute, mais je lis déjà le Stroustrup chez moi et les Scott Meyers dans le métro (ça rentre par un oeil et ça sort par l'autre...).

PS à 3DArchi : Tu as raison. J'ai péché par flemme et je m'en excuse.

[poukill]

P.S.: j'ai juste une question. Quand on se pose un pb comme celui là, le meilleur moyen de le résoudre n'est-il pas encore de faire une petite appli pour vérifier le comportement du compilo et l'exécution?
Ca prend 3 minutes et on a la réponse.

Oui, sauf que des fois c'est bien de comprendre pourquoi. Et étant donné le large panel de compilateur qui donne des choses parfois très différentes à la compilation !!

[3DArchi]

Oui, sauf que des fois c'est bien de comprendre pourquoi. Et étant donné le large panel de compilateur qui donne des choses parfois très différentes à la compilation !!

Sur le principe d'accord, mais pour une question aussi simple, j'ai des doutes. Et puis, à ce moment, la question serait 'pourquoi ça marche?' et non 'est-ce que ça marche?'

[poukill]

C'est pas faux... Mais quand ça marche, commet savoir que ça ne devrait pas marcher ?

[3DArchi]

C'est pas faux... Mais quand ça marche, commet savoir que ça ne devrait pas marcher ?

En évitant la pensée magique. Soit tu sais pourquoi ça marche (même si ton raisonnement peut être faux), et tu ne te poses plus de questions, soit tu ne comprend pas pourquoi ça marche, et là c'est intéressant de savoir.

[Davidbrcz]

+1.
Exact c'est la base du Template Method...
Le seul problème qu'il peut y avoir, c'est que tu ne peux pas appeler de fonctions virtuelles dans ton constructeur. Sur une fonction membre comme dans ton exemple c'est OK...

C'est moyennenmant vrai.
Il est possible d'appeler des fonctions virtuelles dans le constructeur (ou dans le destructeur), mais c'est la résolution statique des liens qui aura lieu ( comprendre que le polymorphisme ne marchera pas).

Par contre, il est formellement interdit d'appeler une fonction virtuelle pure dans le constructeur (ou dans le destructeur). De mémoire, g+= refuse de compiler un tel code et ca ne me choquerai pas que cela soit un UB.

Edit: j'ai retrouvé la justification:
Citation : Norme C++ (10.4)

Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a virtual call (10.3) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undefined.

[nicroman]

C'est moyennenmant vrai.
Il est possible d'appeler des fonctions virtuelles dans le constructeur (ou dans le destructeur), mais c'est la résolution statique des liens qui aura lieu ( comprendre que le polymorphisme ne marchera pas).

En fait... pas vraiment... exemple:

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
 
class A
{
    void doIt();
    virtual void f() = 0;
};
 
class B
{
    B();
    virtual void f();
};
 
void A::doIt()
{
    f();
}
 
B::B()
{
    doIt();   // <= va bien appeler B::f();
}

En fait... pendant le contructeur de B (ou son destructeur), l'objet est de type "B" (même si c'est un C qui est créé).

Par contre, il est formellement interdit d'appeler une fonction virtuelle pure dans le constructeur (ou dans le destructeur). De mémoire, g+= refuse de compiler un tel code et ca ne me choquerai pas que cela soit un UB.

La encore... ca dépend...
La fonction virtuelle pure peut très bien avoir une implémentation !
Le "= 0" signifiant "doit être overridé".

[poukill]

C'est moyennenmant vrai.
Il est possible d'appeler des fonctions virtuelles dans le constructeur (ou dans le destructeur), mais c'est la résolution statique des liens qui aura lieu ( comprendre que le polymorphisme ne marchera pas).

+1.
OUUlà mince. Au temps pour moi.
Effectivement, je me souviens qu'on peut appeler une méthode virtuelle dans un constructeur... Par contre, je me souviens aussi que ce n'étais pas conseillé... Je viens de vérifier dans Standard de programmation en C++ (Sutter et Alexandrescu) )