2015 年の講演で、 Andrei Alexandrescu は std::allocator インターフェースの残虐行為の概要を説明し、実際には割り当てに関するものではないことを簡単に強調し、これらのアロケーターをより使いやすくモジュール化する別の考え方を提案しています。または、説明から引用するには：
std::allocator には、不名誉な過去、暗い現在、そして元気のない未来があります。STL は、1990 年代の時代遅れのセグメント化されたメモリ モデルの一時的なギャップとしてアロケータを導入しました。それらの設計は限られており、多くの点で割り当てをそれほど支援することさえ目的としていませんでした. アロケータがそこにいたので、コミュニティが勇敢な努力を払ったにもかかわらず、根こそぎにすることも機能させることもできなくなるまで、彼らは単にそこにとどまり続けました。
この講演では、第一原理から作成されたメモリ アロケータの完全な設計について説明します。これは、アプリケーション固有の割り当てパターンをサポートするための汎用的で、コンポーネント化され、構成可能です。
現在の std::allocator に対する彼の主なポイントは、ビデオのこのセクションに含まれていますが、要約すると:
- アロケータは、割り当てられる型を気にする必要はなく、サイズとアラインメントのみを気にする必要があります。
- アロケーターは、割り当てに関するサイズ情報を格納する責任を負うべきではありません。割り当てと割り当て解除は、対称的に (それぞれ)
Blk(ptr, size) を返したり受け取ったりする必要があります。 Rebind<U>::otherひどいです（彼はこれ以上詳しく説明しませんでした）- アロケーターはステートレスであってはなりません (アロケーターは文字通りメモリの断片を提供するため、どうしてステートレスになることができるでしょうか?)
- アロケーターは、コンポジションの概念に基づいて定義する必要があります。実際のアロケーターを見ると、それらはすべて条件付きで実行される小さな小さなアロケーターで構成されています。
その講演を見て以来、アイデアがとても健全で使いやすそうだったので、そこから何らかの提案が得られることを期待していました. 私は過去に std::allocator を使用する必要がありましたが、画面が候補関数で実行できないと叫んだときに、初めて C++20 の概念の必要性を理解することができました。
しかし、そこから何も生まれていないようですか？私はその時はいませんでしたが、STL2 が開発中であったようですが、それは廃止されました。std::allocator の症状を少なくとも仲介するのに概念が十分であることがどこかで決定されましたか (そうであれば、どこで/いつ?)、それとも下位互換性の問題ですか? 将来の C++ バージョンのロードマップでこれに関連するものはありますか?