|
|
Hello Stefan,
thank you for the quick response.
I'm not quite
sure I would embedd these vtbls into the objects you are wrapping, as that
is a bit invasive.
Uhm, I am not sure if this is what I meant to do. I intended to take
the route suggested by the std. Python extending tutorial: http://docs.python.org/ext/using-cobjects.html
So I want to put the whole table of API function ptrs in just one of
these Python-API CObjects, to get the addresses across the C++/Python/C
borders. This would leave the C++ objects which I intend to access with
my API untouched. They would even be oblivious to the existence of the
C-API, as the functions will only access the objects using their normal
public interface.
But, yes, the CObject itself would be wrapped in order to get it out to
python. I thought of something like:
static void* call_table[MY_API_PTRS];
.... put function pointers in table ...
object get_c_api() {
return object(handle<>(PyCObject_FromVoidPtr((void*)call_table,
NULL)));
}
Then I would export 'get_c_api' with the normal boost::python
facilities. In the plain C part, I would call get_c_api via python,
extract the void* ptr from the PyCObject* and cast it into the array of
function pointers, whose prototypes are known thanks to a header file
that describes the fixed layout of call_table.
Instead, you may create a dictionary that maps python
type objects to the structures holding your vtbl and provide a simple
lookup mechanism that queries the PyTypeObject pointer from a given python
object and look up the C vtbl with that.
Ok, this would be a nice way to associate the functions with the
corresponding objects. But still I need to use PyCObject_FromVoidPtr or
something equivalent to be able to put the opaque C pointers, or the
ptr to the vtable, into a python dict, do I? But don't worry, I will
need only one vtable with a static structure for my few API functions.
So it boils down to the problem of getting a single address safely from
the C++ part to the C part. Each function will check with
extract<expected_class>(...).check() to make sure it is called
with the C++ object type it is intended for.
Hope it still makes sense.
Regards,
Thomas.
|
_______________________________________________
C++-sig mailing list
C++-sig@xxxxxxxxxx
http://mail.python.org/mailman/listinfo/c++-sig
|
|