問題タブ [move-assignment-operator]

gcc コンパイラがローカル変数 (一時的ではない) を右辺値引数として関数に移動するという問題が発生しました。簡単な例があります：

出力：

ムーブ割り当ては右辺値をゼロにするので、私はそれを期待していませんでした。私の場合、b2 が b1=b2; の後に使用されたため、クラッシュが発生しました。

問題は、なぜそれが起こったのかです。

これらの特性をコンテナに持つ理由は何ですか ( https://en.cppreference.com/w/cpp/memory/allocator_traits )

コンテナーの実装は、割り当てとスワップの実装で何らかの形で動作することを理解しています。(そして、これらのケースの処理は恐ろしいコードです。) 私はまた、move-from コンテナーを状態のままにする必要がある場合があること、resizebleまたは少なくとも最後の割り当て解除を呼び出すことができるため、アロケーターができないことも理解しています。無効のままにします。（個人的には、それは弱い議論だと思います。）

しかし、問題は、その情報が、カスタム アロケーター型自体の通常の実装とセマンティクスの一部にならないのはなぜでしょうか?

つまり、コンテナーのコピー代入はソース アロケーターのコピー代入を試みることができます。その構文上のコピー代入が実際にはコピーされない場合、それは、コンテナーがコピーしないと言っているようなものです propagate_on_container_copy_assignment。

同じように、アロケーターを使用する代わりに、is_always_equal実際にアロケーターの割り当てを何も行わないようにすることができます。

(さらに、is_always_equalが true の場合operator==、アロケーターがstd::true_typeそれを通知するように戻すことができます。)

これらの特性は、通常の C++ の手段でカスタム アロケーターに与えることができるセマンティクスをオーバーライドしようとしているように見えます。これは、ジェネリック プログラミングと現在の C++ 哲学に反しているようです。

唯一の理由は、これが「古い」コンテナとのある種の下位互換性を満たすのに役立つと考えられることです。

今日、新しいコンテナーおよび/または新しい重要なアロケーターを作成する場合、アロケーターのセマンティクスに依存して、これらの特性を忘れることができますか?

私の見解では、move-from アロケーターが null ポインター状態を「割り当て解除」できる限り (これは、この特定のケースではほとんど何もしないことを意味します)、それは問題ないはずresizeです。 、それは単にアロケータがそのヒープにアクセスできなくなったことを意味します。

編集:実際 には、コンテナをこのように単純に記述できますか? 複雑さをカスタムアロケーターのセマンティクスに委任しますか?:

アロケーターに対する唯一の真の要件は、移動元のアロケーターがこれを実行できる必要があるということだと思います。

そして、moved-from-allocator がヒープへのアクセスを失ったために、moved-from コンテナーのサイズを変更できない場合 (たとえば、特定のリソースのデフォルト アロクターがないため)、残念なことに、操作はスローされます (任意のサイズ変更として)。投げることができます）。