From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-07-19 02:20:18
> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>Currently, 'any' has a copy-on-copy policy; that is, each time an 'any'
>instance is copied, the value it holds is copied too.
>This policy is appropriate for small objects, but it is very inefficient if
>the values held are big.
>I've written two variant classes (see
>of which is pretty much the same as 'any'.
>The other class has a share-on-copy policy, just like a read-only
>std::string; that is, the value is held in a reference counted dynamically
The original, pre-Boost version of any was written so that it could be
implemented using reference counting and copy-on-write. This is why the
original version had no non-const access to the contained member -- this
was added as a result of Boost reviewing.
I presume you are proposing a class that is intended to be transparently
reference counting, ie using copy on write? If so, the implementation
you provided needs to perform a copy on the non-const any_cast. If not,
then I would suggest it should be to avoid mixing unrelated semantics
and ideas ;-)
However, I have a couple of issues with this, one of which is the well
documented issues with COW ref counting -- which is why I chose not to
submit the reference counting version to Boost -- and the other is the
issue of interface vs implementation. One of Boost's aims is to
establish interfaces as opposed to implementations. If the only
difference between any and any2 were to be in the representation, then
it would simply be a quality of implementation issue, and not, I would
submit, a case for a separate class. For example, within the same usage
constraints there are two approaches to implementing non-intrusive smart
pointers, and yet there is only one boost::shared_ptr.
Kevlin Henney phone: +44 117 942 2990
mailto:kevlin_at_[hidden] mobile: +44 7801 073 508
http://www.curbralan.com fax: +44 870 052 2289
Curbralan: Consultancy + Training + Development + Review
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk