¿Debo usar rutas de inclusión relativas para mi proyecto o colocar el directorio de inclusión en la ruta de inclusión?

Question

En mi proyecto, actualmente uso rutas relativas para incluir mis archivos, lo que sin duda no cambia con frecuencia. Sin embargo, produce patrones de inclusión bastante extraños, porque generalmente anido mis archivos en muchas carpetas.

Por ejemplo, en mi proyecto actual tengo network/server/myfile.hpp. Necesita incluir common/log.hpp. Actual uso #include "../../common/log.hpp" que es bastante detallado, pero funciona.

Si, en cambio, agrego mi directorio de inclusión principal en la ruta, podría simplemente incluir "common/log.hpp".

Sé que esta pregunta podría ser más acerca de la preferencia que cualquier otra cosa, pero ¿hay algún pros y contras objetivos con respecto a las aplicaciones multiplataforma y qué hay de las convenciones de C++?

Answer 1

Relativo incluye rutas con .. que se ven un poco feas y esperan cierta estructura del sistema de archivos, es decir, "../../common/log.hpp" tiene dos carpetas hacia arriba. Tiene sentido evitar dependencias innecesarias en general y en particular la estructura del sistema de archivos, por lo que mover un archivo de encabezado de un directorio a otro no lo obliga a actualizar todos los archivos fuente que incluyen ese encabezado.

También es elegante que sus inclusiones correspondan a espacios de nombres y clases. Si, por ejemplo, tiene:

namespace foo { namespace bar { struct Baz; } } 

Es conveniente e intuitiva para incluirlo como:

#include "foo/bar/Baz.h" 

Answer 2

Siempre me esfuerzo para que mis proyectos sean independientes de la ubicación. Si trabajo en una nueva computadora/plataforma, quiero ser capaz de compilar y seguir trabajando con un mínimo de configuración requerida. Al hacer una pregunta subjetiva, mi respuesta subjetiva sería que definitivamente prefiero usar caminos relativos.

Answer 3

No CONVENCIONES como tales, puede hacerlo de cualquier manera, de la manera que prefiera.

Es decir, si desea mantenerlo ordenado aunque, obviamente, a continuación, ir a por segunda opción , me gustaría ir yo mismo para la segunda una causa no es que vas a tener que mover una piedra grande, pero solo unos pocos archivos, dicen main.

Y por otra parte las rutas relativas que proporcionan libertad de puerto que la aplicación, lo que sólo lo hacen :)

Answer 4

Al tener #include <common/log.hpp> en el archivo de origen y tener camino a common/log.hpp en la configuración del proyecto (opciones del compilador) está protegiendo su código fuente de los cambios en caso de que common/log.hpp se mueva a otro lugar, entonces recomendaría este enfoque. Tenga en cuenta el uso de corchetes angulares en este caso: el compilador debe buscar el encabezado en los directorios cuyas rutas se especifican mediante la opción del compilador /I.

Answer 5

tengo una regla que cada componente individual no puede utilizar más de un directorio, y que componentes tienen directorios de componentes dependientes en la ruta de inclusión.

Por lo tanto, cada componente utiliza su propio archivos de inclusión con la sintaxis "" y otros componentes del incluye el uso de <>, que muy bien evita sorpresas desagradables con un componente utilizando el encabezado que la última versión implementada instalado en el sistema incluyen directorio en lugar de el del árbol fuente; también tiene el bonito efecto de obligarme a componer mis proyectos desde el principio.