C开发者怒了这个无用的模块设计最终会害死C！

　　2018年年底，C标准委员会历史上规模最大的一次会议在美国SanDiego召开，讨论了哪些特性要加入到
　　C20
　　中。其中，Modules便是可能进入C20的一大重要特性：一直以来C一直通过引用头文件方式使用库，而其他90年代以后的语言比如Java、C、Go等语言都是通过import包的方式来使用库。现在C决定改变这种情况了，在C20中将引入Modules，它和Java、Go等语言的包的概念是类似的，直接通过import包来使用库，再也看不到头文件了。
　　然而就是这一特性，前段时间在Twitter上引发了不小的讨论。再加上诸多其他问题，
　　C20还未发布就已凉凉
　　的论调也早有苗头。C模块化，究竟是问题多多的无用尝试，还是如期待般能带来其承诺的性能升级呢？
　　作者vectorofbool
　　译者苏本如
　　责编仲培艺
　　出品CSDN（ID：CSDNNews）
　　以下为译文：
　　CModules（模块化）被视作C自诞生以来最大的变化，其设计有几个基本目标：
　　1。自顶向下隔离：模块的导入程序不能影响正在导入的模块的内容。导入源中编译器（预处理器）的状态与导入代码的处理无关。
　　2。自下而上隔离：模块的内容不会影响导入代码中预处理器的状态。
　　3。横向隔离：如果两个模块由同一个文件导入，则它们之间不会串扰。导入语句的顺序无关紧要。
　　4。物理封装：只有模块显式声明为导出的实体才会对使用者可见。模块中未导出的实体不会影响其他模块中的名称查找（除了ADL可能有一些不同之处【依赖实参的名字查找】，但这就说来话长了）。
　　5。模块化接口：强制任何给定模块的公共接口在称为模块接口单元（MIU）的单个TU中声明。模块接口子集的实现可以在称为分区的不同TU中定义。
　　如果你期望Modules可以像C的许多其它功能一样经久不衰，那么你会注意到上面这个列表中缺少了编译速度。然而，这是CModules模块最大的承诺之一。模块带来的速度提升可能就是归功于上面的设计。
　　下面我列出从Modules设计中受益匪浅的C编译的几个方面，按照从最明显到最不明显的顺序：
　　1。标记化缓存（TokenizationCaching）：由于TU的隔离，当模块后面导入另一个TU时，可以缓存已经标记化的TU。
　　2。解析树缓存（ParsetreeCaching）：和标记化缓存一样。标记化和解析是C编译中开销最大的操作之一。我自己的测试显示，对于具有大量预处理输出的文件，解析可能会占用高达30的编译时间。
　　3。延迟重编译（LazyRegeneration）：如果foo导入了bar，然后我们修改了bar的实现，我们可以不需要对foo立即重新编译。只有对bar接口修改后才需要重新编译foo。
　　4。模板专门化：这一点比较微妙，可能需要更多的工作来实现，但潜在的加速是巨大的。简而言之，模块接口单元中出现的类或函数模板在经过专门化处理后可以在磁盘上缓存并供后续需要时加载。
　　5。内联函数代码复制缓存：内联函数（包括函数模板和类模板的成员函数）的代码复制结果可以缓存，然后由编译器后端重新加载。
　　6。内联函数省略代码复制：externtemplate允许编译器省略对函数和类模板执行代码复制，这对编辑器的代码去重操作非常有益。模块允许编译器隐式执行更多的externtemplatestyle优化。
　　看上去模块设计相当不错，不是吗？
　　但是我们都忽略了一个非常可怕且极为糟糕的缺陷。
　　还记得Fortran吗？
　　FORTRAN实现了与C的设计有点相似的模块系统。几个月前，SG15工具研究小组在圣地亚哥提交了一篇文章（http：www。openstd。orgjtc1sc22wg21docspapers2018p1300r0。pdf），据我所知，这篇文章迄今为止没有得到任何相关人士的讨论和评论。
　　文章要点摘录如下：
　　1。我们有模块foo和bar，分别由foo。cpp和bar。cpp定义。
　　2。bar。cpp里有importfoo；语句。
　　3。在编译bar。cpp时，如何确保importfoo被解析？当前的设计和实现有一个为foo定义的所谓二进制模块接口（简称BMI）。这个BMI是文件系统中描述模块foo导出接口的文件。我就叫它foo。bmi，文件扩展名在这里无所谓。
　　4。foo。bmi是编译foo。cpp的副产品。编译foo。cpp时，编译器将生成foo。o和foo。bmi。因此，必须在bar。cpp之前编译foo。cpp！
　　趁着警铃还没有拉响，我们来讨论一下我们目前使用头文件的工作方式：
　　1。我们有一个模块foo，由foo。cpp和foo。hpp定义；和另一个模块bar，由bar。cpp和bar。hpp定义。
　　2。bar。cpp中有includelt；foo。hppgt；。
　　3。在编译bar。cpp时，如何确保includelt；foo。hppgt；被解析？这很简单：确保foo。hpp存在于header搜索路径列表的目录中。我们不需要做任何额外的预处理。
　　4。对模块foo和bar的编译没有次序要求，可以并行处理。
　　并行化可能是提高build性能最重要的方面。优化build时，你无需再考虑并行化，因为它已经存在了。
　　模块改变了这一点。模块的导入导致了一个编译时间的依赖项，这在include语句中并没有体现。（关于模块编译的次序问题，可参考：https：vectorofbool。github。io20181220buildlikeninja1。html）。
　　ReneRivera最近在《Aremodulesfast？》（https：bfgroup。github。iocpptoolingstatsmodulesmodulesperfD1441R1。html）一文中探讨了这种设计的后果。
　　剧透一下Rene文章的结论：答案是否定的，或者更准确一点来讲，这很微妙，但大多数情况下答案仍然是不。这篇文章中使用的当前模块实现是非常原始的，但仍然在了解哪些模块看上去对性能有帮助这方面有一定的参考价值。可以期待，随着硬件并行性的提升，header的引导模块变得越来越重要，而且与DAG深度（即互相导入的模块链的长度）也有关系。随着DAG深度的增加，模块会越来越慢，而header则保持相当稳定，即使是对于接近300的极端深度。
　　一个徒劳的扫描任务
　　假设我有下面的源文件：importgreetings；
　　importstd。iostream；
　　intmain（）｛
　　std：：coutlt；lt；greeting：：english（）lt；lt；n；
　　｝
　　这很简单。因为我们导入了一些模块，所以我们需要先编译greetings和std。iostream，然后才能编译这个文件。
　　那么，让我们来
　　emmm
　　怎么啦？
　　我们只有一个包含两个import的源文件，仅此而已，别无他物。我们不知道greetings是在哪里定义的，我们需要找到这个包含modulegreetings；语句的文件。
　　在银河系另一侧的talk。cpp文件看起来很可能是：module；
　　ifdefFROMBULATE
　　includelt；hello。hgt；
　　endif
　　ifndefABSYNTH
　　exportmodulesomething。pie；
　　endif
　　importstd。string；
　　exportnamespacegreeting｛
　　std：：stringenglish（）；
　　｝
　　它定义了我们想要的greeting：：english函数。但是我们怎么知道这是正确的文件呢？它并没有modulegreetings；这一行！
　　但它某些时候确实是我们要的。当我们使用DFROMBULATE编译时，文件hello。h会被粘贴到源文件中。让我们看看hello。h里面有什么？ifdefSOMEBUILTINMACRO
　　defineMODULENAMEgreetings
　　elseLegacymodulename
　　defineMODULENAMEsalutations
　　endif
　　exportmoduleMODULENAME；
　　Ohno！
　　好吧好吧别担心。我们需要做的就是运行预处理器来检查文件中是否出现modulesalutations或modulegreetings。
　　这是可以的，但是有4201个文件可以定义可以被导入的模块，其中任何一个都可能有modulegreetings；。
　　另外，我们还不能使用自己的预处理器实现，需要精确地运行编译这段代码的预处理器。看到SOMEBUILTINMACRO了吗？我们不知道那是什么。如果我们没有正确地对它进行编译，编译就会失败。更糟的是，我们甚至可能会错误地编译此文件。
　　那么我们能做什么呢？我们可以在预处理完所有文件后缓存所有模块的名称，对吗？那么，我们在哪里存储这个映射表呢？当我们想用一个不同的编译器编译，生成不同的映射表时会发生什么？如果我们添加需要扫描的新文件怎么办？为了检查任何模块是否添加、删除或重命名了，我们是否需要在每次构建时搜索这些包含了数千个源文件的所有目录？在那些启动进程和或访问文件需要较大开销的系统上，这些成本也将会叠加上去。
　　可能的解决方案
　　这两个问题虽然不同，但却是相关的，我（和许多其他人）认为模块设计的一个改变可以解决这两个问题，那就是模块接口单元的位置必须是确定的。
　　有两种备选方案可以实施：
　　1。强制从模块名称派生MIU文件名。这模拟了头文件名的设计，它与如何从include指令中找到头文件名直接相关。
　　2。提供一个manifest或mapping文件，描述基于模块名的MIU文件路径。此文件需要用户提供，否则我们将同样遇到上文描述的扫描问题。
　　有了确定且易于定义的MIUlookup（查询），我们就可以进入下一个必要步骤：必须延迟生成模块的BMI。
　　TU之间的编译顺序将扼杀moduleadoption的进程。即使是相对较浅的DAG深度也比与头文件相同的深度慢得多。唯一的答案是TU编译必须是可并行的，即使是导入其他TU时。
　　在这方面，C最好模仿Python的导入实现：当遇到新的导入语句时，Python将首先找到对应于该模块的源文件，然后以确定性的方式查找预编译的版本。如果预编译版本已经存在并且是最新的，就使用它；如果不存在预编译版本，则将编译源文件，并将生成的字节码写入磁盘。然后加载此字节码。如果两个解释器实例同时遇到同一个未编译的源文件，它们将竞争写字节码。不过，竞争并不重要，它们都会得出相同的结论，并将相同的文件写入磁盘。
　　为了方便DAG中TU的并行编译，C模块必须以相同的方式实现。提前编译BMI是不可能的。相反，当编译器第一次遇到有关模块的import语句时，应该延时生成BMI。Build系统根本不应该与BMI有关。
　　只有当一个MIU的位置对于编译器是确定的时候，以上这些才能实现。
　　前景渺茫
　　前段时间，Twitter上发生的事让人心烦意乱。Kona会议前的邮件列表在1月25日开放了。在发布的许多文章中，有一篇《关注模块的工具能力（Concernsaboutmoduletoolability）》（http：www。openstd。orgjtc1sc22wg21docspapers2019p1427r0。pdf），其作者和贡献者名单中很多是来自业界的系统和工具构建工程师。我想呼吁权威人士的关注，但我觉得这份名单中的人才是最有资格提供moduletoolability反馈的人。
　　这篇文章的诞生源于许多工具作者和合作者（并不局限于论文中所提及的，包括我自己）的关注，因为大家都深深感到自己长久以来对于模块的关注都被忽视了。
　　SG15之外的人一直热衷于反驳关于moduletoolability问题的讨论，他们声称SG15缺乏必要的实现经验，无法对模块这个话题提出有用的建议。
　　SG15只搞过面对面的会议，上次在圣地亚哥的会议也没起到什么作用，因为主席不在，而且大家急急忙忙参会，没时间进行任何有用的讨论。由于在官方的WG21会议之外没有安排SG15会议，因此其成员很难保证更新并协同工作。此外，SG15曾多次尝试重提已经被拒绝的问题，被拒绝的原因是因为他们提出的问题被认为超出了C语言范围。
　　关于Kona会议前邮件列表的推文催生了关于C模块化的讨论：关于moduletoolability，该相信谁？（https：twitter。comhorenmarctustatus1089542882783084549）。
　　这场讨论最终以要求SG15他妈的闭嘴而告终，除非SG15能够提供代码示例来证明它们所提到的问题。但是这个示例代码，无法在当前的任何编译器中实现，也不能在任何当前的构建系统中实现。所以即使这些问题确实存在，这个要求也只能得出一个否定的结论，因为这是一个无法凭经验完成的任务。也就是说，要求SG15提供代码根本是一个无法永远完成的任务。
　　这些问题没有继续讨论下去，也没有被推翻。甚至没有人再提到《关注模块的工具能力》中列出的问题。我们只是被简单地告知要相信一些大人物比我们更了解C模块（这里我要再次呼吁权威人士介入）。
　　支持目前模块设计的人尚未证明模块能适应大规模生产环境，但是他们却要求SG15提供模块不能满足大规模生产的证据。尽管已有的模块部署并没有使用当前的设计，也没有使用真实环境中构建实际系统所需的自动模块扫描。
　　如果模块被合并，结果发现它们不能以良好的性能和灵活的方式实现，那么人们就不会使用模块。如果一个brokenmodule建议被合并到C中，后果可能是不可弥补恢复的，C也将永远得不到模块设计承诺带来的好处。
　　至于针对当前模块设计的改进方案能成功解决这些问题呢？我不能给出确定的答案，但我和许多人都认为CModules有重大问题需要解决。
　　然而，从其他人的做法来看，SG15怎么想似乎并不重要，他们的提议总是被缺乏C工具经验的人否决，他们在整个讨论中没有任何发言权，提出的任何问题都被认定为未经证实和超出范围而不予考虑。
　　我不太敢指责这种行为的后果，我也并不热衷人际冲突。然而，我更担心C这个无用的模块设计最终会害死自己。原文：https：vectorofbool。github。io20190127modulesdoa。html
　　本文为CSDN翻译，如需转载，请注明来源出处。作者独立观点，不代表CSDN立场。