Boost logo

Boost :

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-03-31 18:52:54


From: <Vladimir.Batov_at_[hidden]>
Subject: [boost] Review Request: Generalization of the Pimpl idiom

>I hope I am following the submission procedure correctly. I read the
> guidelines and I seem to do what is needed. Apologies if I missed
> something.
> The code is in the Boost Vault called
> It compiles with GCC 4.1.2 (I use it on Ubuntu 7.04) and MS Visual Studio
> 2005.
> Documentation is at DDJ site:
> Any questions/suggestions/critique - vladimir.batov_at_[hidden]
> Thanks,
> Vladimir

First of all, I think that a pimpl library should have a place in boost, but
I think that the pimpl idiom do not scale very well and the library should
present the advantages as well as the liabilities (see below).

Are you thinking in writing the library documentation before the review?
Even if there is a tutorial in DDJ, IMHO, you should spend some time on the
documentation of the library before the review.

Your library is usable in simple cases, I would like to see how it can
manage more complex cases. If no satisfactory solution to these more complex
cases is possible, the library documentation should express it explicitly.

Could you clarify if the base implementation pointer can or can not be
initialized with a pointer to the implementation of the derived class? There
is something wrong in

    Base::Base(int k) : base(new BaseImpl(k)){}
    Derived1::Derived1(int k, int l) : Base(new Derived1Impl(k, l))

respect to

    Base::Base(int k) : base(null())
        reset(new BaseImpl(k));

    Derived1::Derived1(int k, int l) : Base(null<Base>())
        reset(new Derived1Impl(k, l));

Could a class inherit privately from pimpl?

class A : private pimpl<A>::value_semantics {...}

There is something that seams extrange to me. If the pimpl is there to mask
the implementation, doesn't adds the public inheritance of
pimpl<A>::value_semantics some implemtation constraints?
Note that public inheritance adds to the class interface the null()
function, bool type conversion and ! operator, and adds also all the
protected functions to the derevied classes.
Can we found always a null object for every class when pimpl is not used?

Can a class that inherits from a non pimpl class has its own private impl?

class A;

class B : A, public pimpl<B>::value_semantics {...}

How the B implementation has access to A?

maybe we need something like that

class B : public pimpl<B, A>::value_semantics {...}

making the implementation of B inherit from A.

Could we inherit publicly from A and privatly from pimpl<B,

Can we manage with multiple inheritance?
class A : public pimpl<A>::value_semantics {...};
class B : public pimpl<B>::value_semantics {...};
class C : public A, public B {...};

How pimpl interacts with STL containers?

stl::list<A> al;
B b;
// ...somewhere else
A a =al.pop_back();

How 'a' should behaves? like a A or like a B? The STL container user that
shouldn't knowns nothing about A implementation, expect that it will behaves
as a A, but it think that 'a' will behaves like a B. How can we protect from
this situation?

Could we store a non polymorph pimpl object in shared memory?
Could we store non polymorph pimpl objects in a container in shared memory?

I hope that you will find good solutions to these problems. In any case, I
will apreciate that you include in the library documentation the limitations
of the approach, if there are any.


Vicente Juan Botet Escriba

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