Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-02-19 14:25:20

"David Abrahams" <dave_at_[hidden]> wrote in message
> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
> > "David Abrahams" <dave_at_[hidden]> wrote in message
> >
> >> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
> >>
> >> > Any idea about what to do with reference to reference problem?
> >>
> >> What's the problem?
> >>
> > Currently, optional<Y> has:
> >
> > explicit optional ( T const& val )
> > T* get();
> > T* operator->() ;
> > T& operator *();
> >
> > those are all illegal if T is a reference type.
> explicit optional ( typename add_reference<typename
add_const<T>::type>::type val )
> typename add_pointer<typename remove_reference<T>::type>::type
> typename add_pointer<typename remove_reference<T>::type>::type
operator->() ;
> typename add_reference<T>::type operator *();
I see.
Correct me if I'm wrong:

You're essentially saying that, for instance, optional<> is initialized with
a "value of type T";
and that whether that is expressed with 'T' or 'T const&' is an
implementation detail.
It implies that the user should not assume that the initializer is not taken

Similarly, operator*() returns 'the value', being an implementation detail
whether this is 'T' or 'T const&'.

Well, this sounds good by itslef.

Still, there are other problems with optional<T&>:

AFAICT, one way or another, the 'value' that optional holds, in this case of
reference type,
must be stored in the aligned storage.
But you can't get a pointer to a reference so you can't have somehing like:

new (storage) U(value) ; where U=T&

IOWs, you can't have a real 'copy' of a reference with storage and all
(if you could, you could also have a pointer/reference to it).
References are not required to be actual objects, they don't need to be
stored anywhere.

You can have a pointer to the referenced object, but then, the optional<T&>
would not be
an 'optional reference' object but a reference to an 'optional object', so
we're back to argument
that in this case you can use a pointer instead of optional<>.

Now that I think about it, optional<T&> doesn't make sense because T& is not
a object, and
optional<U> represent an optional U object.
References are not objects.
IOWs, that you have or don't have a 'U' means that if you have an U you have
it stored somewhere.

> >> >
> >> > What was the idea of: optional< exactly<T&> > ?
> >>
> >> It's an ambiguity breaker: a way of specifying, when constructed with
> >> a variant<T,T&>, that you want to get the T& and not the T.
> >>
> > hmmm, shouldn't 'exactly' appear along with extract then?
> > What's the meaning of "optional< exactly<T&> > " by itself, without
> > variant<T,T&> in the scene?
> I dunno, maybe nothing; we were talking about optional as a
> replacement for extract.
Aha, OK.

Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at