Hi, How come scoped_ptr can't work with a special 'deleter' as shared_ptr? Thanks Guy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Guy Peleg a écrit :
Hi,
How come scoped_ptr can't work with a special 'deleter' as shared_ptr?
I was just wondering the same thing. This would be quite convenient for me, where I just want to use RAII without redefining the ressource holding class. I agree that I could just use shared_ptr anyway for this purpose, but scoped_ptr would be documenting my intent more precisely. This would be a good addition to scoped_ptr, IMO. -- Loïc
On 03/02/06, Loïc Joly <loic.joly@reportive.com> wrote:
Guy Peleg a écrit :
Hi,
How come scoped_ptr can't work with a special 'deleter' as shared_ptr?
I was just wondering the same thing. This would be quite convenient for me, where I just want to use RAII without redefining the ressource holding class. I agree that I could just use shared_ptr anyway for this purpose, but scoped_ptr would be documenting my intent more precisely.
It's my understanding that scoped_ptr does not allow the custom deleter since shared_ptr does it by keeping a boost::function<> ( or perhaps some other similar utility ) to the deleter, which, if used for scoped_ptr, would make a scoped_ptr larger than a plain pointer ( by about 2 pointers ) and would make the destructor slower ( by about 1 call through a function pointer ), which would be unacceptable for many users of scoped_ptr. In any case, the speed difference between a shared_ptr and some scope pointer that did keep a boost::function<> to a deleter would only be in the allocation of the reference count which, especially with the quick allocator, is usually not that severe. One possibility, however, would be for a deleter_scoped_ptr ( that's not yet written ) to have a second template argument of a functor that would be default-constructed and then called on the pointer as the deleter. That would eliminate the speed and size overhead, but it means much less flexibility in what the deleter can be ( since it must be set at declaration, which means no binders or function pointers, among other things ). ~ Scott McMurray
me22 wrote:
One possibility, however, would be for a deleter_scoped_ptr ( that's not yet written ) to have a second template argument of a functor that would be default-constructed and then called on the pointer as the deleter. That would eliminate the speed and size overhead, but it means much less flexibility in what the deleter can be ( since it must be set at declaration, which means no binders or function pointers, among other things ).
FWIW, I've written a scoped_ptr that does just that. It's available from http://developer.berlios.de/projects/breeze/ No packaged release for now, just a public subversion repository you can download from. You'll find my scoped_ptr in breeze/scoped_ptr.hpp, as breeze::scoped_ptr template < class T, class Pointer = breeze::default_, class Reference = breeze::default_, class Deleter = breeze::default_ > struct breeze::scoped_ptr; It does not offer the same thread-safety guarantees wrt to the deleter as boost::shared_ptr does. As a substitute for boost::scoped_ptr, however it should be safe. The deleter will be called in the same thread as the destructor of the scoped_ptr. HTH, João
participants (4)
-
Guy Peleg -
João Abecasis -
Loïc Joly -
me22