問題タブ [vptr]

この質問は、特に移植性のない MSVC ABI に関するものです。

私は、C++ に相当するものをtypeid、明らかに非移植性でありながら魔法ではない C++ で書こうとしています。Itanium ABI (Linux/Mac で使用) の場合は、非常に簡単です。

だから今、私は 64 ビットの MSVC ABI を見ていて、それをぶつけて、困惑しています。非常に単純なクラス (オフセット 0 の vfptr で始まるクラス) の場合、Itanium とほぼ同じくらい簡単です。

(このコードは、Wine プロジェクトの__RTtypeidに基づいています。)

問題は、一部の C++ クラスがオフセット 0 の vfptr で始まらないことです! vbptr で始まることもあります。

Class1vfptr で始まります。Class2vbptr で始まります。

クラスが vbptr で始まる場合、その最初の仮想ベース サブオブジェクト (レイアウト順で最初の、したがって「最もリーフ」) のオフセット 0 に常に vfptr があると私は信じています。 vbptr で始まるクラスを扱うため、代わりに次のようにします。

MSVCが実際に同等のものを生成すると判断しました

C++ 式をコンパイルするときtypeid(x)— これは、「コンパイラは、静的な型と、コンパイラがすべての型のレイアウトを知っているという事実に基づいて、vbptr があるIS_VBPTR_CLASSかどうかを魔法のように知る」ための擬似コードです。xx

ただし、私の場合、 の静的型がわかりません。わかったとしても、(C++ 内から、テンプレート メタプログラミングを使用して) vbptr で始まるxかどうかを調べる方法がわかりません。x

最後に、私は先に進み、少しごまかしました

"Class1 in Class2" の vftable に格納されている typeinfo がClass1、最も派生した型ではなく、サブオブジェクト type の typeinfo を保持していることを発見するだけClass2です。つまり、パズルのピースがもう 1 つ欠けています。

私の質問を一言で言えば(void*)&object_of_type_class2:typeid(Class2)

抽象クラスでもテーブルを持つことができると読みました。しかし、vtable に含まれるエントリの数について混乱しています。たとえば、私の抽象クラスが次の場合:

その vtable にはいくつのエントリがあるでしょうか? また、この抽象クラスの vtable には 1 つのエントリがあるというのは正しいですか? 助けてくれてありがとう。

先に進む前に、注意:これは純粋に言語弁護士の質問です。標準的な見積もりに基づいて回答を得たいと思っています。C++ コードの書き方についてアドバイスを求めているわけではありません。私がコンパイラの作者であるかのように答えてください。

排他的なサブオブジェクト (#) のみ、特に非仮想ベース (仮想ベース クラスが 1 回だけ名前が付けられたもの) のみを持つオブジェクトの構築中に、ベース クラス サブオブジェクトを参照する左辺値の動的型が「増加」します。ベースの型から実行中のコンストラクターのクラスの型まで。

(#) サブオブジェクトは、それがちょうど 1 つの他のオブジェクト (別のサブオブジェクトまたは完全なオブジェクトである可能性があります) の直接のサブオブジェクトである場合、排他的です。メンバーと非仮想ベースは常に排他的です。

破棄中、型は減少します (そのサブオブジェクトのデストラクタの本体の最後まで、サブオブジェクトがなくなり、動的型がなくなります)。

[共有基底クラス サブオブジェクトを持つオブジェクト (つまり、少なくとも仮想ベースを持つ別個の基本サブオブジェクトを持つクラス内) の構築中に、基本サブオブジェクトの動的型が一時的に「消える」ことがあります。そのようなクラスについてここで議論したくはありません。]

問題は、オブジェクトの動的タイプが別のスレッドで増加するとどうなるかということです。

質問のタイトルは標準 C++ の質問ですが、非標準用語 (vptr)を使用して表現されているため、矛盾しているように見える場合があります。理由は次のとおりです。

• ポリモーフィズムが vptr に関して実装されている必要はありませんが、(ほとんど?) 常に実装されています。オブジェクト内の 1 つ (または複数) の vptr は、ポリモーフィック オブジェクトの動的な型を表します。
• データ競合は、メモリ位置への読み取り/書き込み操作に関して定義されます。
• 標準テキストでは、標準機能を定義するために「解説のみ」で非標準要素を使用することがよくあります。(だから、なぜ vptr を「説明のためだけに」使わないのですか?)

標準では、動的型の関数として、ポリモーフィック オブジェクト (*) の動作を直接定義していません。標準では、いわゆる「ライフタイム」(コンストラクターが完了した後) の間、最も派生した型のコンストラクターの本体内でどの式が許可されるかを指定します (まったく同じ式が同じセマンティックで許可されます)。基本クラスのサブオブジェクト コンストラクター...

(*) ポリモーフィック オブジェクトまたは動的オブジェクトの動的動作 (**) には、次のものが含まれます: 仮想呼び出し、派生からベースへの変換、ダウン キャスト (static_castまたはdynamic_cast)、typeidポリモーフィック オブジェクト。

(**) 動的オブジェクトは、そのクラスが virtual キーワードを使用するオブジェクトです。そのため、そのコンストラクターは自明ではありません。

したがって、説明は次のように述べています。何かが終了した後、何かが開始されるとすぐに、他の何かの前に、など. いくつかの式は有効であり、そのようなことを行います.

構築と破棄の仕様は、スレッドが標準 C++ の一部になる前に書かれました。では、スレッドの標準化によって何が変わったのでしょうか? スレッド動作の定義 (規範部分) [basic.life] /11を含む 1 つの文があります。

この節では、「前」と「後」は「前に起こる」関係 ([intro.multithread]) を指します。

したがって、コンストラクターの呼び出しの完了とオブジェクトの使用の間に発生前の関係があり、オブジェクトのその使用の前に発生し、デストラクタの呼び出しがある場合、オブジェクトは完全に構築されていると見なされることは明らかです。 （それがまったく呼び出された場合）。

ただし、基本クラスのサブオブジェクトが構築された後、派生クラスの構築中に何が起こるかについては述べていません。構築中のポリモーフィック オブジェクトに動的プロパティが使用されている場合、明らかに競合状態がありますが、競合状態は不正ではありません。

[競合状態は非決定論のケースであり、ミューテックス、条件変数、rwlocks、セマフォの多くの使用、他の同期デバイスの多くの使用、およびアトミックプリミティブのすべての使用の意味のある使用は、少なくともアトミック オブジェクトの変更順序のレベル。その低レベルの非決定性が予測不可能な高レベルの動作をもたらすかどうかは、プリミティブの使用方法に依存します。]

次に、標準草案は次のように続けます。

[注: したがって、あるスレッドで構築されているオブジェクトが適切な同期なしで別のスレッドから参照されると、未定義の動作が発生します。— エンドノート]

「適切な同期」はどこで定義されていますか?

「適切な同期」の欠如は、通常のデータ競合と道徳的に同等ですか: vptr でのデータ競合、または標準的に言えば、動的型でのデータ競合ですか?

簡単にするために、少なくとも最初のステップとして、質問の範囲を単一の継承に制限したいと思います。(いずれにせよ、多重継承によるオブジェクトの構築に関して、標準はひどく混乱しています。)

これは言語弁護士の質問なので、私は興味がありません:

• 別のスレッドで構築中のオブジェクトを使用することが推奨されるかどうか (おそらく推奨されません)。
• 同期を使用してその競合状態を確実に修正する方法。
• コンパイラ ベンダーがそのようなユース ケースをサポートするかどうか (おそらくしないし、しない);
• それが実際の実装で確実に機能する可能性があるかどうか（現在の実装では、重要なケースでは確実に機能しない可能性があります）。

編集:前の例は、問題を説明する代わりに、気を散らすものでした。チャットセクションで非常に興味深いが、まったく無関係な議論を引き起こしました.

同じ問題を引き起こさないよりクリーンな例を次に示します。

コンシューマー/プロデューサー ロジックの場合:

• スレッド A:new Der2;
• スレッド B:use_shared();

参考までに、元の例：

コンシューマー/プロデューサーのロジック:

• スレッド A:new Der;
• スレッド B:use_shared();

thisコンストラクターの実行中に別のスレッドで使用できるかどうかは明確ではありませんでしたBase。これは興味深い問題ですが、派生コンストラクターが別のスレッドで実行されている間に基本クラスのサブオブジェクトを使用するという問題とは無関係です。

追加情報

参考までに、現在の言い回しを「動機付けた」DR (それは何も説明していませんが):

コア言語の欠陥レポート #710