Subject: Re: [boost] A Pimpl variant
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2010-04-02 20:13:44
> ----- Original Message -----
> From: "Vicente Botet Escriba" <vicente.botet_at_[hidden]>
> ...
> Hi, I'm aware of your proposal Vladimir :)
> ...
> BTW, does your library provides a RecklessPimpl implementation or
> something
> like that?
You are right, it does not. For quite some time I shared H. Sutter's point
of view that the RecklessPimpl-based solution was, well, evil. :-) Then, I
read Tony's explanations and that did not look that scary to me after all...
if as Tony's suggested all the "nastiness" is encapsulated in RecklessPimpl.
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.
Still, elimination of the memory-allocation-related overhead of the
RecklessPimpl-based Pimpl looked very attractive. Then, I thought that a
fixed-size allocator for the XImpl implementation class might be a
good-enough main-stream alternative. Granted that a fixed-size allocator
might not be as fast as allocation on the stack.
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.
Best,
V.