Discussion :

[Ekleog]

Ben si c'est toujours la même méthode virtuelle appelée, oui peut être (mais ou est l'intérêt de la méthode virtuelle dans ce cas), même pas sur; si c'est des méthodes différentes, non, chaque appel de méthode risque d'invalider le cache

Sauf que le cache n'a pas qu'une ligne -- et heureusement !
(En plus, rien qu'une ligne de cache basique stocke 32o, soit 4 pointeurs, et donc 4 pointeurs de vftable.)

Si donc on en arrive à être "dérangé", d'une manière ou d'une autre et pour une raison ou une autre, par l'overhead qu'impliquent les fonctions virtuelles, c'est peut etre le signe qu'il est temps de revoir les besoins fondamentaux que doit couvrir le langage et qu'il est peut etre utile de remettre le choix de C++ en cause.

Ou bien peut-être qu'il est temps de se passer de l'utilisation des fonctions virtuelles, et de faire sa tambouille maison.
Non ?

[koala01]

Ou bien peut-être qu'il est temps de se passer de l'utilisation des fonctions virtuelles, et de faire sa tambouille maison.
Non ?

Honnêtement, je ne crois pas qu'il soit ni opportun ni réellement efficace d'essayer de remplacer quelque chose qui fait malgré tout partie intégrante du langage par quelque chose de "fait maison"...

Autant j'accorde énormément de crédit à la proposition de screetch de passer par des classes d'opérations, sous certaines conditions, autant je me méfie énormément du syndrome NIH, surtout quand il s'agit de remplacer quelque chose d'aussi profondément inscrit dans le langage que la virtualité

Je ne dis pas qu'une "tambouille maison" ne fera jamais mieux que le langage, mais je dis que c'est à la fois prendre un énorme risque et se donner beaucoup de mal pour finalement pas grand chose!

Sans compter les problèmes de maintenance que cela peut engendrer si le transfert des connaissances ne s'effectue pas de manière correcte

Je suis le premier à défendre C++ "bec et ongles", il faut aussi reconnaitre que, dans certaines circonstances, il peut ne pas être le langage le plus adapté à des besoins spécifiques

[Ekleog]

En même temps, la tambouille maison, c'est uniquement perdre un peu d'efficacité (un add de plus par ci par là), en échange de 7 octets de mémoire par objet. Du coup, ce pourrait presque être un flag du compilateur.
Sauf que, apparemment, ce n'est pas implémenté.

Et puis, en fait, si le programme est déjà fait, il sera dur de le réécrire dans un autre langage.

Enfin, quel langage propose l'équivalent de la virtualité pour un coût inférieur à 8 octets par objet manipulé ?

[koala01]

tu ne m'as pas compris, parce que la virtualité coute d'office l'équivalent d'un pointeur, et qu'il n'y a donc pas un seul langage objet qui la proposera à un cout inférieur à la taille de celui-ci

Ce que je veux dire, c'est que si tu veux éviter la virtualité, c'est tout le paradigme objet que tu décides d'oublier, et, dans ce cas, peut etre qu'un simple langage structuré, mais fortement typé, te convient d'avantage