jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge remote-tracking branch 'origin/master' into gsoc2012-scilab

Browse source 
Conflicts:
	.gitignore
	.travis.yml
	configure.ac
This commit is contained in:
Simon Marchetto 2015-01-26 10:50:20 +01:00
commit adc4b788df
352 changed files with 8897 additions and 2812 deletions
Download patch file Download diff file Expand all files Collapse all files

2
Doc/Manual/Android.html
View file

@ -56,7 +56,7 @@ Add the SDK tools and NDK tools to your path and create a directory somewhere fo
<pre>
$ export PATH=$HOME/android/android-sdk-linux_x86/tools:$HOME/android/android-sdk-linux_x86/platform-tools:$HOME/android/android-ndk-r6b:$PATH
$ mkdir AndroidApps
$ cd AnrdoidApps
$ cd AndroidApps
</pre>
</div>

73
Doc/Manual/CPlusPlus11.html
View file

@ -495,59 +495,59 @@ struct DerivedStruct : BaseStruct {
<H3><a name="CPlusPlus11_strongly_typed_enumerations"></a>7.2.13 Strongly typed enumerations</H3>
<p>SWIG parses the new <tt>enum class</tt> syntax and forward declarator for the enums:</p>
<p>SWIG supports strongly typed enumerations and parses the new <tt>enum class</tt> syntax and forward declarator for the enums, such as:</p>
<div class="code"><pre>
enum class MyEnum : unsigned int;
</pre></div>
<p>The strongly typed enumerations are treated the same as the ordinary and anonymous enums.
This is because the required nested class support in SWIG is new and has not yet been incorporated into the wrapping of these strongly typed enum classes.
This is usually not a problem, however,
there may be some name clashes. For example, the following code:</p>
<p>
Strongly typed enums are often used to avoid name clashes such as the following:
</p>
<div class="code"><pre>
class Color {
enum class PrintingColors : unsigned int {
Cyan, Magenta, Yellow, Black
struct Color {
enum class RainbowColors : unsigned int {
Red, Orange, Yellow, Green, Blue, Indigo, Violet
};
enum class BasicColors {
Red, Green, Blue
enum class WarmColors {
Yellow, Orange, Red
};
enum class AllColors {
// produces warnings because of duplicate names
Yellow, Orange, Red, Magenta, Blue, Cyan, Green, Pink, Black, White
};
};
</pre></div>
<p>A workaround is to write these as a series of separate classes containing anonymous enums:</p>
<div class="code"><pre>
class PrintingColors {
enum : unsigned int {
Cyan, Magenta, Yellow, Black
};
};
class BasicColors {
enum : unsigned int {
Red, Green, Blue
};
};
class AllColors {
enum : unsigned int {
Yellow, Orange, Red, Magenta, Blue, Cyan, Green, Pink, Black, White
// Note normal enum
enum PrimeColors {
Red=100, Green, Blue
};
};
</pre></div>
<p>
Expect to see this improved in a future version of SWIG.
There are various ways that the target languages handle enums, so it is not possible to precisely state how they are handled in this section.
However, generally, most scripting languages mangle in the strongly typed enumeration's class name,
but do not use any additional mangling for normal enumerations. For example, in Python, the following code
</p>
<div class="targetlang"><pre>
print Color.RainbowColors_Red, Color.WarmColors_Red, Color.Red
</pre></div>
<p>
results in
</p>
<div class="shell"><pre>
0 2 100
</pre></div>
<p>
The strongly typed languages often wrap normal enums into an enum class and so treat normal enums and strongly typed enums the same.
The equivalent in Java is:
</p>
<div class="targetlang"><pre>
System.out.println(Color.RainbowColors.Red.swigValue() + " " + Color.WarmColors.Red.swigValue() + " " + Color.PrimeColors.Red.swigValue());
</pre></div>
<H3><a name="CPlusPlus11_double_angle_brackets"></a>7.2.14 Double angle brackets</H3>
@ -611,6 +611,7 @@ The following is an example of an alias template:
<div class="code"><pre>
template&lt; typename T1, typename T2, int &gt;
class SomeType {
public:
T1 a;
T2 b;
int c;

1
Doc/Manual/CSharp.html
View file

@ -1075,6 +1075,7 @@ try {
$action
} catch (std::out_of_range e) {
SWIG_CSharpSetPendingException(SWIG_CSharpApplicationException, e.what());
return $null;
}
%}

4
Doc/Manual/Contents.html
View file

@ -841,6 +841,7 @@
<div class="sectiontoc">
<ul>
<li><a href="Go.html#Go_overview">Overview</a>
<li><a href="Go.html#Go_examples">Examples</a>
<li><a href="Go.html#Go_running_swig">Running SWIG with Go</a>
<ul>
<li><a href="Go.html#Go_commandline">Additional Commandline Options</a>
@ -854,6 +855,7 @@
<li><a href="Go.html#Go_enumerations">Go Enumerations</a>
<li><a href="Go.html#Go_classes">Go Classes</a>
<ul>
<li><a href="Go.html#Go_class_memory">Go Class Memory Management</a>
<li><a href="Go.html#Go_class_inheritance">Go Class Inheritance</a>
</ul>
<li><a href="Go.html#Go_templates">Go Templates</a>
@ -861,6 +863,7 @@
<li><a href="Go.html#Go_primitive_type_mappings">Default Go primitive type mappings</a>
<li><a href="Go.html#Go_output_arguments">Output arguments</a>
<li><a href="Go.html#Go_adding_additional_code">Adding additional go code</a>
<li><a href="Go.html#Go_typemaps">Go typemaps</a>
</ul>
</ul>
</div>
@ -1415,6 +1418,7 @@
<li><a href="Php.html#Php_nn2_6_2">Constructors and Destructors</a>
<li><a href="Php.html#Php_nn2_6_3">Static Member Variables</a>
<li><a href="Php.html#Php_nn2_6_4">Static Member Functions</a>
<li><a href="Php.html#Php_nn2_6_5">Specifying Implemented Interfaces</a>
</ul>
<li><a href="Php.html#Php_nn2_7">PHP Pragmas, Startup and Shutdown code</a>
</ul>

10
Doc/Manual/Customization.html
View file

@ -485,12 +485,12 @@ variables are replaced with.
</tr>
<tr>
<td>$parentname</td>
<td>$parentclassname</td>
<td>The parent class name (if any) for a method.</td>
</tr>
<tr>
<td>$parentsymname</td>
<td>$parentclasssymname</td>
<td>The target language parent class name (if any) for a method.</td>
</tr>
@ -547,7 +547,7 @@ Below shows the expansions for the 1st of the overloaded <tt>something</tt> wrap
The <tt>exception.i</tt> library file provides support for creating
language independent exceptions in your interfaces. To use it, simply
put an "<tt>%include exception.i</tt>" in your interface file. This
creates a function<tt> SWIG_exception()</tt> that can be used to raise
provides a function <tt>SWIG_exception()</tt> that can be used to raise
common scripting language exceptions in a portable manner. For example :</p>
<div class="code"><pre>
@ -1082,7 +1082,7 @@ For example:
<div class="code">
<pre>
%feature("except") void hello(int i=0, double d=0.0) { ... }
%feature("except") hello(int i=0, double d=0.0) { ... }
void hello(int i=0, double d=0.0);
</pre>
</div>
@ -1105,7 +1105,7 @@ If the default arguments are not specified in the feature:
<div class="code">
<pre>
%feature("except") void hello(int i, double d) { ... }
%feature("except") hello(int i, double d) { ... }
void hello(int i=0, double d=0.0);
</pre>
</div>

223
Doc/Manual/Go.html
View file

@ -10,6 +10,7 @@
<div class="sectiontoc">
<ul>
<li><a href="#Go_overview">Overview</a>
<li><a href="#Go_examples">Examples</a>
<li><a href="#Go_running_swig">Running SWIG with Go</a>
<ul>
<li><a href="#Go_commandline">Additional Commandline Options</a>
@ -23,6 +24,7 @@
<li><a href="#Go_enumerations">Go Enumerations</a>
<li><a href="#Go_classes">Go Classes</a>
<ul>
<li><a href="#Go_class_memory">Go Class Memory Management</a>
<li><a href="#Go_class_inheritance">Go Class Inheritance</a>
</ul>
<li><a href="#Go_templates">Go Templates</a>
@ -30,6 +32,7 @@
<li><a href="#Go_primitive_type_mappings">Default Go primitive type mappings</a>
<li><a href="#Go_output_arguments">Output arguments</a>
<li><a href="#Go_adding_additional_code">Adding additional go code</a>
<li><a href="#Go_typemaps">Go typemaps</a>
</ul>
</ul>
</div>
@ -67,7 +70,22 @@ checking and runtime library are not used with Go. This should be
borne in mind when reading the rest of the SWIG documentation.
</p>
<H2><a name="Go_running_swig"></a>23.2 Running SWIG with Go</H2>
<H2><a name="Go_examples"></a>23.2 Examples</H2>
<p>
Working examples can be found here:
</p>
<ul>
<li><a href="https://golang.org/misc/swig">Examples from the Go source tree</a>
<li><a href="https://github.com/swig/swig/tree/master/Examples/go">Examples from the SWIG source tree</a>
</ul>
<p>
The examples in the 2nd link are shipped with the SWIG distribution under the Examples/go directory.
</p>
<H2><a name="Go_running_swig"></a>23.3 Running SWIG with Go</H2>
<p>
@ -76,7 +94,7 @@ default SWIG will generate code for the gc compilers. To generate
code for gccgo, you should also use the <tt>-gccgo</tt> option.
</p>
<H3><a name="Go_commandline"></a>23.2.1 Additional Commandline Options</H3>
<H3><a name="Go_commandline"></a>23.3.1 Additional Commandline Options</H3>
<p>
@ -150,7 +168,7 @@ swig -go -help
</table>
<H3><a name="Go_outputs"></a>23.2.2 Go Output Files</H3>
<H3><a name="Go_outputs"></a>23.3.2 Go Output Files</H3>
<p> When generating Go code, SWIG will generate the following
@ -226,7 +244,7 @@ this:
% go tool 6l main.6
</pre></div>
<H2><a name="Go_basic_tour"></a>23.3 A tour of basic C/C++ wrapping</H2>
<H2><a name="Go_basic_tour"></a>23.4 A tour of basic C/C++ wrapping</H2>
<p>
@ -236,7 +254,7 @@ modifications have to occur. This section briefly covers the
essential aspects of this wrapping.
</p>
<H3><a name="Go_package"></a>23.3.1 Go Package Name</H3>
<H3><a name="Go_package"></a>23.4.1 Go Package Name</H3>
<p>
@ -246,7 +264,7 @@ directive. You may override this by using SWIG's <tt>-package</tt>
command line option.
</p>
<H3><a name="Go_names"></a>23.3.2 Go Names</H3>
<H3><a name="Go_names"></a>23.4.2 Go Names</H3>
<p>
@ -278,7 +296,7 @@ followed by that name, and the destructor will be
named <tt>Delete</tt> followed by that name.
</p>
<H3><a name="Go_constants"></a>23.3.3 Go Constants</H3>
<H3><a name="Go_constants"></a>23.4.3 Go Constants</H3>
<p>
@ -286,7 +304,7 @@ C/C++ constants created via <tt>#define</tt> or the <tt>%constant</tt>
directive become Go constants, declared with a <tt>const</tt>
declaration.
<H3><a name="Go_enumerations"></a>23.3.4 Go Enumerations</H3>
<H3><a name="Go_enumerations"></a>23.4.4 Go Enumerations</H3>
<p>
@ -296,7 +314,7 @@ usual). The values of the enumeration will become variables in Go;
code should avoid modifying those variables.
</p>
<H3><a name="Go_classes"></a>23.3.5 Go Classes</H3>
<H3><a name="Go_classes"></a>23.4.5 Go Classes</H3>
<p>
@ -374,7 +392,43 @@ returns a go interface. If the returned pointer can be null, you can check
for this by calling the Swigcptr() method.
</p>
<H4><a name="Go_class_inheritance"></a>23.3.5.1 Go Class Inheritance</H4>
<H4><a name="Go_class_memory"></a>23.4.5.1 Go Class Memory Management</H4>
<p>
Calling <tt>NewClassName</tt> for some C++ class <tt>ClassName</tt>
will allocate memory using the C++ memory allocator. This memory will
not be automatically freed by Go's garbage collector as the object ownership is
not tracked. When you are done with the C++ object you must free it manually
using <tt>DeleteClassName</tt>.
</p>
<p>
A common technique is to store the C++ object into a Go object, and
use the Go function <tt>runtime.SetFinalizer</tt> to free the C++ object when
the Go object is freed. It is strongly recommended to read the
<a href="https://golang.org/pkg/runtime/#SetFinalizer">runtime.SetFinalizer</a>
documentation before using this technique to understand its limitations.
For example, if the SWIG package is imported as "wrap":
</p>
<div class="code">
<pre>
type GoClassName struct {
w wrap.ClassName
}
func NewGoClassName() *GoClassName {
r := &amp;GoClassName{wrap.NewClassName()}
runtime.SetFinalizer(r,
func(r *GoClassName) {
wrap.DeleteClassName(r.w)
})
return r
}
</pre>
</div>
<H4><a name="Go_class_inheritance"></a>23.4.5.2 Go Class Inheritance</H4>
<p>
@ -386,7 +440,7 @@ Doing the reverse will require an explicit type assertion, which will
be checked dynamically.
</p>
<H3><a name="Go_templates"></a>23.3.6 Go Templates</H3>
<H3><a name="Go_templates"></a>23.4.6 Go Templates</H3>
<p>
@ -394,7 +448,7 @@ In order to use C++ templates in Go, you must tell SWIG to create
wrappers for a particular template instantation. To do this, use
the <tt>%template</tt> directive.
<H3><a name="Go_director_classes"></a>23.3.7 Go Director Classes</H3>
<H3><a name="Go_director_classes"></a>23.4.7 Go Director Classes</H3>
<p>
@ -437,7 +491,7 @@ method defined in Go. The Go code may of course call other methods on
itself, and those methods may be defined either in Go or in C++.
</p>
<H3><a name="Go_primitive_type_mappings"></a>23.3.8 Default Go primitive type mappings</H3>
<H3><a name="Go_primitive_type_mappings"></a>23.4.8 Default Go primitive type mappings</H3>
<p>
@ -544,7 +598,7 @@ that typemap, or add new values, to control how C/C++ types are mapped
into Go types.
</p>
<H3><a name="Go_output_arguments"></a>23.3.9 Output arguments</H3>
<H3><a name="Go_output_arguments"></a>23.4.9 Output arguments</H3>
<p>Because of limitations in the way output arguments are processed in swig,
@ -597,7 +651,7 @@ void f(char *output);
</pre>
</div>
<H3><a name="Go_adding_additional_code"></a>23.3.10 Adding additional go code</H3>
<H3><a name="Go_adding_additional_code"></a>23.4.10 Adding additional go code</H3>
<p>Often the APIs generated by swig are not very natural in go, especially if
@ -692,5 +746,144 @@ func bar() {
</pre>
</div>
<H3><a name="Go_typemaps"></a>23.4.11 Go typemaps</H3>
<p>
You can use the <tt>%typemap</tt> directive to modify SWIG's default
wrapping behavior for specific C/C++ types. You need to be familiar
with the material in the general
"<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter. That chapter
explains how to define a typemap. This section describes some
specific typemaps used for Go.
</p>
<p>
In general type conversion code may be written either in C/C++ or in
Go. The choice to make normally depends on where memory should be
allocated. To allocate memory controlled by the Go garbage collector,
write Go code. To allocate memory in the C/C++ heap, write C code.
</p>
<table BORDER summary="Go Typemaps">
<tr>
<td><b>Typemap</b></td>
<td><b>Description</b></td>
</tr>
<tr>
<td>gotype</td>
<td>
The Go type to use for a C++ type. This type will appear in the
generated Go wrapper function. If this is not defined SWIG will use a
default as <a href="#Go_primitive_type_mappings">described above</a>.
</td>
</tr>
<tr>
<td>imtype</td>
<td>
An intermediate Go type used by the "goin", "goout", "godirectorin",
and "godirectorout" typemaps. If this typemap is not defined for a
C/C++ type, the gotype typemape will be used. This is useful when
gotype is best converted to C/C++ using Go code.
</td>
</tr>
<tr>
<td>goin</td>
<td>
Go code to convert from gotype to imtype when calling a C/C++
function. SWIG will then internally convert imtype to a C/C++ type
and pass it down. If this is not defined no conversion is done.
</td>
</tr>
<tr>
<td>in</td>
<td>
C/C++ code to convert the internally generated C/C++ type, based on
imtype, into the C/C++ type that a function call expects. If this is
not defined the value will simply be cast to the desired type.
</td>
</tr>
<tr>
<td>out</td>
<td>
C/C++ code to convert the C/C++ type that a function call returns into
the internally generated C/C++ type, based on imtype, that will be
returned to Go. If this is not defined the value will simply be cast
to the desired type.
</td>
</tr>
<tr>
<td>goout</td>
<td>
Go code to convert a value returned from a C/C++ function from imtype
to gotype. If this is not defined no conversion is done.
</td>
</tr>
<tr>
<td>argout</td>
<td>
C/C++ code to adjust an argument value when returning from a function.
This is called after the real C/C++ function has run. This uses the
internally generated C/C++ type, based on imtype. This is only useful
for a pointer type of some sort. If this is not defined nothing will
be done.
</td>
</tr>
<tr>
<td>goargout</td>
<td>
Go code to adjust an argument value when returning from a function.
This is called after the real C/C++ function has run. The value will
be in imtype. This is only useful for a pointer type of some sort.
If this is not defined nothing will be done.
</td>
</tr>
<tr>
<td>directorin</td>
<td>
C/C++ code to convert the C/C++ type used to call a director method
into the internally generated C/C++ type, based on imtype, that will
be passed to Go. If this is not defined the value will simply be cast
to the desired type.
</td>
</tr>
<tr>
<td>godirectorin</td>
<td>
Go code to convert a value used to call a director method from imtype
to gotype. If this is not defined no conversion is done.
</td>
</tr>
<tr>
<td>godirectorout</td>
<td>
Go code to convert a value returned from a director method from gotype
to imtype. If this is not defined no conversion is done.
</td>
</tr>
<tr>
<td>directorout</td>
<td>
C/C++ code to convert a value returned from a director method from the
internally generated C/C++ type, based on imtype, into the type that
the method should return If this is not defined the value will simply
be cast to the desired type.
</td>
</tr>
</table>
</body>
</html>

19
Doc/Manual/Java.html
View file

@ -358,7 +358,7 @@ more aggressive from gcc-4.0 onwards and will result in code that fails with str
<p>
The name of the shared library output file is important.
If the name of your SWIG module is "<tt>example</tt>", the name of the corresponding shared library file should be "<tt>libexample.so</tt>" (or equivalent depending on your machine, see <a href="#Java_dynamic_linking_problems">Dynamic linking problems</a> for more information).
The name of the module is specified using the <tt>%module</tt> directive or<tt> -module</tt> command line option.</p>
The name of the module is specified using the <tt>%module</tt> directive or <tt>-module</tt> command line option.</p>
<H3><a name="Java_using_module"></a>25.2.5 Using your module</H3>
@ -2441,7 +2441,7 @@ It also contains all the methods in the C++ class it is proxying plus getters an
member variables. These functions call the native methods in the intermediary JNI class.
The advantage of having this extra layer is the type safety that the proxy class functions offer.
It adds static type checking which leads to fewer surprises at runtime.
For example, you can see that if you attempt to use the <tt> spam() </tt>
For example, you can see that if you attempt to use the <tt>spam()</tt>
function it will only compile when the parameters passed are an <tt>int</tt> and a <tt>Foo</tt>.
From a user's point of view, it makes the class work as if it were a Java class:
</p>
@ -4173,8 +4173,8 @@ void *malloc(size_t nbytes);
<p>
If no declaration name is given to <tt>%exception</tt>, it is applied to all wrapper functions.
The <tt> $action </tt> is a SWIG special variable and is replaced by the C/C++ function call being wrapped.
The <tt> return $null; </tt> handles all native method return types, namely those that have a void return and those that do not.
The <tt>$action</tt> is a SWIG special variable and is replaced by the C/C++ function call being wrapped.
The <tt>return $null;</tt> handles all native method return types, namely those that have a void return and those that do not.
This is useful for typemaps that will be used in native method returning all return types.
See the section on
<a href="#Java_special_variables">Java special variables</a> for further explanation.
@ -5490,6 +5490,15 @@ These are listed below:
<td>Use for mapping NULL terminated arrays of C strings to Java String arrays</td>
</tr>
<tr>
<td>unsigned char *</td>
<td>NIOBUFFER</td>
<td>various.i</td>
<td>input<br> output</td>
<td>java.nio.Buffer</td>
<td>Use for mapping directly allocated buffers to c/c++. useful with directors and long lived memory objects</td>
</tr>
</table>
<H3><a name="Java_typemap_attributes"></a>25.9.6 Java typemap attributes</H3>
@ -5570,7 +5579,7 @@ This special variable is usually used for making calls to a function in the inte
</p>
<p>
<b><tt>$null </tt></b><br>
<b><tt>$null</tt></b><br>
Used in input typemaps to return early from JNI functions that have either void or a non-void return type. Example:
</p>

31
Doc/Manual/Javascript.html
View file

@ -88,6 +88,12 @@ $ swig -javascript -jsc example.i</pre>
<pre>
$ swig -c++ -javascript -jsc example.i</pre>
</div>
<p>The V8 code that SWIG generates should work with most versions from 3.11.10 up to 3.29.14 and later.</p>
<p>Specify the V8 version when running SWIG (e.g. 3.25.30)</p>
<div class="shell">
<pre>
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
</div>
<p>This creates a C/C++ source file <code>example_wrap.c</code> or <code>example_wrap.cxx</code>. The generated C source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application to create an extension module.</p>
<p>The name of the wrapper file is derived from the name of the input file. For example, if the input file is <code>example.i</code>, the name of the wrapper file is <code>example_wrap.c</code>. To change this, you can use the -o option. The wrapped module will export one function which must be called to register the module with the Javascript interpreter. For example, if your module is named <code>example</code> the corresponding initializer for JavascriptCore would be</p>
<div class="code">
@ -129,6 +135,11 @@ $ make check-javascript-examples ENGINE=jsc</pre>
<pre>
$ make check-javascript-test-suite ENGINE=jsc</pre>
</div>
<p>You can specify a specific <code>V8</code> version for running the examples and tests</p>
<div class="shell">
<pre>
$ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
</div>
<H3><a name="Javascript_known_issues"></a>26.2.3 Known Issues</H3>
@ -184,7 +195,7 @@ $ sudo npm install -g node-gyp</pre>
<p>First create the wrapper using SWIG:</p>
<div class="shell">
<pre>
$ swig -javascript -node -c++ example.cxx</pre>
$ swig -javascript -node -c++ example.i</pre>
</div>
<p>Then run <code>node-gyp</code></p>
<div class="shell">
@ -342,8 +353,8 @@ It has some extras to configure <code>node-webkit</code>. See the <a href="https
<div class="code">
<pre>
{
"name": "example"
"main": "app.html"
"name": "example",
"main": "app.html",
"window": {
"show": true,
"width": 800,
@ -446,7 +457,7 @@ var x = 42;
var y = 105;
var g = example.gcd(x,y);
// Accessing the globak variable
// Accessing the global variable
var f = example.Foo;
example.Foo = 3.1415926;</pre>
</div>
@ -467,7 +478,7 @@ public:
}
virtual ~Shape() {
nshapes--;
};
}
double x, y;
void move(double dx, double dy);
virtual double area(void) = 0;
@ -479,7 +490,7 @@ class Circle : public Shape {
private:
double radius;
public:
Circle(double r) : radius(r) { };
Circle(double r) : radius(r) { }
virtual double area(void);
virtual double perimeter(void);
};
@ -488,7 +499,7 @@ class Square : public Shape {
private:
double width;
public:
Square(double w) : width(w) { };
Square(double w) : width(w) { }
virtual double area(void);
virtual double perimeter(void);
};</pre>
@ -765,7 +776,7 @@ class JSEmitter {
*/
virtual int exitClass(Node *) {
return SWIG_OK;
};
}
/**
* Invoked at the beginning of the variableHandler.
@ -777,7 +788,7 @@ class JSEmitter {
*/
virtual int exitVariable(Node *) {
return SWIG_OK;
};
}
/**
* Invoked at the beginning of the functionHandler.
@ -789,7 +800,7 @@ class JSEmitter {
*/
virtual int exitFunction(Node *) {
return SWIG_OK;
};
}
/**
* Invoked by functionWrapper callback after call to Language::functionWrapper.

4
Doc/Manual/Octave.html
View file

@ -59,8 +59,8 @@ Also, there are a dozen or so examples in the Examples/octave directory, and hun
<p>
As of SWIG 3.0.0, the Octave module has been tested with Octave versions 3.0.5, 3.2.4, 3.4.3, 3.6.4, and 3.8.0.
Use of Octave versions older than 3.x.x is not recommended, as these versions are no longer tested with SWIG.
As of SWIG 3.0.3, the Octave module has been tested with Octave versions 3.2.4, 3.4.3, 3.6.4, and 3.8.1.
Use of older Octave versions is not recommended, as these versions are no longer tested with SWIG.
</p>
<H2><a name="Octave_nn3"></a>32.2 Running SWIG</H2>

62
Doc/Manual/Php.html
View file

@ -29,6 +29,7 @@
<li><a href="#Php_nn2_6_2">Constructors and Destructors</a>
<li><a href="#Php_nn2_6_3">Static Member Variables</a>
<li><a href="#Php_nn2_6_4">Static Member Functions</a>
<li><a href="#Php_nn2_6_5">Specifying Implemented Interfaces</a>
</ul>
<li><a href="#Php_nn2_7">PHP Pragmas, Startup and Shutdown code</a>
</ul>
@ -113,9 +114,7 @@ more detail in <a href="#Php_nn2_6">section 27.2.6</a>.
<p>
The usual (and recommended) way is to build the extension as a separate
dynamically loaded module (which is supported by all modern operating
systems). You can then specify that this be loaded
automatically in <tt>php.ini</tt> or load it explicitly for any script which
needs it.
systems).
</p>
<p>
@ -137,16 +136,16 @@ least work for Linux though):
</p>
<div class="code"><pre>
gcc `php-config --includes` -fpic -c example_wrap.c
gcc -shared example_wrap.o -o example.so
gcc `php-config --includes` -fpic -c example_wrap.c example.c
gcc -shared example_wrap.o example.o -o example.so
</pre></div>
<H3><a name="Php_nn1_3"></a>34.1.2 Using PHP Extensions</H3>
<p>
To test the extension from a PHP script, you need to load it first. You
can load it for every script by adding this line to the <tt>[PHP]</tt> section of
To test the extension from a PHP script, you first need to tell PHP to
load it. To do this, add a line like this to the <tt>[PHP]</tt> section of
<tt>php.ini</tt>:
</p>
@ -155,8 +154,14 @@ can load it for every script by adding this line to the <tt>[PHP]</tt> section o
</pre></div>
<p>
Alternatively, you can load it explicitly only for scripts which need it
by adding this line to the start of each such PHP script::
If the module is in PHP's default extension directory, you can omit the path.
</p>
<p>
For some SAPIs (for example, the CLI SAPI) you can instead use the
<a href="http://php.net/manual/en/function.dl.php">dl() function</a> to load
an extension at run time, by adding a like like this to the start of each
PHP script which uses your extension:
</p>
<div class="code"><pre>
@ -164,14 +169,25 @@ by adding this line to the start of each such PHP script::
</pre></div>
<p>
SWIG also generates a php module, which
attempts to do the <tt>dl()</tt> call for you:
But note that this doesn't work when running PHP through a webserver in PHP5.3
and later - you'll need to use <tt>extension</tt> in <tt>php.ini</tt> as
described above.
</p>
<p>
The PHP module which SWIG generates will also attempt to do the <tt>dl()</tt>
call for you if the extension isn't already loaded:
</p>
<div class="code"><pre>
include("example.php");
</pre></div>
<p>
This PHP module also defines the PHP classes for the wrapped API, so you'll
almost certainly want to include it anyway.
</p>
<H2><a name="Php_nn2"></a>34.2 Basic PHP interface</H2>
@ -220,9 +236,9 @@ echo "E = " . E . "\n";
<p>
There's one peculiarity of how constants work in PHP which it is useful
to note (this is not specific to SWIG though) - if you try to use an undeclared
constant, PHP will issue a warning and then expand the constant to a string
version of the constant's name. The warning will often be missed though as
if you're using PHP in a webserver, it will probably end up in error.log or
constant, PHP will emit a notice and then expand the constant to a string
version of the constant's name. Unfortunately it is easy to miss the notice
if you're using PHP in a webserver, as it will probably end up in error.log or
similar.
</p>
@ -756,6 +772,24 @@ Ko::threats();
</pre></div>
<H4><a name="Php_nn2_6_5"></a>34.2.6.5 Specifying Implemented Interfaces</H4>
<p>
PHP supports the concept of abstract interfaces which a class can implement.
Since SWIG 3.0.3, you can tell SWIG that a wrapped class (for example
<code>MyIterator</code>) implements the <code>Iterator</code> interface like
so:
</p>
<div class="code"><pre>
%typemap("phpinterfaces") MyIterator "Iterator";
</pre></div>
<p>
If there are multiple interfaces, just list them separated by commas.
</p>
<H3><a name="Php_nn2_7"></a>34.2.7 PHP Pragmas, Startup and Shutdown code</H3>

20
Doc/Manual/Python.html
View file

@ -194,7 +194,7 @@ int fact(int n);
</div>
<p>
The <tt> #define SWIG_FILE_WITH_INIT </tt> line inserts a macro that specifies that the
The <tt>#define SWIG_FILE_WITH_INIT</tt> line inserts a macro that specifies that the
resulting C file should be built as a python extension, inserting the module
<tt>init</tt> code. This <tt>.i</tt> file wraps the following simple C file:
</p>
@ -395,7 +395,7 @@ of the module prefixed by an underscore</b>. If the name of your module is "<tt
name of the corresponding object file should be
"<tt>_example.so</tt>" or "<tt>_examplemodule.so</tt>".
The name of the module is specified using the <tt>%module</tt> directive or the
<tt> -module</tt> command line option.
<tt>-module</tt> command line option.
</p>
<p>
@ -783,8 +783,8 @@ Building a SWIG extension to Python under Windows is roughly similar to
the process used with Unix. Using the distutils, it is essentially
identical. If you have the same version of the MS compiler that Python
was built with (the python2.4 and python2.5 distributed by python.org
are built with Visual Studio 2003), the standard <tt> python setup.py
build </tt> should just work.
are built with Visual Studio 2003), the standard <tt>python setup.py
build</tt> should just work.
</p>
<p>
@ -3368,6 +3368,18 @@ print("Loading", "Whizz", "Bang", sep=' ... ')
</pre>
</div>
<p>When using <tt>%pythoncode</tt> and <tt>%pythonbegin</tt> you generally
want to make sure that the block is delimited by <tt>%{</tt> and <tt>%}</tt>.
If you delimit it with <tt>{</tt> and <tt>}</tt> then any lines with a
leading <tt>#</tt> will be handled by SWIG as preprocessor directives, when
you probably meant them as Python comments. Prior to SWIG 3.0.3, invalid
preprocessor directives were silently ignored, so generally using the wrong
delimiters resulted in such comments not appearing in the generated output
(though a comment starting with a valid preprocessor directive could cause
problems, for example: <tt># error handling</tt>). SWIG 3.0.3 and later report
an error for invalid preprocessor directives, so you may have to update
existing interface files to delimit blocks of Python code correctly.</p>
<p>Sometimes you may want to replace or modify the wrapper function
that SWIG creates in the proxy <tt>.py</tt> file. The Python module
in SWIG provides some features that enable you to do this. First, to

40
Doc/Manual/Ruby.html
View file

@ -147,7 +147,7 @@
<H2><a name="Ruby_nn2"></a>38.1 Preliminaries</H2>
<p> SWIG 1.3 is known to work with Ruby versions 1.6 and later.
<p> SWIG 3.0 is known to work with Ruby versions 1.8 and later.
Given the choice, you should use the latest stable version of Ruby. You
should also determine if your system supports shared libraries and
dynamic loading. SWIG will work with or without dynamic loading, but
@ -191,7 +191,7 @@ header file. This file is usually contained in a directory such as </p>
<div class="code shell diagram">
<pre>/usr/lib/ruby/1.8/x86_64-linux-gnu/ruby.h
/usr/local/lib/ruby/1.6/i686-linux/ruby.h
/usr/include/ruby-2.1.0/ruby.h
</pre>
</div>
@ -201,8 +201,14 @@ installed, you can run Ruby to find out. For example: </p>
<div class="code shell">
<pre>$ ruby -e 'puts $:.join("\n")'
/usr/local/lib/ruby/site_ruby/1.6 /usr/local/lib/ruby/site_ruby/1.6/i686-linux
/usr/local/lib/ruby/site_ruby /usr/local/lib/ruby/1.6 /usr/local/lib/ruby/1.6/i686-linux .
/usr/local/lib/site_ruby/2.1.0
/usr/local/lib/x86_64-linux-gnu/site_ruby
/usr/local/lib/site_ruby
/usr/lib/ruby/vendor_ruby/2.1.0
/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.1.0
/usr/lib/ruby/vendor_ruby
/usr/lib/ruby/2.1.0
/usr/lib/x86_64-linux-gnu/ruby/2.1.0
</pre>
</div>
@ -260,7 +266,7 @@ operating system would look something like this: </p>
<div class="code shell">
<pre>$ swig -ruby example.i
$ gcc -O2 -fPIC -c example.c
$ gcc -O2 -fPIC -c example_wrap.c -I/usr/local/lib/ruby/1.6/i686-linux
$ gcc -O2 -fPIC -c example_wrap.c -I/usr/include/ruby-2.1.0
$ gcc -shared example.o example_wrap.o -o example.so
</pre>
</div>
@ -334,7 +340,7 @@ using the C++ compiler. For example: </p>
<pre>
$ swig -c++ -ruby example.i
$ g++ -fPIC -c example.cxx
$ g++ -fPIC -c example_wrap.cxx -I/usr/local/lib/ruby/1.6/i686-linux
$ g++ -fPIC -c example_wrap.cxx -I/usr/include/ruby-2.1.0
$ g++ -shared example.o example_wrap.o -o example.so
</pre>
</div>
@ -685,7 +691,7 @@ For example, this struct declaration: </p>
</div>
<p> gets wrapped as a <tt>Vector</tt> class, with
Ruby instance methods <tt>x</tt>, <tt> x=</tt>,
Ruby instance methods <tt>x</tt>, <tt>x=</tt>,
<tt>y</tt> and <tt>y=</tt>. These methods can
be used to access structure data from Ruby as follows: </p>
@ -1313,7 +1319,7 @@ chapter.</p>
<p>Some containers in the STL allow you to modify their default
behavior by using so called functors or function objects.
Functors are often just a very simple struct with<tt> operator()</tt>
Functors are often just a very simple struct with <tt>operator()</tt>
redefined or an actual C/C++ function. This allows you, for
example, to always keep the sort order of a STL container to your
liking.</p>
@ -1327,7 +1333,7 @@ this includes <tt>std::set</tt>,
<tt>std::multiset</tt>
and <tt>std::multimap</tt>.</p>
<p>The functors in swig are called<tt> swig::UnaryFunction</tt>
<p>The functors in swig are called <tt>swig::UnaryFunction</tt>
and <tt>swig::BinaryFunction</tt>.
For C++ predicates (ie. functors that must return bool as a result) <tt>swig::UnaryPredicate</tt>
@ -1380,8 +1386,8 @@ values they point at, while the non-const iterators can both read and
modify the values.</p>
<p>The Ruby STL wrappings support both type of iterators by using
a proxy class in-between. This proxy class is <tt>swig::Iterator or
swig::ConstIterator. </tt> Derived from them are template
a proxy class in-between. This proxy class is <tt>swig::Iterator</tt> or
<tt>swig::ConstIterator</tt>. Derived from them are template
classes that need to be initialized with the actual iterator for the
container you are wrapping and often times with the beginning and
ending points of the iteration range.</p>
@ -1450,7 +1456,7 @@ i
</pre>
</div>
<p>If you'd rather have STL classes without any iterators, you should define<tt> -DSWIG_NO_EXPORT_ITERATOR_METHODS </tt>when running swig.</p>
<p>If you'd rather have STL classes without any iterators, you should define <tt>-DSWIG_NO_EXPORT_ITERATOR_METHODS</tt> when running swig.</p>
<H3><a name="Ruby_nn24"></a>38.3.16 C++ Smart Pointers</H3>
@ -2823,7 +2829,7 @@ 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="http://www.swig.org/Doc1.3/SWIGDocumentation.html#SWIG_default_args">
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>
@ -3017,7 +3023,7 @@ catch(char const *_e) {
<p> Note that if your methods do not have an exception
specification yet they do throw exceptions, SWIG cannot know how to
deal with them. For a neat way to handle these, see the <a href="http://www.swig.org/Doc1.3/SWIGDocumentation.html#exception">Exception
deal with them. For a neat way to handle these, see the <a href="Customization.html#Customization_exception">Exception
handling with %exception</a> section.</p>
<H4><a name="Ruby_directorin_typemap"></a>38.7.6.14 directorin typemap</H4>
@ -4466,7 +4472,7 @@ and then type <tt>make</tt> to build the shared library: </p>
<pre>$ <b>ruby extconf.rb</b>
creating Makefile
$ <b>make</b>
g++ -fPIC -g -O2 -I. -I/usr/local/lib/ruby/1.7/i686-linux \
g++ -fPIC -g -O2 -I. -I/usr/include/ruby-2.1.0 \
-I. -c shape_wrap.cxx
gcc -shared -L/usr/local/lib -o shape.so shape_wrap.o -L. \
-lruby -lruby -lc</pre>
@ -4997,7 +5003,7 @@ object from its underlying C++ object.</p>
<p>In general, you will only need to use the <tt>SWIG_RubyInstanceFor</tt>,
which is required for implementing mark functions as shown below.
However, if you implement your own free functions (see below) you may
also have to call the<tt> SWIG_RubyRemoveTracking</tt> and <tt>RubyUnlinkObjects</tt>
also have to call the <tt>SWIG_RubyRemoveTracking</tt> and <tt>RubyUnlinkObjects</tt>
methods.</p>
<H3><a name="Ruby_nn61"></a>38.10.4 Mark Functions</H3>
@ -5351,7 +5357,7 @@ used for callbacks, for example. </p>
<p>To solve the problem, SWIG can now generate code with director
functions containing the optional macros SWIG_INIT_STACK and
SWIG_RELEASE_STACK. These macros will try to force Ruby to
reinitiliaze the beginning of the stack the first time a
reinitialize the beginning of the stack the first time a
director
function is called. This will lead Ruby to measure and not
collect any VALUE objects defined from that point on. </p>

9
Doc/Manual/SWIG.html
View file

@ -138,6 +138,7 @@ can be obtained by typing <tt>swig -help</tt> or <tt>swig
-xml Generate XML wrappers
-c++ Enable C++ parsing
-cppext <em>ext</em> Change file extension of C++ generated files to <em>ext</em> (default is cxx, except for PHP which uses cpp)
-D<em>symbol</em> Define a preprocessor symbol
-Fstandard Display error/warning messages in commonly used format
-Fmicrosoft Display error/warning messages in Microsoft format
@ -146,7 +147,7 @@ can be obtained by typing <tt>swig -help</tt> or <tt>swig
-l<em>file</em> Include a SWIG library file.
-module <em>name</em> Set the name of the SWIG module
-o <em>outfile</em> Name of output file
-outcurrentdir Set default output dir to current dir instead of input file's path
-outcurrentdir Set default output dir to current dir instead of input file's path
-outdir <em>dir</em> Set language specific files output directory
-pcreversion Display PCRE version information
-swiglib Show location of SWIG library
@ -1046,7 +1047,7 @@ def filecopy(source,target):
</pre></div>
<p>
In this case <tt>f1</tt>,<tt> f2</tt>, and <tt>buffer</tt> are all
In this case <tt>f1</tt>, <tt>f2</tt>, and <tt>buffer</tt> are all
opaque objects containing C pointers. It doesn't matter what value
they contain--our program works just fine without this knowledge.</p>
@ -1711,7 +1712,7 @@ wrapping a header file like this:
</pre></div>
<p>
<tt>%rename </tt>applies a renaming operation to all future
<tt>%rename</tt> applies a renaming operation to all future
occurrences of a name. The renaming applies to functions, variables,
class and structure names, member functions, and member data. For
example, if you had two-dozen C++ classes, all with a member function
@ -3316,7 +3317,7 @@ Most importantly, define a type before it is used! A C compiler will tell you
if the full type information is not available if it is needed, whereas
SWIG will usually not warn or error out as it is designed to work without
full type information. However, if type information is not specified
correctly, the wrappers can be sub-optimal and even result in uncompileable C/C++ code.
correctly, the wrappers can be sub-optimal and even result in uncompilable C/C++ code.
<li>If your program has a main() function, you may need to rename it
(read on).

78
Doc/Manual/SWIGPlus.html
View file

@ -1184,15 +1184,17 @@ public:
</div>
<p>
This produces uncompileable wrapper code because default values in C++ are
This produces uncompilable wrapper code because default values in C++ are
evaluated in the same scope as the member function whereas SWIG
evaluates them in the scope of a wrapper function (meaning that the
values have to be public).
</p>
<p>
This feature is automatically turned on when wrapping <a href="SWIG.html#SWIG_default_args">C code with default arguments</a>
and whenever keyword arguments (kwargs) are specified for either C or C++ code.
The <tt>compactdefaultargs</tt> feature is automatically turned on when wrapping <a href="SWIG.html#SWIG_default_args">C code with default arguments</a>.
Some target languages will also automatically turn on this feature
if the keyword arguments feature (kwargs) is specified for either C or C++ functions, and the target language supports kwargs,
the <tt>compactdefaultargs</tt> feature is also automatically turned on.
Keyword arguments are a language feature of some scripting languages, for example Ruby and Python.
SWIG is unable to support kwargs when wrapping overloaded methods, so the default approach cannot be used.
</p>
@ -1203,7 +1205,7 @@ SWIG is unable to support kwargs when wrapping overloaded methods, so the defaul
<p>
SWIG wraps class members that are public following the C++
conventions, i.e., by explicit public declaration or by the use of
the <tt> using</tt> directive. In general, anything specified in a
the <tt>using</tt> directive. In general, anything specified in a
private or protected section will be ignored, although the internal
code generator sometimes looks at the contents of the private and
protected sections so that it can properly generate code for default
@ -2798,7 +2800,7 @@ public:
</pre></div>
<p>
This code adds a<tt> __str__</tt> method to our class for producing a
This code adds a <tt>__str__</tt> method to our class for producing a
string representation of the object. In Python, such a method would
allow us to print the value of an object using the <tt>print</tt>
command.
@ -2847,12 +2849,12 @@ struct Derived : Base {
<p>
The following special variables are expanded if used within a %extend block:
$name, $symname, $overname, $decl, $fulldecl, $parentname and $parentsymname.
$name, $symname, $overname, $decl, $fulldecl, $parentclassname and $parentclasssymname.
The <a href="Customization.html#Customization_exception_special_variables">Special variables</a> section provides more information each of these special variables.
</p>
<p>
The<tt> %extend</tt> directive follows all of the same conventions
The <tt>%extend</tt> directive follows all of the same conventions
as its use with C structures. Please refer to the <a href="SWIG.html#SWIG_adding_member_functions">Adding member functions to C structures</a>
section for further details.
</p>
@ -3565,7 +3567,7 @@ It is also possible to separate these declarations from the template class. For
template&lt;class T&gt; class List {
...
public:
List() { };
List() { }
T get(int index);
...
};
@ -3612,18 +3614,52 @@ and the second will take two integer arguments.
</p>
<p>
Needless to say, SWIG's template support provides plenty of
opportunities to break the universe. That said, an important final
point is that <b>SWIG does not perform extensive error checking of
templates!</b> Specifically, SWIG does not perform type checking nor
does it check to see if the actual contents of the template
declaration make any sense. Since the C++ compiler will hopefully
check this when it compiles the resulting wrapper file, there is no
practical reason for SWIG to duplicate this functionality (besides,
none of the SWIG developers are masochistic enough to want to
implement this right now).
Needless to say, SWIG's template support provides plenty of opportunities to
break the universe. That said, an important final point is that <b>SWIG does
not perform extensive error checking of templates!</b> Specifically, SWIG does
not perform type checking nor does it check to see if the actual contents of the
template declaration make any sense. Since the C++ compiler checks this when it
compiles the resulting wrapper file, there is no practical reason for SWIG to
duplicate this functionality.
</p>
<a name="SWIGPlus_template_nested_class_example"></a>
<p>
As SWIG's template support does not perform type checking <tt>%template</tt>
can be used as early as after a template declaration. You can, and rarely have
to, use <tt>%template</tt> before the template parameters have been declared.
For example:
</p>
<div class="code">
<pre>
template &lt;class T&gt; class OuterTemplateClass {};
// The nested class OuterClass::InnerClass inherits from the template class
// OuterTemplateClass&lt;OuterClass::InnerStruct&gt; and thus the template needs
// to be expanded with %template before the OuterClass declaration.
%template(OuterTemplateClass_OuterClass__InnerStruct)
OuterTemplateClass&lt;OuterClass::InnerStruct&gt;
// Don't forget to use %feature("flatnested") for OuterClass::InnerStruct and
// OuterClass::InnerClass if the target language doesn't support nested classes.
class OuterClass {
public:
// Forward declarations:
struct InnerStruct;
class InnerClass;
};
struct OuterClass::InnerStruct {};
// Expanding the template at this point with %template is too late as the
// OuterClass::InnerClass declaration is processed inside OuterClass.
class OuterClass::InnerClass : public OuterTemplateClass&lt;InnerStruct&gt; {};
</pre>
</div>
<p>
<b>Compatibility Note</b>: The first implementation of template support relied heavily on
macro expansion in the preprocessor. Templates have been more tightly integrated into
@ -4998,6 +5034,12 @@ class Bar {
</pre>
</div>
<p>
If a nested class, within an outer class, has to be used as a template parameter within the outer class, then the template will
have to be instantiated with <tt>%template</tt> before the beginning of the outer class.
An example can be found in the
<a href="#SWIGPlus_template_nested_class_example">Templates</a> section.
</p>
<p>
<b>Compatibility Note:</b>

2
Doc/Manual/Sections.html
View file

@ -6,7 +6,7 @@
<body bgcolor="#ffffff">
<H1><a name="Sections"></a>SWIG-3.0 Documentation</H1>
Last update : SWIG-3.0.2 (4 Jun 2014)
Last update : SWIG-3.0.5 (in progress)
<H2>Sections</H2>

20
Doc/Manual/Tcl.html
View file

@ -160,7 +160,7 @@ of the module. If the name of your SWIG module is "<tt>example</tt>", the
name of the corresponding object file should be
"<tt>example.so</tt>".
The name of the module is specified using the <tt>%module</tt> directive or the
<tt> -module</tt> command line option.
<tt>-module</tt> command line option.
</p>
<H3><a name="Tcl_nn5"></a>39.1.3 Static linking</H3>
@ -504,7 +504,7 @@ name, but you can override it using the <tt>-prefix</tt> option.
</p>
<p>
When the<tt> -namespace</tt> option is used, objects in the module
When the <tt>-namespace</tt> option is used, objects in the module
are always accessed with the namespace name such as <tt>Foo::bar</tt>.
</p>
@ -1283,7 +1283,7 @@ you can use it in Tcl like this:
% x insert Lager
% x get 1
Stout
% puts [l cget -length]
% puts [x cget -length]
3
%
</pre></div>
@ -2365,7 +2365,7 @@ Tcl extension by specifying the following in an interface file :
$action // Gets substituted by actual function call
}
catch (RangeError) {
Tcl_SetStringObj(tcl_result,"Array index out-of-bounds");
Tcl_SetResult(interp, (char *)"Array index out-of-bounds", TCL_STATIC);
return TCL_ERROR;
}
}
@ -2384,7 +2384,7 @@ exception handler to only apply to specific methods like this:
$action
}
catch (RangeError) {
Tcl_SetStringObj(tcl_result,"Array index out-of-bounds");
Tcl_SetResult(interp, (char *)"Array index out-of-bounds", TCL_STATIC);
return TCL_ERROR;
}
}
@ -2394,7 +2394,7 @@ exception handler to only apply to specific methods like this:
$action
}
catch (RangeError) {
Tcl_SetStringObj(tcl_result,"Array index out-of-bounds");
Tcl_SetResult(interp, (char *)"Array index out-of-bounds", TCL_STATIC);
return TCL_ERROR;
}
}
@ -2419,7 +2419,7 @@ For example:
$action
}
catch (RangeError) {
Tcl_SetStringObj(tcl_result,"Array index out-of-bounds");
Tcl_SetResult(interp, (char *)"Array index out-of-bounds", TCL_STATIC);
return TCL_ERROR;
}
}
@ -2921,7 +2921,6 @@ int Tcl_GetDoubleFromObj(Tcl_Interp *, Tcl_Obj *o, double *dp);
<div class="code">
<pre>
Tcl_Obj *Tcl_NewStringObj(char *str, int len);
void Tcl_SetStringObj(Tcl_Obj *obj, char *str, int len);
char *Tcl_GetStringFromObj(Tcl_Obj *obj, int *len);
void Tcl_AppendToObj(Tcl_Obj *obj, char *str, int len);
</pre>
@ -3037,9 +3036,10 @@ work)
<div class="code">
<pre>
%typemap(out) char * {
Tcl_SetStringObj($result,$1);
%typemap(out,noblock=1,fragment="SWIG_FromCharPtr") char *, const char * {
Tcl_SetObjResult(interp,SWIG_FromCharPtr((const char *)$1));
}
</pre>
</div>

18
Doc/Manual/Typemaps.html
View file

@ -2050,6 +2050,22 @@ wrap_foo() {
</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).
@ -3360,7 +3376,7 @@ list of strings like this:
</div>
<p>
To do this, you not only need to map a list of strings to <tt> char *argv[]</tt>, but the
To do this, you not only need to map a list of strings to <tt>char *argv[]</tt>, but the
value of <tt>int argc</tt> is implicitly determined by the length of the list. Using only simple
typemaps, this type of conversion is possible, but extremely painful.
Multi-argument typemaps help in this situation.

4
Doc/Manual/Warnings.html
View file

@ -349,9 +349,9 @@ These can be overridden using command line options, for example:
<div class="shell"><pre>
$ swig -python -Fstandard example.i
example.i:4: Syntax error in input.
example.i:4: Syntax error in input(1).
$ swig -python -Fmicrosoft example.i
example.i(4) : Syntax error in input.
example.i(4) : Syntax error in input(1).
</pre></div>
<H2><a name="Warnings_nn9"></a>15.9 Warning number reference</H2>