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
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk