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

On Tue, Jul 29, 2014 at 9:01 PM, Michael Powell wrote:

On Tue, Jul 29, 2014 at 11:30 AM, Michael Powell wrote:

...

On Tue, Jul 29, 2014 at 11:25 AM, Chris Cleeland wrote:

...

On Tue, Jul 29, 2014 at 11:02 AM, Michael Powell

...

wrote:

...

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.

The C API is not managing the life time of the instance allocated to the shared_ptr. When the shared_ptr<> falls out of scope, all bets are off. Plain and simple.

Not to beat a dead horse. But here's an apt analogy: I could be wrong, but you are dividing by zero and not expecting a div by zero exception (or worse) to occur.

That's actually a completely incorrect analogy. We are obviously having a disconnect between the explanation I'm giving for what I'm attempting to deal with and your understanding of it. I could tell earlier today that this had occurred, but with a schedule deadline looming I didn't think it was worth wrestling with the so-called pig (to use another analogy that may or may not be correct). You seem to think that I want to abdicate responsibility for managing the lifecycle, and that's completely the OPPOSITE of what I want to do. The whole reason I raised the question in the first place is because I recognize and WANT to deal with lifecycle responsibilities. Ideally, the container behind the C API would participate in bumping the reference count on my pointer, but that's not realistic because (a) it's not my API--it's from a vendor and not open source and (b) it's C and participating in shared_ptr<> refcount semantics in C does not look trivial. So, I am left with figuring out a different way--some object on the C++ side whose lifecycle matches that of the container behind the C API, either by coincidence or by design. Hopefully I've done a better job explaining this time. -- Chris Cleeland