Degree/Radian + Real

[migileke]

Code: Select all

Ogre::Degree rotation;
rotation += 15;

This code will not compile under Ogre 1.4.8. It says that it finds no operator. Not when the 15 is int, float, double or even Ogre::Real. It will only compile if you specify whether the number is a Degree or a Radian.

However, it is very annoying to type "rotation + Degree(15)" everywhere you want to add a number to the amount of degrees. So annoying that it is actually easier to make my rotation variable an Ogre::Real and specify that it's a degree only in the actual rotation.

I would however find it a lot more logical that if you add a number to either a Degree or a Radian, that it automatically assumes that the number is of the same type as the angle.

In short, there should be an operator + for both Degree and Radian so that:
- Degree + Real is the same as Degree + Degree(Real)
- Radian + Real is the same as Radian + Radian(Real)

Or am I fundamentally wrong somewhere? It happened before so I wouldn't be suprised. Or is this already implemented in the SVN version of Ogre?

Please enlighten me
Migileke

[nullsquared]

Code: Select all

template<typename T>
Ogre::Degree &operator+=(Ogre::Degree &a, const T &b) {
    a += Ogre::Degree(b);
    return a;
}

Ogre::Degree deg(50);
deg += 25;

[migileke]

Oh, thank you.

I didn't think it would be possible without rewriting the Ogre source.

Anyway, would there be any objections against adding nullsquare's contribution to the CVS so that others could benefit from this too?

I can't add it myself though, but if any contributor/developer stumbles upon this tiny thing it should take but 2 minutes to add it.

I know it's just a little futility, but I just want to help. Just tell me if I need to shut up.

Greetings,
Migileke

[Game_Ender]

I don't think it will be added (is there a Degree + Real operator?) because the intention of the class was to remove the use of pure numbers. This way everyone knows whether its degree or radian without have to look at the docs, or in this case the type.

This is especially true because that simple template function does all you need to do and you can easily include it in your sources.

[syedhs]

In a long function, the declaration could be up at the top and whenever someone is doing arithmetic operation like this you will begin asking yourself, is it a degree or radian being added here?

[migileke]

Oh, ok, then this patch will remain on my computer only.

We simply have different ideas. If you want the separation so strict that nobody is even allowed to write dubious code, I can understand that, but in my opinion it is in 95% of the cases clear whether it is a radian (which never exceeds 2*pi) or a degree (which never contains pi like 0.25*pi). In the other 5% of the cases it is still possible to write Degree(r) or Radian(r).

But preferences should never be discussed, as there is no 'logical' answer. What may seem logical for one may seem stupid for another.

Greetings,
Migileke

[Kojack]

radian (which never exceeds pi)

If a radian couldn't exceed pi, then you are stuck with only half a circle. Radians have no limit.

[migileke]

I'm sorry, I'm sorry, I meant 2*pi.

And in theory, any number could be a radian, just like any number could be a degree. However, in reality you will never (or at least not in any situation I am aware of) add/subtract more than 2*pi to/from an angle.

For example: Who would do rotation += Radian( 2.5*pi ) if rotation += Radian( 0.5*pi ) does the very same thing?

[Kojack]

Depends on what the angle represents.
You might want to preserve multiple rotations.
angle1=0.18
angle2=angle1+6*pi
Performing an interpolation of those two over time would give you 3 complete rotations from the initial angle.

[migileke]

But still 6*pi is in this case clearly a Radian, so there is no doubt anyway, which was the point I wanted to make.

Before we start a flamewar or something here, I say:

Nevermind.

I'll use nullsquared's "hack".
You keep typing Degree() and Radian().

I only wanted to help.

Greetings,
Migileke

[Klaim]

But preferences should never be discussed, as there is no 'logical' answer. What may seem logical for one may seem stupid for another.

It's logical for everybody once you try to read your code a year later than you wrote it, trying to re-understand what you wanted to do exactly that time.

Every thing that might help make the code obvious at first read is good for later debug session, refactoring or for somebody else trying to read it.

If you never feel the need to make your code the most obvious possible, then it's good for you....for now

Indeed, nevermind.

[nullsquared]

It's really up to personal preference. I barely ever make use of raw degrees or radians (usually work explicitly with the quaternions); wherever I do use them, the case is completely isolated, so some "hack" (actually, it's just valid C++ trickery ) like this would make the code more readable, not not less readable.