Boost logo

Boost :

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


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?

--
View this message in context: http://boost.2283326.n4.nabble.com/pimpl-No-documentation-for-pointer-semantics-tp4663510p4663548.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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