"William E. Kempf" <[EMAIL PROTECTED]> 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
[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
