Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-09-01 17:43:43


Joel de Guzman <djowel_at_[hidden]> wrote in message
news:00d301c370bc$fda04ed0$450caccb_at_godzilla...
> Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
>
> >> Even if I agree with you that an optional<T> should not be a T,
> >> an optional<T> is definitely not a pointer to T.
> >>
> > Definitely!
> > If HTML had blinking banners I think I'd use one to state this :-)
>
> Nor should it model a pointer.
>
It tries not to model a pointer at least.

The OptionalPointee concept was coined to stress this fact,
by formalizing the syntatic meaning of operators * and ->
independently of pointers.

What I'm defending here is the idea of giving operators * and ->
a meaning on their own: the possibly undefined value of its operands.

That this choice of operators still makes the appearance that optional<>
models a pointer I need to address on the documentation by a better
formalization of the concept.

> That was my point and the point of others who dislike *opt.
>
>
> > Yet iterators are not pointers either but they do use
> > operators * and ->
>
> Iterators are not pointers, but they model the pointer.
>
> >> Right. In fact, looking at it more closely, I *could* almost agree with you
> >> that an optional<T> is not a T. There is in fact a getter function (get).
> >> In fact all three (tuple, optional and variant) have a get function. That's
> >> fine, yet, here again, the optional does not jive well because it returns
> >> access *by pointer* whereas both tuple and variant return access by
> >> reference.
> >>
> > This get() issue we agree should be fixed.
>
> Agreed. If there's a way to get at the values through a generic get
> function that unifies the access of optional with variant such that I
> can think of optional as an optimized specialization of variant<T, none>,
> I would be very happy. With such an interface, I can simply ignore
> the pointer-like interface, if you wish to keep it ;-)
>
All right, we're settled then!

>
> Thanks you very much! And BTW, kudos for such a well engineered
> library! Spirit has been using it since v1.7 and I am very happy with
> it. The comments I gave so far are merely my opinion. You are of
> course free to have your own preferences :-)
>
> Keep up the good work!
>
Thank you!

Fernando Cacciola


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk