Discussion :

[stephl]

Il n'a pas forcément inliné quoi que ce soit. Cette option à pour objectif de permettre d'iniliner au moment où l'on créera le programme final. Au moment où la bibliothèque est créée, on ne sait pas encore quelle fonction sera inlinée ou pas à terme. Donc, on met dedans plein d'information pour permettre cet inlining au cas où. Schématiquement, on met tout le code source dans le .lib.

Que le résultat fasse 1Go me semble beaucoup.

Si la lib contient en gros le code source, je trouve cela bizarre car je doute qu'il y ait 1 Go de sources... Même s'il y a 100 Mo de source (je pense être très généreux), ça fait 10 fois plus.
Et en ce qui concerne les templates, comme le code est généré à l'instanciation, je me demande si ce ne serait pas à ce moment là que le code est inliné (et éventuellement dupliqué).

[stephl]

Dans ce fichier, il y a tout ce qui est nécessaire pour effectuer l'édition des liens... avec un exécutable ou une bibliothèque dynamique. Dans une bibliothèque statique, il n'y a en réalité aucune édition des liens d'effectuée.

Je suis d'accord avec toi et je ne crois pas avoir dit le contraire. Ce que je veux dire, c'est que c'est tout de même le linker qui se charge de construire la lib et que je pense qu'à ce moment, le compilateur a peut-être déjà inliné les fonctions présentes dans les headers et marquées inline, ainsi que les templates (compilés et éventuellement inlinés).

[Matthieu Brucher]

Je suis d'accord avec toi et je ne crois pas avoir dit le contraire. Ce que je veux dire, c'est que c'est tout de même le linker qui se charge de construire la lib et que je pense qu'à ce moment, le compilateur a peut-être déjà inliné les fonctions présentes dans les headers et marquées inline, ainsi que les templates (compilés et éventuellement inlinés).

Effectivement, tu n'as pas dit le contraire Si ça se trouve toutes les possibilités ont été générées par le compilateur et c'est l'éditeur des liens qui va, à la fin, choisir les meilleures solutions (potentiellement basées sur un profil), comme tu le dis.
Je pense aussi que pour une bibliothèque statique, avec les inconvénients qu'elle présente de manière générale, il vaut mieux ne pas prendre cette option. Les autres compilateurs ne peuvent pas tirer partie de ces données complémentaires.

[stephl]

Effectivement, tu n'as pas dit le contraire Si ça se trouve toutes les possibilités ont été générées par le compilateur et c'est l'éditeur des liens qui va, à la fin, choisir les meilleures solutions (potentiellement basées sur un profil), comme tu le dis.

Probablement. De toute façon, je ne m'y connais pas assez dans ce domaine pour m'avancer davantage. Je suis d'accord avec ton explication.

Je pense aussi que pour une bibliothèque statique, avec les inconvénients qu'elle présente de manière générale, il vaut mieux ne pas prendre cette option. Les autres compilateurs ne peuvent pas tirer partie de ces données complémentaires.

J'ai effectivement lu cela. Et même sans prendre en compte cette option, le code généré par un compilateur C++ (que ce soit un obj, une lib ou une dll) peut poser des problèmes si utilisé avec un compilateur/linker différent ou même avec le même compilateur et des options de compilation différentes. Ces incompatibilités peuvent être dues au name mangling, au layout des classes en mémoire, à la gestion des exceptions et j'en passe...