RE: [boost] Reference counting 'any'

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-07-19 10:59:45

----- Original Message -----
From: Kevlin Henney <kevlin_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, July 19, 2001 4:20 AM
Subject: [boost] Reference counting 'any'

> >   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
> >http://www.cuj.com/articles/2000/0010/0010a/0010a.htm?topic=articles),
one
> >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
> >allocated object.
>
I think it is important to properly measure the effect of the copy-on-copy
policy on likely real-world usages of 'any'.
According to my personal experiences with my variant classes and to the user
reports for those classes, I know as a fact that there are applications that
are only feasable if the variant class does not copy its value as it
propagates through the execution contexts.
In order words, the variation I propose is undoubtly neccesary and IMO
should make it into boost.

Now, I could simply submit my own varint_t class (which anyone intereseted
can get from the link above),  but I think that a variation of 'any' would
be better because they are not totally unrelated.

> 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?
No, not copy-on-write.
I propose a variant type that is not a (deep) lvalue, so no copy on write is
necessary. That's why I compared it to a *read only* string.
You can *replace* the value but not *modifiy* it.

>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 ;-)

Of course this changes the semantic in that you don't have non-const access
(which I forgot to modify on the sample code).
If your concern is that users may get confused about the different semantics
then I would consider the submission of a different class.

>
> 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 --
True, but COW is not necessary in the approach I am proposing.

(BTW, COW rc issues are performance issues. They can be compared to the
copy-on-copy performance issues that might arise with complex types).

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com