order of overloaded methods in the vtable (on win32)

is the order of overloaded methods in the vtable always the same across win32 compilers?

Problem: I have "interfaces" (pure virtual classes with no data members). They can be used via pointer from different compilers (the client gets the pointer by calling a standard c dll factory method). This works fine across different compiler (e.g. client written with borland, interface dll written with Visual C++) except for one method. This method is overloaded with the same return value but different parameter. There are 4 versions of this method. The same call to this method returns different results depending on the compiler that compiled the client. A quick look a the assembler code showed me that there seems to be a different offset 开发者_如何学运维into the vtable (I'm not really good at reading assembler).

Now I don't know - did I find the cause or is borland just handling the vtable different to visual studio and everything is correct and I have to search elsewhere.

best regards and thank you for your answers

Tobias

There are two possible causes: either the client compiler is choosing a different overload than you expect, or the different compilers are putting the overloads in different vtable entries.

What parameters are you passing/expecting? Could overload resolution be the problem?

If it's the vtable entries then you could try renaming the overloads.

Have you tried using whatever COM mechanism is available on your target compilers when declaring the interface --- e.g. using the interface keyword in MSVC, and giving your interface class a GUID. COM interfaces are supposed to have the functions in the vtable in the order declared, which is therefore common between compilers if they share the same header.

The order of functions in the vtable is one of the things covered by the ABI. Unfortunately, the ABI is not part of the C++ standard so it is quite common for different compilers do use different ABIs.

We ran into this problem a few years ago. I can't find much supporting documentation for it now, but it is my understanding that visual studio groups overloaded functions in the vtable even if they are declared separately. This was causing our build to work fine in gcc, but crash in visual studio. I believe we eventually just removed the overloaded functions, as we didn't find a way around it.

It needn't be the index that's wrong - they can have completely different size entries in their vtables. Unless their ABI matches, there's no guarantee anything is the same. When their ABI does match, it's guaranteed.

Possible ABI's are the IA64 abi that's used by GCC and Intel's C++ compiler, or the COM interop that Microsoft introduced.