2.3 程序转化语意学 (Program Transformation Semantics)
如下程序片段所示:
#include "X.h" X foo() { X xx; return xx; }
看到这个代码,可能做出以下假设:
1. 每次foo()被调用,就传回xx的值
2. 如果 class X定义了一个copy constructor,那么当foo()被调用时,保证该copy constructor也会被调用。
第一个假设的真实性,必须视 class X如何定义而定,第二个假设的真实性,虽然也有部分必须视 class X如何定义而定,但最主要的还是视C++的编译器所提供的进取性优化程度(degree of aggressive optimization)而定,甚至可以假设在一个高品质的C++编译器中,上述两点对于 class X的nontrivial definitions都不正确。
明确的初始化操作 (Explicit Initialization)
已知有这样的定义:
X x0; //下面有三个定义,每一个都明显地以x0来初始化其 class object: void foo_bar() { X x1(x0); X x2 = x0; X x3 = X(x0); }
必要的程序转化有两个阶段:
1. 重写每一个定义,其中的初始化操作会被剥除。
2. class 的copy constructor调用操作会被插入。
例如,在显式的双阶段转化之后,foo_bar()可能看起来像这样:
// 可能的程序转换 // C++伪码 void foo_bar() { X x1; //定义被重写,初始化操作被剥除 X x2; //定义被重写,初始化操作被剥除 X x3; //定义被重写,初始化操作被剥除 // 编译器插入X copy constructor的调用操作 x1.X::X(x0); x2.X::X(x0); x3.X::X(x0); }
其中的:
x1.X::X(x0);
就表现出对以下的copy constructor的调用:
X::X(const X &xx);
参数的初始化 (Argument Initialization)
C++ Standard说,把一个 class object当做参数传给一个函数(或者是作为一个函数的返回值),相当于以下形式的初始化操作:
X xx = arg;
其中xx代表形式参数(或返回值),而arg代表真正的参数值,因此,若已知这个函数:
void foo(X x0);
下面这样的调用方式:
X xx; foo(xx);
将会要求局部实体(local instance)x0以memberwise的方式将xx当做初值。在编译器实现技术上,有一种策略是导入所谓的暂时性object,并调用copy constructor将它初始化,然后将该暂时性object交给函数。例如将前一段程序代码转换如下:
// C++伪码 // 编译器产生出来的暂时对象 X __temp0; // 编译器对copy constructor的调用 __temp0.X::X(xx); // 重新改写函数调用操作,以便使用上述的暂时对象 foo(__temp0);
注意:在C++中作用域运算符::的优先级最高,__temp0.X::X(xx)相当于__temp0.(X::X(xx))
然而这样的转换只做了一半功夫,问题出在foo()的声明。暂时性object先以 class X的copy constructor正确地设定了初值,然后再以bitwise方式拷贝到x0这个局部实体中。foo()的声明因而也必须被转化,形式参数必须从原先的一个 class X object改变为一个 class X reference,如这样:
void foo(X &x0);
其中 class X声明了一个destructor,它会在foo()函数完成之后被调用,对付那个暂时性的object。
另一种实现方法是以"拷贝建构"(copy construct)的方式把实际参数直接建构在其应该的位置上,该位置视函数活动范围的不同记录与程序堆栈中。在函数返回之前,局部对象(local object)的destructor(如果有定义的话)会被执行,Borland C++编译器就是使用此法,但它也提供一个编译选项,用以指定前一种做法,以便和其早期版本兼容。
返回值的初始化 (Return Value Initialization)
已知下面这个函数定义
X bar() { X xx; // 处理xx... return xx; }
可能会问bar()的返回值如何从局部对象xx中拷贝过来?Stroustrup在cfront中的解决办法是一个双阶段转化:
1. 首先加上一个额外参数,类型是 class object的一个reference。这个参数将用来放置被"拷贝建构(copy constructed)"而得到的返回值
2. 在 return 指令之前插入一个copy constructor调用操作,以便将欲传回的objace的内容当做上述新增参数的初值。
真正的返回值是什么?最后一个转化操作会重新改写函数,使它不传回任何值,根据这样的算法,bar()转换如下:
// 函数转换以反映出copy constructor的应用 // C++伪代码 void bar(X &__result) // 加上一个额外参数 { X xx; // 编译器所产生的default constructor调用操作 xx.X::X(); // ...处理xx // 编译器所产生的copy constructor调用操作 __result.X::XX(xx); return; }
现在编译器必须转换每一个bar()调用操作,以反映其新定义。例如:
X xx = bar();
将被转换为下列两个指令句:
// 注意,不必施行default constructor X xx; bar(xx);
而:
bar().memfunc();
可能被转化为:
// 编译器所产生的暂时现象 X __temp0; (bar(__temp0), __temp0).memfunc();
同样道理,如果程序声明了一个函数指针,例如:
X (*pf)(); pf = bar;
它必须被转化为:
void (*pf)(X &); pf = bar;
在使用者层面做优化 (Optimization at the User Level)
Jonathan Shopiro提出"程序员优化"的观念:定义一个"计算用"的constructor,换句话说程序员不再写:
X bar(const T &y, const T &z) { X xx; // ...以y和z来处理xx return xx; }
那会要求xx被"memberwise"地拷贝到编译器所产生的__result中,Jonathan定义另一个constructor,可以直接计算xx的值:
X bar(const T &y, const T &z) { return X(y, z); }
于是当bar()定义被转换之后,效率会比较高:
// C++伪代码 void bar(X &__result) { __result.X::X(y, z); return; }
__result被直接计算出来,而不是经由copy constructor拷贝得到。不过这种解决方法受到了某种批评,担心那些特殊计算用途的constructor可能会大量扩散。在这个层次上, class 的设计是以效率考虑居多,而不是以"支持抽象化"为优先。
在编译器层面做优化 (Optimization at the Compiler Level)
在一个如bar()这样的函数中,所有的 return 指令返回相同的具名数值(named value),因此编译器可能自己优化,方法是以result参数取代named return value。例如下面的
bar()定义: X bar() { X xx; // ...处理xx return xx; }
编译器把其中的xx以及__result取代:
void bar(X &__result) { // default constructor 被调用 // C++伪代码 __result.X::X(); // ...直接处理__result return; }
这样的编译器优化操作,有时被称为Named Return Value(NRV)优化。NRV优化如今被视为是标准C++编译器的一个义不容辞的优化操作——虽然其需求其实超越了正式标准之外,为了对效率的改善有所感觉,请看下面的例子:
class test { friend test foo(double); public: test() { memset(array, 0, 100 *sizeof(double)); } private: double array[100]; };
同时考虑以下函数,它产生、修改,并传回一个test class object:
test foo(double val) { test local; local.array[0] = val; local.array[99] = val; return local; }
有一个main()函数调用上述foo()函数一千万次:
main() { for (int cnt = 0; cnt < 10000000; cnt++) { test t = foo(double(cnt)); } return 0; } // 整个程序的意义是重复循环1000万次,每次产生一个test object // 每个test object配置一个拥有100个double的数组,所有的元素都设初值为0 // 只有#0和#9元素以循环计数器的值作为初值
这个程序的第一个版本不能实施NRV优化,因为test class 缺少一个copy constructor。第二个版本加上一个online copy constructor如下:
inline test::test(const test &t) { memcpy(this, &t, sizeof(test)); } // 不要忘记在 class test声明中加上一个member function如下 // public: // inline test(const test &t);
这个copy constructor的出现激活了C++编译器的NRV优化,NRV优化的执行并不通过另外独立的优化工具完成。
虽然NRV优化提供了重要的效率改善,它还是饱受批评,其中一个原因是,优化由编译器默默完成,而它是否真的被完成,并不十分清楚。第二个原因是,一旦函数变得比较复杂,优化也就变得比较难以施行。
上述两个批评主要关心的是编译器可能在实施优化时失败。第三个批评则是从相反的方向出发,某些程序员真的不喜欢应用程序被优化。想象已经摆好了copy constructor的阵势,使程序"以copying 方式产生一个object时",对称地调用destructor,例如:
void foo() { // 这里希望有一个copy constructor X xx = bar(); // ... // 这里调用destructor }
在此情况下,对称性被优化给打破:程序虽然比较快,确实错误的。难道编译器因为抑制copy constructor的调用而在这里出错吗?也就是说,难道copy constructor在"object是经由copy而完成其初始化"的情况下,一定要被调用吗?
这样的需求在许多程序中可能会被征以严格的"效率税",例如,虽然下面三个初始化操作在语意上相等:
X xx0(1024); X xx1 = X(1024); X xx2 = (X)1024;
但是在第二行和第三行中,语法明显地提供了两个步骤的初始化操作:
1. 将一个暂时性的object设以初值1024
2. 将暂时性的object以拷贝建构的方式作为explicit object的初值
换句话说,xx()是被单一的constructor操作设定初值:
// C++伪代码 xx0.X::X(1024);
而xx1或xx2却调用两个constructor,产生一个暂时性object,并针对该暂时性objet调用 class X的destructor:
// C++伪代码 X __temp0; __temp0.X::X(1024); xx1.X::X(__temp0); __temp0.X::~X();
一般而言,面对"以一个 class object作为另一个 class object的初值"的情况,语言允许编译器有大量的自由发挥空间,其好处是导致码产生时有明显的效率提升,缺点是不能够安全地规划copy constructor的副作用,必须视其执行而定。
Copy Constructor:要还是不要?
已知下面的3D坐标点类:
class Point3d { public: Point3d(float x, float y, float z); private: float _x, _y, _z; };
上述 class 的 default copy constructor被视为trivial。它既没有任何member(或base) class object带有的copy constructor,也没有任何的 virtual base class 或 virtual function,所以默认情况下,一个Point3d class object的"memberwise"初始化操作会导致"bitwise copy",这样的效率很高,但是安全吗?
答案是yes,三个坐标成员是以数值来储存的,bitwise copy既不会导致memory leak,也不会产生address aliasing,因此它既快速又安全。
那么,这个 class 的设计者应该提供一个 explicit copy constructor吗?答案是no,没有理由提供一个copy constructor函数实体,因为编译器自动实施了最好的行为。比较难以回答的是,是否预见 class 需要大量的memberwise初始化操作,例如以传值(by value)的方式传回objects?如果答案是yes,那么提供一个copy constructor的 explicit inline 函数实体就非常合理——在"编译器提供NRV优化"的前提下。
例如,Point3d支持下面一组函数:
Point3d operator+(const Point3d &, const Point3d &); Point3d operator-(const Point3d &, const Point3d &); Point3d operator*(const Point3d &, int);
所有的那些函数都能够良好地符合NRV template:
{ Point3d result; // 计算result return result; }
实现copy constructor的最简单方法如下所示:
Point3d::Point3d(const Point3d &rhs) { _x = rhs._x; _y = rhs._y; _z = rhs._z; } 这没问题,但使用C++ library的memcpy()会更有效率: Point3d::Point3d(const Point3d &rhs) { memcpy(this, &rhs, sizeof(Point3d)); }
然而不管使用memcpy()和memset(),都只有在"class不含任何由编译器产生的内部members"时才能有效地运行。如果Point3d class 声明一个或一个以上的 virtual functions,或内含一个 virtual base class ,那么使用上述函数将会导致那些"被编译器产生的内部members"的初值被改写。例如,已知下面声明:
class Shape { public: // 这会改变内部的vptr Shape() { memset(this, 0, sizeof(Shape)); } virtual ~Shape(); };
编译器为此constructor扩张的内容看起来像是:
// 扩张后的constructor // C++伪代码 Shape::Shape() { // vptr必须在使用者的代码执行之前先设定妥当 __vptr__Shape = __vtbl__Shape; // memset会将vptr清为0 memset(this, 0, sizeof(Shape)); };
如上所述,如要正确使用memset()和memcpy(),需要掌握某些C++ Object Model的语意学知识。
总结
copy constructor的应用,迫使编译器多多少少对程序代码做部分转化,尤其是当一个函数以传值(by value)的方式传回一个 class object,而该 class 有一个copy constructor(不论是显式定义的,或是合成的)时,这将导致深奥的程序转化——不论在函数的定义或使用上。此外编译器也将copy constructor的调用操作优化,以一个额外的第一参数(数值被直接存放其中)取代NRV。程序员如果了解那些转换,以及copy
constructor优化后的可能状态,就比较能够控制程序的执行效率。
版权声明:本文为博主原创文章,未经博主允许不得转载。