Thiago Macieira [thiago.macie...@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...)
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
