[pimpl] No documentation for pointer semantics

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[pimpl] No documentation for pointer semantics

Edward Diener-3
The documentation for "Pimpl with Value Semantics" has:

"and was deployed in the previous chapter for the Pimpls with pointer
semantics..."

but there is no previous chapter about Pimpl with pointer semantics.
 From that point on the documentation of "Pimpl with Value Semantics
makes no sense to me and I do not know what is being explained.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Vladimir Batov-5

On 06/06/2014 09:27 AM, Edward Diener wrote:
> The documentation for "Pimpl with Value Semantics" has:
>
> "and was deployed in the previous chapter for the Pimpls with pointer
> semantics..."
>
> but there is no previous chapter about Pimpl with pointer semantics.
> From that point on the documentation of "Pimpl with Value Semantics
> makes no sense to me and I do not know what is being explained.

Yes, the chapter you are referring to says "/std::shared_ptr/ ... was
deployed in the previous chapter". The previous chapter is called
"Getting Started". It says "we would like ... a /Pimpl/-style class with
the /pointer semantics/. That is:". Then it goes on to explain what
Pimpl with /pointer semantics /is and how shared_ptr plays a role there.
Still, I'll try to re-phrase the chapters to clarify. Thank you, Edward.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Gavin Lambert
In reply to this post by Edward Diener-3
On 6/06/2014 11:27, quoth Edward Diener:
> The documentation for "Pimpl with Value Semantics" has:
>
> "and was deployed in the previous chapter for the Pimpls with pointer
> semantics..."
>
> but there is no previous chapter about Pimpl with pointer semantics.
>  From that point on the documentation of "Pimpl with Value Semantics
> makes no sense to me and I do not know what is being explained.

I believe the prior chapter being referred to is the directly prior
chapter, titled "Getting Started", which shows a class implemented using
pointer semantics.

To be honest I'm a little surprised that pointer semantics are even
discussed; I've always regarded a pointer-semantics-pimpl as a bug
rather than intentional design.  I suppose there could be occasions
where it could be useful for more abstract resources (eg. a database
connection) but doing it for a Book does not seem appropriate to me.
(Perhaps that's just my internal biases showing though.)



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Edward Diener-3
In reply to this post by Vladimir Batov-5
On 6/5/2014 7:53 PM, Vladimir Batov wrote:

>
> On 06/06/2014 09:27 AM, Edward Diener wrote:
>> The documentation for "Pimpl with Value Semantics" has:
>>
>> "and was deployed in the previous chapter for the Pimpls with pointer
>> semantics..."
>>
>> but there is no previous chapter about Pimpl with pointer semantics.
>> From that point on the documentation of "Pimpl with Value Semantics
>> makes no sense to me and I do not know what is being explained.
>
> Yes, the chapter you are referring to says "/std::shared_ptr/ ... was
> deployed in the previous chapter". The previous chapter is called
> "Getting Started". It says "we would like ... a /Pimpl/-style class with
> the /pointer semantics/. That is:". Then it goes on to explain what
> Pimpl with /pointer semantics /is and how shared_ptr plays a role there.
> Still, I'll try to re-phrase the chapters to clarify. Thank you, Edward.

I think you need to explain what the actual pimpl class template is and
does before jumping in with examples that use it. I do admit I am a
person who is nearly incapable of using software based largely on
examples rather than on actual well-explained concepts and interface
details.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Vladimir Batov-5

On 06/06/2014 11:29 AM, Edward Diener wrote:

> On 6/5/2014 7:53 PM, Vladimir Batov wrote:
>>
>> On 06/06/2014 09:27 AM, Edward Diener wrote:
>>> The documentation for "Pimpl with Value Semantics" has:
>>>
>>> "and was deployed in the previous chapter for the Pimpls with pointer
>>> semantics..."
>>>
>>> but there is no previous chapter about Pimpl with pointer semantics.
>>> From that point on the documentation of "Pimpl with Value Semantics
>>> makes no sense to me and I do not know what is being explained.
>>
>> Yes, the chapter you are referring to says "/std::shared_ptr/ ... was
>> deployed in the previous chapter". The previous chapter is called
>> "Getting Started". It says "we would like ... a /Pimpl/-style class with
>> the /pointer semantics/. That is:". Then it goes on to explain what
>> Pimpl with /pointer semantics /is and how shared_ptr plays a role there.
>> Still, I'll try to re-phrase the chapters to clarify. Thank you, Edward.
>
> I think you need to explain what the actual pimpl class template is
> and does before jumping in with examples that use it.

Thanks, Edward. I'll try to re-do the relevant parts as you suggest.
Won't do in in a hurry though remembering my experience with "convert",
right? :-)

> I do admit I am a person who is nearly incapable of using software
> based largely on examples rather than on actual well-explained
> concepts and interface details.

Aha, I suspect you are over 20y.o., aren't you? :-) Down here I sometime
deal with uni students (practice placement) -- they expect everything to
be explained in the Introduction. I kid you not, I had a case when a
student (well, a young employee) need to lean C++, was given a C++ book
to read and then he came back saying -- "I read the Intro, I
more/less(?) understand what it's about. Where do I go from here?" :-)
Anyway, I'll re-work the docs.





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Rob Stewart-6
On June 5, 2014 10:08:15 PM EDT, Vladimir Batov <[hidden email]> wrote:
>
>I'll try to re-do the relevant parts as you suggest.
>Won't do in in a hurry though remembering my experience with "convert",
>right? :-)

Since the review hasn't started, change all you like.

___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

pabristow
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Rob Stewart
> Sent: 06 June 2014 03:55
> To: [hidden email]
> Subject: Re: [boost] [pimpl] No documentation for pointer semantics
>
> On June 5, 2014 10:08:15 PM EDT, Vladimir Batov
> <[hidden email]> wrote:
> >
> >I'll try to re-do the relevant parts as you suggest.
> >Won't do in in a hurry though remembering my experience with "convert",
> >right? :-)
>
> Since the review hasn't started, change all you like.

I unhappy with a review rigid policy that nothing can be changed during a
review.  It isn't always helpful.

We never accept anything without requiring some changes?

Can we instead now use git's easy branches to specify a fixed 'master' branch,
but allow the author to update a 'develop' branch as the review develops?

That way typos and more serious mistakes can be corrected as the review
proceeds.  This will avoid people being confused by these.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 01539 561830





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Vladimir Batov
In reply to this post by Gavin Lambert
Gavin,

Gavin Lambert wrote
...
To be honest I'm a little surprised that pointer semantics are even
discussed; I've always regarded a pointer-semantics-pimpl as a bug
rather than intentional design.  
It's is amazing. I am really surprised to read that. Not in an angry way but in a really unexpected way. Andrzej shared your view and as strongly as well. I am so surprised because I am on the exactly opposite end -- I've been using that Pimpl-enabling "helper" class on a few big projects... exclusively with pointer-semantics.

I suppose there could be occasions
where it could be useful for more abstract resources (eg. a database
connection) ...
I am looking back and trying to figure out how my deployment was/is so different from what you and Andrzej would use Pimpl for. Now that I am thinking about it seems to always play a role of a (shared) handle to some big chunk of data. Not just bit chunk but mostly read-only and non-copyable. For example, a description of a railway track only makes sense when it has prev/next track references, i.e. it has to be accessed as part of the whole picture (railway network). So, for me the implementation-hiding property of Pimpl would always go hand-in-hand with the proxy/handle property... For some reason I always assumed many Handles in the Handle/Body idiom... which Pimpl is just another name for.

Now that I am researching Handle/Body, Bridge they are about decoupling of an abstraction from its implementation. No explicit mention of "shareability" of the implementation. Seems like Rob was right saying I inadvertently "extended the idiom"... On the other hand all the Handle/Body, Bridge, etc. descriptions I've read so far indeed do not mention "shareability". However, they do not say that "shareability" is *not* part of the idiom either. To me it makes sense because Handles are cheap. So, having many Handles for one Body does not seem like such a huge leap. In that light, my offering of pimpl::pointer_semantics and pimpl::value_semantics seems to make sense.

... but doing it for a Book does not seem appropriate to me.
(Perhaps that's just my internal biases showing though.)
What's so different about a Book? Imagine, we model a Library -- a collection of Books. Books are not copied around, instead references to the real and one only Book are passed around. That way if I try borrowing a Book, I'll access its actual data to see if it's available or, maybe, you beat me to it by borrowing it first via your reference. Sounds like our model corresponds quite closely to the real working of a library... which is usually a good thing, right?

Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Rob Stewart-6
On June 6, 2014 4:59:47 AM EDT, Vladimir Batov <[hidden email]> wrote:
>
>I am looking back and trying to figure out how my deployment was/is so
>different from what [Gavin] and Andrzej would use Pimpl for. Now that I am
>thinking about it seems to always play a role of a (shared) handle to
>some
>big chunk of data. Not just bit chunk but mostly read-only and
>non-copyable.

There's nothing wrong with such an implementation.

>So, for me the implementation-hiding
>property of
>Pimpl would always go hand-in-hand with the proxy/handle property...

That's where you go off-track, so to speak.

>For
>some reason I always assumed many Handles in the Handle/Body idiom...
>which
>Pimpl is just another name for.

Another step away...

>Now that I am researching Handle/Body, Bridge they are about decoupling
>of
>an abstraction from its implementation. No explicit mention of
>"shareability" of the implementation. Seems like Rob was right saying I
>inadvertently "extended the idiom"...

:)

> On the other hand all the
>Handle/Body,
>Bridge, etc. descriptions I've read so far indeed do not mention
>"shareability". However, they do not say that "shareability" is *not*
>part
>of the idiom either. To me it makes sense because Handles are cheap.

Making such a lap is not a problem. Continuing to call what you're doing by the same name is the problem. What you're doing is COW, at least if  writing the underlying data triggers a copy. (If not then I'd say you're providing a variation of the Flyweight Pattern.)

>So,
>having many Handles for one Body does not seem like such a huge leap.

No, it doesn't.

>In
>that light, 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.

___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Rob Stewart-6
In reply to this post by pabristow
On June 6, 2014 4:51:36 AM EDT, "Paul A. Bristow" <[hidden email]> wrote:

>> -----Original Message-----
>> From: Boost [mailto:[hidden email]] On Behalf Of Rob
>Stewart
>> Sent: 06 June 2014 03:55
>> To: [hidden email]
>> Subject: Re: [boost] [pimpl] No documentation for pointer semantics
>>
>> On June 5, 2014 10:08:15 PM EDT, Vladimir Batov
>> <[hidden email]> wrote:
>> >
>> >I'll try to re-do the relevant parts as you suggest.
>> >Won't do in in a hurry though remembering my experience with
>"convert",
>> >right? :-)
>>
>> Since the review hasn't started, change all you like.
>
>I unhappy with a review rigid policy that nothing can be changed during
>a review.  It isn't always helpful.

The policy is that the material under review must not change during the review. There's no policy against providing a copy that reflects ongoing changes. Vladimir began to do just that during the Boost.Convert review.

>Can we instead now use git's easy branches to specify a fixed 'master'
>branch,
>but allow the author to update a 'develop' branch as the review
>develops?

Sure

___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Niall Douglas
In reply to this post by pabristow
On 6 Jun 2014 at 9:51, Paul A. Bristow wrote:

> > Since the review hasn't started, change all you like.
>
> I unhappy with a review rigid policy that nothing can be changed during a
> review.  It isn't always helpful.
>
> We never accept anything without requiring some changes?
>
> Can we instead now use git's easy branches to specify a fixed 'master' branch,
> but allow the author to update a 'develop' branch as the review develops?
>
> That way typos and more serious mistakes can be corrected as the review
> proceeds.  This will avoid people being confused by these.
AFIO has a special 'boost-peer-review' branch
(https://github.com/BoostGSoC13/boost.afio/tree/boost-peer-review)
intended for peer review.

Said branch is the most stable of all stable branches. I would avoid
using master branch, as sometimes you need to change master branch
because other projects you depend on have changed.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Vladimir Batov
In reply to this post by Rob Stewart-6
Rob Stewart-6 wrote
...
On June 6, 2014 4:59:47 AM EDT, Vladimir Batov <[hidden email]> 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. Now I open GoF pg. 151 -- the Bridge chapter.

The Applicability section -- you want to share an implementation among multiple objects (perhaps using ref. counting).

The Consequences section -- Hiding implementation details from clients. You can shield clients from implementation details, like the sharing of implementor objects and the accompanying ref. counting mechanism (if any).

The Implementation section -- 3. Sharing implementors.

In fact, the Implementation section goes as far as to call one-to-one relationship between Abstraction and Implementor a degenerate case of the Bridge pattern.

I.e. Gof sees pimpl::pointer_semantics, a.k.a. "Bridge with Shared Implementation" to be the proper Bridge when pimpl::value_semantics to be a degenerate one... although I feel it's a "bridge" :-) to far.

Do I get a cookie? :-)
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Edward Diener-3
In reply to this post by pabristow
On 6/6/2014 4:51 AM, Paul A. Bristow wrote:

>> -----Original Message-----
>> From: Boost [mailto:[hidden email]] On Behalf Of Rob Stewart
>> Sent: 06 June 2014 03:55
>> To: [hidden email]
>> Subject: Re: [boost] [pimpl] No documentation for pointer semantics
>>
>> On June 5, 2014 10:08:15 PM EDT, Vladimir Batov
>> <[hidden email]> wrote:
>>>
>>> I'll try to re-do the relevant parts as you suggest.
>>> Won't do in in a hurry though remembering my experience with "convert",
>>> right? :-)
>>
>> Since the review hasn't started, change all you like.
>
> I unhappy with a review rigid policy that nothing can be changed during a
> review.  It isn't always helpful.
>
> We never accept anything without requiring some changes?
>
> Can we instead now use git's easy branches to specify a fixed 'master' branch,
> but allow the author to update a 'develop' branch as the review develops?

I believe that changes can be made to a reviewed library during a review
as long as the 'master' branch does not change. After all we want all
reviewers to be looking at the same 'master' branch as the code to be
reviewed. But if the developer wants to make changes to other branches
during the review I think this should be allowed.

>
> That way typos and more serious mistakes can be corrected as the review
> proceeds.  This will avoid people being confused by these.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Rob Stewart-6
In reply to this post by Vladimir Batov
On June 6, 2014 8:02:44 AM EDT, Vladimir Batov <[hidden email]> wrote:

>Rob Stewart-6 wrote
>> ...
>> On June 6, 2014 4:59:47 AM EDT, Vladimir Batov &lt;
>
>> vb.mail.247@
>
>> &gt; 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

> Now I open GoF pg. 151 -- the Bridge chapter.
>
>The Applicability section -- you want to share an implementation among
>multiple objects (perhaps using ref. counting).

[snip]

>The Implementation section -- 3. Sharing implementors.
>
>In fact, the Implementation section goes as far as to call one-to-one
>relationship between Abstraction and Implementor a degenerate case of
>the Bridge pattern.
>
>I.e. Gof sees pimpl::pointer_semantics, a.k.a. "Bridge with Shared
>Implementation" to be the proper Bridge when pimpl::value_semantics to
>be a
>degenerate one... although I feel it's a "bridge" :-) to far.

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.

>Do I get a cookie? :-)

If your proposed library is named Boost.Bridge, for example, both forms fit. I'd still provide a pimpl class template, however.

___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Pete Bartlett-2
In reply to this post by Vladimir Batov
>Well, that was a few nervous hours when I felt my familiar Pimpl world was
crashing all around me...

FWIW, the worldview around where I am is similar to yours - very natural to
have common scaffolding for the two sorts of "compiler firewall" (to avoid
using the word pimpl!) - those with value semantics and those with
shared-const semantics. Your implementation seems a little better than ours
- the semantics are right there in the base class name making it hard to
miss for the user browsing the source.

Pete



 




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Vladimir Batov
In reply to this post by Rob Stewart-6
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.

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...";
Then in #2 he reiterates again that "This is a variant of the handle/body idiom."

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.

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.

   

Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Vladimir Batov
In reply to this post by Pete Bartlett-2
Pete,

Thank you for chiming in in support. I felt surrounded and outnumbered... :-)

Pete Bartlett-2 wrote
>Well, that was a few nervous hours when I felt my familiar Pimpl world was
crashing all around me...

FWIW, the worldview around where I am is similar to yours - very natural to
have common scaffolding for the two sorts of "compiler firewall" (to avoid
using the word pimpl!) - those with value semantics and those with
shared-const semantics.
Indeed, in my mind having two sides of that "coin" is quite natural... and I feel Rob agrees with us on that... he is just "vehemently" against calling it "pimpl".

It is only now that I realize how unfortunate that Pimpl name is... Never occurred to me before... The funny part wore off and all we are left with is confusion and disagreement on what it stands for.

Unfortunately, I do not feel that comfortable with "compiler firewall" either as IMO it might be even more susceptible to strict interpretation.

Your implementation seems a little better than ours
- the semantics are right there in the base class name making it hard to
miss for the user browsing the source.
If you have your own idiom-generalization solution, do you think we might joing forces so to speak and to cherry-pick the best bits from the both variants and come up with something better/simpler?.. Unless the dead simple Sutter's version at  http://herbsutter.com/gotw/_101/ indeed satisfies the need.
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Vladimir Batov
In reply to this post by Vladimir Batov
Vladimir Batov wrote
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.
>
>... it seems my "extended"
>interpretation of Pimpl to still be the Pimpl Idiom. :-) First, Pimpl
>== Handle/Body == Bridge.
...
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.
...
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...";
Then in #2 he reiterates again that "This is a variant of the handle/body idiom."
...
When I read Sutter's later writings on that topic (and I see you participating in the conversations), ...
Reading Sutter's http://herbsutter.com/gotw/_100 I conclude that he is not of much help to resolve the matter. First he writes:
Class widget uses a variant of the handle/body idiom. As documented by Coplien [1], handle/body was described as being primarily useful for reference counting of a shared implementation, but it also has more general implementation-hiding uses. For convenience, from now on I’ll call widget the “visible class” and impl the “Pimpl class.” [2] One big advantage of this idiom is that it breaks compile-time dependencies... it’s often dubbed a “compilation firewall.”
To me it reads "it's another application of the handle/body idiom but we focus on its other property so we call it pimpl". Then though Sutter indicates that:

Prefer to hold the Pimpl using a unique_ptr. It’s more efficient than using a shared_ptr, and correctly expresses the intent that the Pimpl object should not be shared.
which is clearly a departure from the generic handle/body idiom. I suspect it is due to Sutter being too much of an educator here rather than actual developer (who would realize that sometimes Pimpl object needs to be shared).

That said, I glanced over his pimpl::value_semantics generalization at http://herbsutter.com/gotw/_101/ and my first impression is quite positive. It's very lightweight and I find splitting one header in two (public and private) to be very sensible (ironically matching the handle/body concept). I myself routinely do that to implement pimpl-based hierarchies. In comparison my-pimpl offering looks quite heavy and old (given no C++11 facelift). More and more I feel my-pimpl is a few years late to the party, err... the review.

 






Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Rob Stewart-6
In reply to this post by Vladimir Batov
On June 6, 2014 8:21:19 PM EDT, Vladimir Batov <[hidden email]> 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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [pimpl] No documentation for pointer semantics

Rob Stewart-6
In reply to this post by Vladimir Batov
On June 7, 2014 5:43:14 AM EDT, Vladimir Batov <[hidden email]> wrote:
>
>I glanced over his pimpl::value_semantics generalization at
>http://herbsutter.com/gotw/_101/ and my first impression is quite
>positive.

I like the idea, too.

>It's very lightweight and I find splitting one header in two (public
>and
>private) to be very sensible (ironically matching the handle/body
>concept).

:)

>I myself routinely do that to implement pimpl-based hierarchies. In
>comparison my-pimpl offering looks quite heavy and old (given no C++11
>facelift). More and more I feel my-pimpl is a few years late to the
>party,
>err... the review.

There are many that will not have variadic templates for years, so the older approach can still offer value. That said, your library would be more complete with something like Herb's approach.


___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12