Jason Cipriani wrote:
I'm refactoring parts of an existing application to use shared_ptrs instead of raw pointers. What is the best way to deal with code like this (please note in this situation passing a pointer to a stack-allocated object to function is acceptable and safe):
void function (shared_ptr<Object> ptr) { ... }
void function2 () { Object o; function(&o); // <--- need to change this }
It seems I have two choices, I am not sure which is better, or if there are other common techniques. I can either use a no-op delete function:
void noop (Object *) {}
void function2 () { Object o; function(shared_ptr<Object>(&o, noop)); }
Or I can allocate it on the heap instead of the stack, and let shared_ptr deal with the cleanup (this seems to be the more convenient solution):
void function2 () { shared_ptr<Object> o(new Object); function(o); }
I do not see a need for any pointer usage in the above example code. I see the following signatures for function depending on the inner details of function. void function (const Object& o) // original not to be modified void function ( Object& o) // original to be modified void function ( Object o) // original not to be modified The latter for cheaply copy-able Object's. I've come across lots of legacy C++ code that egregiously over uses the heap when stack variables suffice. Typically from what was actually C code merely made to compile with a C++ compiler. Or by developers coming from languages where all variables are references of some sort. If you do have a need to call 'function' and you have a pointer or shared_ptr call function with a dereferenced pointer: function( *some_raw_or_shared_ptr ); Exceptions to the above would be if 'function' called some other facility requiring the Object's lifetime to outlive function's scope. Or if in fact the Object's existence affects the function's logic, that is you branch based on the pointer being null. Jeff