----- Original Message -----
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 12:18 PM
Subject: Re: [boost] Formal review: Optional library
> 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 :).
>
Yes. I'm precisely doing it. I'll republish everything ASAP... stay tuned.
Fernando Cacciola
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
