[Development] Changing qreal to a float

maurice.kalinowski at nokia.com maurice.kalinowski at nokia.com
Fri Feb 17 08:10:09 CET 2012


> >
> > On Thu, Feb 16, 2012 at 5:03 AM,  <lars.knoll at nokia.com> wrote:
> > > On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" <dangelog at gmail.com>
> wrote:
> > >>On 15 February 2012 22:56, Sean Harmer <sh at theharmers.co.uk>
> wrote:
> > >>> On 15/02/2012 11:53, andre.poenitz at 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.
> 
> 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.)

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




More information about the Development mailing list