Discussion :

[kidpaddle2]

Bonjour,

Je viens de synthétiser mon code en créant une classe Thread comme suit :

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
class Thread {
protected:
    boost::thread *m_thread;
 
    virtual void work() = 0;
 
public:
    Thread() : m_thread(NULL) {}
    virtual ~Thread() {
        catch_up();
        delete m_thread;
    }
 
    inline void catch_up() {
        if(m_thread != NULL) {
            m_thread->join();
        }
    }
 
    void run() {
        m_thread = new boost::thread(boost::bind(&Thread::work, boost::ref(*this)));
    }
};

Deux classes en héritent publiquement et implémentent la méthode virtuelle work().
En transférant des données de l'une à l'autre (les méthodes work() touchent aux données échangées), je me retrouve avec un runtime terminated à cause d'un appel à une méthode virtuelle pure. Je n'en ai qu'une, cela vient donc de work(), mais pourquoi diable appelleraient-ils Thread::work() au lieu de l'implémentation ?

Edit: Visiblement il y a une affaire de temps derrière... C'est assez aléatoire.

Merci d'avance.

Cordialement,

Kidpaddle2

[Médinoc]

Je suppose qu'il n'y a aucun risque que run() soit appelée pendant un constructeur ou un desctructeur?

[bacelar]

"pure method called"
La Vtable (table des méthodes virtuelles) contient NULL pour la méthode virtuelle appelée. Classiquement, les compilateurs ne remplissent pas la Vtable avant la fin du constructeur de la classe fille, donc un appel de méthode virtuelle dans un constructeur pose en problème car la Vtable n'est pas initialisé.

Dans le destructeur, c'est pareil.

[kidpaddle2]

Merci de vos réponses, mais le problème, c'est que je ne l'appelle pas dans le constructeur...

J'instancie mes classes dérivées avec le constructeur par défaut, et j'appelle leurs méthodes run() à la suite. D'ailleurs c'est bizarre parce qu'en déboggage, il ne me marque un autre thread d'actif uniquement après le deuxième run()...

Edit: "Ya pas", en ne mettant que le code suivant, cela fait pareil... Un problème au niveau de la conception, mais où ?

Code :

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

1
2
3
4
5
6
classe A : public Thread {
    void work() {}
};
//Et dans le main :
A a;
a.run();

[3DArchi]

"pure method called"
La Vtable (table des méthodes virtuelles) contient NULL pour la méthode virtuelle appelée.

En fait, il existe différente stratégies et en particulier un pointeur vers une fonction d'erreur appropriée (Quelle entrée pour les fonctions virtuelles pures ?).

Classiquement, les compilateurs ne remplissent pas la Vtable avant la fin du constructeur de la classe fille, donc un appel de méthode virtuelle dans un constructeur pose en problème car la Vtable n'est pas initialisé.

La vtable est construite à la compilation pour chacune des classes contenant des fonctions virtuelles. Ensuite, le vpointeur est initialisé juste avant l'entrée du constructeur pour référencer la table de la classe en cours de construction.

Dans le destructeur, c'est pareil.

La seule chose que dit la norme, c'est que dans le constructeur/destructeur la fonction virtuelle appelée est celle de la classe en train d'être construite/détruite. Conséquence : certains appels dans le constructeur/destructeur de fonctions virtuelles n'utilisent pas les vtables. (Les appels de fonctions virtuelles pures dans leur classe abstraite est un comportement indéterminé.). Cf tuto Les fonctions virtuelles en C++.


@kidpaddle2 : héritage == sémantique d'entité == pas de copie :

Code :

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

class Thread : private boost::noncopyable

Le cas que je vois pour expliquer ton erreur est que le destructeur a été déroulé et donc le vpointeur désigne la vtable de la classe abstraite. Bref, un problème de durée de vie de variable.

[3DArchi]

En fait, tu penses te prémunir contre la destruction de la variable avant la fin du thread en faisant un join dans le destructeur de Thread. Mais c'est une erreur. Car à ce moment, les destructeurs des classes dérivées ont été déroulés et le vpointeur pointe sur la vtable de Thread. Donc le thread tente d'exécuter le work de Thread qui est une fonction virtuelle pure (et dont l'entrée n'est pas NULL mais vers la fonction d'erreur qui t'affiche le message 'pure function called'.
Dit autrement, la fin d'exécution du thread ne doit pas être une post-condition de ~Thread mais une précondition. Quand tu arrives dans ce destructeur, le thread doit être terminé.