[Development] Changing qreal to a float

[lars.knoll at nokia.com]

On 2/15/12 12:11 PM, "ext Olivier Goffart" <olivier at woboq.com> wrote:

>On Wednesday 15 February 2012 22:02:10 Craig.Scott at csiro.au wrote:
>> On 15/02/2012, at 8:58 PM, <lars.knoll at nokia.com>
>><lars.knoll at nokia.com>
>wrote:
>> > On 2/15/12 10:28 AM, "ext Thiago Macieira" <thiago.macieira at intel.com>
>> > 
>> > wrote:
>> >> On quarta-feira, 15 de fevereiro de 2012 08.49.31,
>>lars.knoll at nokia.com
>> >> 
>> >> wrote:
>> >>> I don't think it'll break too many places though, so I'm not too
>>worried
>> >>> about the change.
>> >> 
>> >> It will. Ask Ubuntu packagers for how much work they had to put in
>>to fix
>> >> the
>> >> mismatches in KDE. We can assume that work is done, but other
>>Qt-based
>> >> software, including non-OSS software, will probably have similar
>>issues.
>> >> But,
>> >> it should be noted that they had lots of rework because the software
>>kept
>> >> on
>> >> breaking. If this change is made to all, one can assume that it will
>>not
>> >> "keep
>> >> on breaking".
>> >> 
>> >> This change by itself isn't that big. Whenever you see a template
>>error
>> >> about
>> >> no overloads for floats and doubles, you know what it is. The
>>problem is
>> >> that
>> >> this error adds up to the porting needs for software to get from Qt
>>4 to
>> >> Qt 5
>> >> and this is likely to be widespread. It will appear on the first
>> >> compilation
>> >> and you have to fix them immediately, including changing certain data
>> >> structures, in order to continue the porting.
>> > 
>> > Yes, some template code will break.
>> > 
>> >>> Choosing float has my vote, as it'll use a lot less memory and is
>>the
>> >>> right thing in the common case. It also directly maps to OpenGL
>>types.
>> >>> Let's rather use double explicitly where needed.
>> >> 
>> >> I'm not disagreeing. I'm just giving more information for the
>> >> decision-making.
>> >> 
>> >> I completely agree we should choose one or the other, not change
>> >> according to
>> >> platform. Accordingly, QT_COORD_TYPE should be removed to.
>> > 
>> > Yes.
>> > 
>> >> Which one to choose, I haven't made up my mind.
>> > 
>> > We will in any case break either code written for x86 or code written
>>for
>> > arm/devices.
>> > 
>> > Given that using  float everywhere makes most of our data structures
>> > smaller, matches with OpenGL, as well as significantly improves
>> > performance on many systems makes me believe we should go for float.
>> 
>> There's one case I don't think anyone has mentioned yet, that being
>>where
>> user code has adopted qreal for their own purposes (for better or
>>worse).
>> In such cases, the code may only ever have been intended for desktop
>>(many
>> apps are written just for desktop), so in such cases I would find it
>> reasonable that a qreal == double assumption might hold. Regardless of
>> whether that is smart or not, I could easily believe there would be code
>> out there doing that with an implicit or explicit assumption that it
>>will
>> equate to at least a double.
>
>Then they can do s/qreal/double/g  in their code.
>
>> 
>> With that in mind, is there anything against making qreal deprecated for
>> Qt5.0 and anywhere qreal appears in the Qt API, explicitly change it to
>> float instead?  That would allow qreal to remain with the behaviour it
>>has
>> now for user code, but all Qt code would switch over to using float as
>>has
>> been indicated as desirable in this discussion thread. You'd still get
>> compiler warnings, etc. about type mismatches where relevant. Anyone
>>see a
>> problem with this approach? It would seem to be more source compatible
>>than
>> simply changing qreal to float.
>
>I was about to suggest exactly the same.
>Then I tought about Qt has its own typedef for quintptr and quint64 and
>what 
>not, so we could as well keep qreal.
>(But i'm far from being opposed, but then we can also deprecate all the
>other 
>ones)

Deprecating qreal and making things explicit in Qt is IMO a good idea. We
don't need any typedef, as float and double are actually the same size on
all our supported platforms (4 and 8 bytes).

Cheers,
Lars