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

William S Fulton <[email protected]>
Newsgroups gmane.comp.programming.swig
Message-ID <CANGqftAmOH+DjEyckgqdXs-KwJkYQraW881fAk6Go7ikbHQvXQ@mail.gmail.com>
Hi Terry

The %apply that Rui mentioned just applies the typemap you want for these
named arguments and types. You can use these %apply directives before SWIG
parses your unmodified C++ header files containing the original argument
names. I don't see a reason to modify your header files, can you elaborate
why you think you need to do that?

William

On Tue, 23 Jun 2020 at 06:19, Terry Barnaby <[email protected]> wrote:

> Many thanks for your reply, yes I could do something like that but this
> is a complex library with lots of classes and functions defined in
> header files and I wanted to leave those header files alone and get SWIG
> to use them directly. I don't want to rewrite the header files into SWIG
> definition files as that would be a lot of work and unmaintainable. So I
> was hoping that SWIG could, somehow, apply an argument rename on a
> function by function basis.
>
> I have done it at the moment by pre-processing all of the header files
> through sed before SWIG sees them, but that's a bit messy.
>
> Terry
> On 22/06/2020 10:54, Rui Oliveira wrote:
> > Hey,
> >
> > You're probably looking to do something like:
> >
> > %apply (float complex *OUTPUT) {(liquid_float_complex *_y),
> > (liquid_float_complex *_x_hat)};
> > void modem_modulate(modem _q, unsigned int _s, liquid_float_complex *_y);
> > void modem_get_demodulator_sample(modem _q, liquid_float_complex
> > *_x_hat);
> > %clear (liquid_float_complex *_y), (liquid_float_complex *_x_hat);
> >
> > This is an example from code I've written. This is documented in:
> > http://www.swig.org/Doc4.0/SWIGDocumentation.html#Arguments_nn7
> >
> > Basically you write typemaps with generic names and then apply them to
> > your particular function arguments.
> > Me personally, I like to clear %apply directives when I no longer need
> > them to avoid bugs to do "stray" typemaps.
> >
> > Hope it helped.
> >
> > Às 10:46 de 22/06/2020, Terry Barnaby escreveu:
> >> I am wrapping a relatively complex C++ class library to produce a
> >> Python interface. One thing I haven't worked out how to do is to tell
> >> SWIG to return certain function reference arguments on the lhs of the
> >> function call only, ie. assume them to be OUTPUT only references. For
> >> example (very simplified):
> >>
> >> class DataFile {
> >>
> >> public:
> >>
> >>     Error setInfo(const Info& info);    // Input only reference
> >>
> >>     Error getInfo(Info& info);        // Output only reference
> >>
> >> };
> >>
> >> Now I can rename the getInfo function in the C++ class library to
> >> "Error getInfo(Info& OUTPUT);" say and add the appropriate typemaps
> >> to match this and that works, but I really don't want to rename all
> >> of the C++'s API function arguments for all of the classes in this
> >> library (They are used for doxygen etc).
> >>
> >> This there a simple way in SWIG to override/rename the arguments of a
> >> particular function and/or particular classes member function ? So
> >> something like:
> >>
> >> %rename("getInfo(Info& OUTPUT)") "getInfo(Info& info)"
> >>
> >> %rename("DataFile::getInfo(Info& OUTPUT)") "DataFile::getInfo(Info&
> >> info)"
> >>
> >>
> >>
> >> _______________________________________________
> >> Swig-user mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/swig-user
> >
> >
> > _______________________________________________
> > Swig-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/swig-user
>
>
>
>
> _______________________________________________
> Swig-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.