基于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旨在解决的问题。