問題タブ [pycxx]

C++ Python ラッパー (PyCXX) の書き直しがほぼ完了しました。

オリジナルでは、古いスタイルと新しいスタイルの拡張クラスを使用できますが、新しいスタイルのクラスから派生させることもできます。

コードが複雑で、エラーが含まれているようです (なぜ PyCXX は新しいスタイルのクラスをそのように処理するのですか? )

私の質問は: PyCXX の複雑なメカニズムの論理的根拠/正当化は何ですか? よりクリーンな代替手段はありますか？

このお問い合わせに関して、私がどこにいるのかを以下に詳しく説明しようと思います。最初に、現時点で PyCXX が何を行っているかを説明してから、改善できる可能性があると思われることを説明します。

Python ランタイムが に遭遇するとd = Derived()、PyObject_Call( ob ) where ob is thePyTypeObject forNewStyleClass . I will writeob asNewStyleClass_PyTypeObject` を実行します。

その PyTypeObject は C++ で構築され、次を使用して登録されています。PyType_Ready

PyObject_Callを呼び出しtype_call(PyTypeObject *type, PyObject *args, PyObject *kwds)、初期化された派生インスタンスを返します。

このようなもの。

（これはすべて（http://eli.thegreenplace.net/2012/04/16/python-object-creation-sequence、Eliに感謝します！）

type_call は基本的に次のことを行います。

そして、私たちの C++ ラッパーは、次のような関数をtp_newおよびtp_initスロットに挿入しました。NewStyleClass_PyTypeObject

Python Derived インスタンスをバインドする必要があることに注意してください。これは対応する C++ クラス インスタンスです。(なぜですか? 以下で説明します。「X」を参照してください)。そのために、次を使用しています。

さて、この橋は疑問を投げかけます。私はこのデザインに非常に疑問を感じています。

この新しい PyObject にメモリがどのように割り当てられたかに注意してください。

次に、このポインターを に型キャストし、の直後に続くBridge4 または 8 ( ) バイトを使用して、対応する C++ クラス インスタンスを指します (これは、上記のように接続されます)。sizeof(void*)PyObjectextension_object_init

これが機能するためには、次のものが必要です。

a)subtype->tp_alloc(subtype,0)余分なsizeof(void*)バイトを割り当てる必要があります b)PyObjectは を超えるメモリを必要としませんsizeof(PyObject_HEAD)。

この時点での主な質問の 1 つはPyObject、Python ランタイムが作成したが Bridge のフィールドとderived_instance重複しないことを保証できるかということです。ExtObjBase* m_pycxx_object

私はそれに答えようとします。割り当てられるメモリの量を決定するのは米国です。作成するときに、このタイプの新しいインスタンスに割り当てるNewStyleClass_PyTypeObjectメモリ量を入力します。PyTypeObject

あなたはそれが次のように入っているのを見ることができますtable->tp_basicsize

しかし今では、生成された PyObject-sNewStyleClass_PyTypeObjectが追加の割り当てられたメモリを必要としないことは明らかです。

これは、このBridgeメカニズム全体が不要であることを意味します。

そして、PyObject を の基底クラスとして使用し、NewStyleClassCXXClassこの基底を初期化して、Python ランタイムの PyObjectd = Derived()が実際にこの基底になるようにする PyCXX の独自の手法は、見栄えがします。シームレスな型キャストが可能になるためです。

Python ランタイムが からスロットを呼び出すときは常にNewStyleClass_PyTypeObject、最初のパラメーターとして d の PyObject へのポインターが渡され、型キャストして に戻すことができますNewStyleClassCXXClass。<-- 'X' (上記参照)

だから本当に私の質問は、なぜ私たちはこれをやらないのですか? PyObject の余分な割り当てを強制することから派生することについて何か特別なことはありNewStyleClassますか?

派生クラスの場合の作成手順がわからないことに気づきました。エリの投稿はそれをカバーしていませんでした。

という事実が関係していると思われます

^ この変数名は 'subtype' です。これがわかりません。これが鍵を握っているのではないでしょうか。

編集: PyCXX が初期化に sizeof(FinalClass) を使用している理由について、1 つの考えられる説明を考えました。それは試行錯誤したアイデアの遺物かもしれません。つまり、Python の tp_new 呼び出しが FinalClass (ベースとして PyObject を持つ) に十分なスペースを割り当てる場合、'placement new' を使用するか、狡猾な reinterpret_cast ビジネスを使用して、その正確な場所に新しい FinalClass を生成できる可能性があります。私の推測では、これが試行され、何らかの問題を引き起こすことが判明し、回避され、遺物が置き去りにされた可能性があります。

tp_alloc で作成されたものはすべて tp_dealloc で破棄する必要があるというのは本当ですか? 同様に {tp_new, tp_free} についても?

明らかな対称性のように見えますが、明確にしていただければ幸いです。

私の実際の使用例はこれです:

したがって、対応するものPyTypeObject ptoは次のとおりです。

ただし、新しいスタイル クラスは PyObject とそれに対応する C++ オブジェクトを互いに別々に格納するため、動作が異なります。

tp_new に PyObject を作成し、tp_init に対応する C++ オブジェクトを作成します。

そして tp_dealloc でそれらの両方を破棄します

これは正しい/最適ですか?

コード：

Visual Studio を使用して Python C 拡張機能をデバッグすると、「PyThreadState_Get: no current thread」というメッセージが表示されてプログラムが中止されます。

リリースでは、プログラムは正常に動作し、デバッグ情報を追加しても正常に動作します。

問題を解決するには？