基於DLL的應用程序框架，帶有雙向接口（Windows）

Question

解決了

this不是問題，因為它無論如何都被隱式地轉換為IFramework 。

我擔心它可能與我的方法沒有返回HRESULT ，或者我的IUnknown::QueryInterface粗短實現，但真正的問題只是一個編譯器設置已經覆蓋了我需要的常見調用約定的幾個宏（也許我應該將它們包含在問題中）。 這破壞了堆棧。

有趣的是，即使沒有實現IUnknown，它對我測試的所有編譯器都有效 - 一點研究表明所有嚴肅的Windows編譯器都以相同的方式處理抽象C ++接口 - 即作為專門用作COM接口的虛擬表。

---

你好。 我正在嘗試創建一個可擴展的應用程序框架。 我的基本概念是這樣的：

“框架”框將構建.exe，而多個“插件”框將構建.dll文件。

但是，我的實施顯然存在缺陷。 我知道問題是什么，但我的解決方法已經不多了。 我用.NET項目完成了這個，但我現在遇到的問題並不適用於C＃環境。

考慮這些接口：

class IFramework
{
public:
    virtual void FrameworkMethod() = 0;
};

class IPlugin
{
public:
    virtual void PluginMethod() = 0;
    virtual void PluginCallbackTest() = 0;
    virtual void SetFramework(IFramework *framework) = 0;
};

框架的實施：

class CFramework : IFramework
{
public:
    void FrameworkMethod(); // printf("FrameworkMethod");
    void DoSomething(); // this is the testbench basically, see below
};

並且插件的實現：

class CPlugin : public IPlugin
{
    IFramework *Framework;
public:
    void PluginMethod(); // printf("PluginMethod");
    void PluginCallbackTest(); // Framework->FrameworkMethod();
    void SetFramework(IFramework *framework); // Framework = framework;
};
// plugin factory -> COM interface
extern "C" PLUGIN_API IPlugin *GetPlugin(); // return new CPlugin;

現在來證明這個概念不起作用：

void CFramework::DoSomething()
{
    HMODULE PluginHandle = LoadLibrary(...); // explicit linking
    auto GetPlugin = ((IPlugin *)(*)())GetProcAddress(...);
    IPlugin *plugin = GetPlugin();
    plugin->PluginMethod();
    // up until here everything's perfectly COM-compliant and works super
    plugin->SetFramework(this); // <-- that is the problem 
    plugin->PluginCallbackTest(); // <-- runtime crash if compiler differs
    FreeLibrary(PluginHandle);
}

問題是SetFramework(this)不像COM那樣工作。 這並不是說這樣寫錯了 - 我無法使用與我用於構建CFramework（運行時崩潰）的編譯器不同的編譯器來實現。

Answer 1

如果您希望允許插件使用不同的編譯器，那么您需要在應用程序和插件之間的邊界上獨占使用COM。 這正是COM旨在解決的問題。