|
|
|
@ -191,15 +191,15 @@ bool operator != ( optional<T> const& lhs, optional<T> const&
|
|
|
|
|
<P>This meaning of the null pointer value allowed pointers to became a defacto 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 <i>refer</i> to optional (that is, possibly inexistent) objects; particularly
|
|
|
|
|
Pointers have been used for decades—from the days of C APIs to modern C++ libraries—to
|
|
|
|
|
<i>refer</i> to optional (that is, possibly inexistent) 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>( *p = 2 )</code> and <code>( p->foo())</code>,
|
|
|
|
|
implicitly convey the notion of optionality, and this information is tied to
|
|
|
|
|
the <i>syntax</i> of the expressions. That is, the presence of operators * and -> tell by
|
|
|
|
|
themselves -without any additional context-, that the expression will be undefined unless
|
|
|
|
|
themselves—without any additional context—that the expression will be undefined unless
|
|
|
|
|
the implied pointee actually exist.<br>
|
|
|
|
|
Furthermore, the existence of the pointee can be tested by a comparison against
|
|
|
|
|
the null pointer value or via a conversion to bool, which allows expressions of
|
|
|
|
@ -228,7 +228,7 @@ them. The problem resides in the shallow-copy of pointer semantics: if you need
|
|
|
|
|
possible undefined value because of the idiomatic aid present in the OptionalPointee
|
|
|
|
|
concept incarnated by pointers. <br>
|
|
|
|
|
Therefore, the final solution which is presented in this library is to shape the
|
|
|
|
|
previously discussed optional -which is a value-based container- as a model
|
|
|
|
|
previously discussed optional—which is a value-based container—as a model
|
|
|
|
|
of the OptionalPointee concept.
|
|
|
|
|
</p>
|
|
|
|
|
<h3>Optional<T> as a model of OptionalPointee</h3>
|
|
|
|
@ -240,7 +240,7 @@ them. The problem resides in the shallow-copy of pointer semantics: if you need
|
|
|
|
|
However, it is particularly important that optional<> objects are not mistaken by pointers,
|
|
|
|
|
they are not. <u><b>optional<> does not model a pointer</b></u>.
|
|
|
|
|
For instance, optional<> has not shallow-copy so does not alias: two different optionals
|
|
|
|
|
never refer to the <i>same</i> value (but my have <i>equivalent</i> values).<br>
|
|
|
|
|
never refer to the <i>same</i> value (but may have <i>equivalent</i> values).<br>
|
|
|
|
|
The difference between an optional<T> and a pointer must be kept in mind, particularly
|
|
|
|
|
because the semantics of relational operators are different: since optional<T>
|
|
|
|
|
is a value-wrapper, relational operators are deep: they compare optional values;
|
|
|
|
@ -806,20 +806,19 @@ class Fred
|
|
|
|
|
|
|
|
|
|
<H2><A NAME="bool">A note about optional<bool></A></H2>
|
|
|
|
|
<p><code>optional<bool></code> should be used with special caution and consideration.</p>
|
|
|
|
|
<p>First, it is functionally similar to a tristate boolean (false,maybe,true)
|
|
|
|
|
-such as <u>boost::tribool</u> (not yet formally in boost)-,
|
|
|
|
|
except that in a tristate boolean, the <i>maybe</i> state
|
|
|
|
|
<u>represents a valid value</u>, unlike the corresponding state
|
|
|
|
|
<p>First, it is functionally similar to a tristate boolean (false,maybe,true) —such as
|
|
|
|
|
<u>boost::tribool</u> (not yet formally in boost)—except that in a tristate boolean,
|
|
|
|
|
the <i>maybe</i> state <u>represents a valid value</u>, unlike the corresponding state
|
|
|
|
|
of an uninitialized optional<bool>.<br>
|
|
|
|
|
It should be carefully considered if an optional bool instead of a tribool is really needed</p>
|
|
|
|
|
<p>Second, optional<> provides and implicit conversion to bool. This conversion
|
|
|
|
|
refers to the initialization state and not to the contained value.<br>
|
|
|
|
|
<p>Second, optional<> provides an implicit conversion to bool. This conversion
|
|
|
|
|
refers to the initialization state and not to the contained value.<br>
|
|
|
|
|
Using optional<bool> can lead to subtle errors due to the implicit bool conversion:</p>
|
|
|
|
|
<pre>
|
|
|
|
|
void foo ( bool v ) ;
|
|
|
|
|
void bar()
|
|
|
|
|
{
|
|
|
|
|
optional<bool> v = try();
|
|
|
|
|
optional<bool> v = Try();
|
|
|
|
|
|
|
|
|
|
// The following intended to pass the <b>value</b> of 'v' to foo():
|
|
|
|
|
foo(v);
|
|
|
|
@ -978,6 +977,6 @@ HREF="http://www.boost.org">www.boost.org</A>, and the boost discussion list at
|
|
|
|
|
<A
|
|
|
|
|
HREF="http://www.yahoogroups.com/list/boost">www.yahoogroups.com/list/boost</A>.
|
|
|
|
|
</P>
|
|
|
|
|
</u></BODY>
|
|
|
|
|
</BODY>
|
|
|
|
|
</HTML>
|
|
|
|
|
|
|
|
|
|