> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Dimov > Sent: 12 December 2002 17:09 > > From: "Iain K.Hanson" <[EMAIL PROTECTED]> > > > > :-) true. But it also does not have container semantics either. > > I prefered your analogy with a special valued INT. Given that we > > have > > *opt1 == *opt2 > > for ordinary value comparisons > > But this doesn't work when one of the optionals is > uninitialized. opt1 == > opt2 (as proposed) is a safer version of the above, as its behavior is > always defined. It also has the desirable property > > optional b(a); > assert(b == a); > > for any a (i.e. it represents "equivalent to" as used by > CopyConstructible > and Assignable.) >
given that dereference is defined then the *potentially* unsafe *opt1 == *opt2 is defined. However the lack of safty is very small as C++ programmers have to be very aware that dereferencing an uninitiallised pointer does very bad things at run time. This is so ingrained that I can't see the problem. Given the above, I can't see the utility of defining rel-ops with container semantics. Particularly as if opt1 == opt2 returns false you have no idea if it is because there is a value mis-match or a state mis-match. I can see the logic in your argument, but given that optional is neither "fish nor fowl" ( its not a smart pointer, its not a container, and its not just a value ), I would rather go for the semantics that offer most utility. /ikh _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
