Messages

1

Feature requests / FS#82 - Add functions to sf::Vector2

« on: July 13, 2010, 01:38:26 am »

It's not that I wouldn't find a Length() function useful.

You mean essential.

The issue is, it doesn't easily integrate into the current SFML design

.. and the design is - of couse - more important than usability.

What's wrong with:

Code: [Select]


T GetLength() const
{
using namespace std; //make custom sqrt overloads work
return static_cast<T>(sqrt(X * X + Y * Y));
}

I do not see there any problems. Since the length of an Vector2i does not make much sense, no one will use GetLength() on it. If someone still needs that value he can use the method because integers implicitly convert to float or double. Even std::complex<T> should work because sqrt has an overload for it. If someone uses his own number class he can overload sqrt is his own namespace and ADL will do the rest.
A traits template would be far too overcomplicated. Every graphics library does it more or less like above.
And you do not have to treat the users like complete idiots.

2

Feature requests / FS#82 - Add functions to sf::Vector2

« on: July 12, 2010, 11:25:50 pm »

They can interact with argument dependent lookup. Methods behave similarly

Wrong, they do not. Do you know ADL? It's a namespace-related feature which can obviously not apply to member functions. The ability to abstract from types becomes less powerful if the types are restricted to classes. Consider the following code. You cannot achieve those semantics with member functions.

Code: [Select]

swap(a, b); // calls the correct function independent of
            // the type and namespace of a and b

"similarly" = does in fact not matter because you always have an object when calling the method -> you do not have to tell the compiler where to look for the function.

Now I would like to know why you don't want those methods in the vector. I do not understand your argumentation in the posts you linked.

3

Feature requests / FS#82 - Add functions to sf::Vector2

« on: July 12, 2010, 10:18:07 pm »

(for simplicity I will only mention the getLength() function/method)

There is no reason not to integrate it.

There are many reasons, although they may be not obvious to the average user, who doesn't have to care about designing a consistent, well-thought API. If you take a look at the discussions at my link posted above, you'll find a lot of explanations.

I did not find a single argument. Only "Vector2<int> would be a problem".

Free functions CAN be in an API, but they should not if there is an alternative.

Why should they not?

Quoting myself:

Just do not pollute the sf namespace with specific functions for this and that. Classes are not only for combining variables into a single one.

Additionally (for example) Visual C++ lists all the methods when hitting . or -> which is not available for globals.

Generic algorithms like std::for_each have to be global, but a function for calculating a vector's length is not generic only because Vector2 is a template.

The decision between global and member functions doesn't primarily depend on the use of templates. Reusability is just one criterion (and can also be achieved by other abstraction features).

Are there any other criteria? In this case reusability does not matter anyway. The function would not be used for anything else that calculating that length.

[*]Global functions aren't limited to classes, they can be used for scalar types as well. Does not matter, I only want to get a vector's length and nothing else
[*]They can be overloaded for different object types. Several classes can have a same-looking method as well
[*]They take implicit object conversions into account. I do not want anything to be converted into a vector implicitly
[*]They increase encapsulation since they don't have direct access to all class members. Vector2 has only public members, is not even close to an argument btw
[*]They can be written as templates once and be reused for multiple classes. Vector2 is already a template
[*]They can interact with argument dependent lookup. Methods behave similarly
[*]They can be declared separate from the class definition. Why should someone want that? Would be confusing to have vector functions in a different header than the vector itself
[/list]

Now it's your turn to tell me when member functions are the better choice (as long as free functions are still an alternative, i.e. when neither virtual nor non-public member access is required). ;)

If you want to use globals a lot, I would recommend C.

4

Feature requests / FS#82 - Add functions to sf::Vector2

« on: July 12, 2010, 04:12:42 pm »

Methods like getLength(), getLengthSq() and normalize() are necessary for serious game programming.

Of course. But "should it be integrated to SFML?" is a different question.

There is no reason not to integrate it.

I thought SFML would be a C++ library...

C++ doesn't mean "everything is an object". Would you say that the standard library, with all its generic non-member functions, is not C++? In C++, free functions can be part of a class API and are sometimes a better/clever design choice.

I would not say that and I did not say it. Free functions CAN be in an API, but they should not if there is an alternative. Generic algorithms like std::for_each have to be global, but a function for calculating a vector's length is not generic only because Vector2 is a template. Just do not pollute the sf namespace with specific functions for this and that. Classes are not only for combining variables into a single one.

Why is

Code: [Select]


cout << getVectorLength(Vector2f(10, 20)) << endl;

better than

Code: [Select]


cout << Vector2f(10, 20).getLength() << endl;

?

5

Feature requests / FS#82 - Add functions to sf::Vector2

« on: July 12, 2010, 01:56:25 pm »

sf::Vector2 is not going to be a physics vector. Its purpose is to easily manipulate a (x, y) pair, nothing else.

Why do you call it vector if its only a pair of coordinates?  You should rename your pseudo vector to sf::Point2 or something. Methods like getLength(), getLengthSq() and normalize() are necessary for serious game programming.

But I think that most of the functions that you're mentionning (magnitude, angle, operators) should be implemented as free functions on top of a simple class like sf::Vector2, they shouldn't be part of the class itself anyway. At least that's how I would design them.

I thought SFML would be a C++ library...