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

[Kai Sterker]

On Sun, 18 May 2003 18:02:03 +0200 Alexandre Courbot wrote:

> 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. 

Probably not as slow as one might think. In SWIG_TypeCheck, the recently
used list element is moved to the beginning of the list. That means, the
more often an object is used, the more towards the front of the list it
will be. I agree that this is not as efficient as a hash table, but not
as bad as a normal list either.


> 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).

Probably not.
 

> 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? ^_^

Yeah, sounds cool. Although I'll have to see it before I really
understand what is going on ;).

 
> 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.

Maybe I could think of something when I see the code.
 

> On the cool things side, the ennoying class-name string needed for 
> pass_instance that broke some flexibility before is not a problem
> anymore.

That's cool.


> 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!

Hm. Not really. After all, you have been working on that stuff for some
time now, so I don't have as good an understanding of these matters as
you have. This may change once I see stuff, but I doubt it :).
Everything sounds really cool and promising so far!

Kai