问让复制和直接初始化行为不同背后的动机是什么？

EN

因为它是一个临时值的拷贝，所以它可以，可能会被优化出来

这里的关键字可能是。该标准允许但不要求编译器对副本进行优化。如果一些编译器允许此代码(优化)，但其他编译器拒绝它(非优化)，这将是非常不一致的。

因此，标准规定了一种一致的处理方法--每个人都必须检查复制构造函数是否可访问，无论他们随后是否使用它。

这个想法是所有编译器要么接受代码，要么拒绝它。否则它将是不可移植的。

另一个例子，请考虑

A a;
B b;

A a1 = a;
A a2 = b;

当A的复制构造函数是私有的时，允许a2但禁止a1同样是不一致的。

我们还可以从标准文本中看到，初始化类对象的两种方法是不同的(8.5/16)：

如果初始化是直接初始化，或者如果是复制初始化，其中源类型的cv非限定版本与目标的类相同，或者是目标的类的派生类，则考虑构造函数，则为

。枚举适用的构造函数(13.3.1.3)，并通过重载解析(13.3)选择最佳构造函数。调用如此选定的构造函数来初始化对象，并将初始化器表达式或表达式列表作为其参数。如果没有应用任何构造函数，或者重载解决方案不明确，则初始化的格式不正确。

否则(即，对于剩余的复制-初始化情况)，如13.3.1.4中所述，枚举可以从源类型转换为目标类型或(当使用转换函数时)转换为其派生类的用户定义转换序列，并且通过重载解决(13.3)选择最佳转换序列。如果转换无法完成或不明确，则初始化的格式不正确。使用初始化器表达式作为其参数来调用选定的函数；如果该函数是构造函数，则该调用将初始化目标类型的cv非限定版本的临时函数。临时值是prvalue。然后，根据上面的规则，调用的结果(对于构造函数的情况是临时的)被用来直接初始化作为复制初始化目标的对象。在某些情况下，允许实现通过将中间结果直接构造到被初始化的对象中来消除这种直接初始化中固有的复制；参见12.2，12.8。

不同之处在于，直接初始化直接使用构造类的构造函数。使用复制初始化时，会考虑其他转换函数，这些函数可能会产生一个必须复制的临时函数。

这只是一种猜测，但如果没有Bjarne Stroustrup证实它的真实情况，我恐怕很难更加确定：

它是这样设计的，因为它假设这样的行为将是程序员所期望的，他将期望在使用=符号时完成复制，而不是使用直接初始化器语法。

我认为可能的副本省略只是在后来的标准版本中添加的，但我不确定-这是一些人可能能够通过检查标准历史来确定的事情。

下面是一个例子：

struct X
{
    X(int);
    X(const X&);
};

int foo(X x){/*Do stuff*/ return 1; }
X x(1);
foo(x);

在我测试的编译器中，即使在完全优化的情况下，foo的参数也总是被复制。由此，我们可以得出结论，副本不会/一定不会在所有情况下都被消除。

现在，让我们从语言设计的角度来考虑，想象一下如果你想要制定何时需要和何时不需要副本的规则，你将不得不考虑所有的场景，这将是非常困难的。此外，即使你能够想出规则，它们也会非常复杂，人们几乎不可能理解。但是，同时，如果您强制到处复制，这将是非常低效的。这就是为什么规则是这样的，你让人们理解规则，同时仍然不强迫复制，如果他们可以避免。

现在我不得不承认，这个答案与Suma的答案非常相似。这个想法是，你可以期待当前规则的行为，而其他任何规则都太难让人们遵循了。