在模块之间传递STL和/或MFC对象

Question

我有一个相当大的代码库，它是高度模块化的（很多很多插件），并且经常需要在模块之间传递字符串等。供参考，代码：

• 仅在MSVC / Visual Studio中编译，很明显不会也不会支持其他编译器。支持他们不是一个问题。
• 仅在Windows上运行，并且非常明显不支持并且不支持其他操作系统。与上述相同。
• 所有模块都是某种类型的Windows PE;假设相同的位数，并且它们是为同一平台构建的。
• 有一些地方MFC比较容易使用，有些地方就是STL。每个模块都有很好的机会使用它们。
• 关于模块之间传递对象的问题仅为 。

现在，我的印象是，如果库或编译器versio发生更改，在模块之间传递STL对象确实会破坏。特别是当涉及到dtors并销毁模块/版本之外的对象时，它们就是在它们中创建的。

MFC是否更安全？你可以安全地从Base.dll传递一个MFC对象（例如CString）到Plugin.dll吗？你必须传递一个指针，你能不能安全地从插件中删除它？

MFC是否静态链接或从DLL中使用是否重要？

MSDN在一些地方提到：

  

常规DLL中的所有内存分配都应该保留在DLL中; DLL不应传递给调用可执行文件或从中接收以下任何内容：

     

  
• 指向MFC对象的指针
  
• 指向MFC分配的内存的指针
  

     

如果您需要执行上述任何操作，或者需要在调用可执行文件和DLL之间传递MFC派生的对象，则必须构建扩展DLL。

但是，the page extension DLLs提到它们主要用于从MFC对象派生的已实现对象。我没有兴趣这样做，只是使用它们并在各种模块之间传递。

传递shared_ptrs会改变任何东西（或带有虚拟dtor的类）吗？

如果没有诉诸C类型，是否有解决方案？

Answer 1

扩展DLL将与应用程序和任何其他扩展DLL共享MFC DLL，以便对象可以在它们之间自由传递。 Microsoft可能打算使用扩展DLL来实现扩展类，但这不是必需的 - 您可以以任何方式使用它。

标准库的最大危险在于它的大部分基于模板。这是危险的，因为如果DLL和应用程序是使用不同版本的模板构建的，那么您将针对单一定义规则运行，未定义的行为会让您陷入困境。这不仅仅是对象的初始化或破坏，而是对任何对象的任何操作！

Answer 2

您可以声明类似于COM的abstruct-method接口并改为传递接口。例如，编写一个像WMCreateReader这样的工厂方法创建一个对象（无论是基于MFC还是STL成员都不需要向调用者公开）并返回其接口。