RE: [boost] Formal review: Optional library

From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-12-12 12:52:27

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Peter Dimov
> Sent: 12 December 2002 17:09
>
> From: "Iain K.Hanson" <iain.hanson_at_[hidden]>
> >
> > :-) 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