sf::Vector2i: Make use of it

[sfml]

sf::Vector2i: Make use of it

[OniLink]

I like this idea.

[LaurentGomila]

It makes sense... I'll have to think about it, and see if it would fit everywhere.

[PKEuS]

I have added some other examples to the ticket.

[TheNexus]

Note that sf::Vector2i stores signed ints, whereas most of the listed members are unsigned ints. You should probably think about the definition of sf::Vector2ui instead of having signed/unsigned conflicts all over the place.

[PKEuS]

Or delete the typedefs for sf::Vector2f and sf::Vector2i and write sf::Vector2< float> etc. all the time. Then there will be never again the problem, that there is a typedef for sf::Vector2< a> but not for sf::Vector2< b>. Thats a cleaner solution in my opinion.

[TheNexus]

No, that would just introduce unnecessarily long type names without real advantages. In my opinion, it is okay to abbreviate the most common types, especially when they are used by SFML itself. Namely, this concerns float, int, unsigned int.

[LaurentGomila]

In fact, none of these solutions satisfy me. It's true that sf::Vector is too long to type, but I don't like sf::Vector2x typedefs.

I'm thinking more and more about doing it the same as Qt does:

• sf::SizeI and sf::SizeF for sizes
• sf::PointI and sf::PointF for positions
• sf::RectI and sf::RectF for rectangles
• signed int everywhere, I think it's not a big deal to use int when negative values don't make sense. People are smart enough to figure out themselves if a negative value would be relevant or not; and it has the additional benefit of allowing -1 for invalid/uninitialized values

This is of course open to discussion.

[TheNexus]

I am not sure whether the division of vectors into size and position/point is the right decision.

• First, there are too many cases where a vector is neither of them (e.g. scale, velocity or acceleration). Sometimes, it is also difficult to draw the border, since a position is basically a size, namely the vector from the coordinate system origin to the object.
• That is also why I believe this leads to many unnecessary conversions, complicating harmless code.
• Vector operations are more difficult to formulate (does a position have a length/origin distance?) and separate overloads for sf::Point and sf::Size become necessary.
• The change breaks a huge amount of existing code.
• The resulting type safety is of limited advantage. I don't think it can prevent a lot of mistakes, since confusing size and position occurs rarely.

In my opinion, the idea behind the separation is a good one, however I fear that the cons outweigh the pros. The functionality becomes more complex, but at the same time it can cover less use cases. I think SFML as a basic multimedia framework should continue to provide the generally usable vectors.

[PKEuS]

First of all, I do not think that sf::Vector2< float> is too long. Most containers and types in the STL have long names as well. The long word "unsigned" can be avoided when C++0x is released, because it contains the header cstdint that defines a uint32_t. Avoiding typedefs has the advantage, that the code becomes more understandable. With a typedef it is not obvious that the class behind it is a template. Another problem is, that most naming conventions like Vector2i, Vector2ui, Vector2f, ... create problems and conflicts if you define too much of them (for example, if you define a Vector2si... Is it Vector2< signed int>, Vector2< short int> or Vector2< someotherstrangetype>?).
I agree to TheNexus, that a division into Size and Point is not a good solution. The reasons are already mentioned by him(although I do not think that "The change breaks a huge amount of existing code" is a good reason to keep the old names).

[TheNexus]

First of all, I do not think that sf::Vector2< float> is too long. Most containers and types in the STL have long names as well.

The difference is, at the STL there are no instantiations which are especially often used, so there is nothing to typedef. In SFML, some types like float clearly have a special status in combination with sf::Vector2. And std::uint32_t is not necessarily the same as unsigned int, apart from that it is even longer.

With a typedef it is not obvious that the class behind it is a template.

Yes, but that is not important. You can use sf::Vector2f as if it were a "raw" class. Very similar to std::string, a lot of C++ programmers don't even know that std::string is a typedef. It just doesn't matter. In fact, class template instantiations are classes.

Anyway, the vectors of the C binding must exist as explicit structure for each type, therefore the removal of the equivalent types from the C++ code is only a step towards inconsistence.

Another problem is, that most naming conventions like Vector2i, Vector2ui, Vector2f, ... create problems and conflicts if you define too much of them

Which is not a problem here since we have at most three different types that also have common abbreviations.

although I do not think that "The change breaks a huge amount of existing code" is a good reason to keep the old names

It is a point to take into account when making such decisions, although not the most important one.