Re: [boost] Formal review: Optional library

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-11 15:49:37

"William E. Kempf" <wekempf_at_[hidden]> writes:

> Tanton Gibbs said:
>>> optional<int> opt0(1);
>>> optional<int> opt1(2);
>>> (opt0 == opt1) // true
>>
>> I would not have any problem with this returning false.  In the normal
>> ptr world:
>> char c, d;
>> char* p, *q;
>> p = &c;
>> q = &d;
>>
>> if( p == q ) // false
>>
>> People expect it to compare memory locations, not initialization status.
>> Therefore, I would have no problem with operator== returning true only
>> if both
>> were uninitialized.
>
> I agree with this.  The optional<> concept takes some type and extends
> it's possible values to include a new "uninitialized" value.  It seems
> wholly logical to me for this:
>
> optional<int> a();
> optional<int> b();
> optional<int> c(1);
> optional<int> d(2);
> optional<int> e(2);
>
> assert(a == b);  // both uninitialized
> assert(a != c);  // one uninitialized
> assert(c != d);  // both initialized to different values
> assert(d == 3);  // both initialized to same value
"2?"----------^ 

BTW, that's a container-like interface. I have no problem with that,
but then I'm a bit concerned about the pointer-like interface to the
rest of the class.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution