Fernando Cacciola said: > From: "Peter Dimov" <[EMAIL PROTECTED]> >> From: "Fernando Cacciola" <[EMAIL PROTECTED]> >> > Perhaps this could be called get_pointer() as shared_ptr<> does. >> >> get_pointer() would be... less objectionable. :-) >> > This particular free function is precisely intended to decouple this > functionality (get a pointer that points to the value) from the class > type (optional<> in this case); so it makes sense to be a commonly named > free function. > But then, get_pointer() is the common name, so it has to be that one.
>> bool operator==(optional const & a, optional const & b) >> { >> if(a.initialized() != b.initialized()) return false; >> return a.initialized()? *a == *b: true; >> } >> >> That is, an unitialized optional is equal to an unitialized optional, >> and not equal to an initialized one. >> >> Two initialized optionals are equal when their values compare equal. >> >> If you think of an optional as a constrained std::vector<T>, you'll >> see > that >> the above semantics correspond to vector<>::operator==. >> >> The other way of thinking about an optional<T> is that it is capable >> of storing all possible values of type T plus an additional value > corresponding >> to the uninitialized state. In other words, optional<int> can be >> thought > of >> as an integer that can store INT_MIN...INT_MAX+1, with INT_MAX+1 being >> interpreted as uninitialized. The above comparison does the right >> thing > for >> this model, too. >> >> A variant<T, nil_t> would have the same operator==, too. >> > Well, this is exactly what William suggested. > Still I don't like it. > But thanks to William insistance on a sound rationale, I realize now > that the real problem > is not the personally-odd definition that something is definitely not > equal to nothing > (instead of undefined); since this definition doesn't look odd to many > of you, > but the fact that such definition would look ackward with respect to the > pointer-like interface. > > Anyway, as I posted recently, I'm just about to conclude that relational > operators > could be properly defined as a synonim for: get_pointer(o1) .relop. > get_pointer(o2). > I found this definition totally consistent with pointer semantics and > the implied > aliasings. So, from recent postings it sounds like you've made several more decisions on the interface (deep const, relational ops, get_pointer(), explicit templated constructor from other optional<> types, anything else?). Can we get you to illustrate the changes and/or republish the documentation again? I think we're finally at a point that everything I brought up has been addressed to my satisfaction, but before I drop out of the discussion I want to make sure :). William E. Kempf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost