[Development] Changing qreal to a float

[Marc Mutz]

On Monday February 20 2012, João Abecasis wrote:
> Boudewijn Rempt wrote:
> > Well, Qt is a library, a platform -- and that means that you cannot
> > predict how and when classes and things like qreal will be used, and that
> > if something is changed there, it _will_ mean a porting effort,
> > potentially a big one. Heck, we haven't even really recovered from the
> > previous porting from Qt3 to Qt4!
>
> Hence my suggestion: Drop qreal entirely, don't deprecate it and don't try
> to figure out what it should mean. We realized it was a broken concept and
> it plays against the C++ language we depend on.
>
> What's the porting effort for applications that use and depend on qreal?
>
> Application developers have to decide exactly what qreal was supposed to
> mean for them and typedef it to what's appropriate. It's a one-line change.
> They can patch Qt's qglobal.h if they ship their version of Qt, or they can
> add the typedef in their own code.
>
> Libraries that depend on Qt will have to analyze the issue and make their
> own decision: a) jump to double or float or b) provide their own
> AwesomeReal, if that makes sense in their context.
>
> It's not even a surprise or unexpected outcome if we document the issue or
> make sure a meaningful error is generated upon use of qreal.
>
> The bigger porting effort doesn't come from the disappearance of qreal
> itselft, but from changing Qt itself to not use it as users will no longer
> be able to assume QRectF and whatnot use double on their platform. And no
> one seems to be against that.

The typedef would only help in the cases where client code actually spells 
out 'qreal'. It wouldn't help in the cases where Q{Point,Rect,Size,Line}F is 
used in the assumption that they work on double.s

This is the kind of talk that makes me recommend STL containers over the Qt 
ones.

Please look at the numbers that Boudewijn posted in the footnote (in the mail 
that you replied to) and realise that you need to keep qreal/QFooF in 
deprecated peace. I, too, know of too much customer code that'd break 
otherwise.

I actually love Christoph's QRect{D,S} idea. Just template the implementation 
(and make QRectX a typedef, don't inherit!!) on the FP type and you can even 
throw in QRectL into the mix.

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