Version imprimable
http://cpp.developpez.com/cours/cpp/?page=page_14#LXIV
"Enfin, ce qui est le plus grave, c'est que les instances des template sont en multiples exemplaires dans les fichiers objets générés par le compilateur"
Si dans un projet on utilise dans 2 fonction un std::vector<int> v; , dans le binaire cette classe sera présente 2 fois ?
Le risque est effectivement présent, surtout si tu utilise un std::vector<int> dans deux unités de compilation séparées.Citation:
Envoyé par guillaume07
Hello
Voilà qui est intéressant. Que se passe-t-il dans le cas où deux unités de compilation s'échangent via des méthodes des std::vector ? Il y a aura deux classes dans le binaire, mais strictement identiques ?
en general, le code n'est pas dupliqué dans l'executable final. La plupart des linker fusionnent les méthodes dont le code généré est identique.
ce qui les conduit même parfois a fusionner std::vector<int> et std::vector<float>, et std::vector<A*> et std::vector<B*>
Je me disais aussi... ça ferait trop gonfler l'empreinte pour rien.
bah oui :)
ca poserait aussi d'enormes problèmes pour les variables statiques des classes templates; il n'y en aurait pas une pour le programme mais une par module, donc deux modules ne parleraient pas à la même variable... "woups!"
:koi:Citation:
Envoyé par screetch
TU aurais un peu plus de détails ?
C'est, en réalité, beaucoup plus comlexe que cela...
Ce dont on est sur tient en plusieurs points:
A partir de là, on peut être tenté de tirer quelques conclusions, qui peuvent parfaitement s'avérer non fondées, telles que:
- Le code d'une classe template est, a priori, inliné car le compilateur ne peux créer le code binaire correspondant qu'une fois qu'il sait quel est le type du (des) paramètre(s) template
- Le compilateur oublie, d'une unité de compilation à l'autre, ce qu'il a pu faire
- Le compilateur reste seul juge de l'opportunité d'inliner (ou non) une fonction déclarée (de manière implicite ou explicite) inline
- Si le code d'une fonction (membre d'une classe) template est utilisé, il est très certainement généré au niveau binaire, ce qui ne veut pas dire (tout dépend du compilateur) que l'ensemble des fonctions de la classe template (s'il échoit) le sera d'office
Là dessus, il faut aussi prendre l'éventualité de l'instanciation explicite, entre autres pour les types primitifs.
- Le code binaire ne sera peut être généré pour l'ensemble d'une classe que pour les instances de celle-ci (par opposition aux références / pointeurs sur les instances de la classe), dans le fichiers où les dites instances sont créées
- Il n'est pas exclu que l'appelle d'une fonction donnée occasionne l'inlining de celle-ci, et donc sa présence à l'intérieur du binaire, à la place où elle est appelée
- ...
Il n'est donc pas exclu, malgré tout, que l'ensemble de std::vector<int> se trouve dans libstdxx.a (sous gcc) et que le code ne soit pas forcément inliné chaque fois que l'on a une variable de ce type.
Et ce n'est qu'un aperçu rapide du problème qu'il peut y avoir à donner une réponse par trop affirmative :P
Si le code généré est abolument identique pourquoi en avoir plusieurs versions (une copie en quelques sortes?)
Certains linker fusionnent donc les methodes qui ont exactement le meme code assembleur généré.
vector<int> et vector<float> pourraient en faire partie, par exemple. A part gérer des données de 32 bits de long, y'a pas de code spécialisé.
oui effectivement thxsCitation:
Envoyé par screetch
Ce dont tu parles c'est du LTO (link time optimization), clang le fait en O4 (mais il faut le gold linker) et gcc le fait depuis la version 4.5 (4.6 ?)Citation:
Envoyé par screetch
Il y a quand même des contraintes où le compilateur est obligé de fusionner des morceaux de deux vector<T> (pour un même T) :
- Pour les variables statiques
- Quand on prend l'adresse d'une fonction
A partir de là, il ne me semble pas idiot que comme le mécanisme de fusion existe, il serve dans d'autres cas où il est approprié...
Par contre, la fusion entre un vector<T> et un vector<U>, même quand le code est identique, est un autre concept, lié uniquement à l'optimisation et non pas à la correction du programme. On peut manuellement forcer un peu cette optimisation (par exemple faire dériver par spécialisation tous les vector<T*> d'un vector<void*> qui contient la quasi totalité du code).
De plus, la LTO ne peut, à mon sens, s'appliquer que... si le code n'a pas été effectivement inliné.
En effet, le principe de l'inlining est de remplacer, purement et simplement, l'appel de la fonction par le code de la fonction appelée, alors qu'autrement, il "suffit" au compilateur de fournir un symbole de la fonction appelée.
Dans le premier cas, il devient virtuellement impossible au linker (ou à tout autre système passant après le compilateur) de distinguer ce qui fait partie d'une fonction appelée de la fonction appelante.
Dans le second cas, le linker a effectivement l'occasion de reconnaitre les différents symboles et, le fait que l'appel d'une même fonction sera représenté (a priori du moins) par un même symbole (y compris si le type est un typedef) devrait, effectivement, permettre de fusionner vector<T> et vector<U> si T et U ne sont, par exemple, que des typedef différents d'un même type (on peut donc, par conséquent, effectivement envisager que vector<T*> soit fusionné avec l'instanciation du vector utilisant le type utilisé par le typedef de uintptr_t, par exemple).
c'est meme préconisé avec mesure a la clé par stroustrup dans son papier a OOPSLA 09 :Citation:
Envoyé par JolyLoic
http://www.open-std.org/jtc1/sc22/wg...2009/n2911.pdf
encore un doute... les fonctions type push_back générés ne prennent pas en paramètre soit un int soit un float selon qu'il s'agisse d'un vector<int> ou d'un vector<float> auquel cas, les codes ne sont pas identiques ?Citation:
Envoyé par screetch
ca depend de la convention d'appel, je ne suis pas sur la.