A similar situation occurs with function (C): it is conceptually an error
to ask a <spanclass="emphasis"><em>null-area</em></span> polygon to return a point inside
itself, but in many applications, it is just impractical for performance
reasons to treat this as an error (because detecting that the polygon has
no area might be too expensive to be required to be tested previously), and
either an arbitrary point (typically at infinity) is returned, or some efficient
way to tell the callee that there is no such point is used.
</p>
<p>
There are various mechanisms to let functions communicate that the returned
value is not valid. One such mechanism, which is quite common since it has
zero or negligible overhead, is to use a special value which is reserved
to communicate this. Classical examples of such special values are <codeclass="computeroutput"><spanclass="identifier">EOF</span></code>, <codeclass="computeroutput"><spanclass="identifier">string</span><spanclass="special">::</span><spanclass="identifier">npos</span></code>,
When those values exist, i.e. the return type can hold all meaningful values
<spanclass="emphasis"><em>plus</em></span> the <spanclass="emphasis"><em>signal</em></span> value, this mechanism
is quite appropriate and well known. Unfortunately, there are cases when
such values do not exist. In these cases, the usual alternative is either
to use a wider type, such as <codeclass="computeroutput"><spanclass="keyword">int</span></code>
in place of <codeclass="computeroutput"><spanclass="keyword">char</span></code>; or a compound
type, such as <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">pair</span><spanclass="special"><</span><spanclass="identifier">point</span><spanclass="special">,</span><spanclass="keyword">bool</span><spanclass="special">></span></code>.
Returning a <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">pair</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">,</span><spanclass="keyword">bool</span><spanclass="special">></span></code>, thus attaching a boolean flag to the
result which indicates if the result is meaningful, has the advantage that
can be turned into a consistent idiom since the first element of the pair
can be whatever the function would conceptually return. For example, the
last two functions could have the following interface:
intends to formalize the notion of initialization (or lack of it) allowing
a program to test whether an object has been initialized and stating that
access to the value of an uninitialized object is undefined behavior. That
is, when a variable is declared as <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code> and no initial value is given, the
variable is <spanclass="emphasis"><em>formally</em></span> uninitialized. A formally uninitialized
optional object has conceptually no value at all and this situation can
be tested at runtime. It is formally <spanclass="emphasis"><em>undefined behavior</em></span>
to try to access the value of an uninitialized optional. An uninitialized
optional can be assigned a value, in which case its initialization state
changes to initialized. Furthermore, given the formal treatment of initialization
states in optional objects, it is even possible to reset an optional to
In C++ there is no formal notion of uninitialized objects, which means
that objects always have an initial value even if indeterminate. As discussed
on the previous section, this has a drawback because you need additional
information to tell if an object has been effectively initialized. One
of the typical ways in which this has been historically dealt with is via
a special value: <codeclass="computeroutput"><spanclass="identifier">EOF</span></code>,
<codeclass="computeroutput"><spanclass="identifier">npos</span></code>, -1, etc... This is
equivalent to adding the special value to the set of possible values of
a given type. This super set of <codeclass="computeroutput"><spanclass="identifier">T</span></code>
plus some <spanclass="emphasis"><em>nil_t</em></span>—where <codeclass="computeroutput"><spanclass="identifier">nil_t</span></code>
is some stateless POD—can be modeled in modern languages as a <spanclass="bold"><strong>discriminated union</strong></span> of T and nil_t. Discriminated
unions are often called <spanclass="emphasis"><em>variants</em></span>. A variant has a
<spanclass="emphasis"><em>current type</em></span>, which in our case is either <codeclass="computeroutput"><spanclass="identifier">T</span></code> or <codeclass="computeroutput"><spanclass="identifier">nil_t</span></code>.
Using the <ahref="../../../../variant/index.html"target="_top">Boost.Variant</a>
library, this model can be implemented in terms of <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">::</span><spanclass="identifier">variant</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">,</span><spanclass="identifier">nil_t</span><spanclass="special">></span></code>. There is precedent for a discriminated
union as a model for an optional value: the <ahref="http://www.haskell.org/"target="_top">Haskell</a>
<spanclass="bold"><strong>Maybe</strong></span> built-in type constructor. Thus,
a discriminated union <codeclass="computeroutput"><spanclass="identifier">T</span><spanclass="special">+</span><spanclass="identifier">nil_t</span></code>
serves as a conceptual foundation.
</p>
<p>
A <codeclass="computeroutput"><spanclass="identifier">variant</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">,</span><spanclass="identifier">nil_t</span><spanclass="special">></span></code> follows naturally from the traditional
idiom of extending the range of possible values adding an additional sentinel
value with the special meaning of <spanclass="emphasis"><em>Nothing</em></span>. However,
this additional <spanclass="emphasis"><em>Nothing</em></span> value is largely irrelevant
for our purpose since our goal is to formalize the notion of uninitialized
objects and, while a special extended value can be used to convey that
meaning, it is not strictly necessary in order to do so.
</p>
<p>
The observation made in the last paragraph about the irrelevant nature
of the additional <codeclass="computeroutput"><spanclass="identifier">nil_t</span></code>
with respect to <spanclass="underline">purpose</span> of <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code>
suggests an alternative model: a <spanclass="emphasis"><em>container</em></span> that either
has a value of <codeclass="computeroutput"><spanclass="identifier">T</span></code> or nothing.
</p>
<p>
As of this writing I don't know of any precedent for a variable-size fixed-capacity
(of 1) stack-based container model for optional values, yet I believe this
is the consequence of the lack of practical implementations of such a container
rather than an inherent shortcoming of the container model.
</p>
<p>
In any event, both the discriminated-union or the single-element container
models serve as a conceptual ground for a class representing optional—i.e.
possibly uninitialized—objects. For instance, these models show the
<spanclass="emphasis"><em>exact</em></span> semantics required for a wrapper of optional
between containers compare container size and if match, contained value
</li>
<liclass="listitem">
If the container is not empty (contains an object of type <codeclass="computeroutput"><spanclass="identifier">T</span></code>), it is modeling an <spanclass="emphasis"><em>initialized</em></span>
optional.
</li>
<liclass="listitem">
If the container is empty, it is modeling an <spanclass="emphasis"><em>uninitialized</em></span>
optional.
</li>
<liclass="listitem">
Testing if the container is empty models testing if the optional is
initialized
</li>
<liclass="listitem">
Trying to extract a <codeclass="computeroutput"><spanclass="identifier">T</span></code>
from an empty container models the undefined behavior of trying to
Objects of type <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code> are intended to be used in places where
objects of type <codeclass="computeroutput"><spanclass="identifier">T</span></code> would
but which might be uninitialized. Hence, <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code>'s purpose is to formalize the additional
possibly uninitialized state. From the perspective of this role, <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code>
can have the same operational semantics of <codeclass="computeroutput"><spanclass="identifier">T</span></code>
plus the additional semantics corresponding to this special state. As such,
could be thought of as a <spanclass="emphasis"><em>supertype</em></span> of <codeclass="computeroutput"><spanclass="identifier">T</span></code>. Of course, we can't do that in C++,
so we need to compose the desired semantics using a different mechanism.
Doing it the other way around, that is, making <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code> a <spanclass="emphasis"><em>subtype</em></span> of
<codeclass="computeroutput"><spanclass="identifier">T</span></code> is not only conceptually
wrong but also impractical: it is not allowed to derive from a non-class
We can draw from the purpose of <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code> the required basic semantics:
Since the purpose of optional is to allow us to use objects with a formal
uninitialized additional state, the interface could try to follow the interface
of the underlying <codeclass="computeroutput"><spanclass="identifier">T</span></code> type
as much as possible. In order to choose the proper degree of adoption of
the native <codeclass="computeroutput"><spanclass="identifier">T</span></code> interface,
the following must be noted: Even if all the operations supported by an
instance of type <codeclass="computeroutput"><spanclass="identifier">T</span></code> are
defined for the entire range of values for such a type, an <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code>
extends such a set of values with a new value for which most (otherwise
valid) operations are not defined in terms of <codeclass="computeroutput"><spanclass="identifier">T</span></code>.
</p>
<p>
Furthermore, since <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code> itself is merely a <codeclass="computeroutput"><spanclass="identifier">T</span></code>
wrapper (modeling a <codeclass="computeroutput"><spanclass="identifier">T</span></code> supertype),
any attempt to define such operations upon uninitialized optionals will
be totally artificial w.r.t. <codeclass="computeroutput"><spanclass="identifier">T</span></code>.
</p>
<p>
This library chooses an interface which follows from <codeclass="computeroutput"><spanclass="identifier">T</span></code>'s
interface only for those operations which are well defined (w.r.t the type
<codeclass="computeroutput"><spanclass="identifier">T</span></code>) even if any of the operands
are uninitialized. These operations include: construction, copy-construction,
assignment, swap and relational operations.
</p>
<p>
For the value access operations, which are undefined (w.r.t the type <codeclass="computeroutput"><spanclass="identifier">T</span></code>) when the operand is uninitialized,
a different interface is chosen (which will be explained next).
</p>
<p>
Also, the presence of the possibly uninitialized state requires additional
operations not provided by <codeclass="computeroutput"><spanclass="identifier">T</span></code>
itself which are supported by a special interface.
<spanclass="special">=</span><spanclass="number">2</span><spanclass="special">)</span></code> and <codeclass="computeroutput"><spanclass="special">(</span>
<spanclass="identifier">p</span><spanclass="special">-></span><spanclass="identifier">foo</span><spanclass="special">()</span><spanclass="special">)</span></code>, implicitly convey the notion of optionality,
and this information is tied to the <spanclass="emphasis"><em>syntax</em></span> of the
expressions. That is, the presence of operators <codeclass="computeroutput"><spanclass="special">*</span></code>
and <codeclass="computeroutput"><spanclass="special">-></span></code> tell by themselves
—without any additional context— that the expression will be undefined
unless the implied pointee actually exist.
</p>
<p>
Such a <spanclass="emphasis"><em>de facto</em></span> idiom for referring to optional objects
can be formalized in the form of a concept: the <ahref="../../../../utility/OptionalPointee.html"target="_top">OptionalPointee</a>
concept. This concept captures the syntactic usage of operators <codeclass="computeroutput"><spanclass="special">*</span></code>, <codeclass="computeroutput"><spanclass="special">-></span></code>
and contextual conversion to <codeclass="computeroutput"><spanclass="keyword">bool</span></code>
to convey the notion of optionality.
</p>
<p>
However, pointers are good to <spanclass="underline">refer</span>
to optional objects, but not particularly good to handle the optional objects
in all other respects, such as initializing or moving/copying them. The
problem resides in the shallow-copy of pointer semantics: if you need to
effectively move or copy the object, pointers alone are not enough. The
problem is that copies of pointers do not imply copies of pointees. For
example, as was discussed in the motivation, pointers alone cannot be used
to return optional objects from a function because the object must move
outside from the function and into the caller's context.
</p>
<p>
A solution to the shallow-copy problem that is often used is to resort
to dynamic allocation and use a smart pointer to automatically handle the
details of this. For example, if a function is to optionally return an
object <codeclass="computeroutput"><spanclass="identifier">X</span></code>, it can use <codeclass="computeroutput"><spanclass="identifier">shared_ptr</span><spanclass="special"><</span><spanclass="identifier">X</span><spanclass="special">></span></code>
as the return value. However, this requires dynamic allocation of <codeclass="computeroutput"><spanclass="identifier">X</span></code>. If <codeclass="computeroutput"><spanclass="identifier">X</span></code>
is a built-in or small POD, this technique is very poor in terms of required
resources. Optional objects are essentially values so it is very convenient
to be able to use automatic storage and deep-copy semantics to manipulate
optional values just as we do with ordinary values. Pointers do not have
this semantics, so are inappropriate for the initialization and transport
of optional values, yet are quite convenient for handling the access to
the possible undefined value because of the idiomatic aid present in the
For value access operations <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><></span></code> uses operators <codeclass="computeroutput"><spanclass="special">*</span></code>
and <codeclass="computeroutput"><spanclass="special">-></span></code> to lexically warn
about the possibly uninitialized state appealing to the familiar pointer
However, it is particularly important to note that <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><></span></code> objects are not pointers. <spanclass="underline"><codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><></span></code> is not, and does not model, a
pointer</span>.
</p></td></tr>
</table></div>
<p>
For instance, <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><></span></code> does not have shallow-copy so does
not alias: two different optionals never refer to the <spanclass="emphasis"><em>same</em></span>
value unless <codeclass="computeroutput"><spanclass="identifier">T</span></code> itself is
a reference (but may have <spanclass="emphasis"><em>equivalent</em></span> values). The
difference between an <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code> and a pointer must be kept in mind,
particularly because the semantics of relational operators are different:
since <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code>
is a value-wrapper, relational operators are deep: they compare optional
values; but relational operators for pointers are shallow: they do not
compare pointee values. As a result, you might be able to replace <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code>
by <codeclass="computeroutput"><spanclass="identifier">T</span><spanclass="special">*</span></code>
on some situations but not always. Specifically, on generic code written
for both, you cannot use relational operators directly, and must use the
and <ahref="../../../../utility/OptionalPointee.html#less"target="_top"><codeclass="computeroutput"><spanclass="identifier">less_pointees</span><spanclass="special">()</span></code></a>
<tdalign="right"><divclass="copyright-footer">Copyright © 2003-2007 Fernando Luis Cacciola Carballal<br>Copyright © 2014 Andrzej Krzemieński<p>
Distributed under the Boost Software License, Version 1.0. (See accompanying
file LICENSE_1_0.txt or copy at <ahref="http://www.boost.org/LICENSE_1_0.txt"target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
