> [mailto:[EMAIL PROTECTED]]On Behalf Of William E. Kempf > Sent: 11 December 2002 20:42 >
[ snip ...] > > 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 I don't agree with this. It seems to be mixing both pointer and value semantics. assert( a == b ) // pointer semantics. if this used value semantics then this would mostly fail and randomly suceeed. given that we can already do *c != *d then if relationl operators are to add any value, they would need to be: assert(a == b); // both uninitialized assert(a != c); // one uninitialized assert(c == d); // both initialized > > 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. If that is the compromise that is required, I can live with it. but it would be nice to have them as I have defined above as we already have the value operators and it would be a short hand for: get( c ) == get ( d ) or c.get( ) == d.get( ) /ikh _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
