Boost logo

Boost Users :

Subject: Re: [Boost-users] Pimpl framework comments/suggestions
From: Clinton Mead (clintonmead_at_[hidden])
Date: 2011-04-17 12:49:25

Hi Rob

I don't really understand what you mean by this. What part of the
implementation has leaked into the interface?

Maybe I've missed the point but what I'm trying to achieve is the opposite.
With all the implementations of pimpl I've seen, the "pointer" is leaked
into the interface. I'm just trying to unleak it and separate it. The idea
is that people can write interfaces without having to specify how pimpl is
actually implemented.

Is there another way to do this which is simpler?


On Mon, Apr 18, 2011 at 2:24 AM, Rob Riggs <rob_at_[hidden]> wrote:

> 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
> approach:
> 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...
> Regards,
> Rob
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]

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