02｜Modules（中）：解决编译性能和符号隔离的银弹

作者回复: C++的演进过程必定要不断借鉴其他的语言模型中的优点，这样才能不断现代化，在保持更高的性能的同时提升生产力。但是，C++跟Java和Python还是存在一个根本性区别，就是C++在演进过程中始终秉持着这样一个思想，即能在编译时解决的计算问题，就一定不要推迟到运行时。所以可以看到，自C++11之后推出的几乎所有新特性，都是为编译时服务的。这也是C++与其他编程语言之间最大的区别之一。

作者回复: 在ES Module之前，JS的模块化方案主要是各类“事实标准”，整体混乱且问题多多，ES Module的定案也花费了相当之多的时间，浏览器能够支持ES Module也是近些年的事情了，出于兼容性考量大部分前端项目还会沿用类似于webpack的方案。 而C++由于更多的历史遗留问题、技术限制甚至是标准委员会内不同大公司之间的一些博弈，导致Modules标准到C++20才得以定案。 模块化的目的就是名称（符号）隔离，并且支持控制模块内名称（符号）的可见性，从这个目的上无论是解释性语言和编译性语言其实是一致的，不同点在于实现原理、实现限制与因语言本身设计思路以及历史遗留问题导致的设计与实现的差异，这些都体现在具体的设计细节与实现技术细节上，就算不同编译性语言之间（比如Java与Rust）与不同解释性语言之间（比如Python与ES）也会有很大差异，但是本质的设计目的一致，所以基本设计构思是不会有差别的。

作者回复: C++本身因为需要向下兼容C语言就导致了很高的复杂性，但这也是C++的设计哲学，保证C++具备极佳的性能。但是一旦用了新的特性就可以部分抛弃对应的旧特性，这样就可以在工程上简化C++的复杂性，这也是C++演进的目标。我们作为开发者，要适当尝试去逐渐迭代使用新的特性，丢弃一些过去的惯用法，保证自己的编程习惯控制在一个大致固定的范围内，这也是为什么说C++20会是一个比较关键的时间节点，让大家逐步从C++11甚至更早的编程习惯下，过渡到新的编程世界中。

作者回复: 1.其实并不是花里胡哨，而是C++在语法兼容性上存在很重的历史负担，而且不能增添不必要的运行时成本，导致很多现代语言特性在C++中的实现就会变得非常“复杂”、“脆弱“，需要更多的技巧来集成到项目中。至于C++的库，其实在互联网时代之前C/C++的库绝对是最丰富的——想想看GNU的那么多库，而且Linux的传统是，但凡有一个应用，大概率会提供对应的.h声明和二进制动态库，基本都是给C/C++用的，所以其实C/C++并不缺少成熟的第三方库，只不过不如Python/Java那么方便。但到了互联网时代之后，Java/Python由于其使用率以及库/模块的集成便利程度，自然在成熟库的数量和丰富性上与C++不在一个等级。另外由于C++缺少标准的第三方模块仓库，所以一般找第三方库都要去GitHub自己挖掘，并且集成难度必然相对于Java/Python更高，这也是C++早期羸弱的Module机制导致的（再加上各个平台不一致的ABI标准），最终形成了一个比较恶劣的第三方库生态环境。 2.用Modules本质就是只需要.cpp或者说模块文件，而不再区分.h/.cpp。但其实Modules一般也是需要划分声明文件和实现文件，和.h/.cpp的分工有异曲同工之妙。

作者回复: 目前cmake生成的Visual Studio工程在使用C++ Modules时无法正常将源代码标记为模块接口或者模块实现，但如果源代码后缀名是ixx时就会将对应的文件作为模块接口/模块实现编译，因此我们将cpp文件复制了一个相同的ixx文件，以自动适配Visual Studio项目。

作者回复: 不知道你的clang版本号是多少，如果版本比较旧可以自己下载新版本源代码编译。但是clang对C++20的支持在3个主流编译器中的确是比较糟糕的，如果条件允许可以安装一个Windows虚拟机，然后使用VS，综合来说，就目前，Visual Studio对C++20的支持是最完善的。

作者回复: 悉心采纳。可以考虑每个标题作为一个章节来学习。后续会针对内容编排进行调整。

作者回复: 看起来概念复杂，但是在工程应用中其实非常简单（比如可以看后面的示例项目章节），而且不需要有很深入的理解就可以受益于现在的modules体系。可以期待一下 Modules（下），参考具体的代码实战有助于快速理解和掌握本课的内容。

作者回复: 从gcc和clang的新规定是可以将模块文件后缀名命名成.cppm，但其实这个是无所谓的，后缀名依然可以继续使用传统的.cpp。

作者回复: 即将跟随课程提供给大家。