Why use boost::optional when I can return a pointer

Question

If I have a find function that can sometimes fail to find the required thing, I tend to make that function return a pointer such that a nullptr indicates that the thing was not found.

E.g.

Student* SomeClass::findStudent(/** some criteria. */)

If the Student exists, it will return a pointer to the found Student object, otherwise it will return nullptr.

I've seen boost::optional advocated for this purpose as well. E.g. When to use boost::optional and when to use std::unique_ptr in cases when you want to implement a function that can return "nothing"?

My question is, isn't returning a pointer the best solution in this case. i.e. There is a possibility that the queried item will not be found, in which case returning nullptr is a perfect solution. What is the advantage of using something like boost::optional (or any other similar solution)?

Note that, in my example, findStudent will only ever return a pointer to an object that is owned by SomeClass.

Answer 1

The advantage of an optional<Student&> return type here is that the semantics of usage are readily apparent to all users that are familiar with optional (and will become readily apparent once they familiarize themselves with it). Those semantics are:

• The caller does not own the Student and is not responsible for memory management. The caller simply gets a reference to an existing object.
• It is clear that this function can fail. You maybe get a value and you maybe get nothing. It is clear that the caller needs to check the result one way or the other.

optional<T> is self-documenting in a way that T* isn't. Moreover, it has other benefits in that it can work in cases where you want to return any kind of object type without the need for allocation. What if you needed to return an int or double or SomePOD?