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