On Tue, Jul 29, 2014 at 11:02 AM, Michael Powell <mwpowellhtx@gmail.com> 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.

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.