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.