n2439 背后的基本原理是什么:
12.1.4 A constructor shall not be declared with a ref-qualifier.
和
12.4.2 A destructor shall not be declared with a ref-qualifier.
假设某个类 A 具有一些昂贵的引用计数语义，我会写这样的东西，以便能够避免保留/释放临时对象:
struct B {
A a;
B (const& A a) & : a(retain(a)) {}
B (const& A a) && : a(a) {}
~B () & { release(a); }
~B () && { }
void do_something_with_a();
};
A a = getA();
auto b = B(a); // retain+released
b.do_something_with_a();
B(getA()).do_something_with_a(); // no retain / release
最佳答案
像这样的侵入式引用计数是 20 多年的老技术。它存在于 COM 和 objective-c 等神秘的地方。
在他们那个时代，这些技术很有用，帮助我们前进(并退后几步)，但事情已经发生了变化。我们变得更聪明了。
现在我们明白，将关注的生命周期与功能分开是一种更明智的做法。它允许概念解耦，代码更清晰，易于推理。
这就是为什么标准有 std::unique_ptr 和 std::shared_ptr...
...但没有 std::intrusive_base 或 std::intrusive_ptr。
因为这些概念实际上是有害的。
重置我们的内部代码编写指导系统以便我们编写很好的解耦代码后，我们发现我们不需要以这种方式优化构造函数 - 如果我们想要对 A 的引用，我们只需引用 A，如果我们想要一个 shared_ptr 的拷贝给它，我们只需复制 shared_ptr。
代码按照 jar 头上说的做。没有隐藏的魔法。突然间，可以推理具有引用计数对象的代码，我们不必记住是否需要释放对象。
欢迎来到后 C++11 世界。太棒了:-)
关于c++ - n2439 "Extending move semantics to *this"对非静态成员函数的限制背后的基本原理，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34421126/