Function Return Type (C++)
Author
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...
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.
However, if we're talking about an RGB triplet, then returning a value isn't going to break anything.
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.
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.
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.
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.
Quote:Original post by _goatQuote: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.
Quote:Original post by CRACK123Quote:Original post by _goatQuote: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.
Quote:Original post by Sc4FreakQuote:Original post by CRACK123Quote:Original post by _goatQuote: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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
