order of overloaded methods in the vtable (on win32)

views:

answers:

+2 Q:

order of overloaded methods in the vtable (on win32)

Hi,

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

+1 A:

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.

R Samuel Klatchko 2010-07-14 06:08:00

still, on win32 the compiler generate vtables that are compatible with COM. This is why this approach works (at least for not overloaded functions).

Tobias Langner 2010-07-14 06:15:42

+1 A:

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.

Anthony Williams 2010-07-14 06:57:34

we tried to emulate the mechanisms necessary to obtain compiler independent code but still remain platform independent. Does COM allow overloaded functions?

Tobias Langner 2010-07-14 07:13:01

"Does COM allow overloaded functions" - No. This is probably why the layout compatibility between the different compilers stops here.

Luther Blissett 2010-07-14 07:36:17

we'll try the renaming. Thank you for your help.

Tobias Langner 2010-07-14 07:38:30

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.

dascandy 2010-07-14 10:08:29

as far as I know, all compiler on win32 that support com follow the COM interop ABI. That's why this works anyway. I did not know that this ABI does not allow overloaded functions - which is why this case does not work. I do not use the index - but the compiler places it inside the code (just look at the assembly level). As long as both compiler put in the same index for the same function, the vtable has the same layout.

Tobias Langner 2010-07-15 06:08:15

That explains it then. The ABI allows the overloaded functions (or it would've broken a long time ago). It doesn't specify in what order they should go apparently.My experience with visual studio is that it doesn't bother to reorder functions at all.

dascandy 2010-07-19 22:11:25

ansaurus

tags:

views:

answers:

order of overloaded methods in the vtable (on win32)

related questions