-
diff --git a/doc/html/boost_optional/tutorial/optional_references/rebinding_semantics_for_assignment_of_optional_references.html b/doc/html/boost_optional/tutorial/optional_references/rebinding_semantics_for_assignment_of_optional_references.html
new file mode 100644
index 0000000..0e4564f
--- /dev/null
+++ b/doc/html/boost_optional/tutorial/optional_references/rebinding_semantics_for_assignment_of_optional_references.html
@@ -0,0 +1,147 @@
+
+
+
+
Rebinding semantics for assignment of optional references + + + + + + + + +
++ 
Home +Libraries +People +FAQ +More +
+++
++ +++ If you assign to an uninitialized
+optional<T&>the effect is to bind (for the + first time) to the object. Clearly, there is no other choice. +int x = 1 ; +int& rx = x ; +optional<int&> ora ; +optional<int&> orb(x) ; +ora = orb ; // now 'ora' is bound to 'x' through 'rx' +*ora = 2 ; // Changes value of 'x' through 'ora' +assert(x==2); +
++ If you assign to a bare C++ reference, the assignment is forwarded to the + referenced object; its value changes but the reference is never rebound. +
+int a = 1 ; +int& ra = a ; +int b = 2 ; +int& rb = b ; +ra = rb ; // Changes the value of 'a' to 'b' +assert(a==b); +b = 3 ; +assert(ra!=b); // 'ra' is not rebound to 'b' +
++ Now, if you assign to an initialized
+optional<T&>, + the effect is to rebind to the new object + instead of assigning the referee. This is unlike bare C++ references. +int a = 1 ; +int b = 2 ; +int& ra = a ; +int& rb = b ; +optional<int&> ora(ra) ; +optional<int&> orb(rb) ; +ora = orb ; // 'ora' is rebound to 'b' +*ora = 3 ; // Changes value of 'b' (not 'a') +assert(a==1); +assert(b==3); +
++ + Rationale +
++ Rebinding semantics for the assignment of initialized +
+optionalreferences has + been chosen to provide consistency among initialization + states even at the expense of lack of consistency with the semantics + of bare C++ references. It is true thatoptional<U>strives to behave as much as possible + asUdoes whenever it is + initialized; but in the case whenU+ isT&, + doing so would result in inconsistent behavior w.r.t to the lvalue initialization + state. ++ Imagine
+optional<T&>+ forwarding assignment to the referenced object (thus changing the referenced + object value but not rebinding), and consider the following code: +optional<int&> a = get(); +int x = 1 ; +int& rx = x ; +optional<int&> b(rx); +a = b ; +
++ What does the assignment do? +
++ If
+ais uninitialized, + the answer is clear: it binds tox+ (we now have another reference tox). + But what ifais already + initialized? it would change the value of the referenced + object (whatever that is); which is inconsistent with the other possible + case. ++ If
+optional<T&>+ would assign just likeT&does, you would never be able to use + Optional's assignment without explicitly handling the previous initialization + state unless your code is capable of functioning whether after the assignment, +aaliases the same object + asbor not. ++ 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 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 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 a scenario, + you can assign the value itself directly, as in: +assert(!!opt); +*opt=value; +
+
++ + +
+++ + diff --git a/doc/html/index.html b/doc/html/index.html index f3c24d2..ec7b663 100644 --- a/doc/html/index.html +++ b/doc/html/index.html @@ -144,7 +144,7 @@
+