Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You should be able to mix modules built with different compilers if you lower your expectations and stick to simple functions.</p> <p>The way classes and virtual functions behave is defined by the C++ standard, but the way that's implemented is up to the compiler. In this case, I know that VC++ builds objects which have virtual functions with a "vtable" pointer in the first 4 bytes of the object (I'm assuming 32-bit), and that points to a table of pointers to the method entry points.</p> <p>So the line: <code>dllclass-&gt;PrintSomething();</code> is actually equivalent to something like:</p> <pre><code>struct IClassVTable { void (*pfIClassDTOR) (Class IClass * this) void (*pfIRefCountedAddRef) (Class IRefCounted * this); void (*pfIRefCountedRelease) (Class IRefCounted * this); void (*pfIClassPrintSomething) (Class IClass * this); ... }; struct IClass { IClassVTable * pVTab; }; (((struct IClass *) dllclass)-&gt;pVTab-&gt;pfIClassPrintSomething) (dllclass); </code></pre> <p>If the g++ compiler is implementing the virtual function tables in any way differently from MSFT VC++ -- as it is free to do and still be conformant to the C++ standard -- this will just crash as you've demonstrated. The VC++ code expects the function pointers to be in particular places in memory (relative to the object pointer).</p> <p>It gets more complicated by inheritance, and really, really, complicated with multiple inheritance and virtual inheritance.</p> <p>Microsoft has been very public about the way VC++ implements classes, so you can write code that depends on it. For example, a lot of COM object headers distributed by MSFT have both C and C++ bindings in the header. The C bindings expose their vtable structure like my code above does.</p> <p>On the other hand, GNU -- IIRC -- has left open the option of using different implementations in different releases, and just guaranteeing the programs built with it's compiler (only!) will conform to the standard behaviour,</p> <p>The short answer is to stick to simple C-style functions, POD structures (Plain Old Data; i.e., no virtual functions), and pointers to opaque objects.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload