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

Update documentation to use the right div class="targetlang" and such.

Browse source 
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 2005-03-18 00:03:54 +00:00
commit 9e9f5d84b3
13 changed files with 161 additions and 161 deletions
Download patch file Download diff file Expand all files Collapse all files

10
SWIG/Doc/Manual/Arguments.html
View file

@ -98,7 +98,7 @@ When the resulting module is created, you can now use the function
like this (shown for Python):
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
&gt;&gt;&gt; a = add(3,4)
&gt;&gt;&gt; print a
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:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
&gt;&gt;&gt; w,h = genwinsize(wid)
&gt;&gt;&gt; print w
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:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
result = add(3,4)
</pre></div>
@ -297,7 +297,7 @@ extern int foo(double a, double b, double *OUTPUT);
The function will return two values like this:
</p>
<div class="code">
<div class="targetlang">
<pre>
iresult, dresult = foo(3.5, 2)
</pre>
@ -347,7 +347,7 @@ extern void negate(double *INOUT);
<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
</pre></div>

2
SWIG/Doc/Manual/Contract.html
View file

@ -82,7 +82,7 @@ Once a contract has been specified, it modifies the behavior of the
resulting module. For example:
</p>
<div class="code">
<div class="shell">
<pre>
&gt;&gt;&gt; example.sqrt(2)
1.4142135623730951

2
SWIG/Doc/Manual/Customization.html
View file

@ -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
types are :</p>
<div class="code"><pre>
<div class="diagram"><pre>
SWIG_MemoryError
SWIG_IOError
SWIG_RuntimeError

90
SWIG/Doc/Manual/Extending.html
View file

@ -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:
</p>
<div class="code">
<div class="diagram">
<pre>
<em>storage</em> <em>type</em> <em>declarator</em> <em>initializer</em>;
</pre>
@ -395,7 +395,7 @@ The parse tree structure and tag names of an interface can be displayed using <t
For example:
</p>
<div class="code">
<div class="shell">
<pre>
$ <b>swig -c++ -python -dump_tags example.i</b>
. 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:
</p>
<div class="code">
<div class="shell">
<pre>
$ swig -c++ -python -dump_tree example.i
...
@ -683,7 +683,7 @@ void foo(Bar *b);
Now, running SWIG:
</p>
<div class="code">
<div class="shell">
<pre>
$ swig -dump_tree example.i
...
@ -733,7 +733,7 @@ void foo(Bar *b);
When you run SWIG on this you now get:
</p>
<div class="code">
<div class="shell">
<pre>
$ ./swig example.i
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:
</p>
<div class="code">
<div class="shell">
<pre>
+++ cdecl ----------------------------------------
| sym:name - "getitem"
@ -828,7 +828,7 @@ When the parser constructs a node for the member <tt>bar</tt>, it creates a raw
attributes:
</p>
<div class="code">
<div class="diagram">
<pre>
nodeType : cdecl
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:
</p>
<div class="code">
<div class="diagram">
<pre>
nodeType : cdecl
name : bar
@ -862,7 +862,7 @@ member function. This produces a transformation to a low-level
accessor function like this:
</p>
<div class="code">
<div class="diagram">
<pre>
nodeType : cdecl
name : bar
@ -1795,7 +1795,7 @@ Internally, types are represented as strings that are constructed in a very
precise manner. Here are some examples:
</p>
<div class="code">
<div class="diagram">
<pre>
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:
</p>
<div class="code">
<div class="diagram">
<pre>
Operator Meaning
------------------- -------------------------------
@ -1846,7 +1846,7 @@ is expected. For instance, here is
an extremely perverted example:
</p>
<div class="code">
<div class="diagram">
<pre>
`p.a(10).p.f(int,p.f(int).int)` foo(int, int (*x)(int));
</pre>
@ -1856,7 +1856,7 @@ an extremely perverted example:
This corresponds to the immediately obvious C declaration:
</p>
<div class="code">
<div class="diagram">
<pre>
(*(*foo(int,int (*)(int)))[10])(int,int (*)(int));
</pre>
@ -2139,7 +2139,7 @@ typedef int Size;
produces two trees like this:
</p>
<div class="code">
<div class="diagram">
<pre>
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:
</p>
<div class="code">
<div class="diagram">
<pre>
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:
</p>
<div class="code">
<div class="diagram">
<pre>
p.f(Integer, p.IntegerPtr, Size).Integer : Start
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:
</p>
<div class="code">
<div class="diagram">
<pre>
"type" - Parameter type (required)
"name" - Parameter name (optional)
@ -2332,7 +2332,7 @@ Typically parameters are denoted in the source by using a typename of
code like this:
</p>
<div class="code">
<div class="diagram">
<pre>
Parm *parms;
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:
</p>
<div class="code">
<div class="shell">
<pre>
$ <b>sh autogen.sh</b>
</pre>
@ -2520,7 +2520,7 @@ $ <b>sh autogen.sh</b>
Next re-run <tt>configure</tt> to regenerate all of the Makefiles:
</p>
<div class="code">
<div class="shell">
<pre>
$ <b>./configure</b>
</pre>
@ -2530,7 +2530,7 @@ $ <b>./configure</b>
Finally, rebuild SWIG with your module added:
</p>
<div class="code">
<div class="shell">
<pre>
$ <b>make</b>
</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.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Declarator name
"type" - Base type T
@ -2995,7 +2995,7 @@ and D is a declarator.
C++ constructor declaration.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of constructor
"parms" - Parameters
@ -3014,7 +3014,7 @@ C++ constructor declaration.
C++ destructor declaration.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of destructor
"code" - Function body code (if any)
@ -3032,7 +3032,7 @@ C++ destructor declaration.
C++ access change.
</p>
<div class="code">
<div class="diagram">
<pre>
"kind" - public, protected, private
</pre>
@ -3047,7 +3047,7 @@ C++ access change.
Constant created by %constant or #define.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of constant.
"type" - Base type.
@ -3065,7 +3065,7 @@ Constant created by %constant or #define.
C++ class definition or C structure definition.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of the class.
"kind" - Class kind ("struct", "union", "class")
@ -3087,7 +3087,7 @@ C++ class definition or C structure definition.
Enumeration.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of the enum (if supplied).
"storage" - Storage class (if any)
@ -3105,7 +3105,7 @@ Enumeration.
Enumeration value.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of the enum value.
"type" - Type (integer or char)
@ -3122,7 +3122,7 @@ Enumeration value.
C++ namespace.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of the namespace.
"symtab" - Symbol table for enclosed scope.
@ -3140,7 +3140,7 @@ C++ namespace.
C++ using directive.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of the object being referred to.
"uname" - Qualified name actually given to using.
@ -3158,7 +3158,7 @@ C++ using directive.
A forward C++ class declaration.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of the class.
"kind" - Class kind ("union", "struct", "class")
@ -3175,7 +3175,7 @@ Code insertion directive. For example, %{ ... %} or
%insert(section).
</p>
<div class="code">
<div class="diagram">
<pre>
"code" - Inserted code
"section" - Section name ("header", "wrapper", etc.)
@ -3190,7 +3190,7 @@ Code insertion directive. For example, %{ ... %} or
Top of the parse tree.
</p>
<div class="code">
<div class="diagram">
<pre>
"module" - Module name
</pre>
@ -3204,7 +3204,7 @@ Top of the parse tree.
%extend directive.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Module name
"symtab" - Symbol table of enclosed scope.
@ -3219,7 +3219,7 @@ Top of the parse tree.
%apply pattern { patternlist }.
</p>
<div class="code">
<div class="diagram">
<pre>
"pattern" - Source pattern.
"symtab" - Symbol table of enclosed scope.
@ -3234,7 +3234,7 @@ Top of the parse tree.
%clear patternlist;
</p>
<div class="code">
<div class="diagram">
<pre>
"firstChild" - Patterns to clear
</pre>
@ -3248,7 +3248,7 @@ Top of the parse tree.
%include directive.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Filename
"firstChild" - Children
@ -3263,7 +3263,7 @@ Top of the parse tree.
%import directive.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Filename
"firstChild" - Children
@ -3279,7 +3279,7 @@ Top of the parse tree.
%module directive.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name of the module
</pre>
@ -3294,7 +3294,7 @@ Top of the parse tree.
%typemap directive.
</p>
<div class="code">
<div class="diagram">
<pre>
"method" - Typemap method name.
"code" - Typemap code.
@ -3311,7 +3311,7 @@ Top of the parse tree.
%typemap directive with copy.
</p>
<div class="code">
<div class="diagram">
<pre>
"method" - Typemap method name.
"pattern" - Typemap source pattern.
@ -3328,7 +3328,7 @@ Top of the parse tree.
%typemap pattern. Used with %apply, %clear, %typemap.
</p>
<div class="code">
<div class="diagram">
<pre>
"pattern" - Typemap pattern (a parameter list)
"parms" - Typemap parameters.
@ -3343,7 +3343,7 @@ Top of the parse tree.
%types directive.
</p>
<div class="code">
<div class="diagram">
<pre>
"parms" - List of parameter types.
</pre>
@ -3358,7 +3358,7 @@ Top of the parse tree.
extern "X" { ... } declaration.
</p>
<div class="code">
<div class="diagram">
<pre>
"name" - Name "C", "Fortran", etc.
</pre>

8
SWIG/Doc/Manual/Introduction.html
View file

@ -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 :
</p>
<div class="code"><pre>
<div class="shell"><pre>
unix &gt; <b>swig -tcl example.i</b>
unix &gt; <b>gcc -c -fpic example.c example_wrap.c -I/usr/local/include</b>
unix &gt; <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):
</p>
<div class="code"><pre>
<div class="shell"><pre>
unix &gt; <b>swig -perl5 example.i</b>
unix &gt; <b>gcc -c example.c example_wrap.c \
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE</b>
@ -262,7 +262,7 @@ unix &gt;
Finally, let's build a module for Python (shown for Irix).
</p>
<div class="code"><pre>
<div class="shell"><pre>
unix &gt; <b>swig -python example.i</b>
unix &gt; <b>gcc -c -fpic example.c example_wrap.c -I/usr/local/include/python2.0</b>
unix &gt; <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
</p>
<div class="code"><pre>
<div class="shell"><pre>
unix &gt; <b>swig -perl5 -module example example.h</b>
unix &gt; <b>gcc -c example.c example_wrap.c \
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE</b>

28
SWIG/Doc/Manual/Library.html
View file

@ -182,7 +182,7 @@ void add(int x, int y, int *result);
Now, in Python:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; import example
&gt;&gt;&gt; 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)
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; import example
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; from example import *
&gt;&gt;&gt; a = malloc_int()
@ -698,7 +698,7 @@ Here is a short example:
Python example:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; a = intArray(10)
&gt;&gt;&gt; for i in range(0,10):
@ -949,7 +949,7 @@ void get_path(char *path);
In the target language:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; get_path()
/home/beazley/packages/Foo/Bar
@ -992,7 +992,7 @@ void get_packet(char *packet);
In the target language:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; get_packet()
'\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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; make_upper("hello world")
'HELLO WORLD'
@ -1087,7 +1087,7 @@ void attach_header(char *hstr);
In the target language:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; make_upper("hello world")
'HELLO WORLD'
@ -1138,7 +1138,7 @@ void get_path(char *path, int maxpath);
In the target language:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; get_path(1024)
'/home/beazley/Packages/Foo/Bar'
@ -1184,7 +1184,7 @@ void get_data(char *data, int *maxdata);
In the target language:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; get_data(1024)
'x627388912'
@ -1241,7 +1241,7 @@ void foo(char **s);
In the target language:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; foo()
'Hello world\n'
@ -1291,7 +1291,7 @@ void foo(char **s, int *slen);
In the target language:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; foo()
'\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 &amp;x);
In the target language:
</p>
<div class="code">
<div class="targetlang">
<pre>
x = foo(); # Returns a string object
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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; from example import *
&gt;&gt;&gt; iv = IntVector(4) # Create an vector&lt;int&gt;

6
SWIG/Doc/Manual/Preface.html
View file

@ -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
</p>
<div class="code"><pre>
<div class="shell"><pre>
<a href="http://www.swig.org">http://www.swig.org</a>
</pre></div>
@ -96,7 +96,7 @@ implementation tricks.
You can also subscribe to the SWIG mailing list by visiting the page
</p>
<div class="code"><pre>
<div class="shell"><pre>
<a href="http://www.swig.org/mail.html">http://www.swig.org/mail.html</a>
</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:
</p>
<div class="code"><pre>
<div class="shell"><pre>
<a href="http://www.swig.org/cvs.html">http://www.swig.org/cvs.html</a>
</pre></div>

40
SWIG/Doc/Manual/SWIG.html
View file

@ -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:
</p>
<div class="code"><pre>
<div class="shell"><pre>
swig [ <em>options</em> ] filename
-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:
</p>
<div class="code"><pre>
<div class="shell"><pre>
$ swig -c++ -python -o example_wrap.cpp example.i
</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:
</p>
<div class="code"><pre>
<div class="shell"><pre>
$ swig -c++ -python -outdir pyfiles -o cppfiles/example_wrap.cpp example.i
</pre></div>
<p>
If the directories <tt>cppfiles</tt> and <tt>pyfiles</tt> exist, the following
will be generated:</p>
<div class="code"><pre>
<div class="shell"><pre>
cppfiles/example_wrap.cpp
pyfiles/example.py
</pre></div>
@ -414,7 +414,7 @@ declarations are accessible as scripting language functions, variables, and
constants respectively. For example, in Tcl:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
% sin 3
5.2335956
% strcmp Dave Mike
@ -430,7 +430,7 @@ constants respectively. For example, in Tcl:
Or in Python:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
&gt;&gt;&gt; example.sin(3)
5.2335956
&gt;&gt;&gt; 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
pointers (in Tcl), might look like this:</p>
<div class="code"><pre>
<div class="targetlang"><pre>
_10081012_p_int
_1008e124_ppp_double
_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
expect :</p>
<div class="code"><pre>
<div class="targetlang"><pre>
# Copy a file
def filecopy(source,target):
f1 = fopen(source,"r")
@ -1115,7 +1115,7 @@ For example:
In this case, you might run SWIG as follows:
</p>
<div class="code">
<div class="shell">
<pre>
$ swig -I/usr/include -includeall example.i
</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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; set_foo("Hello World")
</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:
</p>
<div class="code">
<div class="shell">
<pre>
example.i:20. Typemap warning. Setting const char * variable may leak memory
</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
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 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:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
&gt;&gt;&gt; def add(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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; binary_op(3,4,add)
7
@ -1800,7 +1800,7 @@ Unfortunately, by declaring the callback functions as constants, they are no lon
as functions. For example:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; add(3,4)
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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; binary_op(3,4,add_cb)
7
@ -2070,7 +2070,7 @@ When this
situation is detected, SWIG may generate a warning message such as the
following :</p>
<div class="code"><pre>
<div class="shell"><pre>
interface.i:116. Warning. Array member will be read-only
</pre></div>
@ -2203,7 +2203,7 @@ can use the <tt>%nodefault</tt> directive or the <tt>-no_default</tt>
command line option. For example:
</p>
<div class="code"><pre>
<div class="shell"><pre>
swig -no_default example.i
</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
this :</p>
<div class="code"><pre>
<div class="targetlang"><pre>
&gt;&gt;&gt; v = Vector(3,4,0) # Create a new vector
&gt;&gt;&gt; print v.magnitude() # Print magnitude
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:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
# Perl5 script for accessing nested member
$o = CreateObject(); # Create an object somehow
$o-&gt;{intRep}-&gt;{ivalue} = 7 # Change value of o.intRep.ivalue

62
SWIG/Doc/Manual/SWIGPlus.html
View file

@ -205,7 +205,7 @@ When compiling and linking the resulting wrapper file, it is normal
to use the C++ compiler. For example:
</p>
<div class="code">
<div class="shell">
<pre>
$ swig -c++ -tcl example.i
$ 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:
</p>
<div class="code">
<div class="shell">
<pre>
% swig -Wall -python module.i
</pre>
@ -445,7 +445,7 @@ public:
then the copy constructor can be used as follows:
</p>
<div class="code">
<div class="targetlang">
<pre>
x = new_List() # Create a list
y = new_List(x) # Copy list x
@ -805,7 +805,7 @@ public:
<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_LAGER = Swig::LAGER
Swig_PORTER = Swig::PORTER
@ -916,7 +916,7 @@ void foo(const int &amp;x);
it is called from a script as follows:
</p>
<div class="code">
<div class="targetlang">
<pre>
foo(3) # Notice pass by value
</pre>
@ -1117,7 +1117,7 @@ public:
When wrapped into Python, we can now perform the following operations
:</p>
<div class="code"><pre>
<div class="targetlang"><pre>
$ python
&gt;&gt;&gt; import shapes
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="shell">
<pre>
example:18. Nothing known about class 'Foo'. Ignored.
</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:
</p>
<div class="code">
<div class="diagram">
<pre>
_808fea88_p_Circle
</pre>
@ -1328,7 +1328,7 @@ representation of <tt>C</tt>. With multiple inheritance, the data from
each base class is stacked together. For example:
</p>
<div class="code">
<div class="diagram">
<pre>
------------ &lt;--- (C *), (A *)
| A |
@ -1437,7 +1437,7 @@ void foo(char *x) {
The function is used in a completely natural way. For example:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; foo(3)
x is 3
@ -1468,7 +1468,7 @@ public:
it might be used like this
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; f = Foo() # Create a Foo
&gt;&gt;&gt; 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
(which is determined by the language module).</p>
<div class="code">
<div class="diagram">
<pre>
Type Precedence
---------------- ----------
@ -1559,7 +1559,7 @@ The first rule simply ranks the functions by required argument count.
This would produce the following list:
</p>
<div class="code">
<div class="diagram">
<pre>
rank
-----
@ -1578,7 +1578,7 @@ rank
The second rule, simply refines the ranking by looking at argument type precedence values.
</p>
<div class="code">
<div class="diagram">
<pre>
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:
</p>
<div class="code">
<div class="shell">
<pre>
example.i:4: Warning(509): Overloaded foo(long) is shadowed by foo(int) at example.i:3.
</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:
</p>
<div class="code">
<div class="shell">
<pre>
example.i:4: Warning(516): Overloaded method foo(long) ignored. Method foo(int)
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:
</p>
<div class="code">
<div class="shell">
<pre>
example.i:3: Warning(467): Overloaded foo(int) not supported (no type checking
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,
</p>
<div class="code">
<div class="shell">
<pre>
foo.i:6. Overloaded declaration ignored. Spam::foo(double )
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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; a = Complex(3,4)
&gt;&gt;&gt; b = Complex(5,2)
@ -2248,7 +2248,7 @@ name. If you wrote this:
The resulting scripting interface might work like this:
</p>
<div class="code">
<div class="targetlang">
<pre>
a = Complex(3,4)
b = Complex(5,2)
@ -2361,7 +2361,7 @@ allow us to print the value of an object using the <tt>print</tt>
command.
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
&gt;&gt;&gt;
&gt;&gt;&gt; v = Vector();
&gt;&gt;&gt; v.x = 3
@ -2651,7 +2651,7 @@ then SWIG knows that <tt>List&lt;int&gt;</tt> was already wrapped as a class cal
nothing is known about <tt>List&lt;int&gt;</tt>, you will get a warning message similar to this:
</p>
<div class="code">
<div class="shell">
<pre>
example.h:42. Nothing known about class 'List&lt;int &gt;' (ignored).
example.h:42. Maybe you forgot to instantiate 'List&lt;int &gt;' using %template.
@ -3347,7 +3347,7 @@ namespace B {
When this conflict occurs, you will get an error message that resembles this:
</p>
<div class="code">
<div class="shell">
<pre>
example.i:26. Error. 'foo' is multiply defined in the generated module.
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:
</p>
<div class="code">
<div class="targetlang">
<pre>
f = Foo()
try:
@ -3661,7 +3661,7 @@ When pointers to members are supported, the pointer value might appear as a spec
string like this:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; print example.FOO
_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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; f = make_Foo()
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
f = Foo() # Smart-pointer
p = f.__deref__() # Raw pointer from operator-&gt;
@ -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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; import example
&gt;&gt;&gt; f = example.FooBar()
@ -4125,7 +4125,7 @@ void blah() {
Now, consider the behavior when wrapped into a Python module:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; bar(foo()) # Okay
&gt;&gt;&gt;
@ -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:
</p>
<div class="code">
<div class="targetlang">
<pre>
class Foo:
def __init__(self):
@ -4274,7 +4274,7 @@ public:
Now, consider some script code that uses these classes:
</p>
<div class="code">
<div class="targetlang">
<pre>
f = Foo() # Creates a new Foo
s = Spam() # Creates a new Spam

18
SWIG/Doc/Manual/Scripting.html
View file

@ -181,7 +181,7 @@ double Foo = 3.5;
<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
$Foo = $a + 2.0; # Assignment
</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:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
% set v [new_Vector]
% Vector_x_set $v 3.5
% 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:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
&gt;&gt;&gt; v = Vector()
&gt;&gt;&gt; v.x = 3
&gt;&gt;&gt; v.y = 4
@ -321,7 +321,7 @@ a more natural manner from the interpreter. For example, in Python, you might wa
<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-&gt;{x} = 3;
$v-&gt;{y} = 4;
@ -332,7 +332,7 @@ $v-&gt;{z} = -13;
Finally, in Tcl :
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
Vector v
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
for a few common machines is shown below:</p>
<div class="code"><pre>
<div class="shell"><pre>
# Build a shared library for Solaris
gcc -c example.c example_wrap.c -I/usr/local/include
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:
</p>
<div class="code"><pre>
<div class="targetlang"><pre>
% load ./example.so
% fact 4
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
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
</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
the following :</p>
<div class="code"><pre>
<div class="targetlang"><pre>
&gt;&gt;&gt; import graph
Traceback (innermost last):
File "&lt;stdin&gt;", line 1, in ?

40
SWIG/Doc/Manual/Typemaps.html
View file

@ -603,7 +603,7 @@ you can't use typemaps to interchange the arguments, allowing you to call the
function like this:
</p>
<div class="code">
<div class="targetlang">
<pre>
foo("hello",3) # Reversed arguments
</pre>
@ -682,7 +682,7 @@ are sometimes to attach extra information to a typemap and is often target-langu
this list is as follows:
</p>
<div class="code">
<div class="diagram">
<pre>
typelist : typepattern [, typepattern, typepattern, ... ] ;
@ -703,7 +703,7 @@ variables (parms). The purpose of these variables will be explained shortly.
forms:
</p>
<div class="code">
<div class="diagram">
<pre>
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:
</p>
<div class="code">
<div class="diagram">
<pre>
const char *s Exact type and name 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:
</p>
<div class="code">
<div class="diagram">
<pre>
Integer x
Integer
@ -1117,7 +1117,7 @@ Finding no match, it then applies a reduction <tt>Integer -&gt; int</tt> to the
repeats the search.
</p>
<div class="code">
<div class="diagram">
<pre>
int x
int --&gt; 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
$x = foo("Hello World");
</pre>
@ -1770,7 +1770,7 @@ on the left-hand side of a C assignment operation. Here are a few examples of
and ltypes:
</p>
<div class="code">
<div class="diagram">
<pre>
type ltype
------ ----------------
@ -2080,7 +2080,7 @@ with an "in" typemap---possibly to ignore the input value. For example:
The following special variables are available.
</p>
<div class="code">
<div class="diagram">
<pre>
$result - Result object returned to target language.
$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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; set_vector(type, [ 1, 2.5, 5, 20 ])
</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:
</p>
<div class="code"><pre>
<div class="shell"><pre>
swig -python example.i
Generating wrappers for Python
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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; s = SomeObject()
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; s = SomeObject()
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; s = SomeObject()
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; foo(["ale","lager","stout"])
</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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; f = example.open("Makefile")
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="diagram">
<pre>
_108e688_p_Foo
</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:
</p>
<div class="code">
<div class="diagram">
<pre>
FooBar --&gt; | -----------| &lt;-- Foo
| 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
# Python
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:
</p>
<div class="code">
<div class="diagram">
<pre>
Symbolic Name Precedence Value
------------------------------ ------------------

6
SWIG/Doc/Manual/Varargs.html
View file

@ -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):
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; traceprintf("Hello World")
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; import example
&gt;&gt;&gt; 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:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; example.printf("la de da de da %s", 42)
Segmentation fault (core dumped)

10
SWIG/Doc/Manual/Warnings.html
View file

@ -41,7 +41,7 @@
During compilation, SWIG may generate a variety of warning messages. For example:
</p>
<div class="code">
<div class="shell">
<pre>
example.i:16: Warning(501): Overloaded declaration ignored. bar(double)
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:
</p>
<div class="code">
<div class="shell">
<pre>
% swig -python -w501 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:
</p>
<div class="code">
<div class="shell">
<pre>
% swig -Wall -python example.i
</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:
</p>
<div class="code">
<div class="shell">
<pre>
% swig -w+309,+452 example.i
</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:
</p>
<div class="code"><pre>
<div class="shell"><pre>
$ swig -python -Fstandard example.i
example.i:4: Syntax error in input.
$ swig -python -Fmicrosoft example.i