shared_ptr to stack-allocated object
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); } What's the normal practice here? Thanks, Jason
On Thu, Dec 4, 2008 at 4:03 PM, Jason Cipriani
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); }
What's the normal practice here?
I'm not sure what's normal, but if your function isn't going to take ownership of the object you're passing (which in this case it can't do anyway since the object is allocated on the stack), it should take Object &, not shared_ptr<Object>. Even if it must take shared_ptr<Object> for some reason, it's better to take shared_ptr<Object> const &, to avoid the refcount increment/decrement (in general, I can't think of a reason to pass shared_ptr by value.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Thu, Dec 4, 2008 at 7:22 PM, Emil Dotchevski
On Thu, Dec 4, 2008 at 4:03 PM, 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); }
What's the normal practice here?
I'm not sure what's normal, but if your function isn't going to take ownership of the object you're passing (which in this case it can't do anyway since the object is allocated on the stack), it should take Object &, not shared_ptr<Object>.
Even if it must take shared_ptr<Object> for some reason, it's better to take shared_ptr<Object> const &, to avoid the refcount increment/decrement (in general, I can't think of a reason to pass shared_ptr by value.)
Thanks for the tip. In this case, function needs to take a shared_ptr as it is used in other contexts with shared_ptr's, it's only sometimes used with objects from the stack.
On Thu, Dec 4, 2008 at 4:42 PM, Jason Cipriani
Thanks for the tip. In this case, function needs to take a shared_ptr as it is used in other contexts with shared_ptr's, it's only sometimes used with objects from the stack.
Yes, so you're right, this seems to be a classical use case for a null_deleter, just pass the shared_ptr by const &. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 04 December 2008 19:42 pm, Jason Cipriani wrote:
Thanks for the tip. In this case, function needs to take a shared_ptr as it is used in other contexts with shared_ptr's, it's only sometimes used with objects from the stack.
There is always shared_ptr::get() and shared_ptr::operator*() to pass shared_ptr-owned objects to functions taking raw pointers/references. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJOT005vihyNWuA4URAmunAJ9OFXY2p7OK1IbqvPE/qvTXVFF7JACbBHA+ 02Q+b0bQU3Fxe6fsRvkclX8= =I0a3 -----END PGP SIGNATURE-----
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
participants (4)
-
Emil Dotchevski
-
Frank Mori Hess
-
Jason Cipriani
-
Jeff Flinn