[pypy-dev] cppyy and callbacks

[Alex Stewart]

>
> Some code is in, on the reflex-support branch (to be merged once it is
> documented): void* is represented as an array (I didn't see a PyCObject or
> PyCapsule outside of cpyext), both for returns and data members. There is
> a special case cppyy.gbl.nullptr (C++11 style), which is a unique object to
> represent NULL.
>

(I'm a little unclear what it means to represent "void*" as an array (array
of what?), but the rest of cppyy seems to be pretty well thought out, so
I'll trust you know what you're doing :) )

Out of curiosity, is there some reason you didn't name that cppyy.gbl.NULL
instead?  It seems to me that "nullptr" could potentially cause namespace
collisions if some library decided to have a function/variable by that
name, whereas "NULL" would be consistent with standard C++ naming..

Passing C++ instances through void* was already supported, and so that
> should
> be fine. There was an issue if the code started out with a void* (e.g. from
> a function call), but that now works as well. (That consistency thing
> again.)


For clarification, the specific use case I'm looking at is
objects/functions that use "void *" as an "opaque pointer to application
data" that the library doesn't want/need to care about (just pass back to
the application sometimes).  In this context, it would be really nice if
there was some easy way to use "void*" to represent a pure Python object as
well (not just C++ instances).  Obviously, in pypy objects don't have
static addresses, so we can't just use a pointer to the Python object, but
I was considering the possibility of taking an index or id() of the object
and just casting it into "void*" form, and then converting it back and
using it to look up objects in a list/dict somewhere..  (Alternately, it
occurs to me now one could define a C++ "proxy" object which could store
that sort of lookup information, and then the address of the proxy could be
stored in the void*, which might be a little more kosher..)

In any case, I wanted to make sure that use case was something that would
be feasible in your plan for how void pointers will ultimately work..

--Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20140123/58f989d4/attachment.html>