[Development] Changing qreal to a float

lars.knoll at nokia.com lars.knoll at nokia.com
Fri Feb 17 12:58:46 CET 2012

On 2/17/12 12:39 PM, "ext Atlant Schmidt" <aschmidt at dekaresearch.com>

>> I think the even better approach, once the necessary changes are done
>> inside Qt and things settle down, is to drop qreal completely. Don't
>> pick float or real, don't define it. Or typedef it to some dummy type:
>>    class qreal_IsNoMore {};
>>    typedef qreal_IsNoMore qreal;
>> Force users of qreal to make a conscious decision on what they meant to
>> use. Less error-prone, less chances for silent breakages.
>  The problem with this approach is that one may have
>  a multi-platform application developed in 4.x that
>  wrote QReal data to a file and now the app is up-
>  graded to Qt 5.x; the QReal data is still there in
>  the user's files and it is not necessarily float
>  *OR* double; it is whichever size any given platform
>  implementation used for QReal.
>  If QReal is simply deprecated, the Qt 5.x version of
>  the app remains data compatible with the old files with
>  no work on the developer's part. But if QReal entirely
>  disappears, the developer will have to write nasty code
>  that figures out, on each supported platform, whether
>  the old QReal data should be interpreted as floats or
>  doubles. This sounds quite error-prone.

I think that's rather corner case. If you used QDataStream, you where
already either streaming floats of doubles. If you did that on your own to
a binary format with a badly defined type you need to take care of these
issues anyway. 

On the idea itself I'd like to hear some more opinions. Removing qreal
would cause some SC breakage, but you would also get a compile error on
places that could break. Unfortunately the signal to noise ratio would
most likely be pretty bad.


>                                Atlant
>This e-mail and the information, including any attachments, it contains
>are intended to be a confidential communication only to the person or
>entity to whom it is addressed and may contain information that is
>privileged. If the reader of this message is not the intended recipient,
>you are hereby notified that any dissemination, distribution or copying
>of this communication is strictly prohibited. If you have received this
>communication in error, please immediately notify the sender and destroy
>the original message.
>Thank you.
>Please consider the environment before printing this email.

More information about the Development mailing list