estructura src/carpeta en C++?

Question

vengo a C++ desde Java/AS3-land, y estoy acostumbrado a la estructura de paquete y carpeta para mis clases. y me gusta.

entiendo los conceptos básicos de espacios de nombres en C++, y estoy feliz de dejarlo en lo básico. pero, a medida que mi proyecto se vuelve más complejo, me gustaría mantener mi estructura de carpetas organizada de una manera que pueda mantener en mi cabeza. es decir, algo similar a Java/AS3.

1) ¿hay alguna razón para no tener una estructura de carpetas como:

src/ 
model/ 
view/ 
controller/ 

posiblemente con subcarpetas? (Esto es solo un ejemplo de MVC, la estructura de la carpeta puede ser cualquiera dependiendo de las necesidades del proyecto). Parece ingobernable tener una src/carpeta con una enorme pila de archivos de cabecera y fuente dentro.

2) si la respuesta a 1) podría ser "seguir y hacer lo que quiera", sería imprudente/innecesario crear un espacio de nombres para cada carpeta, similar a la forma de Java/AS3 de crear un paquete para cada ¿carpeta? Según tengo entendido, los espacios de nombres no suelen usarse así, anidados en profundidad y relacionados con las carpetas.

Answer 1

Siempre me ha gustado el espacio de nombres para cada carpeta. Sobre todo porque cuando tengo que mantener el código de otra persona, el espacio de nombres me ayuda a encontrar dónde se definió originalmente la clase.

Los archivos de encabezado bien nombrados también pueden ayudar con esto. Tampoco sugeriría ir a más de 2-3 espacios de nombres, ya que simplemente se vuelve desagradable. Te encontrarás usando "using namespace, blah"; mucho que siempre encuentro como una bandera roja para el código C++. Y no puede usar "usar espacio de nombre" dentro de un archivo de encabezado sin que se produzcan algunos problemas graves.

Todo es completamente opcional en C++.

Answer 2

No hay razón para no ayudar y realmente ayudará a las personas a leer su código. Algunas cosas a tener en cuenta:

1. ¿No más de carpetas -nest, esto puede ser confuso para los lectores del código.
2. Sea coherente en la organización de su código, p. no ponga ningún código de vista en el subdirectorio de controladores, o viceversa.
3. Mantenga el diseño limpio.

Answer 3

Puede organizar sus archivos como desee; solo tendrá que ajustar las rutas de inclusión y las rutas de origen de sus herramientas de compilación para que coincidan.

Dar a cada directorio su propio espacio de nombres es excesivo y probablemente una mala idea, ya que hará que el código sea confuso. Yo recomendaría un espacio de nombres por proyecto como máximo, o incluso solo un espacio de nombres por empresa (ya que presumiblemente dentro de su empresa tiene el poder de cambiar el nombre de las cosas si es necesario para resolver colisiones de nombres. El objetivo principal de los espacios de nombres es manejar el caso donde dos bases de código bajo el control de dos organizaciones diferentes, ambas usan el mismo nombre, y usted, como tercero, desea usarlas en el mismo proyecto, pero no tiene la capacidad de modificar ninguna de las bases de código).

Answer 4

Es posible que desee echar un vistazo a John Lakos Large-Scale C++ Software Design. Básicamente, puede hacerlo, pero sus paquetes deben (como en Java) tener un gráfico de dependencia acíclica. También, puede ser oportuno para cada paquete de cabeceras documento que se exportan y los que no lo son, tal vez, así:

src/ 
|- package1/ 
    |- exported_symbols_1.hh 
    |- exported_symbols_2.hh 
    |- src/ 
     |- impl_1.hh 
     |- impl_1.cc 
|- package2/ 
    |- sub_package_2_1/ 
     |- exported.hh 
     |- src/ 
       ... 
     |- src/ 
      ... 

Cada paquete sólo se permite a #include las cabeceras de nivel superior de otro paquete, nunca se unos en los directorios src/.

Además, cuando se desea utilizar Autotools en un gran proyecto y la intención de distribuir las cabeceras, que puede llegar a ser prudente llamar al directorio de nivel superior no src/ sino por la PACKAGE_TARNAME de ese proyecto. Esto facilita la instalación de los encabezados con la ayuda del Autotools.

(Y, por supuesto, los nombres de los archivos no se ven tan tonta como se ilustra arriba.)

Answer 5

El src/es un lugar común que hay en C/C++ programadores ponen sus fuentes dentro de la raíz del proyecto. Por ejemplo:

doc/ <- documentation 
libs/ <- additional libraries 
po/  <- gettext translations 
src/ <- sources 

es común para crear subdirectorios debajo src/si usted tiene una gran cantidad de archivos de fuentes, pero no hay limitaciones cómo organizar esta subestructura.

Tenga en cuenta que una estructura de directorios es completamente opcional en C++. Eso no es una conexión entre espacios de nombres C++ y la estructura de directorios.

Answer 6

No hay ninguna razón para no dividir su código fuente en diferentes directorios; tiene sentido si hay muchos archivos y agrupaciones lógicas claras. No es necesario crear un archivo distinto para cada clase pequeña, en proyectos grandes, eso tiende a ralentizar la compilación (ya que los archivos de implementación a menudo tienen que incluir muchos de los mismos encabezados solo para compilar las líneas de sus docenas de líneas).)

Así como el uso de espacios de nombres para reflejar las divisiones lógicas en el código, los umbrales exacto en el que el código se subdivide en otros espacios de nombres tiende a ser impulsado por algunas otras fuerzas, por ejemplo:

• factores lo que sugiere el uso de más espacios de nombres
  • código muy volátil (a menudo editado, constante uso identificador adicional/cambiado, a menudo cortos y/o palabras comunes)
  • desarrolladores más
• factores que reducen la necesidad de espacios de nombres
  • estrecha coordinación por un cuerpo central
  • comunicados formales planificadas con controles exhaustivos de conflictos

espacios de nombres también pueden ser utilizados como una forma de permitir una fácil cambiar entre implementaciones alternativas (p. ej. diferentes versiones de un protocolo, funciones seguras de subprocesos frente a funciones de soporte inseguras, implementaciones específicas de SO), por lo que a veces satisfacer tales necesidades implica el uso de espacios de nombres distintos.

Definitivamente puede ser doloroso hurgar en espacios de nombres poco intuitivos y/o profundamente anidados para alcanzar las variables que desee, y "usar el espacio de nombres" es menos efectivo si es probable que necesite usar varios que definan los mismos identificadores de todos modos, pero puede adaptarse a más código modal que tiende a usar uno u otro espacio de nombres más a la vez.

Por lo tanto, es posible que desee considerar estos factores al decidir si se debe colocar el código de cada carpeta (o algún otro grupo lógicamente distinto) en espacios de nombres distintos.