Re: Transfer functionality for shared_ptr
In article <qqmabqoaqc3.fsf@hafnium.numerica.us>,
dgsteffen@numerica.us (Dave Steffen) wrote:
Oddly enough, this came up over here yesterday...
"Nevin :-] Liber" <nevin@eviloverlord.com> writes:
In article <13gvk7441t5baf0@corp.supernews.com>,
alfps@start.no ("Alf P. Steinbach") wrote:
If you have a shared_ptr, perhaps with a custom deleter of unknown type,
what extra functionality is required to then transfer that shared_ptr's
raw pointer and deleter to some other smart pointer?
[...]
If you want to transfer it to something that is not a shared_ptr, this
seems like a bad idea. After all, shared_ptr is maintaining its own
class invariants (such as the ref count across all instances pointing to
an object). If you let any arbitrary class or function muck with it,
they really aren't invariants anymore.
[...]
I suppose there might be a use for a shared_ptr::release() when
use_count() == 1. Do you have something in mind?
Our use case is this: we have a chunk of code that stores shared
pointers in a queue. We now pop these shared pointers off the queue
in function A and pass them into a 3rd party library that offers a
very C-ish interface; we send in void*'s (argh). Later, in function
B, we get the void*'s back and can call delete on them.
The problem is that when we pop the shared pointers off the queue in
function A, they go out of scope at the end of the function call and
delete what they hold.
Now, we know for an absolute fact that in function A use_count() ==
1. We can, of course, copy the underlying information out and work
with that, but that seems wasteful. We'd like to get a pointer to
the data out of the shared pointer and relieve the shared pointer of
the responsibility for cleaning it up.
... that is, more-or-less exactly what was described.
The solution we're pursuing right now is to change what we store in
the queue (e.g. don't store smart pointers). Arguably we shouldn't
be using them anyway, in this case, but going back to raw pointers
instead really goes against the grain. :-)
For C++0X, and unique (sole) ownership patterns such as you describe, my
recommendation is to use std::unique_ptr:
void chunk()
{
std::queue<std::unique_ptr<P>> q;
q.push(std::unique_ptr<P>(new P));
...
}
void A(std::queue<std::unique_ptr<P>>& q)
{
third_party_put(q.front().release());
q.pop();
}
void B()
{
std::unique_ptr<P> ptr(static_cast<P*>(third_party_get()));
...
}
unique_ptr is a non-copyable, move-only smart pointer which can safely
be put into C++0X standard containers. Its semantics are similar to
auto_ptr except that one can not move from lvalues with copy syntax.
The overhead is identical to auto_ptr.
I believe its use in the pattern above will be simpler, safer and more
efficient than special casing shared_ptr when the use count is 1.
Making a special case of shared_ptr when the use count is 1 is something
that will need to be checked at run time and can possibly fail. One can
think of unique_ptr as a shared_ptr where it is known (and enforced) at
compile time that the use count is no greater than 1. If you accidently
code a situation where the use count threatens to grow above 1, the
compiler will let you know.
I realize this is not a solution you can code today. However in
suggesting modifications to shared_ptr, we are implicitly talking about
C++0X anyway.
-Howard
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]