Transferring STL and / or MFC Objects Between Modules

Question

I have a rather large code base, which is very modular (many and many plugins), and very often it is necessary to transfer strings and such between modules. For reference, code:

• only compiles in MSVC / Visual Studio and very clearly does not support and does not support other compilers. Their support is not a concern.
• works only on Windows and very clearly does not support and does not support other OSs. Same as above.
• All modules will be similar to Windows PE; accept the same bitta and that they are built for the same platform.
• There are several places where MFC is easier to use, several where STL. Each module will have a very good chance.
• The question only concerns the transfer of objects between modules.

Now I get the impression that the transfer of STL objects between modules can really break if the library or version of the compiler changes. In particular, when it comes to dtors and destroys objects outside the module / version, they were created.

Is MFC safer? Can you transfer an MFC object (a CString for example) from Base.dll to Plugin.dll safely? You need to pass a pointer, can you safely remove it from the plugin?

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

MSDN mentions in several places that:

All memory allocations in a regular DLL must remain within the DLL; A DLL should not transmit or receive from a call executable any of the following:

• pointers to MFC objects
• memory pointers allocated by MFC

If you need to do any of the above or you need to pass MFC objects between the executing program call and the DLL, then you must create a DLL extension.

However, DLL page extensions mention that they are primarily intended for implemented objects derived from MFC objects. I am not interested in this, I just used them and passed them between the various modules.

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

Is there a solution for this without resorting to type C?

Answer 1

The extension DLL will share the MFC DLL with the application and any other extension DLL so that objects can be freely transferred between them. Microsoft may have planned to extend the DLL to implement extended classes, but this is not a requirement - you can use it in any way.

The biggest danger with the standard library is that most of it is template-based. This is dangerous because if the DLL and application are built with different versions of the templates that you use against the One Definition rule, and undefined behavior will bite you in the rear. This is not just the initialization or destruction of the object, but any operation against the object in general!

Answer 2

You can declare only COM-like abstraction interfaces and only a transfer interface. For example, write a factory method, such as WMCreateReader , that creates an object (regardless of whether it is MFC-based or has no STL elements for the caller) and return its interface.