An overload for sf::RectangleShape::setSize that takes 2 float argument

[iride]

I see that sf::RectangleShape::setSize() only takes a sf::Vector2f object.
Can you make an overload that takes 2 float arguments?

It's kind of looking ugly in my code to construct a temorary Vector2f

[Nexus]

It's kind of looking ugly in my code to construct a temorary Vector2f

If you already have a sf::Vector2f, it will suddenly become beautiful

I often see people use separate x/y coordinates where vectors would be much more appropriate. Of course, in some cases separate floats are handier, but in general you should try to think object-oriented, i.e. treat coordinates (like position, velocity, size) as objects.

[cire]

#include <SFML/Graphics.hpp>

template <typename T>
void setSize(T& obj, float width, float height )
{
    obj.setSize( sf::Vector2f( width, height ) ) ;
}

// Or use a typedef to lessen the visible impact
typedef sf::Vector2f v2f ;

int main()
{
    sf::RectangleShape rect ;
    setSize(rect, 100.0f, 200.0f) ;

    rect.setSize(v2f(100.0f, 200.0f)) ;
}

[iride]

I think there's no reason for this not to be implemented.

sf::Rect<T> has a constructor overload that takes 4 arguments instead of 2 vector arguments..
STL containers also provide emplace_back(args..)

[Laurent]

I think there's no reason for this not to be implemented.

The reason is to avoid duplicating a big amount of functions. In my opinion, "ugliness" is not a valid argument for it.
Functions that have overloads taking separate floats are there mainly for historical reasons.

STL containers also provide emplace_back(args..)

This is for a totally different purpose: it allows to construct the argument directly in its final memory location, instead of having to copy it. It's not to avoid "ugliness"

[Hiura]

Note that with C++11 you can do something cool : obj.setSize({x, y}). 

[iride]

I think there's no reason for this not to be implemented.

The reason is to avoid duplicating a big amount of functions. In my opinion, "ugliness" is not a valid argument for it.
Functions that have overloads taking separate floats are there mainly for historical reasons.

This seems inconsistent with other functions in SFML.
sf::Shape::setPosition(), sf::Shape::setScale(), sf::Shape::setOrigin(),  sf::Shape::move(), and other functions have overloads for taking 2 separate arguments.
But why not sf::Rect::setSize()? This doesn't seem like "duplicating" functions.
Other than "ugliness", I can avoid unnecessary copies of sf::Vector2f object

[Laurent]

This seems inconsistent with other functions in SFML.
sf::Shape::setPosition(), sf::Shape::setScale(), sf::Shape::setOrigin(),  sf::Shape::move(), and other functions have overloads for taking 2 separate arguments.
But why not sf::Rect::setSize()?

Functions that have overloads taking separate floats are there mainly for historical reasons.

Other than "ugliness", I can avoid unnecessary copies of sf::Vector2f object

What's wrong with copying sf::Vector2?

[iride]

This seems inconsistent with other functions in SFML.
sf::Shape::setPosition(), sf::Shape::setScale(), sf::Shape::setOrigin(),  sf::Shape::move(), and other functions have overloads for taking 2 separate arguments.
But why not sf::Rect::setSize()?

Functions that have overloads taking separate floats are there mainly for historical reasons.

Other than "ugliness", I can avoid unnecessary copies of sf::Vector2f object

What's wrong with copying sf::Vector2?

It's just that I don't like unnecessary copies if I can avoid it

[Hiura]

use your compiler's optimisation options. they can do miracle sometimes, especially with copies.

[Laurent]

It's just that I don't like unnecessary copies if I can avoid it

I think it's wrong to think this way. You do copies all the time, and I'm sure you don't notice most of them. And they are not unnecessary; or if you think so, then maybe you should work with an assembly language rather than one that provides abstractions

And, of course, "I don"t like" alone is never an argument. I can't build a library based on what one user likes or not. I need strong arguments. I'm sure you understand that

[iride]

It's just that I don't like unnecessary copies if I can avoid it

I think it's wrong to think this way. You do copies all the time, and I'm sure you don't notice most of them. And they are not unnecessary; or if you think so, then maybe you should work with an assembly language rather than one that provides abstractions

And, of course, "I don"t like" alone is never an argument. I can't build a library based on what one user likes or not. I need strong arguments. I'm sure you understand that

Really? I don't make copies all the time. I try to use pass-by-ref all the time if it's not fundamental types. And there are copies that are absolutely unnecessary(sf::Vector2f in my case). This is why STL provides emplace functions.

And what about inconsistency? I of course thought that sf::RectangleShape::setSize() took 2 float arguments because other functions such as setPosition() and setOrigin() took 2 arguments and wondered why my compiler gave me error. So I thought there was another error in my code searched for the error in my code for 5 minutes. And then I checked the doc and found out that it only takes a Vector.
Inconsistency causes confusions to users. Users shouldn't have to keep in mind that some functions only take a vector and some functions take 2 separate arguments. A simple API should be consistent throughout.

[masskiller]

Really? I don't make copies all the time. I try to use pass-by-ref all the time if it's not fundamental types. And there are copies that are absolutely unnecessary(sf::Vector2f in my case). This is why STL provides emplace functions.

References get copied around, same with pointers, they are of course far better to handle than "true" copies, but they are copies (of miserable size and of memory addresses) nonetheless. Also copying an sf::Vector2<float> is almost exactly the same as copying two floats, so there should be no performance decrease over something so trivial.

A reference (and for that matter a pointer) is always a few bytes that depend on your computer's architecture. Let's assume a 32-bit, there both a reference and a pointer is 4-8 bytes long (not really sure), the same size as a float. That means copying a reference and copying two floats would always be the same or a reference would even be cheaper to pass around.

There should be nothing to complain about other than personal taste as 4 bytes (even when constantly repeated) are meaningless for your average computer these days even if it is a low end one.

Inconsistency causes confusions to users. Users shouldn't have to keep in mind that some functions only take a vector and some functions take 2 separate arguments. A simple API should be consistent throughout.

I do agree on this, but it probably only means that the float version of the functions will probably be replaced entirely by the vector ones, not that it will make any difference though.

[Nexus]

Really? I don't make copies all the time. I try to use pass-by-ref all the time if it's not fundamental types. And there are copies that are absolutely unnecessary(sf::Vector2f in my case).

I always pass sf::Vector2f by value (unless I need to modify it). Passing by reference doesn't pay off, since the reference itself is slightly smaller or as big as the vector, and there is an additional dereferencing. You don't pass double by reference either, and it has the same size as sf::Vector2f. Anyway, the compiler can often inline the function and optimize the parameters away.

This is why STL provides emplace functions.

No. emplace() is designed to construct heavy objects in place, even faster than move semantics. Take a look at the proposal:

The motivation for placement insert is that containers—especially node-based containers—are
very useful for the storage of heavy objects. In some environments efficiency is very important,
but there is in general no way to put elements into containers without copying them. A heavy
object may store its data directly, in which case move semantics will not improve copy performance.

[JayArby]

In final code, I almost always end up using a Vector2f anyway, but if I am hacking something together and want to do a quick test, the constructors/set methods that take plain floats are definitely very handy. I do find myself constantly passing two floats to a given constructor (still) and then realizing my error and going back to create a temporary Vector2f. I'm with iride-it would definitely be nice to see 2-float-constructors come back.

(and if you write the one constructor to call the other one, there isn't really any "duplication".)