|
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