|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-09-01 07:08:25
> >Providing three ways to get at the value seemed a bit excessive.
>
> Each is different wrt (1) returning mechanism and (2) failure:
>
> (i) any_cast returns by copy construction on success, and throws an
> exception on failure.
>
> (ii) to_ptr returns a direct pointer to the content on success, and null
> on failure.
>
> (iii) copy_to 'returns' by copy assignment to an argument, returning
> true on success and false on failure.
>
> If I needed only one I would have only one, but experience with the
> class (and its ancestors) has taught me that these are reasonable
> scenarios to pander to.
I've been thinking about this, trying to 'unify' ref<void> and any, and the
two methods to get the value (any_cast is not a primitive) seemed a bit
excessive to me, too.
I think that I'll change ref<T>::is<U> to return U (const) * instead of
bool, to allow usage of the form
if(U * p = rx.is<U>())
{
}
being backward compatible with the current usage
if(rx.is<U>())
{
}
This covers the to_ptr case - I can see its usefulness immediately. The
pattern is similar to the preferred dynamic_cast usage as described in D &
E.
I think that I'm sold on the implicit conversion to void const * too - this
will replace my operator==(nil). Since ref<> explicitly provides all
comparison operators, the conversion would do no harm.
Would you mind showing some scenarios to demonstrate
(1) typical copy_to() usage (my favourite spelling for this would be
'extract')
(2) typical type_info() usage.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk