Re: [boost] An attempt to generalize thePimplidomwithproperlyseparated interface and implementation

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-10-18 13:20:42

Vladimir Batov:

...

> 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

// foo.hpp:

namespace foo
{

class impl;

typedef shared_ptr<impl> handle;

handle create( ... );
void operation( handle, ... );

}

// foo.cpp:

#include "foo.hpp"
#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 
interface.

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 
> do
> the same for assignment and comparison. I do not feel impl_ptr's approach 
> to
> 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.