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 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?