Estoy trabajando con un sistema integrado, y estoy terminando con un montón de macros #define que interactúan HW. Quiero poner todos estos en un archivo separado (para OOP-ness), pero no sé la mejor manera de #include que. ¿Acabo de ponerlos todos en un archivo .c, y luego incluir eso? Parece tonto poner estos en un archivo .h.¿Dónde pongo todas estas funciones, como #defines, en C?
No veo nada malo con el archivo .h.
Sí, esta es una práctica estándar. – caf
Bueno, la regla general es que los prototipos de funciones residen en archivos .h y sus implementaciones en archivos .c. En este caso, pondría las implementaciones en los archivos .h, normalmente no donde alguien los buscaría. – Tristan
@Tristan: lo que es cierto para las funciones no es necesariamente cierto para las macros; también es común que las funciones en línea residan en los archivos de encabezado – Christoph
Deben ir en los archivos .h. La otra opción es un archivo .c, y eso requeriría el uso de #include para incluir un archivo .c, lo que definitivamente confundirá a las personas, además de confundir su archivo MAKE, si utiliza la suposición estándar de que cada archivo .c corresponderá directamente a un archivo compilado .o archivo.
El patrón normal es que los archivos .h son para cosas que están incluidas en otros lugares (y, particularmente, en muchos otros lugares), y que los archivos .c son para cosas compiladas una vez en archivos de objeto.
Por lo tanto, las siguientes cosas que normalmente entran en .h archivos:
extern declaracionesPor el contrario, las siguientes cosas que normalmente entran en .c archivos:
El caso de " las definiciones de funciones solo entran en los archivos .c "es simplemente el caso degenerado cuando no tiene ninguna función en línea.
En C++, donde la gran cantidad de funciones se definen en forma de plantilla y por lo tanto las definiciones deben ser incluidos cada vez que son utilizados, esas definiciones muy a menudo van en la .h (o .hpp, o lo que sea) de archivos. Entonces este tipo de cosas definitivamente tiene un precedente.
No estoy necesariamente recomendando esto, pero lo he visto en bastantes proyectos integrados en los últimos 10 años: incluye funciones en línea como .inl.
Brooks no tiene ninguna responsabilidad. Es posible considerar la separación de línea y definiciones de las macros de prototipos de las funciones ordinarias y tal:
#include "prototypes.h"
#include "macros.inl"
int foo(void);
int bar(char);
Su objetivo final es la consistencia: las decisiones de diseño deben ayudar a los que se tenga éxito.
Colóquelos donde los necesite.
Si lo necesita solo para un archivo, colóquelo en la parte superior de ese archivo.
Si lo necesita para varios archivos, colóquelo en un archivo de encabezado.
FWIW: Se llaman "macros", no "funciones". – dmckee
¿Por qué parece tonto ponerlos a todos en un archivo .h? – FrustratedWithFormsDesigner
@dmckee: podemos dividir la diferencia y llamarlos "macros funcionales" en lugar de "macros similares a objetos", los términos utilizados en el estándar. –