C ++ 11で型を移動不可能にするのはいつですか？

これが検索結果に表示されないことに驚いたのですが、C ++ 11での移動のセマンティクスの有用性を考えると、誰かが以前にこれを尋ねたのではないかと思いました。

C ++ 11でクラスを移動不可能にする必要があるのはいつですか（または私にとっては良い考えですか）？

（理由他の既存のコードとの互換性の問題より。）

ハーブの回答（編集前）は、実際には移動可能ではないタイプの良い例を示しています：std::mutex。

OSのネイティブミューテックスタイプ（pthread_mutex_tPOSIXプラットフォームなど）は、「ロケーションインバリアント」ではない可能性があります。これは、オブジェクトのアドレスがその値の一部であることを意味します。たとえば、OSは初期化されたすべてのミューテックスオブジェクトへのポインタのリストを保持する場合があります。場合はstd::mutex含まれて（OSはそのミューテックスへのポインタのリストを維持しているため）データメンバとネイティブ型のアドレスなどのネイティブOSのmutex型は、どちらか固定滞在する必要がありstd::mutex、それはで滞在するので、ヒープ上のネイティブmutex型を格納する必要がありますstd::mutexオブジェクト間で移動したときと同じ場所、またはstd::mutex移動してはいけません。にstd::mutexはconstexprコンストラクタがあり、定数初期化（つまり静的初期化）に適格でなければならないため、ヒープに格納することはできません。std::mutexプログラムの実行が開始する前に構築されることが保証されているため、そのコンストラクタはを使用できませんnew。したがって、残された唯一の選択肢はstd::mutex不動であることです。

同じ理由が、固定アドレスを必要とする何かを含む他のタイプにも当てはまります。リソースのアドレスを固定したままにする必要がある場合は、移動しないでください。

移動std::mutexしていないときにmutexをロックしようとしている人がいないことを知っている必要があるため、安全に移動するのは非常に難しいという別の議論があります。mutexはデータの競合を防ぐために使用できる構成要素の1つであるため、競合自体に対して安全でなかった場合は残念です。不動のstd::mutex場合、いったん構築されて破棄される前に誰でもそれに対して実行できる唯一のことは、ロックとロック解除であり、それらの操作はスレッドセーフであることが明示的に保証されており、データの競合を招くことはありません。これと同じ引数がstd::atomic<T>オブジェクトに適用されます。オブジェクトをアトミックに移動できない場合、オブジェクトを安全に移動することができない場合、別のスレッドが呼び出しを試みている可能性がありますcompare_exchange_strong動かされた瞬間のオブジェクト。したがって、型を移動できない別のケースは、型が安全な並行コードの低レベルのビルディングブロックであり、型に対するすべての操作の原子性を保証する必要がある場合です。オブジェクトの値がいつでも新しいオブジェクトに移動される可能性がある場合は、アトミック変数を使用してすべてのアトミック変数を保護する必要があるため、それを使用しても安全であるか、移動されたかがわかります...そのアトミック変数など...

オブジェクトが純粋なメモリの一部であり、値または値の抽象化のホルダーとして機能するタイプではない場合、それを移動することは意味がないと一般的に言っていると思います。int移動できないなどの基本的なタイプ：移動は単なるコピーです。根性をから引き出すことはできません。intその値をコピーしてゼロに設定することはできますが、それでもint値を持つ、それは単なるメモリのバイトです。しかし、intまだ移動可能ですコピーは有効な移動操作だからです。ただし、コピー不可能なタイプの場合、メモリの一部を移動したくない、または移動できず、その値もコピーできない場合は、移動できません。ミューテックスまたはアトミック変数は、メモリの特定の場所（特別なプロパティで処理される）であるため、移動しても意味がなく、コピーもできないため、移動できません。

短い答え：タイプがコピー可能であれば、それも移動可能でなければなりません。ただし、その逆は当てはまりません。などの一部のタイプstd::unique_ptrは移動可能ですが、それらをコピーしても意味がありません。これらは当然移動のみのタイプです。

少し長い答えが続きます...

主に2種類のタイプがあります（他に、トレイトなどの特別な目的のタイプがあります）。

1. intまたはなどの値のようなタイプvector<widget>。これらは値を表し、当然コピー可能でなければなりません。C ++ 11では、一般的に移動はコピーの最適化と考える必要があるため、すべてのコピー可能な型は当然移動可能である必要があります...元のオブジェクトはもう必要なく、とにかくそれを破壊するだけです。

2. 基本クラスや仮想または保護されたメンバー関数を持つクラスなど、継承階層に存在する参照のような型。これらは通常、ポインタまたは参照によって保持され、多くの場合はbase*またbase&はであるため、スライスを回避するためのコピー構成は提供しません。既存のものと同じように別のオブジェクトを取得したい場合は、通常、のような仮想関数を呼び出しますclone。これらは、2つの理由で移動の構築または割り当てを必要としません。それらはコピー可能ではなく、すでにより効率的な自然な「移動」操作を備えています。オブジェクトにポインターをコピー/移動するだけで、オブジェクト自体は移動しません。まったく新しいメモリ位置に移動する必要があります。

ほとんどのタイプはこれら2つのカテゴリのいずれかに分類されますが、他にも有用なタイプがあり、まれにしかありません。特にここでは、などのリソースの一意の所有権を表すstd::unique_ptr型は、値のようではないため（コピーするのは無意味です）、当然ながら移動のみの型ですが、直接使用します（常にではありません）ポインタまたは参照で）、このタイプのオブジェクトをある場所から別の場所に移動したいとします。

実際に調べてみると、C ++ 11のいくつかの型は移動できないことがわかりました。

• すべてmutexのタイプ（recursive_mutex、timed_mutex、recursive_timed_mutex、
• condition_variable
• type_info
• error_category
• locale::facet
• random_device
• seed_seq
• ios_base
• basic_istream<charT,traits>::sentry
• basic_ostream<charT,traits>::sentry
• すべてのatomicタイプ
• once_flag

どうやらClangに関する議論があります：https : //groups.google.com/forum/? fromgroups=#!topic/comp.std.c++/ pCO1Qqb3Xa4

私が見つけたもう1つの理由-パフォーマンス。値を保持するクラス「a」があるとします。ユーザーが限られた時間（スコープ）の値を変更できるインターフェースを出力したいとします。

これを達成する方法は、次のように、デストラクタに値を設定する「a」から「スコープガード」オブジェクトを返すことです。

class a 
{ 
    int value = 0;

  public:

    struct change_value_guard 
    { 
        friend a;
      private:
        change_value_guard(a& owner, int value) 
            : owner{ owner } 
        { 
            owner.value = value;
        }
        change_value_guard(change_value_guard&&) = delete;
        change_value_guard(const change_value_guard&) = delete;
      public:
        ~change_value_guard()
        {
            owner.value = 0;
        }
      private:
        a& owner;
    };

    change_value_guard changeValue(int newValue)
    { 
        return{ *this, newValue };
    }
};

int main()
{
    a a;
    {
        auto guard = a.changeValue(2);
    }
}

change_value_guardを移動可能にした場合、ガードが移動したかどうかをチェックするデストラクタに「if」を追加する必要があります。これは、追加のifであり、パフォーマンスに影響します。

ええ、確かに、それはおそらく任意の正気なオプティマイザによって最適化することができますが、それでも言語（これはC ++ 17が必要ですが、移動不可能な型を返すことができるために保証されたコピー省略が必要です）は私たちを必要としませんガードを作成関数から戻す以外に移動しない場合は、それを支払う必要があります（dont-pay-for-what-you-dont-useの原則）。