Liaison statique ou dynamique entre le CRT, le MFC, l’ATL, etc.

Question

Dans les années 90, lorsque j'ai commencé à utiliser MFC, je liais de manière dynamique mes applications et livrais les DLL MFC correspondantes. Cela m'a causé quelques problèmes (enfer de DLL!) Et je suis passé à la place de la liaison statique - pas seulement pour MFC, mais aussi pour le CRT et ATL. À part les fichiers EXE plus volumineux, la liaison statique ne m'a jamais posé aucun problème - y a-t-il donc des inconvénients que d'autres personnes ont rencontrés? Existe-t-il une bonne raison de revenir à la création de liens dynamiques? Mes applications sont principalement STL / Boost de nos jours FWIW.

Answer 1

Il y a des inconvénients:

• Plus grande taille exe (surtout si vous expédiez plusieurs exe)
• Problèmes liés à l'utilisation d'autres DLL qui reposent ou supposent une liaison dynamique (exemple: DLL tierces que vous ne pouvez pas obtenir en tant que bibliothèques statiques)
• Différentes durées d'exécution C entre les DLL avec liaison statique indépendante (pas d'allocation / désaffectation de modules croisés)
• Pas de maintenance automatique des composants partagés (aucune possibilité pour un fournisseur de module tiers de mettre à jour son code pour résoudre les problèmes sans recompiler ni mettre à jour votre application)

Nous établissons des liens statiques pour nos applications Windows, principalement parce qu’ils permettent le déploiement de xcopy, ce qui n’est pas possible avec l’installation ou le recours à la DLL SxS d’une manière qui fonctionne, car le processus et le mécanisme ne sont pas bien documentés et ne sont pas facilement accessibles à distance. Si vous utilisez des DLL locales dans le répertoire d'installation, cela fonctionnera un peu, mais ce n'est pas bien supporté. L'impossibilité d'effectuer facilement une installation distante sans passer par un MSI sur le système distant est la principale raison pour laquelle nous n'utilisons pas de liaison dynamique, mais (comme vous l'avez souligné), la liaison statique présente de nombreux autres avantages. Il y a des avantages et des inconvénients pour chacun; Espérons que cela aide à les énumérer.

Answer 2

La plupart des réponses que j'entends à ce sujet impliquent de partager vos dll avec d'autres programmes, ou de les mettre à jour, sans qu'il soit nécessaire de corriger votre logiciel.

Franchement, j'estime que ce sont des inconvénients et non des inconvénients. Lorsqu'un tiers DLL est mis à jour, il peut changer suffisamment pour casser votre logiciel. Et ces jours-ci, l’espace disque dur n’est plus aussi précieux qu’il ne l’était autrefois, 500 Ko supplémentaires dans votre exécutable? On s'en fout?

• Être sûr à 100% de la version de dll utilisée par votre logiciel est une bonne chose.
• Il est bon d’être sûr à 100% que le client n’aura pas de maux de tête de dépendance.

Les points positifs l'emportent largement sur les inconvénients à mon avis

Answer 3

Tant que vous gardez votre utilisation limitée à certaines bibliothèques et que vous n'utilisez aucune dll, vous devriez être bon.

Malheureusement, certaines bibliothèques ne peuvent pas être liées statiquement. Le meilleur exemple que j'ai est OpenMP. Si vous tirez parti du support OpenMP de Visual Studio, vous devrez vous assurer que le moteur d’exécution est installé (dans ce cas, vcomp.dll).

Si vous utilisez des dll, vous ne pourrez pas faire circuler certains éléments sans une gymnastique sérieuse. std :: strings viennent à l'esprit. Si vos fichiers exe et dll sont liés dynamiquement, l’allocation a lieu dans le tube cathodique. Sinon, votre programme pourrait essayer d’allouer la chaîne d’un côté et de la désallouer de l’autre. De mauvaises choses en découlent ...

Cela dit, je lie toujours statiquement mes exe et dll. Cela réduit beaucoup les variations dans l’installation et j’estime que les quelques limitations en valent la peine.

Answer 4

L’utilisation des DLL est un avantage: si plusieurs processess chargent la même DLL, leur code peut être partagé entre eux. Cela peut économiser de la mémoire et raccourcir les temps de chargement d’une application qui charge une DLL déjà utilisée par un autre programme.

Answer 5

Non, rien de nouveau sur ce front. Continuez comme ça.

Answer 6

Très certainement.

L'allocation est effectuée sur un segment de mémoire "statique". Étant donné qu’une allocation doit être effectuée sur le même segment de mémoire, cela signifie que si vous expédiez une bibliothèque, veillez à ce que le code client ne puisse pas appeler "votre" p = new LibClass () et le supprimer. l'objet lui-même à l'aide de delete p; .

Ma conclusion: soit protéger l’allocation et la désallocation du code client, soit lier dynamiquement le tube cathodique.

Answer 7

Certaines licences logicielles, telles que LGPL, vous obligent à utiliser une DLL ou à distribuer votre application sous forme de fichiers objets que l'utilisateur peut lier entre eux. Si vous utilisez une telle bibliothèque, vous voudrez probablement l’utiliser comme une DLL.