|
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
>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)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk