为什么在重载决议期间 const 左值引用优先于 const 右值引用

Question

为什么没有歧义？

struct B {};
struct C {};

struct A
{
    A(B const &, C const &) {}
    A(B const &&, C const &&) = delete;
#if 0
    A(B const &, C const &&) = delete;
    A(B const &&, C const &) = delete;
#endif
};

B const b() { return {}; } // const result type may make sense
C const c() { return {}; } // for some user-defined types

int main()
{
    A a0{B{}, C{}}; // I want to prohibit this
    A a1{b(), c()}; // and this cases
    B const bb{};
    C const cc{};
    A a2{b(), cc}; // But surely I also want to prohibit this
    A a3{bb, c()}; // and this cases to compile
}

这里我想将B 和C 实例的左值常量引用存储到A 的实例中。当然，我想确保被引用对象的生命周期超过 A 实例的生命周期。

为了实现这一点，我只需将= delete; 重载为B const && 和C const &&，它们还相应地匹配B && 和C &&。

上述方法非常适合转换构造函数（即一元构造函数）。但事实证明，对于更高的 arities，我必须明确地 = delete; 所有可能的组合组合，其中包含感兴趣参数的 const 右值引用版本（即 #if 1）。

然后我想：“为什么没有歧义？”——因为歧义还应该防止在上述情况下编译错误代码。

所以问题是：“为什么构造函数调用的混合情况没有歧义？”。

Answer 1

tl;dr：它是重新-这样设计的。

在the original move proposal 下，您的代码会模棱两可。根据该提议，左值可以绑定到右值引用，但如果左值引用存在于重载集中，则更喜欢左值引用。

这个过程已经很晚了，随着越来越多的人开始理解该提案，并且仍在考虑 C++11 的概念，the rules were changed so that lvalues could not bind to rvalue references。

我个人认为没有必要进行此更改，但 喜欢此更改的人多于不喜欢它的人，并且移动语义的基本功能可以以任何方式工作。所以这绝对是一个值得做出的妥协，而不是根本没有移动语义。

随着左值不能绑定到右值引用的变化，A(B const &&, C const &&) 不是重载决议集的一部分，如果 either 参数是左值。但是，如果其中一个（或两个）参数都是左值，A(B const &, C const &) 仍保留在重载集中。