Re: [boost] Pimpl Again?

On 06/10/2016 04:59 AM, Emil Dotchevski wrote:

On Thu, Jun 9, 2016 at 5:19 AM, Rainer Deyke wrote:

...

On 08.06.2016 23:57, Emil Dotchevski wrote:

...

On Wed, Jun 8, 2016 at 2:29 PM Rainer Deyke wrote:

...

implementation behind the scenes. Pimpl is not about semantics, it's about reducing physical coupling. It's not about the pointer pointing at the private implementation object (which, being private, is an implementation detail anyway), it's about the private implementation *type* being left incomplete. Pimpl is a technique where the implementation of a class is moved to a separate implementation class (the "impl"), to which the interface class

3. I want a class to have value semantics, but use a copy-on-write maintains a pointer (the "p"). The "p" stands for "private" not for pointer. The defining property of the pimpl idiom is that the private implementation type is left incomplete in the interface: the pointer is opaque. For example, if you implement copy-on-write using a pointer to a type that is defined in the interface, you're not using pimpl. So, logical design (semantics), including copy semantics, is orthogonal to pimpl.

Emil

Emil, as Sutter described in his early articles the pimpl name was introduced by one of his colleagues where the "p" stood for "pointer" due to Hungarian notation as the type was actually a pointer to "impl". That said, I agree with you stressing the "private implementation" property. However, IMO that property only comes after the "separation of interface and implementation". So, one might argue that a class implementing the "separation" property already qualifies as a pimpl (or Handle or Proxy)... and formally I personally agree that it does. The first (and one might argue the only) pimpl property is the "separation", the introduction of a level of indirection, the introduction of a proxy. Many use it to then hide the implementation. Rainer uses it for write-on-copy. I personally find Rainer's application of Pimpl interesting (and I am considering adding such a policy to the proposed pimpl). Then, when you say that "Pimpl is *not* about semantics", I want to agree with you... but in reality I have to disagree. :-) The reason for that is that (for me) the idiom is about indirection -- through handle to body, through proxy to data, i.e. the idiom defines *two* objects... Even your version has two objects -- opaque data and shared_ptr<data>. And, as soon as we introduce 2 objects, we face the important dilemma of defining the relationship between those two objects. The semantics describes that relationship -- be that the pointer semantics, the value semantics or, as Rainer mentioned, the copy-on-write semantics. One might argue that that's outside the idiom. However, I feel that's splitting a hear as on the practical level the proxy-data relationship is part-n-parcel of the whole package. Don't you agree?