проект модулей C++ (техническая спецификация после C++17)

проект и несколько обновленных редакций спецификации модуля C/C++ были опубликованы WG21 ВКЛ open-std.org. я буду ссылаться только на последние документы здесь:

• рабочий проект расширения на C++ для модули N4610 (октябрь 2016).
• четвертая редакция опубликована как P0142R0 (март 2016).
• формулировка для модулей, опубликованных как P0143R2 (март 2016).
• команда clang опубликовала вторую редакцию своих изменений:P0273R1 (октябрь 2016).

следующие сообщения в блоге содержат резюме совещаний по стандартам и, в частности, резюме текущего состояния проекта модулей:

• Отчет О Поездке: C++ Встреча стандартов в Lenexa (май 2015).
• Отчет О Поездке: встреча стандартов C++ в Коне (октябрь 2015).
• Отчет О Поездке: встреча стандартов C++ в Джексонвилле (февраль 2016).
• Отчет О Поездке: встреча стандартов C++ в Оулу (июнь 2016).
• Отчет О Поездке: встреча стандартов C++ внутри Иссакуа (ноябрь 2016).

обновление: как объяснено в отчете о поездке Kona, который я связал выше, в настоящее время есть два конкурирующих предложения, одно от Microsoft и одно от Clang. Предлагаемое решение от Microsoft не позволяет экспортировать макросы, в то время как решение от команды Clang будет поддерживать экспорт макросов. Пока только Microsoft официально представила проект спецификации модуля.

модуль спецификация, предложенная Microsoft

вот краткий обзор наиболее важных концепций, которые содержит это предложение. Как его проект, это может все еще измениться. Новый стандарт модулей будет среди прочего состоять из следующего:

A module ключевое слово для объявления модуля, несколько файлов могут объявить это, чтобы построить один модуль (но для каждого модуля только один compilation-unit может содержать элемент export {} раздел):

module M;

An import ключевое слово для импорта модулей, а не import может быть также решено использовать using module вместо этого, так что новое ключевое слово импорта можно было бы избежать.

import std.io;
import module.submodule;

An export синтаксис, который определяет public декларации, которые являются частью этого модуля, non-интерфейс декларации то, что не должно быть экспортировано как часть модуля, будет определено вне блока экспорта. декларации может быть любым видом объявления В C / C++, то есть не только функции, но и переменные, структуры, шаблоны, пространства имен и классы:

export {
    int f(int);
    double g(double, int);

    int foo;

    namespace Calc {
         int add(int a, int b);
    }        
}

void not_exported_function(char* foo);

важным изменением модулей будет то, что макросы и определения препроцессора будут локальными для модулей и не будут экспортироваться. Таким образом, макросы не оказывают никакого влияния на импортируемые модули:

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

важно отметить, что как текущая система препроцессора, так и модули смогут сосуществовать, а заголовки все еще могут используется, например, для включения макросов.

для получения более подробной информации предлагаю ознакомиться с проектом.

Лязгом Модули

Clang работает над реализацией модулей, которые можно найти по адресу страница модулей clang. Однако clang в настоящее время не реализует конкретный синтаксис для модулей, то есть ни один из вышеупомянутых синтаксисов не был реализован Clang. Чтобы объяснить это, страница содержит следующее заявление:

в настоящее время нет синтаксиса C или C++ для объявлений импорта. Clang будет отслеживать предложение модулей в комитете по С++. Раздел включает в себя как импорт, чтобы увидеть, как модули импортируются сегодня.

основная часть, которая в настоящее время реализуется Clang, - это "язык карт модулей", который позволяет писать карты модулей для существующего кода, который все еще использует файлы заголовков.

экспорт макросов из Модули

Как упоминалось выше, все еще неясно, будет ли экспорт макросов частью окончательного модули TS. В P0273R1 для экспорта макросов был предложен следующий синтаксис:

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

Clang является первым компилятором, который начинает работать над модулями еще до завершения стандартизации. Существует не так много документации, но пример кода можно найти здесь:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/

некоторые комментарии от Дугласа Грегора (разработчик их реализует):
http://clang-developers.42468.n3.nabble.com/C-modules-td3619936.html

в теории, вы можете определите группу вспомогательных макросов, таких как begin_module, end_module, import_module, чтобы защитить себя от любых вероятных изменений синтаксиса, которые произойдут в будущем.

редактировать 1:
Дуглас Грегор выпустил презентацию о своем implementation:
http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf?=submit

EDIT 2:
Поддержка модуля в clang были задокументированы здесь:
http://clang.llvm.org/docs/Modules.html

редактировать 3:
Модули теперь поддерживаются и в компиляторе Microsoft C++ : http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx

1. потому что это очень большие концептуальные изменения.
2. в этом нет реальной необходимости, так как разделение источников на h/cpp делает работу
3. потому что C++ не определяет, как создаются фактические библиотеки "модулей". Он уходит это разработчику компилятора и компоновщику.
4. "модули" иногда довольно зависят от платформы, например DLL совсем разные из общих объектов. Так что не так уж тривиально сливаться между этими понятиями.