问题描述
在我的理解中,以下内容是相同的:
Person p{}; // Case 1
Person p = {}; // Case 1.5
我注意到了
Person p = Person{}; // Case 2
产生与上面的Case 1
和Case 1.5
相同的跟踪输出。
-
问题1:将案例2与案例1或案例1.5进行比较,是因为复制省略还是其他原因?
-
问题2:以下内容之间有什么区别?
Person p{}; // Case 1
Person p = Person{}; // Case 2
Person&& p = Person{}; // Case 3
解决方法
这三个语句在c++11中并不完全相同。
第2种情况要求在C ++ 17之前进行移动构造
该语言要求代码X x = X{}
必须存在一个移动构造函数-否则代码将无法编译。
例如,使用定义如下的Person
类:
class Person{
public:
...
Person(Person&&) = delete;
...
};
将无法在以下语句上编译:
Person p = Person{}; // Case 2
注意:上述代码在c++17及之后的版本中完全有效,因为其措词更改允许即使对象不可移动和不可复制,也可以直接在其目标地址中构造对象(此代码人们通常称为“保证复制省略”。
第3种情况是临时产品的生命周期延长
第三种情况是临时结构的构造,通过绑定到右值引用可以延长其寿命。在将临时变量绑定到右值引用或const
左值引用的某些情况下,它们的寿命可以延长。例如,以下两种构造等效于它们绑定到临时对象的生存期:
Person&& p3_1 = Person{};
const Person& p3_2 = Person{};
就作用域规则而言,它与任何其他自动变量具有相同的生存期(例如,它将以与Person person{}
相同的方式在作用域末尾调用析构函数)。但是,至少在c++11中,构造可以完成的工作与Person p2 = Person{}
完全不同,因为该代码将始终编译,即使移动构造函数不存在(因为这是引用绑定)。
例如,让我们考虑一个不可移动,不可复制的类型,例如std::mutex
。在 C ++ 17 中,编写以下代码是有效的:
std::mutex mutex = std::mutex{};
但是在 C ++ 11 中无法编译。但是,您可以自由编写:
std::mutex&& mutex = std::mutex{};
创建一个临时对象并将其绑定到一个引用,该引用的生存期将与该点上构造的任何作用域变量相同。
compiler explorer上的示例。
注意:有意地传播临时对象的生存期通常不是有意做的,但是在C ++ 17之前,这是使用以下方法实现几乎始终自动的语法的唯一方法不动的物体。例如,上面的代码可能会被重写:auto&& mutex = std::mutex{}
是-关于构造的发生方式以及构造变量的行为;但对于变量的类型为否。
在所有这些情况下,编译器均不使用赋值,即仅具有程序default-construct。您可以使用以下代码进行验证:
#include <iostream>
struct Person {
Person& operator=(Person&) {
std::cout << "Assignment: operator=(Person&)\n"; return *this;
}
Person& operator=(Person&&) {
std::cout << "Move assignment: operator=(Person&&)\n"; return *this;
}
Person(const Person&) { std::cout << "Copy ctor: Person(Person&)\n"; }
Person(Person&&) { std::cout << "Move ctor: Person(Person&&)\n"; }
Person() { std::cout << "Default ctor: Person()\n"; }
};
int main() {
std::cout << "P1:\n";
Person p1{};
std::cout << "Address of P1: " << &p1 << '\n';
std::cout << "P2:\n";
Person p2 = Person{};
std::cout << "Address of P2: " << &p2 << '\n';
std::cout << "P3:\n";
Person&& p3 = Person{};
std::cout << "Address of P3: " << &p3 << '\n';
}
在GodBolt上查看。
第三句话的表现令我有些惊讶;实际上,尽管编译器可能会完全拒绝它。无论如何-请不要声明这样的右值引用。这让读者感到困惑-甚至对我来说,也几乎不是您想做什么。我确定p3
的行为就像是右值引用;但是-事实并非如此,显然:尽管类型为Person&&
,但will在传递给函数时的行为类似于左值引用。