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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development