TODO リスト
David AbrahamsCopyright ©2003, 2006 David AbrahamsDistributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
クラスのサポート
仮想関数コールバックラッパの基底クラス
http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1456023(メッセージの最後を見よ)
http://mail.python.org/pipermail/c++-sig/2003-August/005297.html(
VirtualDispatcher
で検索するとよい)に、コールバッククラスがその Python ラッパとの関係について所有権を交換する方法が述べられている。http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1860301 に、基底クラスを使ってコールバッククラスを非常に単純化し、「懸垂参照」問題を解決し、オーバーライドされていない仮想関数の呼び出すを最適化する方法が述べられている。
その他
値が重複した enum のサポート
Scott Snyder がパッチを提供している。Dave はある理由から不満だったが、これ以上のアクションが無ければおそらく適用されるだろう(http://aspn.activestate.com/ASPN/Mail/Message/1824616)。
関数
関数オブジェクトのラップ
operator() をサポートするクラスは Python のメソッドとしてラップ可能となるだろう(http://mail.python.org/pipermail/c++-sig/2003-August/005184.html)。
多重定義解決の「最良マッチ」
現時点では多重定義の解決はdefの呼び出し順に依存する(後の多重定義を優先する)。これは常に最良マッチの多重定義を選択するよう変更すべきである。このテクニックはすでに Luabind で培われているので、Langbinding の合流待ちとなっている。
型変換器
非 const な PyTypeObject*
から lvalue への変換
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1662717
変換器のスコープ制御
上記が完了すれば Luabind の統合と合流することになるだろう。
boost::tuple
Python との相互変換は問題なさそうである。http://news.gmane.org/find-root.php?message_id=%3cuvewak97m.fsf%40boost%2dconsulting.com%3e を見よ。
FILE*
の変換
void*
の変換
CV
void
へのポインタは、不透明な値として関数へ渡したり関数から返したりできるべきである。
呼び出し後(Post-Call)のアクション
Policies オブジェクト内の post-call アクションチェインに from-python 変換器を渡さなければならない(追加のアクションが登録可能な場合)。http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1755435 の最後を見よ。
PyUnicode
のサポート
Lijun Qin によるレビューが http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1771145 にある。この変更は組み入れる可能性が高い。
所有権のメタデータ
http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1860301 のスレッドにおいて、Niall Douglas は「偽の」懸垂ポインタ・参照がオブジェクトに関するデータをアタッチすることでエラーを返すという解法のアイデアについて述べた。そのデータの寿命について伝えてこないオブジェクトの参照カウントをフレームワークが決められる。
ドキュメンテーション
組み込みの変換器
組み込みの Python 型と C++ 型間の組み込みの対応関係についてドキュメントが必要である。
内部的な話
フレームワークの構造についてドキュメントしておく必要がある。Brett Calcott がこのドキュメントをユーザ向けに書き直すと約束してくれた。
大規模
スレッドの完全なサポート
Boost.Python におけるスレッドサポートの強化について、多くの人々からパッチが寄せられている(例えば http://aspn.activestate.com/ASPN/Mail/Message/1826544 や http://aspn.activestate.com/ASPN/Mail/Message/1865842 のスレッドを見よ)。唯一の問題はこれらが不完全な解法であることで、完全な解法があるのか検証するには時間と注意が必要である。
Langbinding
このプロジェクトは Boost.Python を一般化して他の言語で動作するもので、一番手は Lua である。http://lists.sourceforge.net/lists/listinfo/boost-langbinding の議論を見よ。
リファクタリングと再構成
http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1673338
NumArray サポートの強化
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1757092 で述べられている強化について統合を検討する。
PyFinalize
の安全性
現在のところ、Boost.Python にはグローバル(および関数内静的)オブジェクトが複数あり、それらは Boost.Python 共有オブジェクトがアンロードされるまで参照カウントがゼロにならない。インタープリタが存在しない状態で参照カウントがゼロになるので、クラッシュを引き起こす。PyFinalize
の呼び出しを安全にするには、これらのオブジェクトを破壊し Python の参照カウントを解放する atexit
ルーチンを登録して、Python がインタープリタが存在している間にそれらを始末できるようにしなければならない。Dick Gerrits が何とかすると約束してくれた。