是否有可复制但不可移动的类的用例?

And*_*owl 14 c++ copy-constructor move-semantics deleted-functions c++11

在阅读了@Mehrdad 最近的问题之后,哪些类应该是不可移动的,因此是不可复制的,我开始想知道是否存在可以复制但不能移动的类的用例.从技术上讲,这是可能的:

struct S
{
    S() { }
    S(S const& s) { }
    S(S&&) = delete;
};

S foo()
{
    S s1;
    S s2(s1); // OK (copyable)
    return s1; // ERROR! (non-movable)
}
Run Code Online (Sandbox Code Playgroud)

虽然S有一个复制构造函数,但它显然不会对CopyConstructible概念进行建模,因为这反过来又是MoveConstructible概念的改进,需要存在(未删除的)移动构造函数(参见§17.6.3.1/2,表21) .

是否有类似S上述类型的用例,可复制但不可 CopyConstructible 移动?如果没有,为什么不禁止在同一个类中声明复制构造函数已删除的移动构造函数?

Ste*_*sop 11

假设你有一个移动成本比复制更便宜的类(可能它包含std::array一个POD类型).

在功能上,你"应该"使它成为MoveConstructible,以便S x = std::move(y);表现得像S x = y;,这就是为什么CopyConstructible是MoveConstructible的子概念.通常如果你根本没有声明构造函数,那么"只是工作".

在实践中,我想你可能想暂时禁用移动构造函数,以便通过移动实例来检测程序中是否有任何代码看起来比实际更高效S.对我而言,禁止这样做似乎过分了.在完成的代码中强制执行良好的界面设计不是标准的工作:-)


How*_*ant 8

我目前知道删除的移动构造函数/赋值没有用例.如果不小心完成,它将不必要地防止类型从工厂函数返回或放入std::vector.

但是,删除的移动成员是合法的,以防万一有人可能会找到它们的用途.作为类比,我知道const&&多年没用了.人们问我,我们是否应该禁止它.但是在我们获得足够的功能经验之后,最终会出现一些用例.同样可能还与删除移动成员发生,但据我所知还没有.

  • 只需删除复制成员即可创建不可移动/不可复制的对象。对于此类对象删除的移动成员是多余的。此问答涉及可复制但不可移动的对象。`mutex` 不符合这个条件。 (2认同)