0a0e96f20e
after swig-1.3a4 release. git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@586 626c5289-ae23-0410-ae9c-e8d60b6d4f22
638 lines
20 KiB
HTML
638 lines
20 KiB
HTML
<html>
|
|
<head>
|
|
<title>SWIG Internals</title>
|
|
</head>
|
|
|
|
<body>
|
|
<center>
|
|
<h1>SWIG Internals Manual</h1>
|
|
|
|
<b>Thien-Thi Nguyen <br>
|
|
ttn@glug.org <br>
|
|
|
|
<p>
|
|
David M. Beazley <br>
|
|
beazley@cs.uchicago.edu </br>
|
|
|
|
</b>
|
|
</center>
|
|
|
|
<p>
|
|
<b>$Header$</b>
|
|
|
|
<p>
|
|
(Note : This is a work in progress.)
|
|
|
|
<h2>1. Introduction</h2>
|
|
|
|
This document details SWIG internals: architecture and sometimes
|
|
implementation. The first few sections concentrate on data structures,
|
|
interfaces, conventions and code shared by all language targets.
|
|
Subsequent sections focus on a particular language.
|
|
|
|
<p>
|
|
The audience is assumed to be SWIG developers (who should also read the
|
|
<a href="engineering.html">SWIG Engineering Manual</a> before starting
|
|
to code).
|
|
|
|
<h3>Directory Guide</h3>
|
|
|
|
<table border=1>
|
|
<tr><td><a href="index.html">Doc</a></td>
|
|
<td>HTML documentation. If you find a documentation bug, please
|
|
<a href="mailto:bug-swig-doc@glug.org">let us know</a>.</td>
|
|
</tr>
|
|
|
|
<tr><td>Examples</td>
|
|
<td>This subdir tree contains examples of using SWIG w/ different
|
|
scripting languages, including makefiles. Typically, there are the
|
|
"simple" and "matrix" examples, w/ some languages offering additional
|
|
examples. The GIFPlot example has its own set of per-language
|
|
subdirectories. See the README more index.html file in each directory
|
|
for more info. [FIXME: Ref SWIG user manual.]</td>
|
|
</tr>
|
|
|
|
<tr><td>Lib</td>
|
|
<td>These are the <tt>.i</tt> (interface) files that form the SWIG
|
|
installed library. Language-specific files are in subdirectories (for
|
|
example, guile/typemaps.i). Each language also has a <tt>.swg</tt> file
|
|
implementing runtime type support for that language. The SWIG library
|
|
is not versioned.</td>
|
|
</tr>
|
|
|
|
<tr><td>Misc</td>
|
|
<td>Currently this subdir only contains file <tt>fileheader</tt>. See
|
|
the <a href="engineering.html">Engineering Manual</a> for more
|
|
info.</td>
|
|
</tr>
|
|
|
|
<tr><td>Runtime</td>
|
|
<td>This subdir contains scripts and a makefile for creating runtime
|
|
shared-object libraries used by various languages. Runtime/make.sh
|
|
says: "The runtime libraries are only needed if you are building
|
|
multiple extension modules that need to share information."</td>
|
|
</tr>
|
|
|
|
<tr><td>Source</td>
|
|
<td>SWIG source code is in this subdir tree. Directories marked w/ "(*)"
|
|
are used in building the <tt>swig</tt> executable.
|
|
|
|
<table border=1>
|
|
|
|
<tr><td>DOH (*)</td>
|
|
<td>C library providing memory allocation, file access and generic
|
|
containers. Result: libdoh.a</td>
|
|
</tr>
|
|
|
|
<tr><td>Experiment</td>
|
|
<td>[TODO]</td>
|
|
</tr>
|
|
|
|
<tr><td>Include (*)</td>
|
|
<td>Configuration .h files</td>
|
|
</tr>
|
|
|
|
<tr><td>LParse</td>
|
|
<td>Parser (lex / yacc) files and support [why not (*)?!]</td>
|
|
</tr>
|
|
|
|
<tr><td>Modules</td>
|
|
<td>[TODO]</td>
|
|
</tr>
|
|
|
|
<tr><td>Modules1.1 (*)</td>
|
|
<td>Language-specific callbacks that does actual code generation (each
|
|
language has a .cxx and a .h file). Result: libmodules11.a</td>
|
|
</tr>
|
|
|
|
<tr><td>Preprocessor (*)</td>
|
|
<td>SWIG-specialized C/C++ preprocessor. Result: libcpp.a</td>
|
|
</tr>
|
|
|
|
<tr><td>SWIG1.1 (*)</td>
|
|
<td>Parts of SWIG that are not language-specific, including option
|
|
processing and the type-mapping system. Result: libswig11.a.
|
|
Note: This directory is currently being phased out. </td>
|
|
</tr>
|
|
|
|
<tr><td>SWIG1.3</td>
|
|
<td>[TODO] [funny, nothing here is presently used for swig-1.3].
|
|
This directory might turn into a compatibility interface between
|
|
SWIG1.3 and the SWIG1.1 modules.</td>
|
|
</tr>
|
|
|
|
<tr><td>Swig (*)</td>
|
|
<td>This directory contains the new ANSI C core of the system
|
|
and contains generic functions related to types, file handling,
|
|
scanning, and so forth.</td>
|
|
</tr>
|
|
|
|
</table></td>
|
|
</tr>
|
|
|
|
<tr><td>Tools</td>
|
|
<td>Libtool support and the mkdist.py script.</td>
|
|
</tr>
|
|
|
|
<tr><td>Win</td>
|
|
<td>This improperly-named (spit spit) subdir only has README.txt.</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
|
|
<h3>Overall Program Flow</h3>
|
|
|
|
Here is the general control flow and where under subdir <tt>Source</tt>
|
|
to look for code:
|
|
|
|
<ul>
|
|
|
|
<li> <tt>Modules1.1/swigmain.cxx:main()</tt> is the program entry
|
|
point. It parses the language-specifying command-line option (for
|
|
example, <tt>-java</tt>), creating a new language-specific wrapping
|
|
object (each language is a C++ class derived from base class
|
|
<tt>Language</tt>). This object and the command-line is passed to
|
|
<tt>SWIG_main()</tt>, whose return value is the program exit value.
|
|
|
|
<li> <tt>SWIG1.1/main.cxx:SWIG_main()</tt> is the "real" main. It
|
|
initializes the preprocessor and typemap machinery, defines some
|
|
preprocessor symbols, locates the SWIG library, processes common
|
|
command-line options, and then calls the language-specific command-line
|
|
parser. From here there are three paths: "help", "checkout" and
|
|
everything else.
|
|
<ul>
|
|
<li> In "help" mode, clean up open files and exit.
|
|
<li> In "checkout" mode, copy specified files from the SWIG library
|
|
to the current directory. Errors cause error messages but no
|
|
non-lcoal exits.
|
|
<li> Otherwise, do wrapping: determine output file name(s), define
|
|
some preprocessor symbols and run the preprocessor, initialize
|
|
the interface-definition parser, set up the typemap for handling
|
|
new return strings, and finally do the language-specific parse
|
|
(by calling the language object's <tt>parse()</tt> method), which
|
|
creates output files by side-effect.
|
|
</ul>
|
|
Afterwards, remove temporary files, and clean up. If the command-line
|
|
included <tt>-freeze</tt>, go into an infinite loop; otherwise return the
|
|
error count.
|
|
|
|
<li> The language-specific <tt>parse()</tt> (and all other
|
|
language-specific code) lives in <tt>Modules1.1/foo.{h,cxx}</tt> for
|
|
language Foo. Typically, <tt>FOO::parse()</tt> calls
|
|
<tt>FOO::headers()</tt> and then the global function <tt>yyparse()</tt>,
|
|
which uses the callbacks registered by <tt>SWIG_main()</tt> above.
|
|
|
|
</ul>
|
|
|
|
<h3>Table of Contents</h3>
|
|
<ul>
|
|
<li><a name="i2" href="#2">2. DOH</a>
|
|
<li><a name="i3" href="#3">3. Types and Typemaps</a>
|
|
<li><a name="i4" href="#4">4. Parsing</a>
|
|
<li><a name="i5" href="#5">5. Difference Between SWIG 1.1 and SWIG 1.3</a>
|
|
<li><a name="i6" href="#6">6. Plans for SWIG 2.0</a>
|
|
<li><a name="i7" href="#7">7. Reserved</a>
|
|
<li><a name="i8" href="#8">8. Reserved</a>
|
|
<li><a name="i9" href="#9">9. Reserved</a>
|
|
<li><a name="i10" href="#10">10. Guile Support</a>
|
|
<li><a name="i11" href="#11">11. Python Support</a>
|
|
<li><a name="i12" href="#12">12. Perl Support</a>
|
|
<li><a name="i13" href="#13">13. Java Support</a>
|
|
</ul>
|
|
|
|
<a name="2" href="#i2">
|
|
<h2>2. DOH</h2>
|
|
</a>
|
|
|
|
DOH is a collection of low-level objects such as strings, lists, and
|
|
hash tables upon which the rest of SWIG is built. The name 'DOH'
|
|
unofficially stands for "Dave's Object Hack", but it's also a good
|
|
expletive to use when things don't work (as in "SWIG core
|
|
dumped---DOH!").
|
|
|
|
<h3>2.1 Motivation and Background</h3>
|
|
|
|
The development of DOH is influenced heavily by the problems
|
|
encountered during earlier attempts to create a C++ based version of
|
|
SWIG2.0. In each of these attempts (over a 3 year period), the
|
|
resulting system always ended up growing into a collossal nightmare of
|
|
large inheritance hierarchies and dozens of specialized classes for
|
|
different types of objects (functions, variables, constants, etc.).
|
|
The end result was that the system was tremendously complicated,
|
|
difficult to understand, difficult to maintain, and fairly inflexible
|
|
in the grand scheme of things.
|
|
|
|
<p>
|
|
DOH takes a different approach to tackling the complexity problem.
|
|
First, rather than going overboard with dozens of types and class
|
|
definitions, DOH only defines a handful of simple yet very useful
|
|
objects that are easy to remember. Second, DOH uses dynamic
|
|
typing---one of the features that make scripting languages so useful
|
|
and which make it possible to accomplish things with much less code.
|
|
Finally, DOH utilizes a few coding tricks that allow it to perform
|
|
a limited form of function overloading for certain C datatypes (more
|
|
on that a little later).
|
|
|
|
<p>
|
|
The key point to using DOH is that instead of thinking about code in
|
|
terms of highly specialized C data structures, just about everything
|
|
ends up being represented in terms of a just a few datatypes. For
|
|
example, structures are replaced by DOH hash tables whereas arrays are
|
|
replaced by DOH lists. At first, this is probably a little strange to
|
|
most C/C++ programmers, but in the long run in makes the system
|
|
extremely flexible and highly extensible. Also, in terms of coding,
|
|
many of the newly DOH-based subsystems are less than half the size (in
|
|
lines of code) of the earlier C++ implementation.
|
|
|
|
<h3>2.2 Basic Types</h3>
|
|
|
|
The following built-in types are currently provided by DOH:
|
|
|
|
<ul>
|
|
<li><b>String</b>. A string of characters with automatic memory
|
|
management and high-level operations such as string replacement. In addition,
|
|
strings support file I/O operations that make it possible to use them just
|
|
about anyplace a file can be used.
|
|
|
|
<p>
|
|
<li><b>List</b>. A list of arbitrary DOH objects (of possibly mixed types).
|
|
|
|
<p>
|
|
<li><b>Hash</b>. A hash table that maps a set of string keys to a set of arbitrary
|
|
DOH objects. The DOH version of an associative array for all of you Perl fans.
|
|
|
|
<p>
|
|
<li><b>File</b>. A DOH wrapper around the C FILE * structure. This is provided
|
|
since other objects sometimes want to behave like files (strings for instance).
|
|
|
|
<p>
|
|
<li><b>Void</b>. A DOH wrapper around an arbitrary C pointer. This can be used
|
|
if you want to place arbitrary C data structures in DOH lists and hash tables.
|
|
</ul>
|
|
|
|
Due to dynamic typing, all of the objects in DOH are represented by pointers
|
|
of type <tt>DOH *</tt>. Furthermore, all objects are completely
|
|
opaque--that means that the only way to access the internals of an
|
|
object is through a well-defined public API. For convenience, the following
|
|
symbolic names are sometimes used to improve readability:
|
|
|
|
<ul>
|
|
<Li><tt>DOHString *</tt>. A String object.
|
|
<li><tt>DOHList *</tt>. A list object.
|
|
<li><tt>DOHHash *</tt>. A hash object.
|
|
<li><tt>DOHFile *</tt>. A file object.
|
|
<li><tt>DOHVoid *</tt>. A void object.
|
|
<li><tt>DOHString_or_char *</tt>. A DOH String object or a raw C "char *".
|
|
</ul>
|
|
|
|
It should be stressed that all of these names are merely symbolic aliases to the
|
|
type <tt>DOH *</tt> and that no compile-time type checking is performed (of course,
|
|
a runtime error may occur if you screw up).
|
|
|
|
<h3>2.3 Creating, Copying, and Destroying Objects </h2>
|
|
|
|
The following functions can be used to create new DOH objects
|
|
|
|
<ul>
|
|
<Li><tt>NewString(DOHString_or_char *value)</tt><br>
|
|
Create a new string object with contents initially
|
|
set to value. value can be either a C string or a DOH string object.
|
|
|
|
<p>
|
|
<li><tt>NewStringf(char *fmt, ...)</tt><br>
|
|
Create a new string object with contents initially set to
|
|
a formatted string. Think of this as being sprintf() combined with an object constructor.
|
|
|
|
<p>
|
|
<li><tt>NewList()</tt><br>
|
|
Create a new list object that is initially empty.
|
|
|
|
<p>
|
|
<Li><tt>NewHash()</tt><br>
|
|
Create a new hash object that is initially empty.
|
|
|
|
<p>
|
|
<li><tt>NewFile(DOHString_or_char *filename, char *mode)</tt><br>
|
|
Open a file and return a file object. This is a
|
|
wrapper around the C <tt>fopen()</tt> library call.
|
|
|
|
<p>
|
|
<li><tt>NewFileFromFile(FILE *f)</tt><br>
|
|
Create a new file object given an already opened <tt>FILE *</tt> object.
|
|
|
|
<p>
|
|
<li><tt>NewVoid(void *obj, void (*del)(void *))</tt><br>
|
|
Create a new DOH object that is a wrapper around an
|
|
arbitrary C pointer. <tt>del</tt> is an optional destructor function that will be called when the object
|
|
is destroyed.
|
|
|
|
</ul>
|
|
|
|
Any object can be copied using the <tt>Copy()</tt> function. For example:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
DOH *a, *b, *c, *d;
|
|
a = NewString("Hello World");
|
|
b = NewList();
|
|
c = Copy(a); /* Copy the string a */
|
|
d = Copy(b); /* Copy the list b */
|
|
</pre>
|
|
</blockquote>
|
|
|
|
Copies of lists and hash tables are shallow. That is, their contents are only copied by reference.
|
|
|
|
<p>
|
|
Objects can be deleted using the <tt>Delete()</tt> function. For example:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
DOH *a = NewString("Hello World");
|
|
...
|
|
Delete(a); /* Destroy a */
|
|
</pre>
|
|
</blockquote>
|
|
|
|
All objects are referenced counted and given a reference count of 1 when initially created. The
|
|
<tt>Delete()</tt> function only destroys an object when the reference count reaches zero. When
|
|
an object is placed in a list or hash table, it's reference count is automatically increased. For example:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
DOH *a, *b;
|
|
a = NewString("Hello World");
|
|
b = NewList();
|
|
Append(b,a); /* Increases refcnt of a to 2 */
|
|
Delete(a); /* Decreases refcnt of a to 1 */
|
|
Delete(b); /* Destroys b, and destroys a */
|
|
</pre>
|
|
</blockquote>
|
|
|
|
Should it ever be necessary to manually increase the reference count of an object, the DohIncref() function
|
|
can be used:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
DOH *a = NewString("Hello");
|
|
DohIncref(a);
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<h3>2.4 A Word About Mutability and Copying</h3>
|
|
|
|
All DOH objects are mutable regardless of their current reference
|
|
count. For example, if you create a string and then create a 1000
|
|
references to it (in lists and hash tables), changes to the string
|
|
will be reflected in all of the references. Therefore, if you need to
|
|
make any kind of local change, you should first make a copy using the
|
|
Copy() function. Caveat: when copying lists and hash tables, elements
|
|
are copied by reference.
|
|
|
|
<h3>2.5 Strings</h3>
|
|
|
|
The DOH String type is perhaps the most flexible object. First, it supports a variety of string-oriented
|
|
operations. Second, it supports many of the same operations as lists. Finally, strings provide file I/O
|
|
operations that allow them to be used interchangably with DOH file objects.
|
|
|
|
[ TODO ]
|
|
|
|
<h3>2.6 Lists</h3>
|
|
|
|
[ TODO ]
|
|
|
|
<h3>2.7 Hash tables </h3>
|
|
|
|
[ TODO ]
|
|
|
|
<h3>2.8 Files </h3>
|
|
|
|
[ TODO ]
|
|
|
|
<h3>2.9 Void objects </h3>
|
|
|
|
[ TODO ]
|
|
|
|
<h3>2.10 Utility functions </h3>
|
|
|
|
[ TODO ]
|
|
|
|
<a name="3" href="#i3">
|
|
<h2>3. Types and Typemaps</h2>
|
|
</a>
|
|
|
|
[TODO]
|
|
|
|
<a name="4" href="#i4">
|
|
<h2>4. Parsing</h2>
|
|
</a>
|
|
|
|
[TODO]
|
|
|
|
<a name="5" href="#i5">
|
|
<h2>5. Difference Between SWIG 1.1 and SWIG 1.3</h2>
|
|
</a>
|
|
|
|
[TODO]
|
|
|
|
<a name="6" href="#i6">
|
|
<h2>6. Plans for SWIG 2.0</h2>
|
|
</a>
|
|
|
|
[TODO]
|
|
|
|
<a name="7" href="#i7">
|
|
<h2>7. Reserved</h2>
|
|
</a>
|
|
|
|
<a name="8" href="#i8">
|
|
<h2>8. Reserved</h2>
|
|
</a>
|
|
|
|
<a name="9" href="#i9">
|
|
<h2>9. Reserved</h2>
|
|
</a>
|
|
|
|
<a name="10" href="#i10">
|
|
<h2>10. Guile Support</h2>
|
|
</a>
|
|
|
|
This section details guile-specific support in SWIG.
|
|
|
|
<h3>Meaning of "Module"</h3>
|
|
|
|
<p>
|
|
There are three different concepts of "module" involved, defined
|
|
separately for SWIG, Guile, and Libtool. To avoid horrible confusion,
|
|
we explicitly prefix the context, e.g., "guile-module".
|
|
|
|
<h3>Linkage</h3>
|
|
|
|
<p>
|
|
Guile support is complicated by a lack of user community cohesiveness,
|
|
which manifests in multiple shared-library usage conventions. A set of
|
|
policies implementing a usage convention is called a <b>linkage</b>.
|
|
The default linkage is the simplest; nothing special is done. In this
|
|
case <code>SWIG_init()</code> is provided and users must do something
|
|
like this:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
(define my-so (dynamic-link "./example.so"))
|
|
(dynamic-call "SWIG_init" my-so)
|
|
</pre>
|
|
</blockquote>
|
|
|
|
At this time, the name <code>SWIG_init</code> is hardcoded; this
|
|
approach does not work with multiple swig-modules. NOTE: The "simple"
|
|
and "matrix" examples under Examples/guile include guilemain.i; the
|
|
resulting standalone interpreter does not require calls to
|
|
<code>dynamic-link</code> and <code>dynamic-call</code>, as shown here.
|
|
|
|
<p>
|
|
A second linkage creates "libtool dl module" wrappers, and currently is
|
|
broken. Whoever fixes this needs to track Guile's libtool dl module
|
|
convention, since that is not finalized.
|
|
|
|
<p>
|
|
The only other linkage supported at this time creates shared object
|
|
libraries suitable for use by hobbit's <code>(hobbit4d link)</code>
|
|
guile module. This is called the "hobbit" linkage, and requires also
|
|
using the "-package" command line option to set the part of the module
|
|
name before the last symbol. For example, both command lines:
|
|
[checkme:ttn]
|
|
|
|
<blockquote>
|
|
<pre>
|
|
swig -guile -package my/lib foo.i
|
|
swig -guile -package my/lib -module foo foo.i
|
|
</pre>
|
|
</blockquote>
|
|
|
|
would create module <code>(my lib foo)</code> (assuming in the first
|
|
case foo.i declares the module to be "foo"). The installed files are
|
|
my/lib/libfoo.so.X.Y.Z and friends. This scheme is still very
|
|
experimental; the (hobbit4d link) conventions are not well understood.
|
|
|
|
<p>
|
|
There are no other linkage types planned, but that could change... To
|
|
add a new type, add the name to the enum in guile.h and add the case to
|
|
<code>GUILE::emit_linkage()</code>.
|
|
|
|
<h3>Underscore Folding</h3>
|
|
|
|
<p>
|
|
Underscores are converted to dashes in identifiers. Guile support may
|
|
grow an option to inhibit this folding in the future, but no one has
|
|
complained so far.
|
|
|
|
<h3>Typemaps</h3>
|
|
|
|
<p>
|
|
It used to be that the mappings for "native" types were included in
|
|
guile.cxx. This information is now in Lib/guile/typemaps.i, which
|
|
presents a new challenge: how to have SWIG include typemaps.i before
|
|
processing the user's foo.i. At this time, we must say:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
%include guile/typemaps.i
|
|
</pre>
|
|
</blockquote>
|
|
|
|
in foo.i. This may change in the future.
|
|
|
|
<h3>Smobs</h3>
|
|
|
|
<p>
|
|
For pointer types, SWIG uses Guile smobs. This feature used to be
|
|
available only SWIG was invoked with the command-line option
|
|
"-with-smobs", but as of 2000/07/06 (swig-1.3a4) this is the default
|
|
behavior; the command-line option "-with-smobs" is ignored silently.
|
|
We plan to drop silent recognition of this option after 1.3a4.
|
|
|
|
<p>
|
|
Currently, one wrapper module must be generated without
|
|
<code>-c</code> and compiled with <code>-DSWIG_GLOBAL</code>, all the
|
|
other wrapper modules must be generated with <code>-c</code>. Maybe
|
|
one should move all the global helper functions that come from
|
|
<code>guile.swg</code> into a library, which is built by <code>make
|
|
runtime</code>.
|
|
|
|
<p>
|
|
In earlier versions of SWIG, C pointers were represented as Scheme
|
|
strings containing a hexadecimal rendering of the pointer value and a
|
|
mangled type name. As Guile allows registering user types, so-called
|
|
"smobs" (small objects), a much cleaner representation has been
|
|
implemented now. The details will be discussed in the following.
|
|
|
|
<p>
|
|
A smob is a cons cell where the lower half of the CAR contains the
|
|
smob type tag, while the upper half of the CAR and the whole CDR are
|
|
available. <code>SWIG_Guile_Init()</code> registers a smob type named
|
|
"swig" with Guile; its type tag is stored in the variable
|
|
<code>swig_tag</code>. The upper half of the CAR store an index into
|
|
a table of all C pointer types seen so far, to which new types seen
|
|
are appended. The CDR stores the pointer value. SWIG smobs print
|
|
like this: <code>#<swig struct xyzzy * 0x1234affe></code> Two of
|
|
them are <code>equal?</code> if and only if they have the same type
|
|
and value.
|
|
|
|
<p>
|
|
To construct a Scheme object from a C pointer, the wrapper code calls
|
|
the function <code>SWIG_Guile_MakePtr_Str()</code>, passing both a
|
|
mangled type string and a pretty type string. The former is looked up
|
|
in the type table to get the type index to store in the upper half of
|
|
the CAR. If the type is new, it is appended to type table.
|
|
|
|
<p>
|
|
To get the pointer represented by a smob, the wrapper code calls the
|
|
function <code>SWIG_Guile_GetPtr_Str</code>, passing the mangled name
|
|
of the expected pointer type, which is used for looking up the type in
|
|
the type table and accessing the list of compatible types. If the
|
|
Scheme object passed was not a SWIG smob representing a compatible
|
|
pointer, a <code>wrong-type-arg</code> exception is raised.
|
|
|
|
<h3>Exception Handling</h3>
|
|
|
|
<p>
|
|
SWIG code calls <code>scm_error</code> on exception, using the following
|
|
mapping:
|
|
|
|
<pre>
|
|
MAP(SWIG_MemoryError, "swig-memory-error");
|
|
MAP(SWIG_IOError, "swig-io-error");
|
|
MAP(SWIG_RuntimeError, "swig-runtime-error");
|
|
MAP(SWIG_IndexError, "swig-index-error");
|
|
MAP(SWIG_TypeError, "swig-type-error");
|
|
MAP(SWIG_DivisionByZero, "swig-division-by-zero");
|
|
MAP(SWIG_OverflowError, "swig-overflow-error");
|
|
MAP(SWIG_SyntaxError, "swig-syntax-error");
|
|
MAP(SWIG_ValueError, "swig-value-error");
|
|
MAP(SWIG_SystemError, "swig-system-error");
|
|
</pre>
|
|
|
|
<p>
|
|
The default when not specified here is to use "swig-error".
|
|
See Lib/exception.i for details.
|
|
|
|
<a name="11" href="#i11">
|
|
<h2>10. Python Support</h2>
|
|
</a>
|
|
|
|
[TODO]
|
|
|
|
<a name="12" href="#i12">
|
|
<h2>10. Perl Support</h2>
|
|
</a>
|
|
|
|
[TODO]
|
|
|
|
<a name="13" href="#i13">
|
|
<h2>10. Java Support</h2>
|
|
</a>
|
|
|
|
[TODO]
|
|
|
|
</body>
|
|
</html>
|