[pure virtual call] erreur d'execution

salut,

je comprend pas trop, mais mon code plante sur un polymorphisme.
Soit 3 lasses. La première est abstraite et contient une methode virtuelle pure. Et les deux autre classe hérite de la première implemente cette methode virtuelle. Mais lors de l'appelle à cette methode ( l'appel est fait dans la classe abstraite), je tombe jamais dans le code d'une des classe fille. Ca me plante mon programme. Le debugger me dit : R6025 Pure virtual function call.

des idées ?

Tu ne ferais pas cet appel dans le constructeur de la classe de base des fois?
Ça se n'est pas possible, car dans le constructeur de la classe de base this n'est pas construit pour le type dérivé.

SInon pense bien a appeller cette méthode virtuelle sur this...

C'est ce que je me disais, mais l'appel à un constructeur contenant une fonction virtuelle pure ne devrait pas passer la compilation... a priori :?

Si ça passe.

Autre cas de figure:
- un thread vent de détruire ton objet,
- un second accède ensuite à une fonction virtuelle de l'objet

Citation:

---

Envoyé par Luc Hermitte

Si ça passe.

---

Au temps pour moi. :oops: En y pensant, j'avais déjà eu le problème. Honte à moi!
Donc en monothread, c'est bien ça... Surtout pas d'appel à une fonction virtuelle pure dans un constructeur, l'objet dérivé n'existe pas encore, comme l'a déjà fait remarqué MatRem.

Je réponds un peu tard mais je viens d'avoir le problème. Es-tu sur VC6 ? c'est mon cas.

Voilà le pourquoi de l'erreur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

class A { public: virtual void Do() = 0; };   class B : public A { public: B() {} };   int main() { B().Do(); return 0; }

---

Ce code ne compile pas et c'est logique : B ne définit pas Do() donc il n'a pas le droit d'être instancié.
Maintenant si j'écris:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

class A { public: virtual void Do() = 0; };   class B : public A { public: B( int ) {} };   int main() { B( 'Boom' ).Do(); return 0; }

---

VC6 compile et ça fait Boom à l'exec.

Evidement c'est pas toujours écrit aussi clairement dans le code et, moi, je me suis fait avoir via un algo avec des find_if imbriqués...

C'est donc un bug de VC6 qui autorise à instancier une classe abstraite quand on ne passe pas par le constructeur par défaut ?

De toute façon, VC 6 :roll:
:bug:

Citation:

---

Envoyé par Médinoc

C'est donc un bug de VC6 qui autorise à instancier une classe abstraite quand on ne passe pas par le constructeur par défaut ?

---

It's not a bug, it's a feature.

Plus prosaïquement, VC6 n'est pas un compilateur C++. C'est un bon compilateur C89, qui gère quelques extensions orientée objet dont la syntaxe est proche d'un langage qu'à l'époque, on appelait C++ - mais sans vraiment savoir ce que ce langage faisait vraiment.

Avec les alternatives qu'on a maintenant (et notamment les version Express de Visual C++ 2005 et 2008), je me demande comment on peut encore compiler des programmes avec cet antiquité. No offense intended, bien sûr.

Mon chef de projet tente de migrer vers 2008. On peut comprendre que ce n'est pas évident puisqu'on a plusieurs grosses applis en vc6 qui sont elles mêmes basées sur un framework vc6 commun, lui même utilisant parfois des vieux composants achetés ça et là qui apparemment posent pas mal de problèmes et n'ont plus de mise à jour.

Il faut sacrifier du temps pour faire le portage, syncroniser le portage pour toutes les applis et les équipes qui bossent dessus. Lorsqu'on présente le portage à un directeur qui ne veut pas comprendre l'investissement (après tout l'appli marche comme alors à quoi ça sert de sacrifier tant de temps? Et les nouvelles fonctionnalités prévues?)...

donc vala