DLL需要访问其应用程序的符号 在C++中，DLL是否可以访问加载它的应用程序的一些符号？ 我有一个加载插件（dll）的应用程序，这些插件需要访问应用程序的一些API

是否可以在不创建共享此API的新DLL的情况下实现这一点

函数指针的结构是否适合这种情况

---

示例：主机应用程序中定义的bool Log（char*）函数和需要记录某些事件的插件。

这是可能的，但您的设计选择值得怀疑

EXE可以以与DLL相同的方式导出函数，因此您可以以熟悉的方式使用GetProcAddress

然而，为什么要设计它，使插件需要了解宿主程序的内部功能？应该是相反的

主机应该要求插件实现一组例程（它们导出这些例程），遵守特定的契约。作为其接口的一部分，主机可以在指向结构的指针中向其传递特定于主机的信息（例如，版本信息、功能）等，如果需要的话

---

插件不应试图获取指向主机模块的函数指针。

回调函数指针、回调函数指针列表或回调接口指针-我将使用这些选项之一。Dll客户端必须实现回调接口，并将指向此接口的指针传递给动态创建的Dll。动态创建的Dll保留此指针，并在必要时调用其函数，例如，报告某些事件。

将回调接口传递到插件Dll的另一次投票。即回调接口

class IHostApplication
  {
  public:
    virtual bool Log(const wchar_t* ip_log_string) = 0;
  };

DLL插件接口

class IPlugin
  {
  public:
    virtual void InitializePlugin(IHostApplication *ip_host) = 0;
  };

---

主机将加载插件DLL（必要时动态加载），然后将自身作为IHostApplication*传递给插件，从而启用您可能需要的任何回调。

危害何在？一个插件无论如何都必须遵守一个非常具体的合同，而且如果除了主机应用程序之外的任何人加载它，它可能不会工作。如果执行器也输出一些插件来调用1的符号，我就不会看到太多的伤害，但是在C++之上构建插件架构是个不错的选择吗？插件必须用同一个C++编译器构建（如果不是版本，至少是制造商）。如果你倾向于这样，你可以总是“C”，当然这限制了C风格的函数接口，但这是权衡。我建议使用COM，但我不能直面：）