It's kind of looking ugly in my code to construct a temorary Vector2fIf you already have a sf::Vector2f, it will suddenly become beautiful :)
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.
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" ;)
This seems inconsistent with other functions in SFML.QuoteI 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()?
Functions that have overloads taking separate floats are there mainly for historical reasons.
Other than "ugliness", I can avoid unnecessary copies of sf::Vector2f objectWhat's wrong with copying sf::Vector2?
It's just that I don't like unnecessary copies if I can avoid itQuoteThis 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()?Quote from: LaurentFunctions that have overloads taking separate floats are there mainly for historical reasons.QuoteOther than "ugliness", I can avoid unnecessary copies of sf::Vector2f objectWhat's wrong with copying sf::Vector2?
It's just that I don't like unnecessary copies if I can avoid itI 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 ;)
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.QuoteIt's just that I don't like unnecessary copies if I can avoid itI 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 :P
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.
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.
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 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2642.pdf):
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.
(and if you write the one constructor to call the other one, there isn't really any "duplication".Constructors can only call other constructors in C++11, which SFML doesn't use.