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-30 10:40:24

On Wed, Jul 30, 2014 at 2:23 AM, Dominique Devienne <ddevienne_at_[hidden]>
wrote:

> On Wed, Jul 30, 2014 at 5:32 AM, Chris Cleeland <chris.cleeland_at_[hidden]>
> wrote:
>
>> In my case, the C API is stashing the value of the pointer in a
>> container, and passing that pointer value as an argument to the registered
>> callback function.  That's it.  The C code doesn't *do* anything with the
>> pointer because it treats it as a void*.
>>
>
> Then it's a badly-designed C API I'm afraid...
>

It's a well-documented pattern: http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf

It's been around for years and years in the world of C.  Super common in
the X Toolkit and many other GUi frameworks.

The void* is just a value.  It's convenient that it can hold a pointer,
because then, rather than being a number that is an index in some kind of
user container, it's can be an address.

>
> SQLite introduced a bunch of _v2 APIs (e.g. [1]) specifically to add a void(*xDestroy)(void*)
> argument to some of its functions taking a void* user-data argument, to
> address lifetime issues. That's C programming done right, which interfaces
> just fine with C++ and shared_ptr and co.
>

Only if SQLite is doing something active with the void*.

>
> The fact that one programs and designs APIs in C doesn't mean one
> shouldn't care about lifetimes. My $0.02. --DD
>
> [1] http://www.sqlite.org/capi3ref.html#sqlite3_create_module
>

It's really a matter of ownership, isn't it?  Neither language supports the
concept of shared ownership (save C++11 now with std::shared_ptr<>).

That triggered an interesting thought.  I've been thinking of this all
along as wanting the C API's holding of the pointer value for its ACT as
counting as one of the reference counts. But really, it's just a value, and
it's up to the callback function to decide if that value is valid.  In that
sense, it's almost like I want it to have the semantics of a weak_ptr<> so
that the callback function can check the validity of the ACT before moving
on. Interesting.