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 refer 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 + refer to optional (that is, possibly inexistent) objects; particularly as optional arguments to a function, but also quite often as optional data members.
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: ( *p = 2 ) and ( p->foo()),
implicitly convey the notion of optionality, and this information is tied to
the syntax 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.
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.
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.
optional<bool> should be used with special caution and consideration.
First, it is functionally similar to a tristate boolean (false,maybe,true) --such as boost::tribool (not yet formally in boost)-, -except that in a tristate boolean, the maybe state -represents a valid value, unlike the corresponding state +
First, it is functionally similar to a tristate boolean (false,maybe,true) —such as
+boost::tribool (not yet formally in boost)—except that in a tristate boolean,
+the maybe state represents a valid value, unlike the corresponding state
of an uninitialized optional<bool>.
It should be carefully considered if an optional bool instead of a tribool is really needed
Second, optional<> provides and implicit conversion to bool. This conversion
-refers to the initialization state and not to the contained value.
+
Second, optional<> provides an implicit conversion to bool. This conversion
+ refers to the initialization state and not to the contained value.
Using optional<bool> can lead to subtle errors due to the implicit bool conversion:
void foo ( bool v ) ; @@ -978,6 +977,6 @@ HREF="http://www.boost.org">www.boost.org, and the boost discussion list at www.yahoogroups.com/list/boost. -