编译器在某些情况下会对程序进行转化，有些是编译器需要的，有些是出于性能考虑的，转化可能会产生出乎意料的结果

---

明确的初始化操作

已知有这样的定义

X x0;

下面有三个定义，每一个都明显地以 x0 来初始化其类对象

void foo_bar() {
	X x1( x0 );
	X x2 = x0;
	X x3 = X( x0 );
}

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

1. 重写每一个定义，其中的初始化操作会被剥离。
2. 类的拷贝构造函数的会被安插进去

其 C++ 伪码可能像下面这样：

void foo_bar() {
	X x1;
	X x2;
	X x3;

	x1.X::X( x0 );
	x2.X::X( x0 );
	x3.X::X( x0 );
}

---

参数的初始化

C++ 标准说，把一个类对象当做参数传给一个函数（或是作为一个函数的返回值），相当于以下形式的初始化操作：

X xx = arg;

其中 xx 代表形式参数 (或返回值) 而 arg 代表真正的参数值。因此，若已知这个函数：

void foo( X x0 );

下面这样的调用方式：

X xx;
foo( xx );

将会要求局部实体 x0 以逐成员的方式将 xx 当作初值。在编译器实现技术上，有一种策略是导入所谓的暂时性对象(或临时对象)，并调用拷贝构造函数将它初始化，然后将该暂时性对象(或临时对象)交给函数。

例如将前一段程序代码转换如下：

X __temp0;
__temp0.X::X( xx );
foo( __temp0 ):

然而这样的转换是有问题的，因为我们又要调用 foo( X x0 ) 再展开下去，产生无穷无尽的调用，因此这种情况，函数声明也相当于改为 void foo( X& x0 )。

下面的为vs2022下的汇编代码
可以看到在调用 foo 之前先调用了X的拷贝构造函数

在拷贝构造函数中可以看到对于变量的地址

之后将rax的值传给了rcx，可以看到rax中的值就是之前this指针的地址，然后调用 foo

可以看到 x0 的地址为之前 this 指针的地址，说明确实是 void foo( X& x0 )

---

返回值的初始化

已知下面这个函数定义

X bar()
{
	X xx;
	return xx;
}

那么 bar() 的返回值如何从局部对象 xx 中拷贝过来，在 cfront 中的解决方法是一个双阶段转化：

1. 首先加上一个额外参数，类型是类对象的一个引用。这个数将用来放置拷贝构造得到的返回值
2. 在return指令之前安插一个拷贝构造调用操作，以便将想传回的对象的内容当做上述新增参数的初值

真正的返回值是什么？最后一个转化操作会重新改写函数，使它不传回任何值，bar() 转换如下：

void bar( X& __result )
{
	X xx;
	xx.X::X();
	__result.X::XX( xx );
	
	return;
}

现在编译器必须转换每一个 bar() 调用操作，以反映其新定义。例如：

X xx = bar();

将被转换为下列两个指令句：

X xx;
bar( xx );

将被转换为下列两个指令句：

X xx;
bar( xx );

而对于语句：

bar().memfunc();

可能被转化为：

X __temp0;
( bar( __temp0 ), __temp0 ).memfunc();

同样道理，如果程序声明了一个函数指针，像这样：

X ( *pf )();
pf = bar;

它也必须被转化为：

void ( *pf )( X& );
pf = bar;

---

在使用者层面做优化

比如下面的函数

X bar (const T &y, const T &z)
{
	X xx;
	xx.m_x = y + z;
	return xx;
}

如果使用者将这个函数改为

X bar( const T &y, const T &z)
{
	return X( y, z );
}

于是当 bar() 的定义被转换之后，效率会比较高：

void bar( X &__result )
{
	__result.X::X( y, z );
	return;
}

__result 被直接计算出来，而不是经由拷贝构造拷贝而得。

---

在编译器层面做优化

NRV 优化

在一个如 bar() 这样的函数中，所有的 return 指令传回相同的具名数值，比如上面实例中的局部变量 xx，编译器有可能自己做优化，方法是以 result 参数取代 named return value。例如下面的 bar() 定义：

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

编译器把其中的 xx 以 __result 取代：

void bar( X& __result )
{
	__result.X::X();
	// ... 直接处理__result
	return ;
}

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

看下 VS2022中，下面的实例

X bar(const int y, const int z)
{
    X xx;
    xx.m_x = y + z;
    return xx;
}

int main()
{
	X xxx = bar(1, 2);
}

可以看到像实参一样将 xxx 的地址进行了压栈

可以看到，这里的 xx 的值实际就是 xxx 的地址，然后调用了默认构造函数，就是相当于xxx.X::X()

VS2022貌似默认就算未有明确定义的拷贝构造函数，也会进行NRV优化，看下面这个case

#include <iostream>

class test {
	friend test foo(double);
public:
	test()
	{
		memset(array, 0, 100 * sizeof(double));
	}
private:
	double array[100];
};

test foo(double val)
{
	test local;

	local.array[0] = val;
	local.array[99] = val;
	return local;
}

int main()
{
	for (int cnt = 0; cnt < 100000000; cnt++)
	{
		test t = foo(double(cnt));
	}
	return 0;
}

这里可以看到 ebp-334h 就等于 &t


且 foo 函数中的 local 可以看到就是 t 的地址，说明进行了 NRV 优化

NRV优化的弊端

虽然NRV优化提供了重要的效率改善，还是有有一些弊端：

1. 优化由编译器默默完成，而它是否真的被完成，并不十分清楚(因为很少由编译器会说明其实现程度，或是否实现)。
2. 一旦函数变得比较复杂，优化也就变得比较难以施行。在 cfront 中，只有当所有的 named return 指令句发生于函数的 top level 时，优化才施行。如果导入 “a nested local block with a return statement”，cfront 就会静静地将优化关闭
3. NRV 优化可能会带来意想不到的问题

第三点，可以考虑下面这个case，我们在上面的 test 类中，加入一个类静态变量 count，其初始值为 0，加入一个析构函数

	~test()
	{
		count++;
	}

最后输出这个 test::cout，完整代码如下：

#include <iostream>
using namespace std;
class test {
	friend test foo(double);
public:
	static int count;
	test()
	{
		memset(array, 0, 100 * sizeof(double));
	}
	~test()
	{
		count++;
	}
private:
	double array[100];
};

int test::count = 0;

test foo(double val)
{
	test local;

	local.array[0] = val;
	local.array[99] = val;
	return local;
}

int main()
{
	for (int cnt = 0; cnt < 100000000; cnt++)
	{
		test t = foo(double(cnt));
	}
	cout << test::count << endl;
	return 0;
}

正常不被NRV优化，我们期望的应该是 200000000，但实际输出了 100000000