C ++模块：如果首先包含标准库模块，则包含的第3方文件是否仍会拉入普通标头？

如何解决C ++模块：如果首先包含标准库模块，则包含的第3方文件是否仍会拉入普通标头？

我开始尝试Microsoft Visual Studio的C ++模块实现。 Microsoft splits the standard library into five modules：

• std.regex
• std.filesystem
• std.memory
• std.threading
• std.core

我已将上述标准模块库替换为上述模块，以适合项目中的每个文件。但是，我包含许多第三方库文件。例如，假设第三方库的头文件中有#include <memory>，而在包含第三方库的头文件之前，我的文件中已经有import std.memory;。

std.memory模块是否定义了包括保护措施，从而导致第三方库跳过不必要的#include <memory>或包括内存，即使覆盖<memory>的模块已经被使用包括在内？

标准对此有什么要说的吗？在过渡到模块期间，这似乎是一个重要的问题：如果使用了第三方库，则如果仍然像以前那样包含它们，则对模块的好处似乎会大大减少。

解决方法

C ++ 20完全没有为标准库指定模块。而是指定（大多数）库标题可以导入：import<vector>;，依此类推。因此，无论是将标准库组件附加到 global模块，还是在这种情况下，假设的C ++ 23 std.vector模块接口单元都可能简单

module;
#include<vector>
export module std.vector;
namespace std {
  export using std::vector;
}

甚至

export module std.vector;
export import<vector>;

或将它们附加到命名模块，在这种情况下，标头<vector>可能只是

import std.vector;

（加上功能测试宏）。

如果翻译部门同时做这两种情况，则都不会中断

import std.vector;
#include<vector>

可能会发生#include头文件中包含每一行的情况：std::vector的两个定义位于不同的翻译单元中，就像两个{{1 }}。仍然存在效率的问题：采用前一种策略，翻译单元可以#include<vector>和import使用相同的组件，而命名模块为无法提供宏以防止重新解析。但是，使用这种策略的实现可能会选择将#include 翻译成#include以避免这种情况。

请注意，与MSVC的实现一样，C ++ 23标准库模块可能比标头更粗，因此上述内容适用于（例如）{{1} }和import<vector>;，std.containers，<vector>，等。

,

像#include <vector>这样的指令所做的完全取决于实现。该实现可以具有一种机制，用于检测模块vector是否已包含vector以及模块import由于#include <vector>中的定义已经可用。在这种情况下，#include指令可能什么也不做，或者#include只是一个空文件。

一旦C ++标准库在实际标准中模块化，并且随着模块实现的成熟，这些东西可能只是实现的一部分。但是，此类优化将基于特定于编译器的内在函数或编译器拥有的显式逻辑。它不一定适用于第三方，因此总体问题仍然存在。

解决此问题的主要方法是不要在模块中使用import第三方API标头；您 import 这样的标题。这就是为什么头文件import指令是模块系统的一部分的原因。通过import标头，您可以鼓励实现确保该标头仅被编译一次。

现在是的，如果您在每个#include <vector>上使用<vector>有10个头文件，那么import将为这些模块头文件编译10次。但是，如果您从项目中的10个不同文件中import头中的一个，则该头仅应编译一次。而且，extract_words版的模块标头仅在这些标头的内容发生更改时才需要重新编译，因此项目的后续构建不需要重新处理第三方API。

,

为了公平起见，我们不得不提到MSVC下的模块并未实现全部使用，而是部分使用，因此不要期望太多。就是说，现在标准说模块比tge include指令更有效，因为模块仅导入一次，类似于自定义语言实现支持的预编译标头。这样可以减少编译时间。非导出实体对导入模块的翻译单元没有影响。 此外，模块还允许您选择应该导出哪些单元以及不应该导出哪些单元，从而表达代码的逻辑结构。