feedc0de/boost_optional
1
0
Fork 0
forked from boostorg/optional
Code Pull Requests Activity

Fix some more typos and grammatical errors.

Browse Source 
[SVN r71089]

Conflicts:
	doc/html/boost_optional/detailed_semantics.html
	doc/html/index.html
This commit is contained in:
Andrzej Krzemienski
2014-04-11 11:47:09 +02:00
parent 6cd1827fe2
commit fdbac34bfb
2 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/reference.qbk
View File

@ -381,9 +381,9 @@ assert ( *opt == y ) ;
__SPACE__
[: `optional<T&>& optional<T&>::operator= ( T& const& rhs ) ;`]
[: `optional<T&>& optional<T&>::operator= ( T& rhs ) ;`]
* [*Effect:] (Re)binds thee wrapped reference.
* [*Effect:] (Re)binds the wrapped reference.
* [*Postconditions: ] `*this` is initialized and it references the same
object referenced by `rhs`.
* [*Notes:] If `*this` was initialized, it is ['rebound] to the new object.

16
doc/special_cases.qbk
View File

@ -1,4 +1,4 @@

[section Optional references]
This library allows the template parameter `T` to be of reference type:
@ -37,7 +37,7 @@ the first time) to the object. Clearly, there is no other choice.
assert(x==2);
If you assign to a bare C++ reference, the assignment is forwarded to the
referenced object; it's value changes but the reference is never rebound.
referenced object; its value changes but the reference is never rebound.
int a = 1 ;
int& ra = a ;
@ -95,15 +95,15 @@ use Optional's assignment without explicitly handling the previous
initialization state unless your code is capable of functioning whether
after the assignment, `a` aliases the same object as `b` or not.
That is, you would have to discriminate in order to be consistency.
That is, you would have to discriminate in order to be consistent.
If in your code rebinding to another object is not an option, then is very
likely that binding for the fist time isn't either. In such case, assignment
If in your code rebinding to another object is not an option, then it is very
likely that binding for the first time isn't either. In such case, assignment
to an ['uninitialized ] `optional<T&>` shall be prohibited. It is quite possible
that in such scenario the precondition that the lvalue must be already
initialized exist. If it doesn't, then binding for the first time is OK
that in such a scenario it is a precondition that the lvalue must be already
initialized. If it isn't, then binding for the first time is OK
while rebinding is not which is IMO very unlikely.
In such scenario, you can assign the value itself directly, as in:
In such a scenario, you can assign the value itself directly, as in:
assert(!!opt);
*opt=value;