"Iain K.Hanson" <[EMAIL PROTECTED]> writes:
>> [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.
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
distinction clear.
> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
