Para un preprocesador, la extensión de un archivo realmente no importa. Puede poner el código en un archivo con una extensión "JPG" y aún puede #incluirlo sin error, siempre que el código sea legítimo.

Una de las razones por las que, convencionalmente, se considera una mala práctica #include archivos con una extensión de archivo de origen es desde una perspectiva básica de compilación/creación. Imagine que está transfiriendo un proyecto a gran escala a un nuevo sistema de compilación multiplataforma (digamos, 50 millones de líneas de código).

Ahora debe especificar qué archivos se compilarán como unidades de compilación separadas (archivos de objeto) para compilarlos por separado y vincularlos para formar el binario resultante. Si su base de código tiene la costumbre de usar el preprocesador para incluir archivos con una extensión de archivo fuente, entonces no tiene idea de solo mirar las extensiones de archivo, qué archivos se compilarán como unidades de compilación separadas y qué archivos en realidad solo deben incluirse. por el preprocesador. Entonces, es posible que se enfrente a un correo no deseado de errores simplemente tratando de compilar todos los archivos fuente como unidades de compilación separadas como lo haría una persona en su sano juicio, y es posible que deba depurar su proceso de compilación usando un peine de dientes finos mientras inspecciona todo su código y trata de averiguar qué archivo está destinado a qué.

En un nivel más alto, más allá de las extensiones de archivo, si realmente define elementos en los archivos fuente y los incluye con el preprocesador, entonces corre el riesgo de definiciones redundantes del enlazador de los mismos símbolos, errores complicados de tiempo de enlace (y posiblemente tiempo de compilación). Además, esto puede exhibir un desglose general en el pensamiento entre la separación de interfaz/declaración (encabezados) e implementación/definición (fuentes).

Hay excepciones, como las compilaciones de Unity, que hacen esto como una optimización del tiempo de compilación y pueden ser algo aceptables con estándares de codificación cuidadosos y con beneficios reales y medidos para la práctica, pero en general, incluir archivos fuente puede ser realmente confuso y una señal de que el El desarrollador no entiende realmente el punto de separar las declaraciones de las definiciones o la confusión que esto puede causar al intentar establecer un sistema de compilación.

¿Por qué no es una buena práctica incluir archivos fuente en otros archivos fuente?

Los archivos de origen contienen definiciones. Estos pueden causar múltiples errores de definición y, por lo tanto, generalmente no deben incluirse en otros archivos de origen. Incluso si evita el error de definición múltiple al compilar solo los archivos que incluyen otro archivo fuente, el código puede volverse inmanejable.

En los archivos de encabezado, solo introduce algunos símbolos en el compilador e informa sus tipos. Esto le permite separar la interfaz con la implementación.

Por ejemplo:

archivo ac

 int a = 42; ...

archivo ac

 /* Example of bad code */ #include "ac" ...

Cuando compila ac y bc y los vincula, obtendrá un error de vinculación multiple definition .

Si uno planea incluir varios archivos fuente en un solo archivo y compilar ese archivo, introducirá mucha contaminación (macros, funciones estáticas, etc.) que es algo que no es muy manejable para los lectores y los compiladores.

^{ps Cuando digo en general, quiero decir que a veces incluir el código fuente puede ser útil. Pero en tales casos, para evitar confusiones a los lectores, preferiría cambiar el nombre del sufijo del archivo a algo que no sea .c , puede ser .inc o similar.}

Como se mencionó anteriormente, el principal argumento en contra de incluir archivos C en archivos C es el alto riesgo de múltiples errores de definición. Y dado que es una técnica muy poco utilizada, provoca efectos secundarios inesperados para los mantenedores de código.

Por supuesto, en casos muy especiales, incluir un C-File puede ser el menor de dos males. Por ejemplo, si desea escribir pruebas unitarias para funciones c estáticas, puede incluir el archivo C en el archivo con la prueba unitaria.

ver también: Cómo probar una función estática

Otro uso inusual pero válido es separar las plantillas de clases o funciones de su definición (C++): https://isocpp.org/wiki/faq/templates#separate-template-fn-defn-from-decl