From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-10-18 13:20:42
> That's fair enough. I myself certainly always use shared_ptr-based Pimpl.
> However, due to specificity of my task I tend to use Pimpls with pointer
> semantics only. In this discussion thread as soon as I mentioned Pimpl
> people asked for value semantics and I believe that's reasonable. Are you
> saying you've been using shared_ptr for Pimpls with value semantics?
My use cases so far have always been of the form
typedef shared_ptr<impl> handle;
handle create( ... );
void operation( handle, ... );
#include <windows.h> // this is why we bother with a pimpl
<windows.h> is just an example, of course, there are many other headers that
one would like to hide behind a pimpl. This also creates a stable binary
I think I had a need for a value-based pimpl once or twice, but I don't
remember how I handled it. Probably the old-fashioned way.
> Unfortunately, neither your impl_ptr nor Alan Griffith grin_ptr seem to be
> complete. Alan's implementation is very basic and does not seem to handle
> run-time polymorphic classes. Your impl_ptr is better in that regard and
> closer to shared_ptr (for obvious reasons :-)). However, dynamic_traits
> extends incomplete-type management only onto copy when I feel it needs to
> the same for assignment and comparison. I do not feel impl_ptr's approach
> assignment via deletion and copy construction is 100% kosher.
An interesting question. I haven't given assignment much thought since in
the Old C++ Days (before move), if you were willing to expose a heavy copy
constructor that hits the heap, once could reasonably conclude that the
class (or rather the container it's being put in) is not
performance-critical. So implementing assignment in terms of copy
construction wasn't that bad, efficiency-wise, and saved the user from
having to make the implementation class Assignable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk