Incluir estrategia de pedido de archivos

Question

He visto consejos consistentes de que un archivo de implementación (.cc/.cpp) debe incluir su clase correspondiente definition file first, antes de incluir otros archivos de encabezado. Pero cuando el tema cambia a los archivos de encabezado, y el orden de incluye que contienen, el consejo parece variar.

sugieren:

1. dir2/foo2.h (ubicación preferida - ver detalles a continuación).
2. C archivos de sistema.
3. Archivos de sistema C++.
4. Archivos de otras bibliotecas .h.
5. Los archivos .h de su proyecto.

No está claro cuál es la diferencia entre las entradas 1 y 5 anteriores, y por qué se elegiría una u otra ubicación. Dicho esto, another online guide sugiere este orden (que se encuentra en la sección "Disposición" de ese documento):

1. sistema incluye
2. proyecto incluye
3. local incluye

Una vez más, hay una ambigüedad, esta vez entre los ítems 2 y 3. ¿Cuál es la distinción? ¿Los que representan incluyen entre proyectos e intra-proyectos?

Pero más al punto, parece que los dos estándares de codificación propuestos sugieren que "sus" archivos de encabezado están incluidos al final. Tal consejo, estar al revés de lo que se recomienda para ordenar por inclusión en los archivos de implementación, no es intuitivo. ¿No sería lógico que los archivos de encabezado "tu" aparezcan en primer lugar, antes que los encabezados del sistema y de terceros?

Answer 1

El orden que enumera incluye no debe importar desde un punto de vista técnico. Si lo diseñó bien, debería poder ponerlo en el orden que desee y aún así funcionará. Por ejemplo, si su foo.h necesita <string>, debe incluirse dentro de su foo.h para que no tenga que recordar esa dependencia donde sea que use foo.

Dicho esto, si do tienen dependencias de pedido, la mayoría de las veces, al poner su archivo de definición en último lugar, lo reparará. Eso es porque foo.h depende de <string>, pero no al revés.

Puede pensar que es un buen argumento para poner su archivo de definición al final, pero en realidad es todo lo contrario. Si sus estándares de codificación requieren primero la definición, es más probable que su compilador detecte dependencias de órdenes incorrectas cuando se escriben por primera vez.

Answer 2

No conozco ningún estándar textual, pero como regla general incluyo la menor cantidad de encabezados posible, especialmente dentro de otros archivos de encabezado, para reducir tiempos de compilación, conflictos y dependencias. Soy un fanático de usar la declaración de clases en archivos de encabezado y solo incluir el encabezado y la definición en el lado .cpp cada vez que puedo permitirme.

Dicho mi preferencia personal es el siguiente:

Para encabezados: cabeceras

1. C++
2. encabezados de 3 ª parte
3. otras cabeceras del proyecto
4. encabezados de este proyecto

Para Fuente:

1. archivo precompilado encabezado
2. cabecera de este archivo de origen
3. C++ cabeceras
4. cabeceras de 3 ª parte
5. otras cabeceras del proyecto
6. cabeceras de este proyecto

punteros o sugerencias son por lo general para evitar conflictos y referencias circulares, de lo contrario es un Todas las preferencias personales o cualquier política que prefiera se adhieren a los proyectos colaborativos.

Answer 3

En cuanto al estilo de Google:

no hay ambigüedad, en absoluto.

El primer encabezado incluido debe ser el encabezado relacionado con el archivo fuente this, por lo tanto, en la posición 1. De esta manera, asegúrese de que incluye todo lo que necesita y de que no hay una dependencia "oculta": si lo hay Estaré expuesto de inmediato y evitaré la compilación.

Los otros encabezados se ordenan de aquellos a los que es menos probable que pueda cambiar si se produce un problema entre los que son más propensos a hacerlo. Un problema podría ser un identificador de choque, una macro fugas, etc.

Por definición, los encabezados de los sistemas C y C++ son muy raramente alterados, simplemente porque hay mucha gente que los usa, por lo tanto, vienen en segundo lugar.

El código de terceros se puede cambiar, pero por lo general es engorroso y lleva tiempo, por lo que es el tercero.

El "proyecto incluye" se refiere a las inclusiones de todo el proyecto, generalmente bibliotecas de origen doméstico (middle-ware) que son utilizadas por varios proyectos. Se pueden cambiar, pero esto también impactaría en los otros proyectos, que terminan en cuarto lugar.

Y, finalmente, el "local incluye", es decir, los archivos que son específicos de este proyecto y se pueden cambiar sin afectar a nadie más. En caso de problema, esos son candidatos principales, son los últimos.

Tenga en cuenta que de hecho puede tener muchas más capas (especialmente en una tienda de software), la idea clave es ordenar las dependencias desde la capa inferior (libs del sistema) a la capa superior.

Dentro de una capa dada, tiendo a organizarlos por orden alfabético, porque es más fácil verificarlos.