tutorial online compile compilar c++ build

online - Codificación de C++(en su mayoría) en archivos de encabezado frente a archivos.cpp



compilar c++ online (3)

Durante años he estado codificando C ++ de forma estándar, con declaraciones de clase en los archivos de cabecera .hpp y las definiciones de funciones en los archivos fuente .cpp. Recientemente me mudé a una nueva compañía donde el código (aparentemente influenciado por los estilos de codificación de impulso) está completamente codificado en archivos .hpp con un archivo .cpp corto para incluir los archivos de encabezado y crear el objeto / programa binario.

Me puse a pensar: ¿cuáles son las fortalezas / debilidades de escribir su código en archivos de encabezado en lugar de escribir un archivo .hpp y .cpp para cada objeto? Esto supone que nuestro proyecto no crea bibliotecas comunes que luego se vinculan a los archivos binarios del programa, sino que cada programa binario se crea a partir de la suma de los archivos de encabezado (y un archivo fuente .cpp). ¿Es esta una nueva tendencia en C ++?

Por ejemplo, los objetos de plantilla deben ser solo de encabezado, pero podría parecer una buena idea colocar clases que no sean de plantilla en archivos de encabezado y luego simplemente incluir estas clases de proyectos comunes en su (s) binario (s). Suponiendo que está creando una nueva base de código desde cero, significaría menos vinculación, lo que podría significar menos errores de vinculación y posiblemente compilaciones más rápidas. ¿Las instalaciones de encabezados precompilados también significan que el uso de archivos de encabezado acelera el tiempo de compilación? ¿O son los tiempos de compilación más largos porque ahora necesitamos compilar todo el código al crear un binario en lugar de vincular objetos comunes de biblioteca compartida?

También tenga en cuenta que no estamos escribiendo una API aquí (en cuyo caso, algo como el lenguaje pimpl nos daría más flexibilidad al ocultar la implementación), estamos escribiendo programas para ejecutar en un sitio del cliente.

Gracias por adelantado,


La parte superior de mi cabeza:

Fortalezas:

  • Implementación visible (más de una debilidad, pero depende del caso)
  • no hay necesidad de exportar a una biblioteca
  • Mejor oportunidad para que el compilador optimice algo del código.

Debilidades:

  • implementación visible
  • tiempo de construcción más lento
  • archivos de encabezado hinchados
  • un cambio en la implementación requeriría una reconstrucción completa, tener la implementación en un archivo de implementación no (solo compilar ese archivo o biblioteca específica)
  • En el caso de dependencias circulares, se usan declaraciones de avance y solo se incluye el tipo completo en el archivo de implementación. Si todo lo que tienes es un encabezado, esto ya no es posible.

Estoy seguro de que hay otros, que editaré si puedo pensar en algo más.


Las bibliotecas comunes son una cosa, la reutilización general del código es otra. Si desea utilizar parte del código que ha escrito en otro proyecto, es posible que tenga que copiar y pegar enormes trozos de código y luego mantener los códigos de base separados. El tiempo de compilación se alargará, ya que el programa será una unidad de compilación grande en lugar de muchos archivos cpp / h, donde solo estos, que incluyen el archivo de encabezado modificado, serán recompilados. Por ejemplo, la compilación completa de la aplicación en la que estoy trabajando actualmente toma 7 minutos. Una recompilación tarda unos quince segundos, si los cambios no son graves. Finalmente, el código puede ser menos legible. El archivo de encabezado le ofrece una vista rápida de para qué se crea la clase y cómo usarla. Si las clases se escriben in situ, tendrás que revisar innecesariamente el código fuente.


Las bibliotecas de solo encabezado tienden a hacer que el sistema de compilación sea más fácil y, en general, debe preocuparse menos por las dependencias.

Por otra parte, mover el código a los archivos de implementación facilita el control de los límites de los módulos y la creación de módulos binarios intercambiables, que pueden mejorar las construcciones incrementales. El costo es más "limpieza". Mi corazonada es preferir los archivos de implementación, y hay algunos puntos de datos que me respaldan, como esta publicación de blog del autor de la biblioteca de redes de Boost propuesta.