Update documentation to use the right div class="targetlang" and such.
The only docs left to update are the individual language chapters. git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@7081 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
John Lenz
parent
fa7c87f4bb
commit
9e9f5d84b3
13 changed files with 161 additions and 161 deletions
|
|
@ -98,7 +98,7 @@ When the resulting module is created, you can now use the function
|
||||||
like this (shown for Python):
|
like this (shown for Python):
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> a = add(3,4)
|
>>> a = add(3,4)
|
||||||
>>> print a
|
>>> print a
|
||||||
7
|
7
|
||||||
|
|
@ -153,7 +153,7 @@ void getwinsize(int winid, int *width, int *height);
|
||||||
In this case, the function returns multiple values, allowing it to be used like this:
|
In this case, the function returns multiple values, allowing it to be used like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> w,h = genwinsize(wid)
|
>>> w,h = genwinsize(wid)
|
||||||
>>> print w
|
>>> print w
|
||||||
400
|
400
|
||||||
|
|
@ -234,7 +234,7 @@ extern double add(double *INPUT, double *INPUT);
|
||||||
When the function is used in the scripting language interpreter, it will work like this:
|
When the function is used in the scripting language interpreter, it will work like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
result = add(3,4)
|
result = add(3,4)
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -297,7 +297,7 @@ extern int foo(double a, double b, double *OUTPUT);
|
||||||
The function will return two values like this:
|
The function will return two values like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
iresult, dresult = foo(3.5, 2)
|
iresult, dresult = foo(3.5, 2)
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -347,7 +347,7 @@ extern void negate(double *INOUT);
|
||||||
<p>
|
<p>
|
||||||
Now within a script, you can simply call the function normally :</p>
|
Now within a script, you can simply call the function normally :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
a = negate(3); # a = -3 after calling this
|
a = negate(3); # a = -3 after calling this
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -82,7 +82,7 @@ Once a contract has been specified, it modifies the behavior of the
|
||||||
resulting module. For example:
|
resulting module. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
>>> example.sqrt(2)
|
>>> example.sqrt(2)
|
||||||
1.4142135623730951
|
1.4142135623730951
|
||||||
|
|
|
||||||
|
|
@ -425,7 +425,7 @@ As arguments, <tt>SWIG_exception()</tt> takes an error type code (an
|
||||||
integer) and an error message string. The currently supported error
|
integer) and an error message string. The currently supported error
|
||||||
types are :</p>
|
types are :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="diagram"><pre>
|
||||||
SWIG_MemoryError
|
SWIG_MemoryError
|
||||||
SWIG_IOError
|
SWIG_IOError
|
||||||
SWIG_RuntimeError
|
SWIG_RuntimeError
|
||||||
|
|
|
||||||
|
|
@ -291,7 +291,7 @@ The current C++ parser handles a subset of C++. Most incompatibilities with C a
|
||||||
subtle aspects of how SWIG parses declarations. Specifically, SWIG expects all C/C++ declarations to follow this general form:
|
subtle aspects of how SWIG parses declarations. Specifically, SWIG expects all C/C++ declarations to follow this general form:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
<em>storage</em> <em>type</em> <em>declarator</em> <em>initializer</em>;
|
<em>storage</em> <em>type</em> <em>declarator</em> <em>initializer</em>;
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -395,7 +395,7 @@ The parse tree structure and tag names of an interface can be displayed using <t
|
||||||
For example:
|
For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ <b>swig -c++ -python -dump_tags example.i</b>
|
$ <b>swig -c++ -python -dump_tags example.i</b>
|
||||||
. top (example.i:1)
|
. top (example.i:1)
|
||||||
|
|
@ -453,7 +453,7 @@ pairs. Internally, the nodes are simply represented by hash tables. A display
|
||||||
the parse-tree structure can be obtained using <tt>swig -dump_tree</tt>. For example:
|
the parse-tree structure can be obtained using <tt>swig -dump_tree</tt>. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ swig -c++ -python -dump_tree example.i
|
$ swig -c++ -python -dump_tree example.i
|
||||||
...
|
...
|
||||||
|
|
@ -683,7 +683,7 @@ void foo(Bar *b);
|
||||||
Now, running SWIG:
|
Now, running SWIG:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ swig -dump_tree example.i
|
$ swig -dump_tree example.i
|
||||||
...
|
...
|
||||||
|
|
@ -733,7 +733,7 @@ void foo(Bar *b);
|
||||||
When you run SWIG on this you now get:
|
When you run SWIG on this you now get:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ ./swig example.i
|
$ ./swig example.i
|
||||||
example.i:6. Overloaded declaration ignored. foo_d(double )
|
example.i:6. Overloaded declaration ignored. foo_d(double )
|
||||||
|
|
@ -777,7 +777,7 @@ given prototype. When a feature is added, it shows up as an attribute in the <
|
||||||
You can see this when running with the <tt>-dump_tree</tt> option. For example:
|
You can see this when running with the <tt>-dump_tree</tt> option. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
+++ cdecl ----------------------------------------
|
+++ cdecl ----------------------------------------
|
||||||
| sym:name - "getitem"
|
| sym:name - "getitem"
|
||||||
|
|
@ -828,7 +828,7 @@ When the parser constructs a node for the member <tt>bar</tt>, it creates a raw
|
||||||
attributes:
|
attributes:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
nodeType : cdecl
|
nodeType : cdecl
|
||||||
name : bar
|
name : bar
|
||||||
|
|
@ -844,7 +844,7 @@ sym:name : bar
|
||||||
To produce wrapper code, this "cdecl" node undergoes a number of transformations. First, the node is recognized as a function declaration. This adjusts some of the type information--specifically, the declarator is joined with the base datatype to produce this:
|
To produce wrapper code, this "cdecl" node undergoes a number of transformations. First, the node is recognized as a function declaration. This adjusts some of the type information--specifically, the declarator is joined with the base datatype to produce this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
nodeType : cdecl
|
nodeType : cdecl
|
||||||
name : bar
|
name : bar
|
||||||
|
|
@ -862,7 +862,7 @@ member function. This produces a transformation to a low-level
|
||||||
accessor function like this:
|
accessor function like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
nodeType : cdecl
|
nodeType : cdecl
|
||||||
name : bar
|
name : bar
|
||||||
|
|
@ -1795,7 +1795,7 @@ Internally, types are represented as strings that are constructed in a very
|
||||||
precise manner. Here are some examples:
|
precise manner. Here are some examples:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
C datatype SWIG encoding (strings)
|
C datatype SWIG encoding (strings)
|
||||||
----------------------------- --------------------------
|
----------------------------- --------------------------
|
||||||
|
|
@ -1819,7 +1819,7 @@ a "pointer to a function(int,double) that returns int".
|
||||||
The following operator encodings are used in type strings:
|
The following operator encodings are used in type strings:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
Operator Meaning
|
Operator Meaning
|
||||||
------------------- -------------------------------
|
------------------- -------------------------------
|
||||||
|
|
@ -1846,7 +1846,7 @@ is expected. For instance, here is
|
||||||
an extremely perverted example:
|
an extremely perverted example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
`p.a(10).p.f(int,p.f(int).int)` foo(int, int (*x)(int));
|
`p.a(10).p.f(int,p.f(int).int)` foo(int, int (*x)(int));
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1856,7 +1856,7 @@ an extremely perverted example:
|
||||||
This corresponds to the immediately obvious C declaration:
|
This corresponds to the immediately obvious C declaration:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
(*(*foo(int,int (*)(int)))[10])(int,int (*)(int));
|
(*(*foo(int,int (*)(int)))[10])(int,int (*)(int));
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2139,7 +2139,7 @@ typedef int Size;
|
||||||
produces two trees like this:
|
produces two trees like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
int p.Integer
|
int p.Integer
|
||||||
^ ^ ^ ^
|
^ ^ ^ ^
|
||||||
|
|
@ -2169,7 +2169,7 @@ resolving types, the process starts in the leaf nodes and moves up
|
||||||
the tree towards the root. Here are a few examples that show how it works:
|
the tree towards the root. Here are a few examples that show how it works:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
Original type After typedef_resolve()
|
Original type After typedef_resolve()
|
||||||
------------------------ -----------------------
|
------------------------ -----------------------
|
||||||
|
|
@ -2185,7 +2185,7 @@ For complicated types, the process can be quite involved. Here is the
|
||||||
reduction of a function pointer:
|
reduction of a function pointer:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
p.f(Integer, p.IntegerPtr, Size).Integer : Start
|
p.f(Integer, p.IntegerPtr, Size).Integer : Start
|
||||||
p.f(Integer, p.IntegerPtr, Size).int
|
p.f(Integer, p.IntegerPtr, Size).int
|
||||||
|
|
@ -2318,7 +2318,7 @@ functions and templates. Parameter list are represented as a list of
|
||||||
nodes with the following attributes:
|
nodes with the following attributes:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"type" - Parameter type (required)
|
"type" - Parameter type (required)
|
||||||
"name" - Parameter name (optional)
|
"name" - Parameter name (optional)
|
||||||
|
|
@ -2332,7 +2332,7 @@ Typically parameters are denoted in the source by using a typename of
|
||||||
code like this:
|
code like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
Parm *parms;
|
Parm *parms;
|
||||||
Parm *p;
|
Parm *p;
|
||||||
|
|
@ -2510,7 +2510,7 @@ Next, at the top level of the SWIG distribution, re-run the <tt>autogen.sh</tt>
|
||||||
to regenerate the various build files:
|
to regenerate the various build files:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ <b>sh autogen.sh</b>
|
$ <b>sh autogen.sh</b>
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2520,7 +2520,7 @@ $ <b>sh autogen.sh</b>
|
||||||
Next re-run <tt>configure</tt> to regenerate all of the Makefiles:
|
Next re-run <tt>configure</tt> to regenerate all of the Makefiles:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ <b>./configure</b>
|
$ <b>./configure</b>
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2530,7 +2530,7 @@ $ <b>./configure</b>
|
||||||
Finally, rebuild SWIG with your module added:
|
Finally, rebuild SWIG with your module added:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ <b>make</b>
|
$ <b>make</b>
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2974,7 +2974,7 @@ A declaration is parsed as "storage T D" where storage is a storage class, T is
|
||||||
and D is a declarator.
|
and D is a declarator.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Declarator name
|
"name" - Declarator name
|
||||||
"type" - Base type T
|
"type" - Base type T
|
||||||
|
|
@ -2995,7 +2995,7 @@ and D is a declarator.
|
||||||
C++ constructor declaration.
|
C++ constructor declaration.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of constructor
|
"name" - Name of constructor
|
||||||
"parms" - Parameters
|
"parms" - Parameters
|
||||||
|
|
@ -3014,7 +3014,7 @@ C++ constructor declaration.
|
||||||
C++ destructor declaration.
|
C++ destructor declaration.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of destructor
|
"name" - Name of destructor
|
||||||
"code" - Function body code (if any)
|
"code" - Function body code (if any)
|
||||||
|
|
@ -3032,7 +3032,7 @@ C++ destructor declaration.
|
||||||
C++ access change.
|
C++ access change.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"kind" - public, protected, private
|
"kind" - public, protected, private
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -3047,7 +3047,7 @@ C++ access change.
|
||||||
Constant created by %constant or #define.
|
Constant created by %constant or #define.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of constant.
|
"name" - Name of constant.
|
||||||
"type" - Base type.
|
"type" - Base type.
|
||||||
|
|
@ -3065,7 +3065,7 @@ Constant created by %constant or #define.
|
||||||
C++ class definition or C structure definition.
|
C++ class definition or C structure definition.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of the class.
|
"name" - Name of the class.
|
||||||
"kind" - Class kind ("struct", "union", "class")
|
"kind" - Class kind ("struct", "union", "class")
|
||||||
|
|
@ -3087,7 +3087,7 @@ C++ class definition or C structure definition.
|
||||||
Enumeration.
|
Enumeration.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of the enum (if supplied).
|
"name" - Name of the enum (if supplied).
|
||||||
"storage" - Storage class (if any)
|
"storage" - Storage class (if any)
|
||||||
|
|
@ -3105,7 +3105,7 @@ Enumeration.
|
||||||
Enumeration value.
|
Enumeration value.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of the enum value.
|
"name" - Name of the enum value.
|
||||||
"type" - Type (integer or char)
|
"type" - Type (integer or char)
|
||||||
|
|
@ -3122,7 +3122,7 @@ Enumeration value.
|
||||||
C++ namespace.
|
C++ namespace.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of the namespace.
|
"name" - Name of the namespace.
|
||||||
"symtab" - Symbol table for enclosed scope.
|
"symtab" - Symbol table for enclosed scope.
|
||||||
|
|
@ -3140,7 +3140,7 @@ C++ namespace.
|
||||||
C++ using directive.
|
C++ using directive.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of the object being referred to.
|
"name" - Name of the object being referred to.
|
||||||
"uname" - Qualified name actually given to using.
|
"uname" - Qualified name actually given to using.
|
||||||
|
|
@ -3158,7 +3158,7 @@ C++ using directive.
|
||||||
A forward C++ class declaration.
|
A forward C++ class declaration.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of the class.
|
"name" - Name of the class.
|
||||||
"kind" - Class kind ("union", "struct", "class")
|
"kind" - Class kind ("union", "struct", "class")
|
||||||
|
|
@ -3175,7 +3175,7 @@ Code insertion directive. For example, %{ ... %} or
|
||||||
%insert(section).
|
%insert(section).
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"code" - Inserted code
|
"code" - Inserted code
|
||||||
"section" - Section name ("header", "wrapper", etc.)
|
"section" - Section name ("header", "wrapper", etc.)
|
||||||
|
|
@ -3190,7 +3190,7 @@ Code insertion directive. For example, %{ ... %} or
|
||||||
Top of the parse tree.
|
Top of the parse tree.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"module" - Module name
|
"module" - Module name
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -3204,7 +3204,7 @@ Top of the parse tree.
|
||||||
%extend directive.
|
%extend directive.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Module name
|
"name" - Module name
|
||||||
"symtab" - Symbol table of enclosed scope.
|
"symtab" - Symbol table of enclosed scope.
|
||||||
|
|
@ -3219,7 +3219,7 @@ Top of the parse tree.
|
||||||
%apply pattern { patternlist }.
|
%apply pattern { patternlist }.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"pattern" - Source pattern.
|
"pattern" - Source pattern.
|
||||||
"symtab" - Symbol table of enclosed scope.
|
"symtab" - Symbol table of enclosed scope.
|
||||||
|
|
@ -3234,7 +3234,7 @@ Top of the parse tree.
|
||||||
%clear patternlist;
|
%clear patternlist;
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"firstChild" - Patterns to clear
|
"firstChild" - Patterns to clear
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -3248,7 +3248,7 @@ Top of the parse tree.
|
||||||
%include directive.
|
%include directive.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Filename
|
"name" - Filename
|
||||||
"firstChild" - Children
|
"firstChild" - Children
|
||||||
|
|
@ -3263,7 +3263,7 @@ Top of the parse tree.
|
||||||
%import directive.
|
%import directive.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Filename
|
"name" - Filename
|
||||||
"firstChild" - Children
|
"firstChild" - Children
|
||||||
|
|
@ -3279,7 +3279,7 @@ Top of the parse tree.
|
||||||
%module directive.
|
%module directive.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name of the module
|
"name" - Name of the module
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -3294,7 +3294,7 @@ Top of the parse tree.
|
||||||
%typemap directive.
|
%typemap directive.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"method" - Typemap method name.
|
"method" - Typemap method name.
|
||||||
"code" - Typemap code.
|
"code" - Typemap code.
|
||||||
|
|
@ -3311,7 +3311,7 @@ Top of the parse tree.
|
||||||
%typemap directive with copy.
|
%typemap directive with copy.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"method" - Typemap method name.
|
"method" - Typemap method name.
|
||||||
"pattern" - Typemap source pattern.
|
"pattern" - Typemap source pattern.
|
||||||
|
|
@ -3328,7 +3328,7 @@ Top of the parse tree.
|
||||||
%typemap pattern. Used with %apply, %clear, %typemap.
|
%typemap pattern. Used with %apply, %clear, %typemap.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"pattern" - Typemap pattern (a parameter list)
|
"pattern" - Typemap pattern (a parameter list)
|
||||||
"parms" - Typemap parameters.
|
"parms" - Typemap parameters.
|
||||||
|
|
@ -3343,7 +3343,7 @@ Top of the parse tree.
|
||||||
%types directive.
|
%types directive.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"parms" - List of parameter types.
|
"parms" - List of parameter types.
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -3358,7 +3358,7 @@ Top of the parse tree.
|
||||||
extern "X" { ... } declaration.
|
extern "X" { ... } declaration.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
"name" - Name "C", "Fortran", etc.
|
"name" - Name "C", "Fortran", etc.
|
||||||
</pre>
|
</pre>
|
||||||
|
|
|
||||||
|
|
@ -203,7 +203,7 @@ SWIG is invoked using the <tt>swig</tt> command. We can use this to
|
||||||
build a Tcl module (under Linux) as follows :
|
build a Tcl module (under Linux) as follows :
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
unix > <b>swig -tcl example.i</b>
|
unix > <b>swig -tcl example.i</b>
|
||||||
unix > <b>gcc -c -fpic example.c example_wrap.c -I/usr/local/include</b>
|
unix > <b>gcc -c -fpic example.c example_wrap.c -I/usr/local/include</b>
|
||||||
unix > <b>gcc -shared example.o example_wrap.o -o example.so</b>
|
unix > <b>gcc -shared example.o example_wrap.o -o example.so</b>
|
||||||
|
|
@ -237,7 +237,7 @@ Now, let's turn these functions into a Perl5 module. Without making
|
||||||
any changes type the following (shown for Solaris):
|
any changes type the following (shown for Solaris):
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
unix > <b>swig -perl5 example.i</b>
|
unix > <b>swig -perl5 example.i</b>
|
||||||
unix > <b>gcc -c example.c example_wrap.c \
|
unix > <b>gcc -c example.c example_wrap.c \
|
||||||
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE</b>
|
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE</b>
|
||||||
|
|
@ -262,7 +262,7 @@ unix >
|
||||||
Finally, let's build a module for Python (shown for Irix).
|
Finally, let's build a module for Python (shown for Irix).
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
unix > <b>swig -python example.i</b>
|
unix > <b>swig -python example.i</b>
|
||||||
unix > <b>gcc -c -fpic example.c example_wrap.c -I/usr/local/include/python2.0</b>
|
unix > <b>gcc -c -fpic example.c example_wrap.c -I/usr/local/include/python2.0</b>
|
||||||
unix > <b>gcc -shared example.o example_wrap.o -o _example.so</b>
|
unix > <b>gcc -shared example.o example_wrap.o -o _example.so</b>
|
||||||
|
|
@ -289,7 +289,7 @@ it. For example, you could also build a Perl5 module by just running
|
||||||
SWIG on the C header file and specifying a module name as follows
|
SWIG on the C header file and specifying a module name as follows
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
unix > <b>swig -perl5 -module example example.h</b>
|
unix > <b>swig -perl5 -module example example.h</b>
|
||||||
unix > <b>gcc -c example.c example_wrap.c \
|
unix > <b>gcc -c example.c example_wrap.c \
|
||||||
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE</b>
|
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE</b>
|
||||||
|
|
|
||||||
|
|
@ -182,7 +182,7 @@ void add(int x, int y, int *result);
|
||||||
Now, in Python:
|
Now, in Python:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> import example
|
>>> import example
|
||||||
>>> c = example.new_intp() # Create an "int" for storing result
|
>>> c = example.new_intp() # Create an "int" for storing result
|
||||||
|
|
@ -262,7 +262,7 @@ void add(int x, int y, int *result);
|
||||||
Now, in Python (using proxy classes)
|
Now, in Python (using proxy classes)
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> import example
|
>>> import example
|
||||||
>>> c = example.intp() # Create an "int" for storing result
|
>>> c = example.intp() # Create an "int" for storing result
|
||||||
|
|
@ -626,7 +626,7 @@ Here is a simple example that illustrates the use of these macros:
|
||||||
Now, in a script:
|
Now, in a script:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> from example import *
|
>>> from example import *
|
||||||
>>> a = malloc_int()
|
>>> a = malloc_int()
|
||||||
|
|
@ -698,7 +698,7 @@ Here is a short example:
|
||||||
Python example:
|
Python example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> a = intArray(10)
|
>>> a = intArray(10)
|
||||||
>>> for i in range(0,10):
|
>>> for i in range(0,10):
|
||||||
|
|
@ -949,7 +949,7 @@ void get_path(char *path);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> get_path()
|
>>> get_path()
|
||||||
/home/beazley/packages/Foo/Bar
|
/home/beazley/packages/Foo/Bar
|
||||||
|
|
@ -992,7 +992,7 @@ void get_packet(char *packet);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> get_packet()
|
>>> get_packet()
|
||||||
'\xa9Y:\xf6\xd7\xe1\x87\xdbH;y\x97\x7f"\xd3\x99\x14V\xec\x06\xea\xa2\x88'
|
'\xa9Y:\xf6\xd7\xe1\x87\xdbH;y\x97\x7f"\xd3\x99\x14V\xec\x06\xea\xa2\x88'
|
||||||
|
|
@ -1035,7 +1035,7 @@ void make_upper(char *ustr);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> make_upper("hello world")
|
>>> make_upper("hello world")
|
||||||
'HELLO WORLD'
|
'HELLO WORLD'
|
||||||
|
|
@ -1087,7 +1087,7 @@ void attach_header(char *hstr);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> make_upper("hello world")
|
>>> make_upper("hello world")
|
||||||
'HELLO WORLD'
|
'HELLO WORLD'
|
||||||
|
|
@ -1138,7 +1138,7 @@ void get_path(char *path, int maxpath);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> get_path(1024)
|
>>> get_path(1024)
|
||||||
'/home/beazley/Packages/Foo/Bar'
|
'/home/beazley/Packages/Foo/Bar'
|
||||||
|
|
@ -1184,7 +1184,7 @@ void get_data(char *data, int *maxdata);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> get_data(1024)
|
>>> get_data(1024)
|
||||||
'x627388912'
|
'x627388912'
|
||||||
|
|
@ -1241,7 +1241,7 @@ void foo(char **s);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> foo()
|
>>> foo()
|
||||||
'Hello world\n'
|
'Hello world\n'
|
||||||
|
|
@ -1291,7 +1291,7 @@ void foo(char **s, int *slen);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> foo()
|
>>> foo()
|
||||||
'\xa9Y:\xf6\xd7\xe1\x87\xdbH;y\x97\x7f"\xd3\x99\x14V\xec\x06\xea\xa2\x88'
|
'\xa9Y:\xf6\xd7\xe1\x87\xdbH;y\x97\x7f"\xd3\x99\x14V\xec\x06\xea\xa2\x88'
|
||||||
|
|
@ -1377,7 +1377,7 @@ void bar(const std::string &x);
|
||||||
In the target language:
|
In the target language:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
x = foo(); # Returns a string object
|
x = foo(); # Returns a string object
|
||||||
bar("Hello World"); # Pass string as std::string
|
bar("Hello World"); # Pass string as std::string
|
||||||
|
|
@ -1522,7 +1522,7 @@ namespace std {
|
||||||
Now, to illustrate the behavior in the scripting interpreter, consider this Python example:
|
Now, to illustrate the behavior in the scripting interpreter, consider this Python example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> from example import *
|
>>> from example import *
|
||||||
>>> iv = IntVector(4) # Create an vector<int>
|
>>> iv = IntVector(4) # Create an vector<int>
|
||||||
|
|
|
||||||
|
|
@ -83,7 +83,7 @@ of SWIG-1.3 scare you---it is much more stable (and capable) than SWIG-1.1p5.
|
||||||
The official location of SWIG related material is
|
The official location of SWIG related material is
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
<a href="http://www.swig.org">http://www.swig.org</a>
|
<a href="http://www.swig.org">http://www.swig.org</a>
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -96,7 +96,7 @@ implementation tricks.
|
||||||
You can also subscribe to the SWIG mailing list by visiting the page
|
You can also subscribe to the SWIG mailing list by visiting the page
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
<a href="http://www.swig.org/mail.html">http://www.swig.org/mail.html</a>
|
<a href="http://www.swig.org/mail.html">http://www.swig.org/mail.html</a>
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -110,7 +110,7 @@ CVS access to the latest version of SWIG is also available. More information
|
||||||
about this can be obtained at:
|
about this can be obtained at:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
<a href="http://www.swig.org/cvs.html">http://www.swig.org/cvs.html</a>
|
<a href="http://www.swig.org/cvs.html">http://www.swig.org/cvs.html</a>
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -96,7 +96,7 @@ To run SWIG, use the <tt>swig</tt> command with one or more of the
|
||||||
following options and a filename like this:
|
following options and a filename like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
swig [ <em>options</em> ] filename
|
swig [ <em>options</em> ] filename
|
||||||
|
|
||||||
-chicken Generate CHICKEN wrappers
|
-chicken Generate CHICKEN wrappers
|
||||||
|
|
@ -203,7 +203,7 @@ language (C, C++, etc.). Therefore, you have to use the
|
||||||
file if you want something different than the default. For example:
|
file if you want something different than the default. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
$ swig -c++ -python -o example_wrap.cpp example.i
|
$ swig -c++ -python -o example_wrap.cpp example.i
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -224,13 +224,13 @@ specific files is the same directory as the generated C/C++ file. This can
|
||||||
can be modified using the <tt>-outdir</tt> option. For example:
|
can be modified using the <tt>-outdir</tt> option. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
$ swig -c++ -python -outdir pyfiles -o cppfiles/example_wrap.cpp example.i
|
$ swig -c++ -python -outdir pyfiles -o cppfiles/example_wrap.cpp example.i
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
If the directories <tt>cppfiles</tt> and <tt>pyfiles</tt> exist, the following
|
If the directories <tt>cppfiles</tt> and <tt>pyfiles</tt> exist, the following
|
||||||
will be generated:</p>
|
will be generated:</p>
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
cppfiles/example_wrap.cpp
|
cppfiles/example_wrap.cpp
|
||||||
pyfiles/example.py
|
pyfiles/example.py
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -414,7 +414,7 @@ declarations are accessible as scripting language functions, variables, and
|
||||||
constants respectively. For example, in Tcl:
|
constants respectively. For example, in Tcl:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
% sin 3
|
% sin 3
|
||||||
5.2335956
|
5.2335956
|
||||||
% strcmp Dave Mike
|
% strcmp Dave Mike
|
||||||
|
|
@ -430,7 +430,7 @@ constants respectively. For example, in Tcl:
|
||||||
Or in Python:
|
Or in Python:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> example.sin(3)
|
>>> example.sin(3)
|
||||||
5.2335956
|
5.2335956
|
||||||
>>> example.strcmp('Dave','Mike')
|
>>> example.strcmp('Dave','Mike')
|
||||||
|
|
@ -871,7 +871,7 @@ representation that contains the actual value of the pointer and a type-tag.
|
||||||
Thus, the SWIG representation of the above
|
Thus, the SWIG representation of the above
|
||||||
pointers (in Tcl), might look like this:</p>
|
pointers (in Tcl), might look like this:</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
_10081012_p_int
|
_10081012_p_int
|
||||||
_1008e124_ppp_double
|
_1008e124_ppp_double
|
||||||
_f8ac_pp_char
|
_f8ac_pp_char
|
||||||
|
|
@ -979,7 +979,7 @@ as a pointer, so it doesn't really matter what it is. If you wrapped
|
||||||
this module into Python, you can use the functions just like you
|
this module into Python, you can use the functions just like you
|
||||||
expect :</p>
|
expect :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
# Copy a file
|
# Copy a file
|
||||||
def filecopy(source,target):
|
def filecopy(source,target):
|
||||||
f1 = fopen(source,"r")
|
f1 = fopen(source,"r")
|
||||||
|
|
@ -1115,7 +1115,7 @@ For example:
|
||||||
In this case, you might run SWIG as follows:
|
In this case, you might run SWIG as follows:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ swig -I/usr/include -includeall example.i
|
$ swig -I/usr/include -includeall example.i
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1334,7 +1334,7 @@ it as a function from the target scripting language (it does not work
|
||||||
like a variable). For example, in Python you will have to write:
|
like a variable). For example, in Python you will have to write:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> set_foo("Hello World")
|
>>> set_foo("Hello World")
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1374,7 +1374,7 @@ getting the value. However, the default behavior does <em>not</em> release the
|
||||||
a possible memory leak). In fact, you may get a warning message such as this when wrapping such a variable:
|
a possible memory leak). In fact, you may get a warning message such as this when wrapping such a variable:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
example.i:20. Typemap warning. Setting const char * variable may leak memory
|
example.i:20. Typemap warning. Setting const char * variable may leak memory
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1710,7 +1710,7 @@ In this case, SWIG generates wrapper code where the
|
||||||
default arguments are optional in the target language. For example, this function could be
|
default arguments are optional in the target language. For example, this function could be
|
||||||
used in Tcl as follows :</p>
|
used in Tcl as follows :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
% plot -3.4 7.5 # Use default value
|
% plot -3.4 7.5 # Use default value
|
||||||
% plot -3.4 7.5 10 # set color to 10 instead
|
% plot -3.4 7.5 10 # set color to 10 instead
|
||||||
|
|
||||||
|
|
@ -1751,7 +1751,7 @@ When you first wrap something like this into an extension module, you
|
||||||
may find the function to be impossible to use. For instance, in Python:
|
may find the function to be impossible to use. For instance, in Python:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> def add(x,y):
|
>>> def add(x,y):
|
||||||
... return x+y
|
... return x+y
|
||||||
...
|
...
|
||||||
|
|
@ -1785,7 +1785,7 @@ In this case, <tt>add</tt>, <tt>sub</tt>, and <tt>mul</tt> become function point
|
||||||
constants in the target scripting language. This allows you to use them as follows:
|
constants in the target scripting language. This allows you to use them as follows:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> binary_op(3,4,add)
|
>>> binary_op(3,4,add)
|
||||||
7
|
7
|
||||||
|
|
@ -1800,7 +1800,7 @@ Unfortunately, by declaring the callback functions as constants, they are no lon
|
||||||
as functions. For example:
|
as functions. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> add(3,4)
|
>>> add(3,4)
|
||||||
Traceback (most recent call last):
|
Traceback (most recent call last):
|
||||||
|
|
@ -1835,7 +1835,7 @@ by the function name). The callback mode remains in effect until it is explicit
|
||||||
disabled using <tt>%nocallback</tt>. When you do this, the interface now works as follows:
|
disabled using <tt>%nocallback</tt>. When you do this, the interface now works as follows:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> binary_op(3,4,add_cb)
|
>>> binary_op(3,4,add_cb)
|
||||||
7
|
7
|
||||||
|
|
@ -2070,7 +2070,7 @@ When this
|
||||||
situation is detected, SWIG may generate a warning message such as the
|
situation is detected, SWIG may generate a warning message such as the
|
||||||
following :</p>
|
following :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
interface.i:116. Warning. Array member will be read-only
|
interface.i:116. Warning. Array member will be read-only
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -2203,7 +2203,7 @@ can use the <tt>%nodefault</tt> directive or the <tt>-no_default</tt>
|
||||||
command line option. For example:
|
command line option. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
swig -no_default example.i
|
swig -no_default example.i
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -2306,7 +2306,7 @@ You can make a <tt>Vector</tt> look alot like a class by writing a SWIG interfac
|
||||||
Now, when used with proxy classes in Python, you can do things like
|
Now, when used with proxy classes in Python, you can do things like
|
||||||
this :</p>
|
this :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> v = Vector(3,4,0) # Create a new vector
|
>>> v = Vector(3,4,0) # Create a new vector
|
||||||
>>> print v.magnitude() # Print magnitude
|
>>> print v.magnitude() # Print magnitude
|
||||||
5.0
|
5.0
|
||||||
|
|
@ -2530,7 +2530,7 @@ Although this process is a little hairy, it works like you would expect in the
|
||||||
target scripting language--especially when proxy classes are used. For instance, in Perl:
|
target scripting language--especially when proxy classes are used. For instance, in Perl:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
# Perl5 script for accessing nested member
|
# Perl5 script for accessing nested member
|
||||||
$o = CreateObject(); # Create an object somehow
|
$o = CreateObject(); # Create an object somehow
|
||||||
$o->{intRep}->{ivalue} = 7 # Change value of o.intRep.ivalue
|
$o->{intRep}->{ivalue} = 7 # Change value of o.intRep.ivalue
|
||||||
|
|
|
||||||
|
|
@ -205,7 +205,7 @@ When compiling and linking the resulting wrapper file, it is normal
|
||||||
to use the C++ compiler. For example:
|
to use the C++ compiler. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ swig -c++ -tcl example.i
|
$ swig -c++ -tcl example.i
|
||||||
$ c++ -c example_wrap.cxx
|
$ c++ -c example_wrap.cxx
|
||||||
|
|
@ -394,7 +394,7 @@ all cases, this is caused when classes are determined to be abstract. To see i
|
||||||
all of its warnings turned on:
|
all of its warnings turned on:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
% swig -Wall -python module.i
|
% swig -Wall -python module.i
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -445,7 +445,7 @@ public:
|
||||||
then the copy constructor can be used as follows:
|
then the copy constructor can be used as follows:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
x = new_List() # Create a list
|
x = new_List() # Create a list
|
||||||
y = new_List(x) # Copy list x
|
y = new_List(x) # Copy list x
|
||||||
|
|
@ -805,7 +805,7 @@ public:
|
||||||
<p>
|
<p>
|
||||||
Generates the following set of constants in the target scripting language :</p>
|
Generates the following set of constants in the target scripting language :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
Swig_ALE = Swig::ALE
|
Swig_ALE = Swig::ALE
|
||||||
Swig_LAGER = Swig::LAGER
|
Swig_LAGER = Swig::LAGER
|
||||||
Swig_PORTER = Swig::PORTER
|
Swig_PORTER = Swig::PORTER
|
||||||
|
|
@ -916,7 +916,7 @@ void foo(const int &x);
|
||||||
it is called from a script as follows:
|
it is called from a script as follows:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
foo(3) # Notice pass by value
|
foo(3) # Notice pass by value
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1117,7 +1117,7 @@ public:
|
||||||
When wrapped into Python, we can now perform the following operations
|
When wrapped into Python, we can now perform the following operations
|
||||||
:</p>
|
:</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
$ python
|
$ python
|
||||||
>>> import shapes
|
>>> import shapes
|
||||||
>>> circle = shapes.new_Circle(7)
|
>>> circle = shapes.new_Circle(7)
|
||||||
|
|
@ -1170,7 +1170,7 @@ base classes to be defined in an interface. Otherwise, you may get an
|
||||||
warning message like this:
|
warning message like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
example:18. Nothing known about class 'Foo'. Ignored.
|
example:18. Nothing known about class 'Foo'. Ignored.
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1252,7 +1252,7 @@ pointer and a type string. For example, in Tcl, a C++ pointer might
|
||||||
be encoded as a string like this:
|
be encoded as a string like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
_808fea88_p_Circle
|
_808fea88_p_Circle
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1328,7 +1328,7 @@ representation of <tt>C</tt>. With multiple inheritance, the data from
|
||||||
each base class is stacked together. For example:
|
each base class is stacked together. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
------------ <--- (C *), (A *)
|
------------ <--- (C *), (A *)
|
||||||
| A |
|
| A |
|
||||||
|
|
@ -1437,7 +1437,7 @@ void foo(char *x) {
|
||||||
The function is used in a completely natural way. For example:
|
The function is used in a completely natural way. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> foo(3)
|
>>> foo(3)
|
||||||
x is 3
|
x is 3
|
||||||
|
|
@ -1468,7 +1468,7 @@ public:
|
||||||
it might be used like this
|
it might be used like this
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> f = Foo() # Create a Foo
|
>>> f = Foo() # Create a Foo
|
||||||
>>> f.bar(3)
|
>>> f.bar(3)
|
||||||
|
|
@ -1516,7 +1516,7 @@ required arguments.
|
||||||
<li><p><b>Argument type precedence.</b> All C++ datatypes are assigned a numeric type precedence value
|
<li><p><b>Argument type precedence.</b> All C++ datatypes are assigned a numeric type precedence value
|
||||||
(which is determined by the language module).</p>
|
(which is determined by the language module).</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
Type Precedence
|
Type Precedence
|
||||||
---------------- ----------
|
---------------- ----------
|
||||||
|
|
@ -1559,7 +1559,7 @@ The first rule simply ranks the functions by required argument count.
|
||||||
This would produce the following list:
|
This would produce the following list:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
rank
|
rank
|
||||||
-----
|
-----
|
||||||
|
|
@ -1578,7 +1578,7 @@ rank
|
||||||
The second rule, simply refines the ranking by looking at argument type precedence values.
|
The second rule, simply refines the ranking by looking at argument type precedence values.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
rank
|
rank
|
||||||
-----
|
-----
|
||||||
|
|
@ -1624,7 +1624,7 @@ just by looking at the value of the integer itself (<tt>int</tt> and <tt>long</t
|
||||||
Therefore, when SWIG encounters this situation, it may generate a warning message like this for scripting languages:
|
Therefore, when SWIG encounters this situation, it may generate a warning message like this for scripting languages:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
example.i:4: Warning(509): Overloaded foo(long) is shadowed by foo(int) at example.i:3.
|
example.i:4: Warning(509): Overloaded foo(long) is shadowed by foo(int) at example.i:3.
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1634,7 +1634,7 @@ example.i:4: Warning(509): Overloaded foo(long) is shadowed by foo(int) at examp
|
||||||
or for statically typed languages like Java:
|
or for statically typed languages like Java:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
example.i:4: Warning(516): Overloaded method foo(long) ignored. Method foo(int)
|
example.i:4: Warning(516): Overloaded method foo(long) ignored. Method foo(int)
|
||||||
at example.i:3 used.
|
at example.i:3 used.
|
||||||
|
|
@ -1684,7 +1684,7 @@ Therefore, earlier methods will shadow methods that appear later.
|
||||||
When wrapping an overloaded function, there is a chance that you will get an error message like this:
|
When wrapping an overloaded function, there is a chance that you will get an error message like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
example.i:3: Warning(467): Overloaded foo(int) not supported (no type checking
|
example.i:3: Warning(467): Overloaded foo(int) not supported (no type checking
|
||||||
rule for 'int').
|
rule for 'int').
|
||||||
|
|
@ -1703,7 +1703,7 @@ undefined. You should report this as a bug to the
|
||||||
If you get an error message such as the following,
|
If you get an error message such as the following,
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
foo.i:6. Overloaded declaration ignored. Spam::foo(double )
|
foo.i:6. Overloaded declaration ignored. Spam::foo(double )
|
||||||
foo.i:5. Previous declaration is Spam::foo(int )
|
foo.i:5. Previous declaration is Spam::foo(int )
|
||||||
|
|
@ -2224,7 +2224,7 @@ When used in the target language, it may now be possible to use the overloaded
|
||||||
operator normally. For example:
|
operator normally. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> a = Complex(3,4)
|
>>> a = Complex(3,4)
|
||||||
>>> b = Complex(5,2)
|
>>> b = Complex(5,2)
|
||||||
|
|
@ -2248,7 +2248,7 @@ name. If you wrote this:
|
||||||
The resulting scripting interface might work like this:
|
The resulting scripting interface might work like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
a = Complex(3,4)
|
a = Complex(3,4)
|
||||||
b = Complex(5,2)
|
b = Complex(5,2)
|
||||||
|
|
@ -2361,7 +2361,7 @@ allow us to print the value of an object using the <tt>print</tt>
|
||||||
command.
|
command.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>>
|
>>>
|
||||||
>>> v = Vector();
|
>>> v = Vector();
|
||||||
>>> v.x = 3
|
>>> v.x = 3
|
||||||
|
|
@ -2651,7 +2651,7 @@ then SWIG knows that <tt>List<int></tt> was already wrapped as a class cal
|
||||||
nothing is known about <tt>List<int></tt>, you will get a warning message similar to this:
|
nothing is known about <tt>List<int></tt>, you will get a warning message similar to this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
example.h:42. Nothing known about class 'List<int >' (ignored).
|
example.h:42. Nothing known about class 'List<int >' (ignored).
|
||||||
example.h:42. Maybe you forgot to instantiate 'List<int >' using %template.
|
example.h:42. Maybe you forgot to instantiate 'List<int >' using %template.
|
||||||
|
|
@ -3347,7 +3347,7 @@ namespace B {
|
||||||
When this conflict occurs, you will get an error message that resembles this:
|
When this conflict occurs, you will get an error message that resembles this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
example.i:26. Error. 'foo' is multiply defined in the generated module.
|
example.i:26. Error. 'foo' is multiply defined in the generated module.
|
||||||
example.i:23. Previous declaration of 'foo'
|
example.i:23. Previous declaration of 'foo'
|
||||||
|
|
@ -3612,7 +3612,7 @@ modules, wrapped exception classes themselves can be used to catch errors. For
|
||||||
write code like this:
|
write code like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
f = Foo()
|
f = Foo()
|
||||||
try:
|
try:
|
||||||
|
|
@ -3661,7 +3661,7 @@ When pointers to members are supported, the pointer value might appear as a spec
|
||||||
string like this:
|
string like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> print example.FOO
|
>>> print example.FOO
|
||||||
_ff0d54a800000000_m_Object__f_double_double__double
|
_ff0d54a800000000_m_Object__f_double_double__double
|
||||||
|
|
@ -3791,7 +3791,7 @@ The end result is that access looks very similar to C++. For
|
||||||
example, you could do this in Python:
|
example, you could do this in Python:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> f = make_Foo()
|
>>> f = make_Foo()
|
||||||
>>> print f.x
|
>>> print f.x
|
||||||
|
|
@ -3869,7 +3869,7 @@ Alternatively, you can import the definition of <tt>Foo</tt> from a separate fil
|
||||||
as a method <tt>__deref__()</tt>. For example:
|
as a method <tt>__deref__()</tt>. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
f = Foo() # Smart-pointer
|
f = Foo() # Smart-pointer
|
||||||
p = f.__deref__() # Raw pointer from operator->
|
p = f.__deref__() # Raw pointer from operator->
|
||||||
|
|
@ -3941,7 +3941,7 @@ SWIG emulates the same functionality when creating wrappers. For example, if
|
||||||
you wrap this code in Python, the module works just like you would expect:
|
you wrap this code in Python, the module works just like you would expect:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> import example
|
>>> import example
|
||||||
>>> f = example.FooBar()
|
>>> f = example.FooBar()
|
||||||
|
|
@ -4125,7 +4125,7 @@ void blah() {
|
||||||
Now, consider the behavior when wrapped into a Python module:
|
Now, consider the behavior when wrapped into a Python module:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> bar(foo()) # Okay
|
>>> bar(foo()) # Okay
|
||||||
>>>
|
>>>
|
||||||
|
|
@ -4214,7 +4214,7 @@ Of course, always keep in mind that the real proxy class is written in the targe
|
||||||
For example, in Python, the proxy might look roughly like this:
|
For example, in Python, the proxy might look roughly like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
class Foo:
|
class Foo:
|
||||||
def __init__(self):
|
def __init__(self):
|
||||||
|
|
@ -4274,7 +4274,7 @@ public:
|
||||||
Now, consider some script code that uses these classes:
|
Now, consider some script code that uses these classes:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
f = Foo() # Creates a new Foo
|
f = Foo() # Creates a new Foo
|
||||||
s = Spam() # Creates a new Spam
|
s = Spam() # Creates a new Spam
|
||||||
|
|
|
||||||
|
|
@ -181,7 +181,7 @@ double Foo = 3.5;
|
||||||
<p>
|
<p>
|
||||||
It might be nice to access it from a script as follows (shown for Perl):</p>
|
It might be nice to access it from a script as follows (shown for Perl):</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
$a = $Foo * 2.3; # Evaluation
|
$a = $Foo * 2.3; # Evaluation
|
||||||
$Foo = $a + 2.0; # Assignment
|
$Foo = $a + 2.0; # Assignment
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -269,7 +269,7 @@ void Vector_z_set(Vector *v, double z);
|
||||||
Now, from an interpreter these function might be used as follows:
|
Now, from an interpreter these function might be used as follows:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
% set v [new_Vector]
|
% set v [new_Vector]
|
||||||
% Vector_x_set $v 3.5
|
% Vector_x_set $v 3.5
|
||||||
% Vector_y_get $v
|
% Vector_y_get $v
|
||||||
|
|
@ -309,7 +309,7 @@ A proxy classing mechanism would allow you to access the structure in
|
||||||
a more natural manner from the interpreter. For example, in Python, you might want to do this:
|
a more natural manner from the interpreter. For example, in Python, you might want to do this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> v = Vector()
|
>>> v = Vector()
|
||||||
>>> v.x = 3
|
>>> v.x = 3
|
||||||
>>> v.y = 4
|
>>> v.y = 4
|
||||||
|
|
@ -321,7 +321,7 @@ a more natural manner from the interpreter. For example, in Python, you might wa
|
||||||
<p>
|
<p>
|
||||||
Similarly, in Perl5 you may want the interface to work like this:</p>
|
Similarly, in Perl5 you may want the interface to work like this:</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
$v = new Vector;
|
$v = new Vector;
|
||||||
$v->{x} = 3;
|
$v->{x} = 3;
|
||||||
$v->{y} = 4;
|
$v->{y} = 4;
|
||||||
|
|
@ -332,7 +332,7 @@ $v->{z} = -13;
|
||||||
Finally, in Tcl :
|
Finally, in Tcl :
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
Vector v
|
Vector v
|
||||||
v configure -x 3 -y 4 -z 13
|
v configure -x 3 -y 4 -z 13
|
||||||
|
|
||||||
|
|
@ -366,7 +366,7 @@ To create a shared library or DLL, you often need to look at the
|
||||||
manual pages for your compiler and linker. However, the procedure
|
manual pages for your compiler and linker. However, the procedure
|
||||||
for a few common machines is shown below:</p>
|
for a few common machines is shown below:</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
# Build a shared library for Solaris
|
# Build a shared library for Solaris
|
||||||
gcc -c example.c example_wrap.c -I/usr/local/include
|
gcc -c example.c example_wrap.c -I/usr/local/include
|
||||||
ld -G example.o example_wrap.o -o example.so
|
ld -G example.o example_wrap.o -o example.so
|
||||||
|
|
@ -387,7 +387,7 @@ in the scripting language (load, import, use, etc...). This will
|
||||||
import your module and allow you to start using it. For example:
|
import your module and allow you to start using it. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
% load ./example.so
|
% load ./example.so
|
||||||
% fact 4
|
% fact 4
|
||||||
24
|
24
|
||||||
|
|
@ -401,7 +401,7 @@ additional code in order to operate correctly. On many machines, you
|
||||||
can build a shared C++ module by following the above procedures, but
|
can build a shared C++ module by following the above procedures, but
|
||||||
changing the link line to the following :</p>
|
changing the link line to the following :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
c++ -shared example.o example_wrap.o -o example.so
|
c++ -shared example.o example_wrap.o -o example.so
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -415,7 +415,7 @@ order for the extension to work, it needs to be able to find all of
|
||||||
these libraries at run-time. Otherwise, you may get an error such as
|
these libraries at run-time. Otherwise, you may get an error such as
|
||||||
the following :</p>
|
the following :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> import graph
|
>>> import graph
|
||||||
Traceback (innermost last):
|
Traceback (innermost last):
|
||||||
File "<stdin>", line 1, in ?
|
File "<stdin>", line 1, in ?
|
||||||
|
|
|
||||||
|
|
@ -603,7 +603,7 @@ you can't use typemaps to interchange the arguments, allowing you to call the
|
||||||
function like this:
|
function like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
foo("hello",3) # Reversed arguments
|
foo("hello",3) # Reversed arguments
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -682,7 +682,7 @@ are sometimes to attach extra information to a typemap and is often target-langu
|
||||||
this list is as follows:
|
this list is as follows:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
typelist : typepattern [, typepattern, typepattern, ... ] ;
|
typelist : typepattern [, typepattern, typepattern, ... ] ;
|
||||||
|
|
||||||
|
|
@ -703,7 +703,7 @@ variables (parms). The purpose of these variables will be explained shortly.
|
||||||
forms:
|
forms:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
code : { ... }
|
code : { ... }
|
||||||
| " ... "
|
| " ... "
|
||||||
|
|
@ -1035,7 +1035,7 @@ int foo(const char *s);
|
||||||
To find a typemap for the argument <tt>const char *s</tt>, SWIG will search for the following typemaps:
|
To find a typemap for the argument <tt>const char *s</tt>, SWIG will search for the following typemaps:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
const char *s Exact type and name match
|
const char *s Exact type and name match
|
||||||
const char * Exact type match
|
const char * Exact type match
|
||||||
|
|
@ -1105,7 +1105,7 @@ To find the typemap for <tt>Integer x</tt>, SWIG will first search for the follo
|
||||||
typemaps:
|
typemaps:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
Integer x
|
Integer x
|
||||||
Integer
|
Integer
|
||||||
|
|
@ -1117,7 +1117,7 @@ Finding no match, it then applies a reduction <tt>Integer -> int</tt> to the
|
||||||
repeats the search.
|
repeats the search.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
int x
|
int x
|
||||||
int --> match: typemap 1
|
int --> match: typemap 1
|
||||||
|
|
@ -1505,7 +1505,7 @@ and you wanted to pass a native string in the target language as an argument.
|
||||||
in Perl, you wanted the function to work like this:
|
in Perl, you wanted the function to work like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
$x = foo("Hello World");
|
$x = foo("Hello World");
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1770,7 +1770,7 @@ on the left-hand side of a C assignment operation. Here are a few examples of
|
||||||
and ltypes:
|
and ltypes:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
type ltype
|
type ltype
|
||||||
------ ----------------
|
------ ----------------
|
||||||
|
|
@ -2080,7 +2080,7 @@ with an "in" typemap---possibly to ignore the input value. For example:
|
||||||
The following special variables are available.
|
The following special variables are available.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
$result - Result object returned to target language.
|
$result - Result object returned to target language.
|
||||||
$input - The original input object passed.
|
$input - The original input object passed.
|
||||||
|
|
@ -2307,7 +2307,7 @@ C stack. The typemap then populates this array and passes it to the underlying
|
||||||
When used from Python, the typemap allows the following type of function call:
|
When used from Python, the typemap allows the following type of function call:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> set_vector(type, [ 1, 2.5, 5, 20 ])
|
>>> set_vector(type, [ 1, 2.5, 5, 20 ])
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2414,7 +2414,7 @@ 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:
|
You may even get a warning message like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
swig -python example.i
|
swig -python example.i
|
||||||
Generating wrappers for Python
|
Generating wrappers for Python
|
||||||
example.i:10. Warning. Array member value will be read-only.
|
example.i:10. Warning. Array member value will be read-only.
|
||||||
|
|
@ -2449,7 +2449,7 @@ When combined with the earlier typemaps for arrays, the combination of the "in"
|
||||||
the following usage:
|
the following usage:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> s = SomeObject()
|
>>> s = SomeObject()
|
||||||
>>> s.x = [1, 2.5, 5, 10]
|
>>> s.x = [1, 2.5, 5, 10]
|
||||||
|
|
@ -2462,7 +2462,7 @@ object. For example, in this example, you will get very odd program behavior wh
|
||||||
can be set nicely, but reading the member simply returns a pointer:
|
can be set nicely, but reading the member simply returns a pointer:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> s = SomeObject()
|
>>> s = SomeObject()
|
||||||
>>> s.x = [1, 2.5, 5. 10]
|
>>> s.x = [1, 2.5, 5. 10]
|
||||||
|
|
@ -2493,7 +2493,7 @@ To fix this, you can write an "out" typemap. For example:
|
||||||
Now, you will find that member access is quite nice:
|
Now, you will find that member access is quite nice:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> s = SomeObject()
|
>>> s = SomeObject()
|
||||||
>>> s.x = [1, 2.5, 5, 10]
|
>>> s.x = [1, 2.5, 5, 10]
|
||||||
|
|
@ -2581,7 +2581,7 @@ Suppose that you wanted to wrap this function so that it accepted a single
|
||||||
list of strings like this:
|
list of strings like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> foo(["ale","lager","stout"])
|
>>> foo(["ale","lager","stout"])
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2766,7 +2766,7 @@ scripting language object being returned to the interpreter.).
|
||||||
Now, in a script, you can write code that simply passes buffers as strings like this:
|
Now, in a script, you can write code that simply passes buffers as strings like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> f = example.open("Makefile")
|
>>> f = example.open("Makefile")
|
||||||
>>> example.read(f,40)
|
>>> example.read(f,40)
|
||||||
|
|
@ -2865,7 +2865,7 @@ into typed pointer objects. For example, an instance of <tt>Foo *</tt> might be
|
||||||
a string encoded like this:
|
a string encoded like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
_108e688_p_Foo
|
_108e688_p_Foo
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2901,7 +2901,7 @@ When the class <tt>FooBar</tt> is organized in memory, it contains the contents
|
||||||
of the classes <tt>Foo</tt> and <tt>Bar</tt> as well as its own data members. For example:
|
of the classes <tt>Foo</tt> and <tt>Bar</tt> as well as its own data members. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
FooBar --> | -----------| <-- Foo
|
FooBar --> | -----------| <-- Foo
|
||||||
| int x |
|
| int x |
|
||||||
|
|
@ -3186,7 +3186,7 @@ int foo(char *s, int y);
|
||||||
You can access the functions in a normal way from the scripting interpreter:
|
You can access the functions in a normal way from the scripting interpreter:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
# Python
|
# Python
|
||||||
foo(3) # foo(int)
|
foo(3) # foo(int)
|
||||||
|
|
@ -3282,7 +3282,7 @@ is the mechanism by which it is implemented---as a collection of typemaps.
|
||||||
To support dynamic dispatch, SWIG first defines a general purpose type hierarchy as follows:
|
To support dynamic dispatch, SWIG first defines a general purpose type hierarchy as follows:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="diagram">
|
||||||
<pre>
|
<pre>
|
||||||
Symbolic Name Precedence Value
|
Symbolic Name Precedence Value
|
||||||
------------------------------ ------------------
|
------------------------------ ------------------
|
||||||
|
|
|
||||||
|
|
@ -274,7 +274,7 @@ this actually provides enough support for many simple kinds of varargs functions
|
||||||
instance, you could make function calls like this (in Python):
|
instance, you could make function calls like this (in Python):
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> traceprintf("Hello World")
|
>>> traceprintf("Hello World")
|
||||||
>>> traceprintf("Hello %s. Your number is %d\n" % (name, num))
|
>>> traceprintf("Hello %s. Your number is %d\n" % (name, num))
|
||||||
|
|
@ -722,7 +722,7 @@ int printf(const char *fmt, ...);
|
||||||
Much to your amazement, it even seems to work if you try it:
|
Much to your amazement, it even seems to work if you try it:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> import example
|
>>> import example
|
||||||
>>> example.printf("Grade: %s %d/60 = %0.2f%%\n", "Dave", 47, 47.0*100/60)
|
>>> example.printf("Grade: %s %d/60 = %0.2f%%\n", "Dave", 47, 47.0*100/60)
|
||||||
|
|
@ -735,7 +735,7 @@ Grade: Dave 47/60 = 78.33%
|
||||||
Of course, there are still some limitations to consider:
|
Of course, there are still some limitations to consider:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> example.printf("la de da de da %s", 42)
|
>>> example.printf("la de da de da %s", 42)
|
||||||
Segmentation fault (core dumped)
|
Segmentation fault (core dumped)
|
||||||
|
|
|
||||||
|
|
@ -41,7 +41,7 @@
|
||||||
During compilation, SWIG may generate a variety of warning messages. For example:
|
During compilation, SWIG may generate a variety of warning messages. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
example.i:16: Warning(501): Overloaded declaration ignored. bar(double)
|
example.i:16: Warning(501): Overloaded declaration ignored. bar(double)
|
||||||
example.i:15: Warning(501): Previous declaration is bar(int)
|
example.i:15: Warning(501): Previous declaration is bar(int)
|
||||||
|
|
@ -63,7 +63,7 @@ To suppress the printing of a warning message, a number of techniques can be use
|
||||||
First, you can run SWIG with the <tt>-w</tt> command line option. For example:
|
First, you can run SWIG with the <tt>-w</tt> command line option. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
% swig -python -w501 example.i
|
% swig -python -w501 example.i
|
||||||
% swig -python -w501,505,401 example.i
|
% swig -python -w501,505,401 example.i
|
||||||
|
|
@ -153,7 +153,7 @@ to provide additional diagnostics. All warning messages can be
|
||||||
enabled using the <tt>-Wall</tt> option. For example:
|
enabled using the <tt>-Wall</tt> option. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
% swig -Wall -python example.i
|
% swig -Wall -python example.i
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -168,7 +168,7 @@ To selectively turn on extra warning messages, you can use the directives and op
|
||||||
previous section--simply add a "+" to all warning numbers. For example:
|
previous section--simply add a "+" to all warning numbers. For example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
% swig -w+309,+452 example.i
|
% swig -w+309,+452 example.i
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -285,7 +285,7 @@ default except on Windows where the Microsoft format is used by default.
|
||||||
These can be overridden using command line options, for example:
|
These can be overridden using command line options, for example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="shell"><pre>
|
||||||
$ swig -python -Fstandard example.i
|
$ swig -python -Fstandard example.i
|
||||||
example.i:4: Syntax error in input.
|
example.i:4: Syntax error in input.
|
||||||
$ swig -python -Fmicrosoft example.i
|
$ swig -python -Fmicrosoft example.i
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue