深度探索C++对象模型：6.执行期语意学

第6章：执行期语意学

想象一下我们有下面这个简单的式子：

if(yy ==xx.getValue())...

其中xx和yy定义为：

Xxx;

Yyy;

ClassY定义为：

ClassY{

Public:

Y();

~Y();

Booloperator==(constY&)const;

//...

};

ClassX定义为：

ClassX{

Public:

X();

~X();

OperatorY()const;

XgetValue();

//...

};

首先，让我们决定equality(等号）运算符所参考到的真正实体。在这个例子中，它将被决议（resolves)为“被overloaded的Y成员实体”。下面是该式子的第一次转换：

If(yy.operator==(xx.getValue()))

Y的equality（等号）运算符需要一个类型为Y的参数，然而getValue()传回的却是一个类型为X的object。若非有什么方法可以把一个Xobject转换为一个Yobject，那么这个式子就算错！本例中X提供一个conversion运算符，把一个Xobject转换为一个Yobject。它必须施行于getValue()的返回值身上。下面是该式子的第二次转换：

If(yy.operator==(xx.getValue().operatorY()))

到目前为止所发生的一切都是编译器根据class的隐含语意，对我们的程序代码所做的“增胖”操作。如果我们需要，我们也可以明确地写出那样的式子。不，我们并不建议那么做，不过你如果那么做，会使编译器速度稍微快一些。

虽然程序的语意是正确的，当其教育性却尚不能说是正确的。接下来我们必须产生一个临时对象，用来放置函数调用所传回的值：

n产生一个临时的classXobject,用以放置getValue()的返回值：

Xtemp1=xx.getValue();

n产生一个临时的classYobject，放置operatorY()的返回值：

Ytemp2=temp1.operatorY();

n产生一个临时的intobject，放置equality(等号）运算符的返回值：

Inttemp3=yy.operator==(temp2);

最后，适当的desturctor将被施行于每一个临时性的classobject身上。这导致我们的式子被转换为以下形式：

//以下是条件句if(yy==xx.getValue())...的转换

{

Xtemp1=xx.getValue();

Ytemp2=temp1.operatorY();

Inttemp3=yy.operator==(temp2);

If(temp3)...

Temp2.Y::~Y();

Temp1.X::~X();

}

哦，代码似乎不少！这是C++的一件困难事情：不太容易从程序代码看出表达式的复杂度。

6.1对象的构造和析构

一般而言，constructor和destructor的安插都如你预期：

//C++伪代码

{

Point point;

//point.Point::Point( )一般而言会被安插在这里

...

//point.Point::~Point( )一般而言会被安插在这里

}

如果一个区段（译注：以{}括起来的区域）或函数中有一个以上的离开点，情况会稍微混乱一些。Destructor必须被放在每一个离开点（当时object还存活）之前，例如：

在这个例子中，point的destructor必须在switch指令四个出口的return操作前被生产出来。另外也很可能在这个区段的结束符号（右大括号）之前被生成出来——即使程序分析的结构发现绝不会进行到那里。

一般而言我们会把object尽可能放置在使用它的那个程序区段附近，这样做可以节省不必要的对象产生操作和摧毁操作。

全局对象

如果我们有以下程序片段：

Matrixidentity;

Main()

{

//identity必须在此被初始化

Matrixml=identity;

...

Return0;

}

C++保证，一定会在main( )函数中第一次用到identity之前，把identity构造出来，而在main()函数结束之前把identity摧毁掉。像identity这样的所谓的globalobject如果有constructor和destructor的话，我们说它需要静态的初始化和内存释放操作。

C++程序中所有的globalobjects都被放置在程序的datasegment中。如果明确指定给它一个值，object将以该值为初值。否则object所配置的内存内容为0。因此在下面这段代码中：

Intv1=1024;

Int v2;

V1和v2都被配置于程序的datasegment，v1值为1024，v2值为0（这和C略有不同，C并不自动设定初值）。在C语言中一个globalobject只能够被一个常量表达式（可以在编译时期求其值的那种）设定初值。当然，constructor并不是常量表达式，虽然classobject在编译时期可以被放置于datasegment中并且内容为0，但constructor一直要到程序激活（startup）时才会实施。必须对一个“放置于programdata segment中的object的初始化表达式”做评估，这正是为什么一个object需要静态初始化的原因。

当cfront还是唯一的C++编译器，而且跨平台移植性比效率的考虑更重要的时候，有一个可移植但成本颇高的静态初始化（以及内存释放）方法，我把它称为munch。下面是munch策略的实现：

1、为每一个需要静态初始化的档案产生一个__sti()函数，内带必要的constructor调用操作或inlineexpansions。

2、类似情况，在每一个需要静态的内存释放操作的文件中，产生一个__std()函数。

3、提供一组runtimelibrary "munch"函数：一个_main（ ）函数（用以调用可执行文件中的所有__sti（ ）函数），以及一个exit（ ）函数（以类似方式调用所有的__std( )函数）。

如图所示：

Cfront在你的程序中安插一个_main()函数调用操作，作为main()函数的第一个指令。这里的exit()和Clibrary的exit()不同。为了链接前者，在cfront的CC命令中必须先制定C++standard library。

最后一个需要解决的问题是，如何收集一个程序中的各个objectfiles的__sti()函数和__std()函数。

我们的解决方法是使用nm命令。nm会倾印出object file的符号表格项目。一个可执行文件系由.o文件产生出来，nm将施行于可执行文件身上。其输出被导入（“pipedinto”）munch程序中。Munch程序会“用力咀嚼”符号表格中的名称，搜寻以__sti或__std开头的名称，然后把函数名称加到一个sti()函数和std()函数的跳离表格中。接下来它把这个表格写到一个小的programtext文件中，然后，CC命令被重新激活，将这个内容表格的文件加以编译。然后整个可执行文件被重新链接。_main()和exit()于是在各个表格上走访一遍，轮流调用每一个项目（代表一个函数地址）。

Cfront2.0版之前并不支持nonclassobject的静态初始化操作：也就是说，C语言的限制仍然残留着。所以，像下面这样的例子，每一个初始化都被表示为不合法：

Externint i;

//以下操作都要求静态初始化，在cfront2.0前，这些都不合法

Int j =I;

Int* pi= new int(i);

Doublesal = cpmpute_sal(get_employee(i));

支持“nonclassobjects的静态初始化”，在某种程度上是支持virtualbaseclasses的一个副产品。Virtualbaseclasses怎么会扯进这个主题呢？哦，以一个derivedclass的pointers或reference来存取virtualbaseclasssubobject，是一种nonconstantexpression，必须在执行期才能加以评估求值。例如，尽管下面程序片段在编译器时期可知：

//constantexpression

Vertex3d*pv=newPvertex;

Point3d*p3d=pv;

其virtualbaseclassPoint的subobject在每一个derivedclass中的位置却可能会变动，因此不能够在编译时期设定下来.。下面的初始化操作：

//Point是Point3d的一个virtualbaseclass

//pt的初始化操作需要某种形式的执行器评估

Point*pt=p3d;

需要编译器提供内部扩充，以支持classobject的静态初始化（至少涵盖classobject的指针和references）。例如：

Point*pt=p3d->vbcPoint; //这是在执行期里做的评估

提供必要的支持以涵盖所有的nonclassobjects。

使用被静态初始化的objects有一些缺点。例如，如果exceptionhandling被支持，那些objects将不能够被放置于try区段之内。这对于被静态调用的constructors可能是特别无法接受的。因为任何的throw操作将必然触发exceptionhandlinglibrary默认的terminate（）函数。另一个缺点是为了控制“需要跨越模块做静态初始化”objects的相依顺序而扯出来的复杂度。

局部静态对象（Local Static Objects）

假设我们有以下程序片段：

ConstMatrix&

Identity(){

StaticMatrixmat_identity;

//...

Returnmat_identity;

}

Localstaticclassobject保证了什么样的语意？

1.Mat_identity的constructor必须只能施行一次，虽然上述函数可能会被调用多次。

2.Mat_identity的destructor必须只能施行一次，虽然上述函数可能会被调用多次。

编译器的策略之一就是，无条件地在程序其实（startup）时构造出对象来。然而这会导致所有的localstaticclassobjects都在程序起始时被初始化，即使它们所在的那个函数从不曾被调用过。因此，只在identity()被调用时才把mat_identity构造起来，是比较好的做法（现在的C++Standard已经强制要求这一点）。我们该怎么做呢？

以下就是cfront之中的做法：首先，导入一个临时性对象以保护mat_identity的初始化操作。第一次处理identity时，这个临时对象被评估为false，于是constructor会被调用，然后临时对象被改为true。这样就解决了构造的问题。而在相反的那一端，destructor也需要有条件的施行与mat_identity身上，但只有在mat_identity已经被构造起来时才算数。要判断mat_identity是否被构造，很简单。如果那个临时对象为ture，就表示构造好了。困难的是，由于cfront产生C码，mat_identity对函数而言仍然是local，因此没有办法在静态的内存释放函数（std)中存取它。解决的方法有点诡异：取出localobject的地址。（由于object是static，其地址在downstreamcomponent中将会被转换到程序内用来放置globalobject的datasegment中）下面是cfront的输出：

最后，destructor必须在“与textprogramfile”有关联的静态内存释放函数中被有条件的调用：

请记住，指针的使用是cfront所特有的：然而条件是解构则是所有编译器都需要的。

对象数组

假设我们有下列的数组定义：

Pointknots[10];

需要完成什么东西呢？如果Point既没有定义一个constructor也没有定义一个destructor，那么我们的工作不会比建立一个“内建类型所组成的数组”更多。

然而Point的确定义了一个defaultdestructor，所以这个destructor必须轮流施行与每一个元素之上。一般而言这是经由一个或多个runtimelibrary函数达成。在cfront中，一个被命名为vec_new()的函数，产生出以classobject构造而成的数组。函数类型通常如下：

Void*

Vec_new(

Void*array,//数组起始地址

Size_telem_size,//每一个classobject的大小

Intelem_count,//数组中的元素数目

Void(*constructor)(void*),

Void(*destructor)(void*,char)

}

其中的constructor和destructor参数是这个class的defaultconstructor和defaultdestructor的函数指针。参数array带有的若不是具名数组的地址，就是0。如果是0，那么数组将经由应用程序的new运算符，被配置与堆上。

参数elem_count表示数组中的元素数目。在vec_new()中，constructor施行与elem_count个元素之上。对于支持exceptionhandling的编译器而言，vec_new中destructor的提供是必要的。下面是编译器可能针对我们的10个Point元素所做的vec_nec（）调用操作：

Pointknots[10];

Vec_new(&knots,sizeof(Point),10,&Point::Point,0);

如果Point也定义了一个destructor，当knots的生命结束时，该destructor也必须施行与那10个Point元素身上。

Void*

Vec_delete(

Void*array,

Size_telem_size,

Intelem_count,

Voie(*destructor)(void*,char)

}

如果程序员提供一个或多个明显初值给一个用classobjects组成的数组，像下面这样，会如何：

Pointknots[10]={

Point(),

Point(1.0,1.0,0.5),

-1.0

};

对于那些明显获得初值的元素，vec_new()不再有必要。对于那些尚未被初始化的元素，vec_new()的施行方式就像面对“由classelemetns组成的数组，而该数组没有explicitinitializationlist”一样。因此上一个定义很可能被转换为：

Point knots[10];

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);

DefaultConstructors和数组

如果你想在程序中取出一个constructor的地址，这是不可以的。当然啦，这是编译器在支持vec_new()时该做的事情。然而，经由一个指针来激活constructor，将无法（不被允许）存取defaultargumentvalues。

举个例子，在cfront2.0之前，声明一个由classobjects所组成的数组，意味着这个class必须没有声明constructors或一个defaultconstructor（没有参数那种）。一个constructor不可以去一个或一个以上的默认参数值。这是违反直觉的，会导致以下的大错。下面是在cfront1.0中对于复数库的声明，你能够看出其中的错误吗？

Classcomplex{

Complex(double=0.0,double=0.0);

...

}

在当时的语言规则下，此复数函数库的使用者没办法声明一个由complexclassobjects组成的数组。

再一次地，让我们花点时间考虑，如何支持以下句子：

Complex::complex(double=0.0,double=0.0);

但程序员写出：

Complexc_array[10];

时，而编译器最终需要调用：

Vec_new(&c_array,sizeof(complex),10,

&complex::complex,0);

默认的参数如何能够对vec_new()而言有用？

很明显，有多种可能的实现方法。Cfrotn所采用的方法是产生一个内部的stubconstructor，没有参数。在其函数内部调用由程序员提供的constructor，并将default参数值明确地指定过去（由于constructor的地址已被取得，所以它不能够成为一个inline）：

//内部产生的stubconstructor

//用以支持数组的构造

Complex::complex()

{

Complex(0.0,0.0);

}

编译器自己又一次违反了一个明显的语言规则：class如今支持了两个没带参数的constructors。当然，只有在classobjects数组真正被参生出来时，stub实体才会被产生以及被使用。

6.2 new和delete运算符

运算符new的使用，看起来似乎是个单一运算，像这样：

Int*pi=newint(5);

但事实上它是由以下两个步骤完成：

1、通过适当的new运算符函数实体，配置所需的内存：

//调用函数库中的new运算符

Int*pi=__new(sizeof(int));

2、给配置得来的对象设立初值：

*pi=5;

更进一步地，初始化操作应该在内存配置成功（经由new运算符）后才执行：

Int*pi;

If(pi=__new(sizeof(int)))

*pi=5;

Delete运算符的情况类似，当程序员写下：

Deletepi;

时，如果pi的值是0，C++语言会要求delete运算符不要有操作。因此编译器必须为此调用构造一层保护膜：

If(pi!=0)

__delete(pi);

请注意pi并不会因此被自动清除为0，因此像这样的后继行为：

Pi所指对象之生命会因delete而结束。所以后继任何对pi的参考操作就不再保证有良好的行为，并因此被视为是一种不好的程序风格。然而，把pi继续当做一个指针来用，仍然是可以的，例如：

If(pi==sentinel)...

在这里，使用指针pi和使用pi所指之对象，其差别在于哪一个的生命已经结束了。虽然该地址上的对象不再合法，但地址本身却仍然代表一个合法的程序空间。因此pi能够继续被使用，当只能在受限制的情况下。

以constructor来配置一个classobject，情况类似。例如：

Point3d*origin=newPoint3d;

被转换为:

Point3d*origin;

//C++伪代码

If(origin=__new(sizeof(Point3d)))

Origin=Point3d::Point3d(origin);

如果实现出exceptionhandling，那么转换结果可能会更复杂些：

//C++伪代码

If(origin=__new(sizeof(Point3d)))

{

Try{

Origin=Point3d::Point3d(origin);

}

Cathc(...)

{

//调用deletelibraryfunction以

//释放因new而配置的内存

__delete(origin);

//将原来的exception上传

Throw;

}

}

Destructor的应用极为类似。下面的式子：

Deleteorigin;

会变成：

If(origin!=0)

{

//C++伪代码

Point3d::~Point3d(origin);

__delete(origin);

}

如果在exceptionhandling的情况下，destructor应该被放在一个try区段中。Exceptionhandler会调用delete运算符，然后再一次丢出该exception。

一般的library对于new运算符的实现操作都很直接了当，但有两个精巧之处值得斟酌：

Externvoid*

Operatornew(size_tsize)

{

If(size==0)

Size=1;

Void*last_alloc;

While(!(last_alloc=malloc(size)))

{

If(__new_handler)

(*__new_handler)();

Else

Return0;

}

Returnlast_alloc;

}

虽然这样写是合法的：

NewT[0];

但语言要求每一次对new的调用都必须传回一个独一无二的指针。解决该问题的传统方法是传回一个指针，指向一个默认为1byte的内存区块（这就是为什么程序代码中的size被设为1的原因）。这个实现技术的另一个有趣之处是，它允许使用者提供一个属于自己的__new_handler()函数。这正是为什么每一次循环都调用__new_handler()之故。

New运算符实际上总是以标准的Cmalloc()完成，虽然并没有规定一定得这么做不可。相同的情况，delete运算符也重视以标准的cfree()完成：

Externvoid

Operatordelete(void*ptr)

{

If(ptr)

Free((char*)ptr);

}

针对数组的new语意

当我们这么写：

Int*p_array=newint[5];

时，vec_new()不会真正被调用，因为它的主要功能是把defaultconstructor施行于classobjects所组成的数组的每一个元素身上。倒是new运算符函数会被调用：

Int*p_array=(int*)__new(5*sizeof(int));

相同的情况，如果我们写：

//structsimple_aggr{floatf1,f2;};

Simple_aggr*p_aggr=newsimple_aggr[5];

Vec_new()也不会被调用。为什么呢？因为simple_aggr并没有定义一个constructor或destructor，所以配置数组以及清除p_aggr数组的操作，只是单纯地获得内存和释放内存而已。这些操作由new和delete运算符来完成就绰绰有余了。

然而如果class定义有一个defaultconstructor，某些版本的vec_new()就会被调用，配置并构造classobjects所组成的数组。例如这个算式：

Point3d*p_array=newPoint3d[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时指定数组元素的数目，寻找数组的大小由编译器来完成，因此我们现在可以这样写：

Delete[]p_array;

寻找数组维度给delete运算符的效率带来极大的影响，所以才导致这样的妥协：只有在中括号出现时，编译器才寻找数组的维度，否则它便假设只有单独一个objects要被删除。如果程序员没有提供必须的中括号，像这样：

Deletep_array;

那么就只有第一个元素会被解构。其它的元素仍然存在——虽然其相关的内存已经要求归还。

应该如何记录元素数目？一个明显的方法就是为vec_new()所传回的每一个内存区块配置一个额外的word，然后把元素数目包藏在那个word之中。通常这种被包藏的数值称为所谓的cookie（小甜饼）。

如果我们配置一个数组，内带10个Point3dobjects，我们会预期Point和Point3d的constructor被调用各10次，每次作用于数组中的一个元素：

//完全不是个好主意

Point*ptr=newPoint3d[10];（现代版的编译器VC6.0可以正确的处理）

而当我们delete“由ptr所指向的10个Point3d元素”时，会发生什么事情呢？很明显，我们需要虚拟机制的帮助，以获得预期的Pointdestructor和Point3ddestructor各10次的呼唤（每一次作用于数组中的一个元素）：

//哦欧：这并不是我们所要的

//只有Point：：～Point被调用......

Delete[]ptr;

施行于数组上的destructor，如我们所见，是根据交给vec_delete()函数之“被删除的指针类型的destructor”——本例中正是Pointdestructor。

程序员应该怎样做才好？最好就是避免以一个baseclass指针指向一个derivedclassobjects所组成的数组——如果derivedclassobject比起base大的话。如果你真的一定得这样子写程序，解决之道在于程序员层面，而非语言层面：

For(intix=0;ix<elem_count;++ix)

{

Point3d*p=&((Point3d*)ptr)[ix];

Deletep;

}

基本上，程序员必须迭代走过整个数组，把delete运算符实施于每一个元素身上。以此方式，调用操作将是virtual，因此，Point3d和Point的destructor都会施行于数组中的每一个objects身上。

PlacementOperatornew的语意

有一个预先定义好的重载的(overloaded)new运算符，称为placementoperatornew，它需要第二个参数，类型为void*。调用方式如下：

Point2w*ptw=new(arena)Point2w;

其中arena指向内存中的一个区块，用以放置新产生出来的Point2wobject。这个预先定义好的placementoperatornew的实现方法简直是出乎意料的平凡。它只要将“获得的指针”所指的地址传回即可：

Void*operatornew(size_t,void*p)

{

Returnp;

}

哦，事实上这只是所发生的操作的一半而已。另外一半无法由程序员产生出来

Placementnewoperator所扩充的另一半是将Point2wconstructor自动实施于arena所指的地址上：

Point2w*ptw=(Point2w*)arena;

If(ptw!=0)

Ptw->Point2w::Point2w();

这正是使placementoperatornew威力如此强大的原因。这一份代码决定objects被放置在哪里：编译器系统保证object的constructor会施行于其上。

然而却有一个轻微的不良行为。下面是个有问题的程序片段：

//让arena称为全局性定义

VoidfooBar(){

Point2w*p2w=new(arena)Point2w;

//...doit...

//...nowmanipulateanewobject...

P2w=new(arena)Point2w;

}

如果placementoperator在原已存在的一个object上构造新的object。而该像有的object有一个destructor，这个destructor并不会被调用。调用该destructor的方法之一是将那个指针delete掉。不过本例中你不能像下面这样做：

Deletep2w;

P2w=new(arena)Point2w;

是的，delete运算符会发生作用，这的确是我们所期望的。但是它也会释放由p2w所指的内存，这却不是我们所希望的，因为下一个指令就要用到p2w了。因此，我们应该明确地调用destructor并保留储存空间，以便在使用：

P2w->~Point2w();

P2w=new(arena)Point2w;

剩下的唯一问题是一个设计上的问题：在我们的例子中对placementoperator的第一次调用，会将新object构造与原已存在的object之上？还是会构造与全新地址上？也就是说，如果我们这样写：

Point2w*p2w=new(arena)Point2w;

我们如何知道arena所指向的这块区域是否需要先解构？这个问题在语言层面上并没有解答。一个合理的习俗是另执行new的这一端也要负责执行destructor的责任。

另一个问题关系到arena所表现的真正指针类型。C++Standard说它必须指向相同类型的class，要不就是一块“新鲜”内存，足够容纳该类型的object。注意，derivedclass很明显并不在被支持之列。对于一个derivedclass，或是其它没有关联的类型，其行为虽然并非不合法，却也未经定义。

“新鲜”的存储空间可以这样配置而来：

Char*arena=newchar[sizeof(Point2w)];

相同类型的object则可以这样获得：

Point2w*arena=newPoint2w;

不论哪一种情况，新的Point2w的存储空间的确是覆盖了arena的位置，而此行为已在良好的控制之下。然而，一般而言，placementnewoperator并不支持多态。被交给new的指针，应该适当地指向一块原先配置好的内存。如果derivedclass比其baseclass大，例如：

Point2w*p2w=new(arena)Point3w;

Point3w的constructor将会导致严重的破坏。

Placementnewoperator被引入C++2.0时，最晦涩隐暗的问题就是下面这个由JonathanShopiro提出的问题：

StructBase{intj;virtualvoidf();}

StructDerived:Base{voidf();};

VoidfooBar()

{

Baseb;

B.f();//base::f()被调用

B.~base();

New(&b)Derived;//1

B.f()//哪一个f()被调用

}

由于上述两个classes有相同的大小，故把derivedobject放在baseclass而配置的内存中是安全的。然而，要支持这一点，或许必须放弃对于“经由objects静态调用所有virtualfunctions(比喻b.f())”通常都会有优化处理。结果，placementnewoperator的这种使用方式在StandardC++中未能获得支持。于是上述程序的行为没有明确定义：我们不能过斩钉截铁地说哪一个f()函数实体会被调用。尽管大部分使用者可能以为调用的是Derived::f()，但大部分编译器调用的却是Base::f()。

6.3、临时性对象

如果我们有一个函数，形式如下：

Toperator+(constT&,constT&);

以及两个Tobjects,a和b，那么：

a+b;

可能会导致一个临时性对象，以放置传回的对象。是否导致一个临时性对象，视编译器的进取性以及上述操作发生时的程序上下关系而定。例如下面这个片段：

Ta,b;

Tc=a+b;

编译器会产生一个临时性对象，放置a+b的结果，然后再使用T的copyconstructor，把该临时性对象当作c的初始值。然而更可能的转换时直接以拷贝构造的方式，将a+b的值放到c中，于是就不需要临时性对象，以及对其constructor和destructor的调用了。

此外，视operator+()的定义而定，namereturnvalue(NRV)优化也可能实施起来。这将导致直接在上述c对象中求表达式结果，避免执行copyconstructor和具名对象的destructor。

三种方式所获得的c对象，结果都一样。其间的差异在于初始化的成本。一个编译器可能给我们任何保证吗？严格地说没有。C++Standard允许编译器对于临时性对象的产生有完全的自由度。

理论上，C++Standard允许编译器厂商有完全的自由度。但实际上，由于市场的竞争，几乎保证任何表达式如果有这种形式：

Tc=a+b;//初始化，不会产生一个临时对象

而其中的加法运算符被定义为：

Toperator+(constT&,constT&);

或

TT::operator+(constT&);

那么实现时根本不产生一个临时性对象。

然而请注意，意义相当的assignment叙述句：

c=a+b;//赋值，会产生一个临时对象

不能够忽略临时性对象。相反，它会导致下面的结果：

//C++伪代码

//Ttemp=a+b;

Ttemp;

temp.operator+(a,b);//（1）

//c=temp

C.operator=(temp);//(2)

temp.T::~T();

标示为（1）的那一行，未构造的临时对象被赋值给operator+()。这意思是要不是“表达式的结果被copyconstructed至临时对象中”，就是“以临时对象取得NRV”。在后者中，原本要施行与NRV的constructor，现在将施行与该临时对象。

不管哪一种情况，直接传递c（上例赋值操作的目标对象）到赋值运算符函数中是有问题的,必须在此调用之前先调用destructor。然而，“转换”语意将被用来将下面的assignment操作：

c=a+b;//c.operator=(a+b);

取代为其copyassignment运算符的隐含调用操作，以及一系列的destructor和copyconstruction:

//C++伪代码

c.T::~T();

c.T::T(a+b);

Copyconstructor,destructor以及copyassignmentoperator都可以由使用者供应，所以不能够保证上述两个操作会导致相同的语意。因此，以一连串的destruction和copyconstruction来取代assignment，一般而言是不安全的，而且会产生临时对象，所以这样的初始化操作：

Tc=a+b;

总是比下面的操作更有效率地被编译器转换：

c=a+b;

第三种运算形式是，没有出现目标对象：

a+b;//notarget

这时候有必要产生一个临时对象，以放置运算后的结果。虽然看起来有点怪异，但这种情况实际上在子表达式中十分普遍，例如，如果我们这样写：

Strings("hello"),t("world"),u("!");

那么不论：

Stringv;

v=s+t+u;

或

Printf("%s\n",s+t);

都会导致产生一个临时对象，与s+t相关联。

最后一个表达式带来一些秘教式的论题，那就是“临时对象的生命期”。这个论题颇值得深入探讨。

在C++Standard标准规格上说：临时性对象的被摧毁，应该是对完整表达式求值过程中的最后一个步骤。该完整表达式造成临时性对象的产生。

什么是一个完整表达式？非正式地说，它是被涵括的表达式中最外围的那个。下面这个式子：

（（objA>1024)&&(objB>1024))

?objA+objB:foo(objA,objB);

一共有五个子算式，内带在一个“？：完整表达式”中。任何一个子表达式所产生的任何一个临时对象，都应该在完整表达式被求值完成后，才可以毁去。

当临时性对象是根据程序的执行器语意有条件地被产生出来时，临时性对象的生命规则就显得有些复杂了。举例如下：

If(s+t||u+v)

其中的u+v子算式只有在s+t被评估为false时，才会开始被评估。与第二个子算式有关的临时性对象必须被摧毁。但是，不可以被无条件地摧毁。也就是说，我们希望只有在临时性对象被产生出来的情况下才去摧毁它。

但临时性对象的生命规则有两个例外。第一个例外发生在表达式被用来初始化一个object时，例如：

Boolverbose;

...

StringprogNameVersion=

!Verbose

?0

:progName+progVersion;

其中progName和progVersion都是Stringobjects。这时候会生出一个临时对象，放置加法运算符的运算结果：

Stringoperator+(conststring&,conststring&);

临时对象必须根据对verbose的测试结果有条件地解构。在临时对象的生命规则之下，它应该在完整的“？：表达式”结束之后尽快被摧毁。然而，如果progNameVersion的初始化需要调用一个copyconstructor:

progNameVersion.String::String(temp);

那么临时性对象的解构（在“？：完整表达式”之后）当然就不是我们所期望的。C++Standard要求说：凡含有表达式执行结果的临时性对象，应该存留到object的初始化操作完成为止。

甚至即使每一个都坚守C++Standard中的临时对象生命规则，程序员还是有可能让一个临时对象在他们的控制中被摧毁。其间的主要差异在于这时候的行为有明确的定义。例如，在新的临时对象规则中，下面这个初始化操作保证失败：

Constchar*progNameVersion=

progName+progVersion;

其中progName和progVersion都是Stringobjects。产生出来的代码看起来像这样：

Stringtemp;

Operator+(temp,progName,progVersion);

progNameVersion=temp.String::operatorchar*();

temp.String::~String();

此刻progNameVersion指向未定义的heap内存！

临时性对象的生命规则的第二个例外是“当一个临时性对象被一个reference绑定”时，例如：

ConstString&space="";

产生出这样的代码：

Stringtemp;

temp.String::String("");

Conststring&space=temp;

很明显，如果临时性对象现在被摧毁，那个reference也就差不多没什么用了，。所以规则上说：

如果一个临时性对象被绑定于一个reference，对象将残留，直到被初始化之reference的生命结束，或知道临时对象的生命范畴结束——视哪一种情况先到达而定。