Eh bien, commençons par démolir certaines de vos hypothèses:
- L'un des avantages des bibliothèques d'en-tête uniquement pour C ++ est qu'elles n'ont pas besoin d'être compilées séparément.
Compiler les choses séparément signifie potentiellement ne pas avoir à tout recompiler si seulement une partie change.
Donc, un inconvénient au lieu d’un avantage.
- En C et C ++, Inline n’a de sens que si la fonction est définie dans un fichier d’en-tête *.
Oui, le seul effet inline
qui reste est l'exception à la règle une définition .
Malheur à vous si ces définitions sont différentes de quelque façon que ce soit.
Donc, si une fonction est interne à une unité de compilation, marquez-la static
. Cela rend également l’inline plus probable, car la fonction doit être disponible pour pouvoir l’intégrer.
Néanmoins, jetez un coup d’œil à l’optimisation temps-lien, telle que prise en charge par au moins MSVC ++, gcc et clang.
- Traditionnellement, en C, on utilisait la disposition .c / .h, où l'en-tête représente l'interface publique minimale de l'unité de traduction. De même, .cpp / hpp.
L’un des objectifs est certainement de ne présenter que l’interface minimale, afin d’obtenir une plus grande stabilité des API et des ABI et de réduire les temps de compilation.
En particulier, les classes C ++ ne sont pas vraiment adaptées à cela, car tous les bits privés s'infiltrent dans l'en-tête, de même que les objets protégés, que vous souhaitiez en dériver ou non.
Le modèle de conception PIMPL sert à réduire ces détails.
La partie où la séparation de l'interface et de l'implémentation échoue complètement en C ++ est bien celle des modèles.
Le comité a essayé de faire quelque chose avec les modèles exportés , mais ceux-ci ont été abandonnés car trop compliqués et ne fonctionnaient pas vraiment.
Maintenant, ils travaillent sur un système de modules approprié , bien que cela avance lentement. Cela réduira considérablement les temps de compilation et devrait également augmenter la stabilité des API et des ABI en diminuant leur surface.
Les bibliothèques comportant uniquement des en-têtes sont-elles généralement plus efficaces en termes de code et de temps d’exécution que la présentation classique? Si oui, est-ce dû à une optimisation en ligne étendue ou à d'autres optimisations?
Les bibliothèques contenant uniquement des en-têtes peuvent être plus efficaces en termes de taille de code et de temps d'exécution, bien que cela dépende de savoir si la bibliothèque est partagée, quelle est son utilisation, de quelle manière, et si l'inlining s'avère un gain décisif dans ce cas spécifique.
Et la raison pour laquelle l'optimisation est si importante pour l'optimisation ne tient pas à son dynamisme, mais à ses possibilités de propagation constante et d'optimisation.