Ответ 1
Уже есть два компилятора, которые поддерживают модули С++
clang: http://clang.llvm.org/docs/Modules.htmlMS VS 2015: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx
Похоже, что подход Microsoft выглядит наиболее привлекательным, главным образом потому, что Microsoft бросает гораздо больше ресурсов на их реализацию, чем кто-либо из людей-кланов в настоящее время. См. https://llvm.org/bugs/buglist.cgi?list_id=100798&query_format=advanced&component=Modules&product=clang, что я имею в виду, в модулях для С++ есть некоторые большие ошибки showstopper, тогда как модули для C или особенно Objective C выглядят гораздо более полезными в коде реального мира, Крупнейший и самый важный клиент Visual Studio, Microsoft, активно продвигает модули, потому что он решает целую кучу проблем с масштабированием внутренней сборки, а внутренний код Microsoft - это самый сложный С++ для компиляции в любом месте, поэтому вы не можете выбросить какой-либо компилятор кроме MSVC (например, удачи, получая clang или GCC, чтобы скомпилировать функции линии 40k). Поэтому трюки для сборки clang, используемые Google и т.д., Не доступны для Microsoft, и у них есть огромная насущная необходимость, чтобы они были исправлены раньше, чем позже.
Это не означает, что в предложении Microsoft нет серьезных проблем с дизайном, когда они применяются на практике для крупных базовых кодов реального мира. Однако Габи считает, что вы должны реорганизовать свой код для модулей, и пока я не согласен, я вижу, откуда он.
При запуске нового проекта, на что я должен обратить внимание, чтобы иметь возможность использовать функцию модулей, когда она в конечном итоге выпущена в моем компиляторе?
Поскольку Microsoft-компилятор в настоящее время должен внедрять модули, вы должны убедиться, что ваша библиотека может использоваться во всех этих формах:
- Динамическая библиотека
- Статическая библиотека
- Только библиотека заголовков
Что-то очень удивительное для многих людей, так это то, что модули С++, которые в настоящее время предполагается реализовать, сохраняют эти различия, поэтому теперь вы получаете вариант С++ Module для всех трех выше, с первым наиболее перспективным как люди ожидают, что модуль С++ будет, и последний выглядит как более полезный предварительно скомпилированный заголовок. Причина, по которой вы должны поддерживать эти варианты, состоит в том, что вы можете повторно использовать большинство тех же машин препроцессора, чтобы также поддерживать С++ модули с очень небольшой дополнительной работой.
Позднее Visual Studio позволит связать файл определения модуля (файл .ifc) в качестве ресурса в DLL. Это, наконец, устранит необходимость в расширении .lib и .dll на MSVC, вы просто поставьте единую DLL компилятору, и все это "просто работает" на импорте модуля, без заголовков или чего-либо еще. Это, конечно, немного пахнет COM, но без большинства преимуществ COM.
Можно ли использовать модули в одной кодовой базе и поддерживать совместимость со старыми компиляторами, которые его не поддерживают?
Я собираюсь предположить, что вы имели в виду жирный текст, вставленный выше.
Ответ, как правило, да с еще большим удовольствием от препроцессора. #include <someheader> может превращаться в import someheader внутри заголовка, потому что препроцессор все еще работает как обычно. Таким образом, вы можете пометить отдельные заголовки библиотек поддержкой модулей С++ на таких строках:
// someheader.hpp
#if MODULES_ENABLED
# ifndef EXPORTING_MODULE
import someheader; // Bring in the precompiled module from the database
// Do NOT set NEED_DEFINE so this include exits out doing nothing more
# else
// We are at the generating the module stage, so mark up the namespace for export
# define SOMEHEADER_DECL export
# define NEED_DEFINE
# endif
#else
// Modules are not turned on, so declare everything inline as per the old way
# define SOMEHEADER_DECL
# define NEED_DEFINE
#endif
#ifdef NEED_DEFINE
SOMEHEADER_DECL namespace someheader
{
// usual classes and decls here
}
#endif
Теперь в вашем main.cpp или что-то еще, вы просто выполните:
#include "someheader.hpp"
... и если у компилятора есть /experimental: modules/DMODULES_ENABLED, тогда ваше приложение автоматически использует версию С++ Modules вашей библиотеки. Если это не так, вы получаете встроенное включение, как мы всегда делали.
Я считаю, что это минимально возможный набор изменений в исходный код, чтобы теперь готовить модули кода. Вы заметите, что я ничего не сказал о сборке систем, это потому, что я все еще отлаживаю инструмент cmake, который я написал, чтобы получить все это, чтобы "просто работать", и я ожидаю отладки его еще несколько месяцев. Ожидайте увидеть его, возможно, на конференции С++ в следующем году или в следующем году:)