[Adonthell-devel] Python callbacks status (as well as mine ;))

[Alexandre Courbot]

Hi guys,

I know I'm really a bitch for not having finished this stuff, but at least 
I've spent this afternoon on it. Here is the status:

I realized that our way to handle Python in C++ code could be mostly rethought 
to be improved. As you said Kai, using the SWIG runtime lib for our instance 
passing is a great idea. It has one drawback on the performance side however: 
SWIG_TypeQuery is awfully slow when there is plenty of types, as the types 
are recorded in a linked list and the function compare the strings for all 
the types. So later we'll have to either use our own types cache, either 
submit the SWIG guys a patch so handle the types in a nice hash table (don't 
think they will complain).

As for the callback technique. C++ callbacks are templatized as you know, 
which makes them a very nice mechanism. Python callbacks are templatized as 
well on the C++ side - and they inherit from their C++ callback equivalent. 
The only difference is that at constructor time the C++ callback function is 
set to an hardcoded Python template method which runs the Python function 
with the passed arguments. That way, you can transparently give Python 
callbacks to the input listener for instance - as they are C++ callbacks in 
the base, they will be called correctly, and it doesn't even need a the 
calling function to be virtual! Nice trick, uh? ^_^

We'll be loosing something however: all the callbacks will have to be handled 
by reference. Before this they could be handled by value, which was 
convenient. But in their new form, this is no longer possible, because the 
Python callbacks have additional datum and a virtual destructor to Py_DECREF 
what's needed. So if we pass the callbacks by value, these two bits won't be 
copied of course. I'm a bit pissed about this, but it's not that serious I 
think. I you have a workaround, I'm fine with it.

On the cool things side, the ennoying class-name string needed for 
pass_instance that broke some flexibility before is not a problem anymore. 
This was something mandatory, as we do templatized calls to pass_instance - 
so how can we have a string of the type at this level? I've posted the 
question to comp.lang.c++ and the reply was to generate some specializd 
template functions of this form (exemple for input::event):

template<> inline
const char* get_swig_type_name<input::event *>() { return "input::event *"; }

That way, with just a call to this function, you can get a string that is 
passable to pass_instance, deducted from the context (yes, SWIG now accepts 
this nicer form instead of _p_namespace__class). This will require these 
functions to be defined for every of our classes, but this is doable with a 
single #define. It will only contraint our class definitions a little bit.

So far, so good. I'm not finished yet with that stuff, but it's coming slowly 
and nicely. I'm a bit busy with all the university work, so I don't have much 
time for now. Comments welcome, especially if you know of ways to improve it!

Alex.
-- 
http://www.gnurou.org