Re: [Boost-users] revisiting casting a boost::shared_ptr to void*

On Wed, Jul 30, 2014 at 2:23 AM, Dominique Devienne wrote:

On Wed, Jul 30, 2014 at 5:32 AM, Chris Cleeland 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.