Copy-editing optional documentation. Fixes #5382 and a few other issues I noticed while I was at it.

[SVN r71052]
This commit is contained in:
Steven Watanabe
2011-04-06 21:56:23 +00:00
parent 960631e201
commit c1d2381a9b
6 changed files with 15 additions and 16 deletions

View File

@ -1,4 +1,4 @@
[/
[/
Boost.Optional
Copyright (c) 2003-2007 Fernando Luis Cacciola Carballal
@ -58,7 +58,7 @@ The observation made in the last paragraph about the irrelevant nature of the
additional `nil_t` with respect to [_purpose] of `optional<T>` suggests an
alternative model: a ['container] that either has a value of `T` or nothing.
As of this writing I don't know of any precedence for a variable-size
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.
@ -176,14 +176,14 @@ untitialized optional objects: The operators * and ->]
A relevant feature of a pointer is that it can have a [*null pointer value].
This is a ['special] 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 inexistent objects.
the notion of nonexistent objects.
This meaning of the null pointer value allowed pointers to became a ['de
facto] 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 as optional arguments to a
possibly nonexistent) 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