2

Consider the following :

int increment1 (const int & x)
{ return x+1; }

int increment2 (const int x)
{ return x+1; }

I understand passing references to class objects an such, but I'm wondering if it's worth to pass reference to simple types ? Which is more optimal ? Passing by reference or passing by value (in case of a simle type?)

Maciek
  • 19,435
  • 18
  • 63
  • 87
  • 1
    Can I add another part to the question? What's the point of the `const` in `increment2` - why should the caller care what the callee does with an argument which is passed by value? – Dominic Rodger Oct 21 '09 at 08:13
  • 1
    The point of const in this case is to keep the function arguments immutable, which is more of a concern for the writer of the function. It ensures that anywhere in the function you are still dealing with the original arguments. – nasmorn Oct 21 '09 at 08:25
  • 1
    `const` has a notable effect on the caller too: You can't call `void f(int &x)` with an integer literal argument like `f(1)` but you can do so if it's declared as `void f(const int &x)`. – Mehrdad Afshari Oct 21 '09 at 08:42
  • 2
    @Mehrdad: Dominic was wondering about `increment2`. In that case, the `const` in the function definition applies only to the implementation. It's not part of the function signature. In `increment1`, it _is_ part of the function signature. – MSalters Oct 21 '09 at 09:09

4 Answers4

6

Unless you need the "call by reference" semantics, i.e. you want to access the actual variable in the callee, you shouldn't use call by reference for simple types.

For a similar, more general discussion see: "const T &arg" vs. "T arg"

Community
  • 1
  • 1
Mehrdad Afshari
  • 414,610
  • 91
  • 852
  • 789
6

Do you also understand premature optimization? :)

Do what is clearest. If the function is going to return the value, it does not need a reference. A (human!) reader of the code might then wonder why a reference is being used, for no good reason.

UPDATE: If you want the function to be called increment(), that (to me) implies it should change the passed-in value, and not return it. It sounds like a modify in place kind of operation. Then it might make sense to use a reference (or pointer), and remove the return value:

void increment(int &value)
{
  ++value;
}

If you're investigating what is fastest, I still think you're optimizing prematurely.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • Scott Meyers and Herb Sutter would disagree. Deciding between pass-by-value and pass-by-ref-to-const is not a matter of premature optimization. – sellibitze Oct 21 '09 at 09:30
0

It maybe doesn't "worth", but it is sometimes different. Consider these functions:

int const* addr_ref    (int const& i)  { return &i; }
int const* addr_byvalue(int const  i)  { return &i; }

They obviously return different values. So sometimes it's useful.

In the meantime you should stick to your coding convention. Most likely compiler's optimization within the function will discard unnecessary dereferences, and in the caller code it was using reference as well, so the performance is hardly an issue here.

P Shved
  • 96,026
  • 17
  • 121
  • 165
0

If the functions are templated you have a harder time making the choice. Should T be accepted by value or by const reference, when you don't know how big or expensive to copy T is?

In this case I would prefer passing by const reference. If the size of T is less than or equal to the size of a reference, it's possible for the compiler to perform an optimisation: it simply passes the parameter by value anyway, because a const reference parameter promises not to modify the parameter, so the side effects are the same. However, the compiler may also choose not to perform this optimisation, especially if it has trouble working out if there are any const_casts involved and such.

But for that reason, I would side with passing by const reference - it's possible, but not certain, that a clever compiler can choose the correct pass method for you, depending on the size of the type and the architecture.

AshleysBrain
  • 22,335
  • 15
  • 88
  • 124
  • I don't think a compiler is allowed to replace "int const&" with "int const" behind the curtains. At least not in the multi-threading day and age where this would make an observable difference w.r.t. data sharing and races. – sellibitze Oct 21 '09 at 11:01
  • I think it can, for the same reason it can reasonably cache common subexpressions etc. - you'd have to explicitly mark it a volatile const reference to get that point across to the compiler and prevent it doing that. – AshleysBrain Oct 21 '09 at 12:38
  • That's different. Under the as-if rules a compiler could only do that if it can prove that such a transformation would not make any observable difference. But it might in a multi-threaded case. The function may later access the referenced int with proper synchronization and count on it to change in another thread. – sellibitze Oct 22 '09 at 08:25