Discussion :

[ceugniet]

Bibliothèques statiques (.lib) vs dynamiques (.dll)

Je suis débutant en C et C++, très récent utilisateur de Visual C++ express. Je ne comprends pas bien l'intérêt des bibliothèques dynamiques.

Si j'ai bien compris, la seule différence est que les fonctions appelées ne sont chargées qu'à l'exécution, ce qui évidemment réduit la taille de l'exécutable. Donc le seul intérêt serait la taille de l'exécutable.

Ai-je bien compris ?

Question subsidiaire : Je suppose que même dans le cas des .dll une fonction n'est chargée qu'une seule fois (au premier appel) et reste en mémoire ensuite jusqu'à la fin du programme. Et je suppose que même dans le cas d'une bibliothèque statique, seules les fonctions nécessaires (je veux dire "appelées dans le code" même si l'on n'est pas certain qu'elles seront effectivement utilisées) sont incluses dans l'exécutable (je veux dire pas toute la librairie statique).

Ai-je raison de supposer cela ?

Merci de vos réponses !

[Mac LAK]

Si j'ai bien compris, la seule différence est que les fonctions appelées ne sont chargées qu'à l'exécution, ce qui évidemment réduit la taille de l'exécutable. Donc le seul intérêt serait la taille de l'exécutable.

Ai-je bien compris ?

La réduction de la taille de l'exécutable n'est qu'un effet de bord, certes intéressant, mais absolument pas crucial.
Une DLL, contrairement à une librairie statique, est linkée. Donc, ses dépendances statiques sont résolues, et l'on peut examiner ses dépendances dynamiques au travers d'outils comme Dependancy Walker.
De plus, une DLL n'existe qu'une seule fois en mémoire (la librairie est partagée entre tous les processus qui l'utilisent), tandis qu'une librairie statique est dupliquée autant de fois qu'il y a d'images exécutables l'utilisant (DLL incluses...).

Enfin, une DLL peut être testée et validée unitairement, ce qui évite ensuite d'avoir à revalider ces fonctions lors de l'évolution d'un programme l'utilisant. Une librairie statique pouvant toujours être modifiée lors du link, on ne peut jamais garantir que même si son code est inchangé, il ne sera pas nécessaire de la restester. Une DLL peut carrément ne PAS être recompilée si ce n'est pas nécessaire.

Je ne saurais trop t'encourager à savoir faire et utiliser des DLL plutôt que de te cantonner aux librairies statiques : à force de vouloir faire un "exécutable autonome", certains programmes prennent des proportions démentielles pour un usage, somme toute, assez "gadget". Pour ma part, avoir un gadget qui bouffe 250 Mo de RAM, ça me gonfle, et donc il finit en général assez vite à la poubelle. Je préfère un programme utilisant correctement les DLL, et les déployant de façon également correcte, car cela permet d'alléger les machines et de faire tourner plus de choses en même temps.

Question subsidiaire : Je suppose que même dans le cas des .dll une fonction n'est chargée qu'une seule fois (au premier appel) et reste en mémoire ensuite jusqu'à la fin du programme. Et je suppose que même dans le cas d'une bibliothèque statique, seules les fonctions nécessaires (je veux dire "appelées dans le code" même si l'on n'est pas certain qu'elles seront effectivement utilisées) sont incluses dans l'exécutable (je veux dire pas toute la librairie statique).

Ai-je raison de supposer cela ?

La DLL contient en effet toutes les fonctions implémentées, du moment qu'elles sont appelées (directement ou non) par une fonction exportée.

Pour la librairie statique, cela dépend du linker. Certains incluent l'intégralité de la librairie statique, d'autres ont une granularité au niveau module (= le résultat de compilation d'un fichier C / CPP), d'autres ont une granularité au niveau de la fonction.
VS est par défaut réglé sur une granularité au niveau de la fonction, donc il n'inclus QUE les fonctions utilisées (directement ou indirectement).

Par contre, effectivement, le linker ne peut pas résoudre les cas "dynamiques" : il peut éliminer les fonctions manifestement "mortes" (ex : fonction appelée de façon conditionnelle, mais le test étant faux par compilation, ou encore les fonctions jamais appelées), mais il ne peut pas éliminer les cas dynamiques (test d'une variable qui PEUT changer de valeur, mais qui en pratique ne change jamais). Ces fonctions sont appelées "code mort", car c'est du code qui n'est jamais réellement appelé même s'il pourrait, apparemment, l'être.

[ceugniet]

Merci de ta réponse très détaillée.

A vrai dire, je ne sais vraiment pas comment fonctionne une DLL, ni une LIB d'ailleurs.

une DLL n'existe qu'une seule fois en mémoire (la librairie est partagée entre tous les processus qui l'utilisent)

Ah oui ? Mais comment un seul emplacement mémoire peut-il être utilisé simultanément par plusieurs processus ? Il y a des variables locales, non ? Au minimum des compteurs de boucles, par exemple. Est-ce qu'une DLL ne contient qu'un seul type de fonctions ?

Pour l'instant, je ne comprends rien à C++ proprement dit : on peut dire que je code en C (en utilisant Visual C++, bien sûr !). Est-ce que le concept de DLL ne s'applique qu'à des notions propres à C++ ?

Pour ma part, avoir un gadget qui bouffe 250 Mo de RAM, ça me gonfle
...
VS est par défaut réglé sur une granularité au niveau de la fonction, donc il n'inclus QUE les fonctions utilisées

(euh ! Encore une question bête : c'est quoi VS ? Moi, je parlais de Visual C++ !)
Si uniquement les fonctions nécessaires sont incluses dans l'exécutable, je ne comprends pas comment un "gadget" devrait te bouffer 250Mo de RAM !

Toutes mes questions sont simplement motivées par le besoin de comprendre. Je ne souhaite pas "absolument avoir un exécutable autonome". Je souhaite uniquement pouvoir réutiliser dans divers programmes des fonctions que j'aurais développées une unique fois. Qu'elles soient dans une DLL ou dans une LIB m'indiffère : la seule chose qui me préoccupe est la performance du programme. A tort ou à raison, j'ai pensé, qu'une DLL était là pour fournir un bout de code de temps en temps lorsqu'un processus en a besoin et que chaque appel provoquait un chargement du code en mémoire, puis un déchargement. Je pense que ce n'est pas le cas, mais si c'est cela, alors cela doit avoir un impact désastreux sur les performances si la fonction en question est appelée des milliards de fois ! Alors, qu'une librairie statique, serait un réservoir de code utilisé uniquement au moment du link pour fabriquer un exécutable immobile pendant toute la durée d'une exécution.

En d'autres termes, je ne tiens pas à faire un exécutable autonome, je tiens à faire un exécutable immuable et performant. Si l'utilisation de DLL plutôt que des LIB n'a pas d'impact sur cette unique exigence, je me lancerai alors dans la création de DLL ! (Mais dans ce cas, j'aurais exactement les mêmes questions sur la méthode à suivre pour créer des DLL que celles du fil http://www.developpez.net/forums/d88...l-cpp-express/ auquel tu as déjà répondu, car la procédure pour faire des DLL n'est pas plus claire pour moi que celle qui fabrique des LIB.)

Merci beaucoup de ton aide ! Elle est vraiment très utile pour me décrasser un peu !

[Neitsa]

Bonjour,

Ah oui ? Mais comment un seul emplacement mémoire peut-il être utilisé simultanément par plusieurs processus ? Il y a des variables locales, non ? Au minimum des compteurs de boucles, par exemple. Est-ce qu'une DLL ne contient qu'un seul type de fonctions ?

Les DLLs utilisent ce qu'on appelle le "Copy-On-Write".

D'une manière générale chaque processus "mappe" (met en mémoire) la DLL dans son espace d'adressage. La DLL est placée sur une ou plusieurs pages virtuelles. Mais l'astuce, pour conserver de la mémoire est de faire pointer chacune des pages virtuelles de chaque processus vers la même page physique.

Ainsi si le processus 'A' et le processus 'B' utilise tous deux la DLL 'D', cette dernière peut être affectée à une ou plusieurs pages virtuelles différentes (concrètement la DLL se trouve à une adresse différente dans chaque processus), mais ces pages virtuelles pointent en réalité vers la même page au niveau physique (c-a-d au niveau de la RAM).

Là où le phénomène de copy-on-write prend sa place c'est si les données (pas seulement, mais pour généraliser) de la DLL 'D' sont différentes.
Dans ce cas la page ou les données du processus 'A' et 'B' sont effectivement différentes pointent vers des adresses physiques différentes. Les parties communes aux deux processus reste communes au niveau de la mémoire physique.

Pour l'instant, je ne comprends rien à C++ proprement dit : on peut dire que je code en C (en utilisant Visual C++, bien sûr !). Est-ce que le concept de DLL ne s'applique qu'à des notions propres à C++ ?

Le concept de DLL est un concept répandu dans tous les systèmes d'exploitation modernes. Sous Linux, on les appelle "shared libraries" (bibliothèques partagées), l'appellation "DLL" n'étant que implémentation Microsoft du concept.
Ceci dit, c'est un concept lié à l'O.S plutôt qu'a un langage en particulier.

(euh ! Encore une question bête : c'est quoi VS ? Moi, je parlais de Visual C++ !)

VS : Visual Studio, un IDE regroupant entre autre Visual C++.

la seule chose qui me préoccupe est la performance du programme. A tort ou à raison, j'ai pensé, qu'une DLL était là pour fournir un bout de code de temps en temps lorsqu'un processus en a besoin et que chaque appel provoquait un chargement du code en mémoire, puis un déchargement. Je pense que ce n'est pas le cas, mais si c'est cela, alors cela doit avoir un impact désastreux sur les performances si la fonction en question est appelée des milliards de fois ! Alors, qu'une librairie statique, serait un réservoir de code utilisé uniquement au moment du link pour fabriquer un exécutable immobile pendant toute la durée d'une exécution.

Ca n'est pas le cas. Une DLL reste en espace mémoire (il existe toutefois la possibilité de décharger des DLLs de la mémoire du processus si le chargement est opéré à l'exécution: LoadLibrary() / FreeLibrary()).

Comme le faisait remarquer Mac LAK, la liaison statique vers une bibliothèque n'est pas un choix de performance mais plutôt d'autonomie de l'exécutable vis à vis de dépendance externes.

En d'autres termes, je ne tiens pas à faire un exécutable autonome, je tiens à faire un exécutable immuable et performant. Si l'utilisation de DLL plutôt que des LIB n'a pas d'impact sur cette unique exigence, je me lancerai alors dans la création de DLL !

Comme dit plus tôt, la performance n'est pas un critère de choix dans ce cas.

[ceugniet]

Bonjour,

Et merci d'apporter ton aide...

Comme le faisait remarquer Mac LAK, la liaison statique vers une bibliothèque n'est pas un choix de performance mais plutôt d'autonomie de l'exécutable vis à vis de dépendance externes.



Comme dit plus tôt, la performance n'est pas un critère de choix dans ce cas.

Oui, je sais bien ! C'est moi qui ai parlé de performance, parce que c'est ma seule préoccupation ! J'avais pensé qu'utiliser une dll risquait de ralentir mon exécution : j'ai bien compris que j'avais tort !
Tu m'as convaincu ! Il me reste à comprendre comment les créer, ces librairies, statiques ou dynamiques pour pouvoir mettre en application ce précieux enseignement que vous me fournissez l'un et l'autre.

Merci !

[Mac LAK]

Bien que Neitsa aie répondu à presque tout, je vais faire quelques précisions...

Ah oui ? Mais comment un seul emplacement mémoire peut-il être utilisé simultanément par plusieurs processus ? Il y a des variables locales, non ? Au minimum des compteurs de boucles, par exemple. Est-ce qu'une DLL ne contient qu'un seul type de fonctions ?

C'est effectivement le CODE qui est partagé, pas les données (sauf volonté explicite du développeur, au travers notamment de mémoire partagée).
Ce qui fait donc qu'une DLL est particulièrement adaptée aux fonctions ayant beaucoup de code et peu de données "propres", c'est à dire celles qui n'utilisent guère plus que leurs paramètres.

D'ailleurs, sous Windows, la totalité (ou peu s'en faut) des fonctions du système d'exploitation sont exposées au travers de DLL, et non pas de librairies statiques. Les exceptions sont quelques macros, et la CLib (librairie C) des compilateurs. Et encore... la plupart la proposent en statique ou dynamique, au choix.

Sous Visual, on utilise des "vraies-fausses" librairies statiques d'importation, dont le seul et unique but est de connecter une DLL système de façon transparente : cela t'épargne la corvée de la liaison dynamique si tu ne souhaites pas avoir à le gérer manuellement. Je pense que la plupart des compilateurs sous Windows ont également adopté cette technique.

Est-ce que le concept de DLL ne s'applique qu'à des notions propres à C++ ?

Non, du tout, c'est effectivement un concept du système d'exploitation et non pas d'un langage donné.

Si uniquement les fonctions nécessaires sont incluses dans l'exécutable, je ne comprends pas comment un "gadget" devrait te bouffer 250Mo de RAM !

Oh, facile : il suffit d'avoir "pioché" plusieurs librairies statiques, offrant chacune un petit service, mais qui ont traîné pas mal de dépendances.
Par exemple, j'utilise un vérificateur de mails qui, à lui tout seul, bouffe 40 Mo de mémoire... Heureusement qu'il m'est TRÈS utile, sinon, il aurait fini à la corbeille !
Le pire doit être un système de MAJ pour add-ons d'un célèbre MMORPG : en fonctionnement, c'est 400 Mo de RAM à la poubelle... Du coup, je ne le laisse pas tourner en permanence en tâche de fond, c'est trop coûteux.

Toutes mes questions sont simplement motivées par le besoin de comprendre.

Ce n'est pas un problème : si l'on ne voulait pas te répondre, on ne le ferait pas ! Et puis au moins, ce n'est pas une n-ième demande de "faisage de devoirs"...

Je ne souhaite pas "absolument avoir un exécutable autonome". Je souhaite uniquement pouvoir réutiliser dans divers programmes des fonctions que j'aurais développées une unique fois. Qu'elles soient dans une DLL ou dans une LIB m'indiffère : la seule chose qui me préoccupe est la performance du programme.

Alors une DLL est préférable : en effet, tu peux la tester de façon unitaire, et surtout, si tu l'écris correctement (on en reparlera au besoin), elle est compatible avec la plupart des langages de programmation. Inclus (et de façon non-exhaustive) Delphi, .NET, C++, VB, Java, etc.
Alors qu'une librairie statique n'est utilisable, en général, qu'avec le langage et le compilateur avec lequel elle a été créée.

A tort ou à raison, j'ai pensé, qu'une DLL était là pour fournir un bout de code de temps en temps lorsqu'un processus en a besoin et que chaque appel provoquait un chargement du code en mémoire, puis un déchargement.

On peut effectivement utiliser une DLL de cette manière, c'est notamment ainsi que l'on fabrique les plug-ins. C'est ce que l'on appelle le chargement JIT (Just-In-Time) : cela peut offrir un intérêt non négligeable, mais ce n'est pas obligatoire. On peut aussi se lier à une DLL de façon tout à fait définitive (liaison statique).

Dans le cas d'un chargement JIT, ton programme peut tourner même en l'absence de la DLL. Certes, il ne pourra pas profiter des fonctions implémentées dans la DLL, mais ton programme tourne. Par exemple, il peut fonctionner dans un mode basique et/ou "compatible", et ne profiter de fonctions évoluées qu'avec la bonne DLL.
Inconvénients : il est impossible de savoir, à priori, de quelles DLL ton programme aura besoin si elles sont liées de cette manière. C'est un avantage pour des plug-ins, c'est un gros inconvénient pour des fonctions essentielles.

Dans le cas d'une liaison statique, la DLL est référencée "en dur" dans l'entête de l'image exécutable. On peut savoir quelles sont les DLL d'un programme liées ainsi, via l'outil Dependancy Walker. L'avantage, c'est que l'on sait tout de suite s'il manque une DLL à ton programme ou pas.
L'inconvénient, c'est que sans cette DLL, ton programme ne démarre pas du tout, et tu as un message d'erreur système t'indiquant la DLL manquante.

Dans les deux cas, l'initialisation de la DLL prends le même temps, tout comme l'importation des fonctions. Simplement, la première méthode te fait faire le boulot, la seconde est transparente pour le développeur.

En général, on choisit donc soigneusement le mode d'importation en fonction du besoin réel.

Enfin, côté performances : à moins de charger / décharger la DLL sans arrêt à chaque appel de fonction (chose idiote à faire), la DLL ne "coûte" qu'à l'initialisation du programme, et pas à l'exécution de la fonction. Entre un appel de fonction d'une DLL chargée et l'appel de fonction d'une librairie statique, tu n'auras AUCUNE différence de performances (à l'exception notable du code inliné, mais c'est un autre domaine : l'optimisation lourde du code).

Enfin, un "bon" chargement JIT se fait ainsi : on monte en mémoire la DLL lors du PREMIER appel de la fonction, puis on la laisse en mémoire jusqu'à la fin du programme. On ne décharge donc PAS la DLL à chaque fois que l'on a fini de s'en servir.

En d'autres termes, je ne tiens pas à faire un exécutable autonome, je tiens à faire un exécutable immuable et performant. Si l'utilisation de DLL plutôt que des LIB n'a pas d'impact sur cette unique exigence, je me lancerai alors dans la création de DLL ! (Mais dans ce cas, j'aurais exactement les mêmes questions sur la méthode à suivre pour créer des DLL que celles du fil http://www.developpez.net/forums/d88...l-cpp-express/ auquel tu as déjà répondu, car la procédure pour faire des DLL n'est pas plus claire pour moi que celle qui fabrique des LIB.)

L'avantage d'une DLL, c'est que la correction d'un bug ou l'amélioration des performances du code contenu dans cette librairie n'impose PAS la recompilation des programmes qui l'utilisent.
Ce qui te permet d'ailleurs de diminuer la taille des "patchs" d'un programme, car au lieu de devoir redistribuer un truc monolithique, tu peux ne distribuer QUE les DLL ou EXE modifiés, et pas le reste.

Pour la création d'une DLL, tu coches "Librairie dynamique" à la place de "Librairie statique", et c'est à peu près tout côté création de projet. Je t'encourage vivement à potasser la , sur le chapitre DLL, et à lire les cours / exemples que tu trouveras en lien en bas des FAQ. Ce n'est pas très difficile, et si jamais tu rencontres des problèmes spécifiques, tu sais où poser les questions...

[ceugniet]

Le pire doit être un système de MAJ pour add-ons d'un célèbre MMORPG : en fonctionnement, c'est 400 Mo de RAM à la poubelle... Du coup, je ne le laisse pas tourner en permanence en tâche de fond, c'est trop coûteux.

Je ne comprends toujours pas ! Si ton programme te bouffe 400 Mo de RAM, est-ce que cela ne veut pas dire qu'il a besoin de 400 Mo de RAM ? Veux-tu dire qu'il charge des centaines ou des milliers de fonctions inutiles ? Mais si le link ne charge que les fonctions appelées (comme tu me l'as dit précédemment), comment des fonctions appelées pourraient être inutiles ?

Non, du tout, c'est effectivement un concept du système d'exploitation et non pas d'un langage donné.

Parfait ! Donc, même tant que je me limite à C (je veux dire, tant que je ne comprends pas les subtilités du C++), je peux utiliser ce concept de librairies dynamiques !

Alors une DLL est préférable : en effet, tu peux la tester de façon unitaire

Je ne comprends pas ce que tu veux dire ici !

et surtout, si tu l'écris correctement (on en reparlera au besoin), elle est compatible avec la plupart des langages de programmation. Inclus (et de façon non-exhaustive) Delphi, .NET, C++, VB, Java, etc.
Alors qu'une librairie statique n'est utilisable, en général, qu'avec le langage et le compilateur avec lequel elle a été créée.

Ça aussi je l'ignorais ! Et c'est un argument extrêmement fort en faveur des dll !

Dans le cas d'un chargement JIT, ton programme peut tourner même en l'absence de la DLL. Certes, il ne pourra pas profiter des fonctions implémentées dans la DLL, mais ton programme tourne. Par exemple, il peut fonctionner dans un mode basique et/ou "compatible", et ne profiter de fonctions évoluées qu'avec la bonne DLL.

Je ne comprends pas ! Que se passe-t-il alors lorsqu'une fonction d'une dll absente est appelée ? Est-il possible de "tester" la présence d'une fonction, et de ne l'appeler que si la librairie est là ?
"mais ton programme tourne" C'est magique ça !

L'avantage d'une DLL, c'est que la correction d'un bug ou l'amélioration des performances du code contenu dans cette librairie n'impose PAS la recompilation des programmes qui l'utilisent.

Oui ! Ça je comprends ! C'est effectivement aussi un avantage percutant ! Puisqu'une librairie statique n'est consultée qu'au moment de la création de l'exécutable, il va de soi que pour profiter d'un changement de la librairie, un programme doit être linké à nouveau ! Et réciproquement, la dll, elle, n'est lue qu'à l'exécution et l'exécutable bénéficie immédiatement de la dll telle qu'elle est au moment de l'exécution ! Encore un point pour les librairies dynamiques !

Merci encore ! Mine de rien, je deviens de plus en plus savant

[Mac LAK]

Je ne comprends toujours pas ! Si ton programme te bouffe 400 Mo de RAM, est-ce que cela ne veut pas dire qu'il a besoin de 400 Mo de RAM ? Veux-tu dire qu'il charge des centaines ou des milliers de fonctions inutiles ? Mais si le link ne charge que les fonctions appelées (comme tu me l'as dit précédemment), comment des fonctions appelées pourraient être inutiles ?

Cela veut dire que, pour le peu de fonctions qu'il fait, c'est "anormalement élevé"... Et l'absence de dépendances dynamiques me fait dire qu'il y a eu "abus" au niveau de l'utilisation de librairies statiques.

Je ne comprends pas ce que tu veux dire ici

Que tu peux faire un programme de test de ta DLL, qui va tester TOUTES les fonctions qu'elle exporte. Sauf que, justement, tu n'as PAS besoin de recompiler la DLL pour la faire tester par ce programme, donc si elle marche correctement avec ton programme de test, ce sera le cas aussi avec ton programme final. Et toujours, je le répète, sans avoir à recompiler la DLL.

Ça aussi je l'ignorais ! Et c'est un argument extrêmement fort en faveur des dll !

J'avoue que j'ai toujours du mal à comprendre le point de vue de certains qui veulent à tout prix des librairies statiques "pour avoir un EXE unique"...

Je ne comprends pas ! Que se passe-t-il alors lorsqu'une fonction d'une dll absente est appelée ? Est-il possible de "tester" la présence d'une fonction, et de ne l'appeler que si la librairie est là ?
"mais ton programme tourne" C'est magique ça !

En fait, le chargement JIT va échouer si la DLL est absente. Jusque là, c'est normal.
Mais tout le programme avant fonctionnera SANS avoir encore appelé le chargement, donc il fonctionne "normalement". Ce n'est qu'à l'appel de la fonction normalement située dans la DLL (ex : un traitement particulier sur une donnée de l'utilisateur) que tu auras une erreur.
Mais le reste du programme reste utilisable, comme par exemple fabriquer la configuration finale.

Oui ! Ça je comprends ! C'est effectivement aussi un avantage percutant ! Puisqu'une librairie statique n'est consultée qu'au moment de la création de l'exécutable, il va de soi que pour profiter d'un changement de la librairie, un programme doit être linké à nouveau ! Et réciproquement, la dll, elle, n'est lue qu'à l'exécution et l'exécutable bénéficie immédiatement de la dll telle qu'elle est au moment de l'exécution ! Encore un point pour les librairies dynamiques !

C'est bien ça.