Projet de modules C ++ (Spécification technique après C ++ 17)
Un projet et plusieurs révisions mises à jour pour la spécification du module C / C ++ ont été publiés par le WG21 sur open-std.org. Je ne lierai que les derniers documents ici:
- Working Draft, Extensions to C ++ pour les modules N4610 (octobre 2016).
- Quatrième révision publiée sous le numéro P0142R0 (mars 2016).
- Libellé des modules publié sous la cote P0143R2 (mars 2016).
- L'équipe clang a publié une deuxième révision de leurs modifications: P0273R1 (octobre 2016).
Les articles de blog suivants contiennent un résumé des réunions de normalisation et en particulier un résumé de l'état actuel du projet de modules:
Mise à jour: Comme expliqué dans le rapport de voyage de Kona que j'ai lié ci-dessus, il y a actuellement deux propositions concurrentes, une de Microsoft et une de Clang. La solution proposée par Microsoft ne permet pas d'exporter des macros, tandis que la solution de l'équipe Clang prendrait en charge l'exportation de macros. Jusqu'à présent, seul Microsoft a officiellement soumis un projet de spécification de module.
Spécification du module telle que proposée par Microsoft
Voici un bref aperçu des concepts les plus importants contenus dans cette proposition. Comme il s'agit d'un projet, cela pourrait encore changer. Le nouveau standard des modules comprendra entre autres les éléments suivants:
Un modulemot-clé pour déclarer un module, plusieurs fichiers peuvent le déclarer pour construire un module (mais pour chaque module, une seule unité de compilation peut contenir une export {}section):
module M;
Un importmot-clé pour importer des modules, à la place de importcelui-ci, pourrait également être décidé à utiliser à la using moduleplace, de sorte qu'un nouveau mot-clé d'importation pourrait être évité.
import std.io;
import module.submodule;
Une exportsyntaxe, qui définit les déclarations publiques qui font partie de ce module, les déclarations non-interface qui ne doivent pas être exportées dans le cadre du module seront définies en dehors du bloc d'exportation. Les déclarations peuvent être n'importe quel type de déclaration en C / C ++, c'est-à-dire non seulement des fonctions mais aussi des variables, des structures, des modèles, des espaces de noms et des classes:
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 changement important des modules sera que les macros et les définitions de préprocesseur seront locales aux modules et ne seront pas exportées. Ainsi, les macros n'ont aucun impact sur les modules importés:
#define FILE "my/file"
import std.io; //will not be impacted by the above definition
Il est important de noter que le système de préprocesseur actuel et les modules pourront coexister et que les en-têtes peuvent toujours être utilisés par exemple pour inclure des macros.
Pour plus d'informations, je suggère de lire le projet.
Modules Clang
Clang a travaillé sur une implémentation de modules qui peut être trouvée sur la page des modules clang . Cependant, clang n'implémente actuellement pas de syntaxe concrète pour les modules, c'est-à-dire qu'aucune des syntaxes mentionnées ci-dessus n'a été implémentée par Clang. Pour expliquer cela, la page contient la déclaration suivante:
À l'heure actuelle, il n'y a pas de syntaxe C ou C ++ pour les déclarations d'importation. Clang suivra la proposition de modules dans le comité C ++. Consultez la section Inclut comme importations pour voir comment les modules sont importés aujourd'hui.
La partie principale actuellement implémentée par Clang est le "Module Map Language" qui permet d'écrire des cartes de module pour le code existant qui utilise toujours des fichiers d'en-tête.
Exportations de macros à partir de modules
Comme mentionné ci-dessus, il est encore difficile de savoir si les exportations de macros feront partie des modules TS finaux . Dans P0273R1, la syntaxe suivante a été proposée pour l'exportation des macros:
#export define MAX(A,B) ((A) > (B)) ? (A) : (B);