How to have a separate function signature for a specific language

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How to have a separate function signature for a specific language

Jimi Damon
Hi,

I am just trying to find out what might be the best strategy for
structuring my code for the case where I want a different function
signature for Java as compared to all of the other languages that I am
supporting.

I ran into the Immutability problem of Java arrays , and realized that
%typemap(argout) isn't really going to work with a function that is
being called in Java because I can't modify the String[]. My question is
, is there a way in SWIG to specify that for only Java, I want to change
the signature of the function.


An example is

/* C original function */
int foo(  int argc, char **argv );


In python I would like to call this as

sys.argv = ["-N", "100","-B","512"]
retval = foo( sys.argv )

And have sys.argv be altered.


Since it is not possible in Java, I want to change the function
signature so that it would be called as follows

String[]  foo( String[] args )

or even return something else like a Tuple that could contain both the
return code and the modified args.


Is there a "Best Practices way" to override the function signature and
do it specifically in the SWIG Module.i  file ?


Currently I have a C header file that has

#if defined(SWIGJAVA)
char **foo( int argc, char **argv );
#else
int foo( int argc, char **argv);
#endif

And I will have a typemap to converthe char ** into a String[].

Since I am trying to manage documentation for this code I would prefer
to not go with this approach as my header files start to look really ugly.

Thanks for any ideas.

-Jimi

--
WARNING - This e-mail or its attachments may contain controlled technical
data or controlled technology within the definition of the International
Traffic in Arms Regulations (ITAR) or Export Administration Regulations
(EAR), and are subject to the export control laws of the U.S. Government.
Transfer of this data or technology by any means to a foreign person,
whether in the United States or abroad, without an export license or other
approval from the U.S. Government, is prohibited. The information contained
in this document is CONFIDENTIAL and property of ACCES I/O Products, Inc.
Any unauthorized review, use, disclosure or distribution is prohibited
without express written consent of ACCES I/O Products, Inc. If you are not
the intended recipient, please contact the sender and destroy all copies of
the original message and enclosed attachments.

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Re: How to have a separate function signature for a specific language

William S Fulton
On 13 May 2016 at 00:05, Jimi Damon <[hidden email]> wrote:

> Hi,
>
> I am just trying to find out what might be the best strategy for
> structuring my code for the case where I want a different function
> signature for Java as compared to all of the other languages that I am
> supporting.
>
> I ran into the Immutability problem of Java arrays , and realized that
> %typemap(argout) isn't really going to work with a function that is
> being called in Java because I can't modify the String[]. My question is
> , is there a way in SWIG to specify that for only Java, I want to change
> the signature of the function.
>
>
> An example is
>
> /* C original function */
> int foo(  int argc, char **argv );
>
>
> In python I would like to call this as
>
> sys.argv = ["-N", "100","-B","512"]
> retval = foo( sys.argv )
>
> And have sys.argv be altered.
>
>
> Since it is not possible in Java, I want to change the function
> signature so that it would be called as follows
>
> String[]  foo( String[] args )
>
> or even return something else like a Tuple that could contain both the
> return code and the modified args.
>
>
> Is there a "Best Practices way" to override the function signature and
> do it specifically in the SWIG Module.i  file ?
>
>
> Currently I have a C header file that has
>
> #if defined(SWIGJAVA)
> char **foo( int argc, char **argv );
> #else
> int foo( int argc, char **argv);
> #endif
>
> And I will have a typemap to converthe char ** into a String[].
>
> Since I am trying to manage documentation for this code I would prefer
> to not go with this approach as my header files start to look really ugly.
>
> Thanks for any ideas.
>
You can have multi-argument typemaps for Java too so that (int, char
**) map to a Java String[] and the Java String[] is both input and
output. See the Examples/java/multimap example. You wouldn't need to
change the signature for Java then. Alternatively you could use a
typedef for the return type in your C headers and change the typedef
for Java wrappers and get a typemap to do the appropriate marshalling.

William

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Lua vector

klamb
So I noticed in std_vector.i there's a comment "all access is by value, not ref, as SWIG turns refs to pointers" and then the implementation of the __getitem__ metafunction is "T __getitem__(unsigned int idx)..."

What would the danger be, if any, to changing that to "T& __getitem__(unsigned int idx)".  The only thing I can think of as being a problem is if something else came along and wiped out the vector you were using and you held a reference to it in the script language.  However that's a problem with any data that is owned by the native language and used in the script language.

Any advice on this would be great.

I was also thinking to leave that as is and maybe make a separate get function that would return by reference and have the users use this function if they want references to vector elements.

Cheers,
Kris

------------------------------------------------------------------------------

_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Re: Lua vector

Andrew Haining

You’re exactly right. I modified my own C# vector.i to change it from calling getitem which is by reference to getitemcopy which is by value because the current C# implementation gets by reference which is undesirable in my case. Other than not being able to control the lifecycle of the reference the only other downside I can think of is potential threading issues, the down side to getting by copy is that, potentially vector[object] != vector[object]

 

I personally prefer imbuing the garbage collector ownership of all objects passed to it, it makes the learning curve for garbage collected language developers  much simpler and more consistent with what they already know but I suppose it depends on your needs & target language.

 

From: Kris Lamb [mailto:[hidden email]]
Sent: 23 August 2016 14:24
To: swig-user <[hidden email]>
Subject: [Swig-user] Lua vector

 

So I noticed in std_vector.i there's a comment "all access is by value, not ref, as SWIG turns refs to pointers" and then the implementation of the __getitem__ metafunction is "T __getitem__(unsigned int idx)..."

 

What would the danger be, if any, to changing that to "T& __getitem__(unsigned int idx)".  The only thing I can think of as being a problem is if something else came along and wiped out the vector you were using and you held a reference to it in the script language.  However that's a problem with any data that is owned by the native language and used in the script language.

 

Any advice on this would be great.

 

I was also thinking to leave that as is and maybe make a separate get function that would return by reference and have the users use this function if they want references to vector elements.

 

Cheers,

Kris


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________



Digital Barriers e-Mail Confidentiality and Disclaimer This message contains confidential information and is intended only for the individual named. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Digital Barriers plc is a company registered in England and Wales. Registered number: 7149547. Registered office: Cargo Works, 1-2 Hatfields, London SE1 9PG, United Kingdom. For further information about Digital Barriers, please visit www.digitalbarriers.com.
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

------------------------------------------------------------------------------

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