SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.

SWIG (Simplified Wrapper and Interface Generator)

Version: 4.1.0 (in progress)

Tagline: SWIG is a compiler that integrates C and C++ with languages
         including Perl, Python, Tcl, Ruby, PHP, Java, C#, D, Go, Lua,
         Octave, R, Scheme (Guile, MzScheme/Racket), Scilab, Ocaml.
         SWIG can also export its parse tree into XML.

SWIG reads annotated C/C++ header files and creates wrapper code (glue
code) in order to make the corresponding C/C++ libraries available to
the listed languages, or to extend C/C++ programs with a scripting
language.

Up-to-date SWIG related information can be found at

        http://www.swig.org

A SWIG FAQ and other hints can be found on the SWIG Wiki:

        https://github.com/swig/swig/wiki

License
=======
Please see the LICENSE file for details of the SWIG license. For
further insight into the license including the license of SWIG's
output code, please visit

        http://www.swig.org/legal.html

Release Notes
=============
Please see the CHANGES.current file for a detailed list of bug fixes and
new features for the current release. The CHANGES file contains bug fixes
and new features for older versions. A summary of changes in each release
can be found in the RELEASENOTES file.

Documentation
=============
The Doc/Manual directory contains the most recent set of updated
documentation for this release. The documentation is available in
three different formats, each of which contains identical content.
These format are, pdf (Doc/Manual/SWIGDocumentation.pdf), single
page html (Doc/Manual/SWIGDocumentation.html) or multiple page html
(other files in Doc/Manual). Please select your chosen format and
copy/install to wherever takes your fancy.

There is some technical developer documentation available in the
Doc/Devel subdirectory.  This is not necessarily up-to-date, but it
has some information on SWIG internals.

Documentation is also online at http://www.swig.org/doc.html.

Backwards Compatibility
=======================
The developers strive their best to preserve backwards compatibility
between releases, but this is not always possible as the overriding
aim is to provide the best wrapping experience. Where backwards
compatibility is known to be broken, it is clearly marked as an
incompatibility in the CHANGES and CHANGES.current files.

See the documentation for details of the SWIG_VERSION preprocessor
symbol if you have backward compatibility issues and need to use more
than one version of SWIG.

Installation
============
Please read the Doc/Manual/Preface.html#Preface_installation for
full installation instructions for Windows, Unix and Mac OS X
using the release tarball/zip file. The INSTALL file has generic
build and installation instructions for Unix users.
Users wishing to build and install code from Github should
visit http://swig.org/svn.html to obtain the more detailed
instructions required for building code obtained from Github - extra
steps are required compared to building from the release tarball.

Testing
=======
The typical 'make -k check' can be performed on Unix operating systems.
Please read Doc/Manual/Preface.html#Preface_testing for details.

Examples
========
The Examples directory contains a variety of examples of using SWIG
and it has some browsable documentation.  Simply point your browser to
the file "Example/index.html".

The Examples directory also includes Visual C++ project 6 (.dsp) files for
building some of the examples on Windows. Later versions of Visual Studio
will convert these old style project files into a current solution file.

Known Issues
============
There are minor known bugs, details of which are in the bug tracker, see
http://www.swig.org/bugs.html.

Troubleshooting
===============
In order to operate correctly, SWIG relies upon a set of library
files.  If after building SWIG, you get error messages like this,

    $ swig foo.i
    :1. Unable to find 'swig.swg'
    :3. Unable to find 'tcl8.swg'

it means that SWIG has either been incorrectly configured or
installed.  To fix this:

    1.  Make sure you remembered to do a 'make install' and that
        the installation actually worked.  Make sure you have
        write permission on the install directory.

    2.  If that doesn't work, type 'swig -swiglib' to find out
        where SWIG thinks its library is located.

    3.  If the location is not where you expect, perhaps
        you supplied a bad option to configure.  Use
        ./configure --prefix=pathname to set the SWIG install
        location.   Also, make sure you don't include a shell
        escape character such as ~ when you specify the path.

    4.  The SWIG library can be changed by setting the SWIG_LIB
        environment variable.  However, you really shouldn't
        have to do this.

If you are having other troubles, you might look at the SWIG Wiki at
https://github.com/swig/swig/wiki.

Participate!
============
Please report any errors and submit patches (if possible)!  We only
have access to a limited variety of hardware (Linux, Solaris, OS-X,
and Windows). All contributions help.

If you would like to join the SWIG development team or contribute a
language module to the distribution, please contact the swig-devel
mailing list, details at http://www.swig.org/mail.html.


 -- The SWIG Maintainers

Owner
SWIG
SWIG C/C++ parser code generator
SWIG
Comments
  • Merge doxygen branch

    Merge doxygen branch

    I'd like to merge this branch into master. There is still a lot of work to do here (and I intend to fix at least some bugs), but this seems to be already useful in its current state, i.e. it's better than nothing and doesn't seem to break anything not related to Doxygen (although this remains to be tested, which is another reason for creating this pull request: I hope Travis will do it for me).

  • Prepare SWIG for Node.js v12

    Prepare SWIG for Node.js v12

    This PR replaces all v8::Handle occurrences to v8::Local for all Node.js releases where these both types are the same i.e. v8::Handle is just an alias to v8::Local.

    It also introduces changes for new Node.js v12 related semantics.

    This PR is based on https://github.com/swig/swig/pull/1702.

    Fixes https://github.com/swig/swig/issues/1760, fixes https://github.com/swig/swig/issues/1520

  • [Go] How to call a C++ method from within a Go method on a director?

    [Go] How to call a C++ method from within a Go method on a director?

    Maybe I'm missing something essential here but how do I call a C++ method from within a Go method on a director?

    According to the SWIG documentation (23.4.7) I would assume that this is possible. Quote from the documentation: "The Go code may of course call other methods on itself, and those methods may be defined either in Go or in C++."

    I've created a simple example. The full source can be found here: https://github.com/michael-schaller/go-swig-examples/tree/master/director-example1

    The example is based around this abstract C++ class:

    class Progress
    {
        public:
            Progress(int s) : total_steps(s) { steps_done = 0; };
            virtual ~Progress() {};
    
            void StepDone() { steps_done++; OnStepDone(); };
            float Percent() { return float(steps_done) / float(total_steps) * 100.0; };
            virtual void OnStepDone() = 0;
    
        private:
            int total_steps;
            int steps_done;
    };
    

    If I test this code in C++ I end up with this C++ code:

    class CppProgress : public Progress
    {
        public:
            CppProgress(int s) : Progress(s) {};
            virtual ~CppProgress() {};
    
            virtual void OnStepDone() { printf("Current percent: %f\n", this->Percent()); fflush(stdout); };
    };
    
    void ProgressTest(Progress *p, int steps) {
        for (int step = 0; step < steps; step++) {
            printf("Step %d done.\n", step + 1);
            fflush(stdout);
            p->StepDone();
        }
    }
    

    The output of the C++ test is:

    Step 1 done.
    Current percent: 20.000000
    Step 2 done.
    Current percent: 40.000000
    Step 3 done.
    Current percent: 60.000004
    Step 4 done.
    Current percent: 80.000000
    Step 5 done.
    Current percent: 100.000000
    

    If I try to implement similar Go test code then I wonder how I would access the C++ Percent() method. My example Go code looks like this:

    type GoProgress struct{}
    
    func (p *GoProgress) OnStepDone() {
        // How to call Percent()? Percent is not a method on GoProgress.
        fmt.Printf("Current percent: %f\n", 0.0)
    }
    
    func MakeProgress(steps int) Progress {
        return NewDirectorProgress(&GoProgress{}, steps)
    }
    

    @ianlancetaylor Ian, could you shed some light on this? How can I call a C++ method from within a Go method on a director? Is the documentation wrong or did I miss something essential?

  • What should be the minimum Python version to support in swig-4.0?

    What should be the minimum Python version to support in swig-4.0?

    The swig-3.0.x release supposedly supports python 2.0 and is currently documented:

    SWIG is compatible with most recent Python versions including Python 3.0 and Python 2.6, as well as older versions dating back to Python 2.0. For the best results, consider using Python 2.3 or newer.

    We currently only test for python-2.4 to 3.5.

    One of the aims for the next version of SWIG (3.1) is to vastly reduce the number of options supported for Python wrappers. There are just over 50 command line options and they can be viewed by running swig -python -help. Many of these options only work for newer versions of python and not all the combinations can be tested. Many of the options require newer versions of Python.

    This ticket is an opportunity for SWIG users to express their minimum version required. I would like to start by suggesting that 2.7 should be the minimum version supported as there is still a huge code base that has not moved to python-3 and most 2.x projects can move to 2.7. 2.7 is also a good stepping stone to moving to the very different python-3 world as it has some 3.x features backported into it. If anyone wants support for an older version please say so here and why.

    Lastly we don't know when swig-3.1 will be released. It requires volunteers to implement the necessary changes, so if you are able to help, please say so.

  • Add Node 7.x aka V8 5.2+ support

    Add Node 7.x aka V8 5.2+ support

    • Use WeakCallbackInfo instead of WeakCallbackData
    • Use GetPrivate instead of GetHiddenValue
    • Adopted new signature for SetWeak to support destructor calling
    • SetAccessor deprecation fixed
    • Proper version checks where applicable

    This pull request is similar to the one from @tomleavy (i.e. @arfoll) but with less "hack" (no offence). It also fixes more warnings and resolves the apparent memory leak from not calling destructors. Credits go to the mentioned users for their inspiration.

  • Basic cmake support

    Basic cmake support

    Allows to build swig for example by visual studio users. Does NOT attemps to provide developer support (see the cmake branch) as the tests will likely be kept running by the autotools system.

    see #1039, also #158

  • Segfault in _zval_dtor_func when PHP built with ZTS

    Segfault in _zval_dtor_func when PHP built with ZTS

    A bunch of test in the PHP testsuite fail with an error message "tsrm_ls undefined", if PHP is compiled with zts enabled. The proposed change allows those tests to pass.

  • Updates to lua bindings, part 1.

    Updates to lua bindings, part 1.

    Hi @wsfulton!

    This is first part of updated lua bindings. Main changes:

    1. Class inheritance. Now, instead of merging functions/constants etc from all class bases into its table, class maintains a lua array with SWIG names of its bases. Getter/setter then traverse this list in depth-first manner.
    2. Code refactoring. The main structure was retained, but some code was moved into separate functions and process of generating C-arrays with names of all functions/getters/setters etc was improved. IMHO it is now more understandable and maintainable.
    3. Namespaces now fully supported. Each namespace is treated like a module. Module is just a table in lua. Global namespace becomes main module table, all other namespaces - subtable.
    4. Changes to lang.cxx: original implementations of membervariableHandler set an attribute(flag) "memberget"/"memberset" before calling functionWrapper. I added same thing to variableWrapper, flags are called "varget"/"varset".

    Drawbacks: There were (and still are) options (-elua/-eluac) that make SWIG generate methods/functions arrays in a way that was compatible with embeded lua. The code for this was taken directly from current bindings. Unfortunatelly I have failed to test them. Couldn't find any way to build and setup elua for usual PC. I will try to tackle this problem, but I would like to know your opinion on whether it is acceptable to mark elua support as experimental/use-on-your-own-risk-and-send-us-patches. All I can guarantee now is that elua bindings compile. On the other hand, I have improved elua bindings and in theory they should now pass usual tests.

    Compatibility: New bindings maintains compatibility with previous version - old names are generated by default(verified by tests) A new cmd option was introduced that allows user to enable/disable compatibility.

    Tests: all tests are ok.

    Current state: All changes that were planned for this pull request were implemented. There is some debugging code inside, it is marked with comments '// TODO:REMOVE' in case some further changes will be necessary. And I didn't made any changes to documentation.

    If the idea of the patch is ok with you:

    1. I am ready to fix any issues that may arise and feedback is always welcome
    2. If you give me preliminary approvement of request, I will start updating documentation.

    Patch acts as prerequisite to:

    1. Moving to standard typemaps library. (WIP)
    2. Directors support. (WIP)
  • SWIG support for NodeJS v12

    SWIG support for NodeJS v12

    I understand NodeJS v12 is new, but its release includes changes that break badly even current master of SWIG: https://github.com/nodejs/node/commit/765766be641c747b5bcb4a472801452bd041323f#diff-3c97d28212ec6ec5600be248eb430994R271

    This defines makes v8::Handle not mapped anymore to v8::Local https://github.com/nodejs/node/blob/f0df222e821b0e3f55e8fdb7682d0d8dd9c69117/deps/v8/include/v8.h#L321-L325

    I don't know SWIG codebase nor interactions with V8 API. I can try and hack something, but it might be not as good as one would like to.

  • Fixing python docstring handling for -fastproxy

    Fixing python docstring handling for -fastproxy

    Following up on #721 for some time after the doxygen branch is merged. This standardizes the docstrings generated in the -fastproxy case (and mostly in the -builtin case as well). The required changes were:

    • Saving the unmodified sym:name and params attributes before they are modified and checking for the original versions when building documentation
    • New memberfunction flag to help distinguish between methods and functions when generating documentation in the C files
    • Standardized indentation
  • Comments in %pythoncode damaged

    Comments in %pythoncode damaged

    There's an issue with whitespace handling in the Subversion SWIG bindings which seems to have regressed in SWIG 3.0. This is one way to reproduce, though I think there is a slightly different issue with %extend which may be related. Given input:

    %module foo
    
    %define %bar
    %pythoncode %{
       def one():
          # Comment XXXX
          return 1
    %}
    %enddef
    
    struct TYPE {
    %bar
    };
    

    The output produced is:

    $ grep -5 XXXX foo.py 
        def one():
        mment XXXX
             return 1
    

    The preprocessor trimmed whitespace before the "#" in the comment, and the %pythoncode whitespace adjustment then butchers that code. python.cxx:pythoncode() does not check whether the "initial" whitespace for any given line is actually whitespace, instead it just skips characters.

  • [js] Turn on C++ output for node too

    [js] Turn on C++ output for node too

    Nodejs is like V8 and needs C++ output enabled when wrapping C code.

    The testsuite was masking this bug by using SWIG options -v8 -DBUILDING_NODE_EXTENSION=1 rather than -node when testing with nodejs, while the javascript examples currently all seem to all get processed with -c++.

  • --loglevel=silent: command not found when running `make check`

    --loglevel=silent: command not found when running `make check`

    I must miss a dependency, but can't really see what:

    LDFLAGS="-fsanitize=undefined,address" CFLAGS="-fsanitize=undefined,address -g" CXXFLAGS="-fsanitize=undefined,address" ./configure &> configure.log.txt
    [configure.log.txt](https://github.com/swig/swig/files/10102388/configure.log.txt)
    make && make check -j16
    ...
    checking Examples/lua/class
    /bin/sh: line 1: --loglevel=silent: command not found
    make[3]: *** [../../Makefile:708: javascript_build_cpp] Error 127
    make[2]: *** [../example.mk:29: build] Error 2
    make[2]: Target 'check' not remade because of errors.
    make[1]: *** [Makefile:215: class.actionexample] Error 2
    checking Examples/javascript/constant
    checking Examples/csharp/callback
    checking Examples/guile/constants
    checking errors testcase cpp_bad_global_memberptr
    checking guile testcase abstract_inherit
    checking errors testcase cpp_class_definition
    checking Examples/guile/matrix
    checking Examples/lua/constants
    /bin/sh: line 1: --loglevel=silent: command not found
    make[3]: *** [../../Makefile:708: javascript_build_cpp] Error 127
    make[2]: *** [../example.mk:29: build] Error 2
    make[2]: Target 'check' not remade because of errors.
    make[1]: *** [Makefile:215: constant.actionexample] Error 2
    checking Examples/javascript/enum
    checking Examples/tcl/constants
    checking go testcase go_director_inout (with run test)
    

    Thanks for reply.

  • Rtest3

    Rtest3

    Hallo, this patch should make unittest_sequence more strict, however note that:

    • I had to replace list with c because vectors in R are not exactly lists, therefore comparing vectors (returned by C++) with R lists complicates things a lot
    • I added as.integer because by default numbers are numeric and I guess we want to check the exact type returned by C++ which is integer
    • the first check fails because make_vector_int returns a vector of strings (containing numbers), not integers (in the previous version this test would pass because R does an implicit conversion)

    I hope I got it right,

    Thanks

  • syntax error with c++14 auto without trailing return type

    syntax error with c++14 auto without trailing return type

    Swig 4.0.2 fails to parse the following and other similar variadic template functions. This one uses a fold expression (C++17) I'm not sure if that is the issue.

    namespace teca_variant_array_util
    {
    template <typename TT, typename... PP> 
    auto va_static_cast(PP &&... args)
    {
        return std::make_tuple(static_cast<TT*>(args.get())...);
    }
    }
    

    SWIG reports

    teca_variant_array_util.h:21: Error: Syntax error in input(1).
    

    21 is the opening brace of the function. I'm not trying to wrap this, it's included in the header of a wrapped class. In that context it's easy enough to hide from swig with preprocessor conditions. However, swig probably should probably parse it with out error or perhaps ignore and issue a warning.

  • Suggestion/Question: A way to automate the naming of template instantiations

    Suggestion/Question: A way to automate the naming of template instantiations

    As outlined in https://github.com/swig/swig/issues/2440#issuecomment-1317376852

    If I have lets say a

    template<typename T> class MyContainer;
    

    It would be nice for me to have the option of doing

    %define MyContainer(T)
       %template() MyContainer<T>;
    %enddef
    

    and let swig generate a default name, like MyContainer__$typemap(cstype,T)

    Or if there was a way to stuff the $typemap into %template() myself.

Related tags
A tool for generating cross-language type declarations and interface bindings.

Djinni Djinni is a tool for generating cross-language type declarations and interface bindings. It's designed to connect C++ with either Java or Objec

Nov 29, 2022
Sol3 (sol2 v3.0) - a C++ <-> Lua API wrapper with advanced features and top notch performance - is here, and it's great! Documentation:

sol2 sol2 is a C++ library binding to Lua. It currently supports all Lua versions 5.1+ (LuaJIT 2.0+ and MoonJIT included). sol2 aims to be easy to use

Nov 25, 2022
Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript.

Structy Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript. You can think

Sep 13, 2022
Libraries and examples to support Pimoroni Pico add-ons in C++ and MicroPython.

Pimoroni Pico Libraries and Examples Welcome to the brave new world of Pico! This repository contains the C/C++ and MicroPython libraries for our rang

Nov 24, 2022
Duktape - embeddable Javascript engine with a focus on portability and compact footprint

Duktape ⚠️ Master branch is undergoing incompatible changes for Duktape 3.x. To track Duktape 2.x, follow the v2-maintenance branch. Introduction Dukt

Nov 25, 2022
The missing bridge between Java and native C++

JavaCPP Commercial support: Introduction JavaCPP provides efficient access to native C++ inside Java, not unlike the way some C/C++ compilers interact

Nov 26, 2022
Seamless operability between C++11 and Python
Seamless operability between C++11 and Python

pybind11 — Seamless operability between C++11 and Python Setuptools example • Scikit-build example • CMake example Warning Combining older versions of

Nov 25, 2022
A minimalist and mundane scripting language.

Drift Script A minimalist and mundane scripting language. I like all simple things, simple and beautiful, simple and strong. I know that all developme

Nov 14, 2022
SWIG bindings for raylib (to Lua, and hopefully other languages)

swigraylib SWIG binding for raylib This repo generates raylib bindings to other languages (eg. Lua), by providing a raylib.i SWIG interface file. SWIG

Oct 28, 2021
A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.
A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.

Buck Buck is a build tool. To see what Buck can do for you, check out the documentation at http://buck.build/. Installation Since Buck is used to buil

Nov 25, 2022
Notepad++ is a free source code editor and Notepad replacement that supports several programming languages and natural languages

Npp / Notepad++ is my customized text editor highly enhanced for coding such as insta-run, much more file extensions made self-recognizable, logically colored syntax highlighting for nearly every programming language and designed for very easy customizability -- from the toolbar, context menu, syntax coloring, plug-ins for optional increased capabilities and much more

Jan 23, 2022
High-level interface for low-level programming

Singeli Singeli is now able to compile useful programs to C, but it's very rough around the edges, with poor error reporting. We are beginning to use

Nov 12, 2022
Different Example Programs from different programming languages

Example Programs Don't repeat the same program again. Code Refactoring and Code Cleanup are accepted Name the File According to the Program written in

Jul 16, 2022
Tools and libraries to glue C/C++ APIs to high-level languages

CppSharp is a tool and set of libraries which facilitates the usage of native C/C++ code with the .NET ecosystem. It consumes C/C++ header and library

Nov 23, 2022
GLSL and ESSL are Khronos high-level shading languages.

GLSL GLSL and ESSL are Khronos high-level shading languages. Khronos Registries are available for OpenGL OpenGL ES Vulkan Extension specifications in

Nov 29, 2022
The DirectX Shader Compiler project includes a compiler and related tools used to compile High-Level Shader Language (HLSL) programs into DirectX Intermediate Language (DXIL) representation

DirectX Shader Compiler The DirectX Shader Compiler project includes a compiler and related tools used to compile High-Level Shader Language (HLSL) pr

Nov 24, 2022
A tiny external monitor for PC using STM32 and ST7789. Connects to PC over USB and displays the captured screen on ST7789 (240x240) display.
A tiny external monitor for PC using STM32 and ST7789. Connects to PC over USB and displays the captured screen on ST7789 (240x240) display.

STM32 Tiny Monitor A super tiny monitor for your PC, suitable for your pet ant. A python script sends the captured screen over USB to the STM32 microc

Nov 16, 2022
This is a tool for software engineers to view,record and analyse data(sensor data and module data) In the process of software development.
This is a tool for software engineers to view,record and analyse data(sensor data and module data) In the process of software development.

![Contributors][Huang Jianyu] Statement 由于工具源码在网上公开,除使用部分开源项目代码外,其余代码均来自我个人,工具本身不包含公司的知识产权,所有与公司有关的内容均从软件包中移除,软件发布遵循Apache协议,任何人均可下载进行修改使用,如使用过程中出现任何问

May 5, 2022
Provide translation, currency conversion, and voting services. First using telnet you create a connection to a TCP socket, then the server connects to 3 UDP sockets hosted on other servers to do tasks.

to run micro servers g++ translator.cpp -o translator ./translator <port 1> g++ voting.cpp -o voting ./voting <port 2> g++ currency_converter.cpp -o c

Oct 29, 2021