maneras de incluir muchos archivos de encabezado

Recientemente me encontré con el código que maneja los archivos de cabecera de esta manera. Habría un archivo de encabezado llamado global.h Este global.h incluiría algunos otros archivos de encabezado, por ejemplo,

 #include "settings.h" #include "math.h" #include "somelibrary.h" #include "someOtherlibrary.h" ... 

Ahora, cada vez que algún archivo quisiera incluir, digamos somelibrary.h , en lugar de escribir #include somelibrary.h , solo incluiría global.h . Así que cada archivo fuente en el proyecto acaba de tener: #include "global.h"

¿Es esta forma común de evitar escribir muchas inclusiones en cada archivo fuente? cuales son los otros beneficios

PD. extra: sería bueno si alguien pudiera explicar por qué esto funciona

Esta es una mala práctica de uso común. Si usa global.h, creará un acoplamiento ajustado entre ese archivo y cada módulo del proyecto, lo que a su vez crea un acoplamiento ajustado entre cada módulo individual de su proyecto.

Eso es muy mal diseño OO! Desea que cada módulo sea autónomo y solo dependa de otros módulos que son realmente cruciales para su propia funcionalidad. Además, siempre querrá diseñar módulos para que puedan usarse en varios proyectos.

Por ejemplo, si quiero usar su módulo genérico de la biblioteca matemática, que ya ha desarrollado para un proyecto en particular, entonces ¿por qué demonios me obligaría a incluir todos los demás archivos no relacionados de ese proyecto también?

En cuanto a “evitar escribir muchos objetos incluidos en cada archivo de origen” … No tengo nada que ver con escribir 5-10 líneas muy cortas de texto en la parte superior de un archivo puede ser un obstáculo importante para un progtwigdor. Aparentemente, hay muchas personas que encuentran que es un obstáculo tan grande, que deciden cambiar todo el diseño del progtwig debido a eso. Si no te gusta escribir en el teclado, entonces tal vez no vayas a una carrera de progtwigdor.

El único beneficio es la facilidad de inclusión.

El inconveniente es que cada vez que realiza cambios en un archivo de encabezado, tiene que volver a comstackr todo . Para cualquier proyecto más grande este es un gran problema.

También hace que eliminar o cambiar los módulos existentes sea un dolor, ya que no puede realizar una búsqueda simple de inclusión específica para tener una visión general de dónde se usa.

Simplemente no lo hagas.

Editar:

Para aclarar: está bien agrupar encabezados en uno si se necesitan para hacer X. Sin embargo, rara vez necesito hacer esto en la práctica; escribir #include "xxxxx.x" no es demasiado difícil.

No está bien tener un encabezado con todo en él para toda la aplicación que hace X, Y y Z.

Edición: esta respuesta se refiere al caso cuando los archivos de inclusión provienen de diferentes proyectos

Siempre y cuando los archivos de inclusión se refieran a otros proyectos o bibliotecas (a diferencia de los archivos de encabezado del mismo proyecto), lo llamaría una forma razonable de aclarar las inclusiones. Con el soporte de “encabezado precomstackdo” de los comstackdores de Microsoft, hay incluso un gran beneficio de rendimiento al hacerlo. También garantiza que siempre se incluyan los encabezados en el mismo orden, ya que esto a veces puede dar lugar a errores extraños si dos incluyen internamente dependen uno del otro.

La forma preferida de crear los llamados “encabezados de inclusión estándar” para MSVC es tener un archivo (normalmente denominado “stdafx.h”), que contiene los archivos de encabezado de todas las bibliotecas que va a usar el proyecto, a saber, windows.h, math.h, io.h o string. Con la configuración correcta del comstackdor, todos los incluidos que se mencionan en “stdafx.h” solo se procesan una vez para todo el proyecto. Dado que estos archivos casi nunca cambian, el hecho de que cambiarlos requiera la reconstrucción de todo el proyecto no es un problema. Sin #include "stdafx.h" línea con #include "stdafx.h" debe ser la primera en cada archivo c o cpp. ASFAIK, gcc no tiene equivalente para esto.