Re: [boost] An attempt to generalize the Pimpl idom with properly separated interface and implementation

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

Mathias,

> Here is a simple deep-copying smart pointer.
[snip]
> 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.

[snip]
> 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.

[snip]
> 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.

Thanks,
Vladimir.