Re: [Development] Changing qreal to a float
Hi QMatrix4x4 is still qreal, which is still target depend? Is there any intention to change that? Best regards, Marco ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 QBasicRectfloat QRectF; typedef QBasicRectdouble QRectD; Then you can't specialise QBasicRectfloat 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 QBasicRectT toBasicRectT() const and convenience functions for all the existing typedefs. A tangential question: should QRect be QBasicRectint (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 = QBasicRectint could do the trick. Thanks, Marc -- Marc Mutz marc.m...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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: templateclass t class QBasicRect; typedef QBasicRectfloat QRectF; typedef QBasicRectdouble QRectD; Then you can't specialise QBasicRectfloat 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.m...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 :-) -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
2012/2/21 Thiago Macieira thiago.macie...@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 = QBasicRectint 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
From: Thiago Macieira thiago.macie...@intel.com On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote: A tangential question: should QRect be QBasicRectint (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 = QBasicRectint 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
BRM [bm_witn...@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' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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: 2012/2/21 Thiago Macieira thiago.macie...@intel.commailto:thiago.macie...@intel.com On terça-feira, 21 de fevereiro de 2012 09.59.49tel:2012%2009.59.49, Marc Mutz wrote: sure I'd like that), then keeping QRect and using QRectI = QBasicRectint 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On terça-feira, 21 de fevereiro de 2012 15.40.16, jan-arve.saet...@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 QRectangleint ) constructor and an operator QRectangleint() 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. -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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. -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On segunda-feira, 20 de fevereiro de 2012 14.05.22, craig.sc...@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). -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On Feb 20, 2012, at 2:36 PM, ext Thiago Macieira wrote:
On segunda-feira, 20 de fevereiro de 2012 09.33.27, andre.poen...@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 searchreplace.
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On segunda-feira, 20 de fevereiro de 2012 14.17.29, gunnar.sle...@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: 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 signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On segunda-feira, 20 de fevereiro de 2012 14.34.57, andre.poen...@nokia.com wrote: Thiago Macieira [thiago.macie...@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 -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On Monday February 20 2012, andre.poen...@nokia.com wrote: PS: If we agree that template class T QRectBase; class QRectF : QRectBasefloat class QRectD : QRectBasedouble 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 QRectImplint QRect; typedef QRectImpldouble QRectD; typedef QRectImplfloat QRectF; ? Thanks, Marc -- Marc Mutz marc.m...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On Monday 20 February 2012 17:38:42 Thiago Macieira wrote:
On segunda-feira, 20 de fevereiro de 2012 16.12.24, andre.poen...@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)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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.poen...@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.
--
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
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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.poen...@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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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
templatetypename T class QBasicRect
{
...
};
typedef QBasicRectfloat QRectS;
typedef QBasicRectdouble QRectD;
class QRect : public QRectint
{
/* constructors */
};
#if QT_DEPRECATED_SINCE(5, 0)
Q_DECL_DEPRECATED class QRectF : public QRectqreal_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.
--
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
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On 02/17/2012 09:58 PM, ext lars.kn...@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/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On 20/02/2012, at 1:29 PM, Lincoln Ramsay wrote: On 02/17/2012 09:58 PM, ext lars.kn...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On 2/17/12 12:39 PM, ext Atlant Schmidt aschm...@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
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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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(). -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 QVectornD mixed qreals and floats. I agree, although typedefs will unfortunately break all forward declarations... -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On Thursday 16 February 2012 09:21:34 Girish Ramakrishnan 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 QVectornD 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.) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 QVectornD 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. 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 QVectornD 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
Re: [Development] Changing qreal to a float
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 QVectornD 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On quarta-feira, 15 de fevereiro de 2012 07.38.44, gunnar.sle...@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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
Den 15. feb. 2012 08:38, skrev ext gunnar.sle...@nokia.com: 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 Great. This would allow us to get rid of various hacks for qreal in the meta-type system as well. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On 2/15/12 9:26 AM, ext Thiago Macieira thiago.macie...@intel.com wrote: On quarta-feira, 15 de fevereiro de 2012 07.38.44, gunnar.sle...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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. 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. -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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
Re: [Development] Changing qreal to a float
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' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On 2/15/12 12:53 PM, ext andre.poen...@nokia.com andre.poen...@nokia.com wrote: 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. Just a small nitpick: You won't end up on the wrong side of the river. The earth has a diameter of around 4km. With 24 bits precision, you end up with a jitter of just above 2m. You might get wet feet though ;-) Cheers, Lars 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' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On 02/15/2012 01:17 PM, ext Olivier Goffart wrote: On Wednesday 15 February 2012 07:38:44 gunnar.sle...@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) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On quarta-feira, 15 de fevereiro de 2012 12.33.18, lars.kn...@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 4km. With 24 bits precision, you end up with a jitter of just above 2m. You might get wet feet though ;-) #define __FLT_EPSILON__ 1.1920928955078125e-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. -- 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 Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
From: lars.kn...@nokia.com lars.kn...@nokia.com 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). +1. Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
On 15/02/2012 07:45, ext Thiago Macieira wrote: On quarta-feira, 15 de fevereiro de 2012 12.33.18, lars.kn...@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 4km. With 24 bits precision, you end up with a jitter of just above 2m. You might get wet feet though ;-) #define __FLT_EPSILON__ 1.1920928955078125e-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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
Hi, On Wed, Feb 15, 2012 at 3:26 AM, lars.kn...@nokia.com wrote: 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). 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Changing qreal to a float
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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
