Collegamento statico o dinamico di CRT, MFC, ATL, ecc

Question

Negli anni '90, quando ho iniziato con MFC, collegavo dinamicamente le mie app e spedivo le DLL MFC pertinenti. Questo mi ha causato alcuni problemi (inferno DLL!) E sono passato invece al collegamento statico, non solo per MFC, ma per CRT e ATL. A parte i file EXE più grandi, il collegamento statico non mi ha mai causato alcun problema, quindi ci sono degli aspetti negativi che altre persone hanno riscontrato? C'è una buona ragione per rivisitare nuovamente il collegamento dinamico? Le mie app sono principalmente STL / Boost al giorno d'oggi FWIW.

Answer 1

Ci sono alcuni aspetti negativi:

• Dimensioni exe più grandi (specialmente se spedisci più exe)
• Problemi nell'utilizzo di altre DLL che si basano su o assumono collegamenti dinamici (ad es. DLL di terze parti che non è possibile ottenere come librerie statiche)
• Diversi runtime della c tra DLL con collegamento statico indipendente (nessuna allocazione / deallocazione tra i moduli)
• Nessuna manutenzione automatica dei componenti condivisi (nessuna possibilità che un fornitore di moduli di terze parti aggiorni il proprio codice per risolvere i problemi senza ricompilare e aggiornare l'applicazione)

Eseguiamo collegamenti statici per le nostre app di Windows, principalmente perché consente la distribuzione di xcopy, il che non è possibile con l'installazione o il ricorso alle DLL SxS in un modo che funzioni, poiché il processo e il meccanismo non sono ben documentati o facilmente remotabili. Se usi le DLL locali nella directory di installazione funzionerà, ma non è ben supportato. L'incapacità di eseguire facilmente l'installazione remota senza passare attraverso un MSI sul sistema remoto è il motivo principale per cui non utilizziamo il collegamento dinamico, ma (come hai sottolineato) ci sono molti altri vantaggi del collegamento statico. Ci sono pro e contro per ciascuno; speriamo che questo aiuti a enumerarli.

Answer 2

La maggior parte delle risposte di cui ho sentito parlare riguarda la condivisione delle tue dll con altri programmi o la necessità di aggiornare tali dll senza la necessità di patchare il tuo software.

Francamente considero quelli i lati negativi, non i lati positivi. Quando una dll di terze parti viene aggiornata, può cambiare abbastanza da interrompere il software. E in questi giorni, lo spazio sul disco rigido non è prezioso come una volta, un extra di 500k nel tuo eseguibile? Che importa?

• Essere sicuri al 100% della versione di DLL utilizzata dal software è una buona cosa.
• Essere sicuri al 100% che il client non avrà mal di testa da dipendenza è una buona cosa.

A mio avviso, gli aspetti positivi superano di gran lunga gli aspetti negativi

Answer 3

Fintanto che mantieni il tuo uso limitato a determinate librerie e non usi alcuna dll, dovresti essere buono.

Sfortunatamente, ci sono alcune librerie che non puoi collegare staticamente. Il miglior esempio che ho è OpenMP. Se si utilizza il supporto OpenMP di Visual Studio, è necessario assicurarsi che il runtime sia installato (in questo caso vcomp.dll).

Se usi le DLL allora non puoi passare alcuni oggetti avanti e indietro senza una certa ginnastica seria. std :: stringhe vengono in mente. Se exe e dll sono collegati dinamicamente, l'allocazione avviene nel CRT. In caso contrario, il programma potrebbe tentare di allocare la stringa da un lato e deallocare dall'altro. Ne derivano cose brutte ...

Detto questo, continuo a collegare staticamente i miei exe e quelli di dll. Riduce gran parte della variabilità nell'installazione e ritengo che valga la pena le poche limitazioni.

Answer 4

Una buona caratteristica dell'uso delle dll è che se più processi caricano la stessa dll, il loro codice può essere condiviso tra loro. Questo può risparmiare memoria e ridurre i tempi di caricamento di un'applicazione che carica una dll che è già utilizzata da un altro programma.

Answer 5

No, niente di nuovo su quel fronte. Continua così.

Answer 6

Sicuramente.

L'allocazione viene eseguita su un heap 'statico'. Poiché l'allocazione di una deallocazione deve essere eseguita sullo stesso heap, ciò significa che se si spedisce una libreria, è necessario assicurarsi che il codice client non possa chiamare "your" p = new LibClass () ed eliminarlo stesso oggetto utilizzando delete p; .

La mia conclusione: proteggere l'allocazione e la deallocazione dal codice client o collegare dinamicamente il CRT.

Answer 7

Esistono alcune licenze software come LGPL che richiedono l'utilizzo di una DLL o la distribuzione dell'applicazione come file oggetto che l'utente può collegare insieme. Se stai usando una libreria del genere, probabilmente vorrai usarla come una DLL.