¿Cómo diseño mi programa C++? (¿Dónde debo poner los archivos .h y .cpp?)

Question

Actualmente, programo en Java y uso bastante Maven. Como tal, me he acostumbrado a los esquemas de nombres y las estructuras de carpetas que he usado en los últimos 4 o 5 años.

Como recientemente comencé a aprender C++, me estoy dando cuenta de que no tengo idea de dónde poner todos mis archivos. ¿Debo mantener todo desglosado por espacio de nombres, o por qué nivel está? ¿Dónde, por ejemplo, guardaría una serie de archivos dedicados a la interfaz de usuario, como apuestos a los archivos destinados a ayudar a almacenar datos?

¿Hay alguna norma para este tipo de cosas?

Claramente, no hay una respuesta definitiva a esta pregunta. Simplemente estoy buscando una buena guía. No quiero comenzar a aprender C++ pasando demasiado tiempo preocupándome sobre cómo se presentan mis archivos. Prefiero tener algunos buenos modelos, y solo llegar a la codificación.

Answer 1

La siguiente es bastante típico ...

third-party library 
    release 
    obj 
    debug 
    obj 
    include 
    src 
    sublib 1 
    sublib 2 

mylibrary 
    release 
    obj 
    debug 
    obj 
    include 
    src 
    sublib 1 
    sublib 2 

myapp 
    release 
    obj 
    debug 
    obj 
    subapp 1 
    subapp 2 

mylittleapp 
    release 
    obj 
    debug 
    obj 

Básicamente, subcarpetas para subproyectos es común para proyectos más grandes, pero sobre todo un proyecto particular tiene carpetas para src, etc. incluyen una carpeta para cada configuración de generación es común, y mantener los archivos obj y otros intermedios en una subcarpeta de eso es una buena idea. Puede ser tentador colocar carpetas de subproyecto en carpetas obj, pero generalmente eso es innecesario: las carpetas obj no necesitan estar bien organizadas, por lo que la única preocupación es un conflicto de nombre de archivo, y la mejor solución para eso es tener nombres únicos de archivos de origen. dentro (al menos) de cada proyecto.

Las carpetas "incluir" deben IMO contener encabezados que serán #incluidos por otros proyectos - los encabezados internos pertenecen a la carpeta "src".

Poner cosas de UI en una carpeta separada no es una mala idea, si es lo suficientemente grande. He visto cosas de la interfaz de usuario hechas como un proyecto independiente de nivel superior vinculado a la estática, y me refiero a aplicaciones específicas aquí, no (por ejemplo) wxWidgets. Por lo general, sin embargo, ese nivel de división es el subproyecto si vale la pena separarlo. La forma de dividir los subproyectos es más una cuestión de bloques específicos de la aplicación en general, por lo que depende de si las cosas de la interfaz de usuario se manejan mejor como un bloque separado o como fragmentos separados combinados con la lógica específica de la tarea.

Los espacios de nombre no son la característica de idioma más utilizada, posiblemente porque muchas personas usan tanto el "uso" que no hacen mucha diferencia. Un espacio de nombres para un proyecto de biblioteca principal tiene sentido, pero la asociación de subcarpetas a espacios de nombres 1: 1 no es algo que haya visto. Personalmente, tengo un espacio de nombres que abarca la mayor parte de mi código de biblioteca, con un par de espacios de nombres secundarios para cosas que rara vez se usan en general, pero que se usan mucho en algunos lugares (por ejemplo, espacios de nombres "bit a bit"). Los espacios de nombres secundarios están limitados a pares de fuente/encabezado únicos, por lo que no es necesario que aparezcan subcarpetas. La mayor parte de la selección específica de la biblioteca se hace incluyendo el encabezado correcto, excepto que normalmente incluyo el lote a través del encabezado de nivel superior del proyecto principal.

Básicamente, los espacios de nombres son una forma de evitar conflictos de nombres. No se asocian necesariamente con abstracciones o bloques funcionales ni nada. Dentro de un proyecto en particular, probablemente sea mejor que se asegure de que los nombres no entren en conflicto. Al igual que con el espacio de nombres "std", está bien poner un lote de cosas en un espacio de nombre.

Como dices, sin embargo, esta no es una respuesta definitiva; por supuesto, hay variaciones menores y enfoques bastante diferentes.

Answer 2

En proyectos pequeños, mi equipo agrupa todos los archivos mediante una unidad de enlace, es decir, biblioteca, DLL, EXE. Si la unidad es muy grande, a veces dividiremos los archivos por unidad funcional o subsistema, de modo que si necesita editar un componente, generalmente se encuentran en el mismo lugar.

Answer 3

rompo mis proyectos por tema, un directorio para el tema:

menu_planner 
    src 
    recipes 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    ingredients 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    references 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    meals 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    menus 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    docs 
    designs 

Mi experiencia con C y C++ me ha mostrado que cabecera y fuente archivos deben estar en el mismo directorio. A menudo, encontrar un archivo de encabezado es más difícil cuando no está en el mismo directorio que el archivo de origen.

Un directorio (carpeta) por concepto es una buena idea. Cualquier concepto complejo o compuesto debe dividirse en múltiples carpetas o conceptos.

También aprendí a hacer bibliotecas. Yo uso bibliotecas para contener código que no cambia mucho. El paso de enlace se realiza más rápido con las bibliotecas que los directorios de los archivos de objeto.

Sin embargo,, los lugares de trabajo (tiendas a.k.a.) pueden tener reglas de estilo diferentes que se deben seguir.

Answer 4

No es necesario tener sus archivos de encabezado y archivos cpp en la misma carpeta. He hecho esto muchas veces. Puede tener las carpetas diferentes y usar otro archivo para buscar/incluir ambos archivos en el archivo, que usará como su inclusión. Visite el siguiente enlace para obtener una mejor comprensión de lo que estoy diciendo. Le muestra cómo implementar su propia estructura de organización de archivos.

http://codednotes.blogspot.com/2014/01/organising-headers-and-source-files.html