Utilizzo di librerie di classi (dll) - Riferimento o origine di copia

0

Sto lavorando a un grande progetto per la prima volta e in questo momento sto usando 15 dll da fonti diverse. Avere tutte queste dll nella mia directory di output insieme al mio .exe sta "inquinando" quella cartella molto.

Dalla maggior parte di questi dll ho il codice sorgente che posso copiare in una singola dll di mio riducendo la quantità di dll che ho nella cartella .exe. Questo sembra un compito noioso però ... Il fatto è che, ogni progetto che farò in futuro userà alcune di queste DLL perché hanno alcuni controlli molto utili. (Una di queste dll è il WPF Toolkit .)

In cosa consiste: C'è un modo semplice per ridurre la quantità di dll nella cartella .exe? Avere così tante dll è brutto? Copiare il codice sorgente nel tuo progetto è un anti-pattern?

    
posta Krowi 11.09.2015 - 16:28
fonte

1 risposta

2

Avere molte DLL non è necessariamente male. Storicamente, le DLL hanno due principali compromessi:

  1. Richiedono più tempo durante il caricamento. Quando richiesto, devono essere caricati nella memoria e posizioni mappate per consentire il salto nelle posizioni delle funzioni. Se una DLL non è precaricata all'avvio del programma, questo potrebbe significare pause durante il caricamento di un programma.

  2. Richiedono meno spazio, supponendo che le DLL siano posizionate centralmente e riutilizzate in più programmi.

Tuttavia, l'hardware moderno annulla questi attributi. I computer moderni sono così veloci che, a meno che tu non abbia letteralmente centinaia di DLL da caricare, il ritardo sarà quasi impercettibile, se non del tutto. Le moderne capacità di archiviazione sono attraverso il tetto e lo spazio extra richiesto dalle librerie di condivisione non non viene generalmente notato. Il mio telefono Android ha uno spazio di archiviazione di due ordini di grandezza maggiore rispetto al mio primo computer desktop (e alcuni dei vecchi timer qui in giro possono superarlo).

Se sei ancora preoccupato di questo, considera il collegamento statico delle tue librerie al programma eseguibile. Non copiare semplicemente il codice sorgente .

Il collegamento statico presenta alcuni potenziali vantaggi:

  1. Non devi mai preoccuparti di utilizzare la versione errata di una DLL.
  2. Se riesci a ridimensionare il tuo programma in un singolo file, diventa più facile rendere portatile . Si noti che questo non è né necessario né sufficiente per rendere portatile un'app, ma semplifica il lavoro. Questo può o non può essere un problema.
  3. I moderni linker fanno un buon lavoro rimuovendo il dead code durante il collegamento statico. Ad esempio, ho visto DLL nelle decine di megabyte. I toolkit come Qt possono essere così grandi. Se si utilizza solo una piccola parte del toolkit, prendere in considerazione il collegamento statico. Il linker può rimuovere tutto il codice inutilizzato (morto), portando la dimensione combinata del codice e il codice della libreria in qualcosa di molto più ragionevole.
  4. Salvare il meglio per ultimo: alcuni compilatori supportano ottimizzazioni di interi programmi . Ciò può potenzialmente aumentare la velocità di esecuzione del programma, in genere a un costo elevato durante la compilazione.

C'è uno svantaggio nel collegamento statico di una grande quantità di codice nell'eseguibile principale:

  1. Il tempo di caricamento iniziale è più lungo. L'intero eseguibile deve normalmente essere caricato in memoria, i globali inizializzati, la logica di ingresso, ecc. Prima che possa essere chiamato main() . Questo potrebbe essere un lungo ritardo prima che il controllo passi al tuo programma. Alcuni programmi più grandi (ad esempio, MS Office) aggirano questo problema scaricando gran parte del programma in DLL che vengono caricate dopo il richiamo di main() : ciò consente di visualizzare una schermata di avvio (caricamento). Se si collega statico tutto, non è possibile farlo.

Questo potrebbe non essere nemmeno un problema per te. La maggior parte dei programmi non è abbastanza grande da richiedere una schermata di caricamento. Inoltre, l'hardware moderno è fulmineo rispetto ai periodi bui in cui questa è stata una decisione davvero seria.

È fondamentale non copiare semplicemente il codice sorgente:

  1. La maggior parte, se non tutte, le licenze approvate OSI ti consentiranno di collegare unità di codice. Questo fa parte di ciò che rende "open source" "aperto".
  2. Il codice di collegamento riduce l'accoppiamento rispetto al codice di copia. Sebbene i riferimenti al codice siano gli stessi, è più semplice eseguire l'aggiornamento a una versione più recente della libreria se è sufficiente inserire una nuova libreria statica e collegarla.
  3. A seconda della compatibilità delle licenze utilizzate nel codice e in ogni libreria, potrebbe non essere consentito copiare il codice e continuare a essere conforme alle licenze. Ciò potrebbe creare un lavoro derivativo o combinato , che apre diverse lattine di worm (una lattina per ogni combinazione di licenze). Questo è un mal di testa che non vuoi . Un'ulteriore discussione sull'argomento è pericolosamente vicina alla consulenza legale, quindi consiglio semplicemente di evitare l'intero problema e di seguire la rotta di collegamento dopo aver letto le licenze pertinenti .
risposta data 11.09.2015 - 17:02
fonte

Leggi altre domande sui tag