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-semant... Sent from the Boost - Dev mailing list archive at Nabble.com.