Re: [pygccxml-development] Implicit virtual functions in derived classes
Brought to you by:
mbaas,
roman_yakovenko
From: Julian S. <jul...@rs...> - 2008-02-16 06:58:20
|
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 |