Bibliothèques statiques ou partagées pour un lecteur multimédia

Question

Je ne vais pas entrer dans les détails sur la partie "lecteur multimédia" sauf le fait qu'il utilisera évidemment des plug-ins, qui seront une simple bibliothèque dynamique chargée lors de l'exécution. Maintenant, je pourrais relier dynamiquement ces plug-ins à leurs dépendances, ou les relier statiquement. Les deux ont leurs avantages et leurs inconvénients - je ne compte pas Linux ici, car cela va utiliser des bibliothèques partagées.

Le seul avantage que je vois avec l'utilisation de bibliothèques partagées est que la bibliothèque peut être mise à jour indépendamment du programme. Sous Windows, ceci est rarement un avantage, car la bibliothèque sera à côté de l'application qui l'utilise (grâce à l'absence d'ABI C++ officiel). Sous Windows, pour aider à réduire l'enfer des DLL et partager les librairies C, je devrais utiliser SxS, ce qui n'est pas vraiment un bon citoyen. En ce qui concerne les bibliothèques statiques, je vois un grand avantage: les optimisations de temps de liaison. Ceux-ci ont été soutenus par ICC et VC++ depuis un certain temps maintenant et GCC a une branche pour eux. Comme j'utiliserai probablement VC++ sous Windows, il y aurait une amélioration notable des performances du compilateur (enfin, le "compilateur" actuel convertit simplement C++ en un langage intermédiaire, donc le compilateur ici est le "linker"). code et peut optimiser beaucoup de choses de cette façon. C'est l'option que je penche vers.

Ma question est, laquelle serait la meilleure dans mon cas spécifique? Il n'y a pas d'autres applications qui les utilisent car je ne compte pas Linux dans ce numéro (bien que je ne connaisse pas OS X) ou plusieurs instances (qui exécute deux fois le même lecteur multimédia?), Compatibilité binaire (comme je vais tout distribuer avec l'application) ou facile de mise à jour (sur Windows je vais utiliser un binaire diff très efficace pour distribuer les mises à jour).

Answer 1

Je ne suis pas complètement sûr de ce qu'est votre cas "spécifique". Si votre "lecteur multimédia" est destiné à un client unique (ou un petit groupe de clients) qui mettra à jour tout le lecteur multimédia à la fois ou un plugin donné en même temps sous votre supervision complète, je vais bibliothèques statiques.

Si ce n'est pas le cas je vais opter pour des bibliothèques dynamiques. Les optimisations sont bonnes mais ne sont pas aussi bonnes que la satisfaction client/utilisateur. Il n'y a rien de pire que de mettre à jour votre bibliothèque xxx à la dernière version et que tout à coup les choses s'arrêtent pour fonctionner. Si vous n'avez aucun contrôle sur quand et comment les mises à jour sont faites, soyez aussi flexible que possible.

Réponse au commentaire:

bibliothèques dynamiques En général sont rétrocompatibles pour les versions mineures de version en liaison statique peut dépendre d'une version concrète et de briser si vous essayez de le lier à une autre version. Avec la liaison dynamique, votre programme peut même fonctionner tant que les appels que vous utilisez ne changent pas alors que la liaison statique peut dépendre d'un changement du décalage de la fonction dans la bibliothèque. Par exemple, les bibliothèques statiques peuvent être chargées à l'exécution dans l'espace adresse du processus à un décalage statique. Bien sûr, connaître ce décalage permet certaines optimisations mais si vous mettez à jour la bibliothèque, soit vous mettez à jour TOUS les plugins utilisant cette bibliothèque ou probablement les plugins non mis à jour ne fonctionneront pas (car le décalage de fonction pourrait très bien avoir changé). Je suppose que vous les chargez en cours d'exécution, bien que si cela peut être nommé lien statique est dans l'air, dans tous les autres cas, vous aurez juste la bibliothèque sur chaque plugin et il n'y aura pas de "partage".