c++17 – Thoughts and Applications in C++

std::optional is a useful C++17 feature for knowing when a value is set. There’s been some debate however as to its usefulness for 2 forms.

1. std::optional<bool>
2. std::optional<T*>

Both forms are criticized for being confusing to readers. Considering that this post stems from having to explain recently what it means when std::optional wraps a pointer, I’m inclined to agree. The code below shows where the confusion lies:

std::optional<SomeDataType*> myval;
...
myval = nullptr;

if (myval)
// ?? Is this true or false?

In the highlightedline of the if statement, does will the value evaluate as true or false? It, in fact, does evaluate as true, and the value of operator bool is true. This is where the confusion is though. Some developers see std::optional as a simplified version of a wayt to wrap a pointer, similar to a smartptr. But it is quite different. In this case having set the value, even to nullptr, means the variable is “set”, so to speak. It may not sound very useful, but there are some cases, were knowing if a value is set, where nullptr is a valid value, is useful. The example below of a fast cache that shows that usefulness:

Rvalue references are generally used to signal a value that will no longer be used by the caller. Could be a temporary value who’s lifetime will expire when the call returns, or an lvalue which is wrapped with a std::moveto signal it will no longer be used any further. If this isn’t old news, you can review a short description here or with your favorite search engine.

When we bind an rvalue with a function call, the usual form is:


void f(A&& a)
{
   A a1;
   a1.data = a.data;
  
   // rvalue reference a is “moved” from. 
   a.data = nullptr;

   // Note: you'd likely use a swap, 
   // but this is clearer.
}

This is pretty standard stuff. Instead of making a possibly expensive copy of what member variable data contained, we take over the pointer. What this implies is that the parameter a, is modified. The very notion of rvlaue references is based on the idea that we no longer need what was passed as an argumen to the function once the call is returned, and we can extract what we need from it, and leave it in valid, yet unspecified state. But, what if the parameter was set as const in the signature?

void f(const A&& a)

What would this be??? The parameter is const, meaning we can’t extract and “steal” the underlying data in parameter a like we did above. This implies were back to the slow lane of copying if we need to copy and not just access the parameter. Binding wise, a const rvalue can already bind to this overload:

Tag: c++17

std::optional – removing confusion around pointer types

const rvalue references – useful use-cases