Value of passing by reference

Question

In C++, we have the option to pass by reference or pass by value.

The client code does not need to know which one a parent function uses; that is, int func(int param) and int func(int &param) are called in exactly the same manner from the client code. Isn't this dangerous?

If I'm writing code on the client side, I don't know which of the variables I pass to a function might be changed and which I can expect to remain the same without an explicit knowledge of the parent function declaration. What is the advantage of doing it this way versus explicitly expecting a pointer (e.g., int func(int *param), which would then be called func(&param);)?

When you have to have a pointer, it's easy enough for the client to know which values may be modified - the ones that have an & in front. Alternatively, why not have everything be pass-by-reference, so that there is no guess-work of "Can this function change this value?" The answer is universally yes.

Answer 1

If I'm writing code on the client side, I don't know which of the variables I pass to a function might be changed and which I can expect to remain the same without an explicit knowledge of the parent function declaration.

This is as it should be. When you call an API, you should know what you are calling and why. You should also know what the function does and what it's side effects are (and preconditions and postconditions as well).

What is the advantage of doing it this way versus explicitly expecting a pointer (e.g., int func(int *param), which would then be called func(&param);)?

I will assume that "doing it this way" means "passing by reference".

It seems to me you make the association "received by pointer = may be changed". This is incorrect.

Here are two scenarios when passing by reference/pointer is prefered over the alternative:

• operators:

  class EvenInteger { int value; public: /*...*/ }; // 0, 2, 4, 6, ...
  
  EvenInteger operator +(const EvenInteger& x, const EvenInteger&y);
  

  Here, passing by reference would disble the operator for temporary values, passing by pointer would result in client code like this:

  EvenInteger a{0}, b{122};
  auto c = &a + &b; // addition by address imposed if operator received pointers
  

• instance observer (naturally pass 'this' as an argument):

  class Collection // collection/sequence of arbitrary objects of type Obj
  {
  public:
      class InterestingIterator {
          Collection* parent;
          InterestingIterator(Collection* c); // accessible by Collection
      public:
          // ...
      }
  
      InterestingIterator begin() { return InterestingIterator{this}; }
  };
  

  The implementation of begin, naturally receives a this pointer, without implying it is in any way a return value. Writing the iterator to receive a reference imposes the *this construct on client code.

As a rule, the interface of an API should tell you this:

void f(int x); // makes own copy of x, doesn't return/alter value
void f(int& x); // _may_ alter value (check docs)
void f(int* x); // _may_ alter value, or populate it with a return (check docs)
void f(const int& x); // observer of x
void f(int* const x); // _may_ alter value pointed by x, but not the address
void f(const int* x); // _may_ alter address, but not the pointed value
void f(const int* const x); // observer of value and address

As you can see, you should (always) rely on an API's documentation. If you rely on a function signature, it can only tell you when it doesn't alter it's received parameters, and you see that through const, not through the parameter type (address/reference/etc).

This also implies that you should always write documentation for your APIs.

Answer 2

The differences between references and pointers have been extensively discussed, sometimes even here. That discussion probably shouldn't be re-started.

But the other question - "Why not have everything as X or Y?" is easily answered. C++ gives you both options as a matter of principle, because you might want to use X, but you also might want to use Y.

In such cases the language virtually always offers both on the principle that if one of the two allows a solution that is even slightly better, more effective etc., then the language must contain both. Recall that you can even write your own class-specific memory allocators and deallocators. The language designers are firmly of the opinion that at least some of their users will be able to build a better special-purpose allocator than they could build into the compiler, so they mustn't do anything that prevents this. This is part of the reason why C++ has such an extraordinarily rich set of interacting features, even when they are only slightly different.