swig-user — SWIG User List

[Swig-user] Announce - swig-4.4.1

[William S F. <ws...@fu...>]

*** ANNOUNCE: SWIG 4.4.1 (7 Dec 2025) ***

https://www.swig.org

We're pleased to announce SWIG-4.4.1, the latest SWIG release.

What is SWIG?
=============

SWIG is a software development tool that reads C/C++ header files and
generates the wrapper code needed to make C and C++ code accessible
from other programming languages including Perl, Python, Tcl, Ruby,
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile), D,
Ocaml, Octave, R, Scilab.  SWIG can also export its parse tree in
the form of XML.  Major applications of SWIG include generation of
scripting language extension modules, rapid prototyping, testing,
and user interface development for large C/C++ systems.

Release Notes
=============
Detailed release notes are available with the release and are also
published on the SWIG web site at https://swig.org/release.html.

Availability
============
The release is available for download on Sourceforge at

     https://prdownloads.sourceforge.net/swig/swig-4.4.1.tar.gz

A Windows version is also available at

     https://prdownloads.sourceforge.net/swig/swigwin-4.4.1.zip

Please report problems with this release to the swig-devel mailing list,
details at https://www.swig.org/mail.html.

--- The SWIG Developers

Re: [Swig-user] PyList_New coredumps if called from inline function

[William S F. <ws...@fu...>]

On Thu, 6 Nov 2025 at 14:41, Alexander Moibenko <anm...@gm...> wrote:

> Hello,
> call of PyList_New causes coredump if called from inline function.
> Environment:
> OS: Ubuntu, or Alma Linux 9 (give same result)
> swig:
> SWIG Version 4.0.2
> Compiled with g++ [x86_64-pc-linux-gnu]
> Configured options: +pcre
>
> python: Python 3.12.7
>
> Code:
> swig:
> =====================================
> %module test_PyList_New
>
> %inline %{
>   PyObject * test_PyList_New(const int buf_len)
>   {
>     PyObject * out_list;
>
>     printf("test_PyList_New requested buffer length %d\n", buf_len);
>     out_list = PyList_New(buf_len);
>     return NULL;
>

A python error needs to be set if you want to return NULL. Maybe you meant
to return out_list? Also, the latest SWIG version, swig-4.4.0 returns
immediately to the interpreter for the PyObject* typemaps, as it should as
NULL indicates an error.

William

Re: [Swig-user] PyList_New coredumps if called from inline function

[Alexander M. <anm...@gm...>]

Looks as I found the source of the problem.
I run swig as
swig -shadow -python -py3 -threads test_PyList_New.i
and get warning:
132 | Py_DEPRECATED(3.9) PyAPI_FUNC(void) PyEval_InitThreads(void);

when build .so module
I did not pay attention to this wagning, but it appears, that this is the
source of the problem.

If I run swig as
swig -shadow -python -py3 test_PyList_New.i
the call test_PyList_New() works.

Alexander

On Thu, Nov 6, 2025 at 5:41 PM Alexander Moibenko <anm...@gm...>
wrote:

> Hello,
> call of PyList_New causes coredump if called from inline function.
> Environment:
> OS: Ubuntu, or Alma Linux 9 (give same result)
> swig:
> SWIG Version 4.0.2
> Compiled with g++ [x86_64-pc-linux-gnu]
> Configured options: +pcre
>
> python: Python 3.12.7
>
> Code:
> swig:
> =====================================
> %module test_PyList_New
>
> %inline %{
>   PyObject * test_PyList_New(const int buf_len)
>   {
>     PyObject * out_list;
>
>     printf("test_PyList_New requested buffer length %d\n", buf_len);
>     out_list = PyList_New(buf_len);
>     return NULL;
>   }
>     %}
> ======================================
> Testing:
> python
> Python 3.12.7 (main, Oct 20 2025, 13:39:44) [GCC 11.4.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import test_PyList_New
> >>> test_PyList_New.test_PyList_New(20)
> test_PyList_New requested buffer length 20
> Segmentation fault (core dumped)
>
> This worked with earlier swig versions, at least 2.XX
> Please help.
> Thanks a lot in advance.
> Alexander
>
>

[Swig-user] PyList_New coredumps if called from inline function

[Alexander M. <anm...@gm...>]

Hello,
call of PyList_New causes coredump if called from inline function.
Environment:
OS: Ubuntu, or Alma Linux 9 (give same result)
swig:
SWIG Version 4.0.2
Compiled with g++ [x86_64-pc-linux-gnu]
Configured options: +pcre

python: Python 3.12.7

Code:
swig:
=====================================
%module test_PyList_New

%inline %{
  PyObject * test_PyList_New(const int buf_len)
  {
    PyObject * out_list;

    printf("test_PyList_New requested buffer length %d\n", buf_len);
    out_list = PyList_New(buf_len);
    return NULL;
  }
    %}
======================================
Testing:
python
Python 3.12.7 (main, Oct 20 2025, 13:39:44) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import test_PyList_New
>>> test_PyList_New.test_PyList_New(20)
test_PyList_New requested buffer length 20
Segmentation fault (core dumped)

This worked with earlier swig versions, at least 2.XX
Please help.
Thanks a lot in advance.
Alexander

[Swig-user] Announce - swig-4.4.0

[William S F. <ws...@fu...>]

*** ANNOUNCE: SWIG 4.4.0 (20 Oct 2025) ***

https://www.swig.org

We're pleased to announce SWIG-4.4.0, the latest SWIG release.

What is SWIG?
=============

SWIG is a software development tool that reads C/C++ header files and
generates the wrapper code needed to make C and C++ code accessible
from other programming languages including Perl, Python, Tcl, Ruby,
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile), D,
Ocaml, Octave, R, Scilab.  SWIG can also export its parse tree in
the form of XML.  Major applications of SWIG include generation of
scripting language extension modules, rapid prototyping, testing,
and user interface development for large C/C++ systems.

Release Notes
=============
Detailed release notes are available with the release and are also
published on the SWIG web site at https://swig.org/release.html.

Availability
============
The release is available for download on Sourceforge at

     https://prdownloads.sourceforge.net/swig/swig-4.4.0.tar.gz

A Windows version is also available at

     https://prdownloads.sourceforge.net/swig/swigwin-4.4.0.zip

Please report problems with this release to the swig-devel mailing list,
details at https://www.swig.org/mail.html.

--- The SWIG Developers

[Swig-user] Is there a way to send an extra parameter between the goout and out typemaps?

[Lindley F. <lin...@gm...>]

Is there a way to send an extra parameter between the goout and out
typemaps?

I'm taking a look at whether there's any practical way to map
absl::StatusOr<T> (or std::expected) to Golang's "return T, err" pattern.
This requires propagating both an error and a value across the language
boundary.

We can kindly ask the user to make one of those two an output parameter,
but it would be really neat if we could automatically inject an extra
parameter between goout and out that doesn't have any corresponding
parameter in either the Go or C++ client code.

I don't see anything like that in the SWIG docs, but maybe some feature has
been added that isn't in the docs?

[Swig-user] python: STL containers and enum types

[Alessio M <mas...@gm...>]

Hi there!

I've been having issues with containers that use enums as elements or keys
I can see the code for the container being generated correctly
But the typecheck fails because no descriptor can be found for the enum
type at the following line of code
https://github.com/swig/swig/blob/master/Lib/std/std_common.i#L105

I understand that the enum is seen by python as a simple integer.
Do I need to add anything specific to make them work as keys in maps or
elements in vectors?

Thank you!

enum class FooEnum {
  one,
  two
};
double bar(std::unordered_set<FooEnum> const&)
{
  return 1;
}
double bar(std::unordered_map<FooEnum, int> const&)
{
  return 1;
}
%template(FooSet) std::unordered_set<FooEnum>;
%template(FooMap) std::unordered_map<FooEnum, int>;

[Swig-user] operator+= in python

[Langer, S. A. (Fed) <ste...@ni...>]

Hi --

What’s the correct way to use SWIG to create a Python version of C++ compound assignment operator, like operator+= ?    The simple thing isn’t doing what I expect.
For an object of a Python class that defines __iadd__,
    pyobject += other_pyobject
doesn’t change the identity of pyobject.  But for a C++ object that defines operator+=, SWIG creates an __iadd__ method that returns a new Python object.
So
      swigobject += other_swigobject
changes the identity of swigobject, although it still refers to the same C++ object.  When the redundant Python object is deleted, the C++ destructor is called an extra time, which is bad.

The swig file just declares a simple class that defines MyClass& operator+=(const MyClass&).  The generated __iadd__ wrapper function ends with
      resultobj = SWIG_NewPointerObj(SWIG_as_voidptr(result), SWIGTYPE_p_MyClass, SWIG_POINTER_OWN |  0 );
      return resultobj;
Changing SWIG_POINTER_OWN|0 to 0 fixes the problem, as far as my simple tests show.  I don’t know if it introduces other problems.

I’ve tried SWIG 4.1 to 4.3.1, and they all behave the same.

Thanks.
 -- Steve

Re: [Swig-user] a %downcast macro for Java needs the name of the JVM wrapper type for a call to jenv->FindClass

[William S F. <ws...@fu...>]

Look at the $typemap special variable macro, but use it in a typemap. Good
examples in the Lib/java/std_vector.i file and also some tests in
Examples/testsuite/*.i. Documented in
https://swig.org/Doc4.3/Typemaps.html#Typemaps_special_macro_typemap.

On Tue, 10 Jun 2025 at 20:36, Alessio M <mas...@gm...>
wrote:

> For a given C++ type being wrapped, is it possible to get the
> (fully qualified) name of the wrapped type in the target language?
>
> I have many factory methods that return std::shared_ptr<const BaseClass>
> I do wrap and export to java several types derived from BaseClass
> And I need the runtime wrapper JVM managed type to accurately match those
> derived types
> I wrote the below %downcast macro
> I have a version of this for python which works quite nicely. It uses
> $descriptor(DeriverType) to create the python native extension type
>
> But JNI code does not seem to have any descriptor infrastructure in the
> module.
>
> Is there a way to make this work in Java?
>
> Thank you for any help you can provide
>
>
>
> // Helper function for %downcast, to be called for each target type
>
> %define %_downcast_const(Type)
>     {
>       auto const out = %dynptrcast(const Type,ptr);
>       if (out)
>       {
>         auto const clazz = jenv->FindClass(  >>>>>
> I_NEED_THE_JAVA_CLASS_NAME_HERE<<<<  );
>         if (clazz)
>         {
>           auto const mid = jenv->GetMethodID(clazz, "<init>", "(JZ)V");
>           if (mid)
>             return reinterpret_cast<jlong>(jenv->NewObject(clazz, mid,
> reinterpret_cast<jlong>(new %ptr(const Type)(out)), false));
>         }
>       }
>     }
> %enddef
>
>
>
> // the actual %downcast macro
>
> %define %downcast(typemaptarget, Types...)
>
> %fragment(%fragment_name(downcast, typemaptarget), "header") {
> jlong downcast(%ptr(const typemaptarget) const& ptr, JNIEnv *jenv)
> {
>   if (!ptr)
>     return 0; // TODO: check this is correct
>   else
>   {
>     %formacro(%_downcast_const, Types)
>   }
>   return 0;
> }
> }
>
> %typemap(jni) %ptr(typemaptarget) "jobject"
> %typemap(jtype) %ptr(typemaptarget) #typemaptarget
> %typemap(jstype) %ptr(typemaptarget) #typemaptarget
> %typemap(javaout) %ptr(typemaptarget) {
>   return $jnicall;
> }
>
> %typemap(out, fragment=%fragment_name(downcast, typemaptarget))
> %ptr(typemaptarget) {
>   $result = downcast($1, jenv);
>   if (!$1 || !$result)
>     SWIG_exception(SWIG_TypeError,"Actual object type could not be
> %downcasted. Consider adding derived types to %downcast declaration.");
> }
> %typemap(out, fragment=%fragment_name(downcast, typemaptarget)) %ptr(const
> typemaptarget) {
>   $result = downcast($1, jenv);
>   if (!$1 || !$result)
>     SWIG_exception(SWIG_TypeError,"Actual object type could not be
> %downcasted. Consider adding derived types to %downcast declaration.");
> }
> %typemap(out, fragment=%fragment_name(downcast, typemaptarget))
> %ptr(typemaptarget) const& {
>   $result = downcast(*$1, jenv);
>   if (!$1 || !$result)
>     SWIG_exception(SWIG_TypeError,"Actual object type could not be
> %downcasted. Consider adding derived types to %downcast declaration.");
> }
> %typemap(out, fragment=%fragment_name(downcast, typemaptarget)) %ptr(const
> typemaptarget) const& {
>   $result = downcast(*$1, jenv);
>   if (!$1 || !$result)
>     SWIG_exception(SWIG_TypeError,"Actual object type could not be
> %downcasted. Consider adding derived types to %downcast declaration.");
> }
>
> %enddef
> _______________________________________________
> Swig-user mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

[Swig-user] a %downcast macro for Java needs the name of the JVM wrapper type for a call to jenv->FindClass

[Alessio M <mas...@gm...>]

For a given C++ type being wrapped, is it possible to get the
(fully qualified) name of the wrapped type in the target language?

I have many factory methods that return std::shared_ptr<const BaseClass>
I do wrap and export to java several types derived from BaseClass
And I need the runtime wrapper JVM managed type to accurately match those
derived types
I wrote the below %downcast macro
I have a version of this for python which works quite nicely. It uses
$descriptor(DeriverType) to create the python native extension type

But JNI code does not seem to have any descriptor infrastructure in the
module.

Is there a way to make this work in Java?

Thank you for any help you can provide



// Helper function for %downcast, to be called for each target type

%define %_downcast_const(Type)
    {
      auto const out = %dynptrcast(const Type,ptr);
      if (out)
      {
        auto const clazz = jenv->FindClass(  >>>>>
I_NEED_THE_JAVA_CLASS_NAME_HERE<<<<  );
        if (clazz)
        {
          auto const mid = jenv->GetMethodID(clazz, "<init>", "(JZ)V");
          if (mid)
            return reinterpret_cast<jlong>(jenv->NewObject(clazz, mid,
reinterpret_cast<jlong>(new %ptr(const Type)(out)), false));
        }
      }
    }
%enddef



// the actual %downcast macro

%define %downcast(typemaptarget, Types...)

%fragment(%fragment_name(downcast, typemaptarget), "header") {
jlong downcast(%ptr(const typemaptarget) const& ptr, JNIEnv *jenv)
{
  if (!ptr)
    return 0; // TODO: check this is correct
  else
  {
    %formacro(%_downcast_const, Types)
  }
  return 0;
}
}

%typemap(jni) %ptr(typemaptarget) "jobject"
%typemap(jtype) %ptr(typemaptarget) #typemaptarget
%typemap(jstype) %ptr(typemaptarget) #typemaptarget
%typemap(javaout) %ptr(typemaptarget) {
  return $jnicall;
}

%typemap(out, fragment=%fragment_name(downcast, typemaptarget))
%ptr(typemaptarget) {
  $result = downcast($1, jenv);
  if (!$1 || !$result)
    SWIG_exception(SWIG_TypeError,"Actual object type could not be
%downcasted. Consider adding derived types to %downcast declaration.");
}
%typemap(out, fragment=%fragment_name(downcast, typemaptarget)) %ptr(const
typemaptarget) {
  $result = downcast($1, jenv);
  if (!$1 || !$result)
    SWIG_exception(SWIG_TypeError,"Actual object type could not be
%downcasted. Consider adding derived types to %downcast declaration.");
}
%typemap(out, fragment=%fragment_name(downcast, typemaptarget))
%ptr(typemaptarget) const& {
  $result = downcast(*$1, jenv);
  if (!$1 || !$result)
    SWIG_exception(SWIG_TypeError,"Actual object type could not be
%downcasted. Consider adding derived types to %downcast declaration.");
}
%typemap(out, fragment=%fragment_name(downcast, typemaptarget)) %ptr(const
typemaptarget) const& {
  $result = downcast(*$1, jenv);
  if (!$1 || !$result)
    SWIG_exception(SWIG_TypeError,"Actual object type could not be
%downcasted. Consider adding derived types to %downcast declaration.");
}

%enddef

Re: [Swig-user] Wrapping long doubles in python

[Olly B. <ol...@su...>]

On Thu, Jan 30, 2025 at 02:32:15PM -0800, Ayman Habib wrote:
> I'm upgrading the swig version we use from 4.1.1 to 4.2 and running into a
> problem because of the macro below (it appears in a header file from a
> third party library that I can't change), but I get the same behavior
> inserting the line in my .i file:
> 
> #define MY_PI 3.1415926535897L
> 
> The resulting python code doesn't compile:
> 
>   SWIG_Python_SetConstant(d,
> "MY_PI",SWIG_NewPointerObj(SWIG_as_voidptr(&3.1415926535897),SWIGTYPE_p_long_double,
> 0 ));

Prior to 4.2.0, SWIG quietly incorrectly treated all floating point
literals as being type `double` (so suffixes like `L` above or `f` to
specify a `float` literal were just ignored).

For `long double` in particular that's potentially bad - presumably the
long double type was chosen for a reason, but SWIG's wrapping was
quietly discarding the extra precision this provides.  Using the wrong
types here was also getting in the way of improving support for C++
`auto` and `decltype`.

However SWIG doesn't currently provide long double typemaps (except for
a Python doctype one):

https://github.com/swig/swig/issues/2964

So the upshot is the error you report, but that seems better than quietly
wrapping a constant with a different value to the one specified in the
header being wrapped.

If you're happy with the previous situation of truncating the precision
to that of double then you can just tell SWIG to wrap the constant as a
double by adding this near the top of your interface file:

%constant double MY_PI;
%warnfilter(SWIGWARN_PARSE_REDEFINED) MY_PI;

This should also work with older SWIG versions.

Cheers,
    Olly

Re: [Swig-user] Speeding up builds

[Olly B. <ol...@su...>]

On Fri, May 23, 2025 at 08:19:41AM -0500, Davis C. wrote:
> On Thu, May 22, 2025, 4:58 PM Olly Betts <ol...@su...> wrote:
> 
> > My first suggestion would be to make sure you're using the latest
> > version in case this has already been addressed.
> 
> That was it. I was running version 4.0.1. On 4.3.1 it takes only 30 seconds
> for the same file. I should've thought to check that sooner.

I suspect this is thanks to an improvement in 4.1.0 to the hash function
used for SWIG's internal hash tables.

The old hash function only considered the last five characters plus the
least significant bit of the last-but-sixth character, which could
generate a lot of many-way collisions, especially for C++ code.  For
example, processing li_std_list_wrap.i from the testsuite for Python the
hash collision rate dropped from 39% to 0.

Cheers,
    Olly

Re: [Swig-user] Speeding up builds

[Davis C. <dav...@gm...>]

On Thu, May 22, 2025, 4:58 PM Olly Betts <ol...@su...> wrote:

> My first suggestion would be to make sure you're using the latest
> version in case this has already been addressed.
>

That was it. I was running version 4.0.1. On 4.3.1 it takes only 30 seconds
for the same file. I should've thought to check that sooner.

Thanks!

>

Re: [Swig-user] Speeding up builds

[Olly B. <ol...@su...>]

On Thu, May 22, 2025 at 11:43:35AM -0500, Davis C. wrote:
> Is there any way to speed up the build, or make it multithreaded? Running
> `htop` while its building shows that it's only using a single core.

There's currently no multi-threading in the swig binary (there's not a
lot of obvious scope for parallelism so it would probably be hard to
usefully introduce).

However it really shouldn't take anything like 22 minute to run.  Unless
you're feeding it an enormous generated header I think you must be
triggering some particular pathological case, so identifying and fixing
that should reduce the time taken to something more reasonable.

My first suggestion would be to make sure you're using the latest
version in case this has already been addressed.

If you are, can you profile and see where most of the time is being
spent?

Cheers,
    Olly

[Swig-user] Speeding up builds

[Davis C. <dav...@gm...>]

Hello! I'm new to SWIG, but am looking to integrate it into a project of
mine.

It mostly seems to work flawlessly so far, but on a very large file (a 140k
line header file), SWIG takes a very long time to generate the python
wrapper (22 minutes on my system) [1]. This header file is mostly struct
and enum declarations.

Is there any way to speed up the build, or make it multithreaded? Running
`htop` while its building shows that it's only using a single core. I've
tried some of the CLI flags like `-no<blah>`, but they didn't seem to
provide much of a speed up. I imagine breaking the file up some would help,
but I don't control the file and would prefer to avoid manually splitting
it.

[1]: The specific command I'm using is `swig -python -doxygen -module thing
thing.h`. I'd like the doxygen output, but even without the flag, it's
still quite slow.

Thanks,
Davis

[Swig-user] Announce - swig-4.3.1

[William S F. <ws...@fu...>]

*** ANNOUNCE: SWIG 4.3.1 (15 Apr 2025) ***

https://www.swig.org

We're pleased to announce SWIG-4.3.1, the latest SWIG release.

What is SWIG?
=============

SWIG is a software development tool that reads C/C++ header files and
generates the wrapper code needed to make C and C++ code accessible
from other programming languages including Perl, Python, Tcl, Ruby,
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D,
Ocaml, Octave, R, Scilab.  SWIG can also export its parse tree in
the form of XML.  Major applications of SWIG include generation of
scripting language extension modules, rapid prototyping, testing,
and user interface development for large C/C++ systems.

Release Notes
=============
Detailed release notes are available with the release and are also
published on the SWIG web site at https://swig.org/release.html.

Availability
============
The release is available for download on Sourceforge at

     https://prdownloads.sourceforge.net/swig/swig-4.3.1.tar.gz

A Windows version is also available at

     https://prdownloads.sourceforge.net/swig/swigwin-4.3.1.zip

Please report problems with this release to the swig-devel mailing list,
details at https://www.swig.org/mail.html.

--- The SWIG Developers

Re: [Swig-user] Ignoring default arguments in wrapper generation

[William S F. <ws...@fu...>]

Arguably the following should work for you:

%ignore something(int foo);
int something(int foo, int bar=SOME_DEFINE_COMING_FROM_ANOTHER_HEADER);

like it does for Java. It partially does the ignore as the C++ layer only
generates code for taking two arguments, but the python layer defines:

def something(*args):

when it could generate

def something(foo, bar):

You could raise this as an issue in Github, but at least you have a
workaround.

William

On Wed, 19 Feb 2025 at 10:11, Arnaud Diederen via Swig-user <
swi...@li...> wrote:

>
> ....aaaaaaand,
>
> On Wed, Feb 19, 2025 at 10:42 AM Arnaud Diederen <ar...@he...>
> wrote:
>
>> [...]the problem arises because of
>> `SOME_DEFINE_COMING_FROM_ANOTHER_HEADER`.
>>
>
> Wrong again.
>
> The problem is that the define has syntax that SWiG dislikes:
>
> `#define SOME_DEFINE_COMING_FROM_ANOTHER_HEADER thread_id_t(-1)`
>
> However, that is pretty good news, as I have full control over this.
> Looks like I can proceed with my rube-goldbergery!
> Best regards,
>    A.
>
>
>>
>> That other header, will be converted to another Python module, so I
>> cannot just `%include` it (it'll duplicate functionality in both the
>> current, and that other module.)
>> I tried `%import`'ing it, but no luck.
>>
>> If you happen to have suggestions, I'm all ears!
>>
>> Best regards,
>>     A.
>>
>>
>>
>> On Wed, Feb 19, 2025 at 9:49 AM Arnaud Diederen <ar...@he...>
>> wrote:
>>
>>> Hi,
>>>
>>> we have a relatively complex system that builds Python bindings on top
>>> of a SDK, and SWiG plays an important role early in the chain.
>>>
>>> An issue that has arisen, is the fact that from the following
>>> declaration:
>>> ```
>>> int something(int foo, int bar=10);
>>> ```
>>>
>>> SWiG will generate a Python function with the following signature:
>>> ```
>>> def something(*args):
>>>      return _module.something(*args)
>>> ```
>>> …and leave it up to `_module` to perform the dispatch between
>>> `_wrap_something__SWIG_0` and `_wrap_something__SWIG_1` (or
>>> `_wrap_something` if `compactdefaultargs` is used.)
>>>
>>> However, this is not really playing nice with the rest of our bindings
>>> "build system", because of the presence of `*args`.
>>>
>>> Something that would work much better for me, is if I could tell SWiG
>>> (ideally w/o `%ignore`'ing that function and then re-defining it myself),
>>> to simply "drop" the default value.
>>> In other words, I'd love it if I could tell SWiG to consider that
>>> declaration as if  it were:
>>>
>>> ```
>>> int something(int foo, int bar);
>>> ```
>>> …and our bindings build system would take it up from here.
>>>
>>> I realize this is perhaps not the canonical use-case for SWiG, but is
>>> there any chance I can achieve that, in a hopefully rather elegant manner?
>>>
>>> Note: `compactdefaultargs` does not work in this case, because while the
>>> default args values are assigned in the generated CPP wrapper code
>>> (great!), the Python wrapper itself still has only `*args` (ouch.)
>>>
>>> Any pointer welcome!
>>>
>>> Best regards,
>>>        A.
>>>
>>>
>>>
>>> --
>>>
>>> Arnaud Diederen
>>>
>>> Head of Engineering
>>>
>>> ar...@he... <ste...@he...>
>>>
>>> +32 472 940 315
>>>
>>>
>>>
>>
>> --
>>
>> Arnaud Diederen
>>
>> Head of Engineering
>>
>> ar...@he... <ste...@he...>
>>
>> +32 472 940 315
>>
>>
>>
>
> --
>
> Arnaud Diederen
>
> Head of Engineering
>
> ar...@he... <ste...@he...>
>
> +32 472 940 315
>
>
> _______________________________________________
> Swig-user mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

Re: [Swig-user] Ignoring default arguments in wrapper generation

[Arnaud D. <ar...@he...>]

....aaaaaaand,

On Wed, Feb 19, 2025 at 10:42 AM Arnaud Diederen <ar...@he...>
wrote:

> [...]the problem arises because of
> `SOME_DEFINE_COMING_FROM_ANOTHER_HEADER`.
>

Wrong again.

The problem is that the define has syntax that SWiG dislikes:

`#define SOME_DEFINE_COMING_FROM_ANOTHER_HEADER thread_id_t(-1)`

However, that is pretty good news, as I have full control over this.
Looks like I can proceed with my rube-goldbergery!
Best regards,
   A.


>
> That other header, will be converted to another Python module, so I cannot
> just `%include` it (it'll duplicate functionality in both the current, and
> that other module.)
> I tried `%import`'ing it, but no luck.
>
> If you happen to have suggestions, I'm all ears!
>
> Best regards,
>     A.
>
>
>
> On Wed, Feb 19, 2025 at 9:49 AM Arnaud Diederen <ar...@he...>
> wrote:
>
>> Hi,
>>
>> we have a relatively complex system that builds Python bindings on top of
>> a SDK, and SWiG plays an important role early in the chain.
>>
>> An issue that has arisen, is the fact that from the following declaration:
>> ```
>> int something(int foo, int bar=10);
>> ```
>>
>> SWiG will generate a Python function with the following signature:
>> ```
>> def something(*args):
>>      return _module.something(*args)
>> ```
>> …and leave it up to `_module` to perform the dispatch between
>> `_wrap_something__SWIG_0` and `_wrap_something__SWIG_1` (or
>> `_wrap_something` if `compactdefaultargs` is used.)
>>
>> However, this is not really playing nice with the rest of our bindings
>> "build system", because of the presence of `*args`.
>>
>> Something that would work much better for me, is if I could tell SWiG
>> (ideally w/o `%ignore`'ing that function and then re-defining it myself),
>> to simply "drop" the default value.
>> In other words, I'd love it if I could tell SWiG to consider that
>> declaration as if  it were:
>>
>> ```
>> int something(int foo, int bar);
>> ```
>> …and our bindings build system would take it up from here.
>>
>> I realize this is perhaps not the canonical use-case for SWiG, but is
>> there any chance I can achieve that, in a hopefully rather elegant manner?
>>
>> Note: `compactdefaultargs` does not work in this case, because while the
>> default args values are assigned in the generated CPP wrapper code
>> (great!), the Python wrapper itself still has only `*args` (ouch.)
>>
>> Any pointer welcome!
>>
>> Best regards,
>>        A.
>>
>>
>>
>> --
>>
>> Arnaud Diederen
>>
>> Head of Engineering
>>
>> ar...@he... <ste...@he...>
>>
>> +32 472 940 315
>>
>>
>>
>
> --
>
> Arnaud Diederen
>
> Head of Engineering
>
> ar...@he... <ste...@he...>
>
> +32 472 940 315
>
>
>

-- 

Arnaud Diederen

Head of Engineering

ar...@he... <ste...@he...>

+32 472 940 315

Re: [Swig-user] Ignoring default arguments in wrapper generation

[Arnaud D. <ar...@he...>]

Hi again,

I just noticed that my simplified example below, doesn't properly
illustrate the problem.
Indeed, the following:
```
int something(int foo, int bar=10);
```
_will_ be turned into a Python wrapper with proper type annotations &
default value, and that is because `10` is "known" to SWiG.

Let's take the following example instead:
```
int something(int foo, int bar=SOME_DEFINE_COMING_FROM_ANOTHER_HEADER);
```
the problem arises because of `SOME_DEFINE_COMING_FROM_ANOTHER_HEADER`.

That other header, will be converted to another Python module, so I cannot
just `%include` it (it'll duplicate functionality in both the current, and
that other module.)
I tried `%import`'ing it, but no luck.

If you happen to have suggestions, I'm all ears!

Best regards,
    A.



On Wed, Feb 19, 2025 at 9:49 AM Arnaud Diederen <ar...@he...> wrote:

> Hi,
>
> we have a relatively complex system that builds Python bindings on top of
> a SDK, and SWiG plays an important role early in the chain.
>
> An issue that has arisen, is the fact that from the following declaration:
> ```
> int something(int foo, int bar=10);
> ```
>
> SWiG will generate a Python function with the following signature:
> ```
> def something(*args):
>      return _module.something(*args)
> ```
> …and leave it up to `_module` to perform the dispatch between
> `_wrap_something__SWIG_0` and `_wrap_something__SWIG_1` (or
> `_wrap_something` if `compactdefaultargs` is used.)
>
> However, this is not really playing nice with the rest of our bindings
> "build system", because of the presence of `*args`.
>
> Something that would work much better for me, is if I could tell SWiG
> (ideally w/o `%ignore`'ing that function and then re-defining it myself),
> to simply "drop" the default value.
> In other words, I'd love it if I could tell SWiG to consider that
> declaration as if  it were:
>
> ```
> int something(int foo, int bar);
> ```
> …and our bindings build system would take it up from here.
>
> I realize this is perhaps not the canonical use-case for SWiG, but is
> there any chance I can achieve that, in a hopefully rather elegant manner?
>
> Note: `compactdefaultargs` does not work in this case, because while the
> default args values are assigned in the generated CPP wrapper code
> (great!), the Python wrapper itself still has only `*args` (ouch.)
>
> Any pointer welcome!
>
> Best regards,
>        A.
>
>
>
> --
>
> Arnaud Diederen
>
> Head of Engineering
>
> ar...@he... <ste...@he...>
>
> +32 472 940 315
>
>
>

-- 

Arnaud Diederen

Head of Engineering

ar...@he... <ste...@he...>

+32 472 940 315

[Swig-user] Ignoring default arguments in wrapper generation

[Arnaud D. <ar...@he...>]

Hi,

we have a relatively complex system that builds Python bindings on top of a
SDK, and SWiG plays an important role early in the chain.

An issue that has arisen, is the fact that from the following declaration:
```
int something(int foo, int bar=10);
```

SWiG will generate a Python function with the following signature:
```
def something(*args):
     return _module.something(*args)
```
…and leave it up to `_module` to perform the dispatch between
`_wrap_something__SWIG_0` and `_wrap_something__SWIG_1` (or
`_wrap_something` if `compactdefaultargs` is used.)

However, this is not really playing nice with the rest of our bindings
"build system", because of the presence of `*args`.

Something that would work much better for me, is if I could tell SWiG
(ideally w/o `%ignore`'ing that function and then re-defining it myself),
to simply "drop" the default value.
In other words, I'd love it if I could tell SWiG to consider that
declaration as if  it were:

```
int something(int foo, int bar);
```
…and our bindings build system would take it up from here.

I realize this is perhaps not the canonical use-case for SWiG, but is there
any chance I can achieve that, in a hopefully rather elegant manner?

Note: `compactdefaultargs` does not work in this case, because while the
default args values are assigned in the generated CPP wrapper code
(great!), the Python wrapper itself still has only `*args` (ouch.)

Any pointer welcome!

Best regards,
       A.



-- 

Arnaud Diederen

Head of Engineering

ar...@he... <ste...@he...>

+32 472 940 315

Re: [Swig-user] Wrapping long doubles in python

[Ayman H. <aha...@gm...>]

Thanks John,

I tried 4.3.0 and had the exact same problem, I'm using python 3.9 on
windows with visual studio 2022 Community Edition.
Trying python 3.12 produced the same errors (and a few more that I didn't
get to investigate);

Thanks again for your help and hope that helps track down the issue,
-Ayman


On Mon, Feb 3, 2025 at 8:22 AM John Wyatt <jw...@re...> wrote:

> Hello Ayman,
>
> You did not include important info, such as your platform (Windows or
> Mac?), Python and Visual Studio version.
>
> Would you please try 4.3.0 or the git: https://github.com/swig/swig.git
> to see if the issue is on the latest version?
>
> On Thu, Jan 30, 2025 at 5:34 PM Ayman Habib <aha...@gm...> wrote:
>
>> Hello,
>>
>> I'm upgrading the swig version we use from 4.1.1 to 4.2 and running into
>> a problem because of the macro below (it appears in a header file from a
>> third party library that I can't change), but I get the same behavior
>> inserting the line in my .i file:
>>
>> #define MY_PI 3.1415926535897L
>>
>> The resulting python code doesn't compile:
>>
>>   SWIG_Python_SetConstant(d,
>> "MY_PI",SWIG_NewPointerObj(SWIG_as_voidptr(&3.1415926535897),SWIGTYPE_p_long_double,
>> 0 ));
>>
>> The compilation error follows:
>>
>> '&' on constant (C2101 in visual studio).
>>
>> Any suggestions for working around this issue?
>>
>> Thanks,
>> -Ayman
>> _______________________________________________
>> Swig-user mailing list
>> Swi...@li...
>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>
>

Re: [Swig-user] Wrapping long doubles in python

[John W. <jw...@re...>]

Hello Ayman,

You did not include important info, such as your platform (Windows or
Mac?), Python and Visual Studio version.

Would you please try 4.3.0 or the git: https://github.com/swig/swig.git to
see if the issue is on the latest version?

On Thu, Jan 30, 2025 at 5:34 PM Ayman Habib <aha...@gm...> wrote:

> Hello,
>
> I'm upgrading the swig version we use from 4.1.1 to 4.2 and running into a
> problem because of the macro below (it appears in a header file from a
> third party library that I can't change), but I get the same behavior
> inserting the line in my .i file:
>
> #define MY_PI 3.1415926535897L
>
> The resulting python code doesn't compile:
>
>   SWIG_Python_SetConstant(d,
> "MY_PI",SWIG_NewPointerObj(SWIG_as_voidptr(&3.1415926535897),SWIGTYPE_p_long_double,
> 0 ));
>
> The compilation error follows:
>
> '&' on constant (C2101 in visual studio).
>
> Any suggestions for working around this issue?
>
> Thanks,
> -Ayman
> _______________________________________________
> Swig-user mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>

[Swig-user] Wrapping long doubles in python

[Ayman H. <aha...@gm...>]

Hello,

I'm upgrading the swig version we use from 4.1.1 to 4.2 and running into a
problem because of the macro below (it appears in a header file from a
third party library that I can't change), but I get the same behavior
inserting the line in my .i file:

#define MY_PI 3.1415926535897L

The resulting python code doesn't compile:

  SWIG_Python_SetConstant(d,
"MY_PI",SWIG_NewPointerObj(SWIG_as_voidptr(&3.1415926535897),SWIGTYPE_p_long_double,
0 ));

The compilation error follows:

'&' on constant (C2101 in visual studio).

Any suggestions for working around this issue?

Thanks,
-Ayman

[Swig-user] C++ JavaScript Bindings

[Dylan B. <dc...@ut...>]

I need to access C++ bindings via react. I would like to use swig if possible because I need python as well. Is there a way to do this? It seems as if there is no way with the JavaScript modules that swig produces unless I’m missing something?

Thanks 
Dylan 

[Swig-user] How to handle std::vector<char32_t>?

[Siddharth J. <sid...@gm...>]

I am using SWIG to generate JNI code. I have a C++ struct that has a
std::vector<char32_t> in it among other things. can someone show me how to
map this to Java?

struct Foo {
std::vector<char32_t> data;
}

std::vector<Foo> process();

what should the SWIG interface file look like to handle this? thanks.