Boost logo

Boost :

Subject: Re: [boost] [pimpl] No documentation for pointer semantics
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-06-07 09:04:21


On June 6, 2014 8:21:19 PM EDT, Vladimir Batov <vb.mail.247_at_[hidden]> wrote:
>Rob Stewart-6 wrote
>>
>> 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?

Yes. I should go re-read GoF's description of Bridge and Coplien's description of Handle/Body. It's been a lot of years since I last did so.

>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.
>
>1) http://www.gotw.ca/publications/mill04.htm
>2) http://www.gotw.ca/publications/mill05.htm#1
>3) http://herbsutter.com/gotw/_101/
>
>In #1 Sutter introduces Pimpl as "a special form of the handle/body
>idiom
>(what I call the Pimpl Idiom...";

Saying it's a special form already implies differentiation.

>Then in #2 he reiterates again that "This is a variant of the
>handle/body
>idiom."

Ditto for "variant".

>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" (http://thesaurus.com). 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.

I find no inconsistency or room for confusion. Pimpl implements a degenerate form of the Bridge Pattern, but it isn't the same as other variants of the pattern. Therefore, calling all variants by the name of one degenerate variant is the problem.

[snip]

>All that said, now I am beginning to wonder if that's a good idea to
>even
>try getting "my-pimpl" into Boost.

I've never shared the implementation of a class among instances, apart from COW or Flyweight contexts, to my knowledge. I'm uncertain whether your shared mode supports those better than, for example, shared_ptr or custom solutions, but that doesn't mean it isn't useful, since you've been using it for years.

 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.

As I noted before, if you name your library Bridge, and it offers both pimpl and, say, shared_bridge class templates, the functionality remains and the confusion is lessened (at least for those that have never associated sharing with Pimpl). You could go with bridge::value_semantics and bridge::pointer_semantics, if you really want to, but I don't think that's as nice. Then again, using aliases mean you can offer both.

IOW, I suggest that you postpone the review, rework your library, and then offer it for review.

___
Rob

(Sent from my portable computation engine)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk