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