----- Original Message ----- From: "Iain K.Hanson" <[EMAIL PROTECTED]> To: "'Boost mailing list'" <[EMAIL PROTECTED]> Sent: Thursday, December 12, 2002 8:20 AM Subject: RE: [boost] Formal review: Optional library
> > > > [mailto:[EMAIL PROTECTED]]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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
