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 typ
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 v
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,
> floa
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
__
> 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():
>
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 us
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 float
