Intestazione per file sorgente

Question

Sto cercando di capire lo scopo dietro un'intestazione per ogni metodo del file sorgente. Per come la vedo io, le intestazioni sono pensate per condividere dichiarazioni di funzioni, typedef e macro tra diversi file che li utilizzano. Quando si crea un file di intestazione per il file .c ha lo svantaggio che ogni volta che si desidera vedere una dichiarazione di funzione o una macro è necessario fare riferimento al file di intestazione e generalmente è più semplice che tutto sia in un file di origine (non il tutto il software, ovviamente).

Quindi perché i programmatori utilizzano questo metodo?

Answer 1

I file di intestazione in C dichiarazioni separate (che devono essere disponibili per ciascun file .c che utilizza le funzioni) dalle definizioni (che devono essere in un unico punto). Inoltre, forniscono un po 'di modularità, dal momento che è possibile inserire solo l'interfaccia pubblica in un file di intestazione e non menzionare funzioni e variabili statiche che dovrebbero essere interne al file .c. Questo utilizza il file system per fornire un'interfaccia pubblica e un'implementazione privata.

La pratica di un file .h in un file .c è per lo più conveniente. In questo modo, sai che le dichiarazioni sono nel.h file e le definizioni nel file .c corrispondente.

Answer 2

In genere un'intestazione per un metodo di file di origine significa che si dichiarano solo le funzioni dall'unità di compilazione in quell'intestazione.

In questo modo non si inquina con le dichiarazioni non necessarie. (in un progetto software di grandi dimensioni potrebbe essere un problema)

Come unità di compilazione separate, queste velocizzano la compilazione e possono aiutare a evitare collisioni se i simboli privati ​​vengono dichiarati statici.

Answer 3

Non è necessaria un'intestazione per file di origine. Un'intestazione per modulo, contenente l'interfaccia pubblica, e forse un'intestazione aggiuntiva contenente dichiarazioni private ecc condivisa tra i file in quel modulo.

Answer 4

Perché, come hai detto tu stesso, non è possibile mettere "l'intero software" in un unico file sorgente.

Se il tuo programma è molto piccolo, allora sì è più semplice mettere tutto in un file .c. Man mano che il programma diventa più grande, diventa utile organizzare le cose mettendo insieme le relative funzioni in diversi file .c. Inoltre, nei file .h è possibile limitare le dichiarazioni che si danno alle dichiarazioni di cose che sono supposte da utilizzare in altri file .c. Se un file .c non contiene nulla che dovrebbe essere accessibile al di fuori di se stesso, non ha bisogno di intestazione.

Ad esempio, se .c ha funzione foo() e fooHelper(), ma nessuno tranne foo() dovrebbe chiamare fooHelper() direttamente, poi mettendo foo() e fooHelper() in foo.c, solo inserendo la dichiarazione di foo() in foo.h e dichiarando fooHelper() come statico, si contribuisce a far rispettare le altre parti del proprio programma che dovrebbero solo accedere a foo() e non dovrebbero sapere o preoccuparsi di fooHelper(). Una specie di forma di incapsulamento non orientata agli oggetti.

Infine, i motori sono in genere abbastanza intelligenti da ricostruire solo i file che sono stati modificati dall'ultima build, quindi la suddivisione in più file .c (utilizzando i file .h per condividere ciò che deve essere condiviso) aiuta a velocizzare le build.

Answer 5

Basta inserire nel file di intestazione il minimo indispensabile che gli altri file di origine devono "vedere" per compilare. Ho visto alcune persone che mettono tutto il non-codice nel file di intestazione (tutti typedefs, tutti # define, tutte le strutture, ecc.) Anche se nient'altro nel codebase userà quelli. Ciò rende il file di intestazione molto più difficile da leggere per te e per coloro che desiderano utilizzare il modulo.

Answer 6

file logici, un'organizzazione strutturata e piccola sorgente consentono:

• più veloce, una migliore programmazione - rompere il codice in pezzi più gestibile e comprensibile rende più facile da trovare, capire e modificare il relativo codice.
• riutilizzabilità del codice - diversi "moduli" di codice possono essere separati in gruppi di file sorgente/header che è possibile integrare più facilmente in programmi diversi.
• migliore "incapsulamento" - solo i file .c che includono specificamente quell'intestazione possono utilizzare le funzionalità da esso, che consentono di ridurre al minimo le relazioni tra le diverse parti del codice, che facilita la modularità. Non ti impedisce di usare le cose da qualsiasi luogo, ma ti aiuta a pensare perché un particolare file c ha bisogno di accedere a funzioni dichiarate in una particolare intestazione.
• Aids teamwork - due programmatori che tentano di modificare contemporaneamente lo stesso file di codice causano problemi (ad es. Blocchi esclusivi) o lavoro extra (ad esempio code merges) che si rallentano a vicenda.
• compila più veloce - se si dispone di un'intestazione, ogni volta che si effettua una modifica, è necessario ricompilare tutto. Con molte piccole intestazioni, solo i file .c che includono l'intestazione modificata devono essere ricostruiti.
• più facile manutenibilità & refactoring - per tutti i motivi sopra

In particolare, "uno di intestazione per ogni file sorgente" rende molto facile trovare le dichiarazioni relative al file c si sta lavorando. Non appena inizi a fondere più intestazioni in un singolo file, diventa difficile mettere in relazione i file c e h e, in ultima analisi, rende molto più complessa la creazione di un'applicazione di grandi dimensioni. Se lavori solo su una piccola applicazione, è comunque consigliabile prendere l'abitudine di utilizzare un approccio scalabile.

Answer 7

programmatori utilizzano questo metodo perché permette loro di separare l'interfaccia dall'implementazione mentre garantendo che il codice cliente e attuazione concordano sulle dichiarazioni delle funzioni. Il file .h è il "single point of truth" (vedi Do not Repeat Yourself) sul prototipo di ciascuna funzione.

(codice cliente è il codice che s #include' file h, al fine di utilizzare le funzioni esportate, ma non implementa una delle funzioni nel .h.)