Re: [Development] QQuaternion issues with new 5.5 API

2015-04-24 Thread Marc Mutz
On Friday 24 April 2015 14:32:22 Gunnar Sletta wrote:
> > While implementing qHash() overloads for gui/math3d classes,
> 
> Why are we doing this? a QHash makes very little sense me..

Well, there are are bug reports asking for qHash(QPoint), so it seems to make 
sense to _someone_ :)

Esp. for types that don't have a natural total order (=most), and thus don't / 
shouldn't have operator<, adding a qHash() overload, as long as it can be done 
(it can't for QPointF) is the only way to enable associative containers of any 
kind for that type.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] QQuaternion issues with new 5.5 API

2015-04-24 Thread Thiago Macieira
On Friday 24 April 2015 14:32:22 Gunnar Sletta wrote:
> > While implementing qHash() overloads for gui/math3d classes,
> 
> Why are we doing this? a QHash makes very little sense me..

That's besides the point. Marc could have said "I've just noticed" and the 
rest of his arguments would still be valid.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] QQuaternion issues with new 5.5 API

2015-04-24 Thread Konstantin Ritt
2015-04-24 16:33 GMT+04:00 Marc Mutz :

> Hi,
>
> While implementing qHash() overloads for gui/math3d classes, I found that
> QQuaternion gained several methods for 5.5 which I don't like:
>
> *EulerAngles():
>
> They are missing a QEulerAngles class. Instead, they deal with (float,
> float,
> float) and QVector3D. One function even returns three floats as out-
> parameters. I think my (partial) work on QDate/Time has shown just how much
> compilers don't like out parameters. The question here is how general such
> a
> QEulerAngles class should be...
>
> *AxisAndAngle()/*Axes():
>
> Same here, to a lesser extent. What bugs me most is the return-by-out-
> parameters, not so much that there's no QAxis3D class.
>
> There are several steps forward:
>
> - Create QEulerAngles as a float-only class
> - ditto, but as a template
> - ditto, but also add Q*Angle classes that have DEG/RAD hard-coded as
> template
>   arguments, with explicit conversions between, then use that in
> QEulerAngles.
>   [this likely won't happen for 5.5, though]
> - remove the methods in question for 5.5 and try again in 5.6
>
> Any opinions about which ones to take?
>

Sure I wanted to do it via introducing QAngle (which is also useful for
many other classes, even outside math3d), but that's definitely a 6.0
material; and then there is no much sense in introducing it just for
QQuaternion.

Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] QQuaternion issues with new 5.5 API

2015-04-24 Thread Konstantin Ritt
2015-04-24 16:32 GMT+04:00 Gunnar Sletta :

>
> > On 24 Apr 2015, at 14:33, Marc Mutz  wrote:
> >
> > Hi,
> >
> > While implementing qHash() overloads for gui/math3d classes,
>
> Why are we doing this? a QHash makes very little sense me..
>

Completely agreed.

Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] QQuaternion issues with new 5.5 API

2015-04-24 Thread Gunnar Sletta

> On 24 Apr 2015, at 14:33, Marc Mutz  wrote:
> 
> Hi,
> 
> While implementing qHash() overloads for gui/math3d classes,

Why are we doing this? a QHash makes very little sense me..

-
Gunnar

> I found that 
> QQuaternion gained several methods for 5.5 which I don't like:
> 
> *EulerAngles():
> 
> They are missing a QEulerAngles class. Instead, they deal with (float, float, 
> float) and QVector3D. One function even returns three floats as out-
> parameters. I think my (partial) work on QDate/Time has shown just how much 
> compilers don't like out parameters. The question here is how general such a 
> QEulerAngles class should be...
> 
> *AxisAndAngle()/*Axes():
> 
> Same here, to a lesser extent. What bugs me most is the return-by-out-
> parameters, not so much that there's no QAxis3D class.
> 
> There are several steps forward:
> 
> - Create QEulerAngles as a float-only class
> - ditto, but as a template
> - ditto, but also add Q*Angle classes that have DEG/RAD hard-coded as template
>  arguments, with explicit conversions between, then use that in QEulerAngles.
>  [this likely won't happen for 5.5, though]
> - remove the methods in question for 5.5 and try again in 5.6
> 
> Any opinions about which ones to take?
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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] QQuaternion issues with new 5.5 API

2015-04-24 Thread Marc Mutz
On Friday 24 April 2015 14:33:27 Marc Mutz wrote:
> There are several steps forward:
> 
> - Create QEulerAngles as a float-only class
> - ditto, but as a template
> - ditto, but also add Q*Angle classes that have DEG/RAD hard-coded as
> template arguments, with explicit conversions between, then use that in
> QEulerAngles. [this likely won't happen for 5.5, though]
> - remove the methods in question for 5.5 and try again in 5.6
> 
> Any opinions about which ones to take?

Of course

- do nothing

is an option, too, but clearly not the one that I'd prefer :)

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development