Dovremmo "bilanciare" la quantità di codici tra .h e .cpp?

Naviga le tue risposte
2

Per quanto ne so, .cpp di solito contiene molti più codici di .h, principalmente perché .cpp contiene i dettagli di implementazione delle funzioni invece di una sola riga della definizione di membro / metodo della classe.

Mi viene in mente un'idea piuttosto strana: è buona pratica scrivere o migrare alcuni contenuti o codici da .cpp a .h, al fine di ridurre la quantità di codici in .cpp?

So che non dovremmo scrivere tutto nell'intestazione per:

  1. Impedisci un tempo di compilazione extra durante la ricompilazione dei codici dopo la modifica del contenuto nell'intestazione

  2. Impedisci di includere un'intestazione da un'altra intestazione che non è necessaria per ogni unità di compilazione (ad esempio: spaghetti di intestazione precedenti)

ma penso che alcuni contenuti possano essere spostati nell'intestazione "in sicurezza", come la documentazione della funzione e le funzioni che soddisfano tutte le condizioni seguenti:

  1. Funzioni raramente modificate

  2. Funzioni semplici o banali (ad es .: set e getter)

  3. Funzioni che non portano a dichiarazioni di inclusione extra in cpp

e il vantaggio del vantaggio di spostare le funzioni sulle intestazioni è che possiamo dichiarare quelle funzioni come inline che migliorano ulteriormente le prestazioni.

È buona norma restringere la differenza del numero di riga tra l'intestazione e i file .cpp corrispondenti?

    
posta ggrr 29.03.2016 - 08:51
fonte

2 risposte

9

Non c'è alcun vantaggio nel mettere il codice nelle intestazioni solo per bilanciare la quantità di codice nelle intestazioni e nei file cpp. A meno che non trovi esteticamente gradevole, immagino?

Esistono, tuttavia, una serie di motivi per cui i file di intestazione devono essere contenuti, in gran parte relativi all'uso effettivo di tali elementi in più unità di compilazione. Ad esempio, se si desidera consentire al compilatore di incorporare una funzione o quando si desidera poter utilizzare un modello in più unità di compilazione.

Ci sono anche ottime ragioni per evitare di inserire elementi nei file di intestazione. Primo fra tutti è che la modifica di un file cpp dovrebbe significare solo la ricompilazione di quel file cpp (a meno che l'interfaccia non sia cambiata, ma non si modifica solo quel file), mentre una modifica a un file di intestazione significa la ricompilazione di tutti i file che includono direttamente o indirettamente.

    
risposta data 29.03.2016 - 09:44
fonte
4

In primo luogo, C ++ (intendo almeno C ++ 11) sta praticamente parlando lentamente per essere compilato, in particolare perché la libreria standard è per lo più codice di sola intestazione e le intestazioni standard estraggono un lotto di codice (ad esempio <vector> sta tirando le linee 10K su un recente GCC di Linux 5!), e tu? Sarà meglio usare i contenitori standard abbastanza spesso. Un possibile trucco potrebbe essere intestazioni precompilate , ma questi hanno anche degli svantaggi e praticamente è necessario avere un single header (che è #include -ing un sacco di intestazioni di sistema o di libreria) per farlo funzionare bene.

(se hai tempo - e ne avrai bisogno in abbondanza-, potresti aiutare il comitato standard del C ++ - dare il benvenuto a feedback costruttivi- e contribuire per compilatori di software libero C ++ come GCC o Clang / LLVM )

Quindi (a meno che tu non attivi sistematicamente ottimizzazioni link-time -che rallenta molto il tempo di compilazione, per esempio almeno di un fattore due-, ad esempio compila e link con g++ -flto -O2 su un recente GCC ), un'intestazione deve contenere quelle funzioni che si desidera essere inline , e praticamente parlando in autentico codice C ++ 11 hai un sacco di funzioni inline .

Alcune persone (compresi alcuni implementatori di librerie C ++ standard) stanno fisicamente separando parte della parte "implementazione" dell'intestazione in un file separato (ma #include -d da alcuni pubblici file header), principalmente per motivi di leggibilità. Ad esempio, sul mio GCC 5 Linux, /usr/include/c++/5/bits/deque.tcc è indirettamente incluso dall'intestazione <deque> (e altro).

I futuri standard C ++ potrebbero definire alcuni meccanismi modulo (ma non in C ++ 17 !)

Is it a good practice to narrow the line number difference between header and corresponding cpp files?

Non sono un madrelingua inglese, quindi ho difficoltà a capire cosa intendi veramente, ma suppongo che ti riferisci ad avere file di intestazione piuttosto grandi (forse #include -ing alcune intestazioni di "dettagli di implementazione"). Va bene. In particolare, i modelli praticamente devono essere implementati principalmente nei file di intestazione.

    
risposta data 29.03.2016 - 09:07
fonte

Leggi altre domande sui tag

Quando era l'ambito del blocco per le variabili introdotte in C, e perché è ancora disapprovato? Perché non svuotare i file iterabili in python sollevano eccezioni quando provi a scorrere su di loro [duplicato]