blob: a12ede5536b4b4a556df4c4dad94c3cca37ff3c3 [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Typemaps</title>
<link rel="stylesheet" type="text/css" href="style.css">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#ffffff">
<H1><a name="Typemaps">14 Typemaps</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="#Typemaps_nn2">Introduction</a>
<ul>
<li><a href="#Typemaps_nn3">Type conversion</a>
<li><a href="#Typemaps_nn4">Typemaps</a>
<li><a href="#Typemaps_nn5">Pattern matching</a>
<li><a href="#Typemaps_nn6">Reusing typemaps</a>
<li><a href="#Typemaps_nn7">What can be done with typemaps?</a>
<li><a href="#Typemaps_nn8">What can't be done with typemaps?</a>
<li><a href="#Typemaps_aspects">Similarities to Aspect Oriented Programming</a>
<li><a href="#Typemaps_nn9">The rest of this chapter</a>
</ul>
<li><a href="#Typemaps_nn10">Typemap specifications</a>
<ul>
<li><a href="#Typemaps_defining">Defining a typemap</a>
<li><a href="#Typemaps_nn12">Typemap scope</a>
<li><a href="#Typemaps_nn13">Copying a typemap</a>
<li><a href="#Typemaps_nn14">Deleting a typemap</a>
<li><a href="#Typemaps_nn15">Placement of typemaps</a>
</ul>
<li><a href="#Typemaps_pattern_matching">Pattern matching rules</a>
<ul>
<li><a href="#Typemaps_nn17">Basic matching rules</a>
<li><a href="#Typemaps_typedef_reductions">Typedef reductions matching</a>
<li><a href="#Typemaps_nn19">Default typemap matching rules</a>
<li><a href="#Typemaps_multi_argument_typemaps_patterns">Multi-arguments typemaps</a>
<li><a href="#Typemaps_matching_template_comparison">Matching rules compared to C++ templates</a>
<li><a href="#Typemaps_debugging_search">Debugging typemap pattern matching</a>
</ul>
<li><a href="#Typemaps_nn21">Code generation rules</a>
<ul>
<li><a href="#Typemaps_nn22">Scope</a>
<li><a href="#Typemaps_nn23">Declaring new local variables</a>
<li><a href="#Typemaps_special_variables">Special variables</a>
<li><a href="#Typemaps_special_variable_macros">Special variable macros</a>
<ul>
<li><a href="#Typemaps_special_macro_descriptor">$descriptor(type)</a>
<li><a href="#Typemaps_special_macro_typemap">$typemap(method, typepattern)</a>
</ul>
<li><a href="#Typemaps_special_variable_attributes">Special variables and typemap attributes</a>
<li><a href="#Typemaps_special_variables_and_macros">Special variables combined with special variable macros</a>
</ul>
<li><a href="#Typemaps_nn25">Common typemap methods</a>
<ul>
<li><a href="#Typemaps_nn26">"in" typemap</a>
<li><a href="#Typemaps_nn27">"typecheck" typemap</a>
<li><a href="#Typemaps_nn28">"out" typemap</a>
<li><a href="#Typemaps_nn29">"arginit" typemap</a>
<li><a href="#Typemaps_nn30">"default" typemap</a>
<li><a href="#Typemaps_nn31">"check" typemap</a>
<li><a href="#Typemaps_nn32">"argout" typemap</a>
<li><a href="#Typemaps_nn33">"freearg" typemap</a>
<li><a href="#Typemaps_nn34">"newfree" typemap</a>
<li><a href="#Typemaps_ret">"ret" typemap</a>
<li><a href="#Typemaps_nn35">"memberin" typemap</a>
<li><a href="#Typemaps_nn36">"varin" typemap</a>
<li><a href="#Typemaps_nn37">"varout" typemap</a>
<li><a href="#Typemaps_throws_typemap">"throws" typemap</a>
</ul>
<li><a href="#Typemaps_nn39">Some typemap examples</a>
<ul>
<li><a href="#Typemaps_nn40">Typemaps for arrays</a>
<li><a href="#Typemaps_nn41">Implementing constraints with typemaps</a>
</ul>
<li><a href="#Typemaps_nn43">Typemaps for multiple target languages</a>
<li><a href="#Typemaps_optimal">Optimal code generation when returning by value</a>
<li><a href="#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a>
<li><a href="#Typemaps_warnings">Typemap warnings</a>
<li><a href="#Typemaps_fragments">Typemap fragments</a>
<ul>
<li><a href="#Typemaps_fragment_type_specialization">Fragment type specialization</a>
<li><a href="#Typemaps_automatic_specialization">Fragments and automatic typemap specialization</a>
</ul>
<li><a href="#Typemaps_runtime_type_checker">The run-time type checker</a>
<ul>
<li><a href="#Typemaps_nn45">Implementation</a>
<li><a href="#Typemaps_runtime_type_checker_usage">Usage</a>
</ul>
<li><a href="#Typemaps_overloading">Typemaps and overloading</a>
<ul>
<li><a href="#Typemaps_typecheck_pointer">SWIG_TYPECHECK_POINTER precedence level and the typecheck typemap</a>
</ul>
<li><a href="#Typemaps_nn48">More about %apply and %clear</a>
<li><a href="#Typemaps_nn47">Passing data between typemaps</a>
<li><a href="#Typemaps_nn52">C++ "this" pointer</a>
<li><a href="#Typemaps_nn51">Where to go for more information?</a>
</ul>
</div>
<!-- INDEX -->
<H2><a name="Typemaps_nn2">14.1 Introduction</a></H2>
<p>
Chances are, you are reading this chapter for one of two reasons; you
either want to customize SWIG's behavior or you overheard someone
mumbling some incomprehensible drivel about "typemaps" and you asked
yourself "typemaps, what are those?" That said, let's start with a
short disclaimer that "typemaps" are an advanced customization feature
that provide direct access to SWIG's low-level code generator. Not
only that, they are an integral part of the SWIG C++ type system (a
non-trivial topic of its own). Typemaps are generally
<em>not</em> a required part of using SWIG. Therefore, you might want
to re-read the earlier chapters if you have found your way to this
chapter with only a vague idea of what SWIG already does by default.
</p>
<H3><a name="Typemaps_nn3">14.1.1 Type conversion</a></H3>
<p>
One of the most important problems in wrapper code generation is the
conversion or marshalling of datatypes between programming languages. Specifically,
for every C/C++ declaration, SWIG must somehow generate wrapper code
that allows values to be passed back and forth between languages.
Since every programming language represents data differently, this is
not a simple of matter of simply linking code together with the
C linker. Instead, SWIG has to know something about how data is
represented in each language and how it can be manipulated.
</p>
<p>
To illustrate, suppose you had a simple C function like this:
</p>
<div class="code">
<pre>
int factorial(int n);
</pre>
</div>
<p>
To access this function from Python, a pair of Python API functions
are used to convert integer values. For example:
</p>
<div class="code">
<pre>
long PyInt_AsLong(PyObject *obj); /* Python --&gt; C */
PyObject *PyInt_FromLong(long x); /* C --&gt; Python */
</pre>
</div>
<p>
The first function is used to convert the input argument from a Python integer object
to C <tt>long</tt>. The second function is used to convert a value from C back into a Python integer object.
</p>
<p>
Inside the wrapper function, you might see these functions used like this:
</p>
<div class="code">
<pre>
PyObject *wrap_factorial(PyObject *self, PyObject *args) {
int arg1;
int result;
PyObject *obj1;
PyObject *resultobj;
if (!PyArg_ParseTuple("O:factorial", &amp;obj1)) return NULL;
<b>arg1 = PyInt_AsLong(obj1);</b>
result = factorial(arg1);
<b>resultobj = PyInt_FromLong(result);</b>
return resultobj;
}
</pre>
</div>
<p>
Every target language supported by SWIG has functions that work in a similar manner. For example, in
Perl, the following functions are used:
</p>
<div class="code">
<pre>
IV SvIV(SV *sv); /* Perl --&gt; C */
void sv_setiv(SV *sv, IV val); /* C --&gt; Perl */
</pre>
</div>
<p>
In Tcl:
</p>
<div class="code">
<pre>
int Tcl_GetLongFromObj(Tcl_Interp *interp, Tcl_Obj *obj, long *value);
Tcl_Obj *Tcl_NewIntObj(long value);
</pre>
</div>
<p>
The precise details are not so important. What is important is that
all of the underlying type conversion is handled by collections of
utility functions and short bits of C code like this---you simply have
to read the extension documentation for your favorite language to know
how it works (an exercise left to the reader).
</p>
<H3><a name="Typemaps_nn4">14.1.2 Typemaps</a></H3>
<p>
Since type handling is so central to wrapper code generation, SWIG
allows it to be completely defined (or redefined) by the user. To do this,
a special <tt>%typemap</tt> directive is used. For example:
</p>
<div class="code">
<pre>
/* Convert from Python --&gt; C */
%typemap(in) int {
$1 = PyInt_AsLong($input);
}
/* Convert from C --&gt; Python */
%typemap(out) int {
$result = PyInt_FromLong($1);
}
</pre>
</div>
<p>
At first glance, this code will look a little confusing.
However, there is really not much to it. The first typemap (the "in"
typemap) is used to convert a value from the target language to C. The second
typemap (the "out" typemap) is used to convert in the other
direction. The content of each typemap is a small fragment of code
that is inserted directly into the SWIG generated wrapper functions.
The code is usually C or C++ code which will be generated into the C/C++ wrapper functions.
Note that this isn't always the case as some target language modules allow target language
code within the typemaps which gets generated into target language specific files.
Within this code, a number of special variables prefixed with a $ are expanded. These are
really just placeholders for C/C++ variables that are generated in the course
of creating the wrapper function. In this case, <tt>$input</tt> refers to an
input object that needs to be converted to C/C++ and <tt>$result</tt>
refers to an object that is going to be returned by a wrapper
function. <tt>$1</tt> refers to a C/C++ variable that has the same type as
specified in the typemap declaration (an <tt>int</tt> in this
example).
</p>
<p>
A short example might make this a little more clear. If you were wrapping a
function like this:
</p>
<div class="code">
<pre>
int gcd(int x, int y);
</pre>
</div>
<p>
A wrapper function would look approximately like this:
</p>
<div class="code">
<pre>
PyObject *wrap_gcd(PyObject *self, PyObject *args) {
int arg1;
int arg2;
int result;
PyObject *obj1;
PyObject *obj2;
PyObject *resultobj;
if (!PyArg_ParseTuple("OO:gcd", &amp;obj1, &amp;obj2)) return NULL;
/* "in" typemap, argument 1 */<b>
{
arg1 = PyInt_AsLong(obj1);
}
</b>
/* "in" typemap, argument 2 */<b>
{
arg2 = PyInt_AsLong(obj2);
}
</b>
result = gcd(arg1, arg2);
/* "out" typemap, return value */<b>
{
resultobj = PyInt_FromLong(result);
}
</b>
return resultobj;
}
</pre>
</div>
<p>
In this code, you can see how the typemap code has been inserted into
the function. You can also see how the special $ variables have been
expanded to match certain variable names inside the wrapper function. This is really the
whole idea behind typemaps--they simply let you insert arbitrary code into different
parts of the generated wrapper functions. Because arbitrary code can be inserted, it
possible to completely change the way in which values are converted.
</p>
<H3><a name="Typemaps_nn5">14.1.3 Pattern matching</a></H3>
<p>
As the name implies, the purpose of a typemap is to "map" C datatypes to
types in the target language. Once a typemap is defined for a C datatype,
it is applied to all future occurrences of that type in the input file. For example:
</p>
<div class="code">
<pre>
/* Convert from Perl --&gt; C */
%typemap(in) <b>int</b> {
$1 = SvIV($input);
}
...
int factorial(<b>int</b> n);
int gcd(<b>int</b> x, <b>int</b> y);
int count(char *s, char *t, <b>int</b> max);
</pre>
</div>
<p>
The matching of typemaps to C datatypes is more than a simple textual match. In fact,
typemaps are fully built into the underlying type system. Therefore, typemaps are
unaffected by <tt>typedef</tt>, namespaces, and other declarations that might hide the
underlying type. For example, you could have code like this:
</p>
<div class="code">
<pre>
/* Convert from Ruby--&gt; C */
%typemap(in) <b>int</b> {
$1 = NUM2INT($input);
}
...
typedef int Integer;
namespace foo {
typedef Integer Number;
};
int foo(<b>int</b> x);
int bar(<b>Integer</b> y);
int spam(<b>foo::Number</b> a, <b>foo::Number</b> b);
</pre>
</div>
<p>
In this case, the typemap is still applied to the proper arguments even though typenames don't always
match the text "int". This ability to track types is a critical part of SWIG--in fact, all
of the target language modules work merely define a family of typemaps for the basic types. Yet, it
is never necessary to write new typemaps for typenames introduced by <tt>typedef</tt>.
</p>
<p>
In addition to tracking typenames, typemaps may also be specialized to match against a specific argument name. For
example, you could write a typemap like this:
</p>
<div class="code">
<pre>
%typemap(in) <b>double nonnegative</b> {
$1 = PyFloat_AsDouble($input);
if ($1 &lt; 0) {
PyErr_SetString(PyExc_ValueError, "argument must be nonnegative.");
SWIG_fail;
}
}
...
double sin(double x);
double cos(double x);
double sqrt(<b>double nonnegative</b>);
typedef double Real;
double log(<b>Real nonnegative</b>);
...
</pre>
</div>
<p>
For certain tasks such as input argument conversion, typemaps can be defined for sequences of
consecutive arguments. For example:
</p>
<div class="code">
<pre>
%typemap(in) (<b>char *str, int len</b>) {
$1 = PyString_AsString($input); /* char *str */
$2 = PyString_Size($input); /* int len */
}
...
int count(<b>char *str, int len</b>, char c);
</pre>
</div>
<p>
In this case, a single input object is expanded into a pair of C arguments. This example also
provides a hint to the unusual variable naming scheme involving <tt>$1</tt>, <tt>$2</tt>, and so forth.
</p>
<H3><a name="Typemaps_nn6">14.1.4 Reusing typemaps</a></H3>
<p>
Typemaps are normally defined for specific type and argument name patterns. However, typemaps can also
be copied and reused. One way to do this is to use assignment like this:
</p>
<div class="code">
<pre>
%typemap(in) Integer = int;
%typemap(in) (char *buffer, int size) = (char *str, int len);
</pre>
</div>
<p>
There is a more powerful way to copy a family of typemaps though.
Consider the following family of two typemap methods, "in" and "out" for type <tt>int</tt>:
</p>
<div class="code">
<pre>
%typemap(in) int {
/* Convert an integer argument */
...
}
%typemap(out) int {
/* Return an integer value */
...
}
</pre>
</div>
<p>
Each of the two typemap methods could be copied individually for type <tt>size_t</tt> as follows:
</p>
<div class="code">
<pre>
/* Apply all of the int typemaps to size_t */
%typemap(in) size_t = int;
%typemap(out) size_t = int;
</pre>
</div>
<p>
A more powerful form of copying is available from the <tt>%apply</tt> directive.
The code below is identical to the above:
</p>
<div class="code">
<pre>
/* Apply all of the int typemaps to size_t */
%apply int { size_t };
</pre>
</div>
<p>
<tt>%apply</tt> merely takes <em>all</em> of the typemaps that are defined for one type and
applies them to other types. Note: you can include a comma separated set of types in the
<tt>{ ... }</tt> part of <tt>%apply</tt>.
</p>
<p>
It should be noted that it is not necessary to copy typemaps for types that are related by <tt>typedef</tt>.
For example, if you have this,
</p>
<div class="code">
<pre>
typedef int size_t;
</pre>
</div>
<p>
then SWIG already knows that the <tt>int</tt> typemaps apply. You don't have to do anything.
</p>
<H3><a name="Typemaps_nn7">14.1.5 What can be done with typemaps?</a></H3>
<p>
The primary use of typemaps is for defining wrapper generation behavior at the level
of individual C/C++ datatypes. There are currently six general categories of problems that
typemaps address:
</p>
<p>
<b>Argument handling</b>
</p>
<div class="code">
<pre>
int foo(<b>int x, double y, char *s</b>);
</pre>
</div>
<ul>
<li>Input argument conversion ("in" typemap).</li>
<li>Input argument type checking for types used in overloaded methods ("typecheck" typemap).</li>
<li>Output argument handling ("argout" typemap).</li>
<li>Input argument value checking ("check" typemap).</li>
<li>Input argument initialization ("arginit" typemap).</li>
<li>Default arguments ("default" typemap).</li>
<li>Input argument resource management ("freearg" typemap).</li>
</ul>
<p>
<b>Return value handling</b>
</p>
<div class="code">
<pre>
<b>int</b> foo(int x, double y, char *s);
</pre>
</div>
<ul>
<li>Function return value conversion ("out" typemap).</li>
<li>Return value resource management ("ret" typemap).</li>
<li>Resource management for newly allocated objects ("newfree" typemap).</li>
</ul>
<p>
<b>Exception handling</b>
</p>
<div class="code">
<pre>
<b>int</b> foo(int x, double y, char *s) throw(<b>MemoryError, IndexError</b>);
</pre>
</div>
<ul>
<li>Handling of C++ exception specifications. ("throw" typemap).</li>
</ul>
<p>
<b>Global variables</b>
</p>
<div class="code">
<pre>
<b>int foo;</b>
</pre>
</div>
<ul>
<li>Assignment of a global variable. ("varin" typemap).</li>
<li>Reading a global variable. ("varout" typemap).</li>
</ul>
<p>
<b>Member variables</b>
</p>
<div class="code">
<pre>
struct Foo {
<b>int x[20]</b>;
};
</pre>
</div>
<ul>
<li>Assignment of data to a class/structure member. ("memberin" typemap).</li>
</ul>
<p>
<b>Constant creation</b>
</p>
<div class="code">
<pre>
#define FOO 3
%constant int BAR = 42;
enum { ALE, LAGER, STOUT };
</pre>
</div>
<ul>
<li>Creation of constant values. ("consttab" or "constcode" typemap).</li>
</ul>
<p>
Details of each of these typemaps will be covered shortly. Also, certain language modules may define additional
typemaps that expand upon this list. For example, the Java module defines a variety of typemaps for controlling additional
aspects of the Java bindings. Consult language specific documentation for further details.
</p>
<H3><a name="Typemaps_nn8">14.1.6 What can't be done with typemaps?</a></H3>
<p>
Typemaps can't be used to define properties that apply to C/C++ declarations as a whole. For example,
suppose you had a declaration like this,
</p>
<div class="code">
<pre>
Foo *make_Foo(int n);
</pre>
</div>
<p>
and you wanted to tell SWIG that <tt>make_Foo(int n)</tt> returned a newly
allocated object (for the purposes of providing better memory
management). Clearly, this property of <tt>make_Foo(int n)</tt> is
<em>not</em> a property that would be associated with the datatype
<tt>Foo *</tt> by itself. Therefore, a completely different SWIG
customization mechanism (<tt>%feature</tt>) is used for this purpose. Consult the <a
href="Customization.html#Customization">Customization Features</a> chapter for more
information about that.
</p>
<p>
Typemaps also can't be used to rearrange or transform the order of arguments. For example,
if you had a function like this:
</p>
<div class="code">
<pre>
void foo(int, char *);
</pre>
</div>
<p>
you can't use typemaps to interchange the arguments, allowing you to call the
function like this:
</p>
<div class="targetlang">
<pre>
foo("hello", 3) # Reversed arguments
</pre>
</div>
<p>
If you want to change the calling conventions of a function, write a helper
function instead. For example:
</p>
<div class="code">
<pre>
%rename(foo) wrap_foo;
%inline %{
void wrap_foo(char *s, int x) {
foo(x, s);
}
%}
</pre>
</div>
<H3><a name="Typemaps_aspects">14.1.7 Similarities to Aspect Oriented Programming</a></H3>
<p>
SWIG has parallels to <a href="https://en.wikipedia.org/wiki/Aspect-oriented_programming">Aspect Oriented Software Development (AOP)</a>.
The <a href="https://en.wikipedia.org/wiki/Aspect-oriented_programming#Terminology">AOP terminology</a> with respect to SWIG typemaps can be viewed as follows:
</p>
<ul>
<li> <b>Cross-cutting concerns</b>: The cross-cutting concerns are the modularization of the functionality that the typemaps implement, which is primarily marshalling of types from/to the target language and C/C++.
<li> <b>Advice</b>: The typemap body contains code which is executed whenever the marshalling is required.
<li> <b>Pointcut</b>: The pointcuts are the positions in the wrapper code that the typemap code is generated into.
<li> <b>Aspect</b>: Aspects are the combination of the pointcut and the advice, hence each typemap is an aspect.
</ul>
<p>
SWIG can also be viewed as has having a second set of aspects based around <a href="Customization.html#Customization">%feature</a>.
Features such as <tt>%exception</tt> are also cross-cutting concerns as they encapsulate code that can be used to add logging or exception handling to any function.
</p>
<H3><a name="Typemaps_nn9">14.1.8 The rest of this chapter</a></H3>
<p>
The rest of this chapter provides detailed information for people who
want to write new typemaps. This information is of particular importance to anyone
who intends to write a new SWIG target language module. Power users can also
use this information to write application specific type conversion rules.
</p>
<p>
Since typemaps are strongly tied to the underlying C++ type system,
subsequent sections assume that you are reasonably familiar with the
basic details of values, pointers, references, arrays, type qualifiers
(e.g., <tt>const</tt>), structures, namespaces, templates, and memory
management in C/C++. If not, you would be well-advised to consult a copy
of "The C Programming Language" by Kernighan and Ritchie or
"The C++ Programming Language" by Stroustrup before going any further.
</p>
<H2><a name="Typemaps_nn10">14.2 Typemap specifications</a></H2>
<p>
This section describes the behavior of the <tt>%typemap</tt> directive itself.
</p>
<H3><a name="Typemaps_defining">14.2.1 Defining a typemap</a></H3>
<p>
New typemaps are defined using the <tt>%typemap</tt> declaration. The general form of
this declaration is as follows (parts enclosed in [ ... ] are optional):
</p>
<div class="code">
<pre>
%typemap(<em>method</em> [, <em>modifiers</em>]) <em>typelist</em> <em>code</em> ;
</pre>
</div>
<p>
<em>method</em> is a simply a name that specifies what kind of typemap is being defined. It
is usually a name like <tt>"in"</tt>, <tt>"out"</tt>, or <tt>"argout"</tt>. The purpose of
these methods is described later.
</p>
<p>
<em>modifiers</em> is an optional comma separated list of <tt>name="value"</tt> values.
These are sometimes to attach extra information to a typemap and is often target-language dependent.
They are also known as typemap attributes.
</p>
<p>
<em>typelist</em> is a list of the C++ type patterns that the typemap will match. The general form of
this list is as follows:
</p>
<div class="diagram">
<pre>
typelist : typepattern [, typepattern, typepattern, ... ] ;
typepattern : type [ (parms) ]
| type name [ (parms) ]
| ( typelist ) [ (parms) ]
</pre>
</div>
<p>
Each type pattern is either a simple type, a simple type and argument name, or a list of types in the
case of multi-argument typemaps. In addition, each type pattern can be parameterized with a list of temporary
variables (parms). The purpose of these variables will be explained shortly.
</p>
<p><em>code</em> specifies the code used in the typemap.
Usually this is C/C++ code, but in the statically typed target languages, such as Java and C#, this can contain target language code for certain typemaps.
It can take any one of the following forms:
</p>
<div class="diagram">
<pre>
code : { ... }
| " ... "
| %{ ... %}
</pre>
</div>
<p>
Note that the preprocessor will expand code within the {} delimiters, but not in the last two styles of delimiters,
see <a href="Preprocessor.html#Preprocessor_delimiters">Preprocessor and Typemaps</a>.
Here are some examples of valid typemap specifications:
</p>
<div class="code">
<pre>
/* Simple typemap declarations */
%typemap(in) int {
$1 = PyInt_AsLong($input);
}
%typemap(in) int "$1 = PyInt_AsLong($input);";
%typemap(in) int %{
$1 = PyInt_AsLong($input);
%}
/* Typemap with extra argument name */
%typemap(in) int nonnegative {
...
}
/* Multiple types in one typemap */
%typemap(in) int, short, long {
$1 = SvIV($input);
}
/* Typemap with modifiers */
%typemap(in, doc="integer") int "$1 = scm_to_int($input);";
/* Typemap applied to patterns of multiple arguments */
%typemap(in) (char *str, int len),
(char *buffer, int size)
{
$1 = PyString_AsString($input);
$2 = PyString_Size($input);
}
/* Typemap with extra pattern parameters */
%typemap(in, numinputs=0) int *output (int temp),
long *output (long temp)
{
$1 = &amp;temp;
}
</pre>
</div>
<p>
Admittedly, it's not the most readable syntax at first glance. However, the purpose of the
individual pieces will become clear.
</p>
<H3><a name="Typemaps_nn12">14.2.2 Typemap scope</a></H3>
<p>
Once defined, a typemap remains in effect for all of the declarations that follow. A typemap may be redefined for
different sections of an input file. For example:
</p>
<div class="code">
<pre>
// typemap1
%typemap(in) int {
...
}
int fact(int); // typemap1
int gcd(int x, int y); // typemap1
// typemap2
%typemap(in) int {
...
}
int isprime(int); // typemap2
</pre>
</div>
<p>
One exception to the typemap scoping rules pertains to the <tt>%extend</tt> declaration. <tt>%extend</tt> is used to attach
new declarations to a class or structure definition. Because of this, all of the declarations in an <tt>%extend</tt> block are
subject to the typemap rules that are in effect at the point where the class itself is defined. For example:
</p>
<div class="code">
<pre>
class Foo {
...
};
%typemap(in) int {
...
}
%extend Foo {
int blah(int x); // typemap has no effect. Declaration is attached to Foo which
// appears before the %typemap declaration.
};
</pre>
</div>
<H3><a name="Typemaps_nn13">14.2.3 Copying a typemap</a></H3>
<p>
A typemap is copied by using assignment. For example:
</p>
<div class="code">
<pre>
%typemap(in) Integer = int;
</pre>
</div>
<p>
or this:
</p>
<div class="code">
<pre>
%typemap(in) Integer, Number, int32_t = int;
</pre>
</div>
<p>
Types are often managed by a collection of different typemaps. For example:
</p>
<div class="code">
<pre>
%typemap(in) int { ... }
%typemap(out) int { ... }
%typemap(varin) int { ... }
%typemap(varout) int { ... }
</pre>
</div>
<p>
To copy all of these typemaps to a new type, use <tt>%apply</tt>. For example:
</p>
<div class="code">
<pre>
%apply int { Integer }; // Copy all int typemaps to Integer
%apply int { Integer, Number }; // Copy all int typemaps to both Integer and Number
</pre>
</div>
<p>
The patterns for <tt>%apply</tt> follow the same rules as for <tt>%typemap</tt>. For example:
</p>
<div class="code">
<pre>
%apply int *output { Integer *output }; // Typemap with name
%apply (char *buf, int len) { (char *buffer, int size) }; // Multiple arguments
</pre>
</div>
<H3><a name="Typemaps_nn14">14.2.4 Deleting a typemap</a></H3>
<p>
A particular typemap can be deleted / cleared by simply defining no code. For example:
</p>
<div class="code">
<pre>
%typemap(in) int; // Clears the "in" typemap for int
%typemap(in) int, long, short; // Clears the "in" typemap for int, long, short
%typemap(in) int *output;
</pre>
</div>
<p>
The above syntax deletes a typemap for just one typemap method - the "in" method in each of the examples above.
The <tt>%clear</tt> directive is more powerful and will delete / clear a family of typemaps, that is, all the typemap methods for a given type.
For example:
</p>
<div class="code">
<pre>
%clear int; // Delete all typemaps ("in", "out", "varin", ...) for int
%clear int *output, long *output;
</pre>
</div>
<p>
<b>Note:</b> Since SWIG's default behavior is defined by typemaps, clearing a fundamental type like
<tt>int</tt> will make that type unusable unless you also define a new family of typemaps immediately
after the clear operation.
</p>
<H3><a name="Typemaps_nn15">14.2.5 Placement of typemaps</a></H3>
<p>
Typemap declarations can be declared in the global scope, within a C++ namespace, and within a C++ class. For
example:
</p>
<div class="code">
<pre>
%typemap(in) int {
...
}
namespace std {
class string;
%typemap(in) string {
...
}
}
class Bar {
public:
typedef const int &amp; const_reference;
%typemap(out) const_reference {
...
}
};
</pre>
</div>
<p>
When a typemap appears inside a namespace or class, it stays in effect until the end of the SWIG input
(just like before). However, the typemap takes the local scope into account. Therefore, this
code
</p>
<div class="code">
<pre>
namespace std {
class string;
%typemap(in) string {
...
}
}
</pre>
</div>
<p>
is really defining a typemap for the type <tt>std::string</tt>. You could have code like this:
</p>
<div class="code">
<pre>
namespace std {
class string;
%typemap(in) string { /* std::string */
...
}
}
namespace Foo {
class string;
%typemap(in) string { /* Foo::string */
...
}
}
</pre>
</div>
<p>
In this case, there are two completely distinct typemaps that apply to two completely different
types (<tt>std::string</tt> and <tt>Foo::string</tt>).
</p>
<p>
It should be noted that for scoping to work, SWIG has to know that <tt>string</tt> is a typename defined
within a particular namespace. In this example, this is done using the forward class declaration <tt>class string</tt>.
</p>
<H2><a name="Typemaps_pattern_matching">14.3 Pattern matching rules</a></H2>
<p>
The section describes the pattern matching rules by which C/C++ datatypes are associated with typemaps.
The matching rules can be observed in practice by using the debugging options also described.
</p>
<H3><a name="Typemaps_nn17">14.3.1 Basic matching rules</a></H3>
<p>
Typemaps are matched using both a type and a name (typically the name of a argument). For a given
<tt>TYPE NAME</tt> pair, the following rules are applied, in order, to find a match. The first typemap found
is used.
</p>
<ul>
<li>Typemaps that exactly match <tt>TYPE</tt> and <tt>NAME</tt>.
<li>Typemaps that exactly match <tt>TYPE</tt> only.
<li>If <tt>TYPE</tt> is a C++ template of type <tt>T&lt; TPARMS &gt;</tt>, where <tt>TPARMS</tt> are the template parameters,
the type is stripped of the template parameters and the following checks are then made:
<ul>
<li>Typemaps that exactly match <tt>T</tt> and <tt>NAME</tt>.
<li>Typemaps that exactly match <tt>T</tt> only.
</ul>
</ul>
<p>
If <tt>TYPE</tt> includes qualifiers (const, volatile, etc.), each qualifier is stripped one at a time to form a new stripped type
and the matching rules above are repeated on the stripped type.
The left-most qualifier is stripped first, resulting in the right-most (or top-level) qualifier being stripped last.
For example <tt>int const*const</tt> is first stripped to <tt>int *const</tt> then <tt>int *</tt>.
</p>
<p>
If <tt>TYPE</tt> is an array. The following transformation is made:
</p>
<ul>
<li>Replace all dimensions to <tt>[ANY]</tt> and look for a generic array typemap.
</ul>
<p>
To illustrate, suppose that you had a function like this:
</p>
<div class="code">
<pre>
int foo(const char *s);
</pre>
</div>
<p>
To find a typemap for the argument <tt>const char *s</tt>, SWIG will search for the following typemaps:
</p>
<div class="diagram">
<pre>
const char *s Exact type and name match
const char * Exact type match
char *s Type and name match (qualifier stripped)
char * Type match (qualifier stripped)
</pre>
</div>
<p>
When more than one typemap rule might be defined, only the first match
found is actually used. Here is an example that
shows how some of the basic rules are applied:
</p>
<div class="code"><pre>
%typemap(in) int *x {
... typemap 1
}
%typemap(in) int * {
... typemap 2
}
%typemap(in) const int *z {
... typemap 3
}
%typemap(in) int [4] {
... typemap 4
}
%typemap(in) int [ANY] {
... typemap 5
}
void A(int *x); // int *x rule (typemap 1)
void B(int *y); // int * rule (typemap 2)
void C(const int *x); // int *x rule (typemap 1)
void D(const int *z); // const int *z rule (typemap 3)
void E(int x[4]); // int [4] rule (typemap 4)
void F(int x[1000]); // int [ANY] rule (typemap 5)
</pre>
</div>
<p>
<b>Compatibility note: </b> SWIG-2.0.0 introduced stripping the qualifiers one step at a time. Prior versions
stripped all qualifiers in one step.
</p>
<H3><a name="Typemaps_typedef_reductions">14.3.2 Typedef reductions matching</a></H3>
<p>
If no match is found using the rules in the previous section, SWIG
applies a typedef reduction to the type and repeats the typemap search
for the reduced type. To illustrate, suppose you had code like this:
</p>
<div class="code">
<pre>
%typemap(in) int {
... typemap 1
}
typedef int Integer;
void blah(Integer x);
</pre>
</div>
<p>
To find the typemap for <tt>Integer x</tt>, SWIG will first search for the following
typemaps:
</p>
<div class="diagram">
<pre>
Integer x
Integer
</pre>
</div>
<p>
Finding no match, it then applies a reduction <tt>Integer -&gt; int</tt> to the type and
repeats the search.
</p>
<div class="diagram">
<pre>
int x
int --&gt; match: typemap 1
</pre>
</div>
<p>
Even though two types might be the same via typedef, SWIG allows typemaps to be defined
for each typename independently. This allows for interesting customization possibilities based
solely on the typename itself. For example, you could write code like this:
</p>
<div class="code">
<pre>
typedef double pdouble; // Positive double
// typemap 1
%typemap(in) double {
... get a double ...
}
// typemap 2
%typemap(in) pdouble {
... get a positive double ...
}
double sin(double x); // typemap 1
pdouble sqrt(pdouble x); // typemap 2
</pre>
</div>
<p>
When reducing the type, only one typedef reduction is applied at a
time. The search process continues to apply reductions until a
match is found or until no more reductions can be made.
</p>
<p>
For complicated types, the reduction process can generate a long list of patterns. Consider the following:
</p>
<div class="code">
<pre>
typedef int Integer;
typedef Integer Row4[4];
void foo(Row4 rows[10]);
</pre>
</div>
<p>
To find a match for the <tt>Row4 rows[10]</tt> argument, SWIG would
check the following patterns, stopping only when it found a match:
</p>
<div class="code">
<pre>
Row4 rows[10]
Row4 [10]
Row4 rows[ANY]
Row4 [ANY]
# Reduce Row4 --&gt; Integer[4]
Integer rows[10][4]
Integer [10][4]
Integer rows[ANY][ANY]
Integer [ANY][ANY]
# Reduce Integer --&gt; int
int rows[10][4]
int [10][4]
int rows[ANY][ANY]
int [ANY][ANY]
</pre>
</div>
<p>
For parameterized types like templates, the situation is even more complicated. Suppose you had some declarations
like this:
</p>
<div class="code">
<pre>
typedef int Integer;
typedef foo&lt;Integer, Integer&gt; fooii;
void blah(fooii *x);
</pre>
</div>
<p>
In this case, the following typemap patterns are searched for the argument <tt>fooii *x</tt>:
</p>
<div class="code">
<pre>
fooii *x
fooii *
# Reduce fooii --&gt; foo&lt;Integer, Integer&gt;
foo&lt;Integer, Integer&gt; *x
foo&lt;Integer, Integer&gt; *
# Reduce Integer -&gt; int
foo&lt;int, Integer&gt; *x
foo&lt;int, Integer&gt; *
# Reduce Integer -&gt; int
foo&lt;int, int&gt; *x
foo&lt;int, int&gt; *
</pre>
</div>
<p>
Typemap reductions are always applied to the left-most type that appears. Only when no reductions can be made to the left-most
type are reductions made to other parts of the type. This behavior means that you could define a typemap for
<tt>foo&lt;int, Integer&gt;</tt>, but a typemap for <tt>foo&lt;Integer, int&gt;</tt> would never be matched. Admittedly, this
is rather esoteric--there's little practical reason to write a typemap quite like that. Of course, you could rely on this
to confuse your coworkers even more.
</p>
<p>
As a point of clarification, it is worth emphasizing that typedef matching is a typedef <b>reduction</b> process only, that is, SWIG does not search for every single possible typedef.
Given a type in a declaration, it will only reduce the type, it won't build it up looking for typedefs.
For example, given the type <tt>Struct</tt>, the typemap below will not be used for the <tt>aStruct</tt> parameter,
because <tt>Struct</tt> is fully reduced:
</p>
<div class="code">
<pre>
struct Struct {...};
typedef Struct StructTypedef;
%typemap(in) StructTypedef {
...
}
void go(Struct aStruct);
</pre>
</div>
<H3><a name="Typemaps_nn19">14.3.3 Default typemap matching rules</a></H3>
<p>
If the basic pattern matching rules result in no match being made, even after typedef reductions,
the default typemap matching rules are used to look for a suitable typemap match.
These rules match a generic typemap based on the reserved <tt>SWIGTYPE</tt> base type.
For example pointers will use <tt>SWIGTYPE *</tt> and references will use <tt>SWIGTYPE &amp;</tt>.
More precisely, the rules are based on the C++ class template partial specialization matching rules used
by C++ compilers when looking for an appropriate partial template specialization.
This means that a match is chosen from the most specialized set of generic typemap types available. For example,
when looking for a match to <tt>int const *</tt>, the rules will prefer to match <tt>SWIGTYPE const *</tt>
if available before matching <tt>SWIGTYPE *</tt>, before matching <tt>SWIGTYPE</tt>.
</p>
<p>
Most SWIG language modules use typemaps to define the default behavior of the C primitive types. This
is entirely straightforward. For example, a set of typemaps for primitives marshalled by value or
const reference are written like this:
</p>
<div class="code">
<pre>
%typemap(in) int "... convert to int ...";
%typemap(in) short "... convert to short ...";
%typemap(in) float "... convert to float ...";
...
%typemap(in) const int &amp; "... convert ...";
%typemap(in) const short &amp; "... convert ...";
%typemap(in) const float &amp; "... convert ...";
...
</pre>
</div>
<p>
Since typemap matching follows all <tt>typedef</tt> declarations, any sort of type that is
mapped to a primitive type by value or const reference through <tt>typedef</tt> will be picked
up by one of these primitive typemaps.
Most language modules also define typemaps for char pointers and char arrays to handle strings,
so these non-default types will also be used in preference as the basic typemap matching rules
provide a better match than the default typemap matching rules.
</p>
<p>
Below is a list of the typical default types supplied by language modules, showing what the "in" typemap would look like:
</p>
<div class="code">
<pre>
%typemap(in) SWIGTYPE &amp; { ... default reference handling ... };
%typemap(in) SWIGTYPE * { ... default pointer handling ... };
%typemap(in) SWIGTYPE *const { ... default pointer const handling ... };
%typemap(in) SWIGTYPE *const&amp; { ... default pointer const reference handling ... };
%typemap(in) SWIGTYPE[ANY] { ... 1D fixed size arrays handling ... };
%typemap(in) SWIGTYPE [] { ... unknown sized array handling ... };
%typemap(in) enum SWIGTYPE { ... default handling for enum values ... };
%typemap(in) const enum SWIGTYPE &amp; { ... default handling for const enum reference values ... };
%typemap(in) SWIGTYPE (CLASS::*) { ... default pointer member handling ... };
%typemap(in) SWIGTYPE { ... simple default handling ... };
</pre>
</div>
<p>
If you wanted to change SWIG's default handling for
simple pointers, you would simply redefine the rule for <tt>SWIGTYPE *</tt>.
Note, the simple default typemap rule is used to match against simple types that don't match any other rules:
</p>
<div class="code">
<pre>
%typemap(in) SWIGTYPE { ... simple default handling ... }
</pre>
</div>
<p>
This typemap is important because it is the rule that gets triggered
when call or return by value is used. For instance, if you have a
declaration like this:
</p>
<div class="code">
<pre>
double dot_product(Vector a, Vector b);
</pre>
</div>
<p>
The <tt>Vector</tt> type will usually just get matched against
<tt>SWIGTYPE</tt>. The default implementation of <tt>SWIGTYPE</tt> is
to convert the value into pointers (<a href="SWIG.html#SWIG_nn22">as described in this earlier section</a>).
</p>
<p>
By redefining <tt>SWIGTYPE</tt> it may be possible to implement other
behavior. For example, if you cleared all typemaps for
<tt>SWIGTYPE</tt>, SWIG simply won't wrap any unknown datatype (which might
be useful for debugging). Alternatively, you might modify SWIGTYPE to marshal
objects into strings instead of converting them to pointers.
</p>
<p>
Let's consider an example where the following typemaps are defined and SWIG is looking for the best match for the enum shown below:
</p>
<div class="code">
<pre>
%typemap(in) const Hello &amp; { ... }
%typemap(in) const enum SWIGTYPE &amp; { ... }
%typemap(in) enum SWIGTYPE &amp; { ... }
%typemap(in) SWIGTYPE &amp; { ... }
%typemap(in) SWIGTYPE { ... }
enum Hello {};
const Hello &amp;hi;
</pre>
</div>
<p>
The typemap at the top of the list will be chosen, not because it is defined first, but because it is the closest match for the type being wrapped.
If any of the typemaps in the above list were not defined, then the next one on the list would have precedence.
</p>
<p>
The best way to explore the default typemaps is to look at the ones
already defined for a particular language module. Typemap
definitions are usually found in the SWIG library in a file such as
<tt>java.swg</tt>, <tt>csharp.swg</tt> etc.
However, for many of the target languages the typemaps are hidden behind complicated macros,
so the best way to view the default typemaps, or any typemaps for that matter,
is to look at the preprocessed output by running <tt>swig -E</tt> on any interface file.
Finally the best way to view the typemap matching rules in action is via the <a href="#Typemaps_debugging_search">debugging typemap pattern matching</a> options covered later on.
</p>
<p>
<b>Compatibility note: </b> The default typemap matching rules were modified in SWIG-2.0.0 from a slightly
simpler scheme to match the current C++ class template partial specialization matching rules.
</p>
<H3><a name="Typemaps_multi_argument_typemaps_patterns">14.3.4 Multi-arguments typemaps</a></H3>
<p>
When multi-argument typemaps are specified, they take precedence over
any typemaps specified for a single type. For example:
</p>
<div class="code">
<pre>
%typemap(in) (char *buffer, int len) {
// typemap 1
}
%typemap(in) char *buffer {
// typemap 2
}
void foo(char *buffer, int len, int count); // (char *buffer, int len)
void bar(char *buffer, int blah); // char *buffer
</pre>
</div>
<p>
Multi-argument typemaps are also more restrictive in the way that they are matched.
Currently, the first argument follows the matching rules described in the previous section,
but all subsequent arguments must match exactly.
</p>
<H3><a name="Typemaps_matching_template_comparison">14.3.5 Matching rules compared to C++ templates</a></H3>
<p>
For those intimately familiar with C++ templates, a comparison of the typemap matching rules and template type deduction is interesting.
The two areas considered are firstly the default typemaps and their similarities to partial template specialization and secondly, non-default typemaps and their similarities to full template specialization.
</p>
<p>
For default (SWIGTYPE) typemaps the rules are inspired by C++ class template
partial specialization. For example, given partial specialization for <tt>T const&amp;</tt> :
</p>
<div class="code">
<pre>
template &lt;typename T&gt; struct X { void a(); };
template &lt;typename T&gt; struct X&lt; T const&amp; &gt; { void b(); };
</pre>
</div>
<p>
The full (unspecialized) template is matched with most types, such as:
</p>
<div class="code">
<pre>
X&lt; int &amp; &gt; x1; x1.a();
</pre>
</div>
<p>
and the following all match the <tt>T const&amp;</tt> partial specialization:
</p>
<div class="code">
<pre>
X&lt; int *const&amp; &gt; x2; x2.b();
X&lt; int const*const&amp; &gt; x3; x3.b();
X&lt; int const&amp; &gt; x4; x4.b();
</pre>
</div>
<p>
Now, given just these two default typemaps, where T is analogous to SWIGTYPE:
</p>
<div class="code">
<pre>
%typemap(...) SWIGTYPE { ... }
%typemap(...) SWIGTYPE const&amp; { ... }
</pre>
</div>
<p>
The generic default typemap <tt>SWIGTYPE</tt> is used with most types, such as
</p>
<div class="code">
<pre>
int &amp;
</pre>
</div>
<p>
and the following all match the <tt>SWIGTYPE const&amp;</tt> typemap, just like the partial template matching:
</p>
<div class="code">
<pre>
int *const&amp;
int const*const&amp;
int const&amp;
</pre>
</div>
<p>
Note that the template and typemap matching rules are not identical for all default typemaps though, for example, with arrays.
</p>
<p>
For non-default typemaps, one might expect SWIG to follow the fully specialized template rules.
This is nearly the case, but not quite.
Consider a very similar example to the earlier partially specialized template but this time there is a fully specialized template:
</p>
<div class="code">
<pre>
template &lt;typename T&gt; struct Y { void a(); };
template &lt;&gt; struct Y&lt; int const &amp; &gt; { void b(); };
</pre>
</div>
<p>
Only the one type matches the specialized template exactly:
</p>
<div class="code">
<pre>
Y&lt; int &amp; &gt; y1; y1.a();
Y&lt; int *const&amp; &gt; y2; y2.a();
Y&lt; int const *const&amp; &gt; y3; y3.a();
Y&lt; int const&amp; &gt; y4; y4.b(); // fully specialized match
</pre>
</div>
<p>
Given typemaps with the same types used for the template declared above, where T is again analogous to SWIGTYPE:
</p>
<div class="code">
<pre>
%typemap(...) SWIGTYPE { ... }
%typemap(...) int const&amp; { ... }
</pre>
</div>
<p>
The comparison between non-default typemaps and fully specialized single parameter templates turns out to be the same, as just the one type will match the non-default typemap:
</p>
<div class="code">
<pre>
int &amp;
int *const&amp;
int const*const&amp;
int const&amp; // matches non-default typemap int const&amp;
</pre>
</div>
<p>
However, if a non-const type is used instead:
</p>
<div class="code">
<pre>
%typemap(...) SWIGTYPE { ... }
%typemap(...) int &amp; { ... }
</pre>
</div>
<p>
then there is a clear difference to template matching as both the const and non-const types match the typemap:
</p>
<div class="code">
<pre>
int &amp; // matches non-default typemap int &amp;
int *const&amp;
int const*const&amp;
int const&amp; // matches non-default typemap int &amp;
</pre>
</div>
<p>
There are other subtle differences such as typedef handling, but at least it should be clear that the typemap matching rules
are similar to those for specialized template handling.
</p>
<H3><a name="Typemaps_debugging_search">14.3.6 Debugging typemap pattern matching</a></H3>
<p>
There are two useful debug command line options available for debugging typemaps, <tt>-debug-tmsearch</tt> and <tt>-debug-tmused</tt>.
</p>
<p>
The <tt>-debug-tmsearch</tt> option is a verbose option for debugging typemap searches.
This can be very useful for watching the pattern matching process in action and for debugging which typemaps are used.
The option displays all the typemaps and types that are looked for until a successful pattern match is made.
As the display includes searches for each and every type needed for wrapping, the amount of information displayed can be large.
Normally you would manually search through the displayed information for the particular type that you are interested in.
</p>
<p>
For example, consider some of the code used in the <a href="#Typemaps_typedef_reductions">Typedef reductions</a> section already covered:
</p>
<div class="code">
<pre>
typedef int Integer;
typedef Integer Row4[4];
void foo(Row4 rows[10]);
</pre>
</div>
<p>
A sample of the debugging output is shown below for the "in" typemap:
</p>
<div class="shell">
<pre>
swig -perl -debug-tmsearch example.i
...
example.h:3: Searching for a suitable 'in' typemap for: Row4 rows[10]
Looking for: Row4 rows[10]
Looking for: Row4 [10]
Looking for: Row4 rows[ANY]
Looking for: Row4 [ANY]
Looking for: Integer rows[10][4]
Looking for: Integer [10][4]
Looking for: Integer rows[ANY][ANY]
Looking for: Integer [ANY][ANY]
Looking for: int rows[10][4]
Looking for: int [10][4]
Looking for: int rows[ANY][ANY]
Looking for: int [ANY][ANY]
Looking for: SWIGTYPE rows[ANY][ANY]
Looking for: SWIGTYPE [ANY][ANY]
Looking for: SWIGTYPE rows[ANY][]
Looking for: SWIGTYPE [ANY][]
Looking for: SWIGTYPE *rows[ANY]
Looking for: SWIGTYPE *[ANY]
Looking for: SWIGTYPE rows[ANY]
Looking for: SWIGTYPE [ANY]
Looking for: SWIGTYPE rows[]
Looking for: SWIGTYPE []
Using: %typemap(in) SWIGTYPE []
...
</pre>
</div>
<p>
showing that the best default match supplied by SWIG is the <tt>SWIGTYPE []</tt> typemap.
As the example shows, the successful match displays the used typemap source including typemap method, type and optional name in one of these simplified formats:
</p>
<ul>
<li> <tt>Using: %typemap(method) type name</tt>
<li> <tt>Using: %typemap(method) type name = type2 name2</tt>
<li> <tt>Using: %apply type2 name2 { type name }</tt>
</ul>
<p>
This information might meet your debugging needs, however, you might want to analyze further.
If you next invoke SWIG with the <tt>-E</tt> option to display the preprocessed output, and search for the particular typemap used,
you'll find the full typemap contents (example shown below for Python):
</p>
<div class="code">
<pre>
%typemap(in, noblock=1) SWIGTYPE [] (void *argp = 0, int res = 0) {
res = SWIG_ConvertPtr($input, &amp;argp, $descriptor, $disown | 0 );
if (!SWIG_IsOK(res)) {
SWIG_exception_fail(SWIG_ArgError(res), "in method '" "$symname" "', argument "
"$argnum"" of type '" "$type""'");
}
$1 = ($ltype)(argp);
}
</pre>
</div>
<p>
The generated code for the <tt>foo</tt> wrapper will then contain the snippets of the typemap with the special variables expanded.
The rest of this chapter will need reading though to fully understand all of this, however, the relevant parts of the generated code for the above typemap can be seen below:
</p>
<div class="code">
<pre>
SWIGINTERN PyObject *_wrap_foo(PyObject *SWIGUNUSEDPARM(self), PyObject *args) {
...
void *argp1 = 0 ;
int res1 = 0 ;
...
res1 = SWIG_ConvertPtr(obj0, &amp;argp1, SWIGTYPE_p_a_4__int, 0 | 0 );
if (!SWIG_IsOK(res1)) {
SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "foo" "', argument "
"1"" of type '" "int [10][4]""'");
}
arg1 = (int (*)[4])(argp1);
...
}
</pre>
</div>
<p>
Searches for multi-argument typemaps are not mentioned unless a matching multi-argument typemap does actually exist.
For example, the output for the code in the <a href="#Typemaps_multi_argument_typemaps_patterns">earlier multi-arguments section</a> is as follows:
</p>
<div class="shell">
<pre>
...
example.h:39: Searching for a suitable 'in' typemap for: char *buffer
Looking for: char *buffer
Multi-argument typemap found...
Using: %typemap(in) (char *buffer, int len)
...
</pre>
</div>
<p>
The second option for debugging is <tt>-debug-tmused</tt> and this displays the typemaps used.
This option is a less verbose version of the <tt>-debug-tmsearch</tt> option as it only displays each successfully found typemap on a separate single line.
The output displays the type, and name if present, the typemap method in brackets and then the actual typemap used in the same simplified format output by the <tt>-debug-tmsearch</tt> option.
Below is the output for the example code at the start of this section on debugging.
</p>
<div class="shell">
<pre>
$ swig -perl -debug-tmused example.i
example.h:3: Typemap for Row4 rows[10] (in) : %typemap(in) SWIGTYPE []
example.h:3: Typemap for Row4 rows[10] (typecheck) : %typemap(typecheck) SWIGTYPE *
example.h:3: Typemap for Row4 rows[10] (freearg) : %typemap(freearg) SWIGTYPE []
example.h:3: Typemap for void foo (out) : %typemap(out) void
</pre>
</div>
<p>
Now, consider the following interface file:
</p>
<div class="code">
<pre>
%module example
%{
void set_value(const char* val) {}
%}
%typemap(check) char *NON_NULL {
if (!$1) {
/* ... error handling ... */
}
}
// use default pointer handling instead of strings
%apply SWIGTYPE * { const char* val, const char* another_value }
%typemap(check) const char* val = char* NON_NULL;
%typemap(arginit, noblock=1) const char* val {
$1 = "";
}
void set_value(const char* val);
</pre>
</div>
<p>
and the output debug:
</p>
<div class="shell">
<pre>
swig -perl5 -debug-tmused example.i
example.i:21: Typemap for char const *val (arginit) : %typemap(arginit) char const *val
example.i:21: Typemap for char const *val (in) : %apply SWIGTYPE * { char const *val }
example.i:21: Typemap for char const *val (typecheck) : %apply SWIGTYPE * { char const *val }
example.i:21: Typemap for char const *val (check) : %typemap(check) char const *val = char *NON_NULL
example.i:21: Typemap for char const *val (freearg) : %apply SWIGTYPE * { char const *val }
example.i:21: Typemap for void set_value (out) : %typemap(out) void
</pre>
</div>
<p>
The following observations about what is displayed can be noted (the same applies for <tt>-debug-tmsearch</tt>):
</p>
<ul>
<li>
The relevant typemap is shown, but for typemap copying, the appropriate <tt>%typemap</tt> or <tt>%apply</tt> is displayed, for example, the "check" and "in" typemaps.
</li>
<li>
The typemap modifiers are not shown, eg the <tt>noblock=1</tt> modifier in the "arginit" typemap.
</li>
<li>
The exact <tt>%apply</tt> statement might look different to what is in the actual code. For example, the <tt>const char* another_value</tt> is not shown as it is not relevant here.
Also the types may be displayed slightly differently - <tt>char const *</tt> and not <tt>const char*</tt>.
</li>
</ul>
<H2><a name="Typemaps_nn21">14.4 Code generation rules</a></H2>
<p>
This section describes rules by which typemap code is inserted into
the generated wrapper code.
</p>
<H3><a name="Typemaps_nn22">14.4.1 Scope</a></H3>
<p>
When a typemap is defined like this:
</p>
<div class="code">
<pre>
%typemap(in) int {
$1 = PyInt_AsLong($input);
}
</pre>
</div>
<p>
the typemap code is inserted into the wrapper function using a new block scope. In other words, the
wrapper code will look like this:
</p>
<div class="code">
<pre>
wrap_whatever() {
...
// Typemap code
{
arg1 = PyInt_AsLong(obj1);
}
...
}
</pre>
</div>
<p>
Because the typemap code is enclosed in its own block, it is legal to declare temporary variables
for use during typemap execution. For example:
</p>
<div class="code">
<pre>
%typemap(in) short {
long temp; /* Temporary value */
if (Tcl_GetLongFromObj(interp, $input, &amp;temp) != TCL_OK) {
return TCL_ERROR;
}
$1 = (short) temp;
}
</pre>
</div>
<p>
Of course, any variables that you declare inside a typemap are destroyed as soon as the typemap
code has executed (they are not visible to other parts of the wrapper function or other typemaps
that might use the same variable names).
</p>
<p>
Occasionally, typemap code will be specified using a few alternative forms. For example:
</p>
<div class="code">
<pre>
%typemap(in) int "$1 = PyInt_AsLong($input);";
%typemap(in) int %{
$1 = PyInt_AsLong($input);
%}
%typemap(in, noblock=1) int {
$1 = PyInt_AsLong($input);
}
</pre>
</div>
<p>
These three forms are mainly used for cosmetics--the specified code is not enclosed inside
a block scope when it is emitted. This sometimes results in a less complicated looking wrapper function.
Note that only the third of the three typemaps have the typemap code passed through the SWIG preprocessor.
</p>
<H3><a name="Typemaps_nn23">14.4.2 Declaring new local variables</a></H3>
<p>
Sometimes it is useful to declare a new local variable that exists
within the scope of the entire wrapper function. A good example of this
might be an application in which you wanted to marshal strings. Suppose
you had a C++ function like this
</p>
<div class="code">
<pre>
int foo(std::string *s);
</pre>
</div>
<p>
and you wanted to pass a native string in the target language as an argument. For instance,
in Perl, you wanted the function to work like this:
</p>
<div class="targetlang">
<pre>
$x = foo("Hello World");
</pre>
</div>
<p>
To do this, you can't just pass a raw Perl string as the <tt>std::string *</tt> argument.
Instead, you have to create a temporary <tt>std::string</tt> object, copy the Perl string data into it, and
then pass a pointer to the object. To do this, simply specify the typemap with an extra parameter like this:
</p>
<div class="code">
<pre>
%typemap(in) std::string * <b>(std::string temp)</b> {
unsigned int len;
char *s;
s = SvPV($input, len); /* Extract string data */
temp.assign(s, len); /* Assign to temp */
$1 = &amp;temp; /* Set argument to point to temp */
}
</pre>
</div>
<p>
In this case, <tt>temp</tt> becomes a local variable in
the scope of the entire wrapper function. For example:
</p>
<div class="code">
<pre>
wrap_foo() {
std::string temp; &lt;--- Declaration of temp goes here
...
/* Typemap code */
{
...
temp.assign(s, len);
...
}
...
}
</pre>
</div>
<p>
When you set <tt>temp</tt> to a value, it
persists for the duration of the wrapper function and gets
cleaned up automatically on exit.
</p>
<p>
It is perfectly safe to use more than one typemap involving local
variables in the same declaration. For example, you could declare a
function as :</p>
<div class="code"><pre>
void foo(std::string *x, std::string *y, std::string *z);
</pre></div>
<p>
This is safely handled because SWIG actually renames all local
variable references by appending an argument number suffix. Therefore, the
generated code would actually look like this:
</p>
<div class="code">
<pre>
wrap_foo() {
int *arg1; /* Actual arguments */
int *arg2;
int *arg3;
std::string temp1; /* Locals declared in the typemap */
std::string temp2;
std::string temp3;
...
{
char *s;
unsigned int len;
...
temp1.assign(s, len);
arg1 = *temp1;
}
{
char *s;
unsigned int len;
...
temp2.assign(s, len);
arg2 = &amp;temp2;
}
{
char *s;
unsigned int len;
...
temp3.assign(s, len);
arg3 = &amp;temp3;
}
...
}
</pre>
</div>
<p>There is an exception: if the variable name starts with the <tt>_global_</tt> prefix,
the argument number is not appended. Such variables can be used throughout the generated
wrapper function. For example, the above typemap could be rewritten to use <tt>_global_temp</tt>
instead of <tt>temp</tt> and the generated code would then contain a single <tt>_global_temp</tt> variable
instead of <tt>temp1</tt>, <tt>temp2</tt> and <tt>temp3</tt>:
</p>
<div class="code">
<pre>
%typemap(in) std::string * <b>(std::string _global_temp)</b> {
... as above ...
}
</pre>
</div>
<p>
Some typemaps do not recognize local variables (or they may simply not
apply). At this time, only typemaps that apply to argument conversion support this (input typemaps such as the "in" typemap).
</p>
<p>
<b>Note:</b>
</p>
<p>
When declaring a typemap for multiple types,
each type must have its own local variable declaration.
</p>
<div class="code">
<pre>
%typemap(in) const std::string *, std::string * (std::string temp) // NO!
// only std::string * has a local variable
// const std::string * does not (oops)
....
%typemap(in) const std::string * (std::string temp), std::string * (std::string temp) // Correct
....
</pre>
</div>
<H3><a name="Typemaps_special_variables">14.4.3 Special variables</a></H3>
<p>
Within all typemaps, the following special variables are expanded.
This is by no means a complete list as some target languages have additional special variables which are documented in the language specific chapters.
</p>
<center>
<table border=1 summary="Typemap special variables">
<tr><th>Variable</th><th>Meaning</th></tr>
<tr>
<td>$<em>n</em></td>
<td>
A C local variable corresponding to type <em>n</em> in the typemap
pattern.
</td>
</tr>
<tr>
<td>$argnum</td>
<td>Argument number. Only available in typemaps related to argument conversion</td>
</tr>
<tr>
<td>$<em>n</em>_name</td>
<td>Argument name</td>
</tr>
<tr>
<td>$<em>n</em>_type</td>
<td>Real C datatype of type <em>n</em>.</td>
</tr>
<tr>
<td>$<em>n</em>_ltype</td>
<td>ltype of type <em>n</em></td>
</tr>
<tr>
<td>$<em>n</em>_mangle</td>
<td>Mangled form of type <em>n</em>. For example <tt>_p_Foo</tt></td>
</tr>
<tr>
<td>$<em>n</em>_descriptor</td>
<td>Type descriptor structure for type <em>n</em>. For example
<tt>SWIGTYPE_p_Foo</tt>. This is primarily used when interacting with the
run-time type checker (described later).</td>
</tr>
<tr>
<td>$*<em>n</em>_type</td>
<td>Real C datatype of type <em>n</em> with one pointer removed.</td>
</tr>
<tr>
<td>$*<em>n</em>_ltype</td>
<td>ltype of type <em>n</em> with one pointer removed.</td>
</tr>
<tr>
<td>$*<em>n</em>_mangle</td>
<td>Mangled form of type <em>n</em> with one pointer removed. </td>
</tr>
<tr>
<td>$*<em>n</em>_descriptor</td>
<td>Type descriptor structure for type <em>n</em> with one pointer removed.
</tr>
<tr>
<td>$&amp;<em>n</em>_type</td>
<td>Real C datatype of type <em>n</em> with one pointer added.</td>
</tr>
<tr>
<td>$&amp;<em>n</em>_ltype</td>
<td>ltype of type <em>n</em> with one pointer added.</td>
</tr>
<tr>
<td>$&amp;<em>n</em>_mangle</td>
<td>Mangled form of type <em>n</em> with one pointer added.</td>
</tr>
<tr>
<td>$&amp;<em>n</em>_descriptor</td>
<td>Type descriptor structure for type <em>n</em> with one pointer added.
</tr>
<tr>
<td>$<em>n</em>_basetype</td>
<td>Base typename with all pointers and qualifiers stripped.
</td>
</tr>
</table>
</center>
<p>
Within the table, $<em>n</em> refers to a specific type within the typemap specification. For example,
if you write this
</p>
<div class="code">
<pre>
%typemap(in) int *INPUT {
}
</pre>
</div>
<p>
then $1 refers to <tt>int *INPUT</tt>. If you have a typemap like this,
</p>
<div class="code">
<pre>
%typemap(in) (int argc, char *argv[]) {
...
}
</pre>
</div>
<p>
then $1 refers to <tt>int argc</tt> and $2 refers to <tt>char *argv[]</tt>.
</p>
<p>
Substitutions related to types and names always fill in values from the actual code that was matched.
This is useful when a typemap might match multiple C datatype. For example:
</p>
<div class="code">
<pre>
%typemap(in) int, short, long {
$1 = ($1_ltype) PyInt_AsLong($input);
}
</pre>
</div>
<p>
In this case, <tt>$1_ltype</tt> is replaced with the datatype that is actually matched.
</p>
<p>
When typemap code is emitted, the C/C++ datatype of the special variables <tt>$1</tt> and
<tt>$2</tt> is always an "ltype." An "ltype" is simply a type that can legally appear
on the left-hand side of a C assignment operation. Here are a few examples of types
and ltypes:
</p>
<div class="diagram">
<pre>
type ltype
------ ----------------
int int
const int int
const int * int *
int [4] int *
int [4][5] int (*)[5]
</pre>
</div>
<p>
In most cases a ltype is simply the C datatype with qualifiers stripped off. In addition,
arrays are converted into pointers.
</p>
<p>
Variables such as <tt>$&amp;1_type</tt> and <tt>$*1_type</tt> are used to
safely modify the type by removing or adding pointers. Although not
needed in most typemaps, these substitutions are sometimes needed to properly
work with typemaps that convert values between pointers and values.
</p>
<p>
If necessary, type related substitutions can also be used when declaring locals. For example:
</p>
<div class="code">
<pre>
%typemap(in) int * ($*1_type temp) {
temp = PyInt_AsLong($input);
$1 = &amp;temp;
}
</pre>
</div>
<p>
There is one word of caution about declaring local variables in this manner. If you declare a local variable
using a type substitution such as <tt>$1_ltype temp</tt>, it won't work like you expect for arrays and certain
kinds of pointers. For example, if you wrote this,
</p>
<div class="code">
<pre>
%typemap(in) int [10][20] {
$1_ltype temp;
}
</pre>
</div>
<p>
then the declaration of <tt>temp</tt> will be expanded as
</p>
<div class="code">
<pre>
int (*)[20] temp;
</pre>
</div>
<p>
This is illegal C syntax and won't compile. There is currently no
straightforward way to work around this problem in SWIG due to the way
that typemap code is expanded and processed. However, one possible workaround
is to simply pick an alternative type such as <tt>void *</tt> and use
casts to get the correct type when needed. For example:
</p>
<div class="code">
<pre>
%typemap(in) int [10][20] {
void *temp;
...
(($1_ltype) temp)[i][j] = x; /* set a value */
...
}
</pre>
</div>
<p>
Another approach, which only works for arrays is to use the <tt>$1_basetype</tt> substitution. For example:
</p>
<div class="code">
<pre>
%typemap(in) int [10][20] {
$1_basetype temp[10][20];
...
temp[i][j] = x; /* set a value */
...
}
</pre>
</div>
<H3><a name="Typemaps_special_variable_macros">14.4.4 Special variable macros</a></H3>
<p>
Special variable macros are like macro functions in that they take one or more input arguments
which are used for the macro expansion.
They look like macro/function calls but use the special variable <tt>$</tt> prefix to the macro name.
Note that unlike normal macros, the expansion is not done by the preprocessor,
it is done during the SWIG parsing/compilation stages.
The following special variable macros are available across all language modules.
</p>
<H4><a name="Typemaps_special_macro_descriptor">14.4.4.1 $descriptor(type)</a></H4>
<p>
This macro expands into the type descriptor structure for any C/C++ type specified in <tt>type</tt>.
It behaves like the <tt>$1_descriptor</tt> special variable described above except that the type to expand is
taken from the macro argument rather than inferred from the typemap type.
For example, <tt>$descriptor(std::vector&lt;int&gt; *)</tt> will expand into <tt>SWIGTYPE_p_std__vectorT_int_t</tt>.
This macro is mostly used in the scripting target languages and is demonstrated later in the <a href="#Typemaps_runtime_type_checker_usage">Run-time type checker usage</a> section.
</p>
<H4><a name="Typemaps_special_macro_typemap">14.4.4.2 $typemap(method, typepattern)</a></H4>
<p>
This macro uses the <a href="#Typemaps_pattern_matching">pattern matching rules</a> described earlier to lookup and
then substitute the special variable macro with the code in the matched typemap.
The typemap to search for is specified by the arguments, where <tt>method</tt> is the typemap method name and
<tt>typepattern</tt> is a type pattern as per the <tt>%typemap</tt> specification in the <a href="#Typemaps_defining">Defining a typemap</a> section.
</p>
<p>
The special variables within the matched typemap are expanded into those for the matched typemap type,
not the typemap within which the macro is called.
In practice, there is little use for this macro in the scripting target languages.
It is mostly used in the target languages that are statically typed as a way to obtain the target language type given the C/C++ type and more commonly only when the C++ type is a template parameter.
</p>
<p>
The example below is for C# only and uses some typemap method names documented in the C# chapter, but it shows some of the possible syntax variations.
</p>
<div class="code">
<pre>
%typemap(cstype) unsigned long "uint"
%typemap(cstype) unsigned long bb "bool"
%typemap(cscode) BarClass %{
void foo($typemap(cstype, unsigned long aa) var1,
$typemap(cstype, unsigned long bb) var2,
$typemap(cstype, (unsigned long bb)) var3,
$typemap(cstype, unsigned long) var4)
{
// do something
}
%}
</pre>
</div>
<p>
The result is the following expansion
</p>
<div class="code">
<pre>
%typemap(cstype) unsigned long "uint"
%typemap(cstype) unsigned long bb "bool"
%typemap(cscode) BarClass %{
void foo(uint var1,
bool var2,
bool var3,
uint var4)
{
// do something
}
%}
</pre>
</div>
<H3><a name="Typemaps_special_variable_attributes">14.4.5 Special variables and typemap attributes</a></H3>
<p>
As of SWIG-3.0.7 typemap attributes will also expand special variables and special variable macros.
</p>
<p>
Example usage showing the expansion in the 'out' attribute (C# specific) as well as the main typemap body:
</p>
<div class="code">
<pre>
%typemap(ctype, out="$*1_ltype") unsigned int&amp; "$*1_ltype"
</pre>
</div>
<p>
is equivalent to the following as <tt>$*1_ltype</tt> expands to <tt>unsigned int</tt>:
</p>
<div class="code">
<pre>
%typemap(ctype, out="unsigned int") unsigned int&amp; "unsigned int"
</pre>
</div>
<H3><a name="Typemaps_special_variables_and_macros">14.4.6 Special variables combined with special variable macros</a></H3>
<p>
Special variables can also be used within special variable macros.
The special variables are expanded before they are used in the special variable macros.
</p>
<p>
Consider the following C# typemaps:
</p>
<div class="code">
<pre>
%typemap(cstype) unsigned int "uint"
%typemap(cstype, out="$typemap(cstype, $*1_ltype)") unsigned int&amp; "$typemap(cstype, $*1_ltype)"
</pre>
</div>
<p>
Special variables are expanded first and hence the above is equivalent to:
</p>
<div class="code">
<pre>
%typemap(cstype) unsigned int "uint"
%typemap(cstype, out="$typemap(cstype, unsigned int)") unsigned int&amp; "$typemap(cstype, unsigned int)"
</pre>
</div>
<p>
which then expands to:
</p>
<div class="code">
<pre>
%typemap(cstype) unsigned int "uint"
%typemap(cstype, out="uint") unsigned int&amp; "uint"
</pre>
</div>
<H2><a name="Typemaps_nn25">14.5 Common typemap methods</a></H2>
<p>
The family of typemaps recognized by a language module may vary. However,
the following typemap methods are nearly universal:
</p>
<H3><a name="Typemaps_nn26">14.5.1 "in" typemap</a></H3>
<p>
The "in" typemap is used to convert function arguments from the target language
to C. For example:
</p>
<div class="code">
<pre>
%typemap(in) int {
$1 = PyInt_AsLong($input);
}
</pre>
</div>
<p>
The following special variables are available:
</p>
<div class="code">
<pre>
$input - Input object holding value to be converted.
$symname - Name of function/method being wrapped
</pre>
</div>
<p>
This is probably the most commonly redefined typemap because it can be used
to implement customized conversions.
</p>
<p>
In addition, the "in" typemap allows the number of converted arguments to be
specified. The <tt>numinputs</tt> attributes facilitates this. For example:
</p>
<div class="code">
<pre>
// Ignored argument.
%typemap(in, numinputs=0) int *out (int temp) {
$1 = &amp;temp;
}
</pre>
</div>
<p>
At this time, only zero or one arguments may be converted.
When <tt>numinputs</tt> is set to 0, the argument is effectively ignored and cannot be supplied from the target language.
The argument is still required when making the C/C++ call and the above typemap
shows the value used is instead obtained from a locally declared variable called <tt>temp</tt>.
Usually <tt>numinputs</tt> is not specified, whereupon the default value is 1, that is, there is a one to one mapping of the number of arguments when used from the target language to the C/C++ call.
<a href="#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a> provide a similar concept where the number of arguments mapped from the target language to C/C++ can be changed for multiple adjacent C/C++ arguments.
</p>
<p>
<b>Compatibility note: </b> Specifying <tt>numinputs=0</tt>
is the same as the old "ignore" typemap.
</p>
<H3><a name="Typemaps_nn27">14.5.2 "typecheck" typemap</a></H3>
<p>
The "typecheck" typemap is used to support overloaded functions and methods. It merely checks an argument
to see whether or not it matches a specific type. For example:
</p>
<div class="code">
<pre>
%typemap(typecheck, precedence=SWIG_TYPECHECK_INTEGER) int {
$1 = PyInt_Check($input) ? 1 : 0;
}
</pre>
</div>
<p>
For typechecking, the $1 variable is always a simple integer that is set to 1 or 0 depending on whether or not
the input argument is the correct type.
Set to 1 if the input argument is the correct type otherwise set to 0.
</p>
<p>
If you define new "in" typemaps <em>and</em> your program uses overloaded methods, you should also define a collection of
"typecheck" typemaps. More details about this follow in the <a href="#Typemaps_overloading">Typemaps and overloading</a> section.
</p>
<H3><a name="Typemaps_nn28">14.5.3 "out" typemap</a></H3>
<p>
The "out" typemap is used to convert function/method return values from C
into the target language. For example:
</p>
<div class="code">
<pre>
%typemap(out) int {
$result = PyInt_FromLong($1);
}
</pre>
</div>
<p>
The following special variables are available.
</p>
<div class="code">
<pre>
$result - Result object returned to target language.
$symname - Name of function/method being wrapped
</pre>
</div>
<p>
The "out" typemap supports an optional attribute flag called "optimal". This is for code optimisation and is detailed in the <a href="#Typemaps_optimal">Optimal code generation when returning by value</a> section.
</p>
<H3><a name="Typemaps_nn29">14.5.4 "arginit" typemap</a></H3>
<p>
The "arginit" typemap is used to set the initial value of a function
argument--before any conversion has occurred. This is not normally
necessary, but might be useful in highly specialized applications.
For example:
</p>
<div class="code">
<pre>
// Set argument to NULL before any conversion occurs
%typemap(arginit) int *data {
$1 = NULL;
}
</pre>
</div>
<H3><a name="Typemaps_nn30">14.5.5 "default" typemap</a></H3>
<p>
The "default" typemap is used to turn an argument into a default
argument. For example:
</p>
<div class="code">
<pre>
%typemap(default) int flags {
$1 = DEFAULT_FLAGS;
}
...
int foo(int x, int y, int flags);
</pre>
</div>
<p>
The primary use of this typemap is to either change the wrapping of
default arguments or specify a default argument in a language where
they aren't supported (like C). Target languages that do not support
optional arguments, such as Java and C#, effectively ignore the value specified
by this typemap as all arguments must be given.
</p>
<p>
Once a default typemap has been applied to an argument, all arguments
that follow must have default values.
See the <a href="SWIG.html#SWIG_default_args">Default/optional arguments</a> section
for further information on default argument wrapping.
</p>
<H3><a name="Typemaps_nn31">14.5.6 "check" typemap</a></H3>
<p>
The "check" typemap is used to supply value checking code during argument
conversion. The typemap is applied <em>after</em> arguments have been
converted. For example:
</p>
<div class="code">
<pre>
%typemap(check) int positive {
if ($1 &lt;= 0) {
SWIG_exception(SWIG_ValueError, "Expected positive value.");
}
}
</pre>
</div>
<H3><a name="Typemaps_nn32">14.5.7 "argout" typemap</a></H3>
<p>
The "argout" typemap is used to return values from arguments. This
is most commonly used to write wrappers for C/C++ functions that need
to return multiple values. The "argout" typemap is almost always combined
with an "in" typemap---possibly to ignore the input value. For example:
</p>
<div class="code">
<pre>
/* Set the input argument to point to a temporary variable */
%typemap(in, numinputs=0) int *out (int temp) {
$1 = &amp;temp;
}
%typemap(argout) int *out {
// Append output value $1 to $result
...
}
</pre>
</div>
<p>
The following special variables are available.
</p>
<div class="diagram">
<pre>
$result - Result object returned to target language.
$input - The original input object passed.
$symname - Name of function/method being wrapped
</pre>
</div>
<p>
The code supplied to the "argout" typemap is always placed after
the "out" typemap. If multiple return values are used, the extra
return values are often appended to return value of the function.
</p>
<p>
See the <tt>typemaps.i</tt> library file for examples.
</p>
<H3><a name="Typemaps_nn33">14.5.8 "freearg" typemap</a></H3>
<p>
The "freearg" typemap is used to cleanup argument data. It is only
used when an argument might have allocated resources that need to be
cleaned up when the wrapper function exits. The "freearg" typemap
usually cleans up argument resources allocated by the "in" typemap.
For example:
</p>
<div class="code">
<pre>
// Get a list of integers
%typemap(in) int *items {
int nitems = Length($input);
$1 = (int *) malloc(sizeof(int)*nitems);
}
// Free the list
%typemap(freearg) int *items {
free($1);
}
</pre>
</div>
<p>
The "freearg" typemap inserted at the end of the wrapper function,
just before control is returned back to the target language. This
code is also placed into a special variable <tt>$cleanup</tt> that may
be used in other typemaps whenever a wrapper function needs to abort
prematurely.
</p>
<H3><a name="Typemaps_nn34">14.5.9 "newfree" typemap</a></H3>
<p>
The "newfree" typemap is used in conjunction with the <tt>%newobject</tt>
directive and is used to deallocate memory used by the return result
of a function. For example:
</p>
<div class="code">
<pre>
%typemap(newfree) string * {
delete $1;
}
%typemap(out) string * {
$result = PyString_FromString($1-&gt;c_str());
}
...
%newobject foo;
...
string *foo();
</pre>
</div>
<p>
See <a href="Customization.html#Customization_ownership">Object ownership and %newobject</a> for further details.
</p>
<H3><a name="Typemaps_ret">14.5.10 "ret" typemap</a></H3>
<p>
The "ret" typemap is not used very often, but can be useful for anything associated with
the return type, such as resource management, return value error checking, etc.
Usually this can all be done in the "out" typemap, but sometimes it is handy to use the
"out" typemap code untouched and add to the generated code using the code in the "ret" typemap.
One such case is memory clean up. For example, a <tt>stringheap_t</tt> type is defined indicating
that the returned memory must be deleted and a <tt>string_t</tt> type is defined indicating
that the returned memory must not be deleted.
</p>
<div class="code">
<pre>
%typemap(ret) stringheap_t %{
free($1);
%}
typedef char * string_t;
typedef char * stringheap_t;
string_t MakeString1();
stringheap_t MakeString2();
</pre>
</div>
<p>
The "ret" typemap above will only be used for <tt>MakeString2</tt>, but both functions
will use the default "out" typemap for <tt>char *</tt> provided by SWIG.
The code above would ensure the appropriate memory is freed in all target languages as the need
to provide custom "out" typemaps (which involve target language specific code) is not necessary.
</p>
<p>
This approach is an alternative to using the "newfree" typemap and <tt>%newobject</tt> as there
is no need to list all the functions that require the memory cleanup, it is purely done on types.
</p>
<H3><a name="Typemaps_nn35">14.5.11 "memberin" typemap</a></H3>
<p>
The "memberin" typemap is used to copy data from <em>an already converted input value</em>
into a structure member. It is typically used to handle array members and other special
cases. For example:
</p>
<div class="code">
<pre>
%typemap(memberin) int [4] {
memmove($1, $input, 4*sizeof(int));
}
</pre>
</div>
<p>
It is rarely necessary to write "memberin" typemaps---SWIG already provides
a default implementation for arrays, strings, and other objects.
</p>
<H3><a name="Typemaps_nn36">14.5.12 "varin" typemap</a></H3>
<p>
The "varin" typemap is used to convert objects in the target language to C for the
purposes of assigning to a C/C++ global variable. This is implementation specific.
</p>
<H3><a name="Typemaps_nn37">14.5.13 "varout" typemap</a></H3>
<p>
The "varout" typemap is used to convert a C/C++ object to an object in the target
language when reading a C/C++ global variable. This is implementation specific.
</p>
<H3><a name="Typemaps_throws_typemap">14.5.14 "throws" typemap</a></H3>
<p>
The "throws" typemap is only used when SWIG parses a C++ method with an exception specification or has the <tt>%catches</tt> feature attached to the method (see <a href="SWIGPlus.html#SWIGPlus_catches">Exception handling with %catches</a>).
It provides a default mechanism for handling C++ methods that have declared the exceptions they will throw.
The purpose of this typemap is to convert a C++ exception into an error or exception in the target language.
It is slightly different to the other typemaps as it is based around the exception type rather than the type of a parameter or variable.
For example:
</p>
<div class="code">
<pre>
%typemap(throws) const char * %{
PyErr_SetString(PyExc_RuntimeError, $1);
SWIG_fail;
%}
// Either an exception specification on the method
void bar() throw (const char *);
// Or a %catches feature attached to the method
%catches(const char *) bar();
void bar();
</pre>
</div>
<p>
As can be seen from the resulting generated code below, SWIG generates an exception handler
when wrapping the <tt>bar</tt> function with the catch block comprising the "throws" typemap content.
</p>
<div class="code">
<pre>
...
try {
bar();
} catch(char const *_e) {
PyErr_SetString(PyExc_RuntimeError, _e);
SWIG_fail;
}
...
</pre>
</div>
<p>
Note that if your methods do not have an exception specification but they do throw exceptions and you are not using <tt>%catches</tt>, SWIG cannot know how to deal with them.
Please also see the <a href="Customization.html#Customization_exception">Exception handling with %exception</a> section for another way to handle exceptions.
</p>
<H2><a name="Typemaps_nn39">14.6 Some typemap examples</a></H2>
<p>
This section contains a few examples. Consult language module documentation
for more examples.
</p>
<H3><a name="Typemaps_nn40">14.6.1 Typemaps for arrays</a></H3>
<p>
A common use of typemaps is to provide support for C arrays appearing both as
arguments to functions and as structure members.
</p>
<p>
For example, suppose you had a function like this:
</p>
<div class="code">
<pre>
void set_vector(int type, float value[4]);
</pre>
</div>
<p>
If you wanted to handle <tt>float value[4]</tt> as a list of floats, you might write a typemap
similar to this:
</p>
<div class="code">
<pre>
%typemap(in) float value[4] (float temp[4]) {
int i;
if (!PySequence_Check($input)) {
PyErr_SetString(PyExc_ValueError, "Expected a sequence");
SWIG_fail;
}
if (PySequence_Length($input) != 4) {
PyErr_SetString(PyExc_ValueError, "Size mismatch. Expected 4 elements");
SWIG_fail;
}
for (i = 0; i &lt; 4; i++) {
PyObject *o = PySequence_GetItem($input, i);
if (PyNumber_Check(o)) {
temp[i] = (float) PyFloat_AsDouble(o);
} else {
PyErr_SetString(PyExc_ValueError, "Sequence elements must be numbers");
SWIG_fail;
}
}
$1 = temp;
}
</pre>
</div>
<p>
In this example, the variable <tt>temp</tt> allocates a small array on the
C stack. The typemap then populates this array and passes it to the underlying C function.
</p>
<p>
When used from Python, the typemap allows the following type of function call:
</p>
<div class="targetlang">
<pre>
&gt;&gt;&gt; set_vector(type, [ 1, 2.5, 5, 20 ])
</pre>
</div>
<p>
If you wanted to generalize the typemap to apply to arrays of all dimensions you might write this:
</p>
<div class="code">
<pre>
%typemap(in) float value[ANY] (float temp[$1_dim0]) {
int i;
if (!PySequence_Check($input)) {
PyErr_SetString(PyExc_ValueError, "Expected a sequence");
SWIG_fail;
}
if (PySequence_Length($input) != $1_dim0) {
PyErr_SetString(PyExc_ValueError, "Size mismatch. Expected $1_dim0 elements");
SWIG_fail;
}
for (i = 0; i &lt; $1_dim0; i++) {
PyObject *o = PySequence_GetItem($input, i);
if (PyNumber_Check(o)) {
temp[i] = (float) PyFloat_AsDouble(o);
} else {
PyErr_SetString(PyExc_ValueError, "Sequence elements must be numbers");
SWIG_fail;
}
}
$1 = temp;
}
</pre>
</div>
<p>
In this example, the special variable <tt>$1_dim0</tt> is expanded with the actual
array dimensions. Multidimensional arrays can be matched in a similar manner. For example:
</p>
<div class="code">
<pre>
%typemap(in) float matrix[ANY][ANY] (float temp[$1_dim0][$1_dim1]) {
... convert a 2d array ...
}
</pre>
</div>
<p>
For large arrays, it may be impractical to allocate storage on the stack using a temporary variable
as shown. To work with heap allocated data, the following technique can be used.
</p>
<div class="code">
<pre>
%typemap(in) float value[ANY] {
int i;
if (!PySequence_Check($input)) {
PyErr_SetString(PyExc_ValueError, "Expected a sequence");
SWIG_fail;
}
if (PySequence_Length($input) != $1_dim0) {
PyErr_SetString(PyExc_ValueError, "Size mismatch. Expected $1_dim0 elements");
SWIG_fail;
}
$1 = (float *) malloc($1_dim0*sizeof(float));
for (i = 0; i &lt; $1_dim0; i++) {
PyObject *o = PySequence_GetItem($input, i);
if (PyNumber_Check(o)) {
$1[i] = (float) PyFloat_AsDouble(o);
} else {
free($1);
PyErr_SetString(PyExc_ValueError, "Sequence elements must be numbers");
SWIG_fail;
}
}
}
%typemap(freearg) float value[ANY] {
if ($1) free($1);
}
</pre>
</div>
<p>
In this case, an array is allocated using <tt>malloc</tt>. The <tt>freearg</tt> typemap is then used
to release the argument after the function has been called.
</p>
<p>
Another common use of array typemaps is to provide support for array structure members.
Due to subtle differences between pointers and arrays in C, you can't just "assign" to
a array structure member. Instead, you have to explicitly copy elements into the array.
For example, suppose you had a structure like this:
</p>
<div class="code"><pre>
struct SomeObject {
float value[4];
...
};
</pre></div>
<p>
When SWIG runs, it won't produce any code to set the <tt>vec</tt> member.
You may even get a warning message like this:
</p>
<div class="shell"><pre>
$ swig -python example.i
example.i:10: Warning 462: Unable to set variable of type float [4].
</pre></div>
<p>
These warning messages indicate that SWIG does not know how you want
to set the <tt>vec</tt> field.
</p>
<p>
To fix this, you can supply a special "memberin" typemap like this:
</p>
<div class="code"><pre>
%typemap(memberin) float [ANY] {
int i;
for (i = 0; i &lt; $1_dim0; i++) {
$1[i] = $input[i];
}
}
</pre></div>
<p>
The memberin typemap is used to set a structure member from data that has already been converted
from the target language to C. In this case, <tt>$input</tt> is the local variable in which
converted input data is stored. This typemap then copies this data into the structure.
</p>
<p>
When combined with the earlier typemaps for arrays, the combination of the "in" and "memberin" typemap allows
the following usage:
</p>
<div class="targetlang">
<pre>
&gt;&gt;&gt; s = SomeObject()
&gt;&gt;&gt; s.x = [1, 2.5, 5, 10]
</pre>
</div>
<p>
Related to structure member input, it may be desirable to return structure members as a new kind of
object. For example, in this example, you will get very odd program behavior where the structure member
can be set nicely, but reading the member simply returns a pointer:
</p>
<div class="targetlang">
<pre>
&gt;&gt;&gt; s = SomeObject()
&gt;&gt;&gt; s.x = [1, 2.5, 5, 10]
&gt;&gt;&gt; print s.x
_1008fea8_p_float
&gt;&gt;&gt;
</pre>
</div>
<p>
To fix this, you can write an "out" typemap. For example:
</p>
<div class="code">
<pre>
%typemap(out) float [ANY] {
int i;
$result = PyList_New($1_dim0);
for (i = 0; i &lt; $1_dim0; i++) {
PyObject *o = PyFloat_FromDouble((double) $1[i]);
PyList_SetItem($result, i, o);
}
}
</pre>
</div>
<p>
Now, you will find that member access is quite nice:
</p>
<div class="targetlang">
<pre>
&gt;&gt;&gt; s = SomeObject()
&gt;&gt;&gt; s.x = [1, 2.5, 5, 10]
&gt;&gt;&gt; print s.x
[ 1, 2.5, 5, 10]
</pre>
</div>
<p>
<b>Compatibility Note:</b> SWIG1.1 used to provide a special "memberout" typemap. However, it was mostly
useless and has since been eliminated. To return structure members, simply use the "out" typemap.
</p>
<H3><a name="Typemaps_nn41">14.6.2 Implementing constraints with typemaps</a></H3>
<p>
One particularly interesting application of typemaps is the
implementation of argument constraints. This can be done with the
"check" typemap. When used, this allows you to provide code for
checking the values of function arguments. For example:</p>
<div class="code"><pre>
%module math
%typemap(check) double posdouble {
if ($1 &lt; 0) {
croak("Expecting a positive number");
}
}
...
double sqrt(double posdouble);
</pre></div>
<p>
This provides a sanity check to your wrapper function. If a negative
number is passed to this function, a Perl exception will be raised and
your program terminated with an error message.</p>
<p>
This kind of checking can be particularly useful when working with
pointers. For example:</p>
<div class="code"><pre>
%typemap(check) Vector * {
if ($1 == 0) {
PyErr_SetString(PyExc_TypeError, "NULL Pointer not allowed");
SWIG_fail;
}
}
</pre></div>
<p>
will prevent any function involving a <tt>Vector *</tt> from accepting
a NULL pointer. As a result, SWIG can often prevent a potential
segmentation faults or other run-time problems by raising an exception
rather than blindly passing values to the underlying C/C++ program.</p>
<H2><a name="Typemaps_nn43">14.7 Typemaps for multiple target languages</a></H2>
<p>
The code within typemaps is usually language dependent,
however, many target languages support the same typemaps.
In order to distinguish typemaps across different languages, the preprocessor should be used.
For example, the "in" typemap for Perl and Ruby could be written as:
</p>
<div class="code"><pre>
#if defined(SWIGPERL)
%typemap(in) int "$1 = ($1_ltype) SvIV($input);"
#elif defined(SWIGRUBY)
%typemap(in) int "$1 = NUM2INT($input);"
#else
#warning no "in" typemap defined
#endif
</pre></div>
<p>
The full set of language specific macros is defined in the <a href="Preprocessor.html#Preprocessor_condition_compilation">Conditional Compilation</a> section.
The example above also shows a common approach of issuing a warning for an as yet unsupported language.
</p>
<p>
<b>Compatibility note: </b> In SWIG-1.1 different languages could be distinguished with the language name being put within the <tt>%typemap</tt> directive, for example, <br>
<tt>%typemap(ruby, in) int "$1 = NUM2INT($input);"</tt>.
</p>
<H2><a name="Typemaps_optimal">14.8 Optimal code generation when returning by value</a></H2>
<p>
The "out" typemap is the main typemap for return types.
This typemap supports an optional attribute flag called "optimal", which is for reducing the number of
temporary variables and the amount of generated code, thereby giving the compiler the opportunity to
use <i>return value optimization</i> for generating faster executing code.
It only really makes a difference when returning objects by value and has some limitations on usage,
as explained later on.
</p>
<p>
When a function returns an object by value, SWIG generates code that instantiates the default
type on the stack then assigns the value returned by the function call to it.
A copy of this object is then made on the heap and this is what is ultimately stored and
used from the target language.
This will be clearer considering an example.
Consider running the following code through SWIG:
</p>
<div class="code">
<pre>
%typemap(out) SWIGTYPE %{
$result = new $1_ltype((const $1_ltype &amp;)$1);
%}
%inline %{
#include &lt;iostream&gt;
using namespace std;
struct XX {
XX() { cout &lt;&lt; "XX()" &lt;&lt; endl; }
XX(int i) { cout &lt;&lt; "XX(" &lt;&lt; i &lt;&lt; ")" &lt;&lt; endl; }
XX(const XX &amp;other) { cout &lt;&lt; "XX(const XX &amp;)" &lt;&lt; endl; }
XX &amp; operator =(const XX &amp;other) { cout &lt;&lt; "operator=(const XX &amp;)" &lt;&lt; endl; return *this; }
~XX() { cout &lt;&lt; "~XX()" &lt;&lt; endl; }
static XX create() {
return XX(0);
}
};
%}
</pre>
</div>
<p>
The "out" typemap shown is the default typemap for C# when returning objects by value.
When making a call to <tt>XX::create()</tt> from C#, the output is as follows:
</p>
<div class="targetlang">
<pre>
XX()
XX(0)
operator=(const XX &amp;)
~XX()
XX(const XX &amp;)
~XX()
~XX()
</pre>
</div>
<p>
Note that three objects are being created as well as an assignment.
Wouldn't it be great if the <tt>XX::create()</tt> method was the only time a constructor was called?
As the method returns by value, this is asking a lot and the code that SWIG generates by default
makes it impossible for the compiler to use <i>return value optimisation (RVO)</i>.
However, this is where the "optimal" attribute in the "out" typemap can help out.
If the typemap code is kept the same and just the "optimal" attribute specified like this:
</p>
<div class="code">
<pre>
%typemap(out, optimal="1") SWIGTYPE %{
$result = new $1_ltype((const $1_ltype &amp;)$1);
%}
</pre>
</div>
<p>
then when the code is run again, the output is simply:
</P>
<div class="targetlang">
<pre>
XX(0)
~XX()
</pre>
</div>
<p>
How the "optimal" attribute works is best explained using the generated code.
Without "optimal", the generated code is:
</p>
<div class="code">
<pre>
SWIGEXPORT void * SWIGSTDCALL CSharp_XX_create() {
void * jresult ;
XX result;
result = XX::create();
jresult = new XX((const XX &amp;)result);
return jresult;
}
</pre>
</div>
<p>
With the "optimal" attribute, the code is:
</p>
<div class="code">
<pre>
SWIGEXPORT void * SWIGSTDCALL CSharp_XX_create() {
void * jresult ;
jresult = new XX((const XX &amp;)XX::create());
return jresult;
}
</pre>
</div>
<p>
The major difference is the <tt>result</tt> temporary variable holding the value returned from <tt>XX::create()</tt> is no longer generated and instead the copy constructor call is made directly from
the value returned by <tt>XX::create()</tt>.
With modern compilers implementing RVO, the copy is not actually done, in fact the object is never created
on the stack in <tt>XX::create()</tt> at all, it is simply created directly on the heap.
In the first instance, the <tt>$1</tt> special variable in the typemap is expanded into <tt>result</tt>.
In the second instance, <tt>$1</tt> is expanded into <tt>XX::create()</tt> and this is essentially
what the "optimal" attribute is telling SWIG to do.
</p>
<p>
The "optimal" attribute optimisation is not turned on by default as it has a number of restrictions.
Firstly, some code cannot be condensed into a simple call for passing into the copy constructor.
One common occurrence is when <a href="Customization.html#Customization_exception">%exception</a> is used.
Consider adding the following <tt>%exception</tt> to the example:
</p>
<div class="code">
<pre>
%exception XX::create() %{
try {
$action
} catch(const std::exception &amp;e) {
cout &lt;&lt; e.what() &lt;&lt; endl;
}
%}
</pre>
</div>
<p>
SWIG can detect when the "optimal" attribute cannot be used and will ignore it and in this case will issue the following warning:
</p>
<div class="targetlang">
<pre>
example.i:28: Warning 474: Method XX::create() usage of the optimal attribute ignored
example.i:14: Warning 474: in the out typemap as the following cannot be used to generate
optimal code:
try {
result = XX::create();
} catch(const std::exception &amp;e) {
cout &lt;&lt; e.what() &lt;&lt; endl;
}