aba*_*ert 12
根据模块提案,从您引用的论文中,它是添加模块的三个主要目标中的第一个:
1简介
模块是一种打包库并封装其实现的机制.它们与翻译单元和标题文件的传统方法不同,主要在于所有实体都只在一个地方定义(甚至是类,模板等).本文提出了一个模块机制(有点类似于Modula-2),主要有三个目标:
- 显着改善大型项目的建设时间
- 在接口和实现之间实现更好的分离
- 为现有库提供可行的过渡路径虽然这些是驱动目标,但该提案还解决了许多其他长期存在的实际C++问题(初始化排序,运行时性能等).
那么,他们如何实现这些目标呢？从第4.1节开始:
由于标题文件通常包含在许多其他文件中,因此构建周期的增长通常相对于源代码的总量是超线性的.如果问题没有解决,随着模板的使用增加,并且语言中添加了更强大的声明性工具(如概念,合同编程等),可能会变得更糟.
模块通过预编译模块附加机制(其处理时间 - 正确实现时 - 大致与导入的声明数成比例)替换文本包含机制(其处理时间与所包含的代码量大致成比例)来解决此问题.可以保留在私有模块定义更改时无需重新编译客户端转换单元的属性.
换句话说,解析这些模板所花费的时间至少只进行一次而不是N次,这已经是一个巨大的进步.
后面的部分描述了诸如显式实例化之类的改进.直接改进的一件事是自动模板实例化,如5.8节所述.在这里,所有可以保证的是与预编译头文件完全相同的好处:"模块Set和Reset必须实例化Lib :: S,实际上它们都在它们的接口文件中公开了这个实例化." 但该提案随后为ODR问题提供了一些可能的技术解决方案,其中至少有一些也解决了多实例化问题,在当今世界可能无法实现.例如,所提出的查询实例化的类型已经反复尝试过,而且通常认为使用今天的模型很难实现,但模块可能会使其变得可行.没有证据表明今天不可能做到正确,只是体验它很难,并且没有证据证明模块会更容易,只是它可能是合理的可能性.
这符合提案中从未明确说明的一般含义,但是在背景中是这样的:使编译更简单意味着我们可以在此过程中获得新的优化(直接,因为它更容易推断发生了什么,或间接地,因为一旦不是这么大的痛苦,就会有更多的人处理这个问题.
总之,模块可以并且肯定会使模板编译更快,如果没有其他原因,模板定义本身只需要解析一次.如果没有模块,它们可能会带来其他不可能或更难以实现的好处,但这可能无法保证.