Boost logo

Boost :

From: Vladimir Batov (batov_at_[hidden])
Date: 2007-10-06 19:00:16


> Here is a simple deep-copying smart pointer.
> Could hardly be simpler and more lightweight.

The simplicity of your example and the relative complexity of shared_ptr are
there for a reason. Apart from its obvious purpose (ref.-counting) the
shared_ptr provides more features that are important for my aim of Pimpl
generalization. My suspicion is that your implementation (unlike
shared_ptr) does not handle incomplete classes well for implementation
hiding. Something that is important for Pimpl.

> That is nothing compared to the massive overhead of using shared_ptr.

Well, I feel that "the massive overhead" is debatable. If you refer to
implementation complexity, it's there for a reason and is not an issue as
it's already there. If you refer to perfomance, then it's not a clear cut as
it very much depends on an application and the usage pattern.

> That is why sharing implementation details can only be done if data is
> read-only.

Well, I am not sure I can agree as sharing certainly can be done when data
are not read-only. Multi-threaded applixations certainly do not only work
with read-only data. That's where data access serialization comes in.
However, I am not sure it's relevant to our Pimpl topic.

> There is no need for a policy either, since you could just use
> shared_ptr in your implementation type if you want something to be
> shared and not copied. (that actually gives you more flexibility for the
> implementation than setting a policy in the interface, which would set
> the ABI)

Thanks, I am not (yet) convinced that I can apply that to my Pimpl
implementation (without exposing implementation detail) but I'll cetainly
have a look if that might could be done.


Boost list run by bdawes at, gregod at, cpdaniel at, john at