为什么这个 operator= 调用不明确？

Question

我正在使用转发构造函数制作一个瘦派生类。 （请耐心等待，我必须使用 GCC 4.7.2，它缺少继承的构造函数）。

在第一次尝试时，我忘记添加 explicit 关键字并出现错误。有人可以准确解释为什么会发生这个特定错误吗？我无法弄清楚事件的顺序。

#include <memory>

template<typename T>
struct shared_ptr : std::shared_ptr<T>
{
  template<typename...Args>
  /*explicit*/ shared_ptr(Args &&... args)
    : std::shared_ptr<T>(std::forward<Args>(args)...)
  {}
};

struct A {};

struct ConvertsToPtr
{
  shared_ptr<A> ptr = shared_ptr<A>(new A());
  operator shared_ptr<A> const &() const { return ptr; }
};

int main()
{
  shared_ptr<A> ptr;
  ptr = ConvertsToPtr(); // error here
  return 0;
}

错误：

test.cpp: In function ‘int main()’:
test.cpp:28:23: error: ambiguous overload for ‘operator=’ in ‘ptr = ConvertsToPtr()’
test.cpp:28:23: note: candidates are:
test.cpp:9:8: note: shared_ptr<A>& shared_ptr<A>::operator=(const shared_ptr<A>&)
test.cpp:9:8: note: shared_ptr<A>& shared_ptr<A>::operator=(shared_ptr<A>&&)

Answer 1

g++ 4.8.4 也是这种情况，如下所示：
g++ -g -pedantic --std=c++11 -o test main.cpp
VS2015的设置都是默认的。

问题在于编译器试图将ConvertsToPtr() 返回的临时对象转换为shared_ptr 对象。当编译器与explicit 关键字一起使用时，则不会使用构造函数进行此转换。但是，在使用gdb 进行检查时，它似乎正在使用shared_ptr<A> const &() 转换函数来匹配适当的类型。然后，此转换返回一个const shared_ptr &，它在调用赋值运算符时没有歧义（这也与 wojciech Frohmberg 的发现相匹配）。

但是，如果explicit 被省略，则返回shared_ptr 的对象。这可以与赋值运算符的右值版本或 const 左值版本匹配。

根据N4296，Table-11，在用conversion constructor 构造之后，我们有一个rvalue of shared_ptr 对象。然而，重载解析找到了两个匹配项，它们都在Exact Match 之下（右值版本是Identity matching，而另一个在Qualification matching 之下）。

我也检查了VS2015，就像 cmets 中所说的那样，它有效。但是使用一些cout 调试可以看到 const lvalue assignment 右值优先于 rvalue const lvalue refrence 版本对应项。

编辑：我对标准进行了更深入的研究并添加了修改。关于结果VS2015 的已删除文本是错误的，因为我没有定义这两个分配。当两个赋值都被声明时，它确实更喜欢右值。

我假设 VS 编译器将 Identity 与 Qualification 在排名中匹配。但是，正如我得出的结论，是 VS 编译器有问题。 g++ 编译器遵循给定的标准。但是，由于 GCC 5.0 可以作为 Visual Studio 工作，编译器错误的可能性很小，所以我很高兴看到其他专家的见解。

编辑：在 13.3.3.2 中，在我写的更好的排名之后，抽签破坏者之一是：

— S1 和 S2 是引用绑定 (8.5.3)，两者都没有引用 声明的非静态成员函数的隐式对象参数 没有 ref 限定符，并且 S1 将右值引用绑定到右值 S2 绑定一个左值引用。

附有一个示例，显示给定的右值（不是右值引用）应该匹配const int && 而不是const int &。因此我想，可以安全地假设它与我们的案例相关，即使我们有 && 类型而不是 const && 类型。我想毕竟GCC 4.7,4.8 还是有问题的。