Hi Alex,
(I'm a little unclear what it means to represent "void*" as an array (array
of what?),
exactly. A PyCObject is useless by design (but lacking in PyPy AFAICT, other
than in cpyext, which use would be slow), as is an array of void. It is the
best equivalent I could come up with ...
I figured that the only thing I ever wanted from a PyCObject, is to get the
C-side address. That is why cppyy.addressof() does provide that for arrays
of void now.
Beyond that, PyCObject's serve to go from C -> Python -> C, with no work in
Python. This void array can do that. The only part missing is an as_cobject
(one that returns a cpyext-based, CPython PyCObject), to communicate with
other extension libraries that use the CPython C-API. Such a function is
needed for all other C++ instances also, so I'll add that (PyROOT has it to
allow integration with PyQt, for example).
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..
Is unlikely, as 'nullptr' is a C++11 keyword. I've been thinking of putting
it under 'cppyy' rather than 'cppyy.gbl', but the latter seemed to make more
sense (it's not a module feature, but a C++ feature).
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).
Okay, I understand better now.
Obviously, in pypy objects don't have
static addresses, so we can't just use a pointer to the Python object
That is solvable (cppyy can bind functions that take/provide PyObject* as it
simply hands over the work to cpyext). See for example test_crossing.py in
pypy/module/cppyy/test. The larger problem would be that any randomly given
python object does not have a guaranteed layout.
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..
Alex Pyattaev did this (is in the pypy-dev mail archives, somewhere around
early Summer 2012).
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..
Let me know if you see anything missing. "void*" is an interesting puzzle,
without many people (that I know of) interested in it.
The much bigger pain that we have, is the use of "char*" where the intended
usage is "byte*". (And I don't actually have a solution for that.)
Best regards,
Wim
--
wlavrij...@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
