SFML community forums

General => Feature requests => Topic started by: Platyna on June 21, 2012, 10:15:15 pm

Title: Few suggestions
Post by: Platyna on June 21, 2012, 10:15:15 pm
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.
Title: Re: No assignment operator in class Vector
Post by: eXpl0it3r on June 21, 2012, 10:41:25 pm
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>? :P
Title: Re: Few suggestions
Post by: Platyna on June 21, 2012, 11:24:14 pm
Quote
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?
Title: Re: Few suggestions
Post by: Celtic Minstrel on June 22, 2012, 01:19:34 am
I actually prefer having x and y rather than a vector in the mouse events; as for prevPos, you can easily track that yourself. ;)
Title: Re: Few suggestions
Post by: eXpl0it3r on June 22, 2012, 02:59:28 am
Next time you should write also in answering post that you edited the first entry, didn't see it. ;D

Quote
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. ;)

Quote
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).

Quote
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... ;)
Title: Re: Few suggestions
Post by: Cornstalks on June 22, 2012, 08:45:04 am
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.
Title: Re: Few suggestions
Post by: Platyna on June 22, 2012, 01:08:17 pm
Quote
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.
Title: Re: Few suggestions
Post by: Laurent on June 22, 2012, 01:20:58 pm
Quote
So Vector2 should have a trivial default constructor.
Do you even know what it means? :P

Quote
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.
Title: Re: Few suggestions
Post by: Platyna on June 22, 2012, 01:48:50 pm
Quote
Do you even know what it means? :P
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?
Title: Re: Few suggestions
Post by: Laurent on June 22, 2012, 01:58:11 pm
Quote
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.
Title: Re: Few suggestions
Post by: MorleyDev on June 22, 2012, 04:03:59 pm
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
Title: Re: Few suggestions
Post by: Nexus on June 22, 2012, 04:41:06 pm
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.
Title: Re: Few suggestions
Post by: Cornstalks on June 23, 2012, 06:46:53 pm
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.
Title: Re: Few suggestions
Post by: Celtic Minstrel on June 24, 2012, 08:58:08 am
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;};
Title: Re: Few suggestions
Post by: Midleiro F on July 04, 2012, 07:29:05 am
It would be nice to have implicit conversions from Vector2f to Vector2i and vice-versa too
Title: Re: Few suggestions
Post by: Laurent on July 04, 2012, 07:54:43 am
It would hide potential errors. Explicit conversions are better.
Title: Re: Few suggestions
Post by: Celtic Minstrel on July 06, 2012, 03:21:41 am
I remember thinking that too! Even if it's only an explicit conversion, it would be nice to have.

EDIT: Posted this before seeing Laurent's response, heh. Um... actually, it already has explicit conversions, doesn't it. <_<