[Development] Changing qreal to a float

[andre.poenitz at nokia.com]

Thiago Macieira [thiago.macieira at intel.com]
> [...] How about we leave it defined to double in all platforms and deprecate it?

Replacing all 'qreal' occurrences with 'double' would be a significant performance
hit for some  embedded people. Replacing all 'qreal' occurrences with 'float' spoils
the fun for some desktop people. [Replacing it with anything else would not help
at all,] so (a) leaving qreal in the code _or_ (b) immediately add QRectD/QPolygonD/...
substitutes are the only ways I see to deliver on the "you don't have to completely 
rewrite your code" promise for both sides.

What the actual typedef looks like in case (a) is rather minor in comparison, as 
is it "revertable" by a one-line-patch and a recompilation, which the affected
parties are likely to do anyway. " An unconditional typedef to float would be
acceptable, as long as changing it changes QPolygonF/.. too.

In case (b) your suggestion

  > $ gcc -xc++ -O3 -o /dev/null - <<EOF
  > __attribute__((deprecated)) typedef double qreal;
  > int main() { double x = 1.0; qreal y = x; return 0; }
  > EOF
  > <stdin>: In function ‘int main()’:
  > <stdin>:2:36: warning: ‘qreal’ is deprecated (declared at <stdin>:1) [-
  > Wdeprecated-declarations]

certainly helps user code to phase out 'qreal' quickly. 
[And I agree with the idea _as soon as there is a usable substitute_.]

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. 

As both (a) and (b) are both feasible approaches to solve the issue I don't see 
a reason to go for an approach that leaves either user group out in the rain.

Andre'

PS: If we agree that  template <class T> QRectBase;  class QRectF : QRectBase<float>
class QRectD : QRectBase<double> etc would be acceptable for 5.0 I'd try to come up
with a patch for (b). For (a) the short solution would be simply making the typedef 
unconditional, or in the luxury variant to add a configure switch (which I'd try to avoid...)