On terça-feira, 9 de outubro de 2012 18.19.19, Marc Mutz wrote: > > It would still break forward compatibility. Assume you do the change in > > 5.0.1, and an app gets compiled against 5.0.1 using the new symbol (by not > > reimplementing it in a derived class, or explicitly calling it). Your app > > would crash when run against 5.0.0. > > Ok, so a pure virtual doesn't create a symbol. Understood.
A new pure virtual doesn't create a new symbol. Adding a virtual changes the
vtable layout.
That means you can *override* an existing virtual with a new pure virtual,
thus forcing the class to be abstract. That's binary compatible.
But you cannot override the virtual with a proper function. That breaks the
forwards compatibility.
Note that overriding with a pure virtual might not be *source* compatible. If
the class is non-final (non-leaf), then something might be calling that
function and will now start calling the pure virtual.
struct Base
{
virtual ~Base();
virtual void f();
};
struct Derived : public Base /* before */
{
};
struct UserClass : public Derived
{
void f();
};
void UserClass::f() { Derived::f(); }
/* Assembly:
_ZN9UserClass1fEv:
jmp _ZN4Base1fEv
*/
But if we now override the Derived class's f with a pure virtual
struct Derived : public Base /* after */
{
virtual void f() = 0;
};
Then UserClass::f() becomes:
_ZN9UserClass1fEv:
jmp _ZN7Derived1fEv
Note that it's calling the new symbol, whether it exists or not. That means
the change was not source-compatible.
> Now, what's the forward-compatibility policy on the 4.8 branch?
Any program compiled with Qt 4.8.x will run with Qt 4.8.y, whatever x and y
are (modulo bugs, of course).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
