Boost logo

Boost Users :

Subject: Re: [Boost-users] Pimpl framework comments/suggestions
From: Rob Riggs (rob_at_[hidden])
Date: 2011-04-17 12:24:15

On 04/14/2011 11:32 PM, Clinton Mead wrote:
> Hi All
> I've been experimenting with pimpl recently. What I've seen written
> about the pimpl idiom is that you have an interface class and an
> implementation class, and in the interface class you put some kind of
> pointer to the implementation.
> However, I thought, sometimes you might want that to be a shared
> pointer. Or an intrusive pointer. Or unique pointer. Or maybe
> sometimes you might decide not to use pimpl at all.
> I thought it was a bit silly that you had to make these decisions at
> the time you create the interface class. I thought it would be nice if
> you could write the interface independent of how it was going to be
> connected to the implementation, and then hook them together however
> you like.
> So this is what I've done. Basically I've broke things up into three
> separate parts:
> (1) Interface
> (2) Implementation
> (3) What joins them together (i've created unique_pimpl and
> shared_pimpl as examples)
> I've implemented a unique_ptr and shared_ptr pimpl implementations as
> examples. The idea is that you can basically do this:
> unique_pimpl<interface, impl>::create(...) or
> shared_pimpl<interface, impl>::create(...)
> make_your_own<interface, impl>::create(...)
> for any interface and implementation you choose.
> I've included all the code in a question at
> but it doesn't seem to be
> getting much attention there, so I thought I'd bring it up on this list.
> If something like this isn't in Boost, and people like it, with a bit
> of help I'd be happy to work on it to get it into Boost. Alternatively
> I'm happy for someone else to Boostify this. I've used a bit of c++0x
> in the code, gcc 4.4.5 will compile it though.
> However if I'm just (badly) reinventing the wheel, if someone could
> direct me to where this has already been done that would be good to.
Hi Clinton,

The point of a Pimpl is that the user never knows or cares that it is a
Pimpl -- it's just another object. Pimpl is a very small implementation
detail. With this code, that detail is no longer very small -- the user
needs to know too much about how the object was implemented.

While Pimpl initially stood for "pointer to implementation", a better
way to think about it is "private implementation". The implementation
is completely hidden from the user (and the compiler). With your
proposal, a significant part of the implementation is no longer
private. In fact, it has leaked into the interface.

Take a look at this article for good insights into Pimpl and another

I still think this adds more complexity to Pimpl than is warranted.
But, if I had to implement dozens of such classes for a library, I might
change my mind...



Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at