Why RenderStates is passed by value in draw function?

[Neil]

http://www.sfml-dev.org/documentation/2.0/classsf_1_1Drawable.php

In this function

virtual void    draw (RenderTarget &target, RenderStates states) const

Why is RenderStates passed by value and not (const) reference? On my compiler it is 76 bytes, which is quite big.

I know sometimes draw function may want to alter it. In that case, it can make its own copy from the const reference if required.

Wouldn't this be faster?

Thank you.

[Jesper Juhl]

I doubt you'd be able to measure a difference. And anyway, you'd then slow down the "wants to make a copy" case.
But I really doubt that it actually matters either way, performance wise.

[Hiura]

Measure it, with compiler optimisation turned on, of course. The copy is probably elided when not needed so you'll probably see no difference. But that's just a guess... The key is to always measure.

[FRex]

It will be copied once per drawing, since the calls usually go:
1. RenderTarget::draw //constructed default or passed here as const&
2. Drawable::draw //copy here
3. RenderTarget::draw //the vertex overload, also takes by const&

Also almost all sf::Drawable classes that come with SFML modify it, I think just VertexArray doesn't. It's also 100% trivial to copy.


In theory and for the sake of C++ trivia: yes, it might be faster or it might be slower, but either way it doesn't matter.
It's not performance issue and will probably never be.
The actual OpenGL draw calls (which are some pretty old/legacy functions of GL) time inside RenderTarget::draw is dominating so heavily that it will completely dwarf this in any profiler.

It just doesn't matter. It's impossible to write a real life program which would be impacted by this change in any way.

[Gambit]

I know sometimes draw function may want to alter it. In that case, it can make its own copy from the const reference if required.

This is stupid for a lot of reasons. As it is stated, a lot of drawables modify the states which means you are making senseless copies which could be avoided if the states were passed by value (Sound familiar?).

[Neil]

Ok thanks. I understand now it probably doesn't matter and I shouldn't worry about it.

However I don't understand Gambit's post. Why would passing by const reference result in more copies than passing by value?

[Gambit]

If RenderState is passed by const ref, you cannot alter the state so you have to copy it if you need to modify it.

[Neil]

Yes. How is that worse than pass by value, which results in a copy even if it's not modified?

[Gambit]

Pass by value is a copy even if it is modified. There is no point in passing by reference. Each draw call has the option to change the state if it wants without affecting other draw calls. Most draw calls (Text, Sprite, etc) change the transformation of the state which you cannot do with a const ref. Passing by non-const ref means that changing the state will affect other draw calls as well. As stated earlier, its trivial to pass by value (If 76 bytes is a lot I suggest getting more RAM). From a performance stand point, the overhead is negligible.

[Neil]

Passing by const reference and only making a copy if it needs to be modified results in less copies.
I wouldn't pass by non-const reference. That would cause too many issues about the re-usability of the original state object.
Copying 76 bytes on the stack is nothing to do with the amount of ram. It depends mainly on CPU.

I inherit my classes from sf::Drawable and implement the draw function. Objects may contain subojects that need drawing. Not all objects are interested in changing the render state. This is the motivation of my asking. Is this not a good design?

[Laurent]

Is this not a good design?

It is. Passing the render states by value is also a good design. The thing is, nobody cares because the difference will never be noticeable. There's really nothing else to say about it

[Neil]

Could you explain why passing render states by value is good design?
I'm just curious because it's different to the way I was taught to program* and would like to learn more.
Thanks

(Pass basics by value, pass big things by reference, I know it's only a rule of thumb)

[Gambit]

Read a C++ book/pdf or something, I'm sure it outlines the ups and downs for using both. This is not a C++ tutorial forum.

[Neil]

Hey I've been coding C++ for years so cut the attitude please. If you're going to be flippant, you at least need to be right, which you haven't been in your previous posts.

[Gambit]

Theres no need to be rude. This is not a C++ help and support forum. If you have been coding C++ for years, I'm sure you would know this by now or at least have the ability to source the information yourself.

Passing by value, reference or pointer is not just about size, but about utility as well. The one you chose depends on what is going to happen to the variable that is being passed.

Say I want to share a web page with you.

If I tell you the URL, I'm passing by reference. You can use that URL to see the same web page I can see. If that page is changed, we both see the changes. If you delete the URL, all you're doing is destroying your reference to that page - you're not deleting the actual page itself.

If I print out the page and give you the printout, I'm passing by value. Your page is a disconnected copy of the original. You won't see any subsequent changes, and any changes that you make (e.g. scribbling on your printout) will not show up on the original page. If you destroy the printout, you have actually destroyed your copy of the object - but the original web page remains intact.