Qual è la differenza tra librerie statiche e condivise?
Uso Eclipse e ci sono diversi tipi di progetto tra cui librerie statiche e librerie condivise? Uno ha un vantaggio rispetto all'altro?
Risposte:
Le librerie condivise sono file .so (o in Windows .dll o in OS X .dylib). Tutto il codice relativo alla libreria si trova in questo file ed è referenziato dai programmi che lo utilizzano in fase di esecuzione. Un programma che utilizza una libreria condivisa fa solo riferimento al codice che utilizza nella libreria condivisa.
Le librerie statiche sono file .a (o in Windows .lib). Tutto il codice relativo alla libreria si trova in questo file ed è direttamente collegato al programma in fase di compilazione. Un programma che utilizza una libreria statica prende copie del codice che utilizza dalla libreria statica e lo rende parte del programma. [Windows ha anche file .lib che vengono utilizzati per fare riferimento ai file DLL, ma funzionano allo stesso modo del primo].
Ci sono vantaggi e svantaggi in ciascun metodo:
Le librerie condivise riducono la quantità di codice duplicato in ciascun programma che utilizza la libreria, mantenendo i binari piccoli. Inoltre, consente di sostituire l'oggetto condiviso con uno che è funzionalmente equivalente, ma potrebbe avere aggiunto benefici in termini di prestazioni senza dover ricompilare il programma che lo utilizza. Le librerie condivise avranno tuttavia un piccolo costo aggiuntivo per l'esecuzione delle funzioni e un costo di caricamento in fase di esecuzione poiché tutti i simboli nella libreria devono essere collegati alle cose che usano. Inoltre, le librerie condivise possono essere caricate in un'applicazione in fase di esecuzione, che è il meccanismo generale per l'implementazione dei sistemi di plug-in binari.
Le librerie statiche aumentano le dimensioni complessive del file binario, ma ciò significa che non è necessario portare con sé una copia della libreria in uso. Poiché il codice è collegato in fase di compilazione, non ci sono costi di caricamento aggiuntivi in fase di esecuzione. Il codice è semplicemente lì.
Personalmente, preferisco le librerie condivise, ma utilizzo le librerie statiche quando è necessario assicurarsi che il binario non abbia molte dipendenze esterne che potrebbero essere difficili da soddisfare, come versioni specifiche della libreria standard C ++ o versioni specifiche della libreria Boost C ++.
Una libreria statica è come una libreria e una libreria condivisa è come ... una libreria. Con il primo, ottieni la tua copia del libro / funzione da portare a casa; con quest'ultimo tu e tutti gli altri andate in biblioteca per usare lo stesso libro / funzione. Quindi, chiunque desideri utilizzare la libreria (condivisa) deve sapere dove si trova, perché è necessario "andare a prendere" il libro / la funzione. Con una libreria statica, il libro / la funzione sono tuoi e lo mantieni nella tua casa / programma, e una volta che lo hai non ti interessa dove o quando l'hai preso.
semplificata:
Per una libreria statica, il codice viene estratto dalla libreria dal linker e utilizzato per creare l'eseguibile finale nel punto in cui si compila / si crea la propria applicazione. L'eseguibile finale non ha dipendenze dalla libreria in fase di esecuzione
Per una libreria condivisa, il compilatore / linker verifica che i nomi con cui si collega esistano nella libreria quando viene creata l'applicazione, ma non sposta il loro codice nell'applicazione. In fase di esecuzione, la libreria condivisa deve essere disponibile.
Lo stesso linguaggio di programmazione C non ha alcun concetto di librerie statiche o condivise - sono completamente una funzionalità di implementazione.
Personalmente, preferisco di gran lunga usare le librerie statiche, poiché semplifica la distribuzione del software. Tuttavia, questa è un'opinione sulla quale molto sangue (figurativo) è stato versato in passato.
Le librerie statiche vengono compilate come parte di un'applicazione, mentre le librerie condivise non lo sono. Quando si distribuisce un'applicazione che dipende da librerie condivise, le librerie, ad es. dll su MS Windows deve essere installato.
Il vantaggio delle librerie statiche è che non sono necessarie dipendenze per l'utente che esegue l'applicazione, ad esempio non è necessario aggiornare la propria DLL di qualunque cosa. Lo svantaggio è che la tua applicazione ha dimensioni maggiori perché la stai spedendo con tutte le librerie di cui ha bisogno.
Oltre a portare ad applicazioni più piccole, le librerie condivise offrono all'utente la possibilità di utilizzare la propria versione forse migliore delle librerie piuttosto che fare affidamento su una che fa parte dell'applicazione
Il vantaggio più significativo delle librerie condivise è che esiste una sola copia di codice caricata in memoria, indipendentemente dal numero di processi che utilizzano la libreria. Per le librerie statiche ogni processo ottiene la propria copia del codice. Ciò può comportare un significativo spreco di memoria.
OTOH, un vantaggio delle librerie statiche è che tutto è raggruppato nella tua applicazione. Quindi non devi preoccuparti che il client avrà la libreria (e la versione) giusta disponibile sul proprio sistema.
.sofile su sistemi * nix sono in genere una libreria condivisa (dinamica).
Oltre a tutte le altre risposte, una cosa non ancora menzionata è il disaccoppiamento:
Lasciatemi parlare di un codice di produzione del mondo reale, con cui ho avuto a che fare:
Un software molto grande, composto da> 300 progetti (con Visual Studio), costruito principalmente come lib statica e infine tutti collegati in un unico eseguibile enorme, si finiscono con i seguenti problemi:
-Il tempo di collegamento è estremamente lungo. Potresti finire con più di 15 minuti di link, diciamo 10 di tempo di compilazione -Alcuni strumenti sono in ginocchio con un eseguibile così grande, come strumenti di controllo della memoria che devono strumentare il codice. Potresti cadere nei limiti che erano stati visti come sciocchi.
Più problematico è il disaccoppiamento del software: in questo esempio del mondo reale, i file delle intestazioni di ogni progetto erano raggiungibili da qualsiasi altro progetto. Di conseguenza è stato estremamente facile per uno sviluppatore aggiungere dipendenze; era solo per includere l'intestazione, perché il link alla fine troverà tutti i simboli. Finisce con orribili dipendenze ciclistiche e disordine completo.
Con la libreria condivisa, è un po 'più lavoro perché lo sviluppatore deve modificare il sistema di compilazione del progetto per aggiungere la libreria dipendente. Ho osservato che il codice della libreria condivisa tende a offrire un'API di codice più pulita.
-------------------------------------------------------------------------
| +- | 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 | |
-------------------------------------------------------------------------