在提议N2073和整体上的c ++模块设计

时间:2012-10-11 19:22:28

标签: c++ module standards

在c ++中总会有一些关于模块的讨论。但昨天(仅在昨天我感到羞耻)我遇到了这个thread链接到c ++模块提案。

这就像“男孩哦男孩!最后会有一些关于实现或设计以及一些有趣的想法......”

那一刻我必须请原谅我的愤怒...

我读了两遍。

作者说,有以下好处:

•显着改善大型项目的建设时间(Olalal我虽然在那里!那将是非常棒的......)

•在界面和实现之间实现更好的分离

•为现有库提供可行的过渡路径

•屏蔽宏观干扰

•来自私人成员的屏蔽

•改进了初始化顺序保证

•避免未确诊的ODR问题

•全局优化属性(例外,副作用,别名泄漏......)

和其他一些人提到了algon文本。

(抱歉再次愤怒的语气)

嗯......说实话,我真的不关心他的导入/导出技巧是什么样的(混淆与否无关紧要), 不关心可见性,隐藏,e.t.c 我不关心像java中存在的静态init块和其他一些东西。

但是MAIN GOAL,模块的核心应该是编译速度,在这里提到:

•显着缩短大型项目的构建时间

所有那些没有编译速度提升的动作都是无用的。它是一种传动。

我按照我的说法读了两遍。

关于实现模块以实现加速的热点,绝对没有用。 我只是“什么?你在开玩笑吗?”

QUOTE: 模块通过替换文本包含机制来解决这个问题 处理时间与预编译模块的代码量成正比 附着机制(其处理时间可以与数量成正比) 进口申报单)。客户端翻译单元无需重新编译的属性 当私有模块定义发生变化时,可以保留。

我们知道目标。但除了“它应该?”之外的其他地方。

我不知道mb的道具目标只是说“他对你的想法有什么看法?”但我会像RFC一样有些想法。 好像我错了。

所以在这种情况下,我只是想向社区提出一些非常基本的问题,因为我不这样做 真正理解如何在不重写大部分语言和所有编译的情况下实现模块 和我们今天拥有的联系机制。真的我不明白:( 这样的巨大努力值得吗?这将是完全不同的语言......“evolved c ++”的原因是什么?

不言而喻,要实现模块,应该有一些数据格式,这些模块是编写的,一些元数据。好。 它可以是纯文本不是吗?它服务于目标,但不是!那样会有另一个import-> import-> ipmport 纯文本链,应该在编译时解析。 所以似乎应该有二进制数据:)好的。它应该只是语言特定的跨平台还是平台特定的?

那么代码中的所有#ifdef块呢?如果会有某种预编译的二进制数据,它将是或依赖于平台的(并且全部包括世界上所有的ifdef分支),或者它将是奇怪的模块,我们每次都应该重新编译。 似乎不可能是真的。这方面怎么样?或者说c ++中的模块我们根本不谈论平台无关的元数据,我们只讨论某种预编译数据,这只会在同一项目的重新编译阶段有用吗? 没有类似java的机器可以在运行时排除某些分支吗?

它究竟如何创造?在主要想法:)

那么图书馆的所有内容呢? .dll,.a,.so? 例如现在我们有 来源+标题(+标题+标题+标题) - > obj - >二进制文件。 该链中c ++模块的位置在哪里? 它应该如何?来源 - > OBJ +模块 - >二进制?或来源 - >模块+模块 - > objs->二进制?

似乎以任何方式实施模块都会影响我们今天使用的所有compilatin流程。

总而言之,我只是对基本概念感兴趣,但点燃了更具建设性的东西,“哦,它应该减少编译时间” - 这不是很严重! 并希望有人可以分享一些关于如何实现的知识或概念(或指出正确的方式)。

提前Tnx!希望我不被禁止:(

1 个答案:

答案 0 :(得分:2)

首先,请注意N2073相当老!我知道的最新模块提案是N3347。当然,这也仅涉及语言层面的结构。关于该主题的所有其他论文(或该问题的任何其他主题)也是如此:语言标准根本没有具体说明语言的实现方式。 C ++标准指定的是语言的语义。实现方式取决于编译器编写者,并且在某种程度上取决于定义软件开发平台的人员:对于给定的平台,可能存在规范不同编译器如何互操作的规范。如果模块包含在语言标准中,则可以定义文件格式等内容。

也就是说,请注意,指定模块在语言级别上的表示方式,可以为编译器提供创建高效表示的必要杠杆(当然,假设它是正确的)。目前,任何奇怪的#define都可以围绕许多声明进行扭曲,并使得给定标头中的声明看起来完全无法预测。当然,任何理智的库都会对用户可以执行的操作施加限制,但所有这些限制都超出了语言规范。在存在稳定定义的时刻,编译器可以基于先前以某种方式创建的模块的合适表示来加载其内部数据结构。编译器供应商在如何制作特定的编译器处理模块方面并不需要任何指导:他们比其他人更了解他们的内部数据结构! ......无论如何,任何固定的配方都不适用于某些编译器供应商。

关于模块内容表示的注释:模块中声明的表示是文本还是二进制并不重要:在这两种情况下,表示的数据都是相同的,并且很容易包含例如,名称解析并避免任何解析怪癖。

模块是未来修订标准的议题之一。我没有看到很多关于模块状态的信息,但它是多个编译器供应商感兴趣的主题。当然,他们都有不同的想法,需要什么以及它应该是什么样子但他们同意合作。