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

On Tue, Jul 29, 2014 at 9:49 AM, Chris Cleeland wrote:

On Mon, Jul 28, 2014 at 11:46 PM, Edward Diener wrote:

...

On 7/28/2014 11:22 PM, Chris Cleeland wrote:

...

I'm resurrecting this topic:

Echoing what Edward suggested...

...

...

https://groups.google.com/forum/#!searchin/boost-list/shared_ptr$20void*/boo...

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.

Along the lines what Edward suggested, if the "origin" of the pointer is your thread, then somehow you need to make sure that memory lives beyond the lifetime of the external, in this case C, API, context and all, etc, etc. No room for debate in that topic; it is what it is, deal with it in a responsible manner.

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.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users