Boost logo

Boost :

Subject: Re: [boost] pimpl library proposal
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2010-12-14 05:14:39

> From: "Krzysztof Czainski" <1czajnik_at_[hidden]>
> Sent: Friday, December 10, 2010 12:06 AM
> ...
>> template<class T>
>> struct pimpl
>> {
>> typedef pimpl_base<impl_ptr> value_semantics;
>> typedef pimpl_base<boost::shared_ptr> pointer_semantics;
>> typedef pimpl_base<cow_ptr> cow_semantics;
>> };
>> Isn't it "customization of the copying policy"? Or did you mean something
>> else?
> I see. But if I understand correctly, for each smart pointer type, there
> needs to be a specialization of pimpl_base written from scratch.

I am not sure where you've got that impression from. There is one pimpl_base
implementation. Pointer- or value-semantics behavior are defined by the
provided policy class. Pls see the declaration above.

> Now suppose pimpl_base<SmartPtr> does accept any smart pointer:
> scoped_ptr,
> shared_ptr, clone_ptr, cow_ptr, etc... This is where the creation policy
> is
> needed. See below...

I do not immediately see value in Pimpl accepting "any smart pointer" which
are policy classes for Pimpl. In fact, I do not know of any policy-based
class which would accept *any* other class as its policy. I am convinced a
class to be used as a policy by another class must conform to a certain

> ...
>> I am under impression that I do not quite understand what you mean by
>> "customization of the creating policy" either. Isn't that quality
>> achieved
>> by overloaded constructors? If it is so, then the developer provides the
>> set
>> of overloaded constructors for his/her class. Regardsless of those
>> constructors Pimpl does not need to be modified.
> The default creation policy would be to create impl on the heap using
> operator new, and passing the resulting pointer to SmartPtr. But for
> example, when using shared_ptr, it might be a good idea to use a)
> make_shared instead of operator new, b) a custom allocator/deleter.

I am under impression that the functionality you are suggesting is already
available. Namely, (unless I am still missing your point) "make_shared"
quality is provided by boost::shared_ptr itself and nothing more needs to be
done. As for "custom allocator/deleter" or any other creation policy, then
that functionality belongs in the "implementation" class and deployed via
Pimpl interface. So, it seems nothing more needs to be done in Pimpl either.

> 3. The user should have no way of telling if MyClass uses pimpl or not. It
> should be totally transparent.

I happen to disagree. Pimpl implements a certain pattern/idiom which has
certain qualities. The user deploying that pattern/idiom expects those
qualities. After all, that's why he/she is deploying that pattern/idiom in
the first place. I do not immediately see benefits of hiding those

> Well, I understand You expose the operator bool_type for example.

Again, I believe it is part of the idiom. For example, boost::shared_ptr is
similar in that regard.

> But that is not all. I believe a user is also someone deriving form
> MyClass.
> Your pimpl takes part in runtime polymprphism, and for that it must be
> visible by derived classes.

Again, Pimpl is implementation of a certain programming technique.
Consequently, one can certainly inherit from a Pimpl (and I do it a lot) but
without negating Pimpl's property and ultimately the object size. It's done
via the Bridge pattern (as in GoF). Essentially, the developer has two
separate inheritance hierarchies -- for interface and for implementation. I
believe I have it covered in the documentation.

> ...
> I just thought that, since the user should not know of pimpl's existence,
> there should be no functions to inherit from it.

I see no value in encapsulation for the sake of encapsulation. Say, you can
"typedef boost::shared_ptr<Foo> Zoo;" or go further trying to hide the fact
that Zoo is, in fact, a shared_ptr and, consequently behaves as a
shared_ptr. By trying to hide that fact I believe you do the user great
disservice as you deny the user the knowledge that Zoo has certain
qualities/properties (namely, shared_ptr properties) as *must* be treated as

> ...
>> As for your concern about "a lot of operations" in Pimpl "potentially
>> conflicting with operators" of YourClass, then my reading of the
>> specification is somewhat different. Namely, as I understand, a method
>> introduced in the derived class makes *all* the methods with the same
>> name
>> (not just the same signature) in the base class inaccessible.
> True. So, what if the implementer adds operators * and -> to MyClass?
> Accessing pimpl is still possible, but not as convenient any more.
> satic_cast<implementation&>(*this)->... or an extra local reference is
> always needed:

Therefore, if I understand you correctly you are suggesting to remove those
operators altogether, right? ;-) More so, there is no need for the user to
add operators * and -> as Pimpl provides already those operators for

> For the pointer_semantics-based Pimpl: I do not think that MyClass should
> have pointer semantics just because its pimpl has pointer semantics. So I
> am
> against forwarding op== from the underlying shared_ptr.

I am not sure I follow -- you deploy pointer-semantics Pimpl but do not want
it to behave as such. I have that feeling you are trying to make things
harder than they need be. In my simple world, if I deploy a fork, I do want
it to "behave" as a fork, i.e. to expose fork-like properties. If I don't,
I'll deploy something else.

> I just think virtual functions should just stay in MyClass, and not go
> into
> pimpl, because they should not be hidden. That is why I think "pimpl
> should
> have nothing to do with polymorphism" ;-)

I do not believe the proposed Pimpl implementation has any virtual
functions. As described in the documentation it's deployed in the
inheritance hierarchies differently (the Bridge pattern in GoF).

> For an example of how I use pimpl, and my pimpl helper, which I called
> value_ptr, I shall quote my earlier post, adding an example of how some
> member function of MyClass might be implemented in terms of pimpl:

I am sure your Pimpl implementation does everything just the way you want
it. :-) And if that works better for you than an already available
component, then I do not see anything wrong with deploying it. I do the same
all the time. ;-) Still, I suspect if you try deploying your no-frills
version of a larger scale, it'll start looking more and more as the proposed
Pimpl. There are countless examples of that behavioral pattern (Java comes
to mind). As for the proposed Pimpl, let me assure you that the
functionality provided and described there is there for a reason. May I
suggest you have another look at the documentation for the proposed Pimpl?
You might come to appreciate its versatility... or might not. :-)

Good luck and all the best in your endeavors,

Boost list run by bdawes at, gregod at, cpdaniel at, john at