Boost logo

Boost :

Subject: Re: [boost] A Pimpl variant
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2010-04-03 00:05:12

On Fri, Apr 2, 2010 at 8:13 PM, Vladimir Batov <vbatov_at_[hidden]> wrote:
> Now that I am thinking of the RecklessPimpl-based Pimpl, I see that it does
> provide the implementation-hiding property. However, what troubles me is
> that we seem to lose the other important Pimpl property -- the separation of
> the interface and implementation. Namely, if the internal implementation
> size changes, it has to be reflected in the public header. So, all the
> user-code has to be recompiled.

Yes, that is the limitation. As in my example, when I first wrote it,
I was hiding objects whose size wasn't about to change (eg
CRITICAL_SECTION). There was also an option to over-allocate 'extra
room' by using a size-estimate that was too large. With another
template flag, you could say whether you wanted the size check to be
exact or 'big enough'.

Either way, it doesn't completely eliminate client-recompiles, but it
can lessen them. Including for those cases, like your #5 where you
are adding private functions, etc.

> More so, if my experience is of any guidance, I overwhelmingly use pimpls
> with pointer semantics. In my code they outweigh pimps with value semantics
> like 100:1. I am under impression that the RecklessPimpl-based Pimpl only
> provides value semantics.
> All in all, IMHO the RecklessPimpl-based Pimpl might be a nice fit for
> certain tasks. However, I am under impression that it is not generic
> enough... and, in fact, not Pimpl enough as it loses the separation of the
> interface and implementation and does not provide pointer semantics. All
> IMHO, of course.

some of us value value sematics. :-)

RecklessPimpl obviously isn't for all occasions, but it might make a
nice complement in a package of various Pimpl options.


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