Re: [Boost-users] revisiting casting a boost::shared_ptr to void*

Subject: Re: [Boost-users] revisiting casting a boost::shared_ptr to void*
From: Chris Cleeland (chris.cleeland_at_[hidden])
Date: 2014-07-29 10:49:53

On Mon, Jul 28, 2014 at 11:46 PM, Edward Diener <eldiener_at_[hidden]>
wrote:

> On 7/28/2014 11:22 PM, Chris Cleeland wrote:
>
>> I'm resurrecting this topic:
>>
>> https://groups.google.com/forum/#!searchin/boost-list/
>> shared_ptr$20void*/boost-list/QE_VCTen1YQ/styxqKB2wbQJ
>>
>> because there is an unaddressed issue in it that I'm about to run into:
>>
>> "... beware the pointee may be deleted if the last copy of the shared
>> pointer
>> goes out of scope, as the raw pointer won't have incremented the
>> reference count."
>>
>> I cannot be the first person to run into this--a common issue when
>> crossing an API boundary.  Has anyone come up with a good, safe solution
>> wherein the reference count gets properly incremented?
>>
>
> The issue has nothing to do with casting a shared pointer to a void *.

Yes, I agree.  However, the issue was raised in that thread so I thought it
was sensible to retain the thread title.

> If you need to pass a shared pointer as any raw pointer, if the last use
> of the shared pointer ends the encapsulated raw pointer is deleted. If
> someone is still holding on to that raw pointer after that happens and
> tries to use it you will almost cetainly get a crash.
>

Yes, I know that as well.  That is the issue highlighted in the quote and
which I independently concluded.

> There is no good solution to this other than not using a shared pointer in
> the first place in your particular situation. Think about your problem. You
> want to be able to share this pointer among other objects but then you want
> one or more objects to share this pointer as a raw pointer. Given what a
> shared pointer is, doing this just does not make sense.
>

I will have to disagree with your assessment that using a shared pointer
makes no sense. In my particular situation, the shared pointer is used in a
C++ application, and it's a poster child for shared pointers.  This
mismatch occurs in a couple of places where I have to call into a C API and
register a callback, providing a "context" or "cookie" or "Asynchronous
Completion Token" to the registration.  That context gets held in some
container owned by the C API innards and, when the C API invokes the
callback, it passes that context as an argument to the callback function.

Ideally, the context would be the pointer to the same object held by the
shared pointer--because that is the exact context I need in order to take
action within the callback function.

I suppose I could use some sort of container that maps the context back to
the shared pointer, but that seems wasteful and silly when the pointer
itself is already there.

> If you are just passing your shared pointer to a function as a raw T * you
> have no problem if the function is a synchronous function which does not
> hold on to the raw pointer past the functions exit. This is because the
> shared pointer from which the raw pointer is passed will still be in scope
> when your function returns.
>

Yes, that is precisely the problem. Since the C API cannot participate in
the shared pointer semantics directly, I will need some sort of proxy
shared pointer.  My question centers on the fact that I cannot be the first
person in the world who is using shared pointer very effectively in C++
code and needs to interact efficiently with a callback-based C API in which
the pointer would be the ideal context.