6
我有一个相当大的代码库，它是高度模块化的（很多插件），并且经常需要在模块之间传递字符串等。作为参考，代码：在模块之间传递STL和/或MFC对象
- 只在MSVC/Visual Studio中编译，很明显不会，也不会支持其他编译器。支持他们不是一个问题。
- 只能在Windows上运行，很明显不会，也不会支持其他操作系统。同上。
- 所有模块都是某种Windows PE;假设相同的位，并且它们是为相同的平台而构建的。
- 有几个地方MFC更容易使用，其中一些地方是STL。在每个模块中都有很好的机会。
- 问题是只有关于通过对象之间模块。
现在，我的印象是，如果库或编译器版本发生更改，传递模块之间的STL对象可能会中断。特别是当涉及到模块/版本之外的dtors和破坏对象时，它们就被创建了。
MFC是否更安全？你能否安全地将MFC对象（例如CString）从Base.dll传递给Plugin.dll？你是否必须传递一个指针，你不能安全地从插件中删除它吗？
如果MFC静态链接或使用DLL是否有关系？
MSDN中提到的那几个地方：
常规DLL中的所有内存分配应该留在DLL中;该DLL不应该通过或从主叫接收可执行以下任何一项：
- 指针MFC对象
- 内存指针由MFC
分配如果您不需要做任何的上面，或者如果您需要在调用的可执行文件和DLL之间传递MFC派生的对象，那么您必须构建一个扩展DLL。
但是，the page extension DLLs提到它们主要用于从MFC对象派生的实现对象。我对此没有兴趣，只是使用它们并在各个模块之间传递。
是否通过shared_ptrs改变任何东西（或与虚拟dtor类）？
有没有解决方案，而不诉诸C类型？
我的理解是，使MFC扩展需要客户端（无论使用DLL的可执行文件？）也必须使用MFC和相同的版本。看起来这将排除更新DLL和使用MFC，如果客户端最初没有使用它。它是否正确？这似乎是一个很好的解决方案，否则。 – ssube
@peachykeen，是的，应用程序必须使用MFC。是的，它应该是与DLL所使用的版本相同的版本，但我不确定不匹配的后果 - MFC倾向于比C++库更快地发展，并且因为它们都不基于模板I我不确定从版本到版本的不兼容性。 –