From: Jan J. <je...@po...> - 2008-10-27 17:48:16
|
Jan Jezabek wrote: > William S Fulton wrote: >> Jan Jezabek wrote: >>> Hi everyone, >>> >>> I have come up with a patch for the issues mentioned previously. >>> There is still a warning if you overload a name that has been used as >>> a variable in a base class (see A::ccc and B::ccc(int) in the >>> previous message) - I am still not sure how to handle this. >>> >> That's an unusual case, I don't have any suggestions. >> >>> The main part of the patch - consisting of modifications to >>> allocate.cxx - is here (rev 10739 in my branch): >>> http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2008-jezabek/Source/Modules/allocate.cxx?r1=10418&r2=10739 >>> >>> >>> If you prefer the resulting file then you can find it here: >>> http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2008-jezabek/Source/Modules/allocate.cxx?revision=10739&view=markup >>> >>> >>> The patch separates the part of function_is_defined_in_bases which >>> was responsible for checking if the function is virtual - this part >>> should not be sensitive to %ignore and %rename. The remaining part of >>> function_is_defined_in_bases only checks the bases that are >>> superclasses in the target language (this was not exactly the case >>> earlier - if a base class B was ignored but its superclass A was not >>> then a class deriving from B could have methods with the 'override' >>> modifier - see inherit_same_name4 test-case). >>> I have tested this change using check-csharp-test-suite; the only >>> difference was that the rname testcase stopped complaining about an >>> unnecessary 'new' modifier. >>> >>> I have also created test cases that trigger warnings and errors with >>> the previous code - these are revisions 10740 and 10742, available here: >>> http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=10740 >>> http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=10742 >>> >>> Finally I have made a minor change to allocate.cxx for finding >>> methods that have been overloaded in a subclass (see my first message >>> in this thread): >>> http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=10741 >>> >>> All of these changes are still in my branch, but they are not really >>> COM-specific (apart of 10741) so I'd be happy to merge them to trunk >>> once they are reviewed and accepted as correct. >>> >> Sorry for the delays in looking at this. It automates what users >> previously had to do manually for C#, ie fix up the override/new >> modifier in the C# proxy class which is nice. >> >> I've a query about overloads_base which you have added for the COM >> module. I can't quite work out what this does, eg this triggers the >> attribute being set: >> >> struct Base { >> virtual void overload1() {} >> virtual void overload1(int) {} >> virtual ~Base() {} >> }; >> struct Derived : Base { >> void overload1(int) {} >> }; >> >> but this does not: >> >> struct Base { >> virtual void overload1() {} >> virtual void overload1(int) {} >> virtual ~Base() {} >> }; >> struct Derived : Base { >> void overload1() {} >> }; >> >> Perhaps you can explain better in allocate.cxx what exactly the >> attribute is meant to do and fix what looks like to be a bug? Is it >> meant to be indicating an overridden method that is overloaded in the >> base class? I presume this is targeting the sym:name rather than name >> so it takes into acccount %ignore, %rename? One minor point is as a >> general rule, attribute names don't have underscores, so >> overloads_base ought to become overloadsbase. >> >> William >> > Thanks for looking at this. The purpose of the attribute is to mark a > method which has the same name as a method in one of its ancestors > (excluding the case when the method in the child overrides or hides the > method in the parent). This is analogous to overloading - but it is not > detected at the symbol table level. Your example obviously shows a bug, > I will have a look at it. > The decision is based on sym:name so that the user can rename the method > as a workaround for targets without support for overloading. > I'll take care of the underscore :). > > Jan Jezabek > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ Excuse me if you get this message twice. I sent it yesterday and it has neither appeared in the sf.net archive nor at GMANE. I have verified that I'm subscribed to swig-devel, so it must have got lost somewhere... Hi William, I've committed a new revision to my branch. You can see the diff from the original allocate.cxx here: http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2008-jezabek/Source/Modules/allocate.cxx?r1=10418&r2=10894&diff_format=s A few words about the problem you noticed - it happened because the search in the base classes is interrupted if there is an exact match, i.e. when the function overrides or hides a function in the base class. If this is the case then the overridesbase attribute makes not much sense. Thus I think it should be removed in case it has been set earlier (setting the overridesbase attribute does not stop the search). With the change applied both examples that you gave behave in the same way - the overridesbase attribute is not set for the function in the subclass. I have made the change to the attribute name and have also added a few comments about the attribute. Jan Jezabek -- My GSoC 2008 development blog: http://jezabekgsoc.wordpress.com/ |