Return by Reference to a Pointer, Huh?

Recap

Quick recap, for those who may be hazy on what a reference is in C++:

When a variable is returned by reference, a reference to the variable is passed back to the caller. The caller can then use this reference to continue modifying the variable, which can be useful at times. Return by reference is also fast, which can be useful when returning structs and classes.

In even plainer words, the compiler is not creating a copy of the variable onto the stack of the function but simply passing the reference (i.e. sort of similar to a pointer).

Here is the kicker and what is important to remember; in C++ everything is passed by value (copied) onto the function stack unless it has the ‘&’ symbol denoting a reference.

Reference to Pointer

When is a reference to a pointer useful? Consider the example below.

What would you expect to be the output of the program? If you guessed 5 you’d be correct. The reason why it is 5 and not 7, is because even the pointer itself is copied onto the function stack and the reassignment only modifies that copy of the pointer’s value and not the pointer from main’s scope!

How to solve this dilemma?

Traditionally the way to solve this problem (most commonly seen for link list problems for instance), is to pass a Pointer to a Pointer. This way we are passing an extra level of indirection to the pointer and therefore any modification to the pointer would continue passed the function’s scope. This works because now we are creating a copy of the address of the second level indirection. The example would change to become:

Another way that solve this problem however is by simply passing a reference to a pointer like so:

In the return!

Up until this point, a lot of this should be common place in most code bases. What I found interesting however in the code I’m currently working on at my current job, are functions that return a reference to a pointer. Consider the example below:

The output of theInt and myObject would both be 10. The ability to do this seems odd as it is a good source of memory leaks and un-intuitive to me.

Can someone point me to some good use cases of how this can be useful?

4 Replies to “Return by Reference to a Pointer, Huh?”

  1. I’m not sure that returning references to pointers (or pointers to non-const pointers) is a very healthy thing to do. It breaks encapsulation pretty hard and makes tracking ownership very difficult. Consider the case where MyIntClass returns an int pointer ref (or pointer to non-const pointer to int) and stores that pointer. MyIntClass’ consumers now have a direct pointer/reference to state that is internal to MyIntClass, as does anyone that the consumers pass that pointer to. They can change (at their absolute whim) the internal state of MyIntClass without obeying any kind of explicit contract formed by MyIntClass’ interface, and worse yet they can make other methods unknowing users of MyIntClass. If MyInClass instead had a pair of methods of the form: int get_my_int() const, and void set_my_int(const int my_int), MyIntClass now retains control over its implementation. If, in the future, you need locking or logging or some other form of accountability for the value of myInt you can add it to the accessor and mutator methods.

  2. @Garret Kelly: I totally agree that it does seem to break encapsulation.
    The only way they have managed to do it correctly is because (matching the example above) myIntP is actually a shared_ptr. They like to use the class object as an LValue and use the getter to then perform a re-assign to the pointer.
    It’s odd and I wouldn’t do it….
    I actually dislike references and prefer to return pointers of pointers instead. Passing a pointer is explicit whereas if it’s by reference it’s implicit and you might not know unless you go double check the function definition.

Leave a Reply

Your email address will not be published. Required fields are marked *