From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-12-05 10:58:31
In message <90j1d3+4tvn_at_[hidden]>, William Kempf <sirwillard_at_my-
>> > That is debatable, and several implementors are now going away
>> > COW. Regardless, this is a tangent from the original topic.
>> I think if you interject sharing your really need to look at the
>> COW issues. (Just to note, sigc++ doesn't do COW but then once
>> created a slot is basically RO.)
>Why do you have to look at COW if COW isn't being used? The problems
>with COW don't exist with ref-counting (though ref-counting may have
>problems of it's own).
I think the point here is that sharing is not a solution to a problem:
It is only ever a part of a solution, never the whole solution. The
reference counting itself does not really raise many profound issues,
but the thing being counted must be considered. Is it immutable? Should
its semantics reflect sharing? If yes, then is it safe to do so? If no,
then how can it be unshared?
Reference counting of mutable objects presents challenges for both the
yes and no case: the requirement of additional locking in the former for
an MT environment, and the issues with COW in the latter. It turns out
to be bad whichever way you look. You cannot debate the merits of
reference counting without considering the solution it is a part of.
>> Sharing just is a bigger can of
>> worms unless there is a compelling reason to favor it over cloning.
>One of the reason I agreed with for choosing cloning. It's just not
>the reason we've been debating here.
>> (Personally I prefer sharing over cloning, but I don't feel that
>> it would meet the needs thus far described.)
>The other reason to prefer cloning is that a sharing version can be
>trivially built on top of the cloning version, or shared_ptr can be
>used for simplicity.
Agreed, so that we can build from the bottom up.
Kevlin Henney phone: +44 117 942 2990
Curbralan Limited mobile: +44 7801 073 508
mailto:kevlin_at_[hidden] fax: +44 870 052 2289
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk