Módulos C ++ - ¿por qué fueron retirados de C ++ 0x? Serán de nuevo más tarde?
-
02-10-2019 - |
Pregunta
Me acaba de descubrir este antigua C ++ 0x proyecto sobre módulos en C ++ 0x.
La idea era salir del sistema .h / .cpp actual escribiendo archivos sólo .cpp que luego generar archivos de módulo durante la compilación, que luego a su vez ser utilizados por los demás archivos .cpp.
Esto parece ser una característica realmente grande.
Pero mi pregunta es: ¿por qué lo sacan de C ++ 0x? Fue por demasiadas dificultades técnicas? ¿Falta de tiempo? Y cree usted que van a considerar trabajar en él para una versión ulterior de C ++?
Solución
Desde el Estado de C ++ Evolución (Agrega san Francisco 2008) , la propuesta módulos se clasificó como "la partida para un TR separada:"
Estos temas se consideran demasiado importante como para esperar a otro estándar después de C ++ 0x antes de ser publicados, pero demasiado experimental para concluirse a tiempo para el siguiente estándar. Por lo tanto, estas características serán entregados por un informe técnico a la mayor brevedad.
La propuesta módulos simplemente no estaba listo y en espera de que habría retrasado terminar el C ++ 0x estándar. No era realmente retirado, se acaba nunca se incorpora en el documento de trabajo.
Otros consejos
C ++ Módulos de proyecto (Especificación técnica después de C ++ 17)
A borrador y varias revisiones actualizados para el C / C ++ módulo de especificación han sido publicadas por WG21 en open-std.org. Voy a mantener enlaces con los últimos documentos aquí:
- Proyecto de Trabajo, Extensiones a C ++ para los módulos N4610 (octubre de 2016).
- cuarta revisión publicada como P0142R0 (marzo de 2016).
- La redacción de módulos publicado como P0143R2 (marzo de 2016).
- El equipo de sonido metálico ha publicado una segunda revisión de sus cambios: P0273R1 (octubre de 2016).
Las siguientes entradas del blog contiene un resumen de las reuniones de normalización y en resumen, es un particular de la situación actual de los proyectos de módulos de:
- Trip Report: cumplen con los estándares de C ++ en Lenexa (mayo de 2015).
- Trip Report: cumplen con los estándares de C ++ en Kona (octubre de 2015).
- Trip Report: cumplen con los estándares de C ++ en Jacksonville (febrero de 2016).
- Trip Report: Reunión Normas C ++ en Oulu (junio de 2016).
- Trip Report: Reunión Normas C ++ en Issaquah (noviembre de 2016).
Actualización: Como se explica en el informe de viaje Kona que he vinculado al anterior, en la actualidad hay dos propuestas que compiten, uno de Microsoft y uno de Sonido metálico. La solución propuesta de Microsoft no permite exportar macros, mientras que la solución del equipo Clang apoyaría la exportación de macros. Hasta ahora, sólo Microsoft ha presentado formalmente un proyecto para una especificación del módulo.
módulo de especificación según lo propuesto por Microsoft
Aquí está una descripción rápida de los conceptos más importantes que esta propuesta contiene. Ya que es un proyecto esto podría posiblemente todavía cambiar. Los nuevos módulos estándar entre otras cosas consisten en lo siguiente:
A module
palabra clave para declarar un módulo, varios archivos pueden declarar esto para construir un módulo (pero para cada módulo único compilación unidad puede contener una sección export {}
):
module M;
Una import
palabra clave para módulos de importación, en vez de import
también podría decidirse la utilización using module
lugar, por lo que una nueva palabra clave de importación podría evitarse.
import std.io;
import module.submodule;
Una sintaxis export
, que define el público declaraciones que son parte de este módulo, no interfaz declaraciones que no debe ser exportado como parte del módulo se definirá fuera del bloque de exportación. Declaraciones puede ser cualquier tipo de declaración en C / C ++, es decir, no sólo las funciones, sino también variables, estructuras, plantillas, espacios de nombres y clases:
export {
int f(int);
double g(double, int);
int foo;
namespace Calc {
int add(int a, int b);
}
}
void not_exported_function(char* foo);
Un cambio importante de modules será que las macros y definiciones de preprocesador serán locales a los módulos y no serán exportados. Por lo tanto macros no tienen ningún impacto en los módulos importados:
#define FILE "my/file"
import std.io; //will not be impacted by the above definition
Su nota importante que el tanto el sistema preprocesador actual y los módulos serán capaces de co-existir y cabeceras todavía se puede utilizar por ejemplo para incluir macros.
Para obtener información más detallada sugiero leer el proyecto.
Clang Módulos
Sonido metálico ha estado trabajando en una implementación de módulos que se pueden encontrar en la página módulos clang . Sin embargo tañido actualmente no implementar una sintaxis concreta para los módulos, es decir, ninguno de la sintaxis anteriormente mencionado ha sido implementado por Clang. Para explicar esto que la página contiene la siguiente declaración:
En la actualidad, no hay sintaxis de C o C ++ para las declaraciones de importación. Tañido hará un seguimiento de la propuesta módulos en el comité de C ++. Ver la sección incluye las importaciones como para ver cómo los módulos se importan en la actualidad.
La parte principal que se implementa actualmente por Clang es el "Módulo Idioma del mapa", que permite que el módulo de escritura para los mapas de código existente que todavía utiliza los archivos de cabecera.
exportaciones macro desde Módulos
Como se mencionó anteriormente todavía no está claro si las exportaciones macro serán parte de la final Módulos TS . En P0273R1 se propuso la siguiente sintaxis para la exportación de macros:
#export define MAX(A,B) ((A) > (B)) ? (A) : (B);
Sonido metálico es el primer compilador para empezar a trabajar en módulos, incluso antes de la estandarización se ha completado. No hay mucho de una documentación aún, pero código de ejemplo se podría encontrar aquí:
http://llvm.org/viewvc/llvm-project/cfe/ tronco / test / Módulos /
Algunos comentarios de Douglas Gregor (el desarrollador de la aplicación de ellas):
http://clang-developers.42468.n3.nabble.com /C-modules-td3619936.html
En teoría, se puede definir un grupo de macros como ayudante begin_module, end_module, import_module para proteger a sí mismo de cualquier cambio probable que la sintaxis que vendrá en el futuro.
EDIT 1:
Douglas Gregor ha publicado una presentación sobre su puesta en práctica:
http://llvm.org/devmtg/2012-11/Gregor- Modules.pdf? = submit
EDIT 2:
El soporte de módulos de sonido metálico se han documentado aquí:
http://clang.llvm.org/docs/Modules.html
Datos 3:
Los módulos están ahora soportados en el compilador de Microsoft C ++, así:
http : //blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx
- Debido a que es el cambio conceptual muy grande.
- No hay necesidad real de la misma como la separación de las fuentes a h / CPP hace el trabajo
- Debido a que C ++ no define cómo real "módulos" Las bibliotecas son de construcción. Se va al desarrollador compilador y al enlazador.
- "Módulos" son a veces muy dependiente de la plataforma, por ejemplo DLL bastante diferentes de objetos compartidos. Así que no es tan trivial para combinar entre estos conceptos.