c++ visual-studio visual-c++ precompiled-headers

c++ - Visual Studio 2010, Intellisense y PCH: ¿cuáles son las alternativas a stdafx.h feo?



visual-studio visual-c++ (4)

¿Su problema básicamente parece ser que Intellisense es lento para Boost en VS2010? No tengo una solución directa para este problema, pero ¿ Visual Assist X podría ser una opción para usted? Lo he usado en varias versiones de Visual Studio ahora y con gran placer. No es una solución directa, pero podría funcionar para usted.

Recientemente cambié a Visual Studio 2010 y, para que Intellisense no tarde medio minuto en aparecer cuando se usan las bibliotecas boost , la sugerencia de Microsoft parece usar encabezados precompilados.

Excepto que nunca los usé antes (excepto cuando fue obligado a hacerlo por Ugly ATL Wizards (TM)), así que busqué para averiguar cómo funcionan.

Básicamente, el enfoque de Big Centralized stdafx.h parece claramente incorrecto. Nunca quiero incluir (incluso de forma barata) un montón de archivos de encabezado en todas mis fuentes. Ya que no uso las bibliotecas de Windows (hago envoltorios de nivel superior C ++ / CLI, luego uso .NET para hablar con el mundo exterior), no tengo "un camión completo de enormes encabezados que no cambian". Solo boost y los encabezados estándar de la biblioteca se dispersan alrededor.

Hay un enfoque interesante para este problema, pero no puedo entender cómo hacer que esto funcione. Parece que cada archivo fuente debe compilarse dos veces (corríjame si me equivoco): una vez con / Yc y una vez con / Yu. Esto agrega una carga para el desarrollador que debe modificar manualmente el sistema de compilación.

Esperaba encontrar algún "truco de generación automática de un encabezado precompilado para cada archivo de origen", o al menos algunas "mejores prácticas", pero la mayoría de las personas parece estar contenta con la inclusión del mundo en stdafx.h .

¿Cuáles son las opciones disponibles para usar encabezados precompilados por archivo de origen? Realmente no me importan los tiempos de compilación (siempre que no se disparen), solo quiero que el sentido inteligente funcione rápidamente .


Los encabezados precompilados no son tan malos si los usas correctamente .

No los use como un reemplazo para los incisos incluidos y precisos, sino como una forma de acelerar las cosas. Logra esto haciendo que el encabezado precompilado no haga nada en las versiones de lanzamiento, solo acelera las cosas en la depuración.


Para empezar, estás leyendo mal el artículo. Cada archivo no se compila dos veces. El archivo stdafx.cpp se compila una vez con / Yc (c, para crear) antes que nada y luego todos los demás archivos en su proyecto se compilan una vez con / Yu (u, para uso) e importa el resultado del estado guardado creado anteriormente. de stdafx.cpp.

En segundo lugar, el artículo tiene 7 años y está hablando de VC ++ 6, por lo que debe comenzar desconfiando de él. Pero incluso suponiendo que la información que contiene se aplique a VC ++ 2008 o 2010, parece un mal consejo. El enfoque que recomienda usar /pragma hdrstop es la solución que busca un problema. Si tiene encabezados que contienen cosas que no quiere en cada archivo, entonces simplemente no deberían ir en su encabezado precompilado.


Te equivocas, cada archivo solo se compila una vez. Tiene un archivo .cpp que se compila con / Yc y el resto se compila con / Yu. El archivo con / Yc, que es stdafx.cpp por defecto, contiene una línea, #include "myMainHeader.h" (cambió el nombre del predeterminado). Todos los demás archivos .cpp deben comenzar con #include "myMainHeader.h". / Se compila el archivo / Yc, se guarda todo el estado interno del compilador. Ese archivo se carga cuando cada uno de tus otros archivos se compila. Es por eso que debe comenzar con la inclusión de PCH, de modo que la opción / Yu no cambie el resultado de la compilación, solo la hora. Xcode no hace este requisito y utilizará un PCH independientemente de si su archivo .cpp comienza con la directiva de inclusión correcta. He usado bibliotecas que se basaron en esto y no se pudieron construir sin PCH.