Jump to content
  • Advertisement
Sign in to follow this  
Tom Backton

Function Return Type (C++)

This topic is 3335 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This question is probably a general C++ question, but I'm asking here because maybe the context matters. I have a color class. And there is a function that sets the active color. The return type can be const Color* , const Color& or color. Right now there are tow versions for the first two options. Classes can be big, so generally returning an object by value should be avoided if possible. In this case the size is 12 bytes. So returning by reference and by address cover the cases of dynamically-allocated and statically-allocated objects without the need to type * or &. Return by value may be needed only is the color is supplied as an object returned by value by a function. The question is whether this ever happens. Are the first two options enough? I want to be sure...so I'm asking you experienced guys...

Share this post


Link to post
Share on other sites
Advertisement
There are a few ways to do it, but my preference is to take a reference as an argument. That way the programmer is responsible for both allocating and freeing the color class.

However, if we're talking about an RGB triplet, then returning a value isn't going to break anything.

Share this post


Link to post
Share on other sites
Quote:
Original post by Tom Backton
Classes can be big, so generally returning an object by value should be avoided if possible. In this case the size is 12 bytes.


Don't optimize the small things until you know they're a bottleneck. Worry about big-O complexity of algorithms first.

Quote:
Return by value may be needed only is the color is supplied as an object returned by value by a function.


Or when the function creates the color out of thin air, and you don't want to dynamically allocate it (because that requires the caller to deallocate memory that wasn't allocated there, adds extra memory burden for the pointer itself, and may slow things down anyway for the dynamic allocation).

Besides which, the compiler can quite often optimize out the copying that you'd expect to happen with return-by-value. Especially if the function call gets inlined.

Share this post


Link to post
Share on other sites
The choice of whether to return a value or a reference is irrelevant to the size of the object, and even irrelevant to the cost to copy or move it.
Indeed, that cost can be nullified at will, and copies/moves won't happen unless they're needed anyway.

To choose correctly, you should think in terms of lifetimes, rather.

Share this post


Link to post
Share on other sites
Quote:
Original post by loufoque
The choice of whether to return a value or a reference is irrelevant to the size of the object, and even irrelevant to the cost to copy or move it.
Indeed, that cost can be nullified at will, and copies/moves won't happen unless they're needed anyway.

To choose correctly, you should think in terms of lifetimes, rather.


See, you say that, but then the lead guy on the DS or the PSP will get pretty mad at you.

Pragmatic advice: If it's greater than the machine word, and possible, const-reference it.

Share this post


Link to post
Share on other sites
Quote:
Original post by _goat
Quote:
Original post by loufoque
The choice of whether to return a value or a reference is irrelevant to the size of the object, and even irrelevant to the cost to copy or move it.
Indeed, that cost can be nullified at will, and copies/moves won't happen unless they're needed anyway.

To choose correctly, you should think in terms of lifetimes, rather.


See, you say that, but then the lead guy on the DS or the PSP will get pretty mad at you.

Pragmatic advice: If it's greater than the machine word, and possible, const-reference it.


Even on the DS and PSP, you don't want to optimize unless necessary.

Share this post


Link to post
Share on other sites
Quote:
Original post by CRACK123
Quote:
Original post by _goat
Quote:
Original post by loufoque
The choice of whether to return a value or a reference is irrelevant to the size of the object, and even irrelevant to the cost to copy or move it.
Indeed, that cost can be nullified at will, and copies/moves won't happen unless they're needed anyway.

To choose correctly, you should think in terms of lifetimes, rather.


See, you say that, but then the lead guy on the DS or the PSP will get pretty mad at you.

Pragmatic advice: If it's greater than the machine word, and possible, const-reference it.


Even on the DS and PSP, you don't want to optimize unless necessary.


But passing parameters and data by const reference doesn't cost you anything besides a few extra characters. It's the same reason why you should prefer ++i instead of i++ when they're logically equivalent. The cost is nothing or very little, but there are potential gains.

So when I have a function that takes parameters larger than 1 or 2 words, I make them const reference. Same for a function return type if I don't actually need a copy.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sc4Freak
Quote:
Original post by CRACK123
Quote:
Original post by _goat
Quote:
Original post by loufoque
The choice of whether to return a value or a reference is irrelevant to the size of the object, and even irrelevant to the cost to copy or move it.
Indeed, that cost can be nullified at will, and copies/moves won't happen unless they're needed anyway.

To choose correctly, you should think in terms of lifetimes, rather.


See, you say that, but then the lead guy on the DS or the PSP will get pretty mad at you.

Pragmatic advice: If it's greater than the machine word, and possible, const-reference it.


Even on the DS and PSP, you don't want to optimize unless necessary.


But passing parameters and data by const reference doesn't cost you anything besides a few extra characters. It's the same reason why you should prefer ++i instead of i++ when they're logically equivalent. The cost is nothing or very little, but there are potential gains.

So when I have a function that takes parameters larger than 1 or 2 words, I make them const reference. Same for a function return type if I don't actually need a copy.



True there are potential gains and I don't disagree there at all but largely when you hit performance issues normally there are probably other reasons/factors than const referencing something. Not that I would say not to return a const reference and by practice most of us end of doing that before even getting into the performance optimization part.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sc4Freak
But passing parameters and data by const reference doesn't cost you anything besides a few extra characters. It's the same reason why you should prefer ++i instead of i++ when they're logically equivalent. The cost is nothing or very little, but there are potential gains.

So when I have a function that takes parameters larger than 1 or 2 words, I make them const reference. Same for a function return type if I don't actually need a copy.


There's a big difference between passing objects by const reference, and transforming a function that returns an object by value into one that modifies a non-const reference "out parameter", which is the technique that was actually being discussed.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!