On Wed, Jul 30, 2014 at 2:23 AM, Dominique Devienne <ddevienne@gmail.com> wrote:
On Wed, Jul 30, 2014 at 5:32 AM, Chris Cleeland <chris.cleeland@gmail.com> 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


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.