Few suggestions

[Platyna]

I think there should be an assignment operator in Vector2<T> and Vector3<T>.

Update
Ok. I have few other suggestions:
- There should be a Vector2d typedef for Vector2<double> too.
- All mouse events should have attribute Vector2 position instead of two fields x and y.
- There should be additional field prevPos in MouseMoveEvent.

Update 2
I changed thread subject.

Update 3
New suggestion:
I think class sf::Shape should have a method "bool contains(Vector2 point)" to check if a point is contained.
And maybe it should be separated Shape and DrawableShape. Like a Rect<T> and RectangleShape. It's to be discussed.

[eXpl0it3r]

Although there's no explicit decleration of a assignment operator it's still there since there's an copy constructor.

Vector2(const Vector2<U>& vector);

Not sure if the typedef is really needed, but if so why not add sf::Vector2u for sf::Vector2<unsigned int>?

[Platyna]

Although there's no explicit decleration of a assignment operator it's still there since there's an copy constructor.

You are right. I forgot about that.
What about other suggestions?

[Celtic Minstrel]

I actually prefer having x and y rather than a vector in the mouse events; as for prevPos, you can easily track that yourself.

[eXpl0it3r]

Next time you should write also in answering post that you edited the first entry, didn't see it.

There should be a Vector2d typedef for Vector2<double> too.

I guess it's not nessecary since it's not use internally for SFML, if you need it you can typedef it yourself.

All mouse events should have attribute Vector2 position instead of two fields x and y.

I'd be interessted in hearing what the reason is for not providing it.
I could imagine that he wants to keep the events as close as possible to the actually event, and there you get the x and y position seperated (I think).

There should be additional field prevPos in MouseMoveEvent.

As said above, the events aren't just arbitrary and they aren't something that comes from SFML, it's the OS that shedules those events and there just is no prevPos. And implementing one on your own isn't that hard...

[Cornstalks]

One of the problems with using Vector2 in the events (instead of two fields x and y) is the use of unions. IIRC, Vector2 does not have a trivial default constructor, and so cannot be in a union.

[Platyna]

One of the problems with using Vector2 in the events (instead of two fields x and y) is the use of unions. IIRC, Vector2 does not have a trivial default constructor, and so cannot be in a union.

So Vector2 should have a trivial default constructor.

New suggestion:
I think class sf::Shape should have a method "bool contains(Vector2 point)" to check if a point is contained.
And maybe it should be separated Shape and DrawableShape. Like a Rect<T> and RectangleShape. It's to be discussed.

[Laurent]

So Vector2 should have a trivial default constructor.

Do you even know what it means?

New suggestion:
I think class sf::Shape should have a method "bool contains(Vector2 point)" to check if a point is contained.
And maybe it should be separated Shape and DrawableShape. Like a Rect<T> and RectangleShape. It's to be discussed.

Anything that breaks the public API won't be discussed until I start working on SFML 3.

[Platyna]

Do you even know what it means?

Sorry, my mistake. I didn't know trivial constructor is something different than default constructor.

So, could I ask why something that don't have trivial contructor can't be in union?

[Laurent]

So, could I ask why something that don't have trivial contructor can't be in union?

Because the C++ standard says so. If I remember correctly, this rule was removed from the new C++11 standard.

[MorleyDev]

More specifically, the definition of trivial constructor POD-type was relaxed and "Class() { }" still counts as a trivial constructor so long as all member variables also have trivial constructors ('cause it basically is in that situation).

GCC supports this, but the latest versions of Visual Studio do not (annoyingly).

The reason for this is because if you provide any constructor (except copy or move), the trivial constructor is disabled. And you have to use a trivial constructor, because unions are just blocks of data that can be treated as if they are a variety of types. So non-trivial destructors or constructors can be used, because how would it know which ones to use?

If you want to use non-POD types, I suggest looking at Boost.Variant http://www.boost.org/doc/libs/1_49_0/doc/html/variant.html

[Nexus]

One of the problems with using Vector2 in the events (instead of two fields x and y) is the use of unions. IIRC, Vector2 does not have a trivial default constructor, and so cannot be in a union.

It's an annoying technical restriction, but also shows the drawbacks of C relicts like unions. Maybe, some day there will be another approach for events, but it might be less simple...

I think class sf::Shape should have a method "bool contains(Vector2 point)" to check if a point is contained.

This requires a more complex geometry algorithm, I don't think it should be part of SFML. But you can easily achieve that with Boost.Geometry, for example.

Although there's no explicit decleration of a assignment operator it's still there since there's an copy constructor.

The copy assignment operator is implicitly generated by the compiler, it doesn't depend on the copy constructor.

[Cornstalks]

Correct me if I'm wrong, but even with C++11 I don't think sf::Vector2 would be allowed in a union, because it initializes its members in its default constructor (and thus the constructor is not trivial and sf::Vector2 is not a POD type).

I could be wrong on this, as I've only read part of the standard on this and haven't invested too much time in thoroughly understanding it.

[Celtic Minstrel]

This isn't necessarily an indication of it being allowed by the standard, but clang 3.1 accepts the following code:

Code: [Select]

union test {sf::Vector2f test;};

[Midleiro F]

It would be nice to have implicit conversions from Vector2f to Vector2i and vice-versa too