jitclass cffi pointer

[wrongbad]

Feature request

Similar to how cfunc.cffi generates function pointers for use with cffi
It would be very useful for jitclasses to be transformable to/from cffi void* pointers
This would be especially useful for cffi libraries that take callback func and a void* userdata
The userdata could be a jitclass, offering structured data for free in both the interpreter and "c" context

[wrongbad]

I'm in over my head here.

I see now that there is a note specifically about this "deferred topic" in cfunc.rst

I've found that I can have my jitclass instance "myObject" which contains only an array and pass _box.box_get_dataptr(myObject) to a cffi void*, and then interpret as a carray to read-write it. However this is obviously incorrect because when I come by later to print myObject in the interpreter it segfaults. So I'm apparently not getting the pointer to the backing array data, or the struct I assumed would share the same base address, and instead scribbling on some meta-data the python object needs.

I suppose a completely alternative approach is getting buffer api support for jitclasses and then constructing the object-view independently inside the callback - same as the carray() mechanism which is simple and reliable. I don't know enough about how carray gets compiled, hopefully this approach doesn't require mallocing to construct the "view", where you wouldn't in a pure-c approach. I'm skeptical of this because it looks like python buffers are designed somewhat specifically around the homogenous array use case, with multi-dims and strides and such.

And yet another approach is a pure python mechanism to process a nested class structure, calculating sizes and offsets to make it a view for a single numpy array or bytes object. Then simply piggy-back the working mechanism for arrays to/from void*.

[wrongbad]

Looks like I can't use any of the nice carray() things if I want to avoid mallocs completely (e.g. for a real-time callback). Major oversight on my part.