Obtaining an object with pointer and reference

Question

Lets assume we have an object created statically (Type mObject;) which is exposed to the programmer by using getObject() method. I wonder what are the advantages and disadvantages in getting the object in such ways?

Type* SomeClass::getObject() {
    return &mObject;
}

// the programmer types
Type* obj = someClassObj.getObject();
obj->someMethod();

and this way:

Type& SomeClass::getObject() {
    return mObject;
}

// the programmer types
Type& obj = someClassObj.getObject();
obj.someMethod();

The former API almost encourages the programmer to call `delete` when done with the object, or at the very least leaves him wondering how to clean up. — Joachim Isaksson, Jun 02 '13 at 08:51
In the first case, you will have to document who owns the returned pointer, and hope that clients read the docs. Note that both have const-correctness issues. — juanchopanza, Jun 02 '13 at 08:52
In the first case you could return NULL, so the caller needs to check this. — spiritwolfform, Jun 02 '13 at 08:55
If you're "allowing" the user of your class to modify the returned object (the member), then use references or pointers. However, if you don't need that kind of "behavior", it may be better to just return a copy of the member. — Mark Garcia, Jun 02 '13 at 09:03
@MarkGarcia I think you are wrong (or possibly I'm not getting what you mean.) References and pointers can be `const`, therefore disallowing modification (in a clear and well-understood way.) And returning a copy does *not* disallow modification, it just means the object the user is modifying is not the same object you are holding! Also, returning a copy has the disadvantage of having to copy the object; think about returning a million-element vector you are holding by value (which means a copy, and not a move.) — yzt, Jun 02 '13 at 09:10

score 5 · Accepted Answer · answered Jun 02 '13 at 10:06

In pure C++ we use pointers quite rarely. Especially raw pointers.

Most of the code deal with object instances. As C++ have references to refer to them by identity, unlike C, taking address and passing around a pointer is reserved for situations where it is a must. Like:

when you want NULL to indicate absence
when you want to switch to different objects (reassign the pointer)
when you transfer ownership

Your example fits neither category, so you use a reference. This carries the message to the user that an object will always be there. So there's most time little point to fix the obj, you can just go ahead with someClassObj.getObject().someMethod(). The first case wants a NULL check in between.

excellent, comprehensive and concise! – davka Jun 02 '13 at 11:59 — davka, Jun 02 '13 at 11:59

justin · Answer 2 · 2013-06-02T10:46:39.743

Returning a pointer raises a lot of ambiguity/questions (could it be NULL? must I delete it?), while returning a reference to this static instance introduces guarantees. Namely, that the object will always be allocated and will always return an instance (technically, that static instance may not be constructed if you access it during initialization).

Although it is implementation defined, all implementations I know of use pointers "under the hood" when passing by reference (in the worst case). So there is no added cost to using a reference unless a copy or promotion must be introduced.

In this case, you should return a reference. In most C++ circles, references are favored over pointers when they provide all the functionality you need.

Obtaining an object with pointer and reference

2 Answers2