int foo(type& bar); is a bad practice?

Question

Well, here we are. Yet another proposed practice that my C++ book has an opinion on. It says "a returning-value(non-void) function should not take reference types as a parameter." So basically if you were to implement a function like this:

int read_file(int& into){
   ...
}

and used the integer return value as some sort of error indicator (ignoring the fact that we have exceptions) then that function would be poorly written and it should actually be like

void read_file(int& into, int& error){

}

Now to me, the first one is much clearer and nice to use. If you want to ignore the error value, you do so with ease. But this book suggests the later. Note that this book does not say returning value functions are bad. It rather says that you should either only return a value or you should only use references.

What are your thoughts on this? Is my book full of crap? (again)

Answer 1

The advice is silly. A direct return value is much smaller and easier to type.

Direct return:

if (read_file(...)) {
    ... handle problem ...
}

Indirect return:

int status;

read_file(..., status);
if (status) {
    ... handle problem ...
}

Edit: a bigger issue is whether to use non-const reference parameters at all. It can be surprising to have side effects come flying out of the parameters. One coding standard says that reference parameters should be const and output parameters should use pointers. That way the reader gets a & at the point of call that shouts out "something happens to this parameter".

Answer 2

I think it's more important to be consistent across a project than to evangelize one way as better than another.

Answer 3

It's a rather uninteresting and subjective style debate. Personally I'd rather return a std::pair, a struct, or (in TR1) a tuple.

Answer 4

They are attempting to teach you the practice of "if you return a value, do not modify the variables in the call parameters"

Instead, you can do something like the following:

int read_file(const int& into){ ... }

My syntax might be slightly off, but the const tells it you cannot change it inside the method, but you still get the pass by reference, which is nice with objects. With the int, it doesn't really buy you anything.

---

Edit: Additionally, as others have noted, if your goal is to have multiple return values, then it is usually a better idea to either do as the book suggests, or to instead create a "composite" return type - use a pair, your own custom type, etc.

Answer 5

//somewhere deep in the code space
a = func(i); //i is modified inside func() or not?    
j = i; //what is this for? depends on the answer to the first question

If the code was written with respect to the rule that the book suggests, you can be sure that "i" is not modified just by looking at the call site, thus the code says more to you than otherwise

Anyway, I would prefer to return a tuple, not modifying by reference