|
Boost : |
From: Björn Karlsson (Bjorn.Karlsson_at_[hidden])
Date: 2002-09-03 02:25:36
> From: Greg Colvin [mailto:Gregory.Colvin_at_[hidden]]
>
> I'm not clear why 'dynamic_any' is a new thing, rather than just an
> improved version of 'any'.
>
It's different in that it supports polymorphic retrieval, which could break
existing code/idioms;
Given
class A {};
class B : public A {};
you can do this,
dynany da=new B;
A* pa=any_cast<A*>(da);
This doesn't work with the current any, and it may not be desirable for all
use cases. It implies (among other things) that switch-style any_casts need
to preserve the order of inheritance to work, i.e. if code relies on exact
matches, it can do any_cast<A> before any_cast<B>, whereas with dynany
any_cast<B> wouldn't ever be reached.
I'd like to add that code conventions can help make any (as in boost::any)
extraction "polymorphic-like": If users consistently assign to any using
static_cast<A*> (or equivalent), that alleviates the need for an exact match
for UDTs (or rather, it enforces an exact match). The other way around,
making dynany work only with exact matches, is not currently possible,
AFAICT.
Not sure about the typical use cases for others than myself, I hesitate to
state which version of any/dynany is generally better. As usual, I'd prefer
to have both... any_cast<T> for the exact match, extract<T> for dynany
behavior. If that were to happen, that would imply changed and additions to
the current specification/implementation, rather than a new library.
Bjorn
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk