¿Carpetas separadas "incluir" y "src" para el código de nivel de aplicación?

Question

Esta pregunta se refiere principalmente al desarrollo de C++ estilo Unix/Linux. Veo que muchas bibliotecas C++ almacenan sus archivos de encabezado en una carpeta "incluir" y los archivos de origen en una carpeta "src". En aras de la conformidad, adopté esto en mi propio código. Pero no me queda claro si esto también debe hacerse para el código de la aplicación . He visto algunos casos en los que se usa una estructura de directorio plana para eso. ¿Cuál sería el enfoque recomendado?

Answer 1

También los separé, pero no estrictamente en la extensión, sino en el acceso del archivo.

Supongamos que tiene un módulo que gestiona la información del cliente y utiliza 2 clases para hacer esto: Cliente, CustomerValidityChecker. Supongamos también que otras partes de su aplicación solo necesitan conocer la clase Cliente, y que CustomerValidityChecker solo la usa la clase Cliente para realizar alguna comprobación. Partiendo de estas premisas que almacenar los archivos de la siguiente manera:

carpeta pública (o la inclusión de carpeta):

• customer.h

carpeta privada (o carpeta de origen):

• customer.cpp
• customervaliditychecker.h
• customervaliditychecker.cpp

De esta manera, se convierte inmediatamente claro para los llamadores de su módulo de qué partes son accesibles (público) y que no son partes.

Answer 2

No hay una ventaja clara en mi opinión. Finalmente decidí mantener juntos los archivos de programa y encabezado porque mi editor (Visual SlickEdit) proporciona características referenciales adicionales cuando no están separados.

Answer 3

No hago esto; parece que hay poca ventaja en eso. Como los encabezados tienden a tener una extensión diferente de los archivos fuente, puede hacer que su editor los muestre por separado si realmente lo necesita. Visual Studio lo hace de manera predeterminada, pero lo desactivo porque prefiero verlos juntos

Answer 4

I casi siempre creo carpetas include y src para dividir mi código fuente. Creo que hace que la carpeta esté menos saturada y los archivos son más fáciles de encontrar en mi IDE. Pero creo que esto es solo una cuestión de gusto.

Cualquiera de los métodos es válido. Depende del estilo de codificación que desee seguir cómo lo hace.

Answer 5

Mucho depende del tamaño del proyecto involucrado. Hasta unas pocas docenas de archivos más o menos, mantenerlos en un directorio tiende a ser más conveniente. Para una aplicación más grande que incluye cientos o miles de archivos, comienzas a buscar formas de separarlos (aunque en los proyectos en los que he trabajado, se hizo más en líneas funcionales que src/include). Entre esos, probablemente sea cuestionable.

Answer 6

Tiene sentido separarlos para bibliotecas compartidas porque pueden distribuirse en un formulario compilado sin la fuente.He visto proyectos que separan los encabezados "públicos" (encabezados a los que se puede acceder desde el código fuera de su proyecto o biblioteca) mientras deja los encabezados "privados" y los archivos fuente en el mismo directorio. Creo que es bueno usar un enfoque coherente si está escribiendo una biblioteca compartida o un código de nivel de aplicación porque nunca se sabe cuándo se puede convertir algo que se ha escrito en el nivel de la aplicación en una biblioteca de nivel inferior que se comparte con múltiples proyectos.

Answer 7

I colocar incluir (encabezado) y los archivos fuente en el mismo directorio (carpeta). Creo carpetas diferentes para diferentes temas. Me siento frustrado cuando intento encontrar archivos de encabezado (mientras estoy depurando y también para investigar). En algunas tiendas, solo hay dos carpetas: fuente e incluye. Estos directorios tienden a crecer exponencialmente. Reutilizar el código se convierte en una pesadilla en el mejor de los casos.

En mi humilde opinión, creo que organizar por tema es mejor. Cada carpeta de temas debe compilarse en al menos una biblioteca. Los diferentes proyectos pueden incluir fácilmente los temas al buscar o incluir las carpetas. Los proyectos solo necesitan incluir las bibliotecas. Los motores de compilación inteligente pueden enumerar las carpetas de temas como dependencias. Esto acelera el proceso de construcción.

La organización del tema también agrega un poco de seguridad al proyecto. Se reduce el daño accidental a los archivos (como eliminar los incorrectos o reemplazarlos con versiones diferentes) ya que los archivos están ubicados en directorios diferentes. La eliminación de archivos en la carpeta "Persona" no afectará a los archivos en la carpeta "Forma".

Esto es sólo mi opinión, su kilometraje puede variar.

Answer 8

Tenemos un sistema de compilación que genera automáticamente nuestros archivos MAKE. Una cosa que hace es descender recursivamente en cualquier subdirectorio y compilarlos como bibliotecas, vinculándolos con los objetos del directorio principal para crear la aplicación. (En la práctica, estos "subdirectorios" suelen ser enlaces simbólicos). Las bibliotecas son estáticas a menos que el nombre del directorio termine en ".so". Una cosa que es agradable acerca de esto es que una compilación completa de nuestro sistema, que tiene muchos ejecutables, no tiene que compilar repetidamente las bibliotecas comunes.

Sin embargo, como resultado de esto, no hay separación de encabezados y fuentes. Y nunca ha sido un problema. Honestamente, creo que es mejor así porque los encabezados y los archivos fuente tienen una ubicación común, y puedes tomar un directorio y saber que tienes todo lo que necesitas para usarlo. También funciona de maravilla con la función "external" de Subversion y funciones similares en otros VCS.

Un último lugar donde una separación include/src falla es si utiliza cualquier generador de código, como flex, bison o gengetopts. Averiguar dónde estas herramientas deberían poner sus productos para que se construyan es complicado si has difundido las cosas.

Answer 9

Tenemos un sistema de compilación que usa esta regla. Este sistema de compilación es sconspiracy un conjunto de scripts para configurar SCons y dedicado al mundo C++. Se puede ver un ejemplo que utilizan estas herramientas: fw4spl

Answer 10

línea de base: fuentes y cabeceras que todavía están cambiando van de la /src. El código que ha cristalizado debe ir en /lib & /include (de hecho, puede guardar todos .lib sy .h en /lib).

• Conservar fuentes y encabezados propios, siempre que sean (a) específicos de este proyecto o (b) aún no se hayan tenido en cuenta como bibliotecas compartidas.
• Una vez que ciertas fuentes en el proyecto principal se han tenido en cuenta como una biblioteca (relativamente estable), coloque el .a o .lib en /lib, y su encabezado de interfaz pública en /include.
• Todas las bibliotecas de terceros y sus encabezados de interfaz pública también entran en /lib & /include.

Como otros nota, a menudo es más compatible para Herramientas/IDE para acceder a .h/.c de una carpeta. Pero desde una visión organizacional, puede ser útil separar el código local cambiante del código lib estable.