Re: [pygccxml-development] Implicit virtual functions in derived classes

[Julian S. <jul...@rs...>]

Julian Scheid wrote:
> Due to the way funcs.update works (?) this will put A.foo into "funcs" 
> instead of B.foo when generating the wrapper for C. This in turn will 
> lead to the following wrapper code for class C to be generated:

To elaborate, the order in which "A::foo" and "B::foo" are traversed in 
the "for f in funcs" loop depends on details of Python's Hashset 
implementation - they might or might not be traversed in the right order 
depending on how they are hashed. The right order being B::foo first and 
then A::foo second so that B::foo is added and A::foo is later rejected 
when tested with is_same_function.

I haven't actually checked how things turn out for my hypothetical 
example from the previous mail, if you can't reproduce it using that 
example try using different class names (swapping A and B so that A is 
derived from B and C is derived from A should do the trick).

I found that this problem can be avoided simply by using a list instead 
of a set for "funcs" and extend'ing it instead of update'ing it. While 
possibly a tad less efficient, this seems to work fine and guarantees 
that later on the right superclass is used.

There is another intricacy. In the previous example (with classes A, B 
and C) consider that mb.class_("B").member_functions("foo").exclude() 
has been called. Now, if you use "not ignored and exportable" in the 
query as I suggested originally, what happens is that only A.foo ends up 
in "funcs" and the generated code for C_wrapper will incorrectly 
dispatch to A::foo. What works better is either to disregard whether or 
not a function is marked as ignore (downside being that exclude won't 
affect derived classes) or, better, to filter the resulting list 
"functions" at the very end of "redefined_funcs" and remove all methods 
that are marked as ignore.

My final results are attached as a patch. It seems to solve all issues 
except for the overhead problem. (I was wrong about the static modifier 
- this turned out not to be necessary.)

Cheers,

Julian