I noticed that MinGW's G++ doesn't make vtables using the same algorithm as Visual C++, which can break COM interfaces. If there are two overloaded functions with the same name, Visual Studio will group the functions of the same name together instead of preserve the ordering specified in the virtual table.
virtual void Overloaded(int) = 0;
virtual void Other() = 0;
virtual void Overloaded(Vtable&) = 0;
void Function(Vtable& param)
Visual Studio assembly code (/Ox /Oy-):
mov ebp, esp
mov ecx, DWORD PTR 8[ebp]
mov eax, DWORD PTR [ecx]
mov edx, DWORD PTR [eax]
MinGW assembly code (-O3):
movl %esp, %ebp
subl $8, %esp
movl 8(%ebp), %eax
movl (%eax), %edx
movl %eax, 4(%esp)
movl %eax, (%esp)
Note how in the MinGW version the "call" instruction adds 8 to the address from which the function pointer is read in the MinGW version. Curiously, Visual Studio put the second overload first when it grouped them.
The real question is, which compiler is incorrect here according to COM?
MinGW G++ 3.4.5 (automated installer thing). Visual Studio 2005 SP1.
> I noticed that MinGW's G++ doesn't make vtables using the same algorithm as
> Visual C++, which can break COM interfaces. If there are two overloaded
> functions with the same name, Visual Studio will group the functions of
> the same name together instead of preserve the ordering specified in the
> virtual table.
Both Visual C++ and G++ puts functions in order of declaration into the
VTable. However, if the same name is used for several virtual functions,
there is a difference:
- G++ keeps to the order of declaration
- Visual C++ stores functions into the VTable in reversed order of
Apparently the reason for VC++ to do this is backwards compatability
with some pre-windows X86 std. COM had to support that. No better reason
Stay away from virtual functions with the same name if you want cross
> Input program:
> struct Vtable
> virtual void Overloaded(int) = 0;
> virtual void Other() = 0;
> virtual void Overloaded(Vtable&) = 0;