2008-11-12 11 views
9

Estoy trabajando en un gran proyecto que utiliza el STL y tengo una pregunta sobre su forma preferida de organizar su STL #includes.¿Cómo organizas tus encabezados STL?

  • Prefiere #incluir cada encabezado en el archivo fuente que se utiliza. Por ejemplo, si ambos foo.cpp y bar.cpp requieren std::string, ambos serán #include <string>.
  • ¿Prefiere tener un único archivo de encabezado que incluya todos los encabezados STL que usa su proyecto (es decir, agréguelos al encabezado prefabricado de MS 'stdafx.h').

La ventaja del primer método es que el archivo .cpp es una unidad independiente y se puede utilizar en un proyecto diferente sin tener que preocuparse de que se está perdiendo una #include. Las ventajas del segundo método es que puede utilizar los compiladores de su compilador precompilado además de que puede ajustar STL #includes en pragmas que deshabilita algunas advertencias (por ejemplo, algunos encabezados de Boost causarán advertencias al compilar en el nivel 4).

¿Cuál prefiere usar?

Respuesta

14

Solo incluyo los archivos de encabezado que realmente se necesitan en cada fuente, y no los encabezados 'atrapar todos', para mantener las dependencias (y por lo tanto los tiempos de compilación) lo más baja posible.

Los encabezados precompilados pueden funcionar independientemente de esto (es decir, confío en los encabezados precompilados para acelerar el proceso de compilación, no para obtener declaraciones). Entonces, incluso si algo se declara a través de los encabezados precompilados incluidos, aún incluyo el encabezado 'regular', que será omitido por el mecanismo de inclusión de guardia y no agregará nada significativo a los tiempos de compilación.

Como los encabezados precompilados son un compilador específico. La optimización/cambio de encabezados precompilados no debería tener ningún efecto en el correcto funcionamiento del código en mi opinión.

La ventaja principal de tener dependencias lo más bajo posible es que la refactorización se hace más fácil (o más bien: es factible)

Gran libro sobre todo esto es Large Scale C++ Design from Lakos

+0

Gracias por la respuesta y la recomendación del libro. – Rob

1

totalmente de acuerdo con la sugerencia de que el libro de John Lakos grande Escala C++ Design.

Declare todos los encabezados necesarios para un archivo, ya sea .h o .cpp, en el archivo mismo. No confíe en los efectos secundarios de los archivos incluidos en otros archivos de encabezado.

Tener un archivo de encabezado grande que enumera todo incluye aumentar las dependencias innecesariamente y hace que el diseño sea muy frágil.

Oh, otra cosa nunca tiene que usar declaraciones en un archivo de encabezado. Solo utilícelos en sus archivos de implementación, archivos .cpp.

HTH.

aplausos,

Rob

1

lo que hago es incluir todas las cabeceras de STL que voy a necesitar en todo el proyecto en mi única precompiled header, por lo general el valor por defecto StdAfx.h. Un encabezado precompilado es lo primero que se configura de facto en un proyecto, incluidos todos los encabezados STL-/boost-/platform y las bibliotecas de terceros.

STL & boost están ordenadamente ordenados en espacios de nombres, por lo que nunca causan confusiones o superposiciones.

En los encabezados generalmente utilizo los nombres completos, pero en los archivos fuente hago usando el espacio de nombres x cuando corresponda.

2

Se pueden combinar estos dos métodos:

tener tanto .cpp - archivos incluyen, y también agregar a StdAfx.h. Esto aún le dará la optimización de PCH.

El archivo .cpp todavía debe incluir #include "stdafx.h", por lo que su independencia es discutible. Sin embargo, la dependencia es estado explícitamente, y eliminar el stdafx.h include es más simple que encontrar todos los includes que faltan. Además, los encabezados estándar, como deben hacerlo todos los encabezados, asegúrese de que no estén incluidos dos veces.


En general, estoy de acuerdo con su enfoque para hacer de cada archivo "independiente", es decir, cuando se añade el .cpp a otro proyecto, o se incluye un .h, que se encarga de sus dependencias.


Recuerde que un PCH es una compensación, pueden ser enormes. Tener que usar gran parte del código no utilizado en PCH puede realmente desacelerar sus compilaciones. Sin embargo, los discos rápidos ayudan mucho :)

También tenga en cuenta que la habilitación de encabezados precompilados en MSVC al menos en algunas versiones realmente cambia el procesamiento: las declaraciones anteriores al #include "stdafx.h" se ignoran, por lo que es necesario sea ​​su primera declaración sin comentarios. Trampa fea.