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 However, not all types wrapped in optional<T> will be comparable... so, I'm not adverse to leaving comparison operators out just to simplify the interface. I just don't agree with the current rationale. William E. Kempf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
