[Development] Is overriding an existing virtual method 'BC' in Qt 4?

[Marc Mutz]

On Tuesday October 9 2012, Thiago Macieira wrote:
> 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.

Sorry, that was a sloppy wording. I meant that a pure virtual function doesn't 
cause a symbol to be generated that just prints "pure virtual called" and 
calls abort(). If it did, the new implementation of the virtual function 
would just take the place of that compiler-generated function. That's not the 
case, so un-pure-ing of a virtual will add a new symbol, breaking 
forward-compatibility.

In short: https://bugreports.qt-project.org/browse/QTBUG-13230 is a WontFix 
for Qt 4.

[...]
> > 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).

IOW: no exceptions due to 4.8 being the last of the Qt 4 versions? There're 
fairly good reasons for breaking forward-compatibility here:
   https://codereview.qt-project.org/33266
though they might also be interpreted as good reasons to have a 4.9 release :)

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions