Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-12 09:02:14

----- Original Message -----
From: "Iain K.Hanson" <iain.hanson_at_[hidden]>
To: "'Boost mailing list'" <boost_at_[hidden]>
Sent: Thursday, December 12, 2002 8:20 AM
Subject: RE: [boost] Formal review: Optional library

>
>
> > [mailto:boost-bounces_at_[hidden]]On Behalf Of Iain K.Hanson
> > Sent: 12 December 2002 10:15
> > To: 'Boost mailing list'
> > Subject: RE: [boost] Formal review: Optional library
> >
> >
> >
> > assert( a == b ) // pointer semantics.
> > if this used value semantics then this would mostly fail and randomly
> > suceeed.
>
> Whoops - brain fade. Yhis would also be true of pointer semantics.
> Maybe this argues Fernando's point that they should not be defined.
> However, given that we already have dereference, it would be nice to
> have the syntacic sugar I described in my previous post.
>
I agree that it would be possible to define relational operators
as a shorthand for get(o1) == get(o2).
I'm not sure of its usefullness, but at least it seems consistent with the
part of the interface with pointer semantics.

Notice that aliasing, i.e. the fact that equaliy implies that optional
values (pointees) are effectively the same _object_ will actually work as
expected, unlike Augustus predicted.
The reason is that with this definition, equality will be true iif both
optionals are
_uninitialized_ or are the _exact same object_:

optional<int> o1 ;
optional<int> o2 ;
(o1 == o2) -> true; and since *o1 and *o2 are undefined, there is no implied
aliasing.

o1.reset(1);
o2.reset(2);
(o1 == o1) -> true, and the implied aliasing that *o1=3 implies *o2==3
holds.

(o1 == o2 ) -> false, so no aliasing is implied.

Fernando Cacciola