Class creation and storing angles

[pivottt]

I have a quick question. I need a way to represent orientation in degrees. I made a class which automatically changes negative angles into positive ones (adds 360 until >0) and makes sure they are under 360 (subtracts 360 until <360).

Now I realized I also need a class to represent angular movement, which must be in the range ]-360;360[

I don't think custom types with the unsigned keyword is a thing, but I'm just looking for a better way to do this then making two classes. Or would you just create a class which inherits from angle and overloads a few methods?

Or I could just use floats to represent rotation, because testing if an object does more than 1 turn per second isn't really required.

[Albatross]

Inheritance is the clean and by-the-book way to do it.

You could, if you would prefer to avoid making two different types, add a constructor which takes a boolean as input that defaults to false. If true, its bounds will be (-360,360), if false, [0,360).

-Albatross

[ne555]

> create a class which inherits from angle and overloads a few methods
>> Inheritance is the clean and by-the-book way to do it.
I'm not sure to follow. `angle' is a class that has a value clamped to the range [0;360]
Then you want `angular movement' that has a range that is not included in the range of `angle'

¿wouldn't that violate LSP? `Postconditions cannot be weakened in a subtype.'
as you can have an `angular movement' with a negative value, which is forbidden for an `angle'


> in the range ]-360;360[
excuse my ignorance, ¿valid range is outside that region, i.e. (-infty; -360] [360; infty) ? (so 0 is invalid)

[m4ster r0shi]

I don't think this is what Albatross meant (I could be wrong though).

if you would prefer to avoid making two different types

This implies (to me at least) that inheritance is applied in a way where you have two subclasses of
an Angle class, each one imposing different constraints on the contained value. Something like this:

#include <iostream>
#include <vector>
#include <memory>

struct Angle {

    int value;

    virtual int getValue() {
        return value;
    }

    virtual void setValue(int newValue) {
        value = newValue;
    }

    virtual ~Angle() {}
};

struct Orientation : Angle {

    void setValue(int newValue) {
        Angle::setValue((newValue % 360 + 360) % 360);
    }
};

struct AngularMovement : Angle {

    void setValue(int newValue) {
        Angle::setValue(newValue < -360 ? -360 : newValue > 360 ? 360 : newValue);
    }
};

int main()
{
    typedef std::shared_ptr<Angle> sptr_t;

    std::vector<sptr_t> v = {sptr_t(new Orientation), sptr_t(new AngularMovement)};

    auto f = [&](int n) {

        for (auto a : v) {
            a->setValue(n);
            std::cout << a->getValue() << '\n';
        }

        std::cout << std::endl;
    };

    for (auto n : {0, 180, -180, -360, 360, -1000, 1000}) {
        f(n);
    }

    return 0;
}

Maybe I just haven't looked very closely, but I don't see anything horribly broken with it.

PS: Is there a shorter way to create a vector of std::shared_ptrs using an initializer list?

[Duthomhas]

I'm not sure I see the problem. If the constructor takes anything and clamps it to [0,360), then you can easily add a 'negative' angle:

1 2 3 4 5

angle a( 30 ); angle b( -10 ); angle c = a + b; cout << a << " + " << b << " = " << c << endl;

30 + 350 = 20

Did I miss something?

[ne555]

1 2 3 4 5 6 7

void nop(angle &a){ a=a; } angular_movement a(-10); //valid nop(a); //the `angle' passed is invalid cout << a << '\n';

350

[pivottt]

]-360;360[ means between -360 and +360, but excluding -360 and +360. Sorry for that. I didn't say from 0 to 359 because I'm using floats, not ints.

I think I'll use the angle class where I need it to represent an orientation and I'll makes something like typedef float rotation for the angles which can be negative. The engine just won't check if a rotation is more than one turn per tick. It's not that big of a deal since you usually add an additional limit for each object of your game. Thanks for your ideas though!

[Duthomhas]

I love posting, especially when I make the effort to be logical, succinct, and useful, carefully observing underlying mathematical properties, because it is clear that such effort isn't wasted.

I paid attention when I studied modular arithmetic.

[ne555]

@Duoas: I don't understand what you are trying to say, please be more clearer.
The operations in `angle' are resolved and good, nobody complains about that.

[Duthomhas]

You don't need inherited classes or anything else (like dinking with extra floats). One "angle" class is sufficient.