From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-12-12 10:18:46
Fernando Cacciola said:
> From: "Peter Dimov" <pdimov_at_[hidden]>
>> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>> > 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
>> 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
>> to the uninitialized state. In other words, optional<int> can be
>> 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
>> 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
> could be properly defined as a synonim for: get_pointer(o1) .relop.
> I found this definition totally consistent with pointer semantics and
> the implied
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk