C++ – Non-Optional Pointers vs Non-Const References

ccoding-standardscoding-styleout-parameters

In Other C++ Features, Reference Arguments of the Google C++ Style Guide, I read that non-const references must not be used.

All parameters passed by reference must be labeled const.

It is clear that looking at function calls that use references as arguments is absolutely confusing for C programmers, but C and C++ are different languages now. If an output parameter is required, using a pointer for a required output parameter, may cause the whole function body to be skipped, which makes the implementation of a function more complicated (formally increases the cyclomatic complexity and depth of a function).

I'd like to make C++ code as easy to understand/maintain as possible, so I'm generally interested to read coding style guides. But as to adapt best practices in a team, I think that understanding the rationale behind style guide elements is an important factor.

Are non-const references really that bad? Is banning them only Google specific or is it a commonly accepted rule? What justifies the extra effort for implementing output parameters as pointers?

Best Answer

The rationale behind Google's style guide is simply to make it clear from a function's call site whether a parameter is an input parameter or an output parameter. (See here for further discussion.) Other languages make out parameters explicit by design; C#, for example, has an out keyword that must be used at the call site. Since C++ doesn't make it explicit, Google chose to use const ref. versus pointer to make it clear.

Is this only a Google rule? No, but I doubt it's very widespread. I don't think I've seen it outside of Google's style guide and groups that explicitly adhere to parts of the Google style guide. (For example, I liked the idea when I first read the Google style guide years ago and have used it for some of my own code.)

In particular, the newly announced C++ Core Guidelines prefer return values to output parameters for (almost) everything and uses non-const refs for the rest. Google's use of pointers versus references might make output parameters clearer, but return values are clearer still. Now that C++11 has standardized moves (rvalue references, &&, to make returns of many types cheap) and tuples (allowing an easy way to return multiple values), many of the use cases for out parameters no longer apply.

The C++ Core Guidelines have some big names (Bjarne Stroustrup, Herb Sutter) behind them, are supported by Microsoft, and embrace the latest C++ features (unlike Google's style guide), so I expect its recommendations to be more popular than Google's.

Related Solutions

C++ Coding Style – unique_ptr and References Best Practices

foo.GetBar().DoSomething();

This violates the Law Of Demeter.

Generally I would avoid exposing Bar entirely:

foo::doBarSomething() { this->bar.doSomething(); }

C++ – Use Cases for Non-Const Reference Parameters

Yes, so the function can change thing.

In general, it is best to put the behavior on the object itself. In other words, prefer this:

class Thing {
public:
  void do_stuff() {
    ...
  }
};

...to this:

void do_stuff( Thing & thing ) {
  ...
}

However, both examples are perfectly valid and usable. One good example of a non-member non-const reference parameter is stream extraction operators. This Stack Overflow question goes into more detail: Does anyone actually use stream extraction operators? The general idea is this:

operator>>(std::istream &, Thing &)

The function cannot exist as part of the Thing class because the left-hand is not an object of the class. It also needs to modify a Thing object so the reference cannot be const.

Best Answer

Related Solutions

C++ Coding Style – unique_ptr and References Best Practices

C++ – Use Cases for Non-Const Reference Parameters

Related Topic