このインターフェースを考えると:
struct ISomething
{
virtual void __stdcall DoSomething() = 0;
};
DoSomething
コンパイル設定が異なっていても、アプリケーションはdllまたは共有オブジェクトから返された具体的なオブジェクトを安全に呼び出すことができますか?
( Visual Studio以外のコンパイラで__stdcall
はdが何もないと仮定します。)#define
このインターフェースを考えると:
struct ISomething
{
virtual void __stdcall DoSomething() = 0;
};
DoSomething
コンパイル設定が異なっていても、アプリケーションはdllまたは共有オブジェクトから返された具体的なオブジェクトを安全に呼び出すことができますか?
( Visual Studio以外のコンパイラで__stdcall
はdが何もないと仮定します。)#define
あなたが「オブジェクト」と言うとき、あなたは実際、問題のオブジェクトへのポインタを参照していますか?純粋な仮想declのために、ISomethingを作成することはできません。
つまり、次のことを意味します。
ISomething* pObj = SomeAPICallToGetAnObject();
pObj->DoSomething();
次に、呼び出し元と実装者の両方が呼び出し規約、構造化パラメーターがある場合はそのパッキングなどに同意する限り、機能します。上記の規約は宣言ベースであり、実装者と呼び出し元によって契約上実施されます。これを宣言型コントラクトの一部として定義しないと、厄介なことが起こります。
そのようなことは実際には一般的ですか?絶対。私がよく使用するすべてのWIN32APIコードのCOM側全体は、私が定期的に使用しているのと同じさまざまなコンパイル設定でコンパイルされていないことは間違いありません。しかし、ヘッダーdeclsから取得するコントラクトは、適切な規則を使用してそれを機能させることを保証します。これらの宣言は、実際、私のコンパイルが呼び出しを成功させるための要件に同意することを保証しています。
私はあなたの質問を誤解しなかったと思います。