几天来我一直在努力解决这个问题，我阅读了很多关于新 C++20 模块的文档和帖子，其中这个官方模块，这个和另一个在 Stackoverflow 上，但我真的无法解决这个问题.

我正在使用随Visual Studio Preview 16.6.0 2.0提供的 MSVC 编译器。我知道它还不是一个稳定的版本，但我想弄乱新功能来开始学习它们。

基本上我写了一个模块（myModule）和这个模块的两个分区（mySubmodule1和mySubmodule2），我在两个模块实现文件（mySubmodule1Impl.cpp和mySubmodule2Impl.cpp）中实现了它们。

mySubmodule1依赖于mySubmodule2，反之亦然。这是来源：

mySubmodule1.ixx

mySubmodule2.ixx

mySubmodule1Impl.cpp

mySubmodule2Impl.cpp

我的模块.ixx

正如你所看到的，我可以转发声明MyClass2，mySubmodule1但我不能转发声明MyClass1，mySubmodule2因为MyClass2我使用类型的具体对象MyClass1。

我用这一行编译：cl /EHsc /experimental:module /std:c++latest mySubmodule1.ixx mySubmodule2.ixx myModule.ixx mySubmodule1Impl.cpp mySubmodule2Impl.cpp Source.cppwhere Source.cppis just main.

我收到臭名昭著的错误 C2027: use of undefined type 'myNamespace::MyClass2' in mySubmodule1Impl.cppand mySubmodule2Impl.cppat the lines where I use MyClass2. 此外，编译器告诉我在有前向声明的地方查看 in 的声明MyClass2。mySubmodule1.ixx

现在，我真的不明白我的错误在哪里。我一遍又一遍地检查，但程序的逻辑对我来说似乎很完美。文件的编译顺序应该MyClass2在实现之前定义！

我尝试使用“旧”.h 和 .cpp 文件而不是模块来编译这个确切的程序，它编译并运行良好。所以我想我错过了关于这些新模块的一些东西。

我检查了第一个正式的模块提案（第 10.7.5 段），在第一个提案中有一个名为宣告所有权声明的构造，在这种情况下似乎是完美的。基本上，它允许您导入当前模块中另一个模块拥有的实体，但不导入模块本身。但在该提案的后期修订中，没有任何迹象。绝对没有。在新提案的“变更日志”部分甚至没有引用它。

请不要告诉我循环依赖是不好的。我经常知道它们很糟糕，但并非总是如此。即使您认为它们总是很糟糕，我也不会要求经验法则。我在问为什么我的代码用“旧” .h + .cpp 编译而不是新模块。为什么链接器看不到MyClass2.

编辑 1

这是答案中建议的新设计，但它仍然不起作用。我得到完全相同的错误：

mySubmodule1Impl.cpp

mySubmodule2Impl.cpp

所有其他文件均未更改。

我想开始测试和学习模块，摆脱头文件的日子，看看体验是否不同。我安装了所需的一切（安装程序中的 Visual Studio 模块选项），但 Clang 似乎无法解析导入。另一方面，当我切换到 MSVC 时，它工作正常。我目前正在使用 VS 2019 Insider 预览版。那么，我如何让 clang（10，最新版本）工作？

编辑：有问题的错误module not found与Clang有关。MSVC 工作正常。我需要将哪些标志传递给 Clang，以便它可以找到安装我的 VS-Installer 的模块？例如，我将 CLI 参数传递给 MSVC 以启用模块。

编辑：C++ 文件（main.cpp）：

制作文件

那么，我如何让 Clang 找到 VS 安装的模块，或者它可能已经安装的模块。

这是示例“Hello World”项目的zip。

谢谢你。

正如这个答案中所解释的，模板实例化允许通过不需要为使用它们的每个新文件中的每个新类型重新编译模板来减少编译时间和大小。

我也对C++20 模块应该如何提供一个干净的解决方案来向外部项目公开模板并减少 hpp/cpp 重复感到兴奋。

允许它们一起工作的语法是什么？

例如，我希望模块看起来有点像（未经测试，因此可能是错误的代码，因为我没有足够新的编译器/不确定它是否已实现）：

你好世界.cpp

helloworld_impl.cpp

主文件

然后将在https://quuxplusone.github.io/blog/2019/11/07/modular-hello-world中提到的编译（？）

理想情况下，我还希望模板定义可用于外部项目。

我认为我想要的是一种导入模块的方法，并在导入时决定：

• 使用模块中的所有模板，就好像它们只是声明一样（我将在另一个文件上提供我自己的实例化）
• 使用模块中的模板，就好像它们是定义一样

这基本上是我在 C++20 之前在“从包含的标头中删除定义，但也将模板公开为外部 API”中实现的，但该设置需要复制接口两次，这似乎是模块系统基本上可以为我们做的事情。

我有这个程序我正在尝试编译。住在这里

我正在阅读有关C++ 20 中的模块。该源仅包含有关在 Microsoft C++ 编译器上运行它的信息。是否有任何其他编译器实现了模块？如果是的话，我需要什么额外的标志来编译这个程序。

因此，C++20 承诺了新的模块功能，据说这将消除#include由预处理器驱动的当前系统的所有问题。

问题是：旧标题会发生什么？

这个问题可以分为2个：

1. 标准库头文件会发生什么<iostream>？

我很确定这是一个很容易回答的问题，C++ 标准一定已经解决了这个问题，但我问是因为我不知道该怎么做。您将如何替换该行：

有一个import声明？

2. 使用头文件的其他库（如<windows.h>）<unistd.h>和所有其他第三方 C/C++ 库会发生什么情况？

这个问题似乎更难回答。在我们良好的旧系统中，库生成器会将库编译为目标文件或静态/动态库，并将其与包含接口的/文件#include一起发布（作为用户，您将只有实现的源代码）如果它是一个开源库，则为该库）。.h.hpp

现在，这个新的模块系统只需要库制作者编译库并发布它。这背后的基本原理（据我所知）是链接器将知道库导出的内容（全部存储在目标文件中）并能够进行相应的链接。

当您必须使用具有目标文件和头文件的旧库时，就会出现问题。可以安全地假设大多数相关的库开发人员会将他们的代码转换为新的模块系统，但旧的（已停产的）库不会那么幸运。目标文件里面不会有模块名（因为它没有作为模块编译），所以使用库的代码不会有模块名来使用。在这种情况下图书馆用户应该怎么做？

Visual Studio 2019 不会尝试编译我的 .cxx 或 .ixx 文件。这是我的 .cxx 文件：

这是主要的：

我确实设置了这些标志：/std:c++latest, /experimental:module. 错误消息是

...但是我没有看到任何关于尝试编译 greetings.cxx 的行，所以这一定是问题所在。将其更改为 .ixx 无效。解决方法是什么？

使用以下 MCVE：

我收到投诉

我正在编译调试/Win32。运行时库是/MDd. 我有/std:c++latest并/experimental:module设置；命令行选项是

/JMC /experimental:module /permissive- /GS /analyze- /W3 /Zc:wchar_t /I"../../external/fmt-master/include" /ZI /Gm- /Od /Fd"Debug\vc142.pdb" /Zc:inline /fp:precise /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd /std:c++latest /FC /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\modules.pch" /diagnostics:column

std::cout访问、std::string、srand或时没有问题sin。什么可以告诉 Visual Studio 也找到该time功能？

假设我们有定义模块 foo 的模块接口源文件 foo.ixx。我们用

在许多不同的 cpp 文件中。与传统头文件 foo.h 包含在许多不同的 cpp 文件中的情况相比，编译时间会减少吗？如果编译时间减少了，为什么会这样呢？

我开始尝试 Microsoft Visual Studio 的 C++ 模块实现。微软将标准库分为五个模块：

• 标准正则表达式
• 标准文件系统
• 标准内存
• 标准线程
• 标准核心

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

模块是否std.memory定义了会导致第三方库跳过不必要的包含防护，#include <memory>或者它是否包含内存，即使模块覆盖<memory>已经包含在内？

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

传统上，C++ 库由头文件 + 在二进制文件中编译的实现组成（.a, .so, .dylib, .dll, ...）。头文件#include在源代码中，二进制部分链接到最终的可执行文件。

C++20 中的模块会改变这种布局吗？如果是这样，操作系统是否必须升级它们分发其核心库的方式，例如 Linux 中的标准库或 Windows 中的其他核心 dll？