c++ - poner - tags h1 y cursiva ejemplos
¿Por qué colocar encabezados en un directorio separado? (5)
Además de la utilidad (¿discutible?) Para mantener las cosas ordenadas, útiles en otros proyectos, etc., hay una ventaja muy neutral y objetiva: el tiempo de compilación.
En particular, en un proyecto grande con una gran cantidad de archivos, dependiendo de las rutas de búsqueda para los encabezados (archivos .c / .cpp que usan #include "headername.h" lugar de #include "../../gfx/misc/something/headername.h" y el compilador pasó los parámetros correctos para poder tragar eso) usted reduce drásticamente el número de entradas que el compilador necesita escanear en busca del encabezado derecho. Como la mayoría de los compiladores se inician por separado para cada archivo compilado, deben leer la lista de archivos en la ruta de inclusión y buscar los encabezados correctos para cada archivo compilado. Si hay un montón de archivos .c, .o y otros archivos irrelevantes en la ruta de inclusión, encontrar los incluidos entre ellos toma proporcionalmente más tiempo.
Esta pregunta ya tiene una respuesta aquí:
Sé que es común en los proyectos C / C ++ colocar los archivos de encabezado en un directorio como, por ejemplo, include e implementar en un directorio separado, como src . He estado jugando con diferentes estructuras de proyectos y me pregunto si existen razones objetivas para esto o es simplemente una convención.
En resumen, algunas razones:
- Código mantenible.
- El código está bien diseñado y ordenado.
- Tiempo de compilación más rápido (a veces, para cambios menores realizados).
- Segregación más sencilla de las interfaces para documentación, etc.
- Se puede evitar la dependencia cíclica en el tiempo de compilación.
- Fácil de revisar.
Eche un vistazo al artículo Organización de archivos de código en C y C ++ que lo explica bien.
La convención es una de las razones: la mayoría de las veces, con una abstracción efectiva, solo se preocupa por la interfaz y desea que sea fácil solo mirando los encabezados.
Aunque no es la única razón. Si su proyecto está organizado en módulos, lo más probable es que tenga que incluir algunos encabezados en diferentes módulos, y desea que su directorio de inclusión se limpie de otros archivos de "ruido" allí.
Además, si planea redistribuir su módulo, probablemente desee ocultar los detalles de la implementación. Por lo tanto, solo proporciona encabezados y binarios, y la distribución de encabezados desde una sola carpeta con nada más es más simple.
También hay una alternativa que realmente prefiero: los encabezados públicos van en una carpeta separada (que contienen la interfaz mínima; no hay detalles de implementación visibles), y los encabezados privados y los archivos de implementación están separados (posiblemente, pero no necesariamente, en carpetas separadas) .
Mantiene su estructura de carpetas más limpia. Los encabezados y los archivos de origen son claramente diferentes y se usan para diferentes cosas, por lo que tiene sentido separarlos. Desde este punto de vista, la pregunta es básicamente la misma que " ¿por qué los archivos de origen y la documentación van en carpetas diferentes "? La computadora es muy agnóstica con respecto a lo que coloca en las carpetas y lo que no, las carpetas son, en su mayor parte, solo una abstracción práctica debido a la forma en que los humanos analizamos, almacenamos y recuperamos información.
También existe el hecho de que los archivos de encabezado siguen siendo útiles incluso después de que haya creado , es decir, si está construyendo una biblioteca y alguien quiere usar esa biblioteca, necesitarán los archivos de encabezado, no los archivos de origen, por lo que Agrupar esos archivos de cabecera: capturar las cosas en la bin y las cosas include y no tener que filtrar src , es mucho más fácil.
Prefiero ponerlos en el mismo directorio. Razón:
Los archivos de especificación de la interfaz y los archivos de origen que implementan esa interfaz pertenecen a la misma parte del proyecto. Digamos que tienes subsystemx . Luego, si coloca archivos subsystemx en el directorio subsystemx , subsustemx es autónomo.
Si hay muchos archivos de inclusión, asegúrate de que puedas hacer subsystemx/include y subsystemx/source , pero luego sostengo que si pones la definición de la class Foo en foo.hpp , y foo.cpp ciertamente querrás verlos ( o al menos tener la posibilidad de hacerlo fácilmente) juntos en una lista de directorios. Buscando todos los archivos relacionados con foo
ls foo*
Encontrar todos los archivos de implementación:
ls *.cpp
Buscando todos los archivos de declaración:
ls *.hpp
Simple y limpio.