深入探索C++对象模型(六)
执行期语意学(Runtime Semantics)
对象的构造和析构(Object Constructor and Destructor)
一般而言，constructor和destructor的安插都如你所预期：
{
Point point;
//point.Point::Point() 一般而言会被安插在这里
...
//point.Point::~Point() 一般而言会被安插在这里
}
如果一个区段(译注：以{}括起来的区域)或函数中有一个以上的离开点，情况会稍微混乱一些。Destructor必须被放在每一个离开点(当时object还存活)之前。例如：
{
Point point;
//constructor在这里行动
switch(int(point.x())){
case -1 :
//mumble;
//destructor在这里行动
return;
case 0:
//mumble
//destructor在这里行动
return;
default:
//mumble
//destructor在这里行动
return;
}
//destructor在这里行动
}
一般而言我们会把object尽可能放置在使用它的那个程序区段附近，这么做可以节省非必要的对象产生操作和摧毁操作。
全局对象(Global Objects)
如果我们有以下程序片段：
Matrix identity;
main(){
//identity必须在此处被初始化
Matrix m1 = identity;
...
return 0;
}
C++ 保证，一定会在main()函数中第一次用到identity之前，把identity构造出来，而在main()函数结束之前把identity摧毁掉。像identity这样的所谓global object如果有constructor和destructor的话，我们说它需要静态的初始化操作和内存释放操作。
C++程序中所有的global objects都被放置在程序的data segment中。如果显式指定给它一个值，此object将以该值为初值。否则object配置到的内存内容为0。如下：
int v1 = 1024;
int v2;
v1和v2都被配置于程序的data segment，v1值为1024，v2值为0(这和C略有不同，C并不设定初值)。在C语言中一个global object只能够被一个常量表达式(可在编译期求其值的那种)设定初值。当然，constructor并不是常量表达式。虽然class object在编译时期可以被放置于data segment中并且内容为0，但constructor一直要到程序启动(startup)时才会实施。必须对一个“放置于program data segment中的object的初始化表达式”做评估(evaluate)，这正是为什么一个object需要静态初始化的原因。
当cfront还是唯一的C++编译器，而且跨平台移植性比效率的考虑更重要的时候，有一个可移植但成本颇高的静态初始化(以及内存释放)方法，我把它成为munch。其策略如下：
- 为每一个需要静态初始化的档案产生一个_ sti()函数，内带必要的constructor调用操作或inline expansions。例如前面所说的identity对象会在matrix.c中产生出下面的_sti()函数(sti就是static initialization的缩写)：
_sti_matrix_c_identity(){ identity.Matrix::Matrix(); initialization; } - 类似情况，在每一个需要静态的内存释放操作(static deallocation)的文件，产生一个_std()函数(static deallocation)，内带必要的destructor操作，或是其inline expansions。在我们的例子中会有一个_ std()函数被产生出来，针对identity对象调用Matrix destructor。
- 提供一组runtime library "munch"函数：一个_main()函数(用以调用可执行文件中的所有 _sti()函数)，以及一个exit(函数)(以类似方法调用所有的 _std()函数)。
以一个derived class的pointer或reference来存取virtual base class subobject，是一种nonconstant expression，必须在执行期才能加以评估求值。例如，尽管下列程序片段在编译时期可知：
//constant expression
Vertex3d *pv = new PVertex;
Point3d *p3d = pv;
其virtual base class Point的subobject在每一个derived class中的位置却可能会变动，因此不能够在编译时期设定下来，下面的初始化操作：
//Point是Point3d的一个virtual base class
//pt的初始化操作需要某种形式的执行期评估(runtime evaluation)
Point *pt = p3d;
需要编译器提供内部扩充，以支持class object的静态初始化(至少涵盖class objects的指针和references)，例如：
//Initial support of virtual base class conversion requires
//non-constant initialization support
Point *pt = p3d->vbcPoint;
使用被静态初始化的objects有一些缺点，例如，如果exception handling被支持，那些objects将不能够被放置于try区段之内。这对于被静态调用的constructors可能是特别无法接受的，因为任何的throw操作将必然触发exception handling library默认的terminate()函数。另一个缺点是为了控制"需要跨越模块做静态初始化"objects的相依顺序而扯出来的复杂度。
局部静态对象(Local Static Objects)
假设有如下程序片段：
const Matrix& identity(){
static Matrix mat_identity;
//...
return mat_identity;
}
Local static class objects保证了什么样的语意？
- mat_identity的constructor必须只能施行一次，虽然上述函数可能会被调用多次。
- mat_identity的destructor必须只能施行一次，虽然上述函数可能会被调用多次。
编译器的策略之一就是，无条件地在程序起始(startup)时构造出对象来。然而这会导致所有的local static class objects都在程序起始时被初始化，即使它们所在的那个函数从不曾被调用过。因此，只在identity()函数被调用时才把mat_identity构造起来，是比较好的做法(现在的C++ Standard已经强制要求这一点)。那我们应该怎么做呢？
cfront之中的做法是：首先，导入一个临时性对象以保护mat_identity的初始化操作。第一次处理identity时，这个临时性对象被评估为false，于是constructor会被调用，然后临时性对象被改写为true。这样就解决了构造的问题。而在相反的一端，destructor也需要有条件施行于 mat_identity是否被构造起来，很简单，如果那个临时性对象为true，就表示构造好了。困难的是，由于cfront产生C码，mat_identity对函数而言仍然是local，因此我没办法在静态的内存释放函数(static deallocation function)中存取它。解决办法是：取出local object的地址。(当然，由于object是static，其地址再downstream compoent中被转换到程序内用来放置global object的data segment中)。下面是cfront的输出：
//被产生出来的临时对象，作为戒护之用
static struct Matrix *_0_F3 = 0;
//C++的reference在C中是以pointer来代替identity()的名称会被mangled
struct Matrix* identity_Fv(){
static struct Matrix _1mat_identity;
//如果临时性的保护对象已被设立，那就什么也别做，否则
//调用constructor: _ct_6MatrixFv
//设定保护对象，使它指向目标对象
_0_F3
？ 0 ： (_ct_6MatrixFv(& _1mat_identity),
(_0_F3 = (&_lmat_identity)));
...
}
最后，destructor必须在"与text program file(也就是本例中的stat_0.c)有关了的静态内存释放函数(static deallocation function)"中被有条件的调用：
char _std_stat_0_c(){
_0_F3 ? _dt_6MatrixFv(_0_F3, 2) : 0 ;
...
}
请记住，指针的使用时cfront所特有的；然而条件式解构则是所有编译器都需要的。
对象数组(Array of Objects)
假设有以下的数组定义：
Point knots[10];
需要完成什么东西呢？ 如果Point既没有定义一个constructor也没有定义一个destructor，那么我们的工作不会比建立一个"内建(build-in)类型所组成的数组"更多，也就是说，我们只需配置足够的内存以存储10个连续的Point元素。
然而Point的确定义了一个default destructor，所以这个destructor必须轮流施行于每一个元素之上。一般而言这是经由一个或多个runtime library函数达成。在cfront中，我们使用一个被命名为vec_new()函数，产生出以class objects构造而成的数组。比较晚近的编译器，包括Borland/Microsoft/Sun，则是提供两个函数，一个用以处理“没有virtual base class”的class，另一个用来处理“内带virtual base class”的class。后一个函数通常被称为vec_vnew()。函数类型通常如下：
void* vec_new(
void* array, //数组起始地址
size_t elem_size, //每一个class object的大小
int elem_count, //数组中的元素数目
void (*constructor)(void*) ,
void (*destructor)(void*, char)
)
其中的constructor和destructor参数是这个class的default constructor和default destructor的函数指针。参数array带有的若不是具名数组(本例为knots)的地址，就是0。如果是0，那么数组将经由应用程序的new运算符，被动态配置于heap中。
在vec_new()中，constructor施行于elem_count个元素之上。对于支持exception handling的编译器而言，destructor的提供是必要的。下面是编译器可能针对我们的10个Point元素所做的vec_new()调用操作：
Point knots[10];
vec_new(&knots, sizeof(Point), 10, &Point::Point, 0);
如果Point也定义了一个destructor，当knots的生命结束时，该destructor也必须施行于那10个Point元素身上。这也是经由一个类似的vec_delete()(或是vec_vdelete()——如果classes拥有virtual base classes的话)的runtime library函数完成，其函数原型如下：
void *vec_delete(
void *array, //数组起始地址
size_t elem_size, //每一个class object的大小
int elem_count, //数组中的元素数目
void (*destructor)(void*, char)
)
有些编译器会另外增加一些参数，用以传递其它数值，以便能够有条件地导引vec_delete()逻辑，在vec_delete()中，destructor被施行于elem_count个元素身上。
如下例子：
Point knots[10] = {
Point(),
Point(1.0, 1.0, 0.5),
-1.0
};
对于那些明显获得初值的元素，vec_new()不再有必要。对于那些尚未被初始化的元素，vec_new()的施行方式就像面对“由class elements组成的数组，而该数组没有explicit initialization list”一样，因此上一个定义很可能被转换为：
Point knots[10];
//明确初始化前3个元素
Point::Point(&knots[0]);
Point::Point(&knots[1], 1.0, 1.0, 0.5);
Point::Point(&knots[2], -1.0, 0.0, 0.0);
//以vec_new初始化后7个元素
vec_new(&knots + 3, sizeof(Point), 7, &Point::Point, 0);
new和delete运算符
运算符new的使用，看起来似乎是个单一运算，像这样：
int *pi = new int(5);
但事实上它由以下两个步骤完成：
- 通过适当的new运算符函数实体，配置所需的内存：
//调用函数库中的new运算符 int *pi = _new(sizeof(int)); - 给配置得来的对象设立初值：
更进一步地，初始化操作应该在内存配置成功(经由new运算符)后才执行：*pi = 5;//new运算符的两个分离步骤 //given: int *pi = new int(5) //重写声明 int *pi; if(pi = _new(sizeof(int))) *pi = 5; //成功了才初始化
delete运算符的情况类似。当程序员写下：
delete pi;
时，如果pi的值是0，C++ 语言会要求delete运算符不要有操作。因此编译器必须为此调用构造一层保护膜：
if(pi != 0)
_delete(pi);
请注意pi并不会因此被自动清除为0。所以后续的pi的任何操作是没有定义的。这是因为对于pi所指向之内存的变更或再使用，可能发生也可能不发生。
以constructor来配置一个class object，情况类似。例如：
Point3d *origin = new Point3d;
被转换为：
Point3d *origin;
if(origin = _new(sizeof(Point3d)))
origin = Point3d::Point3d(origin);
一般的library对于new运算符的实现操作都很直接了当，但有两个精巧之处值得斟酌。
extern void* operator new(size_t size){
if(size == 0)
size = 1;
void *last_alloc;
while(!(last_alloc = malloc(size))){
if(_new_handler)
(*_new_handler)();
else return 0;
}
return last_alloc;
}
虽然这样写是合法的：
new T[0];
但语言要求每一次对new的调用都必须传回一个独一无二的指针。解决该问题的传统方法是传回一个指针，指向一个默认为1-byte的内存区块(这就是为什么吧size设为1的原因)。这个实现技术的另一个有趣之处是，它允许使用者提供一个属于自己的_new_handler()函数。这正是为什么每一次循环都调用_new_handler()之故。
new运算符实际上总是以标准的C malloc()完成，虽然并没有规定一定得这么做不可。相同情况，delete运算符总是以标准的C free()完成。
extern void operator delete(void *ptr){
if(ptr)
free((char*)ptr);
}
针对数组的new语意
当我们这样写：
int *p_array = new int[5];
时，vec_new()不会真正被调用，因为它的主要功能是把default constructor施行于class objects所组成的数组的每一个元素身上。倒是new运算符会被调用：
int *p_array = (int*)_new(5 * sizeof(int));
相同情况下，如果我们写：
//struct simple_aggr { float f1, f2; }
simple_aggr *p_aggr = new simple_aggr[5];
vec_new()也不会被调用，为什么？因为simple_aggr并没有定义一个constructor或destructor，所以配置数组以及清除p_aggr数组的操作，只是单纯地获得内存和释放内存而已，这些操作由new和delete运算符来完成就绰绰有余了。
然而如果class定义有一个default constructo，某些版本的vec_new()就会被调用，配置并构造class objects所组成的数组。例如这个算式：
Point3d *p_array = new Point3d[10];
通常会被编译为：
Point3d *p_array;
p_array = vec_new(0, sizeof(Point3d), 10,
&Point3d::Point3d, &Point3d::~Point3d);
在个别的数组元素构造过程中，如果发生exception，destructor就会被传递给vec_new()，只有已经构造妥当的元素才需要destructor的施行，因为它们的内存已经被配置出来了，vec_new()有责任在exception发生时把那些内存释放掉。
寻找数组维度，对于delete运算符的效率带来极大的冲击，所以才导致这样的妥协：只有在中括号出现时，编译器才寻找数组的维度，否则它便假设只有单独一个objects要被删除。如果程序员没有提供必须的中括号，像这样：
delete p_array;
那么就只有第一个元素会被解析，其他的元素仍然存在——虽然相关的内存已经被要求归还了。
Placement Operator new的语意
有一个预先定义好的重载的(overloaded) new运算符，称为placement operator new，它需要第二个参数，类型为void*，调用方式如下：
Point2w *ptw = new(arena) Point2w;
其中arena指向内存中的一个区块，用以放置新产生出来的Point2w object。这个预先定义好的placement operator new的实现方法简直是出乎意料的平凡，它只要将“获得的指针”(上例为arena)所指的地址传回即可：
void *operator new(size_t void *p){
return p;
}
当然，以上只是真正所发生的操作的一半而已。另外一半无法由程序员产生出来。想想这些问题：
- 什么是使placement new operator能够有效运行的另一半部扩充(而且是"arena的明确指定操作"所没有提供的)
- 什么是arena的真正类型？该类型暗示了什么？
Placement new operator所扩充的另一半边是将Point2w constructor自动实施于arena所指的地址上：
Point2w *ptw = (Point2w*)arena;
if(pt2 != 0)
ptw->Point2w::Point2w();
这正是使placement operator new威力如此强大的原因。这一份码决定objects被配置在哪里；编译系统保证object的constructor会施行于其上。
另一个问题关系到arena所表现的真正指针类型。C++ Standard说它必须指向相同类型的class，要不就是一块"新鲜"内存，足够容纳该类型的object。注意，derived class很明显并不在被支持之列。对于一个derived class，或是其他没有关联的类型，其行为虽然并非不合法，却也未经定义：
//新鲜的存储空间可以这样配置而来
char *arena = new char[sizeof(Point2w)];
//相同类型的object可以这样获得
Point2w *arena = new Point2w;
不论哪一种情况，新的Point2w的存储空间的确是覆盖了arena的位置，而此行为已在良好控制之下。然而，一般而言，placement new operator并不支持多态(polymorphism)。被交给new的指针，应该适当地指向一块预先配置好的内存。如果derived class比其base class大，例如：
Point2w *p2w = new(arena) Point3w;
Point3w的constructor将会导致严重的破坏。
临时性对象(Temporary Objects)
如果我们有一个函数，形式如下：
T operator+(const T&, const T&);
以及两个T objects，a和b，那么:
a + b;
可能会导致一个临时性对象，以放置传回的对象。是否会导致一个临时性对象，视编译器的进取性(aggressiveness)以及上述操作发生时的程序上下关系而定。例如：
T a, b;
T c = a + b;
编译器会产生一个临时性对象，放置 a+b的结果，然后再使用T的copy constructor，把该临时性对象当作 c 的初值。然而比较更可能的转换是直接以拷贝构造的方式，将 a+b的值放到c中。于是就不需要临时性对象，以及对其constructor和destructor的调用了。
临时性对象的被摧毁，应该是对完整表达式(full-expression)求值过程中的最后一个步骤。该完整表达式造成临时对象的产生。
什么是一个完整表达式(full-expression)？非正式地说，它是被涵括的表达式中最外围的那个。下面这个式子：
//tertiary full expression with 5 sub-expressions
((objA > 1024) && (objB > 1024) ? objA + objB : foo(objA, objB));
一个有五个子算式，内带一个"? : 完整表达式"中。任何一个子表达式所产生的任何一个临时对象，都应该在完整表达式被求值完成后，才可以毁去。
当临时性对象是根据程序的执行期语意有条件地产生出来时，临时性对象的生命规则就显得有些复杂了。举个例子，像这样的表达式：
if (s + t || u + v)
其中u+v 子算式只有在s+t 被评估为false时，才会开始被评估。与第二个子算式有关的临时性对象必须被摧毁。但是，很明显地，不可以无条件地摧毁，也就是说，我们希望只有在临时性对象被产生出来的情况下才去催毁它。
临时性对象的生命规则有两个例外。第一个例外发生在表达式被用来初始化一个object时，例如：
bool verbase;
...
String progNameVersion = !verbase ? 0 : progName + progVersion;
其中progName和progVersion都是String objects。这时候会生出一个临时对象，放置加法运算符的运算结果：
String operator+(const String&, const String&);
临时对象必须根据对verbase的测试结果有条件地解构。在临时对象的生命规则之下，它应该在完整表达的"? : 表达式"结束评估之后尽快地被摧毁。然而，如果progNameVersion的初始化需要调用一个copy constructor：
progNameVersion.String::String(tmp);
那么临时性对象的解构(在"? : 完整表达式"之后)当然就不是我们所期望的。C++ Standard要求说：凡含有表达式执行结果的临时性对象，应该存留到object的初始化操作完成为止。
临时性对象的生命规则的第二个例外是"当一个临时性对象被一个reference绑定"时，例如：
const String &space = " ";
产生出这样的程序代码：
String tmp;
tmp.String::String(" ");
const String &space = tmp;
如果一个临时性对象被绑定于一个reference，对象将残留，直到被初始化之reference的生命结束，或直到临时对象的生命范畴(scope)结束——视哪一种情况先到达而定。
