Boost logo

Boost :

Subject: Re: [boost] [pimpl] No documentation for pointer semantics
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-06-06 05:49:59

On June 6, 2014 4:59:47 AM EDT, Vladimir Batov <vb.mail.247_at_[hidden]> 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
>big chunk of data. Not just bit chunk but mostly read-only and

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.

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

Another step away...

>Now that I am researching Handle/Body, Bridge they are about decoupling
>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
>Bridge, etc. descriptions I've read so far indeed do not mention
>"shareability". However, they do not say that "shareability" is *not*
>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.)

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

No, it doesn't.

>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.


(Sent from my portable computation engine)

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