C++ 隐式生成的赋值运算符是否应为&；裁判合格吗？

以下代码在gcc 4.8.1上编译时没有问题：

#include <utility>

struct foo
{
};

int main()
{
    foo bar;

    foo() = bar;
    foo() = std::move( bar );
}

---

嗯，分配给右值有一些合法的用例。引自

只有少数几个非常特殊的类型是有意义的 支持分配给右值。特别是用作 代理，例如vector:：reference，以及其赋值的类型 运算符符合常量条件（例如，切片数组）

C++标准委员会显然认为默认赋值不应该有隐式REF限定符，而是应该明确声明。事实上，如果突然所有隐式声明的赋值运算符都不能处理右值，那么现有代码可能会停止工作

当然，我们想让一个隐式声明赋值操作符与rValk一起工作的例子有点困难，但是C++标准委员会可能不想在保留向后兼容性时采取这样的机会。代码如下：

int foo_counter = 0;

struct Foo
{
    Foo()
    {
        ++foo_counter;
    }

    ~Foo()
    {
        --foo_counter;
    }
};

int main()
{
    Foo() = Foo();
}

---

…再也不行了。最后，标准委员会希望确保以前有效的C++（不管多么愚蠢或有计划）继续在C++ 11中工作。

< P>，你的问题似乎更多的是“为什么要赋值给一个RUVE？”而不是“为什么标准RF不限定自动生成的构造函数？” 允许向右值赋值的原因是因为在某些情况下它是有用的

一个示例用法是：

#包括
#包括
int main（）
{
std：：集s；
std：：set：：迭代器iter；
布尔插入；
//将insert的返回值解压缩到iter并插入
标准：tie（iter，插入）=s.insert（7）；
}

---

从cppreference.com借用的示例修改了

这并不能真正回答问题，因为OP专门询问隐式声明的赋值运算符，而不是在general@CharlesSalvia嗯，也许你是对的。我匆忙回答，对这个问题有点误解。请记住，在C++11出现之前，存在隐式复制赋值运算符，因此在非静态成员函数出现ref限定符之前，存在隐式复制赋值运算符。这是标准委员会在用新编译器编译前C++代码时的哲学。@ LUC，由于某种原因，直到我发布问题后才出现向后兼容性。我忘了，在考虑标准变更时，典型的成本/效益分析不适用。相关：似乎他们对链接的提案应用了相同的逻辑（re：向后兼容性），因为问题被视为“非缺陷”。因此

std:：string（）=std:：string（）

的所有实例都将保持有效（无论好坏）。

int foo_counter = 0;

struct Foo
{
    Foo()
    {
        ++foo_counter;
    }

    ~Foo()
    {
        --foo_counter;
    }
};

int main()
{
    Foo() = Foo();
}

#include <set>
#include <tuple>

int main()
{
    std::set<int> s;

    std::set<int>::iterator iter;
    bool inserted;

    // unpacks the return value of insert into iter and inserted
    std::tie(iter, inserted) = s.insert(7);
}