問題タブ [copy-assignment]

これらの特性をコンテナに持つ理由は何ですか ( 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 コンテナーのサイズを変更できない場合 (たとえば、特定のリソースのデフォルト アロクターがないため)、残念なことに、操作はスローされます (任意のサイズ変更として)。投げることができます）。

次のコード スニペットでは、コピー代入演算子が選択されていないのはなぜですか?

コピーコンストラクターが削除されていることについて不平を言ってコンパイルしません。ユーザー宣言の代入演算子を試してみましたが、それでもうまくいきませんでした。したがって、暗黙の生成ルールが破られているわけではありません (動作を妨げる可能性があり=defaultます)。

これがゴッドボルトの例です: https://godbolt.org/z/MkZuGs

いくつかのコンパイラを試しました。私の推測では、どういうわけか、宣言はコピー コンストラクターを呼び出す必要がありますが、その方法や理由がわかりません。