2

I am reading a book on C++ and I am wondering why returning by value is the recommended way. We can return by reference instead of using output parameter so why don't we recommend returning by reference?

enter image description here

Second Person Shooter
  • 14,188
  • 21
  • 90
  • 165
  • 1
    Distinguishing between input and output makes things more comprehensible for the most part. It also often simplifies calling code. `auto foo = myFunction();` is usually easier to parse than `SomeClass foo; myFunction(foo);`, especially if `SomeClass` is nontrivial to construct. – Nathan Pierson Mar 07 '21 at 03:57
  • 2
    Kindly do some research before making posting a question. The question we have now might be answered before.Please traverse to the following link. https://stackoverflow.com/questions/33994995/which-is-more-efficient-return-a-value-vs-pass-by-reference – Mathews Sunny Mar 07 '21 at 03:58
  • 1
    @MathewsSunny: I am comparing return-by-value with return-by-reference. – Second Person Shooter Mar 07 '21 at 04:00
  • 1
    Does this answer your question? [Which is more efficient: Return a value vs. Pass by reference?](https://stackoverflow.com/questions/33994995/which-is-more-efficient-return-a-value-vs-pass-by-reference) – Mathews Sunny Mar 07 '21 at 04:00
  • For more on the readability and calling code issues as opposed to the performance issues, there's [this question](https://softwareengineering.stackexchange.com/questions/202932/named-output-parameters-vs-return-values) over on the Software Engineering exchange. – Nathan Pierson Mar 07 '21 at 04:03
  • Disclaimer: The book I quoted above is a very good book! – Second Person Shooter Mar 07 '21 at 04:30

2 Answers2

4

Before considering returning a reference, you must first decide what object would the result refer to. What are your options?

  1. You could return reference to a local automatic variable... This is very bad because the local variable won't exist once the function returns.
  2. You could return reference to a variable in static or thread local storage. This is bad because global state is bad.
  3. You could return reference to an object that was provided as an argument by the caller. Well, in this case it's typically pointless to return the reference since the caller already knows where the object is since they were responsible in providing the argument in the first place. This is just a complicated version of the "output parameter" that was recommended against by the quoted text.

There of course are cases where returning a reference makes sense. General rules of thumb such as the quoted one don't apply to every case. They apply to most, simple cases. If you know a good reason to not follow it, then don't. If you don't know whether there is a reason, then follow the rule until you gain understanding.

It is important to note the context of the advice. The section begins with "if you have a function that needs to return an object of a class...". The context wasn't "if you have a function that needs to return reference to an object of a class".

I do return-by-reference for member functions that can be called in chain obj.DoX(...).DoY(...).DoZ(...);

Method chaining is an idiom where reference to *this is returned. So, this would be conventional. Technically, my point 3. above applies to this case. The caller already has obj, so why return a reference to it? In this case the answer is: The reference is returned for convenience.

I would say that the advice of the book applies well to functional programming paradigm.

Object oriented programming paradigm is quite different. A member function that modifies *this is in fact a function with an output parameter - the parameter being the implicit *this object - that is modified. So, the quoted rule of thumb can be seen as a recommendation against setter functions... or it could be seen as not being intended to apply to object oriented programming.

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • Thank you very much. Now it is clear enough. I do return-by-reference for member functions that can be called in chain, for example, `obj.DoX(...).DoY(...).DoZ(...);`. – Second Person Shooter Mar 07 '21 at 04:17
  • 2
    @ArtificialStupidity Method chaining is an idiom where a reference to `*this` is generally returned. It depends on use case whether one is better than the other. – eerorika Mar 07 '21 at 04:19
-5

The section of the book you have quoted is clearly talking about pass-by-reference output parameters. This question is based on an entirely flawed assumption.

The book is not stating that a const Val& return signature is less recommended than a Val return signature. Perhaps the author was, however, being unclear.

Patrick Parker
  • 4,863
  • 4
  • 19
  • 51
  • 1
    How exactly is the book *talking about pass-by-reference output parameters* relevant to OP's question about returning a reference? – eerorika Mar 07 '21 at 04:26
  • OP is clearly trying to understand the book they are reading. The accepted answer is leading them down a false path. – Patrick Parker Mar 07 '21 at 04:27
  • 5
    As far as I can tell, OP is trying to understand why the book suggests returning a value (instead of passing output parameter) rather than suggesting returning a reference (instead of passing output parameter). Besides, if you interpret the question being about understanding what the book says, how does "the section is clearly talking about it" help to understand what it means? – eerorika Mar 07 '21 at 04:28
  • "The book is not stating that a const Val& return signature is less recommended than a Val return signature." The quoted sentence is the OP's fundamental misunderstanding that the accepted answer failed to address. – Patrick Parker May 04 '21 at 04:07