|
Boost : |
From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-02-19 08:53:45
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:004501c2d819$9e067300$1d00a8c0_at_pdimov2...
> Joel de Guzman wrote:
> > David Abrahams wrote:
> >
> >> BTW, I just realized that a conversion from variant<T> to optional<T>
> >> could be used to do extraction as well. Maybe it would be better to
> >> ditch extract altogether and just use optional?
> >
> > I think this makes sense. The disadvantage is the overhead of optional
> > just to do "extract"ion.
>
> That means an extra copy and inability to change that data held in the
> variant using non-const extract. If we really need to go that route, it's
> probably better to just make extract return a value.
>
Indeed. optional<T> IS a value (but 'optional')
IOWs, the reason why you couldn't use optional<T&> for extract is not only
because of the reference-to-reference problem but essentially conceptual: An
instance of optional<T> contains a {copy-of} a 'value' of type T.
In this case, the value would be the reference itself instead of the T
object within the variant.
If extract would return by-value (which it could), then optional<T> would
make perfect sense (overhead aside); but AFAICT, exract is intended to
access the object within, thus the T&/T* proposed flavours.
... I've been down this road before, you know: but I'll use the name
'peek()' for this operation.
-- Fernando Cacciola
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk