make shared_ptr not use delete

Question

in my code i would like boost::shared_ptr not to call delete but call ptr->deleteMe() instead.

Also i have a few C styled functions that return a ptr. Can i make it call lib_freeXYZ(ptr); instead of trying to delete?

Topsyturvy

Answer 1

Or how about using the stl to provide the wrapper functor - Doug T. description but without the custom caller.

boost::shared_ptr<T> ptr( new T, std::mem_fun_ref(&T::deleteMe) );
boost::shared_ptr<S> ptr( new S, std::ptr_fun(lib_freeXYZ) );

Toy

I actually prefer this, more elegant. – Drive

I needed some clarifications so I added another question: #27963478. Thanks! – Bloomers

Answer 2

You can give the shared_ptr template a custom deleter function which has the signature

  void Deleter( T* ptr);

for a boost::shared_ptr

So for Deleter you would do

  boost::shared_ptr<T> ptrToT( new T, Deleter );

then in the body of Deleter:

   void Deleter( T* ptr);
   {
        ptr->deleteMe();
        // And make sure YOU ACTUALLY DELETE (or do whatever else you need to
        // do to release the resource)
        delete ptr;
   }

For your specific case when you need something simple (like ptr->deleteMe) see Greg's solution, its very nice.

Drive

i had a similar case where i had to prevent shared_ptr to call delete - it was because the object was allocated statically. may be interesting: #363953 – Ryals

It may be necessary to make sure ptr != 0 before dereferencing it in the deleter. At least I have found that to be the case using std::tr1::shared_ptr on gcc 4.4.5. – Trysail

The additional call to delete ptr is a bit confusing here -- it's like you want to delete the object twice (first with ptr->deleteMe()). I think normally you would use a deleter because you want to do something instead of delete ptr, not in addition to. – Trysail

You have an extra semicolon in the "body of Deleter" section of code. (void Deleter( T* ptr); <-- here ) – Poesy

Answer 3

Doug T. answered your question nicely. I'll tell you about intrusive_ptr. Maybe you can use it in your project too.

If you have some C library that has already reference counting, but you have to manually call those functions, you can use boost::intrusive_ptr too, and provide proper definitions for its add_ref and release functions. intrusive_ptr will find and call them. They are responsible to increment the reference count and decrement it, freeing the resource when necassary:

void intrusive_ptr_add_ref(foo *f) {
    lib_add_ref(f);
}

void intrusive_ptr_release(foo *f) {
    if(lib_dec_ref(f) == 0) 
        lib_free(f);
}

Then you can just create objects from raw pointers of type foo*. intrusive_ptr will call your functions when its copied/destructed:

intrusive_ptr<foo> f(lib_alloc());

// can wrap raw pointers too, which already may be referenced somewhere else
foo *p = get_foo_from_somewhere();
function_taking_intrusive_ptr(p);

Ryals

Answer 4

For the C-style data, do as @Doug. T suggested.

For your class, why not do cleanup in a destructor? Even if this is including deleteMe() in the destructor.

Pavilion

Perhaps there are some boundary issues? calling delete in a different module could be bad, especially if it is using a different crt instance. – Toy

Indeed. In that case, an overloaded delete operator? – Pavilion

Kris - why is Doug answer preferred over Greg answer? Personally, I like the syntax in Greg's answer (especially because I'm dealing with a C library that has a free function for the pointer it returns). But I have no idea about the technical merits or differences. – Intercept

@noloader -- I would prefer Greg's. This one was posted before he created the answer though... – Pavilion