Re: [boost] Review Request: Generalization of the Pimpl idiom

From: Vladimir.Batov_at_[hidden]
Date: 2008-03-31 16:07:21

"Mathias Gaunard" <mathias.gaunard_at_[hidden]> wrote in message 
news:<fsptpe$peo$1_at_[hidden]>...
> 
> I have only quickly gone through your documentation on DDJ, so my 
> comments may be off. Feel free to correct me if I misunderstood 
something.
> 
> Personally, I fail to see the advantage over a shared_ptr member.
> The only differences I could notice are
>   -  implementation class is not user-declared but rather is a 
> specialization of a template.

Well, the pimpl idiom is certainly not a shared_ptr.as pimpl's main 
purpose is separation of interface and implementation and imlemetation 
hiding. shared_ptr does not provide the latter. I was hoping I covered all 
that in the article. 

>   - the null pointer is called null (by the way, I think we shouldn't 
> allow a null value, the private implementation should always be 
> initialized somehow, if lazily)

The private implementation is always initialized by default. Nowever, 
null() is certainly needed for many things. And Foo::null() is certainly 
not a pointer but a proper (but invalid :-)) Foo instance.

> There doesn't seem to be any useful help for allocating the private 
> implementation.

What exactly are your expectations? If you'd like private implementation 
to be allocated for you, then it's simply not possible as ity is called 
private for a reason.

> Such potentially interesting allocation schemes, like stack allocation, 
> seem also to be impossible.

I have not seen one single implementation of pimpl allocating private 
implementation on the stack and I do not believe it is possible as in 
order to allocate on the stack we/compiler have to know the size of the 
class (private implementation class) which is again private.

> Being able to replace the private implementation of a base with the 
> private implementation of a derived class certainly is a necessity.
> I have to admit, though, I do not understand your solution.
> You're passing a null<Widget>() to the Widget constructor, but the 
> constructor wasn't written to take any kind of special argument.

null<Widget>() is an instance of Widget. Therefore, the copy constructor 
is called.

> I'm not really sure of the point (and validity) of having pointer 
> semantics. Do you really want your implementation details to be shared 
> by some of your different instances? (maybe there is a point in sharing 
> implementation details with all instances or all equivalent instances, 
> but some?)

I am not sure about your usage patterns but my usage of 
pimpl::pointer_semantics vs. pimpl::value_semantics is 100:1. What is the 
point (and validity) of having shared_ptr<Foo>? Same is applicable to 
pimpl::pointer_semantics.

> It seems more logical to me to have the same semantics for the object 
> and its private implementation. If the object itself has pointer 
> semantics, then you won't copy it. Using one or the other for the 
> implementation makes no difference, then. You might as well use the 
> value semantics, which would even be more lightweight in that case.

I personally do not see logic the same semantics for the object and its 
private implementation because the object is the interface and its private 
implementation is implementation detail (which is private as well). They 
serve different purpose, have different visibilities et al. What is the 
advantage of them having the same semantics?

Thanks,
Vladimir.