C++ Modules draft (Especificación técnica después de C++17)

Un borrador y varias revisiones actualizadas para la especificación del módulo C/C++ han sido publicados por WG21 en open-std.org. Voy a enlazar solo a los últimos documentos aquí:

• Borrador de trabajo, Extensiones a C++ para Módulos N4610 (Octubre de 2016).
• Cuarta revisión publicada como P0142R0 (Marzo de 2016).
• Texto para 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:

• Informe de viaje: Reunión de estándares C++ en Lenexa (Mayo de 2015).
• Informe de viaje: Los estándares de C++ cumplen en Kona (Octubre de 2015).
• Informe de viaje: Reunión de estándares C++ en Jacksonville (Febrero de 2016).
• Informe de viaje: Reunión de estándares C++ en Oulu (Junio de 2016).
• Informe de viaje: Reunión de Estándares C++ en Issaquah (Noviembre de 2016).

Actualización: Como se explica en el informe de viaje de Kona al que me vinculé anteriormente, actualmente hay dos propuestas competidoras, una de Microsoft y uno de Clang. La solución propuesta de 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 propuesta por Microsoft

He aquí un breve resumen de los conceptos más importantes que contiene esta propuesta. Como es un borrador, esto podría cambiar. El nuevo estándar de módulos será, entre otras cosas consisten en lo siguiente:

Una palabra clave module 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;

Una palabra clave import para importar módulos, en lugar de import también podría decidirse usar using module en su lugar, por lo que se podría evitar una nueva palabra clave de importación.

import std.io;
import module.submodule;

Una sintaxis export, que define las declaraciones públicas que forman parte de este módulo, las declaraciones que no sean de interfaz que no deban 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 a los módulos y no se exportarán. Por lo tanto, las macros no tienen ningún impacto en las importaciones módulos:

#define FILE "my/file"
import std.io;   //will not be impacted by the above definition

Es importante tener en cuenta que tanto el sistema de preprocesador actual como los módulos podrán coexistir y las cabeceras todavía 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, ninguna de las sintaxis mencionadas anteriormente ha sido implementada por Clang. Para explicar esto, la página contiene la siguiente declaración:

En la actualidad, no hay 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 está implementada por Clang es el "Module Map Language" que permite escribir mapas de módulos para código que todavía usa archivos de encabezado.

Exportaciones de macros desde Módulos

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

#export define MAX(A,B) ((A) > (B)) ? (A) : (B);

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 implementa):
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 los probables cambios en la sintaxis que vendrá en el futuro.

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

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

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

1. Porque es un cambio conceptual muy grande.
2. No hay necesidad real de ello 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. Deja al desarrollador del compilador y al enlazador.
4. Los "módulos" a veces dependen bastante de la plataforma, por ejemplo, DLL bastante diferentes desde objetos compartidos. Así que no es tan trivial fusionar estos conceptos.