按值传递参数时的奇怪行为

Question

偶然发现几篇文章声称如果函数无论如何都要进行复制，则按值传递可以提高性能。

我从未真正想过如何在后台实现按值传递。当你这样做时，堆栈上究竟会发生什么：F v = f(g(h()))？

经过一番思考，我得出结论，我会以这样的方式实现它，即 g() 返回的值是在 f() 期望的位置创建的。因此，基本上，没有复制/移动构造函数调用—— f() 将简单地获取 g() 返回的对象的所有权，并在执行离开 f() 的范围时将其销毁。 g() 也一样——它将取得 h() 返回的对象的所有权并在返回时销毁它。

唉，编译器似乎不同意。下面是测试代码：

#include <cstdio>

using std::printf;

struct H
{
    H() { printf("H ctor\n"); }
    ~H() { printf("H dtor\n"); }
    H(H const&) {}
//    H(H&&) {}
//    H(H const&) = default;
//    H(H&&) = default;
};

H h() { return H(); }

struct G
{
    G() { printf("G ctor\n"); }
    ~G() { printf("G dtor\n"); }
    G(G const&) {}
//    G(G&&) {}
//    G(G const&) = default;
//    G(G&&) = default;
};

G g(H) { return G(); }

struct F
{
    F() { printf("F ctor\n"); }
    ~F() { printf("F dtor\n"); }
};

F f(G) { return F(); }

int main()
{
    F v = f(g(h()));
    return 0;
}

在 MSVC 2015 上，它的输出正是我所期望的：

H ctor
G ctor
H dtor
F ctor
G dtor
F dtor

但是如果你注释掉复制构造函数，它看起来像这样：

H ctor
G ctor
H dtor
F ctor
G dtor
G dtor
H dtor
F dtor

我怀疑删除用户提供的复制构造函数会导致编译器生成移动构造函数，这反过来会导致不必要的“移动”，无论有多大的对象都不会消失（尝试添加 1MB 数组作为成员变量）。 IE。编译器非常喜欢“移动”，以至于它选择它而不是根本不做任何事情。

这似乎是 MSVC 中的一个错误，但我真的希望有人解释（和/或证明）这里发生了什么。这是问题 #1。

现在，如果您尝试 GCC 5.4.0 输出根本没有任何意义：

H ctor
G ctor
F ctor
G dtor
H dtor
F dtor

必须在创建 F 之前销毁 H！ H 是 g() 范围的局部变量！请注意，在这里使用构造函数对 GCC 的影响为零。

与 MSVC 相同——对我来说似乎是一个错误，但有人可以解释/证明这里发生了什么吗？那是问题 #2。

在专业使用 C++ 多年后，我遇到了这样的问题，这真是太愚蠢了……在将近 4 年之后，编译器仍然无法就如何传递值达成一致？

Answer 1

对于按值传递参数，参数是函数的局部变量，它是从函数调用的对应参数初始化的。

按值返回时，有一个值叫做返回值。这是由return 表达式的“参数”初始化的。它的生命周期是直到包含函数调用的完整表达式结束。

还有一个名为copy elision 的优化可以在少数情况下应用。其中两种情况适用于按值返回：

• 如果返回值是由另一个相同类型的对象初始化的，那么两个对象可以使用相同的内存位置，并且跳过复制/移动步骤（有一些条件决定何时允许或不允许）
• 如果调用代码使用返回值初始化相同类型的对象，则返回值和目标对象都可以使用相同的内存位置，并跳过复制/移动步骤。 （这里的“同类型对象”包括函数参数）。

这两种方法可以同时应用。此外，从 C++14 开始，复制省略对于编译器是可选的。

在您的电话f(g(h())) 中，这里是对象列表（没有复制省略）：

1. H 默认由return H(); 构建
2. H，h() 的返回值，是从（步骤 1）复制构造的。
3. ~H（第 1 步）
4. H，g 的参数，是从（步骤 2）复制构造的。
5. G 默认由return G(); 构建
6. G，g() 的返回值，是从（第 5 步）复制构造的。
7. ~G（第 5 步）
8. ~H（第 4 步）（见下文）
9. G，f 的参数，是从（步骤 6）复制构造的。
10. F 默认由return F(); 构建
11. F，f() 的返回值，是从（第 10 步）移动构造的。
12. ~F（第 10 步）
13. ~G（第 9 步）（见下文）
14. F v 是从（第 11 步）移动构造的。
15. ~F、~G、~H（第 2、6、11 步）被破坏 - 我认为这三个不需要排序
16. ~F（第 14 步）

对于复制省略，步骤 1+2+3 可以组合成“h() 的返回值是默认构造的”。同样适用于 5+6+7 和 10+11+12。然而，也可以将 2+4 单独组合成“g 的参数是从 1 复制构造的”，也可以同时应用这两个省略号，给出“g 的参数是默认值” -建造”。

由于复制省略是可选的，因此您可能会看到来自不同编译器的不同结果。这并不意味着存在编译器错误。您会很高兴听到在 C++17 中强制要求某些复制省略场景。

如果您包含移动构造函数的输出文本，您在第二种 MSVC 案例中的输出会更有指导意义。我猜想在第一个 MSVC 案例中，它同时执行了我上面提到的两个省略，而第二个案例省略了“2+4”和“6+9”省略。

下面：gcc 和 clang 延迟函数参数的破坏，直到包含函数调用的完整表达式结束。这就是您的 gcc 输出与 MSVC 不同的原因。

在 C++17 起草过程中，实现定义这些破坏是发生在我的列表中的位置，还是出现在完整表达式的末尾。可以说，早期发布的标准中没有充分说明它。 See here 进一步讨论。

Answer 2

这种行为是由一种称为copy elision 的优化技术引起的。简而言之，您提到的所有输出都是有效的！是的！因为这种技术是（唯一的）允许修改程序的行为。更多信息请访问What are copy elision and return value optimization?

Answer 3

MM 和 Ahmad 的回答都让我朝着正确的方向前进，但他们都不完全正确。所以我选择在下面写一个正确的答案...

• C++ 中的函数调用和返回具有以下语义：
  • 作为函数参数传递的值被复制到函数作用域并且函数被调用
  • 返回值被复制到调用者的作用域，被销毁（当我们到达返回完整表达式的末尾时）并且执行离开函数作用域

当谈到在类似 IA-32 的架构上实现这一点时，很明显不需要这些副本——在堆栈上分配未初始化的空间（用于返回值）并以这种方式定义函数调用约定是微不足道的它知道在哪里构造返回值。

参数传递也是如此——如果我们将右值作为函数参数传递，编译器可以直接创建该右值，以便在（随后调用）函数期望的情况下正确创建该右值。

我想这是 复制省略 被引入标准的主要原因（并且在 C++17 中是强制性的）。

我对复制省略很熟悉，之前读过this page。不幸的是，我错过了两件事：

1. 事实上，这也适用于使用右值 (C++11 12.8.p32) 初始化函数参数：

当一个临时类对象没有绑定到一个引用 （12.2）将被复制/移动到具有相同的类对象 cv-unqualified 类型，复制/移动操作可以省略 将临时对象直接构造到 省略复制/移动

1. 当复制省略开始时，它会以一种非常特殊的方式影响对象的生命周期：

当满足某些条件时，允许省略实现 类对象的复制/移动构造，即使复制/移动 对象的构造函数和/或析构函数有副作用。在 在这种情况下，实施会处理 省略复制/移动操作只是两种不同的引用方式 到同一个对象，并且该对象的销毁发生在 后来这两个对象将被销毁 没有优化。这种复制/移动操作的省略，称为 复制省略，在以下情况下是允许的（可能 合并以消除多个副本）

这解释了 GCC 输出——我们将一些右值传递给一个函数，复制省略开始，我们最终通过两种不同的方式引用一个对象，并且生命周期 = 所有这些中最长的（这是临时的生命周期我们的 F v = ...; 表达式）。因此，基本上，GCC 输出完全符合标准。

现在，这也意味着 MSVC 不符合标准！它成功地应用了两个复制省略，但结果对象的生命周期太短了。

第二个 MSVC 输出符合标准——它应用了 RVO，但决定不对函数参数应用复制省略。我仍然认为这是 MSVC 中的一个错误，即使从标准的角度来看代码是可以的。

感谢 M.M 和 Ahmad 将我推向正确的方向。

现在几乎没有关于标准强制执行的生命周期规则的咆哮——我认为它应该仅与 RVO 一起使用。

唉，当应用于省略函数参数的副本时，它没有多大意义。事实上，结合 C++17 强制复制省略规则，它允许像这样的疯狂代码：

T bar();
T* foo(T a) { return &a; }

auto v = foo(bar())->my_method();

此规则强制 T 仅在完整表达式结束时被销毁。此代码将在 C++17 中正确。这是丑陋的，在我看来不应该被允许。此外，您最终会在调用方（而不是在函数内部）销毁这些对象——不必要地增加代码大小并使确定给定函数是否为 nothrow 的过程变得复杂。

换句话说，我个人更喜欢 MSVC 输出 #1（因为最“自然”）。 MSVC 输出#2 和 GCC 输出都应该被禁止。不知道这个想法能不能卖给C++标准化委员会……

edit: 显然在 C++17 中，临时生命周期将变为“未指定”，从而允许 MSVC 的行为。语言中又一个不必要的黑暗角落。他们应该只是强制 MSVC 的行为。