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

Merge latest master into doxygen branch.

Browse source
This commit is contained in:
Vadim Zeitlin 2014-12-15 02:54:57 +01:00
commit 9b857e6cf1
275 changed files with 6821 additions and 2094 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;
}
%}

3
Doc/Manual/Contents.html
View file

@ -854,6 +854,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 +862,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 +1417,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>

176
Doc/Manual/Go.html
View file

@ -23,6 +23,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 +31,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>
@ -374,7 +376,40 @@ 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.3.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. When you are
done with the C++ object you must free it 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. 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.3.5.2 Go Class Inheritance</H4>
<p>
@ -692,5 +727,144 @@ func bar() {
</pre>
</div>
<H3><a name="Go_typemaps"></a>23.3.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,15 @@ 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 +153,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 +168,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 +235,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 +771,23 @@ 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>

8
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>

14
Doc/Manual/Ruby.html
View file

@ -685,7 +685,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 +1313,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 +1327,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 +1380,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 +1450,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>
@ -4997,7 +4997,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>

6
Doc/Manual/SWIG.html
View file

@ -1046,7 +1046,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 +1711,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 +3316,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).

18
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);
...
};

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.