Boost logo

Boost :

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2005-03-05 13:03:12


> -----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

>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.

>, 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.

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.

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.

Regards,
Brock


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