I have to explain my team why exporting classes from DLL is not good solution, if we plan to use that DLL from different compiler. But I can't find prove for that. Is there something in standart like "compiler shouldn't supply backward compatibility, also different compilers can implement their own style of naming exporting symbols, so exported class from DLL can be used then just by same compiler"? I know it is true, but how can I prove that? Also, if you know additional arguments for me, please, help!
Here are a few points that you may find interesting/useful to tell your team.
Different compilers mangle C++ names differently. This simple name mangling issue may be possible to circumvent with an explicit .def file.
Different structure alignment issues which need the correct compiler options (-mms-bitfields, ...).
A fundamental conflict of underlying exception and memory models:
A new/delete or malloc/free in a MSVC DLL will not co-operate with a Cygwin newlib new/delete or malloc/free. One cannot free space which was allocated in a function using a different new/malloc at all.
An exception raised by an MSVC DLL will not be caught by a Cygwin executable, and vice versa.
The slow GNU SJLJ exception model, (used in GCC-3.x and earlier), is compatible with the MSVC++ model, but the new DWARF2 model, (which will be used by GCC-4.x), will be incompatible.
A more complete explanation is given here, from where I shamelessly copied the above. Seeing as you use MinGW, this should be very relevant.
Also, if you haven't done so already, take a look at the discussion for this SO question.