Bozza dei moduli C ++ (Specifiche tecniche dopo C ++ 17)
Una bozza e diverse revisioni aggiornate per la specifica del modulo C / C ++ sono state pubblicate da WG21 su open-std.org. Mi collegherò solo agli ultimi documenti qui:
- Bozza di lavoro, estensioni a C ++ per i moduli N4610 (ottobre 2016).
- Quarta revisione pubblicata come P0142R0 (marzo 2016).
- Formulazione per moduli pubblicata come P0143R2 (marzo 2016).
- Il team di clang ha pubblicato una seconda revisione delle modifiche: P0273R1 (ottobre 2016).
I seguenti post del blog contengono un riepilogo delle riunioni sugli standard e in particolare un riepilogo dello stato attuale della bozza dei moduli:
Aggiornamento: come spiegato nel report di viaggio di Kona che ho collegato sopra, ci sono attualmente due proposte concorrenti, una di Microsoft e una di Clang. La soluzione proposta da Microsoft non consente di esportare macro, mentre la soluzione del team Clang supporterebbe l'esportazione di macro. Finora solo Microsoft ha presentato formalmente una bozza per una specifica del modulo.
Specifica del modulo proposta da Microsoft
Ecco una rapida panoramica dei concetti più importanti contenuti in questa proposta. Poiché è una bozza, questo potrebbe ancora cambiare. Il nuovo standard dei moduli sarà tra l'altro composto da quanto segue:
Una moduleparola chiave per dichiarare un modulo, più file possono dichiararla per costruire un modulo (ma per ogni modulo solo un'unità di compilazione può contenere una export {}sezione):
module M;
Si potrebbe anche decidere di utilizzare una importparola chiave per importare i moduli, in modo da evitare una nuova parola chiave di importazione.importusing module
import std.io;
import module.submodule;
Una exportsintassi, che definisce le dichiarazioni pubbliche che fanno parte di questo modulo, le dichiarazioni non di interfaccia che non dovrebbero essere esportate come parte del modulo verranno definite al di fuori del blocco di esportazione. Le dichiarazioni possono essere qualsiasi tipo di dichiarazione in C / C ++, ovvero non solo funzioni ma anche variabili, strutture, modelli, spazi dei nomi e classi:
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 cambiamento importante dei moduli sarà che le macro e le definizioni del preprocessore saranno locali nei moduli e non verranno esportate. Pertanto le macro non hanno alcun impatto sui moduli importati:
#define FILE "my/file"
import std.io; //will not be impacted by the above definition
È importante notare che sia il sistema del preprocessore corrente che i moduli saranno in grado di coesistere e le intestazioni possono ancora essere utilizzate, ad esempio, per includere macro.
Per informazioni più dettagliate suggerisco di leggere la bozza.
Moduli Clang
Clang ha lavorato su un'implementazione dei moduli che può essere trovata nella pagina dei moduli clang . Tuttavia, clang attualmente non implementa una sintassi concreta per i moduli, ovvero nessuna delle sintassi sopra menzionate è stata implementata da Clang. Per spiegare questo la pagina contiene la seguente dichiarazione:
Al momento, non esiste una sintassi C o C ++ per le dichiarazioni di importazione. Clang terrà traccia della proposta dei moduli nel comitato C ++. Vedere la sezione Include come importazioni per vedere come i moduli vengono importati oggi.
La parte principale attualmente implementata da Clang è il "Module Map Language" che consente di scrivere mappe dei moduli per il codice esistente che utilizza ancora i file di intestazione.
Esportazioni di macro da moduli
Come accennato in precedenza, non è ancora chiaro se le esportazioni di macro faranno parte dei moduli TS finali . In P0273R1 è stata proposta la seguente sintassi per l'esportazione delle macro:
#export define MAX(A,B) ((A) > (B)) ? (A) : (B);