When is it preferable to store data members as references instead of pointers?

Question

Let's say I have an object Employee_Storage that contains a database connection data member. Should this data member be stored as a pointer or as a reference?

• If I store it as a reference, I don't have to do any NULL checking. (Just how important is NULL checking anyway?)

• If I store it as a pointer, it's easier to setup Employee_Storage (or MockEmployee_Storage) for the purposes of testing.

Generally, I've been in the habit of always storing my data members as references. However, this makes my mock objects difficult to set up, because instead of being able to pass in NULLs (presumably inside a default constructor) I now must pass in true/mock objects.

Is there a good rule of thumb to follow, specifically with an eye towards testability?

Answer 1

It is almost never prefereable to store references as data members, and a lot of the time it is impossible. If the objects must be assignable (as they must to be stored in a standard library container), references cannot be used. Also, references cannot be reseated, so once a reference is initialised with an object, it cannot be made to refer to a different object.

See this question http://stackoverflow.com/questions/892133/should-i-prefer-pointers-or-references-in-member-data for a more detailed discussion of the issue.

Answer 2

It's only preferable to store references as data members if they're being assigned at construction, and there is truly no reason to ever change them. Since references cannot be reassigned, they are very limited.

In general, I typically store as pointers (or some form of templated smart pointer). This is much more flexible - both for testing (as you mentioned) but also just in terms of normal usage.

Answer 3

Given a choice, I like to use the most constrained type possible. So if I don't need to support null objects I'd much prefer to declare a

Foo& m_foo;

member rather than a

Foo*const m_foo;

member, because the former declaration documents the fact that m_foo can't be null. In the short term, the advantage isn't that great. But in the long run, when you come back to old code, the instant assurance that you don't have to worry about the case of m_foo being null is quite valuable.

There are other ways of achieving a similar effect. One project I worked on where they didn't understand references would insist any potentially null pointers be suffixed '00' e.g m_foo00. Interestingly, boost::optional seems to support references although I haven't tried it. Or you can litter your code with assertions.