标签：bar Constructors xx 编译器 constructor 2.3 copy class Semantics

2.3 程序转化语意学

#include "X.h"
X foo() {
    X xx;
    return xx;
}

一个人可能会对代码做出以下假设：

每次 foo（）被调用，就传回 xx的值。
如果 class X定义了一个 copy constructor，那么当 foo（）被调用时，保证该copy constructor也会被调用。

然而

1、由X的定义决定。
2、部分地取决于X的定义，最主要还是取决于c++编译器的优化层级有多高。

在一个高质量的c++编译器中，以上两点假设对于class X的nontrivial definitions都是错误的。

2.3.1 显式的初始化操作（Explicit Initialization）

已知有这样的定义：

X x0;
//下面有三个定义，每一个都明显地以x0来初始化其 class object：
void foo_bar() {
    X x1(x0);
    X x2 = x0;
    X x3 = X(x0);
}

必要的程序转化有两个阶段：

重写每一个定义，其中的初始化操作会被剥除。
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);

2.3.2 参数的初始化（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，并调用 copyconstructor将它初始化，然后将此临时性object交给函数。例如将前一段程序代码转换如下：


// C++伪码
// 编译器产生出来的临时对象
X __temp0;
// 编译器对copy constructor的调用
__temp0.X::X(xx);    
// 重新改写函数调用操作，以便使用上述的临时对象
foo(__temp0);

然而这样的转换只做了一半功夫而已，问题出在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++编译器就是使用此法，但它也提供一个编译选项，用以指定前一种做法，以便和其早期版本兼容。

2.3.3 参数的初始化（Argument Initialization）

已知下面这个函数定义

X bar() {
    X xx;
    // 处理xx...
    return xx;
}

你可能会问bar（）的返回值如何从局部对象xx中拷贝过来？Stroustrup在cfront中的解决做法是一个双阶段转化：

首先加上一个额外参数，类型是 class object的一个 reference。这个参数将用来放置被“拷贝建构（copy constructed）”而得的返回值。
在 return指令之前安插一个 copy constructor调用操作，以便将欲传回之object的内容当做上述新增参数的初值。

真正的返回值是什么？最后一个转化操作会重新改写函数，使它不传回任何值，根据这样的算法，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;

2.2.4 在用户层级做优化（Optimization at the User Level）

Jonathan Shopiro他对于像bar（）这样一个函数，最先提出“程序员优化”的观念：定义一个“计算用”的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 的设计是以效率考虑居多，而不是以"支持抽象化"为优先。

2.3.5 在编译器层面做优化（Optimization at the Compiler Level）

在一个如bar()这样的函数中，所有的 return 指令返回相同的具名数值(named value)，因此编译器可能自己优化，方法是以result参数取代named return value。例如下面的:

bar()定义：

X bar() {
    X xx;
    // ...处理xx
    return xx;
}

编译器把其中的xx用__result取代，直接处理__result：

void bar(X &__result) {
    // default constructor 被调用
    // C++伪代码
    __result.X::X();
    // ...直接处理__result
    return;
}

这样的编译器优化操作，有时被称为Named Return Value(NRV)优化。

但定义了copy constructor 才会激活C++编译器中的NRV优化。

如何理解？

NRV优化和拷贝构造函数是有关系的，只有定义了拷贝构造函数才会开启NRV优化，但现代编译器NRV优化的开启一般都与拷贝构造函数没有关系，早期的 cfront需要一个开关来决定是否应该对代码实行NRV优化，这就是是否有客户（程序员）显式提供的拷贝构造函数：如果客户没有显式地提供拷贝构造函数，那么cfront认为客户对默认的逐位拷贝语义很满意，由于逐位拷贝本身就是很高效的，所有没必要再对其实施NRV优化；但如果客户显式提供了拷贝构造函数，这说明客户由于某些原因(例如需要深拷贝等)摆脱了高效的逐位拷贝语义，其拷贝动作开销将增大，所以将应对其实施NRV 优化，其结果就是去掉并不必要的拷贝函数调用。
————————————————
版权声明：本文为CSDN博主「uestc_chenmo」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/uestc_chenmo/article/details/80342719

虽然NRV优化提供了重要的效率改善，但它还是饱受批评。

其中一个原因是，优化由编译器默默完成，而它是否真的被完成，并不十分清楚（因为很少有编译器会说明其实现程度，或是否实现）
第二个原因是，一旦函数变得比较复杂，优化也就变得比较难以施行。

3.虽然下面三个初始化操作在语意上相等：

X xx0(1024);
X xx1 = X(1024);
X xx2 = (X)1024;

但是在第二行和第三行中，语法明显地提供了两个步骤的初始化操作：

将一个暂时性的object设以初值1024
将暂时性的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();

先后调用构造函数和拷贝构造函数，是对于编译器未进行优化的情况下而言。如今在g++编译器中，默认会进行拷贝优化。若关闭优化，编译时需要添加-fno-elide-constructors选项。

一般而言，面对"以一个 class object作为另一个 class object的初值"的情况，语言允许编译器有大量的自由发挥空间，其好处是导致码产生时有明显的效率提升，缺点是不能够安全地规划copy constructor的副作用，必须视其执行而定。

2.3.6 Copy Constructor：要还是不要？

已知下面的3D坐标点类：

class Point3d {
public:
    Point3d(float x, float y, float z);
private:
    float _x, _y, _z;
};

这个class的设计者应该提供一个explicit copy constructor吗？

上述class的default copy constructor被视为trivial。它既没有任何member（或base）class objects 带有copy constructor，也没任何的virtual base class 或virtual function。所以，默认情况下，一个Point3d class object的“memberwise”初始化操作会导致“bitwise copy”。这样的效率很高，但安全吗？答案是yes。三个坐标成员是以数值来存储的。bitwise copy既不会导致memoryleak，也不会产生address aliasing。因此，它既快速，又安全。

那么，这个class的设计者应该提供一个explicit copy constructor吗？你将如何回答这个问题？答案当然很明显是no。没有任何理由要你提供一个copyconstructor函数实例，因为编译器自动为你实施了最好的行为。比较难以回答的是，如果你被问及是否预见class需要大量的memberwise初始化操作，例如以传值（by value）的方式传回objects？如果确实如此，那么提供一个copyconstructor的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（），都只有在“classes 不含任何由编译器产生的内部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));
};

2.3.7 总结

copy constructor的应用，迫使编译器多多少少对你的程序代码做部分转化。尤其是当一个函数以传值（by value）的方式传回一个class object，而该class有一个copy constructor（不论是显式定义出来的，或是合成的）时。这将导致深奥的程序转化——不论在函数的定义上还是在使用上。此外，编译器也将 copyconstructor的调用操作优化，以一个额外的第一参数（数值被直接存放于其中）取代 NRV。程序员如果了解那些转换，以及copy constructor 优化后的可能状态，就比较能够控制其程序的执行效率。

标签：bar,Constructors,xx,编译器,constructor,2.3,copy,class,Semantics
From： https://www.cnblogs.com/qiangz/p/15991677.html

The Semantics of Constructors——2.3 程序转化语意学