Je sais que c'est un ancien thread, mais personne n'a mentionné les interfaces ABI ou les problèmes spécifiques du compilateur. Alors j'ai pensé que je le ferais.
Ceci est fondamentalement basé sur le concept selon lequel vous écrivez une bibliothèque avec un en-tête à distribuer aux gens ou vous réutilisez vous-même plutôt que d'avoir tout dans un en-tête. Si vous envisagez de réutiliser un en-tête et des fichiers source et de les recompiler dans chaque projet, cela ne s'applique pas vraiment.
Fondamentalement, si vous compilez votre code C ++ et créez une bibliothèque avec un compilateur, l'utilisateur essaie d'utiliser cette bibliothèque avec un compilateur différent ou une version différente du même compilateur, vous pouvez obtenir des erreurs de l'éditeur de liens ou un comportement d'exécution étrange en raison d'une incompatibilité binaire.
Par exemple, les fournisseurs de compilateurs modifient souvent leur implémentation de la STL entre les versions. Si vous avez une fonction dans une bibliothèque qui accepte un std :: vector, alors elle s'attend à ce que les octets de cette classe soient arrangés de la manière dont ils étaient arrangés lorsque la bibliothèque a été compilée. Si, dans une nouvelle version du compilateur, le fournisseur a apporté des améliorations d'efficacité à std :: vector, le code de l'utilisateur voit la nouvelle classe qui peut avoir une structure différente et la transmet à votre bibliothèque. Tout se dégrade à partir de là ... C'est pourquoi il est recommandé de ne pas faire passer les objets STL au-delà des limites de la bibliothèque. Il en va de même pour les types C Run-Time (CRT).
Lorsque vous parlez du CRT, votre bibliothèque et le code source de l'utilisateur doivent généralement être liés au même CRT. Avec Visual Studio, si vous créez votre bibliothèque à l'aide du CRT multithread, mais que l'utilisateur établit des liens avec le CRT de débogage multithread, vous rencontrerez des problèmes de liaison car votre bibliothèque ne trouvera peut-être pas les symboles dont elle a besoin. Je ne me souviens plus de quelle fonction il s'agissait, mais pour Visual Studio 2015, Microsoft a créé une fonction CRT en ligne. Soudain, c'était dans l'en-tête et non dans la bibliothèque CRT, donc les bibliothèques qui s'attendaient à le trouver au moment de la liaison ne pouvaient plus le faire et cela a généré des erreurs de lien. Le résultat était que ces bibliothèques devaient être recompilées avec Visual Studio 2015.
Vous pouvez également obtenir des erreurs de lien ou un comportement étrange si vous utilisez l'API Windows mais que vous créez avec des paramètres Unicode différents pour l'utilisateur de la bibliothèque. Cela est dû au fait que l'API Windows a des fonctions qui utilisent des chaînes Unicode ou ASCII et des macros / définit qui utilisent automatiquement les types corrects en fonction des paramètres Unicode du projet. Si vous passez une chaîne à travers la limite de la bibliothèque qui est du type incorrect, les choses se cassent au moment de l'exécution. Ou vous pouvez constater que le programme n'est pas lié en premier lieu.
Ces choses sont également vraies pour le passage d'objets / types à travers les limites de bibliothèques à partir d'autres bibliothèques tierces (par exemple un vecteur Eigen ou une matrice GSL). Si la bibliothèque tierce modifie son en-tête entre la compilation de votre bibliothèque et la compilation de son code par l'utilisateur, les choses vont casser.
Fondamentalement, pour être sûr, les seules choses que vous pouvez passer à travers les limites de la bibliothèque sont des types intégrés et des POD (Plain Old Data). Idéalement, tout POD doit être dans des structures qui sont définies dans vos propres en-têtes et ne reposent sur aucun en-tête tiers.
Si vous fournissez une bibliothèque d'en-tête uniquement, tout le code est compilé avec les mêmes paramètres de compilateur et avec les mêmes en-têtes, de sorte que beaucoup de ces problèmes disparaissent (à condition que la version de la troisième bibliothèque partielle que vous et votre utilisateur utilise soit compatible avec l'API).
Cependant, certains points négatifs ont été mentionnés ci-dessus, tels que l'augmentation du temps de compilation. Vous pouvez également diriger une entreprise et vous ne voudrez peut-être pas donner tous les détails de l'implémentation de votre code source à tous vos utilisateurs au cas où l'un d'eux le vole.