已经有两个编译器支持 C++ 模块
叮当声：http://clang.llvm.org/docs/Modules.html
MS VS 2015：http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx
微软的方法似乎是最受关注的方法，主要是因为微软在其实施中投入的资源比目前任何 clang 人都多。请参阅https://llvm.org/bugs/buglist.cgi?list_id=100798&query_format=advanced&component=Modules&product=clang 了解我的意思，C++ 的模块中有一些大的引人注目的错误，而 C 或特别是 Objective C 的模块在现实世界的代码中看起来更有用。 Visual Studio 最大和最重要的客户 Microsoft 正在大力推动 Modules，因为它解决了大量内部构建可扩展性问题，而且 Microsoft 的内部代码是现有的任何地方最难编译的 C++ 代码，因此您不能扔任何编译器除了 MSVC 之外（例如，祝你好运，让 clang 或 GCC 编译 40k 行函数）。因此，Google 等使用的 clang 构建技巧不适用于 Microsoft，他们迫切需要尽快修复它。
这并不是说 Microsoft 提案在实际应用于大型现实世界代码库时没有严重的设计缺陷。然而 Gaby 认为你应该重构你的模块代码，虽然我不同意，但我可以看到他来自哪里。
现在开始一个新项目时，我应该注意什么才能最终在我的编译器中发布模块功能？
就目前微软的编译器预期实现模块而言，您应该确保您的库可用于所有这些形式：
- 动态库
- 静态库
- 仅标题库
令很多人感到惊讶的是，目前预期实现的 C++ 模块保留了这些区别，所以现在您获得了上述所有三个的 C++ 模块变体，其中第一个看起来最就像人们期望的 C++ 模块一样，最后一个看起来最像一个更有用的预编译头文件。您应该支持这些变体的原因是因为您可以重用大多数相同的预处理器机器，也可以通过很少的额外工作来支持 C++ 模块。
以后的 Visual Studio 将允许将模块定义文件（.ifc 文件）作为资源链接到 DLL 中。这最终将消除 MSVC 上对 .lib 和 .dll 区别的需要，您只需向编译器提供一个 DLL，它在模块导入时“正常工作”，不需要头文件或其他任何东西。这当然有点像 COM，但没有 COM 的大部分优点。
是否可以在单个代码库中使用模块，并且仍然保持与不支持它的旧编译器的兼容性？
我假设您的意思是上面插入的粗体文本。
答案通常是肯定的，而且预处理器宏更有趣。 #include <someheader> 可以在标头中变成import someheader，因为预处理器仍然照常工作。因此，您可以使用 C++ 模块支持标记单个库头文件，如下所示：
// 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 那么你的应用程序会自动使用你的库的 C++ 模块版本。如果没有，您将像我们一直做的那样获得内联包含。
我认为这些是对您的源代码进行的最小可能更改，以使您的代码现在可以准备好模块。你会注意到我对构建系统只字未提，这是因为我仍在调试我编写的 cmake 工具，以使所有这些东西都能无缝地“正常工作”，而且我预计还要调试几个月。期待在明年或后年的 C++ 会议上看到它:)