c++ - titulos - que es un tag h2
¿Cómo organizas tus encabezados STL? (4)
Lo que hago es incluir todos los encabezados STL que voy a necesitar en todo el proyecto en mi único encabezado precompilado , generalmente el StdAfx.h predeterminado. 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á ordenadamente ordenado 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 utilizo el espacio de nombres x cuando corresponde.
Estoy trabajando en un gran proyecto que usa STL y tengo una pregunta sobre su forma preferida de organizar su STL #includes .
- ¿Prefiere #incluir cada encabezado en el archivo de origen que se usa? Por ejemplo, si tanto
foo.cppcomobar.cpprequierenstd::string, ambos incluirán#include <string>. - ¿Prefiere tener un único archivo de encabezado que incluya todos los encabezados STL que utiliza 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 usar en un proyecto diferente sin tener que preocuparse de que le falta un #include . Las ventajas del segundo método es que puede utilizar los compiladores compatibles con el encabezado precompilado, además de que puede pragmas STL #includes en pragmas que desactivan algunas advertencias (por ejemplo, algunos encabezados de Boost causarán advertencias al compilar en el nivel 4).
¿Cuál prefieres usar?
Puedes combinar estos dos métodos:
Tenga ambos archivos .cpp incluidos, y también agréguelos a stdafx.h. Esto aún le dará la optimización de PCH.
El archivo .cpp aún 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 que cada archivo sea "independiente", es decir, cuando se agrega .cpp a otro proyecto, o se incluye una .h, se ocupa 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. Los discos rápidos ayudan mucho, sin embargo :)
También tenga en cuenta que habilitar 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 esta debe ser su primera declaración sin comentarios. Trampa fea.
Solo incluyo los archivos de encabezado que realmente se necesitan en cada fuente, y no los encabezados ''atrapar'', para mantener las dependencias (y por lo tanto los tiempos de compilación) lo más bajo 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 guardias y no agregará nada significativo a los tiempos de compilación.
Como los encabezados precompilados son algo específico del compilador. 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 principal ventaja de tener dependencias tan bajas como sea posible es que la refactorización se vuelve más fácil (o más bien: factible)
Un gran libro sobre todo esto es el diseño a gran escala en C ++ de Lakos
Totalmente de acuerdo con la sugerencia para el libro de John Lakos Large Scale 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 usar declaraciones en un archivo de encabezado. Solo utilícelos en sus archivos de implementación, archivos .cpp.
HTH.
aclamaciones,
Robar