From: Leo Goodstadt (leo.goodstadt_at_[hidden])
Date: 2005-10-17 14:55:10
Stating the obvious, isn't the whole problem because there are two
completely separate modes of action during optional reference assignments:
1) Where the reference is assigned (rebinding to references)
2) Where the referred value is assigned (assignments from the underlying
Pointers do indeed have the same abilities, but they have distinct semantics
for these separate modes. I.e. 'p = px' and '*p = *px'. The absence of
rebinding of references in c++ is by design not accident. (See p.86 of the
Design and Evolution of C++.)
IMHO, signalling distinct semantic modes using clear syntax is essential.
In the example below, it might not always be clearly that a rebinding has
taken place. That requires the programmer to be aware of the types of the
variables on both sides of the assignment, and how this could affect what
takes place. This behaviour of optional would break the aliasing ability of
references, which I feel is deeply ingrained into many c++
(That after "int& ref_AA =AA;" ref_AA can be used exactly in place of AA .
Dangerously subtle bugs would be very difficult to find.
The easiest solution to disambiguate, would be to force all binding and
rebinding of optional references to use distinct syntax (rebind) so that
this is clearly signalled at the minor cost of some syntactic verbosity.
This means that optional<T&> is no longer completely orthogonal to
optional<T> in its syntax, but as that merely reflects the real underlying
differences in semantics, this should be an advantage not a disadvantage.
> Fernando Cacciola wrote:
> optional<int&> or ;
> int v = 3 ;
> int w = 5 ;
> int x = 10 ;
> int& rv = v ;
> int& rw = w ;
> int& rx = x ;
> or = rv ; // 'v' is bound for the first time here.
> or = rw ; // 'or' is initialized so 'v' is changed to 5 
> or = none ; // back to absent
> // unlike , 'or' is bound now to 'x' rather than 'v' changing its
> or = rx ;
> As you can see, WITHOU REBINDING, in one case of assignment, the value of
> the referenced object changes, but in the other case of assignment,
> another object is referenced.
> I consider this a problem and so I propose rebinding as a way out.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk