mirror of
https://github.com/boostorg/optional.git
synced 2025-07-13 20:36:38 +02:00
Cleaned up docs
This commit is contained in:
Andrzej Krzemienski
@ -4,10 +4,10 @@
|
||||
<title>Design Overview</title>
|
||||
<link rel="stylesheet" href="../../../../../../doc/src/boostbook.css" type="text/css">
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.78.1">
|
||||
<link rel="home" href="../../index.html" title="Chapter 1. Boost.Optional">
|
||||
<link rel="home" href="../../index.html" title="Boost.Optional">
|
||||
<link rel="up" href="../../optional/tutorial.html" title="Tutorial">
|
||||
<link rel="prev" href="motivation.html" title="Motivation">
|
||||
<link rel="next" href="optional_references.html" title="Optional references">
|
||||
<link rel="prev" href="../../optional/tutorial.html" title="Tutorial">
|
||||
<link rel="next" href="design_overview/the_semantics.html" title="The semantics">
|
||||
</head>
|
||||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
|
||||
<table cellpadding="2" width="100%"><tr>
|
||||
@ -20,20 +20,12 @@
|
||||
</tr></table>
|
||||
<hr>
|
||||
<div class="spirit-nav">
|
||||
<a accesskey="p" href="motivation.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../../optional/tutorial.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="optional_references.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
|
||||
<a accesskey="p" href="../../optional/tutorial.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../../optional/tutorial.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="design_overview/the_semantics.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
|
||||
</div>
|
||||
<div class="section">
|
||||
<div class="titlepage"><div><div><h3 class="title">
|
||||
<a name="boost_optional.tutorial.design_overview"></a><a class="link" href="design_overview.html" title="Design Overview">Design Overview</a>
|
||||
</h3></div></div></div>
|
||||
<div class="toc"><dl class="toc">
|
||||
<dt><span class="section"><a href="design_overview.html#boost_optional.tutorial.design_overview.the_models">The
|
||||
models</a></span></dt>
|
||||
<dt><span class="section"><a href="design_overview.html#boost_optional.tutorial.design_overview.the_semantics">The
|
||||
semantics</a></span></dt>
|
||||
<dt><span class="section"><a href="design_overview.html#boost_optional.tutorial.design_overview.the_interface">The
|
||||
Interface</a></span></dt>
|
||||
</dl></div>
|
||||
<div class="section">
|
||||
<div class="titlepage"><div><div><h4 class="title">
|
||||
<a name="boost_optional.tutorial.design_overview.the_models"></a><a class="link" href="design_overview.html#boost_optional.tutorial.design_overview.the_models" title="The models">The
|
||||
@ -175,237 +167,6 @@
|
||||
</li>
|
||||
</ul></div>
|
||||
</div>
|
||||
<div class="section">
|
||||
<div class="titlepage"><div><div><h4 class="title">
|
||||
<a name="boost_optional.tutorial.design_overview.the_semantics"></a><a class="link" href="design_overview.html#boost_optional.tutorial.design_overview.the_semantics" title="The semantics">The
|
||||
semantics</a>
|
||||
</h4></div></div></div>
|
||||
<p>
|
||||
Objects of type <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> are intended to be used in places where
|
||||
objects of type <code class="computeroutput"><span class="identifier">T</span></code> would
|
||||
but which might be uninitialized. Hence, <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code>'s purpose is to formalize the additional
|
||||
possibly uninitialized state. From the perspective of this role, <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code>
|
||||
can have the same operational semantics of <code class="computeroutput"><span class="identifier">T</span></code>
|
||||
plus the additional semantics corresponding to this special state. As such,
|
||||
<code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code>
|
||||
could be thought of as a <span class="emphasis"><em>supertype</em></span> of <code class="computeroutput"><span class="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 <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> a <span class="emphasis"><em>subtype</em></span> of
|
||||
<code class="computeroutput"><span class="identifier">T</span></code> is not only conceptually
|
||||
wrong but also impractical: it is not allowed to derive from a non-class
|
||||
type, such as a built-in type.
|
||||
</p>
|
||||
<p>
|
||||
We can draw from the purpose of <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> the required basic semantics:
|
||||
</p>
|
||||
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Default Construction:</strong></span> To introduce
|
||||
a formally uninitialized wrapped object.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Direct Value Construction via copy:</strong></span>
|
||||
To introduce a formally initialized wrapped object whose value is obtained
|
||||
as a copy of some object.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Deep Copy Construction:</strong></span> To obtain
|
||||
a new yet equivalent wrapped object.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Direct Value Assignment (upon initialized):</strong></span>
|
||||
To assign a value to the wrapped object.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Direct Value Assignment (upon uninitialized):</strong></span>
|
||||
To initialize the wrapped object with a value obtained as a copy of
|
||||
some object.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Assignment (upon initialized):</strong></span> To
|
||||
assign to the wrapped object the value of another wrapped object.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Assignment (upon uninitialized):</strong></span> To
|
||||
initialize the wrapped object with value of another wrapped object.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Deep Relational Operations (when supported by
|
||||
the type T):</strong></span> To compare wrapped object values taking into
|
||||
account the presence of uninitialized states.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Value access:</strong></span> To unwrap the wrapped
|
||||
object.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Initialization state query:</strong></span> To determine
|
||||
if the object is formally initialized or not.
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>Swap:</strong></span> To exchange wrapped objects.
|
||||
(with whatever exception safety guarantees are provided by <code class="computeroutput"><span class="identifier">T</span></code>'s swap).
|
||||
</li>
|
||||
<li class="listitem">
|
||||
<span class="bold"><strong>De-initialization:</strong></span> To release the
|
||||
wrapped object (if any) and leave the wrapper in the uninitialized
|
||||
state.
|
||||
</li>
|
||||
</ul></div>
|
||||
<p>
|
||||
Additional operations are useful, such as converting constructors and converting
|
||||
assignments, in-place construction and assignment, and safe value access
|
||||
via a pointer to the wrapped object or null.
|
||||
</p>
|
||||
</div>
|
||||
<div class="section">
|
||||
<div class="titlepage"><div><div><h4 class="title">
|
||||
<a name="boost_optional.tutorial.design_overview.the_interface"></a><a class="link" href="design_overview.html#boost_optional.tutorial.design_overview.the_interface" title="The Interface">The
|
||||
Interface</a>
|
||||
</h4></div></div></div>
|
||||
<p>
|
||||
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 <code class="computeroutput"><span class="identifier">T</span></code> type
|
||||
as much as possible. In order to choose the proper degree of adoption of
|
||||
the native <code class="computeroutput"><span class="identifier">T</span></code> interface,
|
||||
the following must be noted: Even if all the operations supported by an
|
||||
instance of type <code class="computeroutput"><span class="identifier">T</span></code> are
|
||||
defined for the entire range of values for such a type, an <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="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 <code class="computeroutput"><span class="identifier">T</span></code>.
|
||||
</p>
|
||||
<p>
|
||||
Furthermore, since <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> itself is merely a <code class="computeroutput"><span class="identifier">T</span></code>
|
||||
wrapper (modeling a <code class="computeroutput"><span class="identifier">T</span></code> supertype),
|
||||
any attempt to define such operations upon uninitialized optionals will
|
||||
be totally artificial w.r.t. <code class="computeroutput"><span class="identifier">T</span></code>.
|
||||
</p>
|
||||
<p>
|
||||
This library chooses an interface which follows from <code class="computeroutput"><span class="identifier">T</span></code>'s
|
||||
interface only for those operations which are well defined (w.r.t the type
|
||||
<code class="computeroutput"><span class="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 <code class="computeroutput"><span class="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 <code class="computeroutput"><span class="identifier">T</span></code>
|
||||
itself which are supported by a special interface.
|
||||
</p>
|
||||
<h6>
|
||||
<a name="boost_optional.tutorial.design_overview.the_interface.h0"></a>
|
||||
<span class="phrase"><a name="boost_optional.tutorial.design_overview.the_interface.lexically_hinted_value_access_in_the_presence_of_possibly_untitialized_optional_objects__the_operators___and___gt_"></a></span><a class="link" href="design_overview.html#boost_optional.tutorial.design_overview.the_interface.lexically_hinted_value_access_in_the_presence_of_possibly_untitialized_optional_objects__the_operators___and___gt_">Lexically-hinted
|
||||
Value Access in the presence of possibly untitialized optional objects:
|
||||
The operators * and -></a>
|
||||
</h6>
|
||||
<p>
|
||||
A relevant feature of a pointer is that it can have a <span class="bold"><strong>null
|
||||
pointer value</strong></span>. This is a <span class="emphasis"><em>special</em></span> value
|
||||
which is used to indicate that the pointer is not referring to any object
|
||||
at all. In other words, null pointer values convey the notion of nonexistent
|
||||
objects.
|
||||
</p>
|
||||
<p>
|
||||
This meaning of the null pointer value allowed pointers to became a <span class="emphasis"><em>de
|
||||
facto</em></span> standard for handling optional objects because all you
|
||||
have to do to refer to a value which you don't really have is to use a
|
||||
null pointer value of the appropriate type. Pointers have been used for
|
||||
decades—from the days of C APIs to modern C++ libraries—to <span class="emphasis"><em>refer</em></span>
|
||||
to optional (that is, possibly nonexistent) objects; particularly as optional
|
||||
arguments to a function, but also quite often as optional data members.
|
||||
</p>
|
||||
<p>
|
||||
The possible presence of a null pointer value makes the operations that
|
||||
access the pointee's value possibly undefined, therefore, expressions which
|
||||
use dereference and access operators, such as: <code class="computeroutput"><span class="special">(</span>
|
||||
<span class="special">*</span><span class="identifier">p</span>
|
||||
<span class="special">=</span> <span class="number">2</span> <span class="special">)</span></code> and <code class="computeroutput"><span class="special">(</span>
|
||||
<span class="identifier">p</span><span class="special">-></span><span class="identifier">foo</span><span class="special">()</span> <span class="special">)</span></code>, implicitly convey the notion of optionality,
|
||||
and this information is tied to the <span class="emphasis"><em>syntax</em></span> of the
|
||||
expressions. That is, the presence of operators <code class="computeroutput"><span class="special">*</span></code>
|
||||
and <code class="computeroutput"><span class="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 <span class="emphasis"><em>de facto</em></span> idiom for referring to optional objects
|
||||
can be formalized in the form of a concept: the <a href="../../../../../utility/OptionalPointee.html" target="_top">OptionalPointee</a>
|
||||
concept. This concept captures the syntactic usage of operators <code class="computeroutput"><span class="special">*</span></code>, <code class="computeroutput"><span class="special">-></span></code>
|
||||
and contextual conversion to <code class="computeroutput"><span class="keyword">bool</span></code>
|
||||
to convey the notion of optionality.
|
||||
</p>
|
||||
<p>
|
||||
However, pointers are good to <span class="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 <code class="computeroutput"><span class="identifier">X</span></code>, it can use <code class="computeroutput"><span class="identifier">shared_ptr</span><span class="special"><</span><span class="identifier">X</span><span class="special">></span></code>
|
||||
as the return value. However, this requires dynamic allocation of <code class="computeroutput"><span class="identifier">X</span></code>. If <code class="computeroutput"><span class="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
|
||||
<a href="../../../../../utility/OptionalPointee.html" target="_top">OptionalPointee</a>
|
||||
concept incarnated by pointers.
|
||||
</p>
|
||||
<h6>
|
||||
<a name="boost_optional.tutorial.design_overview.the_interface.h1"></a>
|
||||
<span class="phrase"><a name="boost_optional.tutorial.design_overview.the_interface.optional_lt_t_gt__as_a_model_of_optionalpointee"></a></span><a class="link" href="design_overview.html#boost_optional.tutorial.design_overview.the_interface.optional_lt_t_gt__as_a_model_of_optionalpointee">Optional<T>
|
||||
as a model of OptionalPointee</a>
|
||||
</h6>
|
||||
<p>
|
||||
For value access operations <code class="computeroutput"><span class="identifier">optional</span><span class="special"><></span></code> uses operators <code class="computeroutput"><span class="special">*</span></code>
|
||||
and <code class="computeroutput"><span class="special">-></span></code> to lexically warn
|
||||
about the possibly uninitialized state appealing to the familiar pointer
|
||||
semantics w.r.t. to null pointers.
|
||||
</p>
|
||||
<div class="warning"><table border="0" summary="Warning">
|
||||
<tr>
|
||||
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Warning]" src="../../../../../../doc/src/images/warning.png"></td>
|
||||
<th align="left">Warning</th>
|
||||
</tr>
|
||||
<tr><td align="left" valign="top"><p>
|
||||
However, it is particularly important to note that <code class="computeroutput"><span class="identifier">optional</span><span class="special"><></span></code> objects are not pointers. <span class="underline"><code class="computeroutput"><span class="identifier">optional</span><span class="special"><></span></code> is not, and does not model, a
|
||||
pointer</span>.
|
||||
</p></td></tr>
|
||||
</table></div>
|
||||
<p>
|
||||
For instance, <code class="computeroutput"><span class="identifier">optional</span><span class="special"><></span></code> does not have shallow-copy so does
|
||||
not alias: two different optionals never refer to the <span class="emphasis"><em>same</em></span>
|
||||
value unless <code class="computeroutput"><span class="identifier">T</span></code> itself is
|
||||
a reference (but may have <span class="emphasis"><em>equivalent</em></span> values). The
|
||||
difference between an <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> and a pointer must be kept in mind,
|
||||
particularly because the semantics of relational operators are different:
|
||||
since <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="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 <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code>
|
||||
by <code class="computeroutput"><span class="identifier">T</span><span class="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
|
||||
template functions <a href="../../../../../utility/OptionalPointee.html#equal" target="_top"><code class="computeroutput"><span class="identifier">equal_pointees</span><span class="special">()</span></code></a>
|
||||
and <a href="../../../../../utility/OptionalPointee.html#less" target="_top"><code class="computeroutput"><span class="identifier">less_pointees</span><span class="special">()</span></code></a>
|
||||
instead.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
|
||||
<td align="left"></td>
|
||||
@ -417,7 +178,7 @@
|
||||
</tr></table>
|
||||
<hr>
|
||||
<div class="spirit-nav">
|
||||
<a accesskey="p" href="motivation.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../../optional/tutorial.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="optional_references.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
|
||||
<a accesskey="p" href="../../optional/tutorial.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../../optional/tutorial.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="design_overview/the_semantics.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
Reference in New Issue
Block a user