RE: [Boost-users] Scoped_ptr + deleter
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Caleb Epstein Sent: Monday, May 23, 2005 2:32 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Scoped_ptr + deleter
Why doesn't scoped_ptr have an additional template
On 5/23/05, Sohail Somani <s.somani@fincad.com> wrote: parameter to accept
a deleter?
Because that would make it larger than sizeof (T*). I believe the general consensus on this is to use shared_ptr or perhaps the upcoming policy_ptr.
For educational purposes, why is this important?
On 5/23/05, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- Because that would make it larger than sizeof (T*). I believe the general consensus on this is to use shared_ptr or perhaps the upcoming policy_ptr.
For educational purposes, why is this important?
I'm not certain, but I would guess that overhead is the reason. Perhaps someone more closely involved in the implementation (Peter?) would care to comment. The "bells and whistles" all went into shared_ptr. Unless you're trying to eke out every last CPU cycle from your code, using shared_ptr as a scoped_ptr w/deleter is an eminently reasonable design choice -- Caleb Epstein caleb dot epstein at gmail dot com
On May 23, 2005, at 6:13 PM, Caleb Epstein wrote:
On 5/23/05, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- Because that would make it larger than sizeof (T*). I believe the general consensus on this is to use shared_ptr or perhaps the upcoming policy_ptr.
For educational purposes, why is this important?
I'm not certain, but I would guess that overhead is the reason. Perhaps someone more closely involved in the implementation (Peter?) would care to comment.
The "bells and whistles" all went into shared_ptr. Unless you're trying to eke out every last CPU cycle from your code, using shared_ptr as a scoped_ptr w/deleter is an eminently reasonable design choice
A customized deleter does not have to occupy space if it has no data members. boost::compressed_pair can easily be used to optimize away space for an empty member, e.g.: compressed_pair<T*, D> ptr_; // space for D optimized away if D is empty class For my money, the best smart pointer in this domain (minimum overhead, custom deleter) today is static_move_ptr: http://www.kangaroologic.com/move_ptr/ I hope that C++0X will have a cleaner version of this by the name of std::unique_ptr, but that is far from certain. -Howard
Caleb Epstein wrote:
I'm not certain, but I would guess that overhead is the reason. Perhaps someone more closely involved in the implementation (Peter?) would care to comment.
As a user of scoped_ptr and scoped_array, I expressed a strong opinion that its memory usage remain as is, and some Boost developers agreed. If you have a way to maintain the current behavior (speed and memory footprint) as a default, you are welcome to add functionality. Otherwise, it becomes useless to me. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
On 5/24/05, Richard Hadsell <hadsell@blueskystudios.com> wrote:
As a user of scoped_ptr and scoped_array, I expressed a strong opinion that its memory usage remain as is, and some Boost developers agreed. If you have a way to maintain the current behavior (speed and memory footprint) as a default, you are welcome to add functionality. Otherwise, it becomes useless to me.
I'm not suggesting any changes be made to scoped_ptr, and from the replies of others it sounds like move_ptr is way forward on this. -- Caleb Epstein caleb dot epstein at gmail dot com
participants (2)
-
Caleb Epstein -
Howard Hinnant -
Richard Hadsell -
Sohail Somani