RE: [boost] shared_ptr_updates.zip

From: Philip Nash (philip.nash_at_[hidden])
Date: 2001-07-25 17:29:17

> From: "Philip Nash" <philip.nash_at_[hidden]>
[..]
> > My proposal is for:
> > shared_resource<T> and
> > scoped_resource<T>.
>
> [...]
>
> This would be an useful generalization, but it goes beyond what I
> was trying to do - stay within the shared_ptr<> already established
> interface and, as a quality of implementation issue, make it handle
> the different  heap managers problem and provide a dynamic_cast-like
facility.

Agreed. Sorry, I wasn't suggesting that the finalizer function be dropped
from your proposal, just that getting into the IiRA idiom's is probably
beyond the scope of shared_ptr without bloating it (which you seem to agree
with from the above).

> It turns out that to accomplish this the shared_ptr has to store
> a finalizer function anyway, so it was easy to expose; but whether this
feature will
> become officially part of shared_ptr's interface remains to be determined.

How are you implementing the finalizer, btw? Does it allow for member
functions (useful for obj->Release() style deletions)?

> If you are interested in generalizing shared_ptr into
> shared_resource, note that the updated detail/shared_count.hpp can handle
any type and not just
> pointers, so you would be able to build on that.

Thanks, I've not seen that, I'll take a look.

> Writing the code for a shared_resource<> is the easy part -- it's mainly
> about deleting the irrelevant stuff from shared_ptr. The hard part is
> specifying semantics, writing the documentation and writing a robust test.
> :-) [For me at least.]

Yeah, and get ready for a tide of problem reports following submission as a
proposal, no doubt!

I'll give it a go, though...
Thanks for the comments.

[)o
IhIL..