Pythonでは、共有ライブラリのエントリポイントを呼び出すために、どのような状況でSWIGがctypesよりも優れた選択肢ですか？SWIGインターフェイスファイルがまだない場合を考えてみましょう。
2つのパフォーマンスメトリックは何ですか？
25597 次
10 に答える
96
私は小枝を使った豊富な経験があります。SWIGは、物を包むための迅速な解決策であると主張しています。しかし、実際には...
短所：
SWIGは、すべての人と20以上の言語向けに一般的に開発されています。一般に、これには欠点
があります。-構成が必要（SWIG .iテンプレート）、場合によっては注意が必要、
-特殊なケースの処理が不足している（Pythonプロパティをさらに参照）、
-一部の言語のパフォーマンスが不足している。
Pythonの短所：
1）コードスタイルの不一致。C ++とPythonのコードスタイルは非常に異なり（確かに明らかです）、ターゲットコードをよりPythonっぽくするための小枝の可能性は非常に限られています。例として、ゲッターとセッターからプロパティを作成するのはお尻の心です。このQ＆Aを参照してください
2）幅広いコミュニティの欠如。SWIGにはいくつかの優れたドキュメントがあります。しかし、ドキュメントにないものを見つけた場合、情報はまったくありません。ブログもグーグルも役に立ちません。したがって、そのような場合、SWIGで生成されたコードを徹底的に掘り下げる必要があります...それはひどいです、私は言うことができます...
長所：
単純なケースでは、それは本当に速く、簡単で簡単です
一度swigインターフェースファイルを作成した場合は、このC ++コードを他の20以上の言語のいずれかにラップできます（!!!）。
SWIGに関する大きな懸念の1つは、パフォーマンスです。バージョン2.04以降、SWIGには「-builtin」フラグが含まれているため、SWIGは他の自動ラッピング方法よりもさらに高速になります。少なくともいくつかのベンチマークはこれを示しています。
SWIGを使用するのはいつですか？
そこで、小枝を使用するのに適した2つのケースを自分で結論付けました。
2）複数の言語のC++コードをラップする必要がある場合。または、可能性がある場合は、コードを複数の言語に配布する必要がある場合があります。この場合、SWIGの使用は信頼できます。
1）最終用途のためにいくつかのC++ライブラリからいくつかの関数を迅速にラップする必要がある場合。
ライブ体験
更新：
SWIGを使用してライブラリを変換してから1年半が経過しました。
まず、Pythonバージョンを作成しました。SWIGでトラブルが発生した瞬間がいくつかありましたが、それは事実です。しかし今、私たちはライブラリをJavaと.NETに拡張しました。つまり、1つのSWIGで3つの言語があります。そして、多くの時間を節約するという点で、SWIGは素晴らしいと言えます。
アップデート2：
このライブラリにSWIGを使用してから2年になります。SWIGはビルドシステムに統合されています。最近、C++ライブラリのAPIが大幅に変更されました。SWIGは完璧に機能しました。私たちがする必要がある唯一のことは、いくつかの％renameを.iファイルに追加することCppCamelStyleFunctions()ですlooks_more_pythonish。最初に発生する可能性のあるいくつかの問題について心配しましたが、何も問題はありませんでした。それは驚くべきものだった。いくつかの編集とすべてが3つの言語で配布されています。今、私は、私たちのケースでSWIGを使用することが良い解決策であったと確信しています。
アップデート3：
ライブラリにSWIGを使用するのは3年以上です。主な変更点：Pythonの部分は完全に純粋なPythonで書き直されました。その理由は、Pythonが現在私たちのライブラリのアプリケーションの大部分に使用されているためです。純粋なPythonバージョンの動作がC++のラッピングよりも遅い場合でも、ユーザーがネイティブライブラリに苦労することなく、純粋なPythonを使用する方が便利です。
SWIGは、引き続き.NETおよびJavaバージョンで使用されます。
ここでの主な質問は、「プロジェクトを最初から開始した場合、PythonにSWIGを使用しますか？」です。私たちはそうします！SWIGにより、製品を多くの言語に迅速に配布することができました。それは一定期間機能し、ユーザーの要件をよりよく理解する機会を与えてくれました。
于 2011-02-03T22:47:25.317 に答える
70
SWIG は (やや醜い) C または C++ コードを生成します。単純な関数 (直接変換できるもの) の場合は簡単に使用でき、より複雑な関数 (Python で表現するために追加の変換ステップが必要な出力パラメーターを持つ関数など) の場合はかなり簡単に使用できます。インターフェイス ファイルの一部として C のビットを書き込む必要があります。単純な使い方以外では、CPython と、それがどのようにオブジェクトを表現するかについて知る必要があります。難しいことではありませんが、心に留めておくべきことがあります。
ctypes を使用すると、C 関数、構造体、およびその他のデータに直接アクセスし、任意の共有ライブラリをロードできます。これを行うために C を記述する必要はありませんが、C がどのように機能するかを理解する必要があります。これは、SWIG の裏側であると主張することもできます。コードを生成せず、実行時にコンパイラを必要としませんが、単純な使用以外の場合は、C データ型、キャスト、メモリ管理と整列作業。また、C の構造体、共用体、および配列を、適切なメモリ レイアウトを含む同等の ctypes データ構造に手動または自動で変換する必要もあります。
純粋な実行では、SWIG は ctypes よりも高速である可能性があります。実際の作業に関する管理は、実行時に Python ではなく、コンパイル時に C で行われるためです。ただし、多数の異なる C 関数をインターフェイスとして使用する場合を除き、それぞれが数回しか使用されない場合は、オーバーヘッドが実際に顕著になることはまずありません。
開発時には、ctypes の起動コストがはるかに低くなります。インターフェイス ファイルについて学習する必要はなく、.c ファイルを生成してコンパイルする必要も、チェックアウトして警告を黙らせる必要もありません。最小限の労力で 1 つの C 関数の使用を開始し、それをさらに拡張することができます。そして、Python インタープリターで直接テストして試すことができます。多くのコードをラップするのはやや面倒ですが、それを簡単にしようとする試みもあります (ctypes-configure など)。
一方、SWIG は、複数の言語のラッパーを生成するために使用できます (前述のカスタム C コードのように、言語固有の詳細を埋める必要がある場合を除きます)。コード生成は、同等の ctypes よりもはるかに簡単にセットアップできます。
于 2008-09-25T20:47:28.410 に答える
13
CTypes は非常に優れており、SWIG よりもはるかに簡単ですが、不適切または悪意を持って記述された Python コードが実際に Python プロセスをクラッシュさせる可能性があるという欠点があります。ブーストpythonも検討する必要があります。私見では、最終的な python インターフェイスをより詳細に制御しながら、実際には swig よりも簡単です。とにかく C++ を使用している場合は、他の言語をミックスに追加する必要もありません。
于 2008-09-25T20:35:17.580 に答える
11
私の経験では、ctypesには大きな欠点があります。何かがうまくいかない場合（そして、複雑なインターフェースでは必ずそうなります）、デバッグするのは大変です。
問題は、スタックの大部分がctypes / ffiマジックによって隠されており、特定のポイントに到達した方法と、パラメーター値が何であるかを簡単に判断する方法がないことです。
于 2009-01-21T01:36:28.550 に答える
8
また、高レベルの Python コードと低レベルの C コードの間の接着剤として機能するPyrexを使用することもできます。たとえば、 lxmlは Pyrex で記述されています。
于 2008-09-25T20:54:22.447 に答える
7
ctypes は優れていますが、C++ クラスを処理しません。また、ctypes は C の直接バインディングよりも約 10% 遅いことがわかりましたが、それは呼び出している内容に大きく依存します。
ctypes を使用する場合は、ctype バインディングの膨大な例がある Pyglet および Pyopengl プロジェクトを確認してください。
于 2008-09-25T21:22:15.533 に答える
7
私は逆張りで、可能であれば、標準の Python APIを使用して拡張ライブラリを作成することをお勧めします。C と Python の両方の観点から非常によく統合されています... Perl API の経験があれば、非常に嬉しい驚きです。
Ctypes もいいのですが、他の人が言っているように、C++ には対応していません。
ラップしようとしているライブラリの大きさは? コードベースはどのくらいの速さで変更されますか? その他のメンテナンスの問題はありますか？これらはすべて、Python バインディングを記述する最善の方法の選択に影響を与える可能性があります。
于 2008-09-26T04:49:05.350 に答える
5
まだ言及されていない考慮事項をいくつか追加したかっただけです。[編集: おっと、Mike Steder の回答が表示されませんでした]
Cpython 以外の実装 (PyPy、IronPython、Jython など) を試してみたい場合は、ctypes が唯一の方法です。PyPy では C 拡張の記述が許可されていないため、pyrex/cython と Boost.python は除外されます。同じ理由で、ctypes は、IronPython と (すべてが機能するようになると) jython で機能する唯一のメカニズムです。
他の誰かが述べたように、コンパイルは必要ありません。これは、新しいバージョンの .dll または .so が出てきた場合、それをドロップして、その新しいバージョンをロードできることを意味します。変更されたインターフェイスがない限り、それは一時的な交換です。
于 2011-08-04T06:13:02.127 に答える
3
覚えておくべきことは、SWIGはCPython実装のみを対象としているということです。ctypesはPyPyおよびIronPythonの実装でもサポートされているため、より広いPythonエコシステムとの互換性のために、ctypesを使用してモジュールを作成する価値があるかもしれません。
于 2011-02-25T05:35:20.143 に答える
1
私は、SWIG のアプローチが少し肥大化しており (一般に、Python だけでなく)、きれいに書くのではなく、SWIG フレンドリーであるという明示的な考え方で Python コードを書くという厄介な点を越えずに実装するのが難しいことを発見しました。 -書かれた Python コード。私見ですが、C バインディングを C++ に記述し (C++ を使用している場合)、ctypes を使用して任意の C レイヤーにインターフェイスするのは、はるかに簡単なプロセスです。
接続先のライブラリにライブラリの一部として C インターフェイスがある場合、ctypes のもう 1 つの利点は、サードパーティ ライブラリにアクセスするために別の Python バインディング ライブラリをコンパイルする必要がないことです。これは、クロスプラットフォームのコンパイルの問題を回避する純粋な Python ソリューションを策定する場合に特に便利です (異種プラットフォームで提供されるサードパーティ ライブラリの場合)。コンパイルされたコードを PyPi のようなものにデプロイしたいパッケージに、クロスプラットフォームに適した方法で埋め込まなければならないのは面倒です。SWIG またはその下にある明示的な C コードを使用する Python パッケージに関する私の最も苛立たしい点の 1 つは、それらが一般的にクロスプラットフォームで利用できないことです。したがって、クロスプラットフォームで利用可能なサードパーティ ライブラリを使用し、それらを中心に Python ソリューションを開発している場合は、これを考慮してください。
実際の例として、PyGTK を考えてみましょう。これは (私が思うに) SWIG を使用して C コードを生成し、GTK C 呼び出しに接続します。私はこれをごく短時間だけ使用しましたが、セットアップと使用が本当に面倒であることがわかりました。セットアップ時に正しい順序で物事を行わないと、一般的には風変わりな奇妙なエラーが発生します。それは非常に苛立たしい経験であり、Web 上の GTK によって提供されたインターフェイス定義を見て、それらのインターフェイスから Python ctypes インターフェイスへのトランスレーターを作成するのは、非常に簡単な作業であることに気付きました。PyGGI と呼ばれるプロジェクトが生まれ、ある日、私は PyGTK を、GTK C オブジェクト指向インターフェースに完全に適合する、より機能的で便利な製品に書き直すことができました。また、C コードをコンパイルする必要がないため、クロスプラットフォームに対応しています。(私は実際には webkitgtk に接続した後でした。クロスプラットフォームです）。また、GTK をサポートする任意のプラットフォームに PyGGI を簡単にデプロイできます。
于 2013-05-28T15:17:46.637 に答える