[Development] Proposing reversal of the Math3D qreal->float change

[lars.knoll at nokia.com]

On Sep 12, 2012, at 12:27 AM, ext André Pönitz <andre.poenitz at mathematik.tu-chemnitz.de> wrote:

> On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote:
>> On 11/09/2012 13:34, Thiago Macieira wrote:
>>> I propose we revert it.
>> I propose we (I) fix the affected classes in QtMultimedia
>> and Qt3D. I'm away on business this week but I will make a
>> start asap.
> 
> I believe I mentioned that before. Anyway:
> 
> I think there are (medium term) only two acceptable solutions,
> none of them perfect:
> (a) keep everything as it is (or, rather, "was")
> (b) have fully functional real/double "verticals"

(c) Turn qreal into a double everywhere

This was rejected before by some, because it might make things slower on ARM, 
but would have the advantage that it's fully source compatible with Qt 4,
solves the mess and would allow us to introduce floating point types where 
required later. 

Only minuses I can see are
(c1) the names of QXxxF classes which are double and not float based
(c2) possibly slower execution on ARM
(c3) Somewhat higher memory consumption on ARM

(c1) is not easily fixed. But (c2) seems to be less of an issue these days. At least for the 
Cortex A9 ARM claims very good double precision support. Older CPUs also have some
support through VFPv2/3. (c3) should also become less and less of an issue moving forward.

So to bring this up again: How about turning qreal into a typedef for double on all platforms and
remove the mess this way? Whereever we need (or want to use) floats, let's use them explicitly.

Cheers,
Lars

> 
> Version (a) means the current mess will go on. but it has the
> distict charme of (a.1) not breaking anyones existing code and
> (a.2) sticking to feature freeze rules.
> 
> Version (b) is somewhat closer to a proper solution, but fails
> (a.1) and (a.2). It has also the disadvantage of requiring real
> work, and therefore to tie up resources.
> 
> Even with my usual "let's break feature freeze if the feature is
> cool enough" hat on, I am tempted to lean towards (a). We are
> late in the game, and there are one or two rather essential
> things to be done for Qt 5. Having applications lock up regularly
> does not exactly sound like a strong sell to me. And while partial
> and/or extremly slow window updates might give that warm and cosy
> sense of being back in Qt 2.1 times to some, I have ths nagging
> feeling that not everyone out there will appreciate it.
> 
> So, please, make the things that were there work again, and do
> not open up new construction sites. And yes, that may mean
> postpone stuff to Qt 6 (or maybe convincing the Chief in a year
> or two that having a QT_NO_COMPATIBILITY would be a feasible
> approach)
> 
> Andre'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development