[Kos-dev] [David Decotigny <David.Decotigny@irisa.fr>] Re: Probleme avec le C++

[d2]

Bonjour,

Une troisieme vraie-fausse solution a laquelle on pourrait penser :
s'en remettre aux vtables, ce qui eviterait d'avoir a exporter les
symboles de methodes. C'est a dire que toutes les methodes qui doivent
etre utilisees depuis un module exterieur sont virtual. Ca veut dire
alors qu'on peut avoir des methodes/fonctions en dehors du module qui
ont la forme suivante : type_retour nom_fonction(MaClasse & objet), et
dans ce cas on peut appeler toutes les methodes virtual de l'objet
depuis n'importe quel autre module. Le 1er probleme : indirection par
la VMT (normal, puisqu'on n'effectue pas la liaison au chargement, on
deporte la penalite a l'execution). L'autre probleme : si on ecrit
  void toto() {
    MaClasse o1(...);
    MaClasse *o2 = new MaClasse(...);
    o1.virtual_method(...);
    o2->virtual_method(...);
  }
Dans ce cas, le compilo "optimise", c'est a dire qu'il ne passera pas
par la VMT : il faut que le symbole MaClasse::virtual_method(...) soit
lie au moment du chargement.

Par contre, on aurait le droit de passer par une "factory" pour eviter
ce pb. Une "factory" tres simple (tellement simple que c'est pas une
factory) etant une simple fonction qui fait :
   MaClasse & create_ref(...)
ou MaClasse * create_ptr(...)

Puis alors :
  void toto() {
    MaClasse & o1 = create_ref(...);
    MaClasse *o2  = create_ptr(...);
    o1.virtual_method(...);
    o2->virtual_method(...);
  }

Dans ce cas, virtual_method est bien appelee par vtable interposee =>
pas de symbole virtual_method() a lier. Si on veut utiliser ce
mecanisme, je suggere de passer par une *vraie* factory (cf design
patterns).

Perso, je trouve cette solution pas tres heureuse (vtable, pas
terrible, artillerie lourde), et delicate (faire bien attention a
utiliser les factories partout, et pas les new directement ; mais
peut-etre qu'il y a une option gcc pour tout faire passer en virtual).

Bonne journee,

-- 
d2