c++ - riconosciuto - esempio di makefile c



# include tutti i file.cpp in una singola unità di compilazione? (4)

Recentemente ho avuto motivo di lavorare con alcuni progetti di Visual Studio C ++ con le solite configurazioni di Debug e Release, ma anche "Release All" e "Debug All", che non avevo mai visto prima.

Si scopre che l'autore dei progetti ha un singolo ALL.cpp che include tutti gli altri file .cpp. * Tutte le configurazioni creano solo questo un file ALL.cpp. Ovviamente è escluso dalle configurazioni regolari e le configurazioni regolari non creano ALL.cpp

Mi chiedevo solo se fosse una pratica comune? Che benefici porta? (La mia prima reazione fu che puzzava male).

Quali sono le insidie ​​che potresti incontrare con questo? Quello che posso pensare è che se hai spazi dei nomi anonimi nel tuo .cpps, non sono più 'privati' per quel cpp ma ora sono visibili anche in altri cpps?

Tutti i progetti creano DLL, quindi disporre di dati in spazi dei nomi anonimi non sarebbe una buona idea, giusto? Ma le funzioni sarebbero OK?

Saluti.


Answer #1

Mi chiedo se ALL.cpp stia tentando di mettere l'intero progetto all'interno di una singola unità di compilazione, per migliorare la capacità del compilatore di ottimizzare il programma per le dimensioni?

Normalmente alcune ottimizzazioni vengono eseguite solo all'interno di unità di compilazione distinte, come la rimozione di codice duplicato e inlining.

Detto questo, mi sembra di ricordare che i recenti compilatori (Microsoft, Intel, ma non credo che questo includa GCC) possono fare questa ottimizzazione su più unità di compilazione, quindi sospetto che questo "trucco" non sia necessario.

Detto questo, sarebbe curioso vedere se c'è davvero qualche differenza.


Answer #2

Viene indicato da alcuni (e google-able) come una "Unity Build". Si collega in modo follemente veloce e si ricompone abbastanza velocemente. È fantastico per le build su cui non è necessario eseguire iterazioni, come una build di rilascio da un server centrale, ma non necessariamente per la creazione incrementale.

Ed è un PITA da mantenere.

EDIT: ecco il primo link di Google per maggiori informazioni: http://buffered.io/posts/the-magic-of-unity-builds/

La cosa che lo rende veloce è che il compilatore deve solo leggere tutto in una volta, compilare, quindi collegare, piuttosto che farlo per ogni file .cpp.

Bruce Dawson ha scritto molto meglio su questo nel suo blog: http://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/


Answer #3

Sono d'accordo con Bruce; dalla mia esperienza ho provato a implementare Unity Build per uno dei miei progetti .dll che includeva un sacco di header e un sacco di .cpps; per ridurre il tempo Compilation complessivo sul VS2010 (aveva già esaurito le opzioni di Build incrementali) ma piuttosto che ridurre il tempo di Compilation, ho esaurito la memoria e Build non è nemmeno riuscito a finire la Compilation.

Tuttavia da aggiungere; Ho trovato che abilitare l'opzione Compilatore multiprocessore in Visual Studio aiuta a ridurre il tempo di compilazione; Non sono sicuro che tale opzione sia disponibile su altri compilatori di piattaforme.






build