[Development] Changing qreal to a float

andre.poenitz at nokia.com andre.poenitz at nokia.com
Mon Feb 20 16:44:50 CET 2012

Thiago Macieira wrote:
> I also thought we had agreed that QRectF should be float on all platforms 

This part is fine with me.

> [...] and we don't need double-precision geometric classes anyway.

Such opinions have been voiced, there was, however, no consensus, at least
not in the '"we" == "all Qt users"' case. I am pretty sure I mentioned by now
several times that this will break all desktop applications that went "all Qt" and 
rely on double precision coordinates for maps. And yes, such beasts do exist.

> > I have no strong opinion on which of (a) or (b) to choose, all I want to
>> make sure is that we will neither force people to use doubles on ARM, even
>> if they don't need it, nor force people currently relying on precise
>> coordinates to use floats.

>I don't think we can achieve that.

We can achieve that by a simple typedef float qreal, either unconditional (thereby
leaving it to the user to change the typedef and re-compile - which is an acceptable
price to an otherwise completely broken application/lost investment), or make
it depending on a configure switch. (More work, but a "proper" solution
for the unlikely case that someone needs doubles _and_ uses a unmodified
version of Qt)

> My proposal is (in-order):
> 1) replace qreal with double where it should have been double all along
> (interfacing with system APIs that have double)
> 2) replace qreal everywhere else with float
> 3) remove the #ifdef QT_COORD_TYPE check in qglobal.h
> 4) add Q_DECL_DEPRECATED to the two typedef definitions of qreal and wrap them
> #  if defined(QT_NO_FPU) || defined(QT_ARCH_ARM) || defined(QT_ARCH_WINDOWSCE)
> Q_DECL_DEPRECATED typedef float qreal;
> #  else
> Q_DECL_DEPRECATED typedef double qreal;
> #  endif
> #endif
> 5) (optional) add QRectD & family

If all five steps are taken - fine. This would also mostly equivalent to b).

If we stop somewhere between 2) and 4) it is not fine as there won't be 
the "double polygon".

1) alone is ok, can/should be done in any case.


More information about the Development mailing list