> From: "lars.kn...@nokia.com" <lars.kn...@nokia.com> > On 2/16/12 6:21 PM, "ext Girish Ramakrishnan" > <gir...@forwardbias.in> > wrote: > >> Hi Lars, >> >> On Thu, Feb 16, 2012 at 5:03 AM, <lars.kn...@nokia.com> wrote: >>> On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" > <dange...@gmail.com> wrote: >>> >>>> On 15 February 2012 22:56, Sean Harmer <s...@theharmers.co.uk> > wrote: >>>>> On 15/02/2012 11:53, andre.poen...@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. > > 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.
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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
