On Tue, Jul 29, 2014 at 11:30 AM, Michael Powell
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.
Yes, I agree that I'm responsible. If I didn't know or think that, then I wouldn't have asked the question in the first place.
I'm not debating whether or not I *should* be responsible--I'm asking a question related to best-practices for fulfilling that responsibility in the absence of the ability to use a shared pointer and its concomitant semantics everywhere the pointer is held. While I appreciate your response and Edward's response, neither answers the question asked.
Thanks to Dominique for sharing a technique. I hadn't thought of using a heap-allocated shared pointer instance as the proxy. I had thought of stashing another shared pointer instance in the C++ object that manages the callback registration itself, but wasn't sure if that lifecycle would coincide exactly. The heap is probably the better of the two since it dissociates all lifecycles.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users