問題タブ [c++23]

P1787には、同じ実体とは何かについての優れた説明があります。

エンティティの 2 つの宣言は、名前のない型の宣言がリンケージ目的で名前を導入することを考慮して、もしあれば ([dcl.typedef]、[dcl.enum])、それらが対応する ([basic.scope.scope]) 場合、同じエンティティを宣言します。 、関数またはテンプレート パラメーターのスコープではない同じターゲット スコープを持ち、かついずれか

1. それらが同じ翻訳単位に表示される、または
2. 両方ともモジュール リンケージで名前を宣言し、同じモジュールにアタッチされている、または
3. どちらも外部リンケージで名前を宣言します。

したがって、次の例を検討してください。

注記を除いて、次のように述べています。

[ 注: 外部またはモジュール リンケージを持つインライン関数または変数は、複数の翻訳単位 ([basic.def.odr]) で定義できますが、1 つのアドレスを持つ 1 つのエンティティです。したがって、そのような関数の本体で定義された型または変数は、単一のエンティティです。

valueただし、宣言された at を考えてみましょう#1。bの TU との TUではc、 のこれら 2 つの宣言valueは対応しており、 の複合ステートメントによって導入される同じターゲット スコープを持っていfunctionます。ただし、ローカル変数にはリンケージがないため、そのリストのどちらの箇条書きも満たされません。valueでは、異なる 2 つの変換単位で (関数の本体にある) for の 2 つの宣言が同じエンティティを宣言したのはなぜでしょうか? P1787のルールを通してそれをどのように解釈するのですか?

2015 年の講演で、 Andrei Alexandrescu は std::allocator インターフェースの残虐行為の概要を説明し、実際には割り当てに関するものではないことを簡単に強調し、これらのアロケーターをより使いやすくモジュール化する別の考え方を提案しています。または、説明から引用するには：

std::allocator には、不名誉な過去、暗い現在、そして元気のない未来があります。STL は、1990 年代の時代遅れのセグメント化されたメモリ モデルの一時的なギャップとしてアロケータを導入しました。それらの設計は限られており、多くの点で割り当てをそれほど支援することさえ目的としていませんでした. アロケータがそこにいたので、コミュニティが勇敢な努力を払ったにもかかわらず、根こそぎにすることも機能させることもできなくなるまで、彼らは単にそこにとどまり続けました。

この講演では、第一原理から作成されたメモリ アロケータの完全な設計について説明します。これは、アプリケーション固有の割り当てパターンをサポートするための汎用的で、コンポーネント化され、構成可能です。

現在の std::allocator に対する彼の主なポイントは、ビデオのこのセクションに含まれていますが、要約すると:

1. アロケータは、割り当てられる型を気にする必要はなく、サイズとアラインメントのみを気にする必要があります。
2. アロケーターは、割り当てに関するサイズ情報を格納する責任を負うべきではありません。割り当てと割り当て解除は、対称的に (それぞれ) Blk(ptr, size) を返したり受け取ったりする必要があります。
3. Rebind<U>::otherひどいです（彼はこれ以上詳しく説明しませんでした）
4. アロケーターはステートレスであってはなりません (アロケーターは文字通りメモリの断片を提供するため、どうしてステートレスになることができるでしょうか?)
5. アロケーターは、コンポジションの概念に基づいて定義する必要があります。実際のアロケーターを見ると、それらはすべて条件付きで実行される小さな小さなアロケーターで構成されています。

その講演を見て以来、アイデアがとても健全で使いやすそうだったので、そこから何らかの提案が得られることを期待していました. 私は過去に std::allocator を使用する必要がありましたが、画面が候補関数で実行できないと叫んだときに、初めて C++20 の概念の必要性を理解することができました。

しかし、そこから何も生まれていないようですか？私はその時はいませんでしたが、STL2 が開発中であったようですが、それは廃止されました。std::allocator の症状を少なくとも仲介するのに概念が十分であることがどこかで決定されましたか (そうであれば、どこで/いつ?)、それとも下位互換性の問題ですか? 将来の C++ バージョンのロードマップでこれに関連するものはありますか?

だから私はメタクラスをとても楽しみにしていました。その後、メタクラスを追加する前に、まず言語でリフレクションと具体化が必要だと彼らは考えているため、 c++23には含まれないだろうと聞きました。

C++23のリフレクションを見ると、具体化機能があるようです。メタクラスが何をするかを解決するのに十分ですか。つまり、メタクラスは単なるシンタックス シュガーですか?

現在の提案を使用して、次のような型を書いている人を複製できますか:

次のような型を生成します。

さらに進むには、似たようなものを取ります

生成できること

live example、どちらも私がメタクラスに興奮した種類の例です。

構文についてはあまり心配していません (ライブラリを記述して poly 値またはインターフェイスを作成できることは便利ですが、正確な構文はそうではありません)。