sf::Transform::operator()

[korczurekk]

Hi,
Transforming some container with points inside is know pretty harsh:

std::transform(points.begin(), points.end(), points.begin(), [&t](sf::Vector2f p) {
        return t.transformPoint(p);
});

It would be a lot nicer if sf::Transform provided () operators for both points and rectangles:

std::transform(points.begin(), points.end(), points.begin(), t);

[Laurent]

I've got something even shorter with the current API:

for (auto& p : points) p = t * p;

[korczurekk]

It woks well unless I want to keep vertices in one container, std::transform lets me choose where to store it. And TBH, multiplying vector by transform is nowhere near being readable for some outsider that reads my code, especially if he isn't familiar with OpenGL and underlying maths.

[Laurent]

It woks well unless I want to keep vertices in one container, std::transform lets me choose where to store

... points2.push_back(t * p);

With std::transform you have to either points2.resize() before the call, or std::back_inserter(points2) so it's not less verbose.

And TBH, multiplying vector by transform is nowhere near being readable for some outsider that reads my code, especially if he isn't familiar with OpenGL and underlying maths.

I think that (if we forget transformPoint of course) operator* is more intuitive than operator() because it sticks to the mathematical definition of what is done -- here we really multiply the transform and the point.

[korczurekk]

It woks well unless I want to keep vertices in one container, std::transform lets me choose where to store

... points2.push_back(t * p);

With std::transform you have to either points2.resize() before the call, or std::back_inserter(points2) so it's not less verbose.

At this point it's either slow or I have to write more code to reserve memory, it may be surprising, but I really know 'bout push_back method. 

And TBH, multiplying vector by transform is nowhere near being readable for some outsider that reads my code, especially if he isn't familiar with OpenGL and underlying maths.

I think that (if we forget transformPoint of course) operator* is more intuitive than operator() because it sticks to the mathematical definition of what is done -- here we really multiply the transform and the point.

operator() is not meant for manual use, in this case ofc operator* is better, I just want it so it can be passed to all those STL functions that take callable objects as parameters. TBH some additional proxy class and method callable() that'd return it from sf::Transformable would also be nice, from some points of view even cleaner and would ensure that beginners won't misuse that operator(). However it would generate wayyy more code for SFML devs to maintain, so I didn't really think seriously about suggesting it.

[Laurent]

At this point it's either slow or I have to write more code to reserve memory, it may be surprising, but I really know 'bout push_back method.

What's your point exactly? You want to be able to use std::transform, because it is supposed to be less verbose, but I try to show you that the loop it tries to hide can now be even less verbose with C++11 syntax and the multiply operator. So what now?

operator() is not meant for manual use, in this case ofc operator* is better, I just want it so it can be passed to all those STL functions that take callable objects as parameters. TBH some additional proxy class and method callable() that'd return it from sf::Transformable would also be nice, from some points of view even cleaner and would ensure that beginners won't misuse that operator(). However it would generate wayyy more code for SFML devs to maintain, so I didn't really think seriously about suggesting it.

We can't put operator() in all classes just so that they can be used directly as the last argument of standard algorithms. You need to adapt the syntax, and that's why lambdas exist