Dovrei aggiungere la fonte delle librerie invece di collegarle a loro?

13

Sono relativamente nuovo al C ++, quindi non sono sicuro di come gestire al meglio piccole dipendenze (ad es., un linguaggio di scripting o un parser JSON / YAML / XML).

Devo creare progetti separati e collegarli come libreria statica, oppure ci sono dei lati negativi nel mettere semplicemente i file .h / .cpp nel mio progetto principale?

Quest'ultima sembra molto più semplice perché ho passato diverse ore a gestire le librerie incompatibili (diverse impostazioni del compilatore quando costruisci la libreria), ma non voglio iniziare a imparare C ++ nel modo sbagliato.

Se è preferibile tenerli come librerie separate, come farei a mantenere i flag di compilazione in sincronia in modo che i file .lib / .a si colleghino correttamente alla mia applicazione?

(Attualmente sto lavorando con MSVC 2015, ma l'obiettivo è compilare su Mac OS X e iOS usando XCode / clang, in modo da avere a che fare con almeno 3 diversi tipi di librerie (Win x86, Mac x64 , ARM))

    
posta Michael Stum 26.03.2016 - 13:59
fonte

2 risposte

3

TLDR;

Dovrebbe tu aggiungere la fonte? YES
Dovrebbe X aggiungere la fonte? DIPENDE

Ecco il perché ...

Nel passato, il tempo di compilazione era un problema anche per i progetti più piccoli. Compilare le tue fonti e non preoccuparti mai di memorizzare nella cache i risultati del compilatore era decisamente allettante per alcuni. Questo è un punto per le librerie irrilevante per te.

Un altro importante è il controllo delle versioni. Hai davvero bisogno di versionare ciascuna libreria separatamente? Esegui test contro ciascuno di essi? Distribuirlo tra molti membri del team? Le biblioteche sono fantastiche se lo fai, e comodo muoversi, ma di nuovo, sembra che non ti interessi neanche a questo.

Il punto finale è che si tratta di un overhead aggiuntivo e il rilascio dei file di origine è più semplice nel tuo caso, il che dà un punto molto importante per far cadere i sorgenti piuttosto che usare le librerie. Come avrai notato, una volta che hai modificato un singolo compilatore, devi inseguire tutte le dipendenze altrimenti.

Conosco tutto questo per esperienza:

Per i progetti Swift, utilizzo sicuramente framework (librerie) e link a loro, poiché è facile da configurare usando Xcode. Ho anche davvero bisogno del controllo delle versioni, dei test e del disaccoppiamento, ecco perché.

Per i progetti Mono (C #), per Unity, ho iniziato con l'approccio alla moda di suddividere il progetto in librerie, compilato e testato ognuna, il che è stato grandioso ... ma una volta ho abbandonato le librerie in Unity, tutti i tipi di problemi accaduti, dalla versione compromessa degli usi di Mono Unity, al semplice comportamento a volte diverso che il codice mostra quando si cambiano le piattaforme. Non avere un singolo IDE qui per gestire tutte le librerie è stato un vero dolore, quindi mettere tutte le risorse all'interno di Unity è stata una grande vittoria per la produttività.

Infine, più pertinente per te, un progetto di gioco C ++ su cui ho lavorato. Un motore di gioco, un client di rete in tempo reale, un client HTTP di rete, un AI e un archivio di persistenza sono stati scritti per questo gioco, solo dal lato client. Per cosa ho optato? CLion + Librerie. Anche se stavo usando le librerie, non mi sentivo come se fossi. Tutte le fonti erano nel progetto IDE di CLion e, componendo le CMakeList, ero in grado di attivare tutte le build e collegarle in un colpo solo.

In conclusione , direi che usare le librerie è una soluzione a prova di futuro, ma anche un'ottimizzazione prematura se non necessaria. Per quanto ho potuto accertare dalla tua situazione, passare da MSVC a Xcode sarà un problema se avrai più target di build. Quindi, basta rilasciarlo e mantenere quanto più isolamento possibile per quando il tempo in cui potrebbe avere bisogno di usare le librerie.

P.S: Sto avendo un dilemma simile in questi giorni con docker. Dovrei comporre? Dovrei solo correre localmente? .. ecc. Anche Elixir, in quanto consente di creare Applicazioni all'interno della stessa applicazione. Devo farlo? O separare l'app nei cosiddetti micro-servizi? ... ecc. Non esiste un proiettile d'argento, misuri sempre te stesso, come YMMV.

    
risposta data 27.03.2016 - 08:24
fonte
0

Direi di sì, purché sia più facile. Ci sono molti vantaggi:

  1. Produrrà un codice più veloce e migliore, soprattutto se attivi Link Time Optimization.

  2. L'IDE apprezzerà di più, ad es. (si spera) consentirà di passare all'implementazione (.cpp) del codice della libreria, anziché solo all'interfaccia (.h), che è estremamente utile quando si lavora con codice mal documentato (cioè la maggior parte codice).

  3. Spesso consente di aggiungere la dipendenza come un sottomodulo git, che è un po 'hacky ma in realtà è un buon modo per avere delle dipendenze (per C ++ comunque, che non ha praticamente nessun sistema di generazione sensato). Rende molto semplice l'aggiornamento della libreria e il test delle diverse versioni.

  4. Non devi preoccuparti di una dipendenza che viene compilata con MSVC ++ 2013, mentre per esempio stai usando il 2017. O condiviso con MSVCRT statico.

  5. Puoi facilmente creare in modalità di debug e accedere alla libreria.

L'unica ragione per cui penso che non vuoi fare, è se la libreria è grande e ha un sistema di generazione complesso che non vuoi replicare nel tuo, ad es. Boost o LLVM. Ma per le librerie semplici non c'è davvero nessun svantaggio.

Ad esempio, utilizzo libusb in alcuni progetti e devo supportare Windows. libusb usa autotools che è uno scherzo di un sistema di compilazione e comunque non funziona su Windows. Forniscono binari precompilati ma sono costruiti con MSVC ++ 2013 e non funzioneranno con il 2017. La soluzione più semplice di gran lunga era solo quella di aggiungere tutti i file .c e .h pertinenti al mio progetto.

    
risposta data 10.04.2018 - 10:55
fonte

Leggi altre domande sui tag