Cómo usar stdafx.h correctamente?

Question

¿Cuál es la forma correcta de manera de usar stdafx.h, en términos de separación de dependencias?

Si pongo todo ahí, entonces mis compilaciones están ardiendo rápido, y todo lo que necesito decir en ningún fichero es

#include "stdafx.h" 

con las salvedades de que:

1. que hay más tiempo saber qué archivos dependen de qué encabezados.
2. Reduce la modularidad, haciendo que mi código sea menos reutilizable.
3. Ya no puedo separar C #include s de los C++ (por ejemplo, cstring versus string.h) sin mucho dolor. (Hablando de eso, ¿esto siquiera importa?)

Si pongo nada allí, puedo organizar todo bien - pero entonces mis compila frenar de manera espectacular.

Si pongo todo allí y también incluyen cada cabecera en mis archivos individuales, entonces consigo lo mejor de ambos mundos, con la salvedad de que ahora tengo que hacer un seguimiento de los problemas de sincronización.

¿Existe una solución bien conocida/bien aceptada para este problema?

Answer 1

No debe poner sus propios archivos de encabezado en stdafx.h ya que es probable que su código cambie y hará que todo el programa se vuelva a compilar.

Normalmente pongo encabezados estándar y otras bibliotecas, como todo el boost incluye.

Answer 2

Al usar encabezados precompilados, debe asegurarse de que su proyecto se compila limpiamente incluso sin PCH (así que trátelo como optimización, no como un reemplazo para incluir en cada TU). Aparte de eso, no pongas absolutamente todo ahí (y más importante aún, nunca coloques encabezados de tu propio proyecto; PCH debería contener solo aquellos que no cambian o cambian muy raramente - bibliotecas de sistemas, dependencias externas), sino más bien tratar de mantener precompiladas las cosas más usadas/más grandes.

Answer 3

Personalmente, preferiría tener una compilación más lenta que ninguna idea (visibilidad) de cómo son las dependencias. Sin embargo, hay límites para todo.

Como cada proyecto tiene su propio archivo de encabezado precompilado, entonces simplemente me gustaría incluir todos los elementos comunes. Digamos que si un proyecto usa algunos encabezados de impulso, encajarían bien allí, ya que serán utilizados por todo el proyecto y no los cambiarán. Por lo tanto, coloque encabezados raramente/nunca cambiantes en encabezados precompilados, como elementos del sistema o de terceros.

Para la velocidad de compilación, prefiero confiar tanto como sea posible para reenviar cosas, dividirlas en bibliotecas más pequeñas y tratar de ver si las cosas se pueden organizar de manera tal que el código volátil no afecte a la recompilación de muchas otras código.

Answer 4

El compilador Yor puede tener un indicador "mostrar incluye". Actívelo y busque jerarquías de inclusión profundamente anidadas que se repitan. Considere incluir uno de los archivos de inclusión más superficiales en su encabezado para cada uno de esos árboles profundos.

Answer 5

Condicionalmente incluya los PCH, luego defina algo así como "#define _PRE_COMPILE_" De esta forma, los encabezados originales siguen visibles y el código es modular si lo necesita. Un ejemplo de esto sería incluir

#ifdef _PRE_COMPILE_ 
#include "stdafx.h" 
#elif 
#include <iostream> 
#include <cstring> 
#endif 

Incluir esto al comienzo de cada archivo de origen.