In dynamically typed languages like JavaScript or PHP, I often do functions such as:
function getSomething(name) {
if (content_[name]) return content_[name];
return null; // doesn't exist
}
I return an object if it exists or null
if not.
What would be the equivalent in C++ using references? Is there any recommended pattern in general? I saw some frameworks having an isNull()
method for this purpose:
SomeResource SomeClass::getSomething(std::string name) {
if (content_.find(name) != content_.end()) return content_[name];
SomeResource output; // Create a "null" resource
return output;
}
Then the caller would check the resource that way:
SomeResource r = obj.getSomething("something");
if (!r.isNull()) {
// OK
} else {
// NOT OK
}
However, having to implement this kind of magic method for each class seems heavy. Also it doesn't seem obvious when the internal state of the object should be set from "null" to "not null".
Is there any alternative to this pattern? I already know it can be done using pointers, but I am wondering how/if it can be done with references. Or should I give up on returning "null" objects in C++ and use some C++-specific pattern? Any suggestion on the proper way to do that would be appreciated.
You cannot do this during references, as they should never be NULL. There are basically three options, one using a pointer, the others using value semantics.
With a pointer (note: this requires that the resource doesn't get destructed while the caller has a pointer to it; also make sure the caller knows it doesn't need to delete the object):
Using
std::pair
with abool
to indicate if the item is valid or not (note: requires that SomeResource has an appropriate default constructor and is not expensive to construct):Using
boost::optional
:If you want value semantics and have the ability to use Boost, I'd recommend option three. The primary advantage of
boost::optional
overstd::pair
is that an unitializedboost::optional
value doesn't construct the type its encapsulating. This means it works for types that have no default constructor and saves time/memory for types with a non-trivial default constructor.I also modified your example so you're not searching the map twice (by reusing the iterator).
One nice and relatively non-intrusive approach, which avoids the problem if implementing special methods for all types, is that used with boost.optional. It is essentially a template wrapper which allows you to check whether the value held is "valid" or not.
BTW I think this is well explained in the docs, but beware of
boost::optional
ofbool
, this is a construction which is hard to interpret.Edit: The question asks about "NULL reference", but the code snippet has a function that returns by value. If that function indeed returned a reference:
then the function would only make sense if the
someResource
being referred to had a lifetime at least as long as that of the object returning the reference (otherwise you woul dhave a dangling reference). In this case, it seems perfectly fine to return a pointer:but you have to make it absolutely clear that the caller does not take ownership of the pointer and should not attempt to delete it.
Why "besides using pointers"? Using pointers is the way you do it in C++. Unless you define some "optional" type which has something like the
isNull()
function you mentioned. (or use an existing one, likeboost::optional
)References are designed, and guaranteed, to never be null. Asking "so how do I make them null" is nonsensical. You use pointers when you need a "nullable reference".
This code below demonstrates how to return "invalid" references; it is just a different way of using pointers (the conventional method).
Not recommended that you use this in code that will be used by others, since the expectation is that functions that return references always return valid references.
The macro
Nothing(Type)
returns a value, in this case that represented bynullptr
- you can as well use0
, to which the reference's address is set. This address can now be checked as-if you have been using pointers.Here are a couple of ideas:
Alternative 1:
Alternative 2:
Yet another option - one that I have used from time to time for when you don't really want a "null" object returned but instead an "empty/invalid" object will do:
Its quite simple and (depending on what you are doing with it at the other end) can avoid the need to do null pointer checks on the other side. For example if you are generating some lists of thing, e.g: