From kde-core-devel  Tue Apr 15 11:43:42 2014
From: Milian Wolff <mail () milianw ! de>
Date: Tue, 15 Apr 2014 11:43:42 +0000
To: kde-core-devel
Subject: Re: Update needed to binary compatibility guide for Windows?
Message-Id: <5948006.MjBaZSJfvi () minime>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=139756224420837

On Sunday 13 April 2014 23:15:30 Nicol=E1s Alvarez wrote:
> 2014-04-13 22:36 GMT-03:00 Michael Pyne <mpyne@kde.org>:
> > Hi all,
> >=20
> > In the past couple of days our Binary Compatibility in C++ TechBase=
 page
> > [1] was posted to Reddit [2].
> >=20
> > That post received a response [3] which indicated that we're actual=
ly
> > missed a potential source of binary incompatibility with virtual
> > functions on Windows with MSVC.
> >=20
> > Specifically, that adding an override of an existing virtual functi=
on in a
> > class may cause other vtable function entries to be re-ordered. E.g=
. in
> > something like:
> >=20
> > class blah
> > {
> >=20
> > public:
> >     virtual void func1(int arg);
> >     virtual void func2(int arg);
> >     virtual void func3(int arg);
> >=20
> > };
> >=20
> > Adding a virtual override "func2(char *arg)" to the *end* might cau=
se the
> > vftable to line up as if declared in this order:
> >=20
> > class blah
> > {
> >=20
> > public:
> >     virtual void func1(int arg);
> >     virtual void func2(int arg);
> >     virtual void func2(char *arg);
> >     virtual void func3(int arg); // moved
> >=20
> > };
> >=20
> > Is anyone able to confirm this behavior on Windows? If it's true, d=
o we
> > want to adopt a constraint on our handling of virtual functions in =
leaf
> > classes based on this? (Adding virtual methods is already not permi=
tted
> > for non-leaf classes)
>=20
> I can confirm this behavior happens.
>=20
> I compiled this class:
> struct Testobj {
>     virtual void func1();
>     virtual void func2();
>     virtual void func3();
> };
>=20
> And a program that calls func1(); func2(); func3();
>=20
> 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);
> };
>=20
> and recompiled the class but not the program using the class.
>=20
> Output of calling func1(); func2(); func3(); was
> This is func1
> This is func2 taking int
> This is func2
>=20
> This shows that if I declare func1() func2() func3() func2(int), the
> vtable is laid out as func1() func2(int) func2() func3().
>=20
> Tested with MSVC2010.

Awesome, please add this information to the guide on the wiki. The page=
 is a=20
quite helpful one, i.e. no wonder it was posted to reddit. Having it as=
=20
extensive as possible is a good thing imo.

Cheers
--=20
Milian Wolff
mail@milianw.de
http://milianw.de