On Wed, Jun 17, 2015 at 1:08 PM, Ruben Van Boxem <[email protected]> wrote:
> >> > This is most likely an ABI issue yes, because you are relying on the > binary interface of the app and dll to be the same (i.e. the objects are > assumed to have the same memory layout and alignment and padding and > whatnot). Unfortunately, different compilers generate different class > layout and contents (think vptr) so they can be incompatible. > > A way to solve this is to have only a C-style interface (no class types as > parameters) and have the plugin handle all the class creation and memory > management so that the "user code" only sees an opaque pointer (void*) to > something the plugin created and manages the memory for. This requires > quite some changes in the code most likely, but I don't know of another way > to work around this incompatibility. > > Maybe someone else here has another idea :) > > Cheers, > > Ruben > I just sent an answer very similar to yours :-) I suggest Etienne takes a look at how microsoft implemented gdiplus (gdi+). It's a C api, with C++ header-only wrappers that makes the glue logic (for instance, calls the right "C" function for allocating and deallocating resources and constructor and destructor, respectively, etc.). It's the easiest way for breaking ABI barriers. The plugin API code doesn't need to be implemented in plain C, it can be C++ (or whatever) just fine, but it needs to abstract the public API (the exported functions plugins are going to see) via C plain function methods which only pass opaque pointers or POD (plain old data) pointers.
------------------------------------------------------------------------------
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
