Passing STL and/or MFC objects between modules

I have a rather large code base that is highly modular (lots and lots of plugins), and very often need to pass strings and such between modules. For reference, the code:

• only compiles in MSVC/Visual Studio, and very clearly does not and will not support other compilers. Supporting them is not a concern.
• only runs on Windows, and very clearly does not and will not support other OSes. Same as above.
• all modules will be Windows PEs of some sort; assume the same bitness and that they're built for the same platform.
• there are a few spots where MFC is easier to use, a few where STL is. There's a very good chance both will be used within each module.
• The question is only regarding passing objects between modules.

Now, I'm under the impression that passing STL objects between modules can really break, if the library or compiler versio changes. Particularly when it comes to dtors and destroying objects outside of the module/version they were created in.

Is MFC any safer in that way? Can you pass a MFC object (a CString for example) from Base.dll to Plugin.dll safely? Do you have to pass a pointer, can you not safely delete it from the plugin?

Does it matter if MFC is statically linked or used from a DLL?

MSDN 开发者_Python百科mentions in a few places that:

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.

However, the page extension DLLs mention they are intended primarily for implemented objects derived from MFC objects. I have no interest in doing that, just using them and passing between various modules.

Does passing shared_ptrs change anything (or a class with a virtual dtor)?

Is there a solution to this without resorting to C types?

---

An extension DLL will share the MFC DLL with the application and any other extension DLLs, so that objects may be passed freely between them. Microsoft may have intended for extension DLLs to implement extended classes, but that's not a requirement - you can use it any way you want.

The biggest danger with the standard library is that so much of it is based on templates. That's dangerous, because if the DLL and application are built with different versions of the templates you run against the One Definition Rule and undefined behavior bites you in the rear. This is not just initialization or destruction of the object, but any operation against the object whatsoever!

---

You can declare COM-like abstruct-method only interfaces and pass interface instead. For example write a factory method like WMCreateReader that create an object (whether it is MFC based or has STL members does not need to be exposed to the caller) and return its interface.