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, notamment des bibliothèques statiques et des bibliothèques partagées. L'un at-il un avantage sur l'autre?
Les bibliothèques partagées sont des fichiers .so (ou dans Windows .dll ou OS X .dylib). Tout le code relatif à la bibliothèque se trouve dans ce fichier, qui est référencé par les programmes l’utilisant 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 dans Windows .lib). Tout le code relatif à la bibliothèque est dans ce fichier et il est directement lié au programme lors de la compilation. Un programme utilisant une bibliothèque statique prend des copies du code qu'il utilise depuis la bibliothèque statique et en fait partie intégrante. [Windows a également des fichiers .lib qui sont utilisés pour référencer des 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 dupliqué dans chaque programme utilisant cette bibliothèque, en gardant les fichiers binaires de petite taille. Il vous permet également de remplacer l'objet partagé par un objet fonctionnellement équivalent, mais qui peut avoir des avantages supplémentaires en termes de performances sans avoir à recompiler 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 à 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 pour la mise en œuvre de systèmes de plug-in binaires.
Les bibliothèques statiques augmentent la taille globale du fichier binaire, mais cela signifie qu'il n'est pas nécessaire d'emporter une copie de la bibliothèque utilisée. Comme le code est connecté au moment de la compilation, il n’ya pas de coût supplémentaire de chargement au moment de l’exécution. Le code est simplement là.
Personnellement, je préfère les bibliothèques partagées, mais j'utilise des bibliothèques statiques lorsque vous devez vous assurer que le fichier binaire ne comporte pas de nombreuses dépendances externes difficiles à respecter, 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/fonction à emporter à la maison; avec ce dernier, vous et tous les autres 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 vous appartient, et vous le conservez dans votre maison/programme, et une fois que vous l'avez, vous ne vous souciez plus ni du moment ni du moment où vous l'avez.
Simplifié:
- Liaison statique: un grand exécutable
- Liaison dynamique: un petit exécutable et un ou plusieurs fichiers de bibliothèque (fichiers .dll sous Windows, .so sous Linux ou .dylib sous macOS)
Pour une bibliothèque statique, le code est extrait de la bibliothèque par l'éditeur de liens et utilisé pour générer l'exécutable final au moment où vous compilez/construisez votre application. Le fichier 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 que vous associez 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 pas de concept de bibliothèques statiques ni de bibliothèques partagées - elles constituent une fonctionnalité d'implémentation.
Personnellement, je préfère de loin utiliser des bibliothèques statiques, car cela simplifie la distribution de logiciels. Cependant, c'est une opinion sur laquelle beaucoup de sang (figuré) a été versé dans le passé.
Les bibliothèques statiques sont compilées dans le cadre d'une application, alors que les bibliothèques partagées ne le sont pas. Lorsque vous distribuez une application qui dépend de bibliothèques partagées, les bibliothèques, par exemple. les dll sous MS Windows doivent être installés.
L’avantage des bibliothèques statiques est qu’aucune dépendance n’est requise pour l’utilisateur exécutant l’application - par exemple. ils n'ont pas à mettre à niveau leur DLL de quoi que ce soit. L'inconvénient est que la taille de votre application est plus grande, car vous l'envoyez avec toutes les bibliothèques dont elle a besoin.
En plus de créer des applications plus petites, les bibliothèques partagées offrent à l'utilisateur la possibilité d'utiliser leur propre version, peut-être une meilleure version des bibliothèques, plutôt que de compter sur celle qui fait partie de l'application.
L'avantage le plus important des bibliothèques partagées est qu'il n'y a qu'une seule copie de code chargée 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 la mémoire.
OTOH, un avantage des bibliothèques statiques est que tout est intégré à votre application. Ainsi, vous n'avez pas à vous inquiéter du fait que le client aura la bonne bibliothèque (et la bonne version) disponible sur son système.
En plus de toutes les autres réponses, une chose non encore 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 Visual Studio), généralement construit sous la forme de lib statique et enfin, tous liés entre eux dans un seul 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 compilation. Certains outils sont à genoux avec un exécutable aussi volumineux, comme les outils de vérification de la mémoire qui doivent instrumenter le code. Vous pourriez tomber dans l'atteinte de limites considérées 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 à partir de tout autre projet. En conséquence, il était extrêmement facile pour un développeur d'ajouter des dépendances. il s'agissait simplement d'inclure l'en-tête, car le lien à la fin permettra à allwaws de trouver des symboles. Cela se termine par d'horribles dépendances cyclistes et un désordre complet.
Avec la bibliothèque partagée, cela représente un peu de travail supplémentaire, car le développeur doit éditer le système de construction du projet pour ajouter la bibliothèque dépendante. J'ai observé que le code de bibliothèque partagée tend à offrir une API de code plus propre.
-------------------------------------------------------------------------
| +- | Shared(dynamic) | Static Library (Linkages) |
-------------------------------------------------------------------------
|Pros: | less memory use | an executable, using own libraries|
| | | ,coming with the program, |
| | | doesn't need to worry about its |
| | | compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of | bigger memory uses |
| | libraries may be altered | |
| | subject to OS and its | |
| | version, which may affect| |
| | the compilebility and | |
| | runnability of the code | |
-------------------------------------------------------------------------