From: Maciej Sobczak (prog_at_[hidden])
Date: 2004-07-12 15:42:10
Daniel James wrote:
> Max Khesin wrote:
>> As of version 3.1 boost shared_ptr has a constructor that takes a
>> user-defined deleter:
>> Maybe I missed something, but what is your library adding to this?
> His library can handle non-pointers that can't be stored directly in a
> shared pointer.
Exactly, that was my point. There are third-party APIs (and even
operating system interfaces, like file descriptors) where resources are
not handled by explicit pointers, but by "handles", which are usually
lightweight copyable types.
Even assuming that scoped_handle is an easy exercise, a short thought
about potential shared_handle reveals that it would share (ahem) lots of
stuff with shared_ptr, esecially the details of managing reference
counts and custom deleters.
I'm thinking about possibility to reuse all this machinery, but nothing
obvious comes to mind.
I guess that policy-based smart pointer design + template typedefs would
solve this problem (and many others) definitely. :)
> I think there might have been talk of getting a policy base smart
> pointer to do this kind of thing as well.
> I guess that nothing much has happened yet because the need isn't that
Well, that depends on how you look at it.
I'd risk a claim that 95% of programmers would need smart handles more
often than, say, 50% of what is currently in Boost, especially
considering the fact that smart handle would not be a foreign concept -
this is just a smart pointer concept applied to generic resource. Quite
common stuff, I think.
Of course, your mileages may vary.
> On the rare occasions that you need something like this,
> emulating it with smart pointers is usually good enough. And if it
> isn't, then it's not that hard to write it in a non-generic way. There
> aren't as many problems as writing a smart pointer. For example, you
> don't need to deal with the different operator overloads.
Yes, that's true. And this is also why I think it would be a good idea
to have it handy without the need to reinvent the wheel every time.
-- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/