programa ejecutar dev con compilar como c++ visual-studio build-process build

c++ - ejecutar - #incluye todos los archivos.cpp en una sola unidad de compilación?



dev c++ (5)

Hace poco tuve motivos para trabajar con algunos proyectos de Visual Studio C ++ con las configuraciones habituales de depuración y liberación, pero también ''Release All'' y ''Debug All'', que nunca había visto antes.

Resulta que el autor de los proyectos tiene un único ALL.cpp que # incluye todos los demás archivos .cpp. * Todas las configuraciones solo compilan este archivo ALL.cpp. Por supuesto, está excluido de las configuraciones normales, y las configuraciones normales no compilan ALL.cpp

Me preguntaba si esta era una práctica común. ¿Qué ventajas ofrece? (Mi primera reacción fue que olía mal).

¿Qué tipo de trampas es probable que encuentres con esto? Uno en el que puedo pensar es si tienes espacios de nombres anónimos en tu .cpps, ya no son ''privados'' para ese cpp, ¿pero ahora también están visibles en otros cpps?

Todos los proyectos crean archivos DLL, por lo que tener datos en espacios de nombres anónimos no sería una buena idea, ¿verdad? Pero las funciones estarían bien?

Aclamaciones.

Unity construye velocidades de construcción mejoradas por tres razones principales. La primera razón es que todos los archivos de encabezado compartidos solo deben analizarse una vez. Muchos proyectos C ++ tienen muchos archivos de cabecera incluidos por la mayoría o todos los archivos CPP y el análisis redundante de estos es el principal costo de compilación, especialmente si tiene muchos archivos fuente cortos. Los archivos de encabezado precompilados pueden ayudar con este costo, pero generalmente hay muchos archivos de encabezado que no están precompilados.

La siguiente razón principal por la que la unidad se crea mejorar las velocidades de compilación es porque el compilador se invoca menos veces. Hay un cierto costo inicial al invocar el compilador.

Finalmente, la reducción en el análisis de encabezado redundante significa una reducción en el código-gen redundante para las funciones en línea, por lo que el tamaño total de los archivos de objeto es más pequeño, lo que hace que la vinculación sea más rápida.

Las compilaciones de Unity también pueden dar mejor código-gen.

Las compilaciones de Unity NO son más rápidas debido a la E / S de disco reducida. He perfilado muchas compilaciones con xperf y sé de lo que estoy hablando. Si tiene suficiente memoria, la memoria caché de disco del sistema operativo evitará la E / S redundante; las lecturas posteriores de un encabezado provendrán de la memoria caché de disco del sistema operativo. Si no tienes suficiente memoria, las compilaciones unificadas pueden incluso empeorar los tiempos de compilación al hacer que el espacio de memoria del compilador exceda la memoria disponible y se deslocalice.

La E / S de disco es costosa, por lo que todos los sistemas operativos almacenan en caché de manera agresiva los datos para evitar la E / S de disco redundante.

Me pregunto si ALL.cpp está intentando poner todo el proyecto en una sola unidad de compilación, para mejorar la capacidad del compilador de optimizar el tamaño del programa.

Normalmente, algunas optimizaciones solo se realizan en distintas unidades de compilación, como la eliminación de código duplicado y la creación de líneas.

Dicho esto, parece recordar que compiladores recientes (de Microsoft, de Intel, pero no creo que esto incluya a GCC) pueden hacer esta optimización en varias unidades de compilación, por lo que sospecho que este ''truco'' es innecesario.

Dicho esto, sería curioso ver si realmente hay alguna diferencia.

Algunos (y google-able) lo mencionan como "Unity Build". Vincula locamente rápido y compila razonablemente rápido también. Es ideal para compilaciones en las que no necesita iterar, como una compilación de lanzamiento desde un servidor central, pero no es necesariamente para compilación incremental.

Y es un PITA para mantener.

EDITAR: aquí está el primer enlace de Google para obtener más información: http://buffered.io/posts/the-magic-of-unity-builds/

Lo que lo hace rápido es que el compilador solo necesita leer todo una vez, compilar y luego vincular, en lugar de hacerlo para cada archivo .cpp.

Bruce Dawson ha escrito mucho mejor sobre esto en su blog: http://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/

Estoy de acuerdo con Bruce; según mi experiencia, intenté implementar Unity Build para uno de mis proyectos .dll, que incluía una gran cantidad de encabezados y muchos .cpps; para reducir el tiempo de compilación general en el VS2010 (ya había agotado las opciones de compilación incremental) pero en lugar de reducir el tiempo de compilación, me quedé sin memoria y la compilación no pudo terminar la compilación.

Sin embargo para agregar; Encontré que habilitar la opción de compilación multiprocesador en Visual Studio ayuda bastante a reducir el tiempo de compilación; No estoy seguro si dicha opción está disponible en otros compiladores de plataforma.