shared_pointer for C-allocated object?
I have some legacy C code that returns a pointer: fftw_plan fftw_create_plan(int n, fftw_direction dir, int flags); where fftw_plan is a pointer. Can I use shared_pointer to wrap it? I guess the issue is that eventually delete will be called on this pointer, but it wasn't allocated with new. Is this a problem?
-----Original Message----- On Behalf Of Neal D. Becker Sent: Monday, February 02, 2004 7:58 AM I have some legacy C code that returns a pointer:
fftw_plan fftw_create_plan(int n, fftw_direction dir, int flags);
where fftw_plan is a pointer.
Can I use shared_pointer to wrap it? I guess the issue is that eventually delete will be called on this pointer, but it wasn't allocated with new. Is this a problem?
I think you could just use a custom deleter that calls free: shared_ptr<fftw_plan> p(make_pointer(), &::free);
Neal D. Becker wrote:
I have some legacy C code that returns a pointer:
fftw_plan fftw_create_plan(int n, fftw_direction dir, int flags);
where fftw_plan is a pointer.
Can I use shared_pointer to wrap it? I guess the issue is that eventually delete will be called on this pointer, but it wasn't allocated with new. Is this a problem?
What do you need to call when you are finished with fftw_plan?
"Neal D. Becker" <nbecker@hns.com> writes:
I have some legacy C code that returns a pointer:
fftw_plan fftw_create_plan(int n, fftw_direction dir, int flags);
where fftw_plan is a pointer.
Can I use shared_pointer to wrap it? I guess the issue is that eventually delete will be called on this pointer, but it wasn't allocated with new. Is this a problem?
Custom deleters are your friend. See the shared_ptr docs for more info. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 02/02/2004 10:32 AM, Javier Estrada wrote:
Custom deleters are your friend.
How about custom allocators AND deleters?
The reason I say this is because it would be useful to have a policy-based approach when interacting with APIs that do the allocation/destruction. But instead of placing two pointers(1 for allocator + 1 for deleter) why not use a virtual function table for both? In other words, instead of just having a sp_counted_base::dispose + destruct, why not add an virtual allocate? Then, instead of passing the deleter as an argument to the CTOR, a sp_counted_base* would be passed and the user would define a subclass of sp_counted_base which used whatever allocator and destructor desired. This would save some memory and wouldn't (I don't think) constrain the user much since I don't think the user would want a separate destructor and allocator for each instance of the shared object.
Aaah. That's what I intended to articulate, but not in such an elaborate way as you ;-)
On 02/02/2004 07:44 PM, Javier Estrada wrote:
Aaah. That's what I intended to articulate, but not in such an elaborate way as you ;-) Great. Now, have a look at:
http://groups.yahoo.com/group/boost/files/shared_cyclic_ptr/ auto_new.hpp //latest evolution of auto_new auto_smart_ptr.zip //example used in move_ptr post and see if you can think of a way to achieve this. I'll be trying also, but "two heads are better than one" and maybe Jonathan Turkanis would have some ideas too on how to merge the ideas with those for move_ptr.
Larry Evans <cppljevans@cox-internet.com> writes:
On 02/02/2004 10:32 AM, Javier Estrada wrote:
Custom deleters are your friend. How about custom allocators AND deleters? The reason I say this is because it would be useful to have a policy-based approach when interacting with APIs that do the allocation/destruction. But instead of placing two pointers(1 for allocator + 1 for deleter) why not use a virtual function table for both? In other words, instead of just having a sp_counted_base::dispose + destruct, why not add an virtual allocate? Then, instead of passing the deleter as an argument to the CTOR, a sp_counted_base* would be passed and the user would define a subclass of sp_counted_base which used whatever allocator and destructor desired. This would save some memory and wouldn't (I don't think) constrain the user much since I don't think the user would want a separate destructor and allocator for each instance of the shared object.
What's the point of storing an allocator? Once the storage for the deleter is allocated, a shared_ptr never needs to allocate again. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 02/02/2004 08:51 PM, David Abrahams wrote:
Larry Evans <cppljevans@cox-internet.com> writes:
On 02/02/2004 10:32 AM, Javier Estrada wrote:
How about custom allocators AND deleters? [snip]
But instead of placing two pointers(1 for allocator + 1 for deleter) why not use a virtual function table for both? In other words, instead of [snip]
What's the point of storing an allocator? Once the storage for the deleter is allocated, a shared_ptr never needs to allocate again.
Good point. I can't think of a reason. However, the idea of using a virtual function table instead of a deleter may have some future advantages. If something other than just deletion needs to be done, then making this other function an entry in the vft would save some space. For example, in the auto_new class, only a vft ptr is needed instead of both a deleter and pointer to the most derived class. I.e. sp_counted_base_impl<P,D>::ptr sp_counted_base_impl<P,D>::del Maybe Javier knows more.
On 02/02/2004 09:23 PM, Larry Evans wrote:
On 02/02/2004 08:51 PM, David Abrahams wrote:
Larry Evans <cppljevans@cox-internet.com> writes:
On 02/02/2004 10:32 AM, Javier Estrada wrote:
How about custom allocators AND deleters?
[snip]
But instead of placing two pointers(1 for allocator + 1 for deleter) why not use a virtual function table for both? In other words, instead of
[snip]
What's the point of storing an allocator? Once the storage for the deleter is allocated, a shared_ptr never needs to allocate again.
Good point. I can't think of a reason. However, the idea of using [snip] I thought I came up with a reason: The auto_new mentioned in the previous post allocates a new Referent along with the Overhead to save the extra allocation of shared_ptr for the reference counts. This was an alternative implementation of Brouchard's idea about saving the extra allocation with shifted_ptr:
http://article.gmane.org/gmane.comp.lib.boost.devel/31643/match=shifted+ptr I was hoping that the vtable could contain a virtual CTOR; however, since virtuals cannot be templated, this is not possible. Consequently, at least one advantage of shared_ptr cannot be achieved with auto_new. That advantage, mentioned "eons" ago, was, IIRC, that the referent might be allocated from thread local storage, or some special allocator that had to have a corresponding deallocator which of course, restored the memory to the same thread local storage. Any ideas for solutions to this problem, i.e. how to save the extra allocation and function pointer; yet, still solve the need for matching allocate/delete methods?
David Abrahams wrote:
"Neal D. Becker" <nbecker@hns.com> writes:
I have some legacy C code that returns a pointer:
fftw_plan fftw_create_plan(int n, fftw_direction dir, int flags);
where fftw_plan is a pointer.
Can I use shared_pointer to wrap it? I guess the issue is that eventually delete will be called on this pointer, but it wasn't allocated with new. Is this a problem?
Custom deleters are your friend. See the shared_ptr docs for more info.
Thanks! Just what I needed: boost::shared_ptr<fftw_plan_struct> plan; plan (fftw_create_plan (_size, dir, flags), &fftw_destroy_plan)
participants (6)
-
Brock Peabody -
David Abrahams -
Javier Estrada -
Larry Evans -
Neal D. Becker -
Peter Dimov