Sto lavorando con un sistema embedded e sto per finire con un sacco di macro di interfaccia HW #define. Voglio mettere tutto questo in un file separato (per OOP-ness), ma non conosco il modo migliore di #include. Li metto tutti in un file .c, quindi includo quello? Sembra sciocco metterli in un file .h.Dove inserisco tutte queste funzioni #defines, in C?
Non vedo niente di sbagliato con il file .h.
Sì, questa è una pratica standard. – caf
Bene, la regola generale è che i prototipi di funzione risiedono nei file .h e le loro implementazioni nei file .c. In questo caso, inserirò le implementazioni nei file .h, normalmente non dove qualcuno li cercherebbe. – Tristan
@Tristan: ciò che è vero per le funzioni non è necessariamente vero per le macro; è anche comune che le funzioni inline risiedano nei file di intestazione – Christoph
Questi file devono essere inseriti nei file .h. L'altra opzione è un file .c e ciò richiederebbe l'utilizzo di #include per includere un file .c, che confonderà sicuramente le persone, oltre a confondere il makefile, se si utilizza l'ipotesi standard che ogni file .c corrisponderà direttamente a un compilato il file .o.
Il modello normale è che i file .h sono per cose che sono incluse in altri luoghi (e, in particolare, in più luoghi diversi), e che i file .c sono per cose che sono compilate una volta in file oggetto.
Così, le seguenti cose normalmente vanno in .h file:
extern dichiarazioniAl contrario, le seguenti cose normalmente vanno in .c file:
Il caso del " le definizioni delle funzioni vanno solo nei file .c "è semplicemente il caso degenere quando non si hanno funzioni inline.
In C++, dove un sacco di funzioni sono definite in forma su modelli e, quindi, le definizioni devono essere inclusi ogni volta che vengono utilizzati, queste definizioni molto spesso vanno nella .h (o .hpp, o qualsiasi altra cosa) file. Quindi questo genere di cose ha sicuramente un precedente.
Non lo sto necessariamente raccomandando ma l'ho visto in parecchi progetti incorporati negli ultimi 10 anni: include funzioni inline come .inl.
Brooks suddivide le responsabilità in modo corretto. Si potrebbe prendere in considerazione la separazione in linea e definizioni di macro da prototipi di funzioni ordinarie e quali:
#include "prototypes.h"
#include "macros.inl"
int foo(void);
int bar(char);
il vostro obiettivo finale è la coerenza: tutte le decisioni di layout dovrebbero aiutare coloro che si riesce.
Metti dove vuoi.
Se è necessario solo per un file, inserirlo nella parte superiore del file.
Se è necessario per più file, inserirlo in un file di intestazione.
FWIW: Sono chiamati "macro", non "funzioni". – dmckee
Perché sembra sciocco metterli tutti in un file .h? – FrustratedWithFormsDesigner
@dmckee: possiamo dividere la differenza e chiamarle "macro simili alle funzioni" anziché "macro simili a oggetti" - i termini usati nello standard. –