1) DLL によって提供される INTERFACE が実際に C++ インターフェイスである場合、はい、他の言語が DLL とインターフェイスするのが (不可能ではないにしても) 難しくなります。
C++ は、C よりもインターフェイスが複雑です。これは、クラスの構造 (this
渡されるポインター、仮想関数ポインター/VTABLE レイアウト) および例外処理 (呼び出されたコードが例外が発生したという事実を処理する必要がある場合)がより複雑であるためです。そのためには、コードは、例外をスローしたコードの呼び出しスタックを「巻き戻し」、途中で作成されたオブジェクトを見つけるまで破棄できる必要がありますcatch
- それが呼び出しスタックに存在しない場合DLL内で問題が発生します-この巻き戻しはC++標準の一部ではありません。標準は、プロセッサが必要とする/必要以上にC++を実装する必要があるアーキテクチャと機能を制限したくないためです)。DLL 内で例外をキャッチすると、ここでの問題が解決されます。
言い換えれば、コードを呼び出している言語が C++ ではない場合 (およびおそらく同じベンダーから)、呼び出し元の言語が何であれ、C++ を処理する必要があります。これはかなり複雑になる可能性があります。
C++ オブジェクトは、呼び出し元のコードで関連する言語との間で変換する必要があります。C と共通の基本的な型の場合、これは通常問題にはなりませんが、クラス、構造体などは、ローカル言語で互換性のあるものと一致させる必要があります。
一方、AC 関数はインターフェイスが非常に簡単です。引数をスタックに置き、関数を呼び出し、戻り時に引数をクリーンアップします。奇妙なことは何も起こらず、隠し関数パラメーターも、スタックを巻き戻す必要もありません。唯一のわずかな複雑さは、struct
(特定のサイズよりも大きい) a を返す関数です。ただし、これは C ではかなり特殊なケースです。C の「オブジェクト」ははるかに単純であり、ほとんどの言語には、基本的な C 言語の型 (しかし、C スタイルstruct
は依然としていくつかの興味深い問題を引き起こす可能性union
があり、「巧妙に」使用すると非常に困難になる可能性があります)。
2) 言語の選択は複雑な作業であり、DLL がどのように使用されるか、提供されるインターフェイスの種類、および DLL が別の C++ とインターフェイスしている場合は、DLL 自体がどのインターフェイスに接続する必要があるかに大きく依存します。 DLL (またはその他の C++ コード) の場合、おそらく C++ を使用する必要があります。extern "C"
しかし、 for インターフェイス関数を使用して、C インターフェイスを持つ C++ DLL を生成する方法があります(そしてthrows
、"C" の壁を越えないようにします。これは間違いなく問題を引き起こすからです)。
結論:
明らかに、インターフェイスを「C++ のみを使用する」ように制限することで、C、Python、または Lisp [おそらく C 関数をかなり簡単に呼び出すことができる] からライブラリを使用する人がいるという点で、さらに複雑になります。ユーザーは C++ コードを C 言語ラッパーでラップする必要があります。はい、これは可能であり、C++ で本当に優れたライブラリが利用可能で、C スタイルのインターフェイスが利用可能な言語に接続したい場合に、かなり定期的に使用されます。これは、DLL のプロデューサーによって提供されないことを除いて、「DLL 内で C から C++ へのインターフェイスを提供する」とほぼ同じソリューションです。