RE: [boost] Generalizing the shared_ptr
As of version 3.1 boost shared_ptr has a constructor that takes a user-defined deleter: template<class Y, class D> shared_ptr(Y * p, D d): px(p), pn(p, d) { detail::sp_enable_shared_from_this(p, p, pn); } Maybe I missed something, but what is your library adding to this? m -----Original Message----- From: Maciej Sobczak [mailto:prog@msobczak.com] Sent: Wednesday, July 07, 2004 4:18 PM To: boost@lists.boost.org Subject: [boost] Generalizing the shared_ptr << File: scoped_handle.h >> << File: test.cc >> << File: ATT57508.txt >> Hi, (not sure if it was discussed before) I've found Boost smart pointers inflexible in the sense that they operate only on pointers. It would be a good idea to generalize their interface to handle just about anything that requires special care when destroying. HANDLE (on Windows), FILE*, file descriptors (on Unix), third-party API handles, etc. come to mind. I wrote a very simple class (see attachments), scoped_handle, which encapsulates the resource (whatever it is) and its disposing (whatever that means). The techniques used are similar to those used in implementation of boost::shared_ptr. The example file shows how the class can be used to guard resources allocated by operator new, fopen, open, etc. Is it possible to achieve the same results with the existing Boost libraries? If not, is there any interest in developing this kind of class? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Max Khesin wrote:
As of version 3.1 boost shared_ptr has a constructor that takes a user-defined deleter: template<class Y, class D> shared_ptr(Y * p, D d): px(p), pn(p, d) { detail::sp_enable_shared_from_this(p, p, pn); } 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. Another possible example it to store sockets: scoped_handle<int> sock(::socket(AF_INET, SOCK_STREAM, 0), ::close); Something similar has been mentioned before, for example see: http://lists.boost.org/MailArchives/boost/msg49290.php 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 great. 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. Daniel
Hi, 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 great.
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/
Maciej Sobczak wrote:
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.
Um, all the machinery is in detail::shared_count? Why should it be impossible to reuse?
On 07/12/2004 03:42 PM, Maciej Sobczak wrote: [snip]
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.
[snip]
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 great.
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.
[snip] I've been thinking about generalizing it for reflection. For example, for every type which is to be "reflected", the instances of that type would be stored in a reflector handle. The "reflection" (i.e. information on all the reflector handles) of a type, T, would be stored in reflection<T>. This information is similar to that used for garbage collection of cycles; hence, I think the code in: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/mana... could be used.
participants (5)
-
Daniel James -
Larry Evans -
Maciej Sobczak -
Max Khesin -
Peter Dimov