C++20模块会改变静态库和共享库的结构吗

当然。与传统的头/库相比，模块是向用户表示库代码的一种非常不同的类型。模块的主要优点是编译器可以将其解析到抽象语法树(AST(级别。每个模块只发生一次这种情况——与每次包含特定头文件的情况相反。因此，加速的一种可能性是将非常频繁的头文件转换为模块，并节省大量编译器时间，而不是多次重新编译到AST，而只是一次。AST同样适用于模板。。。它是对C++语言的一个通用而完整的描述。

但这也是目前主要的"；缺点"：AST完全依赖于编译器。供应商、系统甚至编译器版本之间都不稳定。因此，分发AST毫无意义，至少在当前的工具链环境中是这样。

因此，在我的理解中，模块不容易取代常见的头/库。它们是轻量级(仅限最佳标头(和潜在的高度模板化代码的理想替代品，这些代码将多次包含在典型程序中。许多库，最重要的是标准库，都是这样的。但也有许多不同设计的库(小型API+重型二进制后端(。对于这些，我想，我们将不得不像以前一样继续使用include/库。但是，C++是向后兼容的，所以将模块与include混合在一起根本没有问题。

此外，模块可以仅包装包含文件(例如，使用API(。这可能不是一个非常强大的模块使用，但可能会导致更统一的编程模式。在这种情况下，您仍然需要将您的"；所以"；或"；dylib"；或任何库。

因此，我相信未来的某个时候会同时分发这两个模块，一些C++模块，还有传统的头文件+库。模块本身可以拆分为许多文件(只有"导出"符号对用户可见(。模块可能会遵循与标头截然不同的设计准则。这很可能不会有任何好处；每个模块一类"；，而是"；每个模块一整串逻辑连接的代码"；。