From kde-core-devel  Mon Apr 14 02:15:30 2014
From: =?UTF-8?Q?Nicol=C3=A1s_Alvarez?= <nicolas.alvarez () gmail ! com>
Date: Mon, 14 Apr 2014 02:15:30 +0000
To: kde-core-devel
Subject: Re: Update needed to binary compatibility guide for Windows?
Message-Id: <CANPC-tsi8Mm3dQcQcb0c9ZKnH-knqkFZz9bBKXDNZkqRgPbrvg () mail ! gmail ! com>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=139744177410091

2014-04-13 22:36 GMT-03:00 Michael Pyne <mpyne@kde.org>:
> Hi all,
>
> In the past couple of days our Binary Compatibility in C++ TechBase page =
[1]
> was posted to Reddit [2].
>
> That post received a response [3] which indicated that we're actually mis=
sed a
> potential source of binary incompatibility with virtual functions on Wind=
ows
> with MSVC.
>
> Specifically, that adding an override of an existing virtual function in =
a
> class may cause other vtable function entries to be re-ordered. E.g. in
> something like:
>
> class blah
> {
> public:
>     virtual void func1(int arg);
>     virtual void func2(int arg);
>     virtual void func3(int arg);
> };
>
> Adding a virtual override "func2(char *arg)" to the *end* might cause the
> vftable to line up as if declared in this order:
>
> class blah
> {
> public:
>     virtual void func1(int arg);
>     virtual void func2(int arg);
>     virtual void func2(char *arg);
>     virtual void func3(int arg); // moved
> };
>
> Is anyone able to confirm this behavior on Windows? If it's true, do we w=
ant
> to adopt a constraint on our handling of virtual functions in leaf classe=
s
> based on this? (Adding virtual methods is already not permitted for non-l=
eaf
> classes)

I can confirm this behavior happens.

I compiled this class:
struct Testobj {
    virtual void func1();
    virtual void func2();
    virtual void func3();
};

And a program that calls func1(); func2(); func3();

Then I added a func2(int) overload to the *end*:
struct Testobj {
    virtual void func1();
    virtual void func2();
    virtual void func3();
    virtual void func2(int);
};

and recompiled the class but not the program using the class.

Output of calling func1(); func2(); func3(); was
This is func1
This is func2 taking int
This is func2

This shows that if I declare func1() func2() func3() func2(int), the
vtable is laid out as func1() func2(int) func2() func3().

Tested with MSVC2010.

--=20
Nicol=C3=A1s