深入探索C++对象模型一书中拷贝构造函数和NRV关系探讨

最近深入探索C++对象模型一书,对于P67中最后一段话的第一句非常不解

这个程序的第一个版本不能实施 NRV 优化,因为 test class 缺少一个 copy constructor

从这段文字来看如果没有拷贝构造函数就不会有 NRV 优化,这一点让人颇为不解,因为从 P66 页中给出的例子来看,NRV 通过额外的引用型参数优化掉了参数的返回,根本没有拷贝 构造函数的调用,这个代码和作者自己的论述看上去是自相矛盾的。

对于这个问题,我在三更_雨的博文第二章构造函数语义学–关于NRV优化和copy constructor,找到一些相关的答案,调整了文章行文顺序,放在此处做一个记录。

作者的观点

这个解释来自作者李普曼:

早期的cfront需要一个开关来决定是否应该对代码实行NRV优化,这就是是否有客户(程 序员)显式提供的拷贝构造函数:如果客户没有显示提供拷贝构造函数,那么cfront认为 客户对默认的逐位拷贝语义很满意,由于逐位拷贝本身就是很高效的,没必要再对其实施 NRV优化;但如果客户显式提供了拷贝构造函数,这说明客户由于某些原因(例如需要深拷 贝等)摆脱了高效的逐位拷贝语义,其拷贝动作开销将增大,所以将应对其实施NRV 优化 ,其结果就是去掉并不必要的拷贝函数调用。

这说明其实作者之所以这么说是因为cfront编译器的缘故,不过目前这种编译器并不多见 ,所以这个论述本身也就不成立了,读者可以直接忽略这个观点。

译者的观点

作者既然给出了解释,其他的解释原本没有太大的必要,但是这些观点对于书的理解有一定 的帮助,所以也纪录在此。

这本书的译者侯捷先生在他的 FAQ 中对于这个问题有和读者之间的讨论。过程如下:

leetron给侯捷写信说道:

问题: 在67页,最下面两行:这个程式的第一个版本不能实施NRV最佳化,因为test class 缺少 一个copy constructor。但是在66页「在编译器层面做最佳化」那一段中所列的码显示, 当编译器把xx以__result取代,变成__result.X::X(); 即default constructor被唤起 。唤起default constructor 是可以理解的,可是编译器转换后的码并没有使用到 copy constructor呀,为什麽67页最后两行却说缺少一个 copy constructor,就不能实施这个 最佳化了呢?

我对上面这个问题做了些解释,但不知我的猜想是否正确。

我的解释是:如同63页与64页「回返值的初始化」这一段,编译器可能将 63页下面的 X bar()函式定义转换成64页的虚拟码,其中有一行__result.X::X(xx); 这会使用到copy constructor。

转换成64页的码后,65页与66页分述了两种后续可能出现的最佳化动作,其中一种即是66 页的编译器层面做最佳化。如此,虽然66页最佳化后的码看起来并不使用到copy constructor,但是这些码是根据像64页那种样子的码(注一)最佳化而来的,而若没有 copy constructor,根本无法转换成64页那种虚拟码,因为其中有一个呼叫copy constructor的动作。所以,虽然 66页经过编译器最佳化的结果省去了 __result.X::X(xx); 这个copy constructor的呼唤动作(因为根本没有xx了),但若没 有明白提供一个copy constructor,却无法让编译器进行这样的最佳化。

另一方面,我叁考第5章,205页最下面一段话:「一般而言如果你的设计之中,有许多函 式都需要以传值(by value) 传回一个local class object….那麽提供一个copy constructor 就比较合理–甚至即使default memberwise语意已经足够。它的出现会触发 NRV最佳化。然而,就像我在前一个例子中所展现的那样,NRV最佳化后将不再需要唤起 copy constructor,因为运算结果已经被直接计算於「将被传回的object」体内了。」所 以,我提出如上所述那个解释,但不确定是否正确,所以e-mail给您以确认一下。

注一:当然,编译器到底怎麽实作这些转换动作,理论上我们是未知的,不能一概而论。 所以我写「像64页那种样子的码」。

侯捷给出的答复是:

首先,我要说 leetron 把他的意思描述得非常清楚。在我收到的读者来函中,算是上品 — 尤其是描述这麽复杂的思路。

其次,我同意 leetron 说:

转换成64页的码后,65页与66页分述了两种后续可能出现的最佳化动作,其中一种即是 66页的编译器层面做最佳化。

但是我不同意 leetron 这样的看法:

如此,虽然66页最佳化后的码看起来并不使用到copy constructor,但是这些码是根据 像64页那种样子的码(注一)最佳化而来的,

我认为,NRV 最佳化并非是由 p63 的原始码而至 p64 的虚拟码,再至 p66 的最佳化。 我认为是从 p63 的原始码直接至 p66 的最佳化。所以,似乎可以不需要 copy ctor。

但这麽一来我也无法解释为什麽 lippman 在 p67 最下强调「必须要有 copy ctor 才能 实施 NRV 最佳化」。

最后侯捷引用了另外一个读者的论述

黄俊达先生认为:Lippman 在 p67 最后一行所言『这个程式的第一个版本不能实施 NRV 最佳化,因为 test class 缺少一个 copy constructor』,此语错误。黄先生认为如 果程式没有 explicit copy constructor,编译器会自动为我们做出来(如为 trivial,则 直接 bitwise copy;如为 nontrivial,则由编译器为我们合成出一个 copy constructor )。因此,有没有 explicit copy constructor 并不影响 NRV 最佳化的实施。他认为 NRV 最佳化主要是由编译器 option 来决定要不要实施。他并且做了一些实验,判断 VC 和 gcc 都没有做到 NRV 最佳化,而其不做的理由不是因为技术上的困难,是为了避免造成「user defined copy constructor 之副作用失效」– 所谓副作用是指,例如「在 user defined copy constructor 中做一个 cout 输出」之类这种「与 memberwise copy 无关」的动作。