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

• 只在msvc/visual studio中编译，显然不支持也不支持其他编译器。支持他们不是一个问题。
• 只在Windows上运行，很明显不支持也不支持其他操作系统。同上。
• 所有模块都将是某种类型的Windows PES；假定具有相同的位，并且它们是为相同的平台构建的。
• 有几个地方的MFC更容易使用，一些地方的STL。每个模块中都有很好的机会使用这两个模块。
• 这个问题只涉及在模块之间传递对象。

现在，我的印象是，如果库或编译器版本发生更改，在模块之间传递STL对象会真正中断。尤其是当涉及到数据终端和在模块/版本外销毁对象时。

以这种方式，最惠国待遇是否更安全？您能安全地将mfc对象(例如CString)从base.dll传递到plugin.dll吗？你需要传递一个指针吗，你不能安全地从插件中删除它吗？

如果MFC是静态链接的还是从DLL使用的，这有关系吗？

在一些地方，msdn提到：

All memory allocations within a regular DLL should stay within the DLL; the DLL should not pass to or receive from the calling executable any of the following:

• pointers to MFC objects
• pointers to memory allocated by MFC

If you need to do any of the above, or if you need to pass MFC-derived objects between the calling executable and the DLL, then you must build an extension DLL.

但是，页面扩展DLL提到它们主要用于从MFC对象派生的已实现对象。我没有兴趣这样做，只是使用它们并在不同模块之间传递。

传递共享指针是否会更改任何内容(或使用虚拟dtor的类)？

在不使用C类型的情况下，是否有解决方案？

扩展dll将与应用程序和任何其他扩展dll共享MFC dll，以便对象可以在它们之间自由传递。Microsoft可能希望扩展DLL实现扩展类，但这不是一项要求-您可以以任何方式使用它。

标准库最大的危险在于它中的大部分都是基于模板的。这是危险的，因为如果DLL和应用程序是用不同版本的模板构建的，那么您将违反一个定义规则，并且未定义的行为会在后面咬到您。这不仅仅是对象的初始化或破坏，而是针对对象的任何操作！

您可以声明类似于COM的abstruct方法的仅接口，而不是传递接口。例如，编写一个工厂方法，如wmCreateReader，该方法创建一个对象(无论它是基于MFC的还是具有STL成员，都不需要向调用方公开)并返回其接口。