Why RenderStates is passed by value in draw function?

[Neil]

What is the difference between

void func(State s)
{
        // s not changed
        func2(s);
}

void func(State s)
{
        // s needs to be changed
        s.a = 5;
        func2(s);
}

and

void func(const State& s)
{
        // s not changed
        func2(s);
}

void func(const State& s)
{
        // s needs to be changed
        State s2 = s;
        s2.a = 5;
        func2(s2);
}

Except that in the former, the state is always copied, and in the latter, the state is only copied if it needs to be modified?

My question is why the latter is not considered the better solution.

[Gambit]

More code for no justifyable reason? As I keep saying, it is trivial to copy RenderStates, it doesnt need to be passed by reference, I dont know how else to say it.

[Neil]

You didn't appear to understand what I was saying so that is why I put the code. But you are very rude so I'm not going to talk to you any more.

[Jesper Juhl]

I'm not near a compiler for a couple of days so I can't check, but modern optimizing compilers are pretty smart, and I'd guess that if you checked the disassembly from an optimized build you'd see that the compiler probably elides/removes the copy completely in rhe case where it is not modified (as already mentioned).

[Laurent]

Sorry guys but... This whole discussion looks really stupid, you should stop it

Neil, in case it was not clear enough, yes you're right, from a pure technical point of view your code is more "optimized" (*). But nobody cares because in the end it will make no difference. So I pass by value to save one extra line of code because 80% of SFML classes need to do that copy. That's just it...

(*) compilers are smart, I'm pretty sure it doesn't even make any difference at all

[Neil]

I can believe that the cost of passing render states by value is trivial and so there's no point worrying about it.

I am reluctant to believe the compiler can optimize away the copy in a pass by value in this case. Draw is a virtual function and it may not be known until run-time whether the states parameter is modified or not by the resolved function.

[StormWingDelta]

I can believe that the cost of passing render states by value is trivial and so there's no point worrying about it.

I am reluctant to believe the compiler can optimize away the copy in a pass by value in this case. Draw is a virtual function and it may not be known until run-time whether the states parameter is modified or not by the resolved function.

It comes down to the IDE you are using and the other parts like the compiler.  If I remember right both Code::Blocks and Visual Studio do a lot of the optimization that we'd have to have done manually years back.  It most likely can optimize things you wouldn't think of.

[eXpl0it3r]

StormWingDelta: What you said makes no sense and what you meant to say has already been said multiple times. An IDE (Integrated Development Environment) does absolutely not optimize anything, it doesn't even produce any kind of binary code. The compiler creates the binary code and does the optimization! By now you should really be able to tell the difference between an IDE and a compiler.

I am reluctant to believe the compiler can optimize away the copy in a pass by value in this case. Draw is a virtual function and it may not be known until run-time whether the states parameter is modified or not by the resolved function.

Programming is never about any kind of believe. Study, try, test, profile. The easiest way is really to go write reliable test cases. The harder way is to go study what the standard allows and what the compilers actually do (of course that only works for open source compilers).

As for the discussion in general: Stop trying to optimize stuff which hasn't been proven to be a bottleneck in anyone's code.

[Nexus]

I understand Nei's argument because the general rule is: use const reference for bigger objects, value for built-ins and small classes. The reason why SFML deviates here has been mentioned: the states are mostly modified, so code is simpler.

And Gambit, don't be rude just because you're on the same side as SFML team members. When you make a (bad) argument and are asked for clarification, then explain your point.

[Gambit]

I wasnt trying to be rude, I was just trying to get a point across.