Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-03-05 19:09:31


Brock Peabody wrote:
>>-----Original Message-----
>>From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
>>On Behalf Of Joel de Guzman
>>
>>FWIW, a tuple<T&> can't be re-bound.
>
>
> True, but neither can a tuple<T&> be null.
>
>
>>I'll state my point again. I noticed this odd behavior of
>>optional some years ago: giving optional re-binding semantics
>>*is actually* giving it special semantics and requires special
>>case handling. This leads to subtle problems like the one
>>Fernando is experiencing now.
>
>
> IIUC the proposed changes do not prevent rebinding:
>
> int i = 1, j = 2;
>
> boost::optional<int&> oa = i;
>
> oa = j; //i is 2
>
> oa.reset();
>
> oa = j; //oa is rebound

Hmmm. I smell something wrong with that.

>>If you want rebinding semantics,
>>use a pointer
>
>
> But optionals are so much cleaner. Given a T& your only options would be a
> naked pointer which would have to be unpleasantly documented or to put it in
> a shared pointer with a noop deleter.

Agreed.

>>, or use boost::ref.
>
>
> I guess boost::optional<boost::ref<T> > would do the trick.
>
>
>>The right behavior, I strongly
>>believe, is to do as the references do. This is what tuple did
>>and we have nary a problem with it.
>
>
> Maybe the right solution then is that boost::optional<T&> can only be
> initialized via constructor.

Yes. This is what I expected. As always, when in doubt,
do as the <place your primitive here>. In this case, tuple
got it right: no special case handling for references. The
behavior, WRT assignment and construction, should follow
that of a struct with a T& member.

> There are really two separate issues:
>
> 1) should optional<T&> be rebindable
>
> I think it's handy to be able to rebind optional<T&> but then again, I don't
> see why we can't rebind regular references either other than a lack of good
> syntax for doing it.
>
> On the other hand, I can see that since T& isn't rebindable, making
> optional<T&> rebindable causes problems in generic code and I can always use
> optional<ref<T> > anyway.

Exactly!

> 2) should optional<T&>::op= forward to its reference when bound.
>
> I still think this is a bad idea. For one thing, you can't disallow
> rebinding as long as you've got an op= unless you make op= sugar for *oa =,
> in which case assigning to unbound optional<T&> is undefined.

When in doubt, do as the references do. I strongly believe that
tuple, optional and variant should all have the same behavior
when it comes to dealing with references. Tuple did it right.
I hope optional and variant follow.

Regards,

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

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