"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Fernando Cacciola" <[EMAIL PROTECTED]> writes: > > > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> "Fernando Cacciola" <[EMAIL PROTECTED]> 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 get(); > 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 by-value. 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
