Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-12 14:02:52

"Iain K.Hanson" <iain.hanson_at_[hidden]> writes:

>> [mailto:boost-bounces_at_[hidden]]On Behalf Of David Abrahams
>> Sent: 12 December 2002 18:16
>>1. The contained value is part of the state. Pretending otherwise
>> just confuses everything.
> Whether it is initialised is orthaganal to its contained value. As
> Bill Kempf said "if it walks like a duck and talks like a duck".

But it doesn't, really. If you're going to have deep constness and
deep assignment, the only thing remaining that makes it pointer-like
is the operator*/operator-> interface. At that point, it's just a
very convenient shorthand for saying .front()/.begin() on a

> There is no confusion, there are two different ways of looking at
> them. I can see the logic in Peter's view, I just think that like
> pointers, equivelence of optional's is not about there contained
> value, it is about whether they have been initialised or not. The
> name of the class say's it.

I don't see how the name of the class implies anything. If I have two
optional integers, 3 and 4, I naturally think of them as unequal.

>>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.
> As I said previously, its syntatic sugar. There is nothing that you
> need the rel-ops for that you can not do another way.
>>How is Peter's suggestion less-useful?
> because the false result tells you nothing.

??? it's not as though the function returns false randomly!

It tells you whether one optional is substitutable for another in the
same expression (ignoring the address-of operator), which is the
essence of equivalence in C++.

                       David Abrahams
   dave_at_[hidden] *
Boost support, enhancements, training, and commercial distribution

Boost list run by bdawes at, gregod at, cpdaniel at, john at