[Development] Changing qreal to a float

Thiago Macieira thiago.macieira at intel.com
Wed Feb 15 10:28:44 CET 2012

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.

> 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.

Which one to choose, I haven't made up my mind. 

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120215/3e73310a/attachment.sig>

More information about the Development mailing list