Módulos C ++: ¿por qué se eliminaron de C ++ 0x? ¿Volverán más tarde?

110

Acabo de descubrir este antiguo borrador de C ++ 0x sobre módulos en C ++ 0x.

La idea era salir del sistema .h / .cpp actual escribiendo solo archivos .cpp que luego generarían archivos de módulo durante la compilación, que luego serían usados ​​por los otros archivos .cpp.

Esta parece una característica realmente excelente.

Pero mi pregunta es: ¿por qué lo eliminaron de C ++ 0x? ¿Fue por demasiadas dificultades técnicas? ¿Falta de tiempo? ¿Y cree que considerarán trabajar en ello para una versión posterior de C ++?

Tomaka17
fuente

Respuestas:

70

Desde el estado de la evolución de C ++ (posterior a San Francisco 2008) , la propuesta de módulos se clasificó como "Encabezado para un TR separado:"

Estos temas se consideran demasiado importantes para esperar otro estándar después de C ++ 0x antes de ser publicados, pero demasiado experimentales para finalizar a tiempo para el próximo estándar. Por lo tanto, estas características se entregarán mediante un informe técnico lo antes posible.

La propuesta de módulos simplemente no estaba lista y esperarla habría retrasado la finalización del estándar C ++ 0x. En realidad, no se eliminó, simplemente nunca se incorporó al documento de trabajo.

James McNellis
fuente
89

Borrador de módulos C ++ (Especificación técnica posterior a C ++ 17)

WG21 ha publicado un borrador y varias revisiones actualizadas de la especificación del módulo C / C ++ en open-std.org. Solo vincularé los documentos más recientes aquí:

  • Borrador de trabajo, Extensiones a C ++ para los módulos N4610 (octubre de 2016).
  • Cuarta revisión publicada como P0142R0 (marzo de 2016).
  • Redacción de los módulos publicados como P0143R2 (marzo de 2016).
  • El equipo de clang ha publicado una segunda revisión de sus cambios: P0273R1 (octubre de 2016).

Las siguientes publicaciones del blog contienen un resumen de las reuniones de estándares y, en particular, un resumen del estado actual del borrador de los módulos:

Actualización: como se explicó en el informe de viaje de Kona al que me vinculé anteriormente, actualmente hay dos propuestas en competencia, una de Microsoft y otra de Clang. La solución propuesta por Microsoft no permite exportar macros, mientras que la solución del equipo de Clang admitiría la exportación de macros. Hasta ahora, solo Microsoft ha presentado formalmente un borrador para una especificación de módulo.

Especificación del módulo propuesto por Microsoft

A continuación, se ofrece una descripción general rápida de los conceptos más importantes que contiene esta propuesta. Como es un borrador, esto posiblemente aún podría cambiar. El nuevo estándar de módulos consistirá, entre otras cosas, en lo siguiente:

Una modulepalabra clave para declarar un módulo, varios archivos pueden declarar esto para construir un módulo (pero para cada módulo solo una unidad de compilación puede contener una export {}sección):

module M;

También podría decidirse utilizar una importpalabra clave para importar módulos, en lugar de importella using module, por lo que podría evitarse una nueva palabra clave de importación.

import std.io;
import module.submodule;

Una exportsintaxis, que define las declaraciones públicas que forman parte de este módulo, las declaraciones que no son de interfaz que no deben exportarse como parte del módulo se definirán fuera del bloque de exportación. Las declaraciones pueden ser cualquier tipo de declaración en C / C ++, es decir, no solo 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 módulos será que las macros y las definiciones de preprocesador serán locales para los módulos y no se exportarán. Por tanto, las 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

Es importante señalar que tanto el sistema de preprocesador actual como los módulos podrán coexistir y los encabezados aún se pueden usar, por ejemplo, para incluir macros.

Para obtener información más detallada, sugiero leer el borrador.

Módulos Clang

Clang ha estado trabajando en una implementación de módulos que se puede encontrar en la página de módulos de clang . Sin embargo, clang actualmente no implementa una sintaxis concreta para los módulos, es decir, Clang no ha implementado ninguna de las sintaxis mencionadas anteriormente. Para explicar esto, la página contiene la siguiente declaración:

En la actualidad, no existe una sintaxis C o C ++ para las declaraciones de importación. Clang hará un seguimiento de la propuesta de módulos en el comité de C ++. Consulte la sección Incluye como importaciones para ver cómo se importan los módulos hoy.

La parte principal que actualmente implementa Clang es el "Lenguaje de mapa de módulo" que permite escribir mapas de módulo para código existente que todavía usa archivos de encabezado.

Exportaciones de macros de módulos

Como se mencionó anteriormente, aún no está claro si las exportaciones macro serán parte de los módulos TS finales . En P0273R1 se propuso la siguiente sintaxis para la exportación de macros:

#export define MAX(A,B) ((A) > (B)) ? (A) : (B);
lanoxx
fuente
2
Actualización de 2018 Rapperswil, existe la propuesta fusionada de Gabriel dos Reis y Richard Smith, p1103r0. botondballo.wordpress.com/2018/06/20/…
Dwayne Robinson
32

Clang es el primer compilador que comienza a trabajar en módulos incluso antes de que se complete la estandarización. Todavía no hay mucha documentación, pero se puede encontrar un código de ejemplo aquí:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/

Algunos comentarios de Douglas Gregor (el desarrollador que los implementó):
http://clang-developers.42468.n3.nabble.com/C-modules-td3619936.html

En teoría, puede definir un montón de macros auxiliares como begin_module, end_module, import_module para protegerse de cualquier cambio probable en la sintaxis que vendrá en el futuro.

EDICIÓN 1:
Douglas Gregor ha publicado una presentación sobre su implementación:
http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf?=submit

EDIT 2:
El soporte del módulo en clang se ha documentado aquí:
http://clang.llvm.org/docs/Modules.html

EDICIÓN 3: Los
módulos ahora también son compatibles con el compilador C ++ de Microsoft: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1. aspx

zah
fuente
-39
  1. Porque es un cambio conceptual muy grande.
  2. No hay una necesidad real, ya que la separación de las fuentes a h / cpp hace el trabajo
  3. Porque C ++ no define cómo se construyen las bibliotecas de "módulos" reales. Lo deja en manos del desarrollador del compilador y del enlazador.
  4. Los "módulos" a veces dependen bastante de la plataforma, por ejemplo, las DLL son bastante diferentes de los objetos compartidos. Por eso no es tan trivial fusionarse entre estos conceptos.
Artyom
fuente
78
Ciertamente hay una necesidad. .h / .cpp es una solución ridículamente mala y anticuada. Un sistema de módulos sería un gran cambio, pero es uno que el comité de estándares aparentemente considera importante.
jalf
13
El modelo de construcción del encabezado es el problema que los módulos deben resolver, no la solución. Además, los módulos no reemplazan a las DLL / SO.
bames53
5
Esto es incorrecto: 1. La propuesta del módulo tiene mucho cuidado para garantizar la compatibilidad con versiones anteriores del sistema de encabezado existente, de modo que nada se rompa cuando se introduzcan módulos en el futuro. 2. La necesidad de reducir la complejidad del tiempo de compilación del módulo de encabezado de una complejidad O (M * N) a O (M + N) está muy bien documentada. 3. El estándar del módulo no dictará cómo se compilan y vinculan los módulos, pero agrega una semántica clara para separar entre la API pública y privada de un módulo. 4. El formato binario de las DLL u objetos compartidos no se ve afectado por el estándar.
lanoxx
3
"No hay una necesidad real, ya que la separación de las fuentes a h / cpp hace el trabajo", al igual que el corte con cadena de un dedo inyectado, ¡pero no significa que no sea un problema! Solo mire .NET o cualquier otro idioma más nuevo, tener que ordenar las cosas de cierta manera solo para que realmente pueda ser visible o compilarse correctamente es una gran carga que debe desaparecer.
paulm