Exporting classes to a dll in a portable way, without using interfaces?

I have a question about shared libraries/.dlls and class importing/exporting. From what I have under开发者_如何学Gostood after some research the two ways to do it is as follows:

Just using __declspec(dllexport/dllimport) before the class and praying that the different compiler versions mangle the names in the same way, and accept the fact that your .dll will not be useable by different compilers.

Use pure virtual classes in the dll as interfaces. Then all the classes that would need exporting would inherit from them and should implement the virtual functions. What the .dll would export in this case is just "factory" Construct/Destruct functions which would create and release the objects.

These are the only two ways I know. The first is a no-no since it offers 0 portability. The second, though convenient and a good programming design for a .dll that accomplishes a purpose starts to be annoying when you realize that you need to have a different constructor function for every different constructor, can only use POD types as parameters and you lose many advantages of C++ classes such as overloaded functions and default function arguments.

For a .dll that is supposed to offer a library to the user, a collection of classes for example even the second way becomes really inconvenient. So I am wondering what is the solution here? Just compile a different .dll with the first way for each major compiler? How do the shared libraries version of big libraries work? For example wxWidgets does offer a .dll version too. How do they achieve normal usage of classes by the end user of the .dll avoiding the interface solution?

---

Solution with having separate DLL for each compiler version works. At the same time it is still not an official feature. You will never know if next service pack will break the compatibility or not, nobody will give you exact list of compiler/linker keys that will maintain/break the compatibility, etc. I heard reliable rumors that Windows8 finally implemented this in the right way.

By the way Visual Studio 2012 Release Candidate can be still downloaded from: http://msdn.microsoft.com/en-us/vstudio/bb984878.aspx. Maybe you should try it?