Boost logo

Boost :

Subject: Re: [boost] [pimpl] No documentation for pointer semantics
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2014-06-06 20:21:19

Rob Stewart-6 wrote
> On June 6, 2014 8:02:44 AM EDT, Vladimir Batov wrote:
>>Rob Stewart-6 wrote
>>> ...
>>>> On June 6, 2014 4:59:47 AM EDT, Vladimir Batov wrote:
>>>>... my offering of pimpl::pointer_semantics and
>>>>pimpl::value_semantics seems to make sense.
>>> That's the problem. It isn't the Pimpl Idiom anymore.
>>Well, that was a few nervous hours when I felt my familiar Pimpl world
>>was crashing all around me... after looking closely it seems my "extended"
>>interpretation of Pimpl to still be the Pimpl Idiom. :-) First, Pimpl
>>== Handle/Body == Bridge.
> Assertion
> ...
> Conclusion
> If one accepts the assertion that the Pimpl Idiom is the Bridge Pattern,
> the conclusion is appropriate. I don't accept the assertion. That is, the
> Pimpl Idiom is the degenerate case, but it isn't the same as the Bridge
> Pattern.

Rob, if I understand correctly, you concede that my offering of
"pointer_semantics" and "value_semantics" is appropriate *if* it was called
"bridge" rather than "pimpl" because you assert that my-pimpl == bridge and
real-pimpl == my-pimpl:value_semantics. In other words, "real pimpl is a
subset of bridge, a coincidental bridge, a degenerate bridge", right?

Here we have no choice but go and ask H. Sutter as it was him who
popularized Pimpl and wrote quite a bit about it.


In #1 Sutter introduces Pimpl as "a special form of the handle/body idiom
(what I call the Pimpl Idiom...";
Then in #2 he reiterates again that "This is a variant of the handle/body

So far, it's not exactly clear who is correct in our interpretations of
Pimpl because loosely "variant" might be interpreted as "subset"... although
strictly speaking "variant" means "modified" ( In
earlier Sutter's writings I certainly find those constant references to the
Bridge pattern quite unfortunate... *if* that similarity is purely
incidental. Maybe it was done for educational purposes. And, indeed, in his
later writings Sutter seems to drop mentioning Bridge and exclusively
stressing Pimpl being the Compiler Firewall idiom.

When I read Sutter's later writings on that topic (and I see you
participating in the conversations), I can see where your convictions are
coming from. He uses std::unique_ptr in his C++11 examples and in #3 even
provides a "some sort of library helper" as a generalization of the idiom.

It's hard for me to say if Sutter's later focus on the Compiler Firewall
idiom using only value-semantics is for educational purposes (to avoid
distractions) or he indeed shares your (strict) convictions. I must confess
that, if I agree with your strict view/interpretation of Pimpl, then I'd
personally find it quite disappointing that after all that talk and
discussions and everything Pimpl turns out to be merely a degenerate
Bridge... something GoF stated from the very beginning in 1994... i.e. what
was all that fuss for 20 years?

All that said, now I am beginning to wonder if that's a good idea to even
try getting "my-pimpl" into Boost. There seems no clear interpretation (in
our *collective* mind) of what Pimpl embodies, what is Pimpl and what is
not. More so, from reading #3 I conclude that Sutter advocates a far(!)
simpler deployment pattern than I am offering. IMO all that uncertainty and
controversy do not bode well for the code wishing be a part of Boost.


View this message in context:
Sent from the Boost - Dev mailing list archive at

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