[Development] Changing qreal to a float

1,500 views
Skip to first unread message

gunnar...@nokia.com

unread,
Feb 15, 2012, 2:38:44 AM2/15/12
to devel...@qt-project.org
For some time we have wanted to unify the behavior of qreal on desktop and embedded. Currently, qreal is defined to be double on desktop and to a float on embedded.

The reasons for unifying are:

- Using "double" is pure waste for a lot of use cases. QRectF, QPointF, QPainter, QPolygonF, OpenGL, QMouseEvent, QTouchEvent, to name a few. None of these require the precision offered by double precision floating point.

- Predictable behavior on across desktop and device. In the past we have had a few cases where things fell apart when run on embedded because the reduced precision. These were fixed, but they would have been immediately caught during development if they were the same.

- For specific use cases were higher precision floats are required, double can still be used. Both inside and outside the Qt libraries.

Our initial idea was to change "qreal" to "double" to avoid any potential regression but the impact on size combined with the fact that the added precision is almost never needed changed our minds (https://bugreports.qt-project.org/browse/QTBUG-23758)

The only questionable use case is geolocation. We know for a fact that floats have limitations in this area and both Qt3D and QtLocation make use of QVector[2|3|4]D and QMatrix4x4 which will now be a float. However, this is no worse (for device) than it already is, so any use case that fails and needs work will now be found early in the development cycle as opposed to during device testing.

Unless there are any objections that I have not yet covered, I will go ahead with this change.

cheers,
Gunnar
_______________________________________________
Development mailing list
Devel...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Thiago Macieira

unread,
Feb 15, 2012, 3:26:31 AM2/15/12
to devel...@qt-project.org
On quarta-feira, 15 de fevereiro de 2012 07.38.44, gunnar...@nokia.com
wrote:

> Our initial idea was to change "qreal" to "double" to avoid any potential
> regression but the impact on size combined with the fact that the added
> precision is almost never needed changed our minds
> (https://bugreports.qt-project.org/browse/QTBUG-23758)

There is one reason for choosing double though: it can store any 32-bit
integer without loss of precision. So doubles can be used to pass around pixel
coordinates that are 32-bit integers. That's the reason Wayland chose to use
it for all coordinates.

Float has 24 bits of mantissa precision, which is enough for 16777216x16777216
pixels. Probably good enough I'd say.

I think the most important thing is to unify the definition. Every time I met
someone from Canonical, they asked me about it because trying to build Qt-
based software on ARM revealed lots of float-double mistakes.

Note: changing qreal to float is source-incompatible and requires manual fixups
where it breaks. But it's not silent.

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

signature.asc

Kent Hansen

unread,
Feb 15, 2012, 3:24:34 AM2/15/12
to devel...@qt-project.org

Great. This would allow us to get rid of various hacks for qreal in the
meta-type system as well.

Kent

Jedrzej Nowacki

unread,
Feb 15, 2012, 3:27:33 AM2/15/12
to devel...@qt-project.org

Great! I'll be abe to remove workarounds for this issue from QMetaType :-)


Cheers,

Jędrek

lars....@nokia.com

unread,
Feb 15, 2012, 3:49:31 AM2/15/12
to thiago....@intel.com, devel...@qt-project.org
On 2/15/12 9:26 AM, "ext Thiago Macieira" <thiago....@intel.com>
wrote:

>On quarta-feira, 15 de fevereiro de 2012 07.38.44,
>gunnar...@nokia.com
>wrote:
>> Our initial idea was to change "qreal" to "double" to avoid any
>>potential
>> regression but the impact on size combined with the fact that the added
>> precision is almost never needed changed our minds
>> (https://bugreports.qt-project.org/browse/QTBUG-23758)
>
>There is one reason for choosing double though: it can store any 32-bit
>integer without loss of precision. So doubles can be used to pass around
>pixel
>coordinates that are 32-bit integers. That's the reason Wayland chose to
>use
>it for all coordinates.
>
>Float has 24 bits of mantissa precision, which is enough for
>16777216x16777216
>pixels. Probably good enough I'd say.
>
>I think the most important thing is to unify the definition. Every time I
>met
>someone from Canonical, they asked me about it because trying to build Qt-
>based software on ARM revealed lots of float-double mistakes.
>
>Note: changing qreal to float is source-incompatible and requires manual
>fixups
>where it breaks. But it's not silent.

I don't think it'll break too many places though, so I'm not too worried
about the change.

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.

Cheers,
Lars

Thiago Macieira

unread,
Feb 15, 2012, 4:28:44 AM2/15/12
to devel...@qt-project.org
On quarta-feira, 15 de fevereiro de 2012 08.49.31, lars....@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.

signature.asc

lars....@nokia.com

unread,
Feb 15, 2012, 4:58:05 AM2/15/12
to thiago....@intel.com, devel...@qt-project.org
On 2/15/12 10:28 AM, "ext Thiago Macieira" <thiago....@intel.com>
wrote:

>On quarta-feira, 15 de fevereiro de 2012 08.49.31, lars....@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.

Yes, some template code will break.


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

Yes.


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

We will in any case break either code written for x86 or code written for
arm/devices.

Given that using float everywhere makes most of our data structures
smaller, matches with OpenGL, as well as significantly improves
performance on many systems makes me believe we should go for float.

Craig...@csiro.au

unread,
Feb 15, 2012, 6:02:10 AM2/15/12
to lars....@nokia.com, devel...@qt-project.org

There's one case I don't think anyone has mentioned yet, that being where user code has adopted qreal for their own purposes (for better or worse). In such cases, the code may only ever have been intended for desktop (many apps are written just for desktop), so in such cases I would find it reasonable that a qreal == double assumption might hold. Regardless of whether that is smart or not, I could easily believe there would be code out there doing that with an implicit or explicit assumption that it will equate to at least a double.

With that in mind, is there anything against making qreal deprecated for Qt5.0 and anywhere qreal appears in the Qt API, explicitly change it to float instead? That would allow qreal to remain with the behaviour it has now for user code, but all Qt code would switch over to using float as has been indicated as desirable in this discussion thread. You'd still get compiler warnings, etc. about type mismatches where relevant. Anyone see a problem with this approach? It would seem to be more source compatible than simply changing qreal to float.


--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

Olivier Goffart

unread,
Feb 15, 2012, 6:11:27 AM2/15/12
to devel...@qt-project.org, Craig...@csiro.au

Then they can do s/qreal/double/g in their code.

>
> With that in mind, is there anything against making qreal deprecated for
> Qt5.0 and anywhere qreal appears in the Qt API, explicitly change it to
> float instead? That would allow qreal to remain with the behaviour it has
> now for user code, but all Qt code would switch over to using float as has
> been indicated as desirable in this discussion thread. You'd still get
> compiler warnings, etc. about type mismatches where relevant. Anyone see a
> problem with this approach? It would seem to be more source compatible than
> simply changing qreal to float.

I was about to suggest exactly the same.
Then I tought about Qt has its own typedef for quintptr and quint64 and what
not, so we could as well keep qreal.
(But i'm far from being opposed, but then we can also deprecate all the other
ones)

lars....@nokia.com

unread,
Feb 15, 2012, 6:26:15 AM2/15/12
to oli...@woboq.com, devel...@qt-project.org, Craig...@csiro.au

Deprecating qreal and making things explicit in Qt is IMO a good idea. We
don't need any typedef, as float and double are actually the same size on
all our supported platforms (4 and 8 bytes).

Cheers,
Lars

andre....@nokia.com

unread,
Feb 15, 2012, 6:53:39 AM2/15/12
to gunnar...@nokia.com, devel...@qt-project.org

> Sletta Gunnar (Nokia-MP/Oslo) wrote:
> - Using "double" is pure waste for a lot of use cases. QRectF, QPointF, QPainter, QPolygonF,
> OpenGL, QMouseEvent, QTouchEvent, to name a few. None of these require the precision
> offered by double precision floating point.

Whether having doubles in a QPolygonF or a QRectF is necessary depends on what you are doing with it. If you restrict it to the the current Qt-internal use cases, 'float' is possibly fine, if you use it for general coordinate handling in, say, GIS it is certainly not.

> The only questionable use case is geolocation. We know for a fact that floats have limitations
> in this area and both Qt3D and QtLocation make use of QVector[2|3|4]D and QMatrix4x4 which
> will now be a float. However, this is no worse (for device) than it already is,

It won't be worse in the _embedded_ case (and even there only for the embedded cases that did not use a custom build of Qt with hard-coded 'double' for qreal). Right...

I seem to remember we had this kind of discussion in ~2006 already, and back then the resolution was to have "double" at least on the desktop side to cover the GIS cases. Sending someone to the wrong side of a 100m wide river just because the navigation system insisted on using single precision float seemed inacceptable at that time.

Anyway. It's probably better to go for any kind of uniformity. If that's single precision, it should be made clear that QPolygonF/QRectF are not meant for applications needing "polygons" in general. Maybe one should consider adding some QPolygonD/QRectD/... later to get the functionality back. Until these exist, it might be worthwhile to keep the (then unconditional) typedef though, to allow easy creation of custom builds of Qt with double precision coordinates.

Andre'

Thiago Macieira

unread,
Feb 15, 2012, 7:01:12 AM2/15/12
to devel...@qt-project.org
On quarta-feira, 15 de fevereiro de 2012 12.11.27, Olivier Goffart wrote:
> Then I tought about Qt has its own typedef for quintptr and quint64 and what
> not, so we could as well keep qreal.
> (But i'm far from being opposed, but then we can also deprecate all the
> other ones)

Those have other reasons for being.

qint64 exists because it's "long long" on most platforms and compilers, except
for MSVC. On that case, it's __int64. The standard type "long long" is
available only on C++11.

quintptr has no standard type to match. qptrdiff has one: ptrdiff_t. The closest
to quintptr is size_t. That one has a different problem though: it's not
exactly the same type as our quint64, since GCC defines it to "unsigned long",
not "unsigned long long", on 64-bit platforms. We have avoided using "long" in
Qt 4, so this type would suffer from even more template issues.

Also, both size_t and ptrdiff_t require an #include.

PS: $ gcc -fsyntax-only -xc++ - <<<'long long long x;'
<stdin>:1:1: error: ‘long long long’ is too long for GCC

signature.asc

Olivier Goffart

unread,
Feb 15, 2012, 7:17:15 AM2/15/12
to devel...@qt-project.org
On Wednesday 15 February 2012 07:38:44 gunnar...@nokia.com wrote:
> The only questionable use case is geolocation. We know for a fact that
> floats have limitations in this area and both Qt3D and QtLocation make use
> of QVector[2|3|4]D and QMatrix4x4 which will now be a float. However, this
> is no worse (for device) than it already is, so any use case that fails and
> needs work will now be found early in the development cycle as opposed to
> during device testing.

Note that QVector[2|3|4]D already uses float, even on desktop (not on the
API, but as internal storage)

lars....@nokia.com

unread,
Feb 15, 2012, 7:33:18 AM2/15/12
to andre....@nokia.com, gunnar...@nokia.com, devel...@qt-project.org
On 2/15/12 12:53 PM, "ext andre....@nokia.com"
<andre....@nokia.com> wrote:

Just a small nitpick: You won't end up on the wrong side of the river. The
earth has a diameter of around 40000km. With 24 bits precision, you end up
with a jitter of just above 2m. You might get wet feet though ;-)

Cheers,
Lars

Cristian Adam

unread,
Feb 15, 2012, 7:38:51 AM2/15/12
to ext Olivier Goffart, devel...@qt-project.org
Note that QtLocation already moved away from QVector2|3D because
of this exact problem. Panning at zoom level 20 was a pain to use :)

Cheers,
Cristian.

Thiago Macieira

unread,
Feb 15, 2012, 8:45:18 AM2/15/12
to devel...@qt-project.org
On quarta-feira, 15 de fevereiro de 2012 12.33.18, lars....@nokia.com wrote:
> Just a small nitpick: You won't end up on the wrong side of the river. The
> earth has a diameter of around 40000km. With 24 bits precision, you end up
> with a jitter of just above 2m. You might get wet feet though ;-)

#define __FLT_EPSILON__ 1.19209289550781250000e-7F

Multiply that by 360 (degrees in a latitude) and we've got and error of 0.15".
Multiply it by the circumference (not the diameter) at the equator of
40,075,017 m and we have 4.77m.

That's just one coordinate. The error accumulates with successive operations.

signature.asc

BRM

unread,
Feb 15, 2012, 11:29:55 AM2/15/12
to devel...@qt-project.org
> From: "lars....@nokia.com" <lars....@nokia.com>

+1.

Ben

marius.st...@nokia.com

unread,
Feb 15, 2012, 12:07:28 PM2/15/12
to thiago....@intel.com, devel...@qt-project.org
On 15/02/2012 07:45, ext Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2012 12.33.18, lars....@nokia.com wrote:
>> Just a small nitpick: You won't end up on the wrong side of the river. The
>> earth has a diameter of around 40000km. With 24 bits precision, you end up
>> with a jitter of just above 2m. You might get wet feet though ;-)
>
> #define __FLT_EPSILON__ 1.19209289550781250000e-7F
>
> Multiply that by 360 (degrees in a latitude) and we've got and error of 0.15".
> Multiply it by the circumference (not the diameter) at the equator of
> 40,075,017 m and we have 4.77m.
>
> That's just one coordinate. The error accumulates with successive operations.

If it makes a difference:

- MySQL's spatial extension represents coordinates in double-percision
(8 bytes).
http://dev.mysql.com/doc/refman/5.0/en/gis-class-geometry.html

- SQLServer used to use 27bits in their calculations, giving "less than
10cm on a line between the equator and the North Pole (10,000km).", but
they are now increasing that to 48bits, giving sub-millimeteric precision.

http://connect.microsoft.com/SQLServer/feedback/details/580254/spatial-operations-are-done-with-a-low-precision-causing-troubles-in-the-returned-data

- Who knows what Oracle does. Their documentation is confusing at best.
Probably because they support a multitude of coordinate systems. Their
recommendation is not to use tolerances lower than 5 cm though.

http://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_intro.htm#autoId9

:-)

--
.marius

Sean Harmer

unread,
Feb 15, 2012, 4:56:17 PM2/15/12
to devel...@qt-project.org
On 15/02/2012 11:53, andre....@nokia.com wrote:
> Anyway. It's probably better to go for any kind of uniformity. If that's single precision, it should be made clear that QPolygonF/QRectF are not meant for applications needing "polygons" in general. Maybe one should consider adding some QPolygonD/QRectD/... later to get the functionality back. Until these exist, it might be worthwhile to keep the (then unconditional) typedef though, to allow easy creation of custom builds of Qt with double precision coordinates.

Why not make these classes into templates and have typedefs for the
float and double cases? It always confused me why QVector<n>D mixed
qreals and floats.

Sean


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Girish Ramakrishnan

unread,
Feb 16, 2012, 2:01:50 AM2/16/12
to lars....@nokia.com, Craig...@csiro.au, devel...@qt-project.org
Hi,

Just adding a +1 for this.

I think changing qreal to float will result in subtle porting bugs:
like when a Qt4 QDataStream (a double) is read by Qt5 (which is now
suddenly float).

Girish

Robin Burchell

unread,
Feb 16, 2012, 2:28:22 AM2/16/12
to Girish Ramakrishnan, devel...@qt-project.org, Craig...@csiro.au
On Thu, Feb 16, 2012 at 8:01 AM, Girish Ramakrishnan
<gir...@forwardbias.in> wrote:
> I think changing qreal to float will result in subtle porting bugs:
> like when a Qt4 QDataStream (a double) is read by Qt5 (which is now
> suddenly float).

Huh? QDataStream doesn't have any stream operators for qreal, does it?
The documentation doesn't list any at least...

Thiago Macieira

unread,
Feb 16, 2012, 3:17:35 AM2/16/12
to devel...@qt-project.org
On quinta-feira, 16 de fevereiro de 2012 08.28.22, Robin Burchell wrote:
> On Thu, Feb 16, 2012 at 8:01 AM, Girish Ramakrishnan
>
> <gir...@forwardbias.in> wrote:
> > I think changing qreal to float will result in subtle porting bugs:
> > like when a Qt4 QDataStream (a double) is read by Qt5 (which is now
> > suddenly float).
>
> Huh? QDataStream doesn't have any stream operators for qreal, does it?
> The documentation doesn't list any at least...

No, but it does have them for doubles and floats. But see
QDataStream::floatingPointPrecision().

signature.asc

Giuseppe D'Angelo

unread,
Feb 16, 2012, 6:16:27 AM2/16/12
to devel...@qt-project.org
On 15 February 2012 22:56, Sean Harmer <s...@theharmers.co.uk> wrote:
> On 15/02/2012 11:53, andre....@nokia.com wrote:
>> Anyway. It's probably better to go for any kind of uniformity. If that's single precision, it should be made clear  that QPolygonF/QRectF are not meant for applications needing "polygons" in general. Maybe one should consider adding some QPolygonD/QRectD/... later to get the functionality back. Until these exist, it might be worthwhile to keep the (then unconditional) typedef though, to allow easy creation of custom builds of Qt with double precision coordinates.
>
> Why not make these classes into templates and have typedefs for the
> float and double cases? It always confused me why QVector<n>D mixed
> qreals and floats.

I agree, although typedefs will unfortunately break all forward declarations...

--
Giuseppe D'Angelo

lars....@nokia.com

unread,
Feb 16, 2012, 8:03:42 AM2/16/12
to dang...@gmail.com, devel...@qt-project.org
On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" <dang...@gmail.com> wrote:

>On 15 February 2012 22:56, Sean Harmer <s...@theharmers.co.uk> wrote:
>> On 15/02/2012 11:53, andre....@nokia.com wrote:
>>> Anyway. It's probably better to go for any kind of uniformity. If
>>>that's single precision, it should be made clear that QPolygonF/QRectF
>>>are not meant for applications needing "polygons" in general. Maybe one
>>>should consider adding some QPolygonD/QRectD/... later to get the
>>>functionality back. Until these exist, it might be worthwhile to keep
>>>the (then unconditional) typedef though, to allow easy creation of
>>>custom builds of Qt with double precision coordinates.
>>
>> Why not make these classes into templates and have typedefs for the
>> float and double cases? It always confused me why QVector<n>D mixed
>> qreals and floats.
>
>I agree, although typedefs will unfortunately break all forward
>declarations...

That would break quite a bit of code, so I'm against it.

It's not a big deal to simply add the QRectD, etc. types if required.

In any case, here's the patch to close the issue:
http://codereview.qt-project.org/16551

Cheers,
Lars

Gábor Lehel

unread,
Feb 16, 2012, 9:46:43 AM2/16/12
to lars....@nokia.com, devel...@qt-project.org
On Thu, Feb 16, 2012 at 2:03 PM, <lars....@nokia.com> wrote:
> On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" <dang...@gmail.com> wrote:
>
>>On 15 February 2012 22:56, Sean Harmer <s...@theharmers.co.uk> wrote:
>>> Why not make these classes into templates and have typedefs for the
>>> float and double cases? It always confused me why QVector<n>D mixed
>>> qreals and floats.
>>
>>I agree, although typedefs will unfortunately break all forward
>>declarations...
>
> That would break quite a bit of code, so I'm against it.
>
> It's not a big deal to simply add the QRectD, etc. types if required.

You could use inheritance:

struct QRectD: public QRectT<double>
{
...forwarding constructors...
};

For the forwarding constructors you could either write them out
manually, which is a chore (but considerably less than doing it for
the whole class), or write template constructors for each arity at the
price of worse error messages. Possibly you could automate the whole
thing with a macro. The problem you can run into is that QList<
QRectT<double> > and QList<QRectD> would no longer be compatible, I'm
not sure if there are others.

Girish Ramakrishnan

unread,
Feb 16, 2012, 12:21:34 PM2/16/12
to lars....@nokia.com, devel...@qt-project.org
Hi Lars,

On Thu, Feb 16, 2012 at 5:03 AM, <lars....@nokia.com> wrote:
> On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" <dang...@gmail.com> wrote:
>
>>On 15 February 2012 22:56, Sean Harmer <s...@theharmers.co.uk> wrote:
>>> On 15/02/2012 11:53, andre....@nokia.com wrote:
>>>> Anyway. It's probably better to go for any kind of uniformity. If
>>>>that's single precision, it should be made clear  that QPolygonF/QRectF
>>>>are not meant for applications needing "polygons" in general. Maybe one
>>>>should consider adding some QPolygonD/QRectD/... later to get the
>>>>functionality back. Until these exist, it might be worthwhile to keep
>>>>the (then unconditional) typedef though, to allow easy creation of
>>>>custom builds of Qt with double precision coordinates.
>>>
>>> Why not make these classes into templates and have typedefs for the
>>> float and double cases? It always confused me why QVector<n>D mixed
>>> qreals and floats.
>>
>>I agree, although typedefs will unfortunately break all forward
>>declarations...
>
> That would break quite a bit of code, so I'm against it.
>
> It's not a big deal to simply add the QRectD, etc. types if required.
>
> In any case, here's the patch to close the issue:
> http://codereview.qt-project.org/16551
>

I thought we were agreeing upon deprecating qreal (i.e leave it as-is)
and use float and double explicitly inside Qt. At least, that's what I
+1d for :) The patch above changes qreal and doesn't deprecate it.

Girish

Olivier Goffart

unread,
Feb 16, 2012, 1:35:37 PM2/16/12
to devel...@qt-project.org

Can be done in another commit,
One after the massive s/qreal/float/g in the code.
If we really want that...
(That will not make cherry picking to/from 4.8 patch easier.)

lars....@nokia.com

unread,
Feb 16, 2012, 1:36:52 PM2/16/12
to gir...@forwardbias.in, devel...@qt-project.org
On 2/16/12 6:21 PM, "ext Girish Ramakrishnan" <gir...@forwardbias.in>
wrote:

We need to do this in steps. Right now, this would break signal/slot
connections wherever a real type is being used (because of the string
based matching). Kent is working on improvements to the metaobject system
(see http://codereview.qt-project.org/#change,14763). Once that is in I
can do the s/qreal/float/ in all of Qt without breaking connections that
still use qreal for arguments because the new format stores the actual
type and not the string.

But the patch above ensures we have the right binary format for qreal's,
and changing over to use float in the method signature is binary
compatible (once we don't match on strings in connect() anymore).

Cheers,
Lars

andre....@nokia.com

unread,
Feb 16, 2012, 1:45:56 PM2/16/12
to devel...@qt-project.org
Olivier Goffart wrote:
> > I thought we were agreeing upon deprecating qreal (i.e leave it as-is)
> > and use float and double explicitly inside Qt. At least, that's what I
> > +1d for :) The patch above changes qreal and doesn't deprecate it.
>
> Can be done in another commit,
> One after the massive s/qreal/float/g in the code.
> If we really want that...

The s/qreal/float/g cannot be undone easily for custom builds, so it should
only happen if there's a way to reproduce currently existing functionality
(e.g. by adding QRectD classes, possibly conditional on some QT_NO_*
or similar)

Andre'

BRM

unread,
Feb 16, 2012, 1:48:03 PM2/16/12
to lars....@nokia.com, devel...@qt-project.org
> From: "lars....@nokia.com" <lars....@nokia.com>

The concerns are not the signals/slots. Yes, that is one aspect.
The concern is other code that uses qreal - e.g. people embedding it in binary protocols, or using it in printf()'s, etc.
The vast majority of Qt is probably in the desktop arena, and there qreal is a double; and it's probably relied on that way.
There have also been numerous other concerns raised in this thread about why it is not a good idea to simply make qreal a float.

I agree that the better approach is to simply deprecate qreal and use float and double explicitly instead.
Leave qreal in there for now using its existing functionality; mark it deprecated; and in then in 6.0 remove it entirely. (I doubt that could be done in a 5.x point release.)
If anything, the metaobject system should printout warnings about qreal being deprecated when used in a signal/slot; the build system probably should too.

Ben

maurice.k...@nokia.com

unread,
Feb 17, 2012, 2:10:09 AM2/17/12
to oli...@woboq.com, devel...@qt-project.org

I assume you meant subsequent commits to be cherry-picked, not the qreal change itself right? That simply cannot go into 4.8 as it is far too massive change in itself.

BR,
Maurice

joao.a...@nokia.com

unread,
Feb 17, 2012, 6:26:50 AM2/17/12
to bm_wi...@yahoo.com, lars....@nokia.com, devel...@qt-project.org
Ben wrote:
> The concerns are not the signals/slots. Yes, that is one aspect.
> The concern is other code that uses qreal - e.g. people embedding it
> in binary protocols, or using it in printf()'s, etc.
> The vast majority of Qt is probably in the desktop arena, and there
> qreal is a double; and it's probably relied on that way.
> There have also been numerous other concerns raised in this thread
> about why it is not a good idea to simply make qreal a float.
>
> I agree that the better approach is to simply deprecate qreal and use
> float and double explicitly instead.
> Leave qreal in there for now using its existing functionality; mark it
> deprecated; and in then in 6.0 remove it entirely. (I doubt that could
> be done in a 5.x point release.)
> If anything, the metaobject system should printout warnings about
> qreal being deprecated when used in a signal/slot; the build system
> probably should too.

I think the even better approach, once the necessary changes are done
inside Qt and things settle down, is to drop qreal completely. Don't
pick float or real, don't define it. Or typedef it to some dummy type:

class qreal_IsNoMore {};
typedef qreal_IsNoMore qreal;

Force users of qreal to make a conscious decision on what they meant to
use. Less error-prone, less chances for silent breakages.

I think Qt 5.0 is a perfect time to fix the broken concept of qreal,
there's no point in letting something like this linger on until Qt 6.
(Is it even possible to *deprecate* a typedef?).

Cheers,


João

Atlant Schmidt

unread,
Feb 17, 2012, 6:39:08 AM2/17/12
to joao.a...@nokia.com, bm_wi...@yahoo.com, lars....@nokia.com, devel...@qt-project.org
João:

> I think the even better approach, once the necessary changes are done
> inside Qt and things settle down, is to drop qreal completely. Don't
> pick float or real, don't define it. Or typedef it to some dummy type:
>
> class qreal_IsNoMore {};
> typedef qreal_IsNoMore qreal;
>
> Force users of qreal to make a conscious decision on what they meant to
> use. Less error-prone, less chances for silent breakages.

The problem with this approach is that one may have
a multi-platform application developed in 4.x that
wrote QReal data to a file and now the app is up-
graded to Qt 5.x; the QReal data is still there in
the user's files and it is not necessarily float
*OR* double; it is whichever size any given platform
implementation used for QReal.

If QReal is simply deprecated, the Qt 5.x version of
the app remains data compatible with the old files with
no work on the developer's part. But if QReal entirely
disappears, the developer will have to write nasty code
that figures out, on each supported platform, whether
the old QReal data should be interpreted as floats or
doubles. This sounds quite error-prone.

Atlant

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

lars....@nokia.com

unread,
Feb 17, 2012, 6:58:46 AM2/17/12
to asch...@dekaresearch.com, joao.a...@nokia.com, bm_wi...@yahoo.com, devel...@qt-project.org
On 2/17/12 12:39 PM, "ext Atlant Schmidt" <asch...@dekaresearch.com>
wrote:

>João:
>
>> I think the even better approach, once the necessary changes are done
>> inside Qt and things settle down, is to drop qreal completely. Don't
>> pick float or real, don't define it. Or typedef it to some dummy type:
>>
>> class qreal_IsNoMore {};
>> typedef qreal_IsNoMore qreal;
>>
>> Force users of qreal to make a conscious decision on what they meant to
>> use. Less error-prone, less chances for silent breakages.
>
> The problem with this approach is that one may have
> a multi-platform application developed in 4.x that
> wrote QReal data to a file and now the app is up-
> graded to Qt 5.x; the QReal data is still there in
> the user's files and it is not necessarily float
> *OR* double; it is whichever size any given platform
> implementation used for QReal.
>
> If QReal is simply deprecated, the Qt 5.x version of
> the app remains data compatible with the old files with
> no work on the developer's part. But if QReal entirely
> disappears, the developer will have to write nasty code
> that figures out, on each supported platform, whether
> the old QReal data should be interpreted as floats or
> doubles. This sounds quite error-prone.

I think that's rather corner case. If you used QDataStream, you where
already either streaming floats of doubles. If you did that on your own to
a binary format with a badly defined type you need to take care of these
issues anyway.

On the idea itself I'd like to hear some more opinions. Removing qreal
would cause some SC breakage, but you would also get a compile error on
places that could break. Unfortunately the signal to noise ratio would
most likely be pretty bad.

Cheers,
Lars

Lincoln Ramsay

unread,
Feb 19, 2012, 9:29:07 PM2/19/12
to devel...@qt-project.org
On 02/17/2012 09:58 PM, ext lars....@nokia.com wrote:
> On the idea itself I'd like to hear some more opinions. Removing qreal
> would cause some SC breakage, but you would also get a compile error on
> places that could break. Unfortunately the signal to noise ratio would
> most likely be pretty bad.

I vote for removing it. I think that's better than making it just float
or double.

--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/

Craig...@csiro.au

unread,
Feb 19, 2012, 10:05:22 PM2/19/12
to lincoln...@nokia.com, devel...@qt-project.org

On 20/02/2012, at 1:29 PM, Lincoln Ramsay wrote:

> On 02/17/2012 09:58 PM, ext lars....@nokia.com wrote:
>> On the idea itself I'd like to hear some more opinions. Removing qreal
>> would cause some SC breakage, but you would also get a compile error on
>> places that could break. Unfortunately the signal to noise ratio would
>> most likely be pretty bad.
>
> I vote for removing it. I think that's better than making it just float
> or double.

Rather than an outright removal, perhaps it would be better to simply #ifdef it out with some way for devs to re-enable it. Thus, by default it will be as though it was no longer defined (hence prompts people to update their code), but for those who really do have qreal embedded throughout their own code base, there's an easy mechanism for them to keep their code building without hacking into Qt's headers, etc.

Just my $0.02.

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

Thiago Macieira

unread,
Feb 20, 2012, 3:01:23 AM2/20/12
to devel...@qt-project.org
On segunda-feira, 20 de fevereiro de 2012 14.05.22, Craig...@csiro.au
wrote:

> Rather than an outright removal, perhaps it would be better to simply #ifdef
> it out with some way for devs to re-enable it. Thus, by default it will be
> as though it was no longer defined (hence prompts people to update their
> code), but for those who really do have qreal embedded throughout their own
> code base, there's an easy mechanism for them to keep their code building
> without hacking into Qt's headers, etc.

Well, we could keep the current typedef for Qt 4.x compatibility mode (the
macros).

signature.asc

andre....@nokia.com

unread,
Feb 20, 2012, 4:33:27 AM2/20/12
to lincoln...@nokia.com, devel...@qt-project.org
> Ramsay Lincoln (Nokia-MP/Brisbane) wrote:
> On 02/17/2012 09:58 PM, ext lars....@nokia.com wrote:
> > On the idea itself I'd like to hear some more opinions. Removing qreal
> > would cause some SC breakage, but you would also get a compile error on
> > places that could break. Unfortunately the signal to noise ratio would
> > most likely be pretty bad.
>
> I vote for removing it. I think that's better than making it just float
> or double.

This needlessly removes existing functionality. We promised to try
hard to not do that in the Qt 4-> Qt 5 transition. Removing the typedef
is essentially a showstopper for people currently relying on double.

Leaving the 'qreal' typedef (to float...) hurts less as it can be fixed by
recompilation, and is not does not affect code size and performance
compared to a global search&replace.

Andre'

Thiago Macieira

unread,
Feb 20, 2012, 8:36:31 AM2/20/12
to devel...@qt-project.org
On segunda-feira, 20 de fevereiro de 2012 09.33.27, andre....@nokia.com
wrote:

> This needlessly removes existing functionality. We promised to try
> hard to not do that in the Qt 4-> Qt 5 transition. Removing the typedef
> is essentially a showstopper for people currently relying on double.
>
> Leaving the 'qreal' typedef (to float...) hurts less as it can be fixed by
> recompilation, and is not does not affect code size and performance
> compared to a global search&replace.

How about we leave it defined to double in all platforms and deprecate it?


$ 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]

And then proceed to use float where we need float?

signature.asc

gunnar...@nokia.com

unread,
Feb 20, 2012, 9:17:29 AM2/20/12
to thiago....@intel.com, devel...@qt-project.org

On Feb 20, 2012, at 2:36 PM, ext Thiago Macieira wrote:

> On segunda-feira, 20 de fevereiro de 2012 09.33.27, andre....@nokia.com
> wrote:
>> This needlessly removes existing functionality. We promised to try
>> hard to not do that in the Qt 4-> Qt 5 transition. Removing the typedef
>> is essentially a showstopper for people currently relying on double.
>>
>> Leaving the 'qreal' typedef (to float...) hurts less as it can be fixed by
>> recompilation, and is not does not affect code size and performance
>> compared to a global search&replace.
>
> How about we leave it defined to double in all platforms and deprecate it?

On embedded, this has the side effect that QML items would grow in size, and quite significantly as well. In addition, parts of scenegraph rendering would be slower as matrix multiplications are now double-base. These were the reasons for suggesting defining it to a float rather than a double in the first place.

cheers,
Gunnar

>
>
> $ 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]
>
> And then proceed to use float where we need float?
>
> --
> 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

andre....@nokia.com

unread,
Feb 20, 2012, 9:34:57 AM2/20/12
to thiago....@intel.com, devel...@qt-project.org
Thiago Macieira [thiago....@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...)

Thiago Macieira

unread,
Feb 20, 2012, 9:53:40 AM2/20/12
to devel...@qt-project.org
On segunda-feira, 20 de fevereiro de 2012 14.17.29, gunnar...@nokia.com
wrote:

> > How about we leave it defined to double in all platforms and deprecate it?
>
> On embedded, this has the side effect that QML items would grow in size, and
> quite significantly as well. In addition, parts of scenegraph rendering
> would be slower as matrix multiplications are now double-base. These were
> the reasons for suggesting defining it to a float rather than a double in
> the first place.

Why would it grow in size if we change the QML items to float, which was the
original intention?

You missed this line after the code:

signature.asc

Thiago Macieira

unread,
Feb 20, 2012, 10:02:09 AM2/20/12
to devel...@qt-project.org
On segunda-feira, 20 de fevereiro de 2012 14.34.57, andre....@nokia.com
wrote:

> Thiago Macieira [thiago....@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.

We can't "fix" it unless we keep the current detection logic. Since it would be
a deprecated type anyway, we could keep the logic anyway -- minus the presence
of QT_COORD_TYPE.

I also thought we had agreed that QRectF should be float on all platforms and
we don't need double-precision geometric classes anyway.

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

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

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
in QT_DEPRECATED_SINCE(5,0):

#if QT_DEPRECATED_SINCE(5, 0)
# 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

signature.asc

andre....@nokia.com

unread,
Feb 20, 2012, 10:44:50 AM2/20/12
to thiago....@intel.com, devel...@qt-project.org
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
in QT_DEPRECATED_SINCE(5,0):
> #if QT_DEPRECATED_SINCE(5, 0)
> # 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.

Andre'

Christoph Feck

unread,
Feb 20, 2012, 10:58:05 AM2/20/12
to devel...@qt-project.org
On Monday 20 February 2012 16:02:09 Thiago Macieira wrote:
> I also thought we had agreed that QRectF should be float on all
> platforms and we don't need double-precision geometric classes
> anyway.

I think we agreed on the former, but hopefully not on the latter. Many
geometric classes, such as QLineF, have functions that are used
outside rendering, so having double-precision classes are very useful
to have.

Maybe add explicit QRectS and QRectD classes, and deprecate QRectF
(same for QPointF, QLineF and friends)?

--
Christoph Feck
http://kdepepo.wordpress.com/

Marc Mutz

unread,
Feb 20, 2012, 10:15:15 AM2/20/12
to devel...@qt-project.org
On Monday February 20 2012, andre....@nokia.com wrote:
> 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...)

Why not just use a typedef:

typedef QRectImpl<int> QRect;
typedef QRectImpl<double> QRectD;
typedef QRectImpl<float> QRectF;

?

Thanks,
Marc

--
Marc Mutz <marc...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

Samuel Rødal

unread,
Feb 20, 2012, 11:04:56 AM2/20/12
to devel...@qt-project.org
On 02/20/2012 04:58 PM, ext Christoph Feck wrote:
> On Monday 20 February 2012 16:02:09 Thiago Macieira wrote:
>> I also thought we had agreed that QRectF should be float on all
>> platforms and we don't need double-precision geometric classes
>> anyway.
>
> I think we agreed on the former, but hopefully not on the latter. Many
> geometric classes, such as QLineF, have functions that are used
> outside rendering, so having double-precision classes are very useful
> to have.
>
> Maybe add explicit QRectS and QRectD classes, and deprecate QRectF
> (same for QPointF, QLineF and friends)?

This seems quite unfeasible. These classes are mainly used together with
QPainter (or scene graph for QML 2), and if those are to use float
internally, I don't really see the point with keeping double versions
around for just a subset of classes.

--
Samuel

andre....@nokia.com

unread,
Feb 20, 2012, 11:12:24 AM2/20/12
to marc...@kdab.com, devel...@qt-project.org
Marc Mutz [marc...@kdab.com]

> On Monday February 20 2012, andre....@nokia.com wrote:
> > 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...)
>
> Why not just use a typedef:
>
> typedef QRectImpl<int> QRect;
> typedef QRectImpl<double> QRectD;
> typedef QRectImpl<float> QRectF;

To keep it source compatible with code using forward-declarations of QRectF etc.
Not exactly a big issue, but no need to break it...

Andre'

Boudewijn Rempt

unread,
Feb 20, 2012, 11:20:58 AM2/20/12
to devel...@qt-project.org
On Monday 20 February 2012 Feb, Samuel Rødal wrote:
> On 02/20/2012 04:58 PM, ext Christoph Feck wrote:
> > On Monday 20 February 2012 16:02:09 Thiago Macieira wrote:
> >> I also thought we had agreed that QRectF should be float on all
> >> platforms and we don't need double-precision geometric classes
> >> anyway.
> >
> > I think we agreed on the former, but hopefully not on the latter. Many
> > geometric classes, such as QLineF, have functions that are used
> > outside rendering, so having double-precision classes are very useful
> > to have.
> >
> > Maybe add explicit QRectS and QRectD classes, and deprecate QRectF
> > (same for QPointF, QLineF and friends)?
>
> This seems quite unfeasible. These classes are mainly used together with
> QPainter (or scene graph for QML 2),

Er, I don't think you can put it that way. Those classes were public api in Qt and are used for all kinds of purposes in all kinds of applications. Frankly, this discussion has me dreading the Qt4->Qt5 move... Not just my pet application, Krita, will be affected (1), but customer's applications as well. And those don't ship with a custom-built Qt either.


> and if those are to use float
> internally, I don't really see the point with keeping double versions
> around for just a subset of classes.

Well, Qt is a library, a platform -- and that means that you cannot predict how and when classes and things like qreal will be used, and that if something is changed there, it _will_ mean a porting effort, potentially a big one. Heck, we haven't even really recovered from the previous porting from Qt3 to Qt4!

And anything you change can have huge consequences: I know of one application that was hit by optimizations in QPainter between Qt 4.5 and Qt 4.6 where a huge part of the core engine had to be rewritten.

1) 8389 instances of qreal, 2845 of QRectF, 6601 of QPointF, 253 of QLineF.
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

Thiago Macieira

unread,
Feb 20, 2012, 11:38:42 AM2/20/12
to devel...@qt-project.org
On segunda-feira, 20 de fevereiro de 2012 16.12.24, andre....@nokia.com
wrote:

> To keep it source compatible with code using forward-declarations of QRectF
> etc. Not exactly a big issue, but no need to break it...

To keep source compatibility with forward declarations, you need:

class QRect$SUFFIX: public QBasicRect<$TYPE>
{
#ifdef Q_COMPILER_INHERITING_CONSTRUCTORS
using QBasicRect<$TYPE>::QBasicRect;
#else
/* insert here the constructors */
#endif
};

signature.asc

Olivier Goffart

unread,
Feb 20, 2012, 11:47:49 AM2/20/12
to devel...@qt-project.org, Thiago Macieira
On Monday 20 February 2012 17:38:42 Thiago Macieira wrote:
> On segunda-feira, 20 de fevereiro de 2012 16.12.24, andre....@nokia.com
>
> wrote:
> > To keep it source compatible with code using forward-declarations of
> > QRectF etc. Not exactly a big issue, but no need to break it...
>
> To keep source compatibility with forward declarations, you need:
>
> class QRect$SUFFIX: public QBasicRect<$TYPE>
> {
> #ifdef Q_COMPILER_INHERITING_CONSTRUCTORS
> using QBasicRect<$TYPE>::QBasicRect;
> #else
> /* insert here the constructors */
> #endif
> };

And add some constructor and functions such as
QRect QRectF::toRect()
QRectF::QRectF(const QRect)
explicit QRectF::QRectF(const QRectD)

Samuel Rødal

unread,
Feb 20, 2012, 12:09:31 PM2/20/12
to devel...@qt-project.org
On 02/20/2012 05:20 PM, ext Boudewijn Rempt wrote:
> On Monday 20 February 2012 Feb, Samuel Rødal wrote:
>> On 02/20/2012 04:58 PM, ext Christoph Feck wrote:
>>> On Monday 20 February 2012 16:02:09 Thiago Macieira wrote:
>>>> I also thought we had agreed that QRectF should be float on all
>>>> platforms and we don't need double-precision geometric classes
>>>> anyway.
>>>
>>> I think we agreed on the former, but hopefully not on the latter. Many
>>> geometric classes, such as QLineF, have functions that are used
>>> outside rendering, so having double-precision classes are very useful
>>> to have.
>>>
>>> Maybe add explicit QRectS and QRectD classes, and deprecate QRectF
>>> (same for QPointF, QLineF and friends)?
>>
>> This seems quite unfeasible. These classes are mainly used together with
>> QPainter (or scene graph for QML 2),
>
> Er, I don't think you can put it that way. Those classes were public api in Qt and are used for all kinds of purposes in all kinds of applications. Frankly, this discussion has me dreading the Qt4->Qt5 move... Not just my pet application, Krita, will be affected (1), but customer's applications as well. And those don't ship with a custom-built Qt either.

QLineF / QRectF being split into single / double precision -> QTransform
/ QMatrix4x4 need the same split, since those operate on QLineF / QRectF.

And thus QVector2D, QVector3D, QVector4D, and QQuaternion also need two
versions. Should we name those QVector3DS / QVector3DD etc?

I'm just saying it's infeasible and ugly to have two floating point
versions of each class, I'm not saying we should drop double precision
support on desktop. Maybe it's better to keep qreal the way it is (Apple
uses CGFloat which works in a similar way), or to make public facing
classes use double regardless, and only use single precision floating
point in the implementation on embedded CPUs. Although, the latter might
come with a significant performance cost.

These complications make me lean toward just keeping qreal the way it is...

--
Samuel

João Abecasis

unread,
Feb 20, 2012, 12:14:46 PM2/20/12
to ext Boudewijn Rempt, devel...@qt-project.org

Boudewijn Rempt wrote:
> Well, Qt is a library, a platform -- and that means that you cannot predict how and when classes and things like qreal will be used, and that if something is changed there, it _will_ mean a porting effort, potentially a big one. Heck, we haven't even really recovered from the previous porting from Qt3 to Qt4!

Hence my suggestion: Drop qreal entirely, don't deprecate it and don't try to figure out what it should mean. We realized it was a broken concept and it plays against the C++ language we depend on.

What's the porting effort for applications that use and depend on qreal?

Application developers have to decide exactly what qreal was supposed to mean for them and typedef it to what's appropriate. It's a one-line change. They can patch Qt's qglobal.h if they ship their version of Qt, or they can add the typedef in their own code.

Libraries that depend on Qt will have to analyze the issue and make their own decision: a) jump to double or float or b) provide their own AwesomeReal, if that makes sense in their context.

It's not even a surprise or unexpected outcome if we document the issue or make sure a meaningful error is generated upon use of qreal.

The bigger porting effort doesn't come from the disappearance of qreal itselft, but from changing Qt itself to not use it as users will no longer be able to assume QRectF and whatnot use double on their platform. And no one seems to be against that.

Cheers,


João

Thiago Macieira

unread,
Feb 20, 2012, 12:20:08 PM2/20/12
to devel...@qt-project.org
On segunda-feira, 20 de fevereiro de 2012 17.47.49, Olivier Goffart wrote:
> On Monday 20 February 2012 17:38:42 Thiago Macieira wrote:
> > On segunda-feira, 20 de fevereiro de 2012 16.12.24,
> > andre....@nokia.com
> >
> > wrote:
> > > To keep it source compatible with code using forward-declarations of
> > > QRectF etc. Not exactly a big issue, but no need to break it...
> >
> > To keep source compatibility with forward declarations, you need:
> >
> > class QRect$SUFFIX: public QBasicRect<$TYPE>
> > {
> > #ifdef Q_COMPILER_INHERITING_CONSTRUCTORS
> >
> > using QBasicRect<$TYPE>::QBasicRect;
> >
> > #else
> >
> > /* insert here the constructors */
> >
> > #endif
> > };
>
> And add some constructor and functions such as
> QRect QRectF::toRect()

This one is inherited.

> QRectF::QRectF(const QRect)
> explicit QRectF::QRectF(const QRectD)

Those are the constructors I meant.

signature.asc

Mark

unread,
Feb 20, 2012, 12:27:47 PM2/20/12
to João Abecasis, devel...@qt-project.org
2012/2/20 João Abecasis <joao.a...@nokia.com>
Hi list,

Qt4 was going to have a "qt4support" module right? Why not drop it out of Qt5 and put it in the Qt4 support module?
That way users know it's deprecated and should not be used but does allow them to use it if they want.

Just my 5ct.

Regards,
Mark

Thiago Macieira

unread,
Feb 20, 2012, 12:36:21 PM2/20/12
to devel...@qt-project.org
On segunda-feira, 20 de fevereiro de 2012 18.27.47, Mark wrote:
> Qt4 was going to have a "qt4support" module right?

No, that was never the intention.

> Why not drop it out of
> Qt5 and put it in the Qt4 support module?
> That way users know it's deprecated and should not be used but does allow
> them to use it if they want.

--

signature.asc

Marc Mutz

unread,
Feb 20, 2012, 12:36:50 PM2/20/12
to devel...@qt-project.org
On Monday February 20 2012, João Abecasis wrote:
> Boudewijn Rempt wrote:
> > Well, Qt is a library, a platform -- and that means that you cannot
> > predict how and when classes and things like qreal will be used, and that
> > if something is changed there, it _will_ mean a porting effort,
> > potentially a big one. Heck, we haven't even really recovered from the
> > previous porting from Qt3 to Qt4!
>
> Hence my suggestion: Drop qreal entirely, don't deprecate it and don't try
> to figure out what it should mean. We realized it was a broken concept and
> it plays against the C++ language we depend on.
>
> What's the porting effort for applications that use and depend on qreal?
>
> Application developers have to decide exactly what qreal was supposed to
> mean for them and typedef it to what's appropriate. It's a one-line change.
> They can patch Qt's qglobal.h if they ship their version of Qt, or they can
> add the typedef in their own code.
>
> Libraries that depend on Qt will have to analyze the issue and make their
> own decision: a) jump to double or float or b) provide their own
> AwesomeReal, if that makes sense in their context.
>
> It's not even a surprise or unexpected outcome if we document the issue or
> make sure a meaningful error is generated upon use of qreal.
>
> The bigger porting effort doesn't come from the disappearance of qreal
> itselft, but from changing Qt itself to not use it as users will no longer
> be able to assume QRectF and whatnot use double on their platform. And no
> one seems to be against that.

The typedef would only help in the cases where client code actually spells
out 'qreal'. It wouldn't help in the cases where Q{Point,Rect,Size,Line}F is
used in the assumption that they work on double.s

This is the kind of talk that makes me recommend STL containers over the Qt
ones.

Please look at the numbers that Boudewijn posted in the footnote (in the mail
that you replied to) and realise that you need to keep qreal/QFooF in
deprecated peace. I, too, know of too much customer code that'd break
otherwise.

I actually love Christoph's QRect{D,S} idea. Just template the implementation
(and make QRectX a typedef, don't inherit!!) on the FP type and you can even
throw in QRectL into the mix.

Thanks,
Marc

--
Marc Mutz <marc...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

Marc Mutz

unread,
Feb 20, 2012, 12:41:45 PM2/20/12
to devel...@qt-project.org
On Monday February 20 2012, you wrote:
> > Why not just use a typedef:
> >
> >   typedef QRectImpl<int> QRect;
> >   typedef QRectImpl<double> QRectD;
> >   typedef QRectImpl<float> QRectF;
>
> To keep it source compatible with code using  forward-declarations of
> QRectF etc. Not exactly a big issue, but no need to break it...

Good point :)

--
Marc Mutz <marc...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

andre....@nokia.com

unread,
Feb 20, 2012, 1:42:06 PM2/20/12
to joao.a...@nokia.com, bo...@valdyas.org, devel...@qt-project.org
Abecasis Joao wrote:
> What's the porting effort for applications that use and depend on qreal?

The effort depends mainly on whether there will be a way to have a "double"
incarnation of the "coordinate classes".

_If_ there is a *D set (e.g. the proposed thin wrapper around a *Base<T>
then the porting effort would be limited. I'd even call it "acceptable".

If there is _no_ way to use the coordinate class with doubles the
effort will be significant as the applications would essentially have to
create the *D classes themselves, or find a substitute outside Qt.
Implementing e.g. QPolygon::intersected() on your own is no fun.

> The bigger porting effort doesn't come from the disappearance of qreal
> itselft, but from changing Qt itself to not use it as users will no longer
> be able to assume QRectF and whatnot use double on their platform.
> And no one seems to be against that.

I am not sure I parse that correctly. But to re-iterate: The main problem is
is the disappearance of the "double" instances, no matter how they are called.

Andre'

Olivier Goffart

unread,
Feb 20, 2012, 2:11:51 PM2/20/12
to devel...@qt-project.org, Thiago Macieira
On Monday 20 February 2012 18:20:08 Thiago Macieira wrote:
> On segunda-feira, 20 de fevereiro de 2012 17.47.49, Olivier Goffart wrote:
> > On Monday 20 February 2012 17:38:42 Thiago Macieira wrote:
> > > On segunda-feira, 20 de fevereiro de 2012 16.12.24,
> > > andre....@nokia.com
> > >
> > > wrote:
> > > > To keep it source compatible with code using forward-declarations of
> > > > QRectF etc. Not exactly a big issue, but no need to break it...
> > >
> > > To keep source compatibility with forward declarations, you need:
> > >
> > > class QRect$SUFFIX: public QBasicRect<$TYPE>
> > > {
> > > #ifdef Q_COMPILER_INHERITING_CONSTRUCTORS
> > >
> > > using QBasicRect<$TYPE>::QBasicRect;
> > >
> > > #else
> > >
> > > /* insert here the constructors */
> > >
> > > #endif
> > > };
> >
> > And add some constructor and functions such as
> > QRect QRectF::toRect()
>
> This one is inherited.

from?


>
> > QRectF::QRectF(const QRect)
> > explicit QRectF::QRectF(const QRectD)
>
> Those are the constructors I meant.

Thiago Macieira

unread,
Feb 20, 2012, 2:16:18 PM2/20/12
to devel...@qt-project.org
On segunda-feira, 20 de fevereiro de 2012 18.36.50, Marc Mutz wrote:
> Please look at the numbers that Boudewijn posted in the footnote (in the
> mail that you replied to) and realise that you need to keep qreal/QFooF in
> deprecated peace. I, too, know of too much customer code that'd break
> otherwise.
>
> I actually love Christoph's QRect{D,S} idea. Just template the
> implementation (and make QRectX a typedef, don't inherit!!) on the FP type
> and you can even throw in QRectL into the mix.

Maybe this then:

#if QT_DEPRECATED_SINCE(5,0)


# if defined(QT_NO_FPU) || defined(QT_ARCH_ARM) || defined(QT_ARCH_WINDOWSCE)

typedef float qreal_t;
# else
typedef double qreal_t;
# endif
Q_DECL_DEPRECATED qreal_t qreal;
#endif

template<typename T> class QBasicRect
{
...
};

typedef QBasicRect<float> QRectS;
typedef QBasicRect<double> QRectD;

class QRect : public QRect<int>
{
/* constructors */
};

#if QT_DEPRECATED_SINCE(5, 0)
Q_DECL_DEPRECATED class QRectF : public QRect<qreal_t>
{
/* constructors */
};
#endif


I personally don't like the name QBasicRect but QRect is taken already.
QRectangle would help here, but not for QPoint or QSize. Also, the S and D
suffixes are weird.

PS: bonus points for whoever guesses why I introduced qreal_t.

signature.asc

Samuel Rødal

unread,
Feb 21, 2012, 2:24:52 AM2/21/12
to devel...@qt-project.org

Well, especially the S suffix feels weird, QRectF and QRectD might not
be that confusing (although not sure how to preserve compatibility
then). OpenGL uses the same suffixes, as in glUniform2f and glUniform2d etc.

Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
const" etc. Can that be done with the typedefs proposed above, or does
it require having "QRectD QRectD::toRectD() const" as well? :)

--
Samuel

Thiago Macieira

unread,
Feb 21, 2012, 3:35:23 AM2/21/12
to devel...@qt-project.org
On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote:
> Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
> const" etc. Can that be done with the typedefs proposed above, or does
> it require having "QRectD QRectD::toRectD() const" as well?

With some template magic it can be done.

If you write:
template <class t> class QBasicRect;
typedef QBasicRect<float> QRectF;
typedef QBasicRect<double> QRectD;

Then you can't specialise QBasicRect<float or double> anymore. You can only use
the default expansion or partial specialisations that are yet to be written.
That means it's easier to add an "constexpr inline QRectD toRectD() const;" to
all classes than to just the float and integer ones.

But someone really motivated can add more magic using QEnableIf.

signature.asc

André Somers

unread,
Feb 21, 2012, 3:38:58 AM2/21/12
to devel...@qt-project.org
Op 21-2-2012 9:35, Thiago Macieira schreef:

> On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote:
>> Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
>> const" etc. Can that be done with the typedefs proposed above, or does
>> it require having "QRectD QRectD::toRectD() const" as well?
> With some template magic it can be done.
>
> If you write:
> template<class t> class QBasicRect;
> typedef QBasicRect<float> QRectF;
> typedef QBasicRect<double> QRectD;
>
> Then you can't specialise QBasicRect<float or double> anymore. You can only use
> the default expansion or partial specialisations that are yet to be written.
> That means it's easier to add an "constexpr inline QRectD toRectD() const;" to
> all classes than to just the float and integer ones.
>
> But someone really motivated can add more magic using QEnableIf.
>
Just wondering: while I think using templates for these classes is a
good idea in principle, will using such template magic as you are
suggesting here hurt compilation times, both of Qt itself and Qt
applications using these classes?

André

Thiago Macieira

unread,
Feb 21, 2012, 3:58:41 AM2/21/12
to devel...@qt-project.org
On terça-feira, 21 de fevereiro de 2012 09.38.58, André Somers wrote:
> Just wondering: while I think using templates for these classes is a
> good idea in principle, will using such template magic as you are
> suggesting here hurt compilation times, both of Qt itself and Qt
> applications using these classes?

I don't think it would be noticeable, not more so than the existing code
anyway.

Complete guess.

signature.asc

Marc Mutz

unread,
Feb 21, 2012, 3:59:49 AM2/21/12
to devel...@qt-project.org, Thiago Macieira
On Tuesday February 21 2012, Thiago Macieira wrote:
> On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote:
> > Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
> > const" etc. Can that be done with the typedefs proposed above, or does
> > it require having "QRectD QRectD::toRectD() const" as well?
>
> With some template magic it can be done.

That simply being full template specialisation? That'd duplicate quite some
code, though, yes.

> If you write:
> template <class t> class QBasicRect;
> typedef QBasicRect<float> QRectF;
> typedef QBasicRect<double> QRectD;
>
> Then you can't specialise QBasicRect<float or double> anymore. You can only
> use the default expansion or partial specialisations that are yet to be
> written. That means it's easier to add an "constexpr inline QRectD
> toRectD() const;" to all classes than to just the float and integer ones.
>
> But someone really motivated can add more magic using QEnableIf.

Specialising toRectD() to not appear in QRectD would force the same
specialisation on generic code. So my feeling is that if there's a
QBasicRect<>, then it should contain
QBasicRect<T> toBasicRect<T>() const
and convenience functions for all the existing typedefs.

A tangential question: should QRect be QBasicRect<int> (in which case it would
probably have a class invariant of right()-left()==width() instead of
width()-1 as now. If there is a plan to move to CRect semantics (not sure I'd
like that), then keeping QRect and using QRectI = QBasicRect<int> could do
the trick.

Thanks,
Marc

--
Marc Mutz <marc...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

Marc Mutz

unread,
Feb 21, 2012, 4:02:24 AM2/21/12
to devel...@qt-project.org
On Tuesday February 21 2012, André Somers wrote:
> Op 21-2-2012 9:35, Thiago Macieira schreef:
> > On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote:
> >> Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
> >> const" etc. Can that be done with the typedefs proposed above, or does
> >> it require having "QRectD QRectD::toRectD() const" as well?
> >
> > With some template magic it can be done.
> >
> > If you write:
> > template<class t> class QBasicRect;
> > typedef QBasicRect<float> QRectF;
> > typedef QBasicRect<double> QRectD;
> >
> > Then you can't specialise QBasicRect<float or double> anymore. You can
> > only use the default expansion or partial specialisations that are yet to
> > be written. That means it's easier to add an "constexpr inline QRectD
> > toRectD() const;" to all classes than to just the float and integer ones.
> >
> > But someone really motivated can add more magic using QEnableIf.
>
> Just wondering: while I think using templates for these classes is a
> good idea in principle, will using such template magic as you are
> suggesting here hurt compilation times, both of Qt itself and Qt
> applications using these classes?

One would disallow compilers to instantiate the template with C++11 extern
templates (this would be a good idea for all templates, esp. those with
arguments constrained to just a few potential types). All other compilers:
who cares? :)

Thanks,
Marc

--
Marc Mutz <marc...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

Thiago Macieira

unread,
Feb 21, 2012, 4:23:38 AM2/21/12
to devel...@qt-project.org
On terça-feira, 21 de fevereiro de 2012 10.02.24, Marc Mutz wrote:
> One would disallow compilers to instantiate the template with C++11 extern
> templates (this would be a good idea for all templates, esp. those with
> arguments constrained to just a few potential types). All other compilers:
> who cares? :)

C++98 costs more, I'm with you :-)

signature.asc

Thiago Macieira

unread,
Feb 21, 2012, 4:31:16 AM2/21/12
to devel...@qt-project.org
On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote:
> A tangential question: should QRect be QBasicRect<int> (in which case it
> would probably have a class invariant of right()-left()==width() instead
> of width()-1 as now. If there is a plan to move to CRect semantics (not
> sure I'd like that), then keeping QRect and using QRectI = QBasicRect<int>
> could do the trick.

QRect must have the same semantics as it has today. Whether we want to add a
*second* rectangle class with slightly different semantics, I'll leave up to
the implementor.

I'd rather it were part of the template. That means whoever is implementing
this template needs to add some magic for the logic for integers to be
different from the logic from FP.

In time, it's usually a good idea to have a range of [start, end) -- that is,
inclusive of the start and exclusive of the end. It's a matter of choosing the
operators right when doing comparisons. But that implies on integer quantities
that "end" is "the successor of the last valid element". That's an invariant
that the STL iterators already match.

signature.asc

Andreas Aardal Hanssen

unread,
Feb 21, 2012, 9:28:19 AM2/21/12
to Thiago Macieira, devel...@qt-project.org
2012/2/21 Thiago Macieira <thiago....@intel.com>

On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote:
> sure I'd like that), then keeping QRect and using QRectI = QBasicRect<int>
> could do the trick.
QRect must have the same semantics as it has today. Whether we want to add a
*second* rectangle class with slightly different semantics, I'll leave up to
the implementor.
 
QRect's silly semantics are one huge reason why it can make sense to obsolete it and its friends, and make new QRectangle classes that all behave the same.

I've run into numerous issues that are due to the fact that some rectangle variable's right() value is different depending on whether it's QRect or QRectF. QRect was kept this way for compatibility with Qt 3. Qt 5 should have no more such crap.

There never was any QPoly (gon), QEll (ipse), why should there be a QRect. M'just sayin'. 

(sorry if this arrives twice to the list btw)

--
Andreas Aardal Hanssen

BRM

unread,
Feb 21, 2012, 9:34:35 AM2/21/12
to devel...@qt-project.org
> From: Thiago Macieira <thiago....@intel.com>

> On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote:
>> A tangential question: should QRect be QBasicRect<int> (in which case
> it
>> would  probably have a class invariant of right()-left()==width() instead
>> of width()-1 as now. If there is a plan to move to CRect semantics (not
>> sure I'd like that), then keeping QRect and using QRectI =
> QBasicRect<int>
>> could do the trick.
>
> QRect must have the same semantics as it has today. Whether we want to add a
> *second* rectangle class with slightly different semantics, I'll leave up to
> the implementor.
>
> I'd rather it were part of the template. That means whoever is implementing
> this template needs to add some magic for the logic for integers to be
> different from the logic from FP.

Perhaps a template is not the best option?
Perhaps an abstract/virtual class that is derived from for the various classes would be better?
Each class could then have its own internal data instead.
Yes, it would mean a little more duplication in the code; but it would allow for the specialization of each class to its type.

$0.02

Ben

andre....@nokia.com

unread,
Feb 21, 2012, 9:47:52 AM2/21/12
to bm_wi...@yahoo.com, devel...@qt-project.org

BRM [bm_wi...@yahoo.com]

> Perhaps a template is not the best option?
> Perhaps an abstract/virtual class that is derived from for the various classes would be better?

Not at all.

The discuasion was initiiated by performance and size considerations.

Andre'

jan-arve...@nokia.com

unread,
Feb 21, 2012, 10:40:16 AM2/21/12
to thiago....@intel.com, and...@hanssen.name, devel...@qt-project.org

Sorry for top-posting from my N9...


I was thinking the same, but I'm afraid we can't change it, since it would cause too many subtle bugs.

The best thing I can think is to deprecate it, and add a QRectS or QRectI, but I'm not utterly convinced...


Jan-Arve


21.02.12 15:31 skrev ext Andreas Aardal Hanssen:

Thiago Macieira

unread,
Feb 21, 2012, 11:12:17 AM2/21/12
to devel...@qt-project.org
On terça-feira, 21 de fevereiro de 2012 15.40.16, jan-arve...@nokia.com
wrote:

> Sorry for top-posting from my N9...
>
>
> I was thinking the same, but I'm afraid we can't change it, since it would
> cause too many subtle bugs.

> The best thing I can think is to deprecate it, and add a QRectS or QRectI,
> but I'm not utterly convinced...

We could deprecate QRect and QRectF, and introduce a proper QRectangle. It
should be doable by means of an implicit QRect(const QRectangle<int> &)
constructor and an operator QRectangle<int>() const.

If that doesn't work, it would unfortunately mean deprecating all of the API
that uses QRect and QRectF and add new API.

But by the same token that Andreas has of subtle bugs, this change would
introduce subtle bugs in Qt code that relies on the quirky QRect behaviour.

signature.asc

Thiago Macieira

unread,
Feb 21, 2012, 11:14:05 AM2/21/12
to devel...@qt-project.org
On terça-feira, 21 de fevereiro de 2012 06.34.35, BRM wrote:
> Perhaps a template is not the best option?
> Perhaps an abstract/virtual class that is derived from for the various
> classes would be better?

Perhaps templates are not the best option, but a class with virtuals definitely
isn't. I don't think you thought your proposal through before sending...

There are simply no common methods between the classes. They may look the same
and execute similar operations, but since they operate on different data types,
they are not the same.

signature.asc
Reply all
Reply to author
Forward
0 new messages