Re: Howto override the argument names of certain class member functions

On Sat, 27 Jun 2020 at 12:13, Terry Barnaby <[email protected]> wrote:

> Hi William,
>
> Thanks for the reply. Notes below in the text.
>
> Terry
> On 27/06/2020 11:52, William S Fulton wrote:
>
> Hi Terry
>
>
> On Sat, 27 Jun 2020 at 10:42, Terry Barnaby <[email protected]> wrote:
>
>> Hi William,
>>
>> I have a large class library. There are multiple functions that have a,
>> say, "(Channel& chan)" argument. In most cases these are used to return
>> values, but in some cases the functions modify the contents of the object
>> who's reference is passed. So I cannot generically use the %template
>>
>
> I think you meant %apply.
>
> Yes, sorry, I meant %apply.
>
>
>
> system as that only applies to the type and names of arguments passes,
>> there is not ability to say a particular function is just using that
>> argument as an output return. A lot of this libraries code is auto
>> generated from a IDL and I generate a set of modified *.h files with the
>> argument names changed to OUTPUT at the appropriate places but quite a few
>> class member functions are not like that.
>>
> So I think you are saying you want to %apply these typemaps for parameters
> with the same name and type, but only on a select few functions and you
> don't want to modify the header files. The best solution SWIG has is to use
> %apply and %clear as Rui alluded to. This will work to some degree as the
> %apply will apply for all the functions in a header file you have include
> with %include. You can then use %clear after the %include. If you want to
> selectively apply the typemaps to parameters with the same type and name in
> one header file, then the next best solution is to use %ignore and then add
> the functions back in with %extend, renaming the parameters to something
> else. You imply that you only have a few of these that you don't want the
> typemaps to apply to, so this might be workable for you.
>
> Unfortunately this is a large library and within header files there are
> multiple functions which I would need to do this on, so it can't be done
> using %apply and %clear unless a re-write the header file into SWIG. I
> could use %ignore and %extent but I think this would get quite messy
> especially as most of the functions are members of classes. I will have a
> play with that.
>
Use a macro which does the %ignore and %extend in a simple call. That'll be
easy to use unless you have a huge number and variety of function
signatures.


>
>
> Looking at the original post, you have this in a header file:
>
>   class DataFile {
>    public:
>        Error setInfo(const Info& info);    // Input only reference
>        Error getInfo(Info& info);        // Output only reference
>    };
>
> the types are NOT the same as one is const and the other is not const. If
> you look at the typemap rules, you'll see that if you have a typemap for
> const Info&, it will not apply to non-const Info&. However a non-const
> Info& typemap it wil apply to const Info&. So if you want to consistently
> apply typemaps to const and non-const, then solution is easy, something
> like:
>
> %typemap(argout) const Info& OUTPUT "" // does nothing (effectively clears
> the typemap)
> %typemap(argout) Info& OUTPUT "/* some code for argout*/"
> %apply Info& OUTPUT { Info& info };
> %apply const Info& OUTPUT { const Info& info };
>
> The main reason SWIG does not have function and parameter name
> combinations for typemaps is there is no C++ scoping syntax to get at the
> scope of a parameter name from outside of the function. I can elaborate
> more if anyone is really interested.
>
> That was a bit of a simplification, and as you say didn't show the issue!
> In effect there are multiple functions like getInfo. I do have many
> functions that use the "const Type&" which as you say the %typemap, %apply
> system works well on.
>
Perhaps your API needs to be improved. I can't see why you would want to
use the OUTPUT typemaps on a non-const reference type. Are you needing to
have OUTPUT typemaps for non-const references?


> Well I would have thought it would be possible in SWIG even if at a simple
> pre-processing regular expression string replacement level which is how I
> have effectively handled it now ? I would have thought though that SWIG
> could do this internally it must know:
> <Namespace>::<class>::functionName::[Arg Type/name list] from its C++
> parsing to nodes ?
>
Something like that would indeed be possible and would be a powerful
extension to SWIG. I think if there was valid C++ syntax and scoping for
specifing a parameter, it would have been implemented ages ago. I can think
of various approaches to providing this matching capability. If you'd like
to discuss and contribute to an implementation of it, please raise a Github
issue.

Regards
William

_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user