The Simplified Wrapper and Interface Generator (SWIG) is an open-source software tool used to connect computer programs or libraries written in C or C++ with scripting languages such as Lua, Perl, PHP, Python, R, Ruby, Tcl, and other languages like C#, Java, JavaScript, Go, D, OCaml, Octave, Scilab and Scheme. Output can also be in the form of XML.

Function

The aim is to allow the calling of native functions (that were written in C or C++) by other programming languages, passing complex data types to those functions, keeping memory from being inappropriately freed, inheriting object classes across languages, etc. The programmer writes an interface file containing a list of C/C++ functions to be made visible to an interpreter. SWIG will compile the interface file and generate code in regular C/C++ and the target programming language. SWIG will generate conversion code for functions with simple arguments; conversion code for complex types of arguments must be written by the programmer. The SWIG tool creates source code that provides the glue between C/C++ and the target language. Depending on the language, this glue comes in two forms:

a shared library that an extant interpreter can link to as some form of extension module, or
a shared library that can be linked to other programs compiled in the target language (for example, using Java Native Interface (JNI) in Java).
SWIG is not used for calling interpreted functions by native code; this must be done by the programmer manually.

Example

SWIG wraps simple C declarations by creating an interface that closely matches the way in which the declarations would be used in a C program. For example, consider the following interface file.

In this file, there are two functions sin() and strcmp(), a global variable Foo, and two constants STATUS and VERSION. When SWIG creates an extension module, these declarations are accessible as scripting language functions, variables, and constants respectively. In Python.

Purpose

There are two main reasons to embed a scripting engine in an existing C/C++ program:

• The program can then be customized far faster, via a scripting language instead of C/C++. The scripting engine may even be exposed to the end user, so that they can automate common tasks by writing scripts.
• Even if the final product is not to contain the scripting engine, it may nevertheless be very useful for writing test scripts.

There are several reasons to create dynamic libraries that can be loaded into extant interpreters, including:

• Provide access to a C/C++ library which has no equivalent in the scripting language.
• Write the whole program in the scripting language first, and after profiling, rewrite performance critical code in C or C++.

Specifications

Industry :

Information technology