[Development] Qt LTS & C++11 plans

[Marc Mutz]

On Thursday 02 July 2015 03:02:51 Thiago Macieira wrote:
> [*] getting a d pointer does not mean getting rid of the private members.
> See  the Qt 6 task for QDateTime, for example. It's also possible to have
> classes with no d pointer, but you need to be absolutely sure there's no
> chance of extension for the next 10 years.

I would qualify it as "add a d-pointer if you envision further extensions that 
you could implement now but choose not to." Even so, always keep in mind that 
you can always create a new type instead of extending an existing one.

Taking QColor as an example, it would have been perfectly ok (and even better 
design, imo) to start with QColorRGB8 and QColorHSV8, and when HSL support is 
added, make a new QColorHSL8, and with 16-bit support, add -16 classes. 
There's a reason QColor isn't used in low-level API (instead, QRgb is used), 
and that is its complexity (just look at op== if you don't believe).

HSL or 16-bit support can anyway not be used by an app without active code 
changes, and thus a recompile. And if you want a color type as a black-box 
pass-through, you can use QVariant, or a more specialised QAnyColor.

IMO, d-pointers should be added to polymorphic classes, because by their very 
nature, they can receive updates to behaviour without a user having to 
recompile. And else to value classes where you know there will be updates in 
the future, and having a separate class for it is not an option.

D-pointers are not called Compiler Firewalls for nothing. Just compare 
assembly generated from use of QColor (which doesn't even have a d-pointer, 
but is mostly out-of-line anyway) with that generated for QRgb.

For QColor, the optimiser is all but disabled.

And this stuff matters. No-one is using C++ to get the performance they can 
have with Java or C#. And one of the advantages of C++ is that user-defined 
types can enjoy the performance of built-in types, and don't have to _be_ a 
compiler firewall.

We have erred too much on the side of the d-pointer, in the past. We should be 
more conscious of its negative effects.

At the same time, we have been very bad at creating small classes. Maybe 
because reviews would blindly ask for a d-pointer, then? I don't know. Those 
we have are pretty good, don't get me wrong. We just have too little of them. 
QGradientStop is a QPair<qreal,QColor>. That's just lazy. It should be a 
struct { qreal step; QColor color }, or, maybe, because Q*Animation classes 
have the same need, a more generically-named { step, value }, so one can 
easily write them as templates:

   template <typename Value>
   struct QStop {
       qreal step;
       Value value;
   };
   using QGradientStop = QStop<QColor>;
   using QGraphicsItemAnimation::PositionStop = QStop<QPointF>;
   ...

Nothing of the above contradicts Thiago in any way. It's just Qt's historic 
bias to lots of pimpls that I'd like to shift.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts