> > 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
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
