Comment l'appel à une méthode virtuelle....

est il implemente par un compilateur C++?
s'il vous plait aidez moi a repondre a cette question , c'est pour un exam!

merci..

En gros, toute classe possédant au moins une méthode virtuelle va se voir attribuer par le compilateur une table virtuelle (v-table), contenant des pointeurs vers les méthodes virtuelles. Tu pourras trouver plus de doc sur le net a propos des v-tables ...Surtout si c'est pour un exam :P

Bonjour,
Lorsque tu déclares au moins une fonction virtuelle quelquepart dans la hiérarcie d'un objet, il y a création d'une table virtuelle de méthode (aussi nommée VMT).

Quand tu demandes à exécuter la-dite méthode virtuelle : Recherche si l'objet à sa propre VMT, si oui, la fonction demandée y est-elle?
Si elle y est, elle s'exécute, sinon on lance la recherche sur la VMT du parent, ainsi de suite jusqu'à trouver la méthode.

Citation:

---

Si elle y est, elle s'exécute, sinon on lance la recherche sur la VMT du parent, ainsi de suite jusqu'à trouver la méthode.

---

A vérifier, mais je crois que la table de tous les objets sera complète, si une méthode n'a pas été surdéfinie l'entrée correspondante pointera simplement sur la méthode de la classe mère. Il n'y a pas de recherche récursive comme tu le suggères.

Citation:

---

Envoyé par Loulou24

Citation:

---

Si elle y est, elle s'exécute, sinon on lance la recherche sur la VMT du parent, ainsi de suite jusqu'à trouver la méthode.

---

A vérifier, mais je crois que la table de tous les objets sera complète, si une méthode n'a pas été surdéfinie l'entrée correspondante pointera simplement sur la méthode de la classe mère. Il n'y a pas de recherche récursive comme tu le suggères.

---

La methode générale de la v-Table n'est effectivement pas recursive, le constructeur de chaque objet ecrit l'adresse des méthodes redefinies, si bien qu'a la fin la vtable est la liste des methodes virtuelles...

Toutefois chaque compilo est libre de son implementation et il me semble que g++ n'utilise pas de v-table mais un autre mécanisme (à vérifier)

Je m'excuse si j'ai mal aiguillé cette personne,
je me rapellé d'un cours ou la VMT et le mécanisme de recherche a été décrit comme ça.

J'avoue que je n'ai pas vérifier dans les sources de g++, ni des autres compilateurs :P

Quelqu'un connait-il un site sur le sujet ? ça peut être intéressant, car la méthode implémentée influence grandement les performance à l'exécution.

Pour ce qui est des performances à l'exécution de manière générale, il y a le document n1359. (que je n'arrive pas à charger. C'est bizarre)

Pour ce qui est des vtables (pas VMT en C++ -- même combat que pas de méthodes, mais des fonctions membre) il me semble aussi que les détails d'implémentation sont laissés à la discrétion des fournisseurs de compilos. Je me souviens d'un bouquin de Stanley Lipmann au sujet du "modèle Objet" du C++ (ou un titre comme ça) qui traitait justement des vtables.
Pour ce qui est de la récurisivité des tables (comprendre cout non constant pour retrouver la bonne function)... je n'y crois pas beaucoup. Je n'en vois pas l'intérêt non plus.

Parfois les ressources qui traitent de l'héritage multiple et sa variante en diamant abordent le sujet des vtables pour expliquer comment s'est mis en oeuvre.

En l'occurence je crois pouvoir vous aider (en ce qui concerne g++ en tout cas).
D'une, OUI, il utilise une VTable (suffisemment d'erreurs liés à ça en utilisant Qt pour m'en convaincre...) Un petit test idiot qui marche : définissez une classe avec un destructeur virtuel, sans l'implémenter...
Ex :

Code:

---

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

#include <iostream>   using namespace std;   class Foo { public : Foo(int barVal); virtual ~Foo();   int bar();   private : int _bar; };   Foo::Foo(int barVal) : _bar(barVal) {}   //Foo::~Foo() {}   int Foo::bar() {return _bar;}

---

ceci génère à l'édition de lien :

Code:

---

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

gimli test 57 % gcc -o foobar testcon1.cpp /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/../../../crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' /users/dea/cahier/tmp/ccW19gwI.o(.text+0x8): In function `Foo::Foo[not-in-charge](int)': : undefined reference to `vtable for Foo' /users/dea/cahier/tmp/ccW19gwI.o(.text+0x20): In function `Foo::Foo[in-charge](int)': : undefined reference to `vtable for Foo' /users/dea/cahier/tmp/ccW19gwI.o(.text+0x5a): In function `__static_initialization_and_destruction_0(int, int)': : undefined reference to `std::ios_base::Init::Init[in-charge]()' /users/dea/cahier/tmp/ccW19gwI.o(.text+0x89): In function `__tcf_0': : undefined reference to `std::ios_base::Init::~Init [in-charge]()' /users/dea/cahier/tmp/ccW19gwI.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit status

---

Voilà donc qui résoud le Pb de savoir s'il utilise une Vtable ou non...

Pour ce qui est du fonctionnement de cette dernière, il me semble en effet que toutes les adresses de toutes les fonctions héritées sont présentent. En effet le fonctionnement est le suivant (je le sais pour avoir compilé en assembleur certain code pour comprendre le fonctionnement de fonction dites "virtual inline"... Sisi c'est possible, et en plus ça marche, à condition d'utiliser -O2, je crois...)
En fait lors d'un appel de fonction, c'est l'instruction assembleur :

Code:

---

1 2	CALL adresse

---

qui est utilisé (hors fonctions/méthodes inline pour lesquelles l'appel est remplacé par le corps de la méthode). Lors d'un appel de fonctions/méthodes classique, "adresse" est une valeur fixée "en dur" (une constante, quoi).

L'appel à une méthode virtuelle est plus proche de... Immaginons une bête structure C dotée de pointeurs de fonction. Et bien voilà !!!
Le "call" ne prend pas en paramètre une valeur constante, mais une référence au pointeur, qui lui même contient l'adresse... Ainsi la même opération sur des instances différentes de la structure C peut aboutir au lancement de routines différentes...
On peut écrire ceci en assembleur comme suit :

Code:

---

1 2	CALL [adresse]

---

adresse n'est plus l'adresse de la routine mais l'adresse du pointeur qui contient l'adresse de la routine.

Dans le cas des méthodes virtuelles (en tout cas sous G++, mais je suspecte que ce fonctionnement n'est pas différent avec d'autres compilos), adresse vaut en fait :
adresse = adresseObj + OFFSET
OFFSET est une constante, qui dépend de la méthode appellée (calculé à la compil'). Puisque la VTable appartient à l'objet, il suffit d'aller chercher à l'endrois approprié son adresse (cela s'écrit en une seule instruction assembleur, "CALL [adresseObj + OFS]")

Etant donné qu'en C++, on peut faire l'appel d'une méthode sur un objet référence par un pointeur à n'importe quel niveau de la hiérarchie de classe, il est IMPERATIF que la VTable soit complète pour n'importe quel objet de la-dite hiérarchie.
Un peu de code compilé par un "g++ -S" permet de s'en convaincre...
En effet, de plus, une recherche récursive necéssiterait une table de symboles (correspondance nom de fonction <--> adresse), une recherche dans cette table, ce qui en plus de rendre la complexité variable, l'augmentrait tout simplement de façon dramatique à tout les coups...

Voilà, et pour les curieux qui voudraient savoir l'effet du sus-dit "virtual inline", et bien il fonctionne (sous reserve d'optimisation suffisante, sous gcc en tout cas) comme inline lorsque l'appel de méthode se fait sur un objet instancié en variable automatique ou globale, et comme virtual dès qu'il conserne un objet dynamique (pointeur).

Voili voiloù, j'espère vos doutes et interrogation dissoutes.