Date: 2008-03-31 16:07:21
"Mathias Gaunard" <mathias.gaunard_at_[hidden]> wrote in message
> I have only quickly gone through your documentation on DDJ, so my
> comments may be off. Feel free to correct me if I misunderstood
> 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
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
> 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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk