Re: [boost] [review][pimpl_ptr] Pimpl Pointer review (COW)

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-05-20 14:00:35

Rene Rivera wrote:
> Tobias Schwinger wrote:
> 
>>Rene Rivera wrote:
>>
>>>I think we all have to keep in mind the scope of this utility. It not 
>>>meant to solve all the pointer uses. 
>>
>>I understand your concern, still, in my eyes COW is just another 
>>application of the handle/body pattern and thus not /that/ far 
>>away from the scope of this submission. 
> 
> [...]
> 
>>> From my experience, you don't because at that point you would use some 
>>>other kind of pointer. Most likely a reference counted pointer that can 
>>>travel across DLL boundaries.
>>
>>    template<typename T> void dispose_func(void* ptr) 
>>    { delete static_cast<T*>(ptr); }
> 
> 
> Yes I do know how the DLL boundary issue is solve ;-) 

I figured /you/ do, but the issue deserved public demystification ;-).

> My point is the reference counting... 

Yes, I do understand your point, that is looking from the perspective
of someone who implements a smart pointer.

> What is being suggested, by you and others, is to have a reference 
> counted pointer with deep copy semantics implemented as copy on 
> write for efficiency. 

>From a user's perspective, however, it makes sense that an opaque 
smart pointer intended for Handle/Body is implemented as copy on 
write in some cases (and it is completely unimportant to me whether 
the copy on write implementation needs reference counting to get the 
job done):

Let's say I use the pimpl idiom in an imaginary application. I use a 
Boost utility and (as usual) I'm quite happy with it.
Some time later (say, the application has been released) it turns out 
that things should run faster and my profiler tells me that (among 
other things) the application spends too much time copying pimplEd 
classes.
At this point I'm very thankful, if all I have to do is switch the 
smart pointer to a different memory mangement policy, rather than 
being left on my own. 

Note that especially classes that are expensive to copy tend to be 
good candidates for both pimpl and COW, so optimization will not 
affect a well-done design. And (as stated in my previous post) both
pimpl and COW are applications of the very same design pattern, 
namely Handle/Body (or Bridge using Go4 terminology).

> And in my opinion at that point you are looking at the territory of 
> shared_ptr/weak_ptr, 

If so (see above)...

> and hence outside of the intended scope of the 
> pimpl_ptr submission.

...the scope might be too narrow.

Regards,

Tobias