Re: [Swig-user] How can I specify different typemaps depending on the method being wrapped ?

[Marvin G. <pub...@gm...>]

On 12/Aug/28 11:50 AM, Éric Cabot wrote:
>>
>> Context: porting C++ code to C#
>>
>> Say I have many C++ classes with some member methods returning the type MyType:
>>
>> class Class1
>>
>> {
>>
>> public:
>>
>>                 virtual MyType foo1();
>>
>>                 virtual MyType foo2();
>>
>> };
>>
>> Say I have 100 classes like this.
>>
>> I am using the directorout typemap on this type like in the following:
>>
>> %typemap(directorout) MyType %{
>>
>>    $result = something...
>>
>> %}
>>
>> But I found a few cases where I would like to handle it differently.
>>
>> So in some of the 100 classes I would like the typemap to be the following 
>> instead:
>>
>> %typemap(directorout) MyType %{
>>
>>    $result = something *else* ....
>>
>> %}
>>
>> How can I do this ?
>>
>> i.e.: I would like to tell swig to apply a given %typemap(directorout) to 
>> some class methods but to use another %typemap(directorout) to other class 
>> methods, all for the same type (e.g.: MyType).
>>
>> The only thing I found is to use the $symname variable and do something ugly 
>> like this:
>>
>> %typemap(directorout) MyType %{
>>
>> if( strcmp( "$symname", "foo1" ) == 0 )
>>
>> $result = something...
>>
>>        else
>>
>> $result = something else ....
>>
>> %}
>>
>> This is far from being perfect because two classes can have the method foo1 
>> but different handling may be desired and calling strcmp all the time is slow.
>>
>> I wish there was a way to do something like:
>>
>> %typemap(directorout) MyType *Class1::*, Class2::foo1, Class2::foo3* %{
>>
>> $result = something...
>>
>> %}
>>
>> %typemap(directorout) MyType *Class2::foo2, Class3::** %{
>>
>> $result = something else...
>>
>> %}
>>
>> Thanks !
>>
>
Hmm.  I assumed you can mostly do what you want, but looking at the debug 
output, I see it works for "out" and "javaout" (and presumably csout), but not 
"directorout".

I ran swig with -debug-tmsearch on one of our interface files and see pages of 
output like...

> RemoteMethodsInterface.i:66: Searching for a suitable 'out' typemap for: 
> Example::AreaOfEffect::ImmutableLocalClassPtr const 
> Example::Tank::RemoteMethodsInterface::fireGun
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr const 
> Example::Tank::RemoteMethodsInterface::fireGun
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr const fireGun
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr const
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr 
> Example::Tank::RemoteMethodsInterface::fireGun
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr fireGun
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr ...

Note that it is proving the method name and the class-qualified name to search.  
I get similar results for 'javaout' typemap searches, but the directorout 
typemap searches look like:
> RemoteMethodsInterface.i:66: Searching for a suitable 'directorout' typemap 
> for: Example::AreaOfEffect::ImmutableLocalClassPtr const c_result
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr const c_result
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr const
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr c_result
>   Looking for: Example::AreaOfEffect::ImmutableLocalClassPtr ...
So, except for directorout, you COULD do (for example)

%typemap(out) MyType Class2::foo2, MyType foo, MyType Class3::foo4 %{ special; }
%typemap(out) MyType %{ everything else; }

I don't know why the directorout typemap doesn't provide the context of the 
method name.  The c_result bit must be something coming from the code generating 
the director wrapper code -- it isn't in my interface.   It may just be a bug or 
artifact of something that causes swig to lose the method name context.

marvin