57

已经有两个编译器支持 C++ 模块：

现在开始一个新项目时，我应该注意什么才能最终在我的编译器中发布模块功能？

是否可以使用模块并仍然保持与不支持它的旧编译器的兼容性？

4

2 回答 2

29

已经有两个编译器支持 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 行函数）。因此，谷歌等使用的 clang 构建技巧对微软来说是不可用的，他们迫切需要尽快修复它。

这并不是说微软的提议在实际应用于大型现实世界代码库时没有一些严重的设计缺陷。然而 Gaby 认为你应该重构你的模块代码，虽然我不同意，但我可以看到他来自哪里。

现在开始一个新项目时，我应该注意什么才能最终在我的编译器中发布模块功能？

就目前微软的编译器预期实现模块而言，您应该确保您的库可用于所有这些形式：

  1. 动态库
  2. 静态库
  3. 仅标题库

令许多人感到惊讶的是，目前预期实现的 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++ 会议上看到它 :)

于 2016-07-06T15:24:34.287 回答
5

是否可以使用模块并仍然保持与不支持它的旧编译器的兼容性？

不，这是不可能的。#ifdef使用这样的魔法可能是可能的：

#ifdef CXX17_MODULES
    ...
#else
    #pragma once, #include "..." etc.
#endif

但这意味着您仍然需要提供.h支持，从而失去所有好处，而且您的代码库现在看起来很丑陋。

如果您确实想遵循这种方法，那么检测CXX17_MODULES我刚刚编写的“”的最简单方法是编译一个小型测试程序，该程序使用带有您选择的构建系统的模块，并为每个人定义一个全局以查看是否编译成功与否。

现在开始一个新项目时，我应该注意什么才能最终在我的编译器中发布模块功能？

这取决于。如果您的项目是企业项目并为您提供食物，那么一旦它在马厩中发布，我会等待几年，以便它得到广泛的适应。另一方面，如果您的项目能够负担得起最前沿的技术，请务必使用模块。

基本上，这与 Python3 和 Python2 或 PHP7 和 PHP5 的情况相同。您需要在成为一名优秀的最新程序员和不讨厌 Debian 的人之间找到平衡；-)

于 2016-04-02T16:42:59.703 回答