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 23:29:18

On Tue, Jul 29, 2014 at 9:01 PM, Michael Powell <mwpowellhtx_at_[hidden]>
wrote:

> On Tue, Jul 29, 2014 at 11:30 AM, Michael Powell <mwpowellhtx_at_[hidden]>
> wrote:
> > On Tue, Jul 29, 2014 at 11:25 AM, Chris Cleeland
> > <chris.cleeland_at_[hidden]> wrote:
> >>
> >>
> >>
> >> On Tue, Jul 29, 2014 at 11:02 AM, Michael Powell <mwpowellhtx_at_[hidden]
> >
> >> 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