Différence entre les bibliothèques statiques et partagées?

Quelle est la différence entre les bibliothèques statiques et partagées?

J’utilise Eclipse et il existe plusieurs types de projets, y compris des bibliothèques statiques et des bibliothèques partagées? A-t-on un avantage sur l’autre?

Les bibliothèques partagées sont des fichiers .so (ou Windows .dll ou OS X .dylib). Tout le code relatif à la bibliothèque se trouve dans ce fichier, et il est référencé par les programmes qui l’utilisent au moment de l’exécution. Un programme utilisant une bibliothèque partagée fait uniquement référence au code qu’il utilise dans la bibliothèque partagée.

Les bibliothèques statiques sont des fichiers .a (ou Windows .lib). Tout le code relatif à la bibliothèque se trouve dans ce fichier, et il est directement lié au programme au moment de la compilation. Un programme utilisant une bibliothèque statique prend des copies du code qu’il utilise de la bibliothèque statique et en fait une partie du programme. [Windows dispose également de fichiers .lib utilisés pour référencer les fichiers .dll, mais ils agissent de la même manière que le premier].

Chaque méthode présente des avantages et des inconvénients.

Les bibliothèques partagées réduisent la quantité de code qui est dupliquée dans chaque programme qui utilise la bibliothèque, ce qui réduit la taille des fichiers binarys. Il vous permet également de remplacer l’object partagé par un autre fonctionnellement équivalent, mais peut avoir des avantages en termes de performances sans avoir à recomstackr le programme qui l’utilise. Les bibliothèques partagées auront toutefois un petit coût supplémentaire pour l’exécution des fonctions ainsi qu’un coût de chargement au moment de l’exécution, car tous les symboles de la bibliothèque doivent être connectés aux éléments qu’ils utilisent. De plus, les bibliothèques partagées peuvent être chargées dans une application au moment de l’exécution, ce qui constitue le mécanisme général d’implémentation des systèmes de plug-in binarys.

Les bibliothèques statiques augmentent la taille globale du fichier binary, mais cela signifie que vous n’avez pas besoin de transporter une copie de la bibliothèque utilisée. Comme le code est connecté au moment de la compilation, il n’y a pas de coûts de chargement supplémentaires. Le code est simplement là.

Personnellement, je préfère les bibliothèques partagées, mais utilisez des bibliothèques statiques lorsque vous devez vous assurer que le binary ne comporte pas beaucoup de dépendances externes, telles que des versions spécifiques de la bibliothèque standard C ++ ou des versions spécifiques de la bibliothèque Boost C ++.

Une bibliothèque statique est comme une librairie et une bibliothèque partagée est comme une bibliothèque. Avec l’ancien, vous obtenez votre propre copie du livre / de la fonction à emporter chez vous; avec ce dernier vous et tout le monde allez à la bibliothèque pour utiliser le même livre / la même fonction. Ainsi, toute personne souhaitant utiliser la bibliothèque (partagée) doit savoir où elle se trouve, car vous devez “aller chercher” le livre / la fonction. Avec une bibliothèque statique, le livre / la fonction est à vous et vous le conservez dans votre maison / programme, et une fois que vous l’avez, vous ne vous souciez pas de savoir où et quand vous l’avez reçu.

Simplifié:

  • Liaison statique: un grand exécutable
  • Liaison dynamic: un petit exécutable plus un ou plusieurs fichiers de bibliothèque (fichiers .dll sous Windows, .so sous Linux ou .dylib sous macOS)

Les bibliothèques statiques sont compilées dans le cadre d’une application, contrairement aux bibliothèques partagées. Lorsque vous dissortingbuez une application qui dépend de bibliothèques partagées, les bibliothèques, par exemple. Les DLL sur MS Windows doivent être installées.

L’avantage des bibliothèques statiques est qu’il n’y a pas de dépendances requirejses pour l’utilisateur exécutant l’application – par exemple, elles n’ont pas besoin de mettre à jour leur DLL … L’inconvénient est que votre application est plus grande parce que vous l’envoyez avec toutes les bibliothèques dont il a besoin.

En plus de créer des applications plus petites, les bibliothèques partagées permettent aux utilisateurs d’utiliser leur propre version, peut-être meilleure, des bibliothèques plutôt que de s’en remettre à une partie de l’application.

Pour une bibliothèque statique, le code est extrait de la bibliothèque par l’éditeur de liens et utilisé pour créer le fichier exécutable final au moment où vous comstackz / créez votre application. L’exécutable final n’a aucune dépendance sur la bibliothèque au moment de l’exécution

Pour une bibliothèque partagée, le compilateur / éditeur de liens vérifie que les noms avec lesquels vous créez un lien existent dans la bibliothèque lors de la création de l’application, mais ne déplace pas leur code dans l’application. Au moment de l’exécution, la bibliothèque partagée doit être disponible.

Le langage de programmation C lui-même n’a aucun concept de bibliothèques statiques ou partagées – elles constituent une fonctionnalité d’implémentation.

Personnellement, je préfère de beaucoup utiliser des bibliothèques statiques, car cela simplifie la dissortingbution de logiciels. Cependant, il s’agit d’une opinion sur laquelle beaucoup de sang (figuratif) a été versé par le passé.

L’avantage le plus important des bibliothèques partagées est qu’il n’y a qu’une seule copie du code chargé en mémoire, quel que soit le nombre de processus utilisant la bibliothèque. Pour les bibliothèques statiques, chaque processus obtient sa propre copie du code. Cela peut entraîner un gaspillage important de mémoire.

OTOH, un avantage des bibliothèques statiques est que tout est intégré dans votre application. Vous n’avez donc pas à craindre que le client dispose de la bonne bibliothèque (et de la version) disponible sur son système.

En plus de toutes les autres réponses, une chose non mentionnée est le découplage:

Permettez-moi de parler d’un code de production du monde réel, avec lequel j’ai eu affaire:

Un très gros logiciel, composé de plus de 300 projets (avec studio visuel), principalement construit en tant que librairie statique et enfin tous reliés entre eux dans un énorme exécutable, vous vous retrouvez avec les problèmes suivants:

-Le temps de liaison est extrêmement long. Vous pourriez vous retrouver avec plus de 15 minutes de lien, par exemple 10 secondes de temps de compilation. Certains outils sont à genoux avec un aussi gros exécutable, comme les outils de vérification de la mémoire qui doivent instrumenter le code. Vous pourriez tomber dans des limites qui avaient été vues comme des imbéciles.

Le découplage de votre logiciel est plus problématique: sur cet exemple concret, les fichiers d’en-tête de chaque projet étaient accessibles depuis d’autres projets. En conséquence, il était extrêmement facile pour un développeur d’append des dépendances; il s’agissait juste d’inclure l’en-tête, car à la fin, le lien trouvera des symboles. Il se termine par d’horribles dépendances cyclistes et un désordre complet.

Avec la bibliothèque partagée, c’est un peu de travail supplémentaire car le développeur doit modifier le système de génération de projet pour append la bibliothèque dépendante. J’ai observé que le code de la bibliothèque partagée avait tendance à offrir une API de code plus propre.