From: David Abrahams (dave_at_[hidden])
Date: 2002-12-12 13:15:58
"Iain K.Hanson" <iain.hanson_at_[hidden]> writes:
>> [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
>> 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.
1. The contained value is part of the state. Pretending otherwise
just confuses everything.
2. As long as there's a way to check for an emptiness mismatch (what
you're calling a "state mismatch", e.g. x.empty() == y.empty()), I
don't why there's a problem that operator== doesn't make that
> 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.
How is Peter's suggestion less-useful?
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk