sirven - ¿Cómo se manejan las plantillas en el sistema de módulos C++?
template en c++ pdf (1)
Estoy leyendo el documento Un sistema de módulos para que C ++ comprenda los módulos de C ++, una característica propuesta para C ++.
No puedo entender completamente cómo se exportarán las plantillas con esta arquitectura de módulo.
¿Algunas ideas?
Actualmente, las implementaciones de C ++ realmente solo tienen dos "cosas" que corresponden al código: el código fuente que escribimos y editamos, y el ensamblaje, que el compilador emite en función de la fuente.
Debido a que las plantillas de C ++ están "reificadas", se escupe un ensamblaje separado para cada instanciación de la plantilla. Por esa razón, no se puede producir un ensamblaje donde se definen las plantillas, sino solo donde se utilizan. Es por eso que las plantillas tienen que estar en los archivos de encabezado para que, básicamente, se puedan copiar y pegar en el punto de uso (eso es todo lo que #include es realmente).
La idea es tener una tercera representación del código. Imagine que internamente el compilador tiene algún tipo de representación interna después de haber analizado el código pero antes de que comience a producir ensamblaje. La "cosa" que produce es, en última instancia, algún tipo de representación de un árbol de sintaxis abstracta (AST). Básicamente es exactamente su programa, mapeado desde una forma que es más fácil para los humanos, a una forma que es más fácil para las computadoras.
Esta es, en términos generales, la idea detrás de los módulos (o al menos su implementación). Toma su código y escupe algún tipo de archivo que representa el AST. Este AST es una representación completa de su programa, por lo que es completamente sin pérdidas. Sabe todo sobre las plantillas que declaraste, y así sucesivamente. Cuando se carga un módulo, simplemente carga este archivo y el compilador puede usarlo exactamente como si tuviera toda la fuente disponible. Pero, el paso de convertir una fuente legible por humanos en este AST es en realidad un paso bastante costoso. Comenzar con el AST puede ser mucho más rápido.
Si solo tienes una unidad de traducción, esto sería más lento. Después de todo, el análisis -> codegen es aún más rápido que el análisis -> serializar -> deserializar -> codegen. Pero digamos que tienes 10 unidades de traducción que # incluyen vector. Analizarás el código en el vector 10 veces. En este punto, el costo adicional de la serialización / deserialización se compensa por el hecho de que solo tiene que analizar una vez (y la deserialización se puede hacer mucho más rápido que el análisis; este formato de datos se diseñará específicamente para que la deserialización sea más rápida, mientras que el código fuente es Diseñado para ser legible, compatible con versiones anteriores, etc).
Los encabezados precompilados en cierto sentido son una vista previa de los módulos: https://clang.llvm.org/docs/PCHInternals.html