On 2/15/12 12:11 PM, "ext Olivier Goffart" <oliv...@woboq.com> wrote:
>On Wednesday 15 February 2012 22:02:10 craig.sc...@csiro.au wrote: >> On 15/02/2012, at 8:58 PM, <lars.kn...@nokia.com> >><lars.kn...@nokia.com> >wrote: >> > On 2/15/12 10:28 AM, "ext Thiago Macieira" <thiago.macie...@intel.com> >> > >> > wrote: >> >> On quarta-feira, 15 de fevereiro de 2012 08.49.31, >>lars.kn...@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. >> >> 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. > >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) 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
