Merge branch 'master' into gsoc2009-matevz
parser.y still to be fixed up Conflicts: Doc/Devel/engineering.html Examples/Makefile.in Lib/allegrocl/allegrocl.swg Lib/csharp/csharp.swg Lib/csharp/enums.swg Lib/csharp/enumsimple.swg Lib/csharp/enumtypesafe.swg Lib/java/java.swg Lib/python/pydocs.swg Lib/r/rtype.swg Source/Include/swigwarn.h Source/Modules/octave.cxx Source/Modules/python.cxx Source/Modules/ruby.cxx Source/Swig/scanner.c Source/Swig/stype.c Source/Swig/swig.h configure.ac
This commit is contained in:
William S Fulton
commit
e805d5f925
1074 changed files with 54339 additions and 20134 deletions
127
.gitignore
vendored
Normal file
127
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,127 @@
|
|||
# Compiled Source
|
||||
*.o
|
||||
*.class
|
||||
|
||||
# Editor files and various other junk
|
||||
*.sw?
|
||||
*.bak
|
||||
|
||||
# Local PCRE
|
||||
pcre
|
||||
*.gz
|
||||
|
||||
# C/C++ object files, based on:
|
||||
# https://github.com/github/gitignore/blob/master/C.gitignore
|
||||
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
|
||||
*.slo
|
||||
*.lo
|
||||
|
||||
# C/C++ dynamic libraries, based on:
|
||||
# https://github.com/github/gitignore/blob/master/C.gitignore
|
||||
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
|
||||
*.dll
|
||||
*.so
|
||||
*.so.*
|
||||
*.dylib
|
||||
|
||||
# C/C++ static libraries, based on:
|
||||
# https://github.com/github/gitignore/blob/master/C.gitignore
|
||||
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
|
||||
*.lib
|
||||
*.lai
|
||||
*.la
|
||||
*.a
|
||||
|
||||
# C/C++ executables, based on:
|
||||
# https://github.com/github/gitignore/blob/master/C.gitignore
|
||||
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
|
||||
*.exe
|
||||
*.out
|
||||
*.app
|
||||
|
||||
# Generated by autogen.sh
|
||||
CCache/autom4te.cache/
|
||||
CCache/config.h.in
|
||||
CCache/configure
|
||||
Source/Include/swigconfig.h.in
|
||||
Source/Makefile.in
|
||||
Tools/config/compile
|
||||
Tools/config/config.guess
|
||||
Tools/config/config.sub
|
||||
Tools/config/depcomp
|
||||
Tools/config/install-sh
|
||||
Tools/config/missing
|
||||
Tools/config/ylwrap
|
||||
aclocal.m4
|
||||
autom4te.cache/
|
||||
configure
|
||||
|
||||
# Generated by ./configure
|
||||
CCache/Makefile
|
||||
CCache/ccache_swig_config.h
|
||||
CCache/config.h
|
||||
CCache/config.log
|
||||
CCache/config.status
|
||||
Examples/Makefile
|
||||
Examples/guile/Makefile
|
||||
Examples/test-suite/*/Makefile
|
||||
Examples/xml/Makefile
|
||||
Lib/ocaml/swigp4.ml
|
||||
/Makefile
|
||||
Source/Include/stamp-h1
|
||||
Source/Include/swigconfig.h
|
||||
Source/Makefile
|
||||
.deps
|
||||
config.log
|
||||
config.status
|
||||
preinst-swig
|
||||
swig.spec
|
||||
|
||||
# Build Artifacts
|
||||
.dirstamp
|
||||
CCache/ccache-swig
|
||||
Source/CParse/parser.c
|
||||
Source/CParse/parser.h
|
||||
Source/eswig
|
||||
swig
|
||||
|
||||
# Generated documentation
|
||||
Doc/Manual/CCache.html
|
||||
Doc/Manual/SWIGDocumentation.html
|
||||
Doc/Manual/SWIGDocumentation.pdf
|
||||
Doc/Manual/*.book
|
||||
|
||||
# Test Suite Generated Files
|
||||
Examples/test-suite/allegrocl/*/
|
||||
Examples/test-suite/cffi/*/
|
||||
Examples/test-suite/chicken/*/
|
||||
Examples/test-suite/clisp/*/
|
||||
Examples/test-suite/csharp/*/
|
||||
Examples/test-suite/d/*/
|
||||
Examples/test-suite/go/*/
|
||||
Examples/test-suite/guile/*/
|
||||
Examples/test-suite/guilescm/*/
|
||||
Examples/test-suite/java/*/
|
||||
Examples/test-suite/lua/*/
|
||||
Examples/test-suite/mzscheme/*/
|
||||
Examples/test-suite/ocaml/*/
|
||||
Examples/test-suite/octave/*/
|
||||
Examples/test-suite/perl5/*/
|
||||
Examples/test-suite/php/*/
|
||||
Examples/test-suite/pike/*/
|
||||
Examples/test-suite/python/*/
|
||||
Examples/test-suite/r/*/
|
||||
Examples/test-suite/ruby/*/
|
||||
Examples/test-suite/tcl/*/
|
||||
Examples/test-suite/uffi/*/
|
||||
|
||||
# Python generated files, based on:
|
||||
# https://github.com/github/gitignore/blob/master/Python.gitignore
|
||||
*.py[cod]
|
||||
*/__pycache__/
|
||||
/__pycache__/
|
||||
|
||||
# C# generated files
|
||||
*_runme.exe.mdb
|
||||
*_runme.exe
|
||||
|
||||
11
.project
11
.project
|
|
@ -1,11 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<projectDescription>
|
||||
<name>SWIG</name>
|
||||
<comment></comment>
|
||||
<projects>
|
||||
</projects>
|
||||
<buildSpec>
|
||||
</buildSpec>
|
||||
<natures>
|
||||
</natures>
|
||||
</projectDescription>
|
||||
22
ANNOUNCE
22
ANNOUNCE
|
|
@ -1,31 +1,31 @@
|
|||
*** ANNOUNCE: SWIG 2.0.1 (in progress) ***
|
||||
*** ANNOUNCE: SWIG 2.0.10 (in progress) ***
|
||||
|
||||
http://www.swig.org
|
||||
|
||||
We're pleased to announce SWIG-2.0.1, the latest SWIG release.
|
||||
We're pleased to announce SWIG-2.0.10, the latest SWIG release.
|
||||
|
||||
What is SWIG?
|
||||
=============
|
||||
|
||||
SWIG is a software development tool that reads C/C++ header files and
|
||||
generates the wrapper code needed to make C and C++ code accessible
|
||||
from other languages including Perl, Python, Tcl, Ruby, PHP, Java,
|
||||
Scheme (Guile, MzScheme, CHICKEN), Ocaml, Lua, Pike, C#, Modula-3, Octave, R,
|
||||
Common Lisp (CLISP, Allegro CL, CFFI, UFFI). SWIG can also export its parse
|
||||
tree in the form of XML and Lisp s-expressions. Major applications of
|
||||
SWIG include generation of scripting language extension modules, rapid
|
||||
prototyping, testing, and user interface development for large C/C++
|
||||
systems.
|
||||
from other programming languages including Perl, Python, Tcl, Ruby,
|
||||
PHP, C#, Go, Java, Lua, Scheme (Guile, MzScheme, CHICKEN), D, Ocaml,
|
||||
Pike, Modula-3, Octave, R, Common Lisp (CLISP, Allegro CL, CFFI, UFFI).
|
||||
SWIG can also export its parse tree in the form of XML and Lisp
|
||||
s-expressions. Major applications of SWIG include generation of
|
||||
scripting language extension modules, rapid prototyping, testing,
|
||||
and user interface development for large C/C++ systems.
|
||||
|
||||
Availability
|
||||
============
|
||||
The release is available for download on Sourceforge at
|
||||
|
||||
http://prdownloads.sourceforge.net/swig/swig-2.0.1.tar.gz
|
||||
http://prdownloads.sourceforge.net/swig/swig-2.0.10.tar.gz
|
||||
|
||||
A Windows version is also available at
|
||||
|
||||
http://prdownloads.sourceforge.net/swig/swigwin-2.0.1.zip
|
||||
http://prdownloads.sourceforge.net/swig/swigwin-2.0.10.zip
|
||||
|
||||
Please report problems with this release to the swig-devel mailing list,
|
||||
details at http://www.swig.org/mail.html.
|
||||
|
|
|
|||
|
|
@ -712,12 +712,13 @@ static void from_cache(int first)
|
|||
passfail = retrieve_from_cache(hashname, output_file, hardlink);
|
||||
}
|
||||
|
||||
free(stderr_file);
|
||||
if (passfail == -1) {
|
||||
close(fd_stderr);
|
||||
unlink(stderr_file);
|
||||
free(stderr_file);
|
||||
return;
|
||||
}
|
||||
free(stderr_file);
|
||||
}
|
||||
|
||||
/* get rid of the intermediate preprocessor file */
|
||||
|
|
|
|||
|
|
@ -1,27 +1,53 @@
|
|||
This file contains the changes for the current release.
|
||||
Below are the changes for the current release.
|
||||
See the CHANGES file for changes in older releases.
|
||||
See the RELEASENOTES file for a summary of changes in each release.
|
||||
|
||||
Version 2.0.1 (in progress)
|
||||
===========================
|
||||
Version 2.0.10 (in progress)
|
||||
============================
|
||||
|
||||
2010-07-16: wsfulton
|
||||
Fix wrapping of function pointers and member function pointers when the function
|
||||
returns by reference.
|
||||
2013-01-18: Brant Kyser
|
||||
[Java] Patch #15 - Allow the use of the nspace feature without the -package commandline option.
|
||||
This works as long and the new jniclasspackage pragma is used to place the JNI intermediate class
|
||||
into a package and the nspace feature is used to place all exposed types into a package.
|
||||
|
||||
2010-07-08: wsfulton
|
||||
Fix #3024875 - shared_ptr of classes with non-public destructors. This also fixes
|
||||
the "unref" feature when used on classes with non-public destructors.
|
||||
2013-01-15: wsfulton
|
||||
Fix Visual Studio examples to work when SWIG is unzipped into a directory containing spaces.
|
||||
|
||||
2010-06-10: wsfulton
|
||||
[Lua] Fix SWIG_lua_isnilstring multiply defined when using multiple
|
||||
modules and wrapping strings. Patch from 'Number Cruncher'.
|
||||
2013-01-15: wsfulton
|
||||
[C#] Fix cstype typemap lookup for member variables so that a fully qualified variable name
|
||||
matches. For example:
|
||||
%typemap(cstype) bool MVar::mvar "MyBool"
|
||||
struct MVar {
|
||||
bool mvar;
|
||||
};
|
||||
|
||||
2010-06-10: olly
|
||||
[PHP] Fix directors to correctly call a method with has a
|
||||
different name in PHP to C++ (we were always using the C++ name
|
||||
in this case).
|
||||
2013-01-11: Brant Kyser
|
||||
[Java, C#, D] SF Bug #1299 - Fix generated names for when %nspace is used on
|
||||
classes with the same name in two different namespaces.
|
||||
|
||||
2013-01-11: Vladimir Kalinin
|
||||
[C#] Add support for csdirectorin 'pre', 'post' and 'terminator' attributes.
|
||||
|
||||
2013-01-08: olly
|
||||
[PHP] Fix to work with a ZTS build of PHP (broken in 2.0.7).
|
||||
|
||||
2013-01-07: olly
|
||||
Fix bashism in configure, introduced in 2.0.9.
|
||||
|
||||
2013-01-06: wsfulton
|
||||
Pull patch #4 from ptomulik to fix SF Bug #1296 - Fix incorrect warning for virtual destructors
|
||||
in templates, such as:
|
||||
Warning 521: Illegal destructor name B< A >::~B(). Ignored.
|
||||
|
||||
2013-01-05: wsfulton
|
||||
[Python] Pull patch #3 from ptomulik to fix SF Bug #1295 - standard exceptions as
|
||||
classes using the SWIG_STD_EXCEPTIONS_AS_CLASSES macro.
|
||||
|
||||
2013-01-04: wsfulton
|
||||
[Java] Pull patch #2 from BrantKyser to fix SF Bug #1283 - fix smart pointers in conjuction
|
||||
with directors.
|
||||
|
||||
2013-01-03: wsfulton
|
||||
[Java] Pull patch #1 from BrantKyser to fix SF Bug #1278 - fix directors and nspace feature when
|
||||
multilevel namespaces are used.
|
||||
|
||||
2010-06-03: wsfulton
|
||||
Fix uncompileable code when %rename results in two enum items
|
||||
with the same name. Reported by Vadim Zeitlin.
|
||||
|
|
|
|||
15
COPYRIGHT
15
COPYRIGHT
|
|
@ -1,7 +1,7 @@
|
|||
SWIG Copyright and Authors
|
||||
--------------------------
|
||||
|
||||
Copyright (c) 1995-2010 The SWIG Developers
|
||||
Copyright (c) 1995-2011 The SWIG Developers
|
||||
Copyright (c) 2005-2006 Arizona Board of Regents (University of Arizona).
|
||||
Copyright (c) 1998-2005 University of Chicago.
|
||||
Copyright (c) 1995-1998 The University of Utah and the Regents of the University of California
|
||||
|
|
@ -15,6 +15,7 @@ Active SWIG Developers:
|
|||
Olly Betts (olly@survex.com) (PHP)
|
||||
Joseph Wang (joequant@gmail.com) (R)
|
||||
Xavier Delacour (xavier.delacour@gmail.com) (Octave)
|
||||
David Nadlinger (code@klickverbot.at) (D)
|
||||
|
||||
Past SWIG developers and major contributors include:
|
||||
Dave Beazley (dave-swig@dabeaz.com) (SWIG core, Python, Tcl, Perl)
|
||||
|
|
@ -42,7 +43,7 @@ Past SWIG developers and major contributors include:
|
|||
Tiger Feng (songyanf@cs.uchicago.edu) (SWIG core)
|
||||
Mark Rose (mrose@stm.lbl.gov) (Directors)
|
||||
Jonah Beckford (beckford@usermail.com) (CHICKEN)
|
||||
Ahmon Dancy (dancy@franz.com) (Allegro CL)
|
||||
Ahmon Dancy (dancy@franz.com) (Allegro CL)
|
||||
Dirk Gerrits (Allegro CL)
|
||||
Neil Cawse (C#)
|
||||
Harco de Hilster (Java)
|
||||
|
|
@ -53,19 +54,23 @@ Past SWIG developers and major contributors include:
|
|||
Duncan Temple Lang (R)
|
||||
Miklos Vajna <vmiklos@frugalware.org> (PHP directors)
|
||||
Mark Gossage (mark@gossage.cjb.net) (Lua)
|
||||
Raman Gopalan (ramangopalan@gmail.com) (eLua)
|
||||
Gonzalo Garramuno (ggarra@advancedsl.com.ar) (Ruby, Ruby's UTL)
|
||||
John Lenz (Guile, MzScheme updates, Chicken module, runtime system)
|
||||
Ian Lance Taylor (Go)
|
||||
Vadim Zeitlin (PCRE)
|
||||
Stefan Zager (szager@gmail.com) (Python)
|
||||
|
||||
Past contributors include:
|
||||
James Michael DuPont, Clark McGrew, Dustin Mitchell, Ian Cooke, Catalin Dumitrescu, Baran
|
||||
Kovuk, Oleg Tolmatcev, Tal Shalif, Lluis Padro, Chris Seatory, Igor Bely, Robin Dunn,
|
||||
Edward Zimmermann, David Ascher, Dominique Dumont, Pier Giorgio Esposito, Hasan Baran Kovuk,
|
||||
Klaus Wiederänders
|
||||
Klaus Wiederänders, Richard Beare, Hans Oesterholt.
|
||||
(See CHANGES and CHANGES.current and the bug tracker for a more complete list).
|
||||
|
||||
Past students:
|
||||
Songyan Feng (Chicago).
|
||||
Xinghua Shi (Chicago).
|
||||
Xinghua Shi (Chicago).
|
||||
Jing Cao (Chicago).
|
||||
Aquinas Hobor (Chicago).
|
||||
|
||||
|
|
@ -95,5 +100,5 @@ Mike Weiblen, Paul Brannan, Ram Bhamidipaty, Reinhard Fobbe, Rich Wales,
|
|||
Richard Salz, Roy Lecates, Rudy Albachten, Scott Drummonds
|
||||
Scott Michel, Shaun Lowry, Steve Galser, Tarn Weisner Burton,
|
||||
Thomas Weidner, Tony Seward, Uwe Steinmann, Vadim Chugunov, Wyss Clemens,
|
||||
Zhong Ren.
|
||||
Zhong Ren.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
<li><a name="i8" href="#8">8. Naming Conventions</a>
|
||||
<li><a name="i9" href="#9">9. Visibility</a>
|
||||
<li><a name="i10" href="#10">10. Miscellaneous Coding Guidelines</a>
|
||||
<li><a name="i11" href="#11">11. SVN Tagging Conventions</a>
|
||||
<li><a name="i11" href="#11">11. Git Tagging Conventions</a>
|
||||
</ul>
|
||||
|
||||
<a name="1" href="#i1">
|
||||
|
|
@ -119,8 +119,8 @@ are case-insensitive on Windows so this convention will prevent you from inadver
|
|||
creating two files that differ in case-only.
|
||||
|
||||
<p>
|
||||
Each file should include a short abstract, license information and
|
||||
a SVN revision tag like this:
|
||||
Each file should include a short abstract and license information
|
||||
like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
|
|
@ -137,8 +137,6 @@ a SVN revision tag like this:
|
|||
* This file defines ...
|
||||
* ----------------------------------------------------------------------------- */
|
||||
|
||||
static char cvs[] = "$Id$ xxx.c";
|
||||
|
||||
#include "swig.h"
|
||||
|
||||
/* Declarations */
|
||||
|
|
@ -159,12 +157,6 @@ static int avariable;
|
|||
</pre>
|
||||
</blockquote>
|
||||
|
||||
The SVN revision tag should be placed into a static string as shown
|
||||
above mangled with the name of the file.
|
||||
This adds the revision information to the SWIG executable and
|
||||
makes it possible to extract version information from a raw binary
|
||||
(sometimes useful in debugging).
|
||||
|
||||
<p>
|
||||
As a general rule, files start to get unmanageable once they exceed
|
||||
about 2000 lines. Files larger than this should be broken up into
|
||||
|
|
@ -379,10 +371,10 @@ making your changes.
|
|||
These are largely covered in the main documentation in the Extending.html file.
|
||||
|
||||
<a name="11" href="#i11">
|
||||
<h2>11. SVN Tagging Conventions</h2>
|
||||
<h2>11. Git Tagging Conventions</h2>
|
||||
</a>
|
||||
|
||||
Use <tt>svn tag</tt> to declare some set of file revisions as related in some
|
||||
Use <tt>git tag</tt> to declare some set of file revisions as related in some
|
||||
symbolic way. This eases reference, retrieval and manipulation of these files
|
||||
later. At the moment (2001/01/16 14:02:53), the conventions are very simple;
|
||||
let's hope they stay that way!
|
||||
|
|
@ -390,10 +382,10 @@ let's hope they stay that way!
|
|||
<p>
|
||||
There are two types of tags, internal (aka personal) and external.
|
||||
Internal tags are used by SWIG developers primarily, whereas external
|
||||
tags are used when communicating with people w/ anonymous svn access.
|
||||
tags are used when communicating with people w/ anonymous git access.
|
||||
<ul>
|
||||
<li> Internal tags should start with the developer name and a hyphen.
|
||||
<li> External tags should start with "v-".
|
||||
<li> External tags should start with "rel-".
|
||||
</ul>
|
||||
|
||||
That's all there is to it. Some example tags:
|
||||
|
|
@ -402,10 +394,8 @@ That's all there is to it. Some example tags:
|
|||
<li> ttn-pre-xml-patch
|
||||
<li> ttn-post-xml-patch
|
||||
<li> ttn-going-on-vacation-so-dutifully-tagging-now
|
||||
<li> v-1-3-a37-fixes-bug-2432
|
||||
<li> v-1-3-a37-fixes-bug-2433
|
||||
<li> v-1-3-a37-fixes-bug-2432-again
|
||||
<li> v-1-3-a37-release
|
||||
<li> rel-1.3.40
|
||||
<li> rel-2.0.9
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ The following documentation describe the internal APIs used by SWIG. These may
|
|||
<li><a href="parm.html">Parameter and Parameter list handling functions</a>
|
||||
<li><a href="scanner.html">Generic C/C++ Scanner interface</a>
|
||||
<li><a href="wrapobj.html">Wrapper objects</a>.
|
||||
<li><a href="runtime.txt">SWIG Runtime</a>.
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
|
|
|||
|
|
@ -7,11 +7,6 @@
|
|||
<center>
|
||||
<h1>SWIG Internals Manual</h1>
|
||||
|
||||
<b>Thien-Thi Nguyen <br>
|
||||
|
||||
<p>
|
||||
David M. Beazley <br>
|
||||
|
||||
</b>
|
||||
</center>
|
||||
|
||||
|
|
@ -45,6 +40,10 @@ David M. Beazley <br>
|
|||
<li><a name="i5" href="#5">5. C/C++ Wrapper Support Functions</a>
|
||||
<li><a name="i6" href="#6">6. Symbol Naming Guidelines for Generated C/C++ Code</a>
|
||||
<li><a name="i7" href="#7">7. Debugging SWIG</a>
|
||||
<ul>
|
||||
<li><a name="i7.1" href="#7.1">7.1 Debugging DOH Types The Hard Way</a>
|
||||
<li><a name="i7.2" href="#7.2">7.2 Debugging DOH memory allocation problems</a>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
<a name="1" href="#i1">
|
||||
|
|
@ -1015,15 +1014,139 @@ In the past SWIG has generated many symbols which flout the standard especially
|
|||
<a name="7" href="#i7">
|
||||
<h2>7. Debugging SWIG</h2>
|
||||
</a>
|
||||
Warning. Debugging SWIG is for the very patient.
|
||||
|
||||
<p>
|
||||
The DOH types used in the SWIG source code are all typedefined to void.
|
||||
Consequently, it is impossible for debuggers to automatically extract any information about DOH objects.
|
||||
The easiest approach to debugging and viewing the contents of DOH objects is to make a call into one of the family of SWIG print functions from the debugger.
|
||||
The "Debugging Functions" section in <a href="tree.html">SWIG Parse Tree Handling</a> lists them.
|
||||
It is sometimes easier to debug by placing a few calls to these functions in code of interest and recompile, especially if your debugger cannot easily make calls into functions within a debugged binary.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The SWIG distribution comes with some additional support for the gdb debugger in the <tt>Tools/swig.gdb</tt> file.
|
||||
Follow the instructions in this file for 'installing'.
|
||||
This support file provides an easy way to call into some of the family of SWIG print functions via additional user-defined gdb commands.
|
||||
Some usage of the <tt>swigprint</tt> and <tt>locswigprint</tt> user-defined commands are demonstrated below.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
More often than not, a parse tree node needs to be examined.
|
||||
The session below displays the node <tt>n</tt> in one of the Java language module wrapper functions.
|
||||
The <tt>swigprint</tt> method is used to show the symbol name (<tt>symname</tt> - a DOH String type) and the node (<tt>n</tt> - a DOH Hash type).
|
||||
</p>
|
||||
<blockquote>
|
||||
<pre>
|
||||
Breakpoint 1, JAVA::functionWrapper (this=0x97ea5f0, n=0xb7d2afc8) at Modules/java.cxx:799
|
||||
799 String *symname = Getattr(n, "sym:name");
|
||||
(gdb) next
|
||||
800 SwigType *t = Getattr(n, "type");
|
||||
(gdb) swigprint symname
|
||||
Shape_x_set
|
||||
(gdb) swigprint n
|
||||
Hash(0xb7d2afc8) {
|
||||
'membervariableHandler:view' : variableHandler,
|
||||
'feature:except' : 0,
|
||||
'name' : x,
|
||||
'ismember' : 1,
|
||||
'sym:symtab' : Hash(0xb7d2aca8) {......},
|
||||
'nodeType' : cdecl,
|
||||
'nextSibling' : Hash(0xb7d2af98) {.............},
|
||||
'kind' : variable,
|
||||
'variableHandler:feature:immutable' : <Object 'VoidObj' at 0xb7cfa008>,
|
||||
'sym:name' : Shape_x_set,
|
||||
'view' : membervariableHandler,
|
||||
'membervariableHandler:sym:name' : x,
|
||||
'membervariableHandler:type' : double,
|
||||
'membervariableHandler:parms' : <Object 'VoidObj' at 0xb7cfa008>,
|
||||
'parentNode' : Hash(0xb7d2abc8) {..............................},
|
||||
'feature:java:enum' : typesafe,
|
||||
'access' : public,
|
||||
'parms' : Hash(0xb7cb9408) {......},
|
||||
'wrap:action' : if (arg1) (arg1)->x = arg2;,
|
||||
'type' : void,
|
||||
'memberset' : 1,
|
||||
'sym:overname' : __SWIG_0,
|
||||
'membervariableHandler:name' : x,
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
Note that all the attributes in the Hash are shown, including the 'sym:name' attribute which was assigned to the <tt>symname</tt> variable.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Hash types can be shown either expanded or collapsed.
|
||||
When a Hash is shown expanded, all the attributes are displayed along with their values, otherwise a '.' replaces each attribute when collapsed.
|
||||
Therefore a count of the dots provides the number of attributes within an unexpanded Hash.
|
||||
Below shows the 'parms' Hash being displayed with the default Hash expansion of 1, then with 2 provided as the second argument to <tt>swigprint</tt> to expand to two Hash levels in order to view the contents of the collapsed 'nextSibling' Hash.
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
(gdb) swigprint 0xb7cb9408
|
||||
Hash(0xb7cb9408) {
|
||||
'name' : self,
|
||||
'type' : p.Shape,
|
||||
'self' : 1,
|
||||
'nextSibling' : Hash(0xb7cb9498) {...},
|
||||
'hidden' : 1,
|
||||
'nodeType' : parm,
|
||||
}
|
||||
(gdb) swigprint 0xb7cb9408 2
|
||||
Hash(0xb7cb9408) {
|
||||
'name' : self,
|
||||
'type' : p.Shape,
|
||||
'self' : 1,
|
||||
'nextSibling' : Hash(0xb7cb9498) {
|
||||
'name' : x,
|
||||
'type' : double,
|
||||
'nodeType' : parm,
|
||||
},
|
||||
'hidden' : 1,
|
||||
'nodeType' : parm,
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
The same Hash can also be displayed with file and line location information via the <tt>locswigprint</tt> command.
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
(gdb) locswigprint 0xb7cb9408
|
||||
example.h:11: [Hash(0xb7cb9408) {
|
||||
Hash(0xb7cb9408) {
|
||||
'name' : self,
|
||||
'type' : p.Shape,
|
||||
'self' : 1,
|
||||
'nextSibling' : Hash(0xb7cb9498) {...},
|
||||
'hidden' : 1,
|
||||
'nodeType' : parm,
|
||||
}]
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
<b>Tip</b>: Commands in gdb can be shortened with whatever makes them unique and can be command completed with the tab key.
|
||||
Thus <tt>swigprint</tt> can usually be shortened to <tt>sw</tt> and <tt>locswigprint</tt> to <tt>loc</tt>.
|
||||
The help for each command can also be obtained within the debugging session, for example, 'help swigprint'.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The sub-section below gives pointers for debugging DOH objects using casts and provides an insight into why it can be hard to debug SWIG without the family of print functions.
|
||||
<p>
|
||||
|
||||
The DOH types are all typedefined to void.
|
||||
Consequently, it is impossible for debuggers to extract any information about DOH objects.
|
||||
Most debuggers will be able to display useful variable information when an object is cast to the appropriate type.
|
||||
Below are some tips for displaying some of the DOH objects.
|
||||
Be sure to compile with compiler optimisations turned off before attempting the casts shown in a debugger window else they are unlikely to work.
|
||||
Even displaying the underlying string in a String* doesn't work straight off in all debuggers due to the multiple definition of String as a struct and a void.
|
||||
<a name="7.1" href="#i7.1">
|
||||
<h3>7.1 Debugging DOH Types The Hard Way</h3>
|
||||
</a>
|
||||
The DOH types used in SWIG are all typedefined to void and hence the lack of type information for inspecting types within a debugger.
|
||||
Most debuggers will however be able to display useful variable information when an object is cast to the appropriate type.
|
||||
Getting at the underlying C string within DOH types is cumbersome, but possible with appropriate casts.
|
||||
The casts below can be used in a debugger windows, but be sure to compile with compiler optimisations turned off before attempting the casts else they are unlikely to work.
|
||||
Even displaying the underlying string in a String * doesn't work straight off in all debuggers due to the multiple definitions of String as a struct and a void.
|
||||
<p>
|
||||
|
||||
Below are a list of common SWIG types.
|
||||
|
|
@ -1033,34 +1156,56 @@ With each is the cast that can be used in the debugger to extract the underlying
|
|||
|
||||
<p>
|
||||
<li>String *s;</li>
|
||||
<br>
|
||||
(struct String *)((DohBase *)s)->data
|
||||
<tt>(struct String *)((DohBase *)s)->data</tt>
|
||||
<br>
|
||||
The underlying char * string can be displayed with
|
||||
<br>
|
||||
(*(struct String *)(((DohBase *)s)->data)).str
|
||||
<tt>(*(struct String *)(((DohBase *)s)->data)).str</tt>
|
||||
|
||||
<p>
|
||||
<li>SwigType *t;</li>
|
||||
<br>
|
||||
(struct String *)((DohBase *)t)->data
|
||||
<tt>(struct String *)((DohBase *)t)->data</tt>
|
||||
<br>
|
||||
The underlying char * string can be displayed with
|
||||
<br>
|
||||
(*(struct String *)(((DohBase *)t)->data)).str
|
||||
<tt>(*(struct String *)(((DohBase *)t)->data)).str</tt>
|
||||
|
||||
<p>
|
||||
<li>const_String_or_char_ptr sc;</li>
|
||||
Either <br>
|
||||
(*(struct String *)(((DohBase *)sc)->data)).str
|
||||
<tt>(*(struct String *)(((DohBase *)sc)->data)).str</tt>
|
||||
<br> or <br>
|
||||
(char *)sc
|
||||
<tt>(char *)sc</tt>
|
||||
<br> will work depending on whether the underlying type is really a String * or char *.
|
||||
|
||||
</ul>
|
||||
|
||||
<a name="7.2" href="#i7.2">
|
||||
<h3>7.2 Debugging DOH memory allocation problems</h3>
|
||||
</a>
|
||||
|
||||
<p>
|
||||
Please also read the Debugging Functions section in <a href="tree.html">SWIG Parse Tree Handling</a> for the <tt>Swig_print_node()</tt>, <tt>Swig_print_tree()</tt> and <tt>Swig_print_tags()</tt> functions for displaying node contents. It is often easier to place a few calls to these functions in code of interest and recompile than use the debugger.
|
||||
The DOH objects are reference counted and use pools for memory allocation.
|
||||
The implementation is in <tt>memory.c</tt>. When there are memory corruption problems,
|
||||
various memory allocator tools are normally used to diagnose problems. These can be used
|
||||
on SWIG and can be very useful. However, they won't necessarily find use of stale DOH objects,
|
||||
that is, DOH objects
|
||||
that are used after they have been deleted. This is because the DOH memory allocator
|
||||
grabs a chunk of memory from the C memory allocator and manages the usage internally.
|
||||
Stale DOH object usage can be checked for by defining <tt>DOH_DEBUG_MEMORY_POOLS</tt> in
|
||||
<tt>memory.c</tt>. If an attempt to use an object is made after the reference count is
|
||||
zero, an assertion is triggered instead of quietly re-using the stale object...
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
swig: DOH/memory.c:91: DohCheck: Assertion `!DOH_object_already_deleted' failed.
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
This can be memory intensive as previously used memory in the pool is not re-used so is
|
||||
only recommended for diagnosing memory corruption problems.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
|
|
|||
|
|
@ -6,13 +6,6 @@
|
|||
<body>
|
||||
<center>
|
||||
<h1>SWIG Parse Tree Handling</h1>
|
||||
|
||||
<p>
|
||||
David M. Beazley <br>
|
||||
dave-swig@dabeaz.com<br>
|
||||
December, 2006<br>
|
||||
|
||||
</b>
|
||||
</center>
|
||||
|
||||
<h2>Introduction</h2>
|
||||
|
|
@ -210,7 +203,33 @@ This function restores a node to the state it was in prior to the last <tt>Swig_
|
|||
|
||||
<h2>Debugging Functions</h2>
|
||||
|
||||
The following functions are used to help debug SWIG parse trees.
|
||||
<p>
|
||||
The following functions can be used to help debug any SWIG DOH object.
|
||||
</p>
|
||||
|
||||
<b><tt>void Swig_print(DOH *object, int count = -1)</tt></b>
|
||||
|
||||
<blockquote>
|
||||
Prints to stdout a string representation of any DOH type.
|
||||
The number of nested Hash types to expand is set by count (default is 1 if count<0). See Swig_set_max_hash_expand() to change default.
|
||||
<pre>
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<b><tt>void Swig_print_with_location(DOH *object, int count = -1)</tt></b>
|
||||
|
||||
<blockquote>
|
||||
Prints to stdout a string representation of any DOH type, within [] brackets
|
||||
for Hash and List types, prefixed by line and file information.
|
||||
The number of nested Hash types to expand is set by count (default is 1 if count<0). See Swig_set_max_hash_expand() to change default.
|
||||
<pre>
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
|
||||
<p>
|
||||
The following functions can be used to help debug SWIG parse trees.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b><tt>void Swig_print_tags(Node *node, String_or_char *prefix)</tt></b>
|
||||
|
|
|
|||
|
|
@ -1118,7 +1118,7 @@ namespace BAR {
|
|||
function that returns an object (or pointer/reference) of C/C++
|
||||
type <tt>X</tt>, the wrapping defun (or defmethod) on the Lisp
|
||||
side will automatically wrap the pointer returned in an instance
|
||||
of the apropriate class. This makes it much easier to write and
|
||||
of the appropriate class. This makes it much easier to write and
|
||||
debug code than if pointers were passed around as a jumble of
|
||||
integer values.
|
||||
</p>
|
||||
|
|
|
|||
781
Doc/Manual/Android.html
Normal file
781
Doc/Manual/Android.html
Normal file
|
|
@ -0,0 +1,781 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG and Android</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Android"></a>18 SWIG and Android</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#Android_overview">Overview</a>
|
||||
<li><a href="#Android_examples">Android examples</a>
|
||||
<ul>
|
||||
<li><a href="#Android_examples_intro">Examples introduction</a>
|
||||
<li><a href="#Android_example_simple">Simple C example</a>
|
||||
<li><a href="#Android_example_class">C++ class example</a>
|
||||
<li><a href="#Android_examples_other">Other examples</a>
|
||||
</ul>
|
||||
<li><a href="#Android_stl">C++ STL</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
|
||||
|
||||
<p>
|
||||
This chapter describes SWIG's support of Android.
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
<H2><a name="Android_overview"></a>18.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
The Android chapter is fairly short as support for Android is the same as for Java, where the Java Native Interface (JNI) is
|
||||
used to call from Android Java into C or C++ compiled code.
|
||||
Everything in the <a href="Java.html">Java chapter</a> applies to generating code for access from Android Java code.
|
||||
This chapter contains a few Android specific notes and examples.
|
||||
</p>
|
||||
|
||||
<H2><a name="Android_examples"></a>18.2 Android examples</H2>
|
||||
|
||||
|
||||
<H3><a name="Android_examples_intro"></a>18.2.1 Examples introduction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The examples require the <a href="http://developer.android.com/sdk/index.html">Android SDK</a> and <a href="http://developer.android.com/sdk/ndk/index.html">Android NDK</a> which can be installed as per instructions in the links.
|
||||
The Eclipse version is not required for these examples as just the command line tools are used (shown for Linux as the host, but Windows will be very similar, if not identical in most places).
|
||||
Add the SDK tools and NDK tools to your path and create a directory somewhere for your Android projects (adjust PATH as necessary to where you installed the tools):
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ export PATH=$HOME/android/android-sdk-linux_x86/tools:$HOME/android/android-sdk-linux_x86/platform-tools:$HOME/android/android-ndk-r6b:$PATH
|
||||
$ mkdir AndroidApps
|
||||
$ cd AnrdoidApps
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The examples use a target id of 1. This might need changing depending on your setup.
|
||||
After installation of the Android SDK, the available target ids can be viewed by running the command below.
|
||||
Please adjust the id to suit your target device.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ android list targets
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The following examples are shipped with SWIG under the Examples/android directory and include a Makefile to build and install each example.
|
||||
</p>
|
||||
|
||||
<H3><a name="Android_example_simple"></a>18.2.2 Simple C example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
This simple C example shows how to call a C function as well as read and modify a global variable.
|
||||
First we'll create and build a pure Java Android app. Afterwards the JNI code will be generated by SWIG and built into the app.
|
||||
First create and build an app called <tt>SwigSimple</tt> in a subdirectory called <tt>simple</tt> using the commands below.
|
||||
Adjust the <tt>--target</tt> id as mentioned earlier in the <a href="Android.html#Android_examples_intro">Examples introduction</a>.
|
||||
<a href="http://developer.android.com/guide/developing/projects/projects-cmdline.html">Managing Projects from the Command Line</a> on the Android developer's site is a useful reference for these steps.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ android create project --target 1 --name SwigSimple --path ./simple --activity SwigSimple --package org.swig.simple
|
||||
$ cd simple
|
||||
$ ant debug
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Modify <tt>src/org/swig/simple/SwigSimple.java</tt> from the default to:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
package org.swig.simple;
|
||||
|
||||
import android.app.Activity;
|
||||
import android.os.Bundle;
|
||||
import android.view.View;
|
||||
import android.widget.Button;
|
||||
import android.widget.TextView;
|
||||
import android.widget.ScrollView;
|
||||
import android.text.method.ScrollingMovementMethod;
|
||||
|
||||
public class SwigSimple extends Activity
|
||||
{
|
||||
TextView outputText = null;
|
||||
ScrollView scroller = null;
|
||||
|
||||
/** Called when the activity is first created. */
|
||||
@Override
|
||||
public void onCreate(Bundle savedInstanceState)
|
||||
{
|
||||
super.onCreate(savedInstanceState);
|
||||
setContentView(R.layout.main);
|
||||
|
||||
outputText = (TextView)findViewById(R.id.OutputText);
|
||||
outputText.setText("Press 'Run' to start...\n");
|
||||
outputText.setMovementMethod(new ScrollingMovementMethod());
|
||||
|
||||
scroller = (ScrollView)findViewById(R.id.Scroller);
|
||||
}
|
||||
|
||||
public void onRunButtonClick(View view)
|
||||
{
|
||||
outputText.append("Started...\n");
|
||||
nativeCall();
|
||||
outputText.append("Finished!\n");
|
||||
|
||||
// Ensure scroll to end of text
|
||||
scroller.post(new Runnable() {
|
||||
public void run() {
|
||||
scroller.fullScroll(ScrollView.FOCUS_DOWN);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// TODO
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The above simply adds a <i>Run</i> button and scrollable text view as the GUI aspects of the program.
|
||||
The associated resources need to be created, modify <tt>res/layout/main.xml</tt> as follows:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
android:orientation="vertical"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<Button
|
||||
android:id="@+id/RunButton"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
android:text="Run..."
|
||||
android:onClick="onRunButtonClick"
|
||||
/>
|
||||
<ScrollView
|
||||
android:id="@+id/Scroller"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<TextView
|
||||
android:id="@+id/OutputText"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
/>
|
||||
</ScrollView>
|
||||
</LinearLayout>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Rebuild the project with your changes:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ant debug
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Although there are no native function calls in the code, yet, you may want to check that this simple pure
|
||||
Java app runs before adding in the native calls.
|
||||
First, set up your Android device for hardware debugging, see <a href="http://developer.android.com/guide/developing/device.html">Using hardware devices</a> on the Android developer's site.
|
||||
When complete your device should be listed in those attached, something like:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ adb devices
|
||||
List of devices attached
|
||||
A32-6DBE0001-9FF80000-015D62C3-02018028 device
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
This means you are now ready to install the application...
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ adb install bin/SwigSimple-debug.apk
|
||||
95 KB/s (4834 bytes in 0.049s)
|
||||
pkg: /data/local/tmp/SwigSimple-debug.apk
|
||||
Success
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The newly installed 'SwigSimple' app will be amongst all your other applications on the home screen. Run the app and it will show a <i>Run</i> button text box below it.
|
||||
Press the <i>Run</i> button to see the simple text output.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The application can be uninstalled like any other application and in fact must be uninstalled before installing an updated version. Uninstalling is quite easy too from your host computer:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ adb uninstall org.swig.simple
|
||||
Success
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Now that you have a pure Java Android app working, let's add some JNI code generated from SWIG.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First create a <tt>jni</tt> subdirectory and then create some C source code in <tt>jni/example.c</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.c */
|
||||
|
||||
/* A global variable */
|
||||
double Foo = 3.0;
|
||||
|
||||
/* Compute the greatest common divisor of positive integers */
|
||||
int gcd(int x, int y) {
|
||||
int g;
|
||||
g = y;
|
||||
while (x > 0) {
|
||||
g = x;
|
||||
x = y % x;
|
||||
y = g;
|
||||
}
|
||||
return g;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Create a SWIG interface file for this C code, <tt>jni/example.i</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%inline %{
|
||||
extern int gcd(int x, int y);
|
||||
extern double Foo;
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Invoke SWIG as follows:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ swig -java -package org.swig.simple -outdir src/org/swig/simple -o jni/example_wrap.c jni/example.i
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
SWIG generates the following files:
|
||||
</p>
|
||||
<ul>
|
||||
<li><tt>src/org/swig/simple/exampleJNI.java</tt></li>
|
||||
<li><tt>src/org/swig/simple/example.java</tt></li>
|
||||
<li><tt>jni/example_wrap.c</tt></li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Next we need to create a standard Android NDK build system file <tt>jni/Android.mk</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.c example.c
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
See the <a href="http://developer.android.com/sdk/ndk/index.html">Android NDK documentation</a> for more on the NDK build system and getting started with the NDK.
|
||||
A simple invocation of ndk-build will compile the .c files and generate a shared object/system library. Output will be similar to:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ndk-build
|
||||
Compile thumb : example <= example_wrap.c
|
||||
Compile thumb : example <= example.c
|
||||
SharedLibrary : libexample.so
|
||||
Install : libexample.so => libs/armeabi/libexample.so
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Now that the C JNI layer has been built, we can write Java code to call into the this layer.
|
||||
Modify the <tt>nativeCall</tt> method in <tt>src/org/swig/simple/SwigSimple.java</tt> to call the JNI code as follows and add the static constructor to load the system library containing the compiled JNI C code:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// Call our gcd() function
|
||||
|
||||
int x = 42;
|
||||
int y = 105;
|
||||
int g = example.gcd(x,y);
|
||||
outputText.append("The greatest common divisor of " + x + " and " + y + " is " + g + "\n");
|
||||
|
||||
// Manipulate the Foo global variable
|
||||
|
||||
// Output its current value
|
||||
double foo = example.getFoo();
|
||||
outputText.append("Foo = " + foo + "\n");
|
||||
|
||||
// Change its value
|
||||
example.setFoo(3.1415926);
|
||||
|
||||
// See if the change took effect
|
||||
outputText.append("Foo = " + example.getFoo() + "\n");
|
||||
|
||||
// Restore value
|
||||
example.setFoo(foo);
|
||||
}
|
||||
|
||||
/** static constructor */
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Compile the Java code as usual, uninstall the old version of the app if still installed and re-install the new app:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ant debug
|
||||
$ adb uninstall org.swig.simple
|
||||
$ adb install bin/SwigSimple-debug.apk
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Run the app again and this time you will see the output pictured below, showing the result of calls into the C code:
|
||||
</p>
|
||||
|
||||
<center><img src="android-simple.png" alt="Android screenshot of SwigSimple example"></center>
|
||||
|
||||
|
||||
<H3><a name="Android_example_class"></a>18.2.3 C++ class example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The steps for calling C++ code are almost identical to those in the previous C code example.
|
||||
All the steps required to compile and use a simple hierarchy of classes for shapes are shown in this example.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First create an Android project called <tt>SwigClass</tt> in a subdirectory called <tt>class</tt>.
|
||||
The steps below create and build a the JNI C++ app.
|
||||
Adjust the <tt>--target</tt> id as mentioned earlier in the <a href="Android.html#Android_examples_intro">Examples introduction</a>.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ android create project --target 1 --name SwigClass --path ./class --activity SwigClass --package org.swig.classexample
|
||||
$ cd class
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Now create a <tt>jni</tt> subdirectory and then create a C++ header file <tt>jni/example.h</tt> which defines our
|
||||
hierarchy of shape classes:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.h */
|
||||
|
||||
class Shape {
|
||||
public:
|
||||
Shape() {
|
||||
nshapes++;
|
||||
}
|
||||
virtual ~Shape() {
|
||||
nshapes--;
|
||||
};
|
||||
double x, y;
|
||||
void move(double dx, double dy);
|
||||
virtual double area(void) = 0;
|
||||
virtual double perimeter(void) = 0;
|
||||
static int nshapes;
|
||||
};
|
||||
|
||||
class Circle : public Shape {
|
||||
private:
|
||||
double radius;
|
||||
public:
|
||||
Circle(double r) : radius(r) { };
|
||||
virtual double area(void);
|
||||
virtual double perimeter(void);
|
||||
};
|
||||
|
||||
class Square : public Shape {
|
||||
private:
|
||||
double width;
|
||||
public:
|
||||
Square(double w) : width(w) { };
|
||||
virtual double area(void);
|
||||
virtual double perimeter(void);
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
and create the implementation in the <tt>jni/example.cpp</tt> file:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.cpp */
|
||||
|
||||
#include "example.h"
|
||||
#define M_PI 3.14159265358979323846
|
||||
|
||||
/* Move the shape to a new location */
|
||||
void Shape::move(double dx, double dy) {
|
||||
x += dx;
|
||||
y += dy;
|
||||
}
|
||||
|
||||
int Shape::nshapes = 0;
|
||||
|
||||
double Circle::area(void) {
|
||||
return M_PI*radius*radius;
|
||||
}
|
||||
|
||||
double Circle::perimeter(void) {
|
||||
return 2*M_PI*radius;
|
||||
}
|
||||
|
||||
double Square::area(void) {
|
||||
return width*width;
|
||||
}
|
||||
|
||||
double Square::perimeter(void) {
|
||||
return 4*width;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Create a SWIG interface file for this C++ code in <tt>jni/example.i</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
|
||||
/* Let's just grab the original header file here */
|
||||
%include "example.h"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Invoke SWIG as follows, note that the -c++ option is required for C++ code:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ swig -c++ -java -package org.swig.classexample -outdir src/org/swig/classexample -o jni/example_wrap.cpp jni/example.i
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
SWIG generates the following files:
|
||||
</p>
|
||||
<ul>
|
||||
<li><tt>src/org/swig/classexample/Square.java</tt></li>
|
||||
<li><tt>src/org/swig/classexample/exampleJNI.java</tt></li>
|
||||
<li><tt>src/org/swig/classexample/example.java</tt></li>
|
||||
<li><tt>src/org/swig/classexample/Circle.java</tt></li>
|
||||
<li><tt>src/org/swig/classexample/Shape.java</tt></li>
|
||||
<li><tt>jni/example_wrap.cpp</tt></li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Next we need to create an Android NDK build system file for compiling the C++ code <tt>jni/Android.mk</tt>.
|
||||
The <tt>-frtti</tt> compiler flag isn't strictly needed for this example, but is needed for any code that uses C++ RTTI:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.cpp example.cpp
|
||||
LOCAL_CFLAGS := -frtti
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<p>
|
||||
A simple invocation of ndk-build will compile the .cpp files and generate a shared object/system library. Output will be similar to:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ndk-build
|
||||
Compile++ thumb : example <= example_wrap.cpp
|
||||
Compile++ thumb : example <= example.cpp
|
||||
StaticLibrary : libstdc++.a
|
||||
SharedLibrary : libexample.so
|
||||
Install : libexample.so => libs/armeabi/libexample.so
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Now that the C JNI layer has been built, we can write Java code to call into this layer.
|
||||
Modify <tt>src/org/swig/classexample/SwigClass.java</tt> from the default to:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
package org.swig.classexample;
|
||||
|
||||
import android.app.Activity;
|
||||
import android.os.Bundle;
|
||||
import android.view.View;
|
||||
import android.widget.Button;
|
||||
import android.widget.TextView;
|
||||
import android.widget.ScrollView;
|
||||
import android.text.method.ScrollingMovementMethod;
|
||||
|
||||
public class SwigClass extends Activity
|
||||
{
|
||||
TextView outputText = null;
|
||||
ScrollView scroller = null;
|
||||
|
||||
/** Called when the activity is first created. */
|
||||
@Override
|
||||
public void onCreate(Bundle savedInstanceState)
|
||||
{
|
||||
super.onCreate(savedInstanceState);
|
||||
setContentView(R.layout.main);
|
||||
|
||||
outputText = (TextView)findViewById(R.id.OutputText);
|
||||
outputText.setText("Press 'Run' to start...\n");
|
||||
outputText.setMovementMethod(new ScrollingMovementMethod());
|
||||
|
||||
scroller = (ScrollView)findViewById(R.id.Scroller);
|
||||
}
|
||||
|
||||
public void onRunButtonClick(View view)
|
||||
{
|
||||
outputText.append("Started...\n");
|
||||
nativeCall();
|
||||
outputText.append("Finished!\n");
|
||||
|
||||
// Ensure scroll to end of text
|
||||
scroller.post(new Runnable() {
|
||||
public void run() {
|
||||
scroller.fullScroll(ScrollView.FOCUS_DOWN);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// ----- Object creation -----
|
||||
|
||||
outputText.append( "Creating some objects:\n" );
|
||||
Circle c = new Circle(10);
|
||||
outputText.append( " Created circle " + c + "\n");
|
||||
Square s = new Square(10);
|
||||
outputText.append( " Created square " + s + "\n");
|
||||
|
||||
// ----- Access a static member -----
|
||||
|
||||
outputText.append( "\nA total of " + Shape.getNshapes() + " shapes were created\n" );
|
||||
|
||||
// ----- Member data access -----
|
||||
|
||||
// Notice how we can do this using functions specific to
|
||||
// the 'Circle' class.
|
||||
c.setX(20);
|
||||
c.setY(30);
|
||||
|
||||
// Now use the same functions in the base class
|
||||
Shape shape = s;
|
||||
shape.setX(-10);
|
||||
shape.setY(5);
|
||||
|
||||
outputText.append( "\nHere is their current position:\n" );
|
||||
outputText.append( " Circle = (" + c.getX() + " " + c.getY() + ")\n" );
|
||||
outputText.append( " Square = (" + s.getX() + " " + s.getY() + ")\n" );
|
||||
|
||||
// ----- Call some methods -----
|
||||
|
||||
outputText.append( "\nHere are some properties of the shapes:\n" );
|
||||
Shape[] shapes = {c,s};
|
||||
for (int i=0; i<shapes.length; i++)
|
||||
{
|
||||
outputText.append( " " + shapes[i].toString() + "\n" );
|
||||
outputText.append( " area = " + shapes[i].area() + "\n" );
|
||||
outputText.append( " perimeter = " + shapes[i].perimeter() + "\n" );
|
||||
}
|
||||
|
||||
// Notice how the area() and perimeter() functions really
|
||||
// invoke the appropriate virtual method on each object.
|
||||
|
||||
// ----- Delete everything -----
|
||||
|
||||
outputText.append( "\nGuess I'll clean up now\n" );
|
||||
|
||||
// Note: this invokes the virtual destructor
|
||||
// You could leave this to the garbage collector
|
||||
c.delete();
|
||||
s.delete();
|
||||
|
||||
outputText.append( Shape.getNshapes() + " shapes remain\n" );
|
||||
outputText.append( "Goodbye\n" );
|
||||
}
|
||||
|
||||
/** static constructor */
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Note the static constructor and the interesting JNI code is in the <tt>nativeCall</tt> method.
|
||||
The remaining code deals with the GUI aspects which are identical to the previous C simple example. Modify <tt>res/layout/main.xml</tt> to contain the xml for the 'Run' button and scrollable text view:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
android:orientation="vertical"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<Button
|
||||
android:id="@+id/RunButton"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
android:text="Run..."
|
||||
android:onClick="onRunButtonClick"
|
||||
/>
|
||||
<ScrollView
|
||||
android:id="@+id/Scroller"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<TextView
|
||||
android:id="@+id/OutputText"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
/>
|
||||
</ScrollView>
|
||||
</LinearLayout>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<p>
|
||||
Compile the Java code as usual, uninstall the old version of the app if installed and re-install the new app:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ant debug
|
||||
$ adb uninstall org.swig.classexample
|
||||
$ adb install bin/SwigClass-debug.apk
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Run the app to see the result of calling the C++ code from Java:
|
||||
</p>
|
||||
|
||||
<center><img src="android-class.png" alt="Android screenshot of SwigClass example"></center>
|
||||
|
||||
<H3><a name="Android_examples_other"></a>18.2.4 Other examples</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The Examples/android directory contains further examples which can be run and installed in a similar manner to the previous two examples.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that the 'extend' example is demonstrates the directors feature.
|
||||
Normally C++ exception handling and the STL is not available by default in the version of g++ shipped with Android, but this example turns these features on as described in the next section.
|
||||
</p>
|
||||
|
||||
<H2><a name="Android_stl"></a>18.3 C++ STL</H2>
|
||||
|
||||
|
||||
<p>
|
||||
Should the C++ Standard Template Library (STL) be required, an <tt>Application.mk</tt> file needs to be created
|
||||
in the same directory as the <tt>Android.mk</tt> directory containing information about the STL to use.
|
||||
See the NDK documentation in the $NDKROOT/docs folder especially CPLUSPLUS-SUPPORT.html.
|
||||
Below is an example of the <tt>Application.mk</tt> file to make the STLport static library available for use:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
# File: Application.mk
|
||||
APP_STL := gnustl_static
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
|
@ -5,12 +5,13 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="CSharp"></a>18 SWIG and C#</H1>
|
||||
<H1><a name="CSharp"></a>19 SWIG and C#</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#CSharp_introduction">Introduction</a>
|
||||
<li><a href="#CSharp_differences_java">Differences to the Java module</a>
|
||||
<li><a href="#CSharp_void_pointers">Void pointers</a>
|
||||
<li><a href="#CSharp_arrays">C# Arrays</a>
|
||||
<ul>
|
||||
<li><a href="#CSharp_arrays_swig_library">The SWIG C arrays library</a>
|
||||
|
|
@ -30,12 +31,14 @@
|
|||
<li><a href="#CSharp_directors_implementation">Directors implementation</a>
|
||||
<li><a href="#CSharp_director_caveats">Director caveats</a>
|
||||
</ul>
|
||||
<li><a href="#CSharp_multiple_modules">Multiples modules</a>
|
||||
<li><a href="#CSharp_typemap_examples">C# Typemap examples</a>
|
||||
<ul>
|
||||
<li><a href="#CSharp_memory_management_member_variables">Memory management when returning references to member variables</a>
|
||||
<li><a href="#CSharp_memory_management_objects">Memory management for objects passed to the C++ layer</a>
|
||||
<li><a href="#CSharp_date_marshalling">Date marshalling using the csin typemap and associated attributes</a>
|
||||
<li><a href="#CSharp_date_properties">A date example demonstrating marshalling of C# properties</a>
|
||||
<li><a href="#CSharp_date_pre_post_directors">Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a>
|
||||
<li><a href="#CSharp_partial_classes">Turning wrapped classes into partial classes</a>
|
||||
<li><a href="#CSharp_extending_proxy_class">Extending proxy classes with additional C# code</a>
|
||||
<li><a href="#CSharp_enum_underlying_type">Underlying type for enums</a>
|
||||
|
|
@ -46,7 +49,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="CSharp_introduction"></a>18.1 Introduction</H2>
|
||||
<H2><a name="CSharp_introduction"></a>19.1 Introduction</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -57,7 +60,7 @@ PInvoke is part of the ECMA/ISO C# specification.
|
|||
It is also better suited for robust production environments due to the Managed C++ flaw called the
|
||||
<a href="http://msdn.microsoft.com/en-us/library/aa290048(VS.71).aspx">Mixed DLL Loading Problem</a>.
|
||||
SWIG C# works equally well on non-Microsoft operating systems such as Linux, Solaris and Apple Mac using
|
||||
<a href="http://www.mono-project.com/">Mono</a> and <a href="http://www.dotgnu.org/pnet.html">Portable.NET</a>.
|
||||
<a href="http://www.mono-project.com/Main_Page">Mono</a> and <a href="http://www.dotgnu.org/pnet.html">Portable.NET</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -66,7 +69,7 @@ The <a href="http://msdn.microsoft.com">Microsoft Developer Network (MSDN)</a> h
|
|||
Monodoc, available from the Mono project, has a very useful section titled <a href="http://www.mono-project.com/Interop_with_Native_Libraries">Interop with native libraries</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_differences_java"></a>18.2 Differences to the Java module</H2>
|
||||
<H2><a name="CSharp_differences_java"></a>19.2 Differences to the Java module</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -169,6 +172,14 @@ javadestruct_derived -> csdestruct_derived
|
|||
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Typemap macros:</p>
|
||||
<div class="code"><pre>
|
||||
SWIG_JAVABODY_PROXY -> SWIG_CSBODY_PROXY
|
||||
SWIG_JAVABODY_TYPEWRAPPER -> SWIG_CSBODY_TYPEWRAPPER
|
||||
</pre></div>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Additional typemaps:</p>
|
||||
|
||||
|
|
@ -180,6 +191,20 @@ csattributes C# attributes for attaching to proxy classes/enums
|
|||
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Additional typemap attributes:</p>
|
||||
|
||||
<p>
|
||||
The "null" attribute in the "out" typemap can be specified to provide a value for <tt>$null</tt> to expand into for wrapped functions that return non-void. Normally the default value of <tt>0</tt> is used.
|
||||
For example this is needed if you change the return type to void:
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(ctype) Status "void"
|
||||
%typemap(out, null="") Status { ... }
|
||||
</pre></div>
|
||||
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Feature equivalent names:</p>
|
||||
<div class="code"><pre>
|
||||
|
|
@ -217,10 +242,12 @@ $jnicall -> $imcall
|
|||
<p>
|
||||
Unlike the "javain" typemap, the "csin" typemap does not support the 'pgcpp' attribute as the C# module does not have a premature garbage collection prevention parameter.
|
||||
The "csin" typemap supports additional optional attributes called 'cshin' and 'terminator'.
|
||||
The "csdirectorin" typemap supports additional optional attributes called 'terminator'.
|
||||
The 'cshin' attribute should contain the parameter type and name whenever a <a href="Java.html#Java_constructor_helper_function">constructor helper function</a> is generated due to the 'pre' or 'post' attributes.
|
||||
The 'terminator' attribute normally just contains a closing brace for when the 'pre' attribute contains an opening brace, such as when a C# <tt>using</tt> or <tt>fixed</tt> block is started.
|
||||
Note that 'pre', 'post', 'terminator' and 'cshin' attributes are not used for marshalling the property set.
|
||||
Please see the <a href="#CSharp_date_marshalling">Date marshalling example</a> and <a href="#CSharp_date_properties">Date marshalling of properties example</a> for further understanding of these "csin" applicable attributes.
|
||||
Please see the <a href="#CSharp_date_pre_post_directors">Date marshalling director example</a> for further understanding of the "csdirectorin" attributes.
|
||||
</p>
|
||||
</li>
|
||||
|
||||
|
|
@ -455,7 +482,25 @@ Windows users can also get the examples working using a
|
|||
<a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> environment for automatic configuration of the example makefiles.
|
||||
Any one of the three C# compilers (Portable.NET, Mono or Microsoft) can be detected from within a Cygwin or Mingw environment if installed in your path.
|
||||
|
||||
<H2><a name="CSharp_arrays"></a>18.3 C# Arrays</H2>
|
||||
<H2><a name="CSharp_void_pointers"></a>19.3 Void pointers</H2>
|
||||
|
||||
|
||||
<p>
|
||||
By default SWIG treats <tt>void *</tt> as any other pointer and hence marshalls it as a type wrapper class called <tt>SWIGTYPE_p_void</tt>.
|
||||
If you want to marshall with the .NET <tt>System.IntPtr</tt> type instead, there is a simple set of named typemaps called
|
||||
<tt>void *VOID_INT_PTR</tt> that can be used.
|
||||
They can be applied like any other named typemaps:
|
||||
</p>
|
||||
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%apply void *VOID_INT_PTR { void * }
|
||||
void * f(void *v);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="CSharp_arrays"></a>19.4 C# Arrays</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -467,7 +512,7 @@ with one of the following three approaches; namely the SWIG C arrays library, P/
|
|||
pinned arrays.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_arrays_swig_library"></a>18.3.1 The SWIG C arrays library</H3>
|
||||
<H3><a name="CSharp_arrays_swig_library"></a>19.4.1 The SWIG C arrays library</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -504,7 +549,7 @@ example.print_array(c.cast()); // Pass to C
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling"></a>18.3.2 Managed arrays using P/Invoke default array marshalling</H3>
|
||||
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling"></a>19.4.2 Managed arrays using P/Invoke default array marshalling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -575,7 +620,8 @@ marshalling for the arrays:
|
|||
<pre>
|
||||
[DllImport("example", EntryPoint="CSharp_myArrayCopy")]
|
||||
public static extern void myArrayCopy([In, MarshalAs(UnmanagedType.LPArray)]int[] jarg1,
|
||||
[Out, MarshalAs(UnmanagedType.LPArray)]int[] jarg2, int jarg3);
|
||||
[Out, MarshalAs(UnmanagedType.LPArray)]int[] jarg2,
|
||||
int jarg3);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -617,19 +663,20 @@ This results in the module class method
|
|||
</div>
|
||||
|
||||
<p>
|
||||
and intermediate class method
|
||||
and intermediary class method
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
[DllImport("example", EntryPoint="CSharp_myArraySwap")]
|
||||
public static extern void myArraySwap([In, Out, MarshalAs(UnmanagedType.LPArray)]int[] jarg1,
|
||||
[In, Out, MarshalAs(UnmanagedType.LPArray)]int[] jarg2, int jarg3);
|
||||
[In, Out, MarshalAs(UnmanagedType.LPArray)]int[] jarg2,
|
||||
int jarg3);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_arrays_pinning"></a>18.3.3 Managed arrays using pinning</H3>
|
||||
<H3><a name="CSharp_arrays_pinning"></a>19.4.3 Managed arrays using pinning</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -696,7 +743,8 @@ As a result, we get the following method in the module class:
|
|||
fixed ( int *swig_ptrTo_sourceArray = sourceArray ) {
|
||||
fixed ( int *swig_ptrTo_targetArray = targetArray ) {
|
||||
{
|
||||
examplePINVOKE.myArrayCopy((IntPtr)swig_ptrTo_sourceArray, (IntPtr)swig_ptrTo_targetArray, nitems);
|
||||
examplePINVOKE.myArrayCopy((IntPtr)swig_ptrTo_sourceArray, (IntPtr)swig_ptrTo_targetArray,
|
||||
nitems);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -710,7 +758,7 @@ marshalling is the "unsafe" quantifier, which is required because we are handlin
|
|||
</p>
|
||||
|
||||
<p>
|
||||
Also the intermediate class method looks a little different from the default marshalling
|
||||
Also the intermediary class method looks a little different from the default marshalling
|
||||
example - the method is expecting an IntPtr as the parameter type.
|
||||
</p>
|
||||
|
||||
|
|
@ -723,7 +771,7 @@ public static extern void myArrayCopy(IntPtr jarg1, IntPtr jarg2, int jarg3);
|
|||
|
||||
|
||||
|
||||
<H2><a name="CSharp_exceptions"></a>18.4 C# Exceptions</H2>
|
||||
<H2><a name="CSharp_exceptions"></a>19.5 C# Exceptions</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -820,7 +868,7 @@ set so should only be used when a C# exception is not created.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="CSharp_exception_example_check_typemap"></a>18.4.1 C# exception example using "check" typemap</H3>
|
||||
<H3><a name="CSharp_exception_example_check_typemap"></a>19.5.1 C# exception example using "check" typemap</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1002,7 +1050,7 @@ method and C# code does not handle pending exceptions via the canthrow attribute
|
|||
Actually it will issue this warning for any function beginning with <tt>SWIG_CSharpSetPendingException</tt>.
|
||||
</P>
|
||||
|
||||
<H3><a name="CSharp_exception_example_percent_exception"></a>18.4.2 C# exception example using %exception</H3>
|
||||
<H3><a name="CSharp_exception_example_percent_exception"></a>19.5.2 C# exception example using %exception</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1067,7 +1115,7 @@ The managed code generated does check for the pending exception as mentioned ear
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_exception_example_exception_specifications"></a>18.4.3 C# exception example using exception specifications</H3>
|
||||
<H3><a name="CSharp_exception_example_exception_specifications"></a>19.5.3 C# exception example using exception specifications</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1124,7 +1172,7 @@ SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
|
|||
Multiple catch handlers are generated should there be more than one exception specifications declared.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_custom_application_exception"></a>18.4.4 Custom C# ApplicationException example</H3>
|
||||
<H3><a name="CSharp_custom_application_exception"></a>19.5.4 Custom C# ApplicationException example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1258,7 +1306,7 @@ try {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="CSharp_directors"></a>18.5 C# Directors</H2>
|
||||
<H2><a name="CSharp_directors"></a>19.6 C# Directors</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1271,7 +1319,7 @@ The following sections provide information on the C# director implementation and
|
|||
However, the <a href="Java.html#Java_directors">Java directors</a> section should also be read in order to gain more insight into directors.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_directors_example"></a>18.5.1 Directors example</H3>
|
||||
<H3><a name="CSharp_directors_example"></a>19.6.1 Directors example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1392,7 +1440,7 @@ CSharpDerived - UIntMethod(123)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_directors_implementation"></a>18.5.2 Directors implementation</H3>
|
||||
<H3><a name="CSharp_directors_implementation"></a>19.6.2 Directors implementation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1578,7 +1626,7 @@ void SwigDirector_Base::BaseBoolMethod(Base const &b, bool flag) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_director_caveats"></a>18.5.3 Director caveats</H3>
|
||||
<H3><a name="CSharp_director_caveats"></a>19.6.3 Director caveats</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1626,7 +1674,42 @@ However, a call from C# to <tt>CSharpDefaults.DefaultMethod()</tt> will of cours
|
|||
should pass the call on to <tt>CSharpDefaults.DefaultMethod(int)</tt>using the C++ default value, as shown above.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_typemap_examples"></a>18.6 C# Typemap examples</H2>
|
||||
<H2><a name="CSharp_multiple_modules"></a>19.7 Multiples modules</H2>
|
||||
|
||||
|
||||
<p>
|
||||
When using <a href="Modules.html">multiple modules</a> it is is possible to compile each SWIG generated wrapper
|
||||
into a different assembly.
|
||||
However, by default the generated code may not compile if
|
||||
generated classes in one assembly use generated classes in another assembly.
|
||||
The visibility of the
|
||||
<tt>getCPtr()</tt> and pointer constructor generated from the <tt>csbody</tt> typemaps needs changing.
|
||||
The default visibility is <tt>internal</tt> but it needs to be <tt>public</tt> for access from a different assembly.
|
||||
Just changing 'internal' to 'public' in the typemap achieves this.
|
||||
Two macros are available in <tt>csharp.swg</tt> to make this easier and using them is the preferred approach
|
||||
over simply copying the typemaps and modifying as this is forward compatible with any changes in
|
||||
the <tt>csbody</tt> typemap in future versions of SWIG.
|
||||
The macros are for the proxy and typewrapper classes and can respectively be used to
|
||||
to make the method and constructor public:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
SWIG_CSBODY_PROXY(public, public, SWIGTYPE)
|
||||
SWIG_CSBODY_TYPEWRAPPER(public, public, public, SWIGTYPE)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Alternatively, instead of exposing these as public, consider
|
||||
using the <tt>[assembly:InternalsVisibleTo("Name")]</tt> attribute available in the .NET framework when you
|
||||
know which assemblies these can be exposed to.
|
||||
Another approach would be to make these public, but also to hide them from intellisense by using
|
||||
the <tt>[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]</tt> attribute
|
||||
if you don't want users to easily stumble upon these so called 'internal workings' of the wrappers.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_typemap_examples"></a>19.8 C# Typemap examples</H2>
|
||||
|
||||
|
||||
This section includes a few examples of typemaps. For more examples, you
|
||||
|
|
@ -1634,7 +1717,7 @@ might look at the files "<tt>csharp.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
|
||||
|
||||
<H3><a name="CSharp_memory_management_member_variables"></a>18.6.1 Memory management when returning references to member variables</H3>
|
||||
<H3><a name="CSharp_memory_management_member_variables"></a>19.8.1 Memory management when returning references to member variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1758,7 +1841,7 @@ public class Bike : IDisposable {
|
|||
Note the <tt>addReference</tt> call.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_memory_management_objects"></a>18.6.2 Memory management for objects passed to the C++ layer</H3>
|
||||
<H3><a name="CSharp_memory_management_objects"></a>19.8.2 Memory management for objects passed to the C++ layer</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1877,7 +1960,7 @@ The 'cscode' typemap simply adds in the specified code into the C# proxy class.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_date_marshalling"></a>18.6.3 Date marshalling using the csin typemap and associated attributes</H3>
|
||||
<H3><a name="CSharp_date_marshalling"></a>19.8.3 Date marshalling using the csin typemap and associated attributes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1974,13 +2057,13 @@ The typemaps to achieve this are shown below.
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%typemap(cstype) const CDate& "System.DateTime"
|
||||
%typemap(cstype) const CDate & "System.DateTime"
|
||||
%typemap(csin,
|
||||
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);"
|
||||
) const CDate &
|
||||
"$csclassname.getCPtr(temp$csinput)"
|
||||
|
||||
%typemap(cstype) CDate& "out System.DateTime"
|
||||
%typemap(cstype) CDate & "out System.DateTime"
|
||||
%typemap(csin,
|
||||
pre=" CDate temp$csinput = new CDate();",
|
||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
||||
|
|
@ -2109,7 +2192,8 @@ public class example {
|
|||
try {
|
||||
examplePINVOKE.addYears(CDate.getCPtr(temppDate), years);
|
||||
} finally {
|
||||
pDate = new System.DateTime(temppDate.getYear(), temppDate.getMonth(), temppDate.getDay(), 0, 0, 0);
|
||||
pDate = new System.DateTime(temppDate.getYear(), temppDate.getMonth(), temppDate.getDay(),
|
||||
0, 0, 0);
|
||||
}
|
||||
}
|
||||
...
|
||||
|
|
@ -2126,13 +2210,13 @@ The <tt>subtractYears</tt> method is nearly identical to the above <tt>addYears<
|
|||
<div class="code">
|
||||
<pre>
|
||||
%typemap(csin,
|
||||
pre=" using (CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day)) {",
|
||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
||||
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
|
||||
terminator=" } // terminate temp$csinput using block",
|
||||
cshin="ref $csinput"
|
||||
) CDate *
|
||||
"$csclassname.getCPtr(temp$csinput)"
|
||||
pre=" using (CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day)) {",
|
||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
||||
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
|
||||
terminator=" } // terminate temp$csinput using block",
|
||||
cshin="ref $csinput"
|
||||
) CDate *
|
||||
"$csclassname.getCPtr(temp$csinput)"
|
||||
|
||||
void subtractYears(CDate *pDate, int years) {
|
||||
*pDate = CDate(pDate->getYear() - years, pDate->getMonth(), pDate->getDay());
|
||||
|
|
@ -2152,7 +2236,8 @@ public class example {
|
|||
try {
|
||||
examplePINVOKE.subtractYears(CDate.getCPtr(temppDate), years);
|
||||
} finally {
|
||||
pDate = new System.DateTime(temppDate.getYear(), temppDate.getMonth(), temppDate.getDay(), 0, 0, 0);
|
||||
pDate = new System.DateTime(temppDate.getYear(), temppDate.getMonth(), temppDate.getDay(),
|
||||
0, 0, 0);
|
||||
}
|
||||
} // terminate temppDate using block
|
||||
}
|
||||
|
|
@ -2161,7 +2246,7 @@ public class example {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_date_properties"></a>18.6.4 A date example demonstrating marshalling of C# properties</H3>
|
||||
<H3><a name="CSharp_date_properties"></a>19.8.4 A date example demonstrating marshalling of C# properties</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2189,7 +2274,7 @@ Console.WriteLine("Important date: " + importantDate);
|
|||
</div>
|
||||
|
||||
<p>
|
||||
When SWIG wraps a variable that is a class/struct/union, it is wrapped using a pointer to the type for the reasons given in <a href="SWIG.html#SWIG_structure_data_members">Stucture data members</a>.
|
||||
When SWIG wraps a variable that is a class/struct/union, it is wrapped using a pointer to the type for the reasons given in <a href="SWIG.html#SWIG_structure_data_members">Structure data members</a>.
|
||||
The typemap type required is thus <tt>CDate *</tt>. Given that the previous section already designed <tt>CDate *</tt> typemaps, we'll use those same typemaps plus the 'csvarin' and 'csvarout' typemaps.
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -2261,8 +2346,69 @@ Some points to note:
|
|||
<li>The 'csin' typemap has 'pre', 'post' and 'cshin' attributes, and these are all ignored in the property set. The code in these attributes must instead be replicated within the 'csvarin' typemap. The line creating the <tt>temp$csinput</tt> variable is such an example; it is identical to what is in the 'pre' attribute.
|
||||
</ul>
|
||||
|
||||
<H3><a name="CSharp_date_pre_post_directors"></a>19.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</H3>
|
||||
|
||||
<H3><a name="CSharp_partial_classes"></a>18.6.5 Turning wrapped classes into partial classes</H3>
|
||||
|
||||
<p>
|
||||
The 'pre' and 'post' attributes in the "csdirectorin" typemap act like the attributes of the same name in the "csin" typemap.
|
||||
For example if we modify the <a href="#CSharp_date_marshalling">Date marshalling example</a> like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
class CDate {
|
||||
...
|
||||
void setYear(int);
|
||||
void setMonth(int);
|
||||
void setDay(int);
|
||||
};
|
||||
struct Action {
|
||||
virtual void someCallback(CDate &date);
|
||||
virtual ~Action();
|
||||
...
|
||||
};
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
and declare <tt>%feature ("director")</tt> for the <tt>Action</tt> class, we would have to define additional
|
||||
marshalling rules for <tt>CDate &</tt> parameter. The typemap may look like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%typemap(csdirectorin,
|
||||
pre="System.DateTime temp$iminput = new System.DateTime();",
|
||||
post="CDate temp2$iminput = new CDate($iminput, false);\n"
|
||||
"temp2$iminput.setYear(tempdate.Year);\n"
|
||||
"temp2$iminput.setMonth(tempdate.Month);\n"
|
||||
"temp2$iminput.setDay(tempdate.Day);"
|
||||
) CDate &date "out temp$iminput"
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The generated proxy class code will then contain the following wrapper for calling user-overloaded <tt>someCallback()</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
...
|
||||
private void SwigDirectorsomeCallback(IntPtr date) {
|
||||
System.DateTime tempdate = new System.DateTime();
|
||||
try {
|
||||
someCallback(out tempdate);
|
||||
} finally {
|
||||
// we create a managed wrapper around the existing C reference, just for convenience
|
||||
CDate temp2date = new CDate(date, false);
|
||||
temp2date.setYear(tempdate.Year);
|
||||
temp2date.setMonth(tempdate.Month);
|
||||
temp2date.setDay(tempdate.Day);
|
||||
}
|
||||
}
|
||||
...
|
||||
</pre></div>
|
||||
<p>
|
||||
Pay special attention to the memory management issues, using these attributes.
|
||||
</p>
|
||||
|
||||
|
||||
<H3><a name="CSharp_partial_classes"></a>19.8.6 Turning wrapped classes into partial classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2362,7 +2508,7 @@ demonstrating that the class contains methods calling both unmanaged code - <tt>
|
|||
The following example is an alternative approach to adding managed code to the generated proxy class.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_extending_proxy_class"></a>18.6.6 Extending proxy classes with additional C# code</H3>
|
||||
<H3><a name="CSharp_extending_proxy_class"></a>19.8.7 Extending proxy classes with additional C# code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2401,7 +2547,7 @@ public class ExtendMe : IDisposable {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_enum_underlying_type"></a>18.6.7 Underlying type for enums</H3>
|
||||
<H3><a name="CSharp_enum_underlying_type"></a>19.8.8 Underlying type for enums</H3>
|
||||
|
||||
|
||||
<P>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Chicken"></a>19 SWIG and Chicken</H1>
|
||||
<H1><a name="Chicken"></a>20 SWIG and Chicken</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -72,7 +72,7 @@
|
|||
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn2"></a>19.1 Preliminaries</H2>
|
||||
<H2><a name="Chicken_nn2"></a>20.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -89,7 +89,7 @@
|
|||
directory for the basic steps to run SWIG CHICKEN.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn3"></a>19.1.1 Running SWIG in C mode</H3>
|
||||
<H3><a name="Chicken_nn3"></a>20.1.1 Running SWIG in C mode</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,7 +122,7 @@
|
|||
object files and linked into your project.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn4"></a>19.1.2 Running SWIG in C++ mode</H3>
|
||||
<H3><a name="Chicken_nn4"></a>20.1.2 Running SWIG in C++ mode</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -151,10 +151,10 @@
|
|||
object files and linked into your project.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn5"></a>19.2 Code Generation</H2>
|
||||
<H2><a name="Chicken_nn5"></a>20.2 Code Generation</H2>
|
||||
|
||||
|
||||
<H3><a name="Chicken_nn6"></a>19.2.1 Naming Conventions</H3>
|
||||
<H3><a name="Chicken_nn6"></a>20.2.1 Naming Conventions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -170,7 +170,7 @@
|
|||
<tt>%rename</tt> SWIG directive in the SWIG interface file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn7"></a>19.2.2 Modules</H3>
|
||||
<H3><a name="Chicken_nn7"></a>20.2.2 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -192,7 +192,7 @@
|
|||
(uses <i>modulename</i>))</code> CHICKEN Scheme form.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn8"></a>19.2.3 Constants and Variables</H3>
|
||||
<H3><a name="Chicken_nn8"></a>20.2.3 Constants and Variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -229,7 +229,7 @@
|
|||
for info on how to apply the %feature.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn9"></a>19.2.4 Functions</H3>
|
||||
<H3><a name="Chicken_nn9"></a>20.2.4 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -248,7 +248,7 @@
|
|||
parameters). The return values can then be accessed with <code>(call-with-values)</code>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn10"></a>19.2.5 Exceptions</H3>
|
||||
<H3><a name="Chicken_nn10"></a>20.2.5 Exceptions</H3>
|
||||
|
||||
|
||||
<p>The SWIG chicken module has support for exceptions thrown from
|
||||
|
|
@ -290,7 +290,7 @@
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H2><a name="Chicken_nn11"></a>19.3 TinyCLOS</H2>
|
||||
<H2><a name="Chicken_nn11"></a>20.3 TinyCLOS</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -333,7 +333,7 @@
|
|||
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn12"></a>19.4 Linkage</H2>
|
||||
<H2><a name="Chicken_nn12"></a>20.4 Linkage</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -354,7 +354,7 @@
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Chicken_nn13"></a>19.4.1 Static binary or shared library linked at compile time</H3>
|
||||
<H3><a name="Chicken_nn13"></a>20.4.1 Static binary or shared library linked at compile time</H3>
|
||||
|
||||
|
||||
<p>We can easily use csc to build a static binary.</p>
|
||||
|
|
@ -395,7 +395,7 @@ in which case the test script does not need to be linked with example.so. The t
|
|||
be run with <tt>csi</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn14"></a>19.4.2 Building chicken extension libraries</H3>
|
||||
<H3><a name="Chicken_nn14"></a>20.4.2 Building chicken extension libraries</H3>
|
||||
|
||||
|
||||
<p>Building a shared library like in the above section only works if the library
|
||||
|
|
@ -453,7 +453,7 @@ distributed and used by anyone, even if SWIG is not installed.</p>
|
|||
<p>See the <tt>Examples/chicken/egg</tt> directory in the SWIG source for an example that builds
|
||||
two eggs, one using the first method and one using the second method.</p>
|
||||
|
||||
<H3><a name="Chicken_nn15"></a>19.4.3 Linking multiple SWIG modules with TinyCLOS</H3>
|
||||
<H3><a name="Chicken_nn15"></a>20.4.3 Linking multiple SWIG modules with TinyCLOS</H3>
|
||||
|
||||
|
||||
<p>Linking together multiple modules that share type information using the <code>%import</code>
|
||||
|
|
@ -477,7 +477,7 @@ with <code>(declare (uses ...))</code>.
|
|||
To create an extension library or an egg, just create a <tt>module_load.scm</tt> file that <code>(declare (uses ...))</code>
|
||||
all the modules.</p>
|
||||
|
||||
<H2><a name="Chicken_nn16"></a>19.5 Typemaps</H2>
|
||||
<H2><a name="Chicken_nn16"></a>20.5 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -486,7 +486,7 @@ all the modules.</p>
|
|||
<code>Lib/chicken/chicken.swg</code>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn17"></a>19.6 Pointers</H2>
|
||||
<H2><a name="Chicken_nn17"></a>20.6 Pointers</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -519,7 +519,7 @@ all the modules.</p>
|
|||
type. flags is either zero or SWIG_POINTER_DISOWN (see below).
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_collection"></a>19.6.1 Garbage collection</H3>
|
||||
<H3><a name="Chicken_collection"></a>20.6.1 Garbage collection</H3>
|
||||
|
||||
|
||||
<p>If the owner flag passed to <code>SWIG_NewPointerObj</code> is 1, <code>NewPointerObj</code> will add a
|
||||
|
|
@ -550,7 +550,7 @@ all the modules.</p>
|
|||
must be called manually.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn18"></a>19.7 Unsupported features and known problems</H2>
|
||||
<H2><a name="Chicken_nn18"></a>20.7 Unsupported features and known problems</H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -560,7 +560,7 @@ all the modules.</p>
|
|||
<a href="SWIGPlus.html#SWIGPlus_default_args">%feature(compactdefaultargs)</a>.</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Chicken_nn19"></a>19.7.1 TinyCLOS problems with Chicken version <= 1.92</H3>
|
||||
<H3><a name="Chicken_nn19"></a>20.7.1 TinyCLOS problems with Chicken version <= 1.92</H3>
|
||||
|
||||
|
||||
<p>In Chicken versions equal to or below 1.92, TinyCLOS has a limitation such that generic methods do not properly work on methods
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<TITLE>SWIG Users Manual</TITLE>
|
||||
</HEAD>
|
||||
<BODY BGCOLOR="#ffffff">
|
||||
<H1>SWIG Users Manual</H1>
|
||||
<H1><a name="Contents"></a>SWIG Users Manual</H1>
|
||||
|
||||
<p>
|
||||
|
||||
|
|
@ -152,6 +152,12 @@
|
|||
<li><a href="SWIG.html#SWIG_nn26">Arrays</a>
|
||||
<li><a href="SWIG.html#SWIG_readonly_variables">Creating read-only variables</a>
|
||||
<li><a href="SWIG.html#SWIG_rename_ignore">Renaming and ignoring declarations</a>
|
||||
<ul>
|
||||
<li><a href="SWIG.html#SWIG_nn29">Simple renaming of specific identifiers</a>
|
||||
<li><a href="SWIG.html#SWIG_advanced_renaming">Advanced renaming support</a>
|
||||
<li><a href="SWIG.html#SWIG_limiting_renaming">Limiting global renaming rules</a>
|
||||
<li><a href="SWIG.html#SWIG_chosen_unignore">Ignoring everything then wrapping a few selected symbols</a>
|
||||
</ul>
|
||||
<li><a href="SWIG.html#SWIG_default_args">Default/optional arguments</a>
|
||||
<li><a href="SWIG.html#SWIG_nn30">Pointers to functions and callbacks</a>
|
||||
</ul>
|
||||
|
|
@ -237,6 +243,7 @@
|
|||
<li><a href="SWIGPlus.html#SWIGPlus_catches">Exception handling with %catches</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn33">Pointers to Members</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_smart_pointers">Smart pointers and operator->()</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_ref_unref">C++ reference counted objects - ref/unref feature</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn35">Using declarations and inheritance</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nested_classes">Nested classes</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_const">A brief rant about const-correctness</a>
|
||||
|
|
@ -256,8 +263,11 @@
|
|||
<li><a href="Preprocessor.html#Preprocessor_nn5">Macro Expansion</a>
|
||||
<li><a href="Preprocessor.html#Preprocessor_nn6">SWIG Macros</a>
|
||||
<li><a href="Preprocessor.html#Preprocessor_nn7">C99 and GNU Extensions</a>
|
||||
<li><a href="Preprocessor.html#Preprocessor_delimiters">Preprocessing and delimiters</a>
|
||||
<ul>
|
||||
<li><a href="Preprocessor.html#Preprocessor_nn8">Preprocessing and %{ ... %} & " ... " delimiters</a>
|
||||
<li><a href="Preprocessor.html#Preprocessor_nn9">Preprocessing and { ... } delimiters</a>
|
||||
</ul>
|
||||
<li><a href="Preprocessor.html#Preprocessor_typemap_delimiters">Preprocessor and Typemaps</a>
|
||||
<li><a href="Preprocessor.html#Preprocessor_nn10">Viewing preprocessor output</a>
|
||||
<li><a href="Preprocessor.html#Preprocessor_warning_error">The #error and #warning directives</a>
|
||||
|
|
@ -391,6 +401,7 @@
|
|||
<li><a href="Typemaps.html#Typemaps_nn43">Typemaps for multiple target languages</a>
|
||||
<li><a href="Typemaps.html#Typemaps_optimal">Optimal code generation when returning by value</a>
|
||||
<li><a href="Typemaps.html#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a>
|
||||
<li><a href="Typemaps.html#Typemaps_warnings">Typemap warnings</a>
|
||||
<li><a href="Typemaps.html#Typemaps_fragments">Typemap fragments</a>
|
||||
<ul>
|
||||
<li><a href="Typemaps.html#Typemaps_fragment_type_specialization">Fragment type specialization</a>
|
||||
|
|
@ -489,7 +500,7 @@
|
|||
<li><a href="Warnings.html#Warnings_nn12">C/C++ Parser (300-399)</a>
|
||||
<li><a href="Warnings.html#Warnings_nn13">Types and typemaps (400-499) </a>
|
||||
<li><a href="Warnings.html#Warnings_nn14">Code generation (500-599)</a>
|
||||
<li><a href="Warnings.html#Warnings_nn15">Language module specific (800-899) </a>
|
||||
<li><a href="Warnings.html#Warnings_nn15">Language module specific (700-899) </a>
|
||||
<li><a href="Warnings.html#Warnings_nn16">User defined (900-999)</a>
|
||||
</ul>
|
||||
<li><a href="Warnings.html#Warnings_nn17">History</a>
|
||||
|
|
@ -623,13 +634,32 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CSharp.html#CSharp">18 SWIG and C#</a></h3>
|
||||
<h3><a href="Android.html#Android">18 SWIG and Android</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Android.html#Android_overview">Overview</a>
|
||||
<li><a href="Android.html#Android_examples">Android examples</a>
|
||||
<ul>
|
||||
<li><a href="Android.html#Android_examples_intro">Examples introduction</a>
|
||||
<li><a href="Android.html#Android_example_simple">Simple C example</a>
|
||||
<li><a href="Android.html#Android_example_class">C++ class example</a>
|
||||
<li><a href="Android.html#Android_examples_other">Other examples</a>
|
||||
</ul>
|
||||
<li><a href="Android.html#Android_stl">C++ STL</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CSharp.html#CSharp">19 SWIG and C#</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="CSharp.html#CSharp_introduction">Introduction</a>
|
||||
<li><a href="CSharp.html#CSharp_differences_java">Differences to the Java module</a>
|
||||
<li><a href="CSharp.html#CSharp_void_pointers">Void pointers</a>
|
||||
<li><a href="CSharp.html#CSharp_arrays">C# Arrays</a>
|
||||
<ul>
|
||||
<li><a href="CSharp.html#CSharp_arrays_swig_library">The SWIG C arrays library</a>
|
||||
|
|
@ -649,12 +679,14 @@
|
|||
<li><a href="CSharp.html#CSharp_directors_implementation">Directors implementation</a>
|
||||
<li><a href="CSharp.html#CSharp_director_caveats">Director caveats</a>
|
||||
</ul>
|
||||
<li><a href="CSharp.html#CSharp_multiple_modules">Multiples modules</a>
|
||||
<li><a href="CSharp.html#CSharp_typemap_examples">C# Typemap examples</a>
|
||||
<ul>
|
||||
<li><a href="CSharp.html#CSharp_memory_management_member_variables">Memory management when returning references to member variables</a>
|
||||
<li><a href="CSharp.html#CSharp_memory_management_objects">Memory management for objects passed to the C++ layer</a>
|
||||
<li><a href="CSharp.html#CSharp_date_marshalling">Date marshalling using the csin typemap and associated attributes</a>
|
||||
<li><a href="CSharp.html#CSharp_date_properties">A date example demonstrating marshalling of C# properties</a>
|
||||
<li><a href="CSharp.html#CSharp_date_pre_post_directors">Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a>
|
||||
<li><a href="CSharp.html#CSharp_partial_classes">Turning wrapped classes into partial classes</a>
|
||||
<li><a href="CSharp.html#CSharp_extending_proxy_class">Extending proxy classes with additional C# code</a>
|
||||
<li><a href="CSharp.html#CSharp_enum_underlying_type">Underlying type for enums</a>
|
||||
|
|
@ -663,7 +695,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Chicken.html#Chicken">19 SWIG and Chicken</a></h3>
|
||||
<h3><a href="Chicken.html#Chicken">20 SWIG and Chicken</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -701,7 +733,41 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Go.html#Go">20 SWIG and Go</a></h3>
|
||||
<h3><a href="D.html#D">21 SWIG and D</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="D.html#D_introduction">Introduction</a>
|
||||
<li><a href="D.html#D_command_line_invocation">Command line invocation</a>
|
||||
<li><a href="D.html#D_typemaps">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="D.html#D_typemap_name_comparison">C# <-> D name comparison</a>
|
||||
<li><a href="D.html#D_ctype_imtype_dtype">ctype, imtype, dtype</a>
|
||||
<li><a href="D.html#D_in_out_directorin_direcetorout">in, out, directorin, directorout</a>
|
||||
<li><a href="D.html#D_din_dout_ddirectorin_ddirectorout">din, dout, ddirectorin, ddirectorout</a>
|
||||
<li><a href="D.html#D_typecheck_typemaps">typecheck typemaps</a>
|
||||
<li><a href="D.html#D_code_injection_typemaps">Code injection typemaps</a>
|
||||
<li><a href="D.html#D_special_variables">Special variable macros</a>
|
||||
</ul>
|
||||
<li><a href="D.html#D_features"><tt>%feature</tt>s</a>
|
||||
<li><a href="D.html#D_pragmas">Pragmas</a>
|
||||
<li><a href="D.html#D_exceptions">D Exceptions</a>
|
||||
<li><a href="D.html#D_directors">D Directors</a>
|
||||
<li><a href="D.html#D_other_features">Other features</a>
|
||||
<ul>
|
||||
<li><a href="D.html#D_nspace">Extended namespace support (<tt>nspace</tt>)</a>
|
||||
<li><a href="D.html#D_native_pointer_support">Native pointer support</a>
|
||||
<li><a href="D.html#D_operator_overloading">Operator overloading</a>
|
||||
<li><a href="D.html#D_test_suite">Running the test-suite</a>
|
||||
</ul>
|
||||
<li><a href="D.html#D_typemap_examples">D Typemap examples</a>
|
||||
<li><a href="D.html#D_planned_features">Work in progress and planned features</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Go.html#Go">22 SWIG and Go</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -725,12 +791,14 @@
|
|||
<li><a href="Go.html#Go_templates">Go Templates</a>
|
||||
<li><a href="Go.html#Go_director_classes">Go Director Classes</a>
|
||||
<li><a href="Go.html#Go_primitive_type_mappings">Default Go primitive type mappings</a>
|
||||
<li><a href="Go.html#Go_output_arguments">Output arguments</a>
|
||||
<li><a href="Go.html#Go_adding_additional_code">Adding additional go code</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Guile.html#Guile">21 SWIG and Guile</a></h3>
|
||||
<h3><a href="Guile.html#Guile">23 SWIG and Guile</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -765,7 +833,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Java.html#Java">22 SWIG and Java</a></h3>
|
||||
<h3><a href="Java.html#Java">24 SWIG and Java</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -847,6 +915,7 @@
|
|||
<li><a href="Java.html#Java_directors_overhead">Overhead and code bloat</a>
|
||||
<li><a href="Java.html#Java_directors_example">Simple directors example</a>
|
||||
<li><a href="Java.html#Java_directors_threading">Director threading issues</a>
|
||||
<li><a href="Java.html#Java_directors_performance">Director performance tuning</a>
|
||||
</ul>
|
||||
<li><a href="Java.html#Java_allprotected">Accessing protected members</a>
|
||||
<li><a href="Java.html#Java_common_customization">Common customization features</a>
|
||||
|
|
@ -862,6 +931,7 @@
|
|||
<li><a href="Java.html#Java_simple_pointers">Simple pointers</a>
|
||||
<li><a href="Java.html#Java_c_arrays">Wrapping C arrays with Java arrays</a>
|
||||
<li><a href="Java.html#Java_unbounded_c_arrays">Unbounded C Arrays</a>
|
||||
<li><a href="Java.html#Java_binary_char">Binary data vs Strings</a>
|
||||
<li><a href="Java.html#Java_heap_allocations">Overriding new and delete to allocate from Java heap</a>
|
||||
</ul>
|
||||
<li><a href="Java.html#Java_typemaps">Java typemaps</a>
|
||||
|
|
@ -902,12 +972,12 @@
|
|||
<li><a href="Java.html#Java_performance">Performance concerns and hints</a>
|
||||
<li><a href="Java.html#Java_debugging">Debugging</a>
|
||||
</ul>
|
||||
<li><a href="Java.html#Java_examples">Examples</a>
|
||||
<li><a href="Java.html#Java_examples">Java Examples</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Lisp.html#Lisp">23 SWIG and Common Lisp</a></h3>
|
||||
<h3><a href="Lisp.html#Lisp">25 SWIG and Common Lisp</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -930,7 +1000,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Lua.html#Lua">24 SWIG and Lua</a></h3>
|
||||
<h3><a href="Lua.html#Lua">26 SWIG and Lua</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -938,6 +1008,7 @@
|
|||
<li><a href="Lua.html#Lua_nn2">Preliminaries</a>
|
||||
<li><a href="Lua.html#Lua_nn3">Running SWIG</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_commandline">Additional command line options</a>
|
||||
<li><a href="Lua.html#Lua_nn4">Compiling and Linking and Interpreter</a>
|
||||
<li><a href="Lua.html#Lua_nn5">Compiling a dynamic module</a>
|
||||
<li><a href="Lua.html#Lua_nn6">Using your module</a>
|
||||
|
|
@ -956,38 +1027,39 @@
|
|||
<li><a href="Lua.html#Lua_nn17">C++ overloaded functions</a>
|
||||
<li><a href="Lua.html#Lua_nn18">C++ operators</a>
|
||||
<li><a href="Lua.html#Lua_nn19">Class extension with %extend</a>
|
||||
<li><a href="Lua.html#Lua_nn20">C++ templates</a>
|
||||
<li><a href="Lua.html#Lua_nn21">C++ Smart Pointers</a>
|
||||
<li><a href="Lua.html#Lua_nn22">C++ Exceptions</a>
|
||||
<li><a href="Lua.html#Lua_nn20">Using %newobject to release memory</a>
|
||||
<li><a href="Lua.html#Lua_nn21">C++ templates</a>
|
||||
<li><a href="Lua.html#Lua_nn22">C++ Smart Pointers</a>
|
||||
<li><a href="Lua.html#Lua_nn23">C++ Exceptions</a>
|
||||
</ul>
|
||||
<li><a href="Lua.html#Lua_nn23">Typemaps</a>
|
||||
<li><a href="Lua.html#Lua_nn24">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_nn24">What is a typemap?</a>
|
||||
<li><a href="Lua.html#Lua_nn25">Using typemaps</a>
|
||||
<li><a href="Lua.html#Lua_nn26">Typemaps and arrays</a>
|
||||
<li><a href="Lua.html#Lua_nn27">Typemaps and pointer-pointer functions</a>
|
||||
<li><a href="Lua.html#Lua_nn25">What is a typemap?</a>
|
||||
<li><a href="Lua.html#Lua_nn26">Using typemaps</a>
|
||||
<li><a href="Lua.html#Lua_nn27">Typemaps and arrays</a>
|
||||
<li><a href="Lua.html#Lua_nn28">Typemaps and pointer-pointer functions</a>
|
||||
</ul>
|
||||
<li><a href="Lua.html#Lua_nn28">Writing typemaps</a>
|
||||
<li><a href="Lua.html#Lua_nn29">Writing typemaps</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_nn29">Typemaps you can write</a>
|
||||
<li><a href="Lua.html#Lua_nn30">SWIG's Lua-C API</a>
|
||||
<li><a href="Lua.html#Lua_nn30">Typemaps you can write</a>
|
||||
<li><a href="Lua.html#Lua_nn31">SWIG's Lua-C API</a>
|
||||
</ul>
|
||||
<li><a href="Lua.html#Lua_nn31">Customization of your Bindings</a>
|
||||
<li><a href="Lua.html#Lua_nn32">Customization of your Bindings</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_nn32">Writing your own custom wrappers</a>
|
||||
<li><a href="Lua.html#Lua_nn33">Adding additional Lua code</a>
|
||||
<li><a href="Lua.html#Lua_nn33">Writing your own custom wrappers</a>
|
||||
<li><a href="Lua.html#Lua_nn34">Adding additional Lua code</a>
|
||||
</ul>
|
||||
<li><a href="Lua.html#Lua_nn34">Details on the Lua binding</a>
|
||||
<li><a href="Lua.html#Lua_nn35">Details on the Lua binding</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_nn35">Binding global data into the module.</a>
|
||||
<li><a href="Lua.html#Lua_nn36">Userdata and Metatables</a>
|
||||
<li><a href="Lua.html#Lua_nn37">Memory management</a>
|
||||
<li><a href="Lua.html#Lua_nn36">Binding global data into the module.</a>
|
||||
<li><a href="Lua.html#Lua_nn37">Userdata and Metatables</a>
|
||||
<li><a href="Lua.html#Lua_nn38">Memory management</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Modula3.html#Modula3">25 SWIG and Modula-3</a></h3>
|
||||
<h3><a href="Modula3.html#Modula3">27 SWIG and Modula-3</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1025,17 +1097,19 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Mzscheme.html#Mzscheme">26 SWIG and MzScheme</a></h3>
|
||||
<h3><a href="Mzscheme.html#Mzscheme">28 SWIG and MzScheme/Racket</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Mzscheme.html#MzScheme_nn2">Creating native MzScheme structures</a>
|
||||
<li><a href="Mzscheme.html#MzScheme_nn2">Creating native structures</a>
|
||||
<li><a href="Mzscheme.html#MzScheme_simple">Simple example</a>
|
||||
<li><a href="Mzscheme.html#MzScheme_external_docs">External documentation</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ocaml.html#Ocaml">27 SWIG and Ocaml</a></h3>
|
||||
<h3><a href="Ocaml.html#Ocaml">29 SWIG and Ocaml</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1086,7 +1160,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Octave.html#Octave">28 SWIG and Octave</a></h3>
|
||||
<h3><a href="Octave.html#Octave">30 SWIG and Octave</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1094,6 +1168,7 @@
|
|||
<li><a href="Octave.html#Octave_nn2">Preliminaries</a>
|
||||
<li><a href="Octave.html#Octave_nn3">Running SWIG</a>
|
||||
<ul>
|
||||
<li><a href="Octave.html#Octave_nn4">Command-line options</a>
|
||||
<li><a href="Octave.html#Octave_nn5">Compiling a dynamic module</a>
|
||||
<li><a href="Octave.html#Octave_nn6">Using your module</a>
|
||||
</ul>
|
||||
|
|
@ -1121,7 +1196,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Perl5.html#Perl5">29 SWIG and Perl5</a></h3>
|
||||
<h3><a href="Perl5.html#Perl5">31 SWIG and Perl5</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1188,7 +1263,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Php.html#Php">30 SWIG and PHP</a></h3>
|
||||
<h3><a href="Php.html#Php">32 SWIG and PHP</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1228,7 +1303,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Pike.html#Pike">31 SWIG and Pike</a></h3>
|
||||
<h3><a href="Pike.html#Pike">33 SWIG and Pike</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1252,7 +1327,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Python.html#Python">32 SWIG and Python</a></h3>
|
||||
<h3><a href="Python.html#Python">34 SWIG and Python</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1285,11 +1360,16 @@
|
|||
<li><a href="Python.html#Python_nn25">C++ namespaces</a>
|
||||
<li><a href="Python.html#Python_nn26">C++ templates</a>
|
||||
<li><a href="Python.html#Python_nn27">C++ Smart Pointers</a>
|
||||
<li><a href="Python.html#Python_nn27a">C++ Reference Counted Objects (ref/unref)</a>
|
||||
<li><a href="Python.html#Python_nn27a">C++ reference counted objects</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn28">Further details on the Python class interface</a>
|
||||
<ul>
|
||||
<li><a href="Python.html#Python_nn29">Proxy classes</a>
|
||||
<li><a href="Python.html#Python_builtin_types">Built-in Types</a>
|
||||
<ul>
|
||||
<li><a href="Python.html#Python_builtin_limitations">Limitations</a>
|
||||
<li><a href="Python.html#Python_builtin_overloads">Operator overloads -- use them!</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn30">Memory management</a>
|
||||
<li><a href="Python.html#Python_nn31">Python 2.2 and classic classes</a>
|
||||
</ul>
|
||||
|
|
@ -1340,6 +1420,8 @@
|
|||
<ul>
|
||||
<li><a href="Python.html#Python_nn68">%feature("autodoc", "0")</a>
|
||||
<li><a href="Python.html#Python_nn69">%feature("autodoc", "1")</a>
|
||||
<li><a href="Python.html#Python_autodoc2">%feature("autodoc", "2")</a>
|
||||
<li><a href="Python.html#Python_autodoc3">%feature("autodoc", "3")</a>
|
||||
<li><a href="Python.html#Python_nn70">%feature("autodoc", "docstring")</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn71">%feature("docstring")</a>
|
||||
|
|
@ -1355,7 +1437,23 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ruby.html#Ruby">33 SWIG and Ruby</a></h3>
|
||||
<h3><a href="R.html#R">35 SWIG and R</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="R.html#R_nn2">Bugs</a>
|
||||
<li><a href="R.html#R_nn3">Using R and SWIG</a>
|
||||
<li><a href="R.html#R_nn4">Precompiling large R files</a>
|
||||
<li><a href="R.html#R_nn5">General policy</a>
|
||||
<li><a href="R.html#R_language_conventions">Language conventions</a>
|
||||
<li><a href="R.html#R_nn6">C++ classes</a>
|
||||
<li><a href="R.html#R_nn7">Enumerations</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ruby.html#Ruby">36 SWIG and Ruby</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1489,7 +1587,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Tcl.html#Tcl">34 SWIG and Tcl</a></h3>
|
||||
<h3><a href="Tcl.html#Tcl">37 SWIG and Tcl</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1555,23 +1653,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="R.html#R">35 SWIG and R</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="R.html#R_nn2">Bugs</a>
|
||||
<li><a href="R.html#R_nn3">Using R and SWIG</a>
|
||||
<li><a href="R.html#R_nn4">Precompiling large R files</a>
|
||||
<li><a href="R.html#R_nn5">General policy</a>
|
||||
<li><a href="R.html#R_language_conventions">Language conventions</a>
|
||||
<li><a href="R.html#R_nn6">C++ classes</a>
|
||||
<li><a href="R.html#R_nn7">Enumerations</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Extending.html#Extending">36 Extending SWIG to support new languages</a></h3>
|
||||
<h3><a href="Extending.html#Extending">38 Extending SWIG to support new languages</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
|
|||
|
|
@ -454,6 +454,11 @@ variables are replaced with.
|
|||
<td>The actual operation to be performed (a function call, method invocation, variable access, etc.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$name</td>
|
||||
<td>The C/C++ symbol name for the function.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$symname</td>
|
||||
<td>The symbol name used internally by SWIG</td>
|
||||
|
|
@ -479,6 +484,16 @@ variables are replaced with.
|
|||
<td>The fully qualified C/C++ declaration of the method being wrapped including the return type</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$parentname</td>
|
||||
<td>The parent class name (if any) for a method.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$parentsymname</td>
|
||||
<td>The target language parent class name (if any) for a method.</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
|
||||
<p>
|
||||
|
|
@ -704,6 +719,11 @@ depends on the target language on implementing the 'disown' mechanism
|
|||
properly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The use of <tt>%newobject</tt> is also integrated with reference counting and is covered in the
|
||||
<a href="SWIGPlus.html#SWIGPlus_ref_unref">C++ reference counted objects</a> section.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Compatibility note:</b> Previous versions of SWIG had a special <tt>%new</tt> directive. However, unlike <tt>%newobject</tt>,
|
||||
it only applied to the next declaration. For example:
|
||||
|
|
|
|||
454
Doc/Manual/D.html
Normal file
454
Doc/Manual/D.html
Normal file
|
|
@ -0,0 +1,454 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG and D</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="D"></a>21 SWIG and D</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#D_introduction">Introduction</a>
|
||||
<li><a href="#D_command_line_invocation">Command line invocation</a>
|
||||
<li><a href="#D_typemaps">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="#D_typemap_name_comparison">C# <-> D name comparison</a>
|
||||
<li><a href="#D_ctype_imtype_dtype">ctype, imtype, dtype</a>
|
||||
<li><a href="#D_in_out_directorin_direcetorout">in, out, directorin, directorout</a>
|
||||
<li><a href="#D_din_dout_ddirectorin_ddirectorout">din, dout, ddirectorin, ddirectorout</a>
|
||||
<li><a href="#D_typecheck_typemaps">typecheck typemaps</a>
|
||||
<li><a href="#D_code_injection_typemaps">Code injection typemaps</a>
|
||||
<li><a href="#D_special_variables">Special variable macros</a>
|
||||
</ul>
|
||||
<li><a href="#D_features"><tt>%feature</tt>s</a>
|
||||
<li><a href="#D_pragmas">Pragmas</a>
|
||||
<li><a href="#D_exceptions">D Exceptions</a>
|
||||
<li><a href="#D_directors">D Directors</a>
|
||||
<li><a href="#D_other_features">Other features</a>
|
||||
<ul>
|
||||
<li><a href="#D_nspace">Extended namespace support (<tt>nspace</tt>)</a>
|
||||
<li><a href="#D_native_pointer_support">Native pointer support</a>
|
||||
<li><a href="#D_operator_overloading">Operator overloading</a>
|
||||
<li><a href="#D_test_suite">Running the test-suite</a>
|
||||
</ul>
|
||||
<li><a href="#D_typemap_examples">D Typemap examples</a>
|
||||
<li><a href="#D_planned_features">Work in progress and planned features</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
|
||||
|
||||
<H2><a name="D_introduction"></a>21.1 Introduction</H2>
|
||||
|
||||
|
||||
<p>From the <a href="http://www.digitalmars.com/d/">D Programming Language</a> web site: <em>D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. [...] The D language is statically typed and compiles directly to machine code.</em> As such, it is not very surprising that D is able to directly <a href="http://www.digitalmars.com/d/1.0/interfaceToC.html">interface with C libraries</a>. Why would a SWIG module for D be needed then in the first place?</p>
|
||||
|
||||
<p>Well, besides the obvious downside that the C header files have to be manually converted to D modules for this to work, there is one major inconvenience with this approach: D code usually is on a higher abstraction level than C, and many of the features that make D interesting are simply not available when dealing with C libraries, requiring you e.g. to manually convert strings between pointers to <tt>\0</tt>-terminated char arrays and D char arrays, making the algorithms from the D2 standard library unusable with C arrays and data structures, and so on.</p>
|
||||
|
||||
<p>While these issues can be worked around relatively easy by hand-coding a thin wrapper layer around the C library in question, there is another issue where writing wrapper code per hand is not feasible: C++ libraries. D did not support interfacing to C++ in version 1 at all, and even if <tt>extern(C++)</tt> has been added to D2, the support is still very limited, and a custom wrapper layer is still required in many cases. </p>
|
||||
|
||||
<p>To help addressing these issues, the SWIG C# module has been forked to support D. Is has evolved quite a lot since then, but there are still many similarities, so if you do not find what you are looking for on this page, it might be worth having a look at the chapter on <a href="CSharp.html">C#</a> (and also on <a href="Java.html">Java</a>, since the C# module was in turn forked from it).</p>
|
||||
|
||||
|
||||
<H2><a name="D_command_line_invocation"></a>21.2 Command line invocation</H2>
|
||||
|
||||
|
||||
<p>To activate the D module, pass the <tt>-d</tt> option to SWIG at the command line. The same standard command line switches as with any other language module are available, plus the following D specific ones:</p>
|
||||
|
||||
<dl>
|
||||
<dt><tt>-d2</tt></dt>
|
||||
<dd>
|
||||
<p>By default, SWIG generates code for D1/Tango. Use the <tt>-d2</tt> flag to target D2/Phobos instead.</p>
|
||||
</dd>
|
||||
|
||||
<dt id="D_splitproxy"><tt>-splitproxy</tt></dt>
|
||||
<dd>
|
||||
<p>By default, SWIG generates two D modules: the <em>proxy</em> module, named like the source module (either specified via the <tt>%module</tt> directive or via the <tt>module</tt> command line switch), which contains all the proxy classes, functions, enums, etc., and the <em>intermediary</em> module (named like the proxy module, but suffixed with <tt>_im</tt>), which contains all the <tt>extern(C)</tt> function declarations and other private parts only used internally by the proxy module.</p>
|
||||
<p>If the split proxy mode is enabled by passing this switch at the command line, all proxy classes and enums are emitted to their own D module instead. The main proxy module only contains free functions and constants in this case.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>-package <pkg></tt></dt>
|
||||
<dd>
|
||||
<p>By default, the proxy D modules and the intermediary D module are written to the root package. Using this option, you can specify another target package instead.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>-wrapperlibrary <wl></tt></dt>
|
||||
<dd>
|
||||
<p>The code SWIG generates to dynamically load the C/C++ wrapper layer looks for a library called <tt>$module_wrap</tt> by default. With this switch, you can override the name of the file the wrapper code loads at runtime (the <tt>lib</tt> prefix and the suffix for shared libraries are appended automatically, depending on the OS).</p>
|
||||
<p>This might especially be useful if you want to invoke SWIG several times on separate modules, but compile the resulting code into a single shared library.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_typemaps"></a>21.3 Typemaps</H2>
|
||||
|
||||
|
||||
<H3><a name="D_typemap_name_comparison"></a>21.3.1 C# <-> D name comparison</H3>
|
||||
|
||||
|
||||
<p>If you already know the SWIG C# module, you might find the following name comparison table useful:</p>
|
||||
|
||||
<div class="diagram"><pre>
|
||||
ctype <-> ctype
|
||||
imtype <-> imtype
|
||||
cstype <-> dtype
|
||||
csin <-> din
|
||||
csout <-> dout
|
||||
csdirectorin <-> ddirectorin
|
||||
csdirectorout <-> ddirectorout
|
||||
csinterfaces <-> dinterfaces
|
||||
csinterfaces_derived <-> dinterfaces_derived
|
||||
csbase <-> dbase
|
||||
csclassmodifiers <-> dclassmodifiers
|
||||
cscode <-> dcode
|
||||
csimports <-> dimports
|
||||
csbody <-> dbody
|
||||
csfinalize <-> ddestructor
|
||||
csdestruct <-> ddispose
|
||||
csdestruct_derived <-> ddispose_derived
|
||||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="D_ctype_imtype_dtype"></a>21.3.2 ctype, imtype, dtype</H3>
|
||||
|
||||
|
||||
<p>Mapping of types between the C/C++ library, the C/C++ library wrapper exposing the C functions, the D wrapper module importing these functions and the D proxy code.</p>
|
||||
|
||||
<p>The <tt>ctype</tt> typemap is used to determine the types to use in the C wrapper functions. The types from the <tt>imtype</tt> typemap are used in the extern(C) declarations of these functions in the intermediary D module. The <tt>dtype</tt> typemap contains the D types used in the D proxy module/class.</p>
|
||||
|
||||
|
||||
<H3><a name="D_in_out_directorin_direcetorout"></a>21.3.3 in, out, directorin, directorout</H3>
|
||||
|
||||
|
||||
<p>Used for converting between the types for C/C++ and D when generating the code for the wrapper functions (on the C++ side).</p>
|
||||
|
||||
<p>The code from the <tt>in</tt> typemap is used to convert arguments to the C wrapper function to the type used in the wrapped code (<tt>ctype</tt>->original C++ type), the <tt>out</tt> typemap is utilized to convert values from the wrapped code to wrapper function return types (original C++ type-><tt>ctype</tt>).</p>
|
||||
|
||||
<p>The <tt>directorin</tt> typemap is used to convert parameters to the type used in the D director callback function, its return value is processed by <tt>directorout</tt> (see below).</p>
|
||||
|
||||
|
||||
<H3><a name="D_din_dout_ddirectorin_ddirectorout"></a>21.3.4 din, dout, ddirectorin, ddirectorout</H3>
|
||||
|
||||
|
||||
<p>Typemaps for code generation in D proxy and type wrapper classes.</p>
|
||||
|
||||
<p id="D_din">The <tt>din</tt> typemap is used for converting function parameter types from the type used in the proxy module or class to the type used in the intermediary D module (the <a href="D.html#D_dinput"><tt>$dinput</tt></a> macro is replaced). To inject further parameter processing code before or after the call to the intermediary layer, the <tt>pre</tt>, <tt>post</tt> and <tt>terminator</tt> attributes can be used (please refer to the <a href="CSharp.html#CSharp_date_marshalling">C# date marshalling example</a> for more information on these).</p>
|
||||
|
||||
<p id="D_dout">The <tt>dout</tt> typemap is used for converting function return values from the return type used in the intermediary D module to the type returned by the proxy function. The <tt>$excode</tt> special variable in <tt>dout</tt> typemaps is replaced by the <tt>excode</tt> typemap attribute code if the method can throw any exceptions from unmanaged code, otherwise by nothing (the <a href="D.html#D_imcall"><tt>$imcall</tt> and <tt>$owner</tt></a> macros are replaced).</p>
|
||||
|
||||
<p id="D_ddirectorinout">The code from the <tt>ddirectorin</tt> and <tt>ddirectorout</tt> typemaps is used for conversion in director callback functions. Arguments are converted to the type used in the proxy class method they are calling by using the code from <tt>ddirectorin</tt>, the proxy class method return value is converted to the type the C++ code expects via the <tt>ddirectorout</tt> typemap (the <a href="D.html#D_dpcall"><tt>$dcall</tt> and <tt>$winput</tt></a> macros are replaced).</p>
|
||||
|
||||
<p>The full chain of type conversions when a director callback is invoked looks like this:</p>
|
||||
|
||||
<div class="diagram"><pre>
|
||||
type CPPClass::method(type a)
|
||||
↑ ↓
|
||||
<directorout> <directorin>
|
||||
↑ ↓
|
||||
ctype methodCallback(ctype a) C++
|
||||
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
|
||||
imtype methodCallback(imtype a) D
|
||||
↑ ↓
|
||||
<ddirectorout> <ddirectorin>
|
||||
↑ ↓
|
||||
dtype DClass.method(dtype a)</pre></div>
|
||||
|
||||
|
||||
<H3><a name="D_typecheck_typemaps"></a>21.3.5 typecheck typemaps</H3>
|
||||
|
||||
|
||||
<p>Because, unlike many scripting languages supported by SWIG, D does not need any dynamic dispatch helper to access an overloaded function, the purpose of these is merely to issue a warning for overloaded C++ functions that cannot be overloaded in D (as more than one C++ type maps to a single D type).</p>
|
||||
|
||||
|
||||
<H3><a name="D_code_injection_typemaps"></a>21.3.6 Code injection typemaps</H3>
|
||||
|
||||
|
||||
<p>These typemaps are used for generating the skeleton of proxy classes for C++ types.</p>
|
||||
|
||||
<p>By overriding <tt>dbase</tt>, <tt>dinterfaces</tt> or <tt>dinterfaces_derived</tt>, the inheritance chain of the generated proxy class for a type can be modified. <tt>dclassmodifiers</tt> allows you to add any custom modifiers around the class keyword.</p>
|
||||
|
||||
<p>Using <tt>dcode</tt> and <tt>dimports</tt>, you can specify additional D code which will be emitted into the class body respectively the imports section of the D module the class is written to.</p>
|
||||
|
||||
<p id="D_class_code_typemaps"><tt>dconstructor</tt>, <tt>ddestructor</tt>, <tt>ddispose</tt> and <tt>ddispose_derived</tt> are used to generate the class constructor, destructor and <tt>dispose()</tt> method, respectively. The auxiliary code for handling the pointer to the C++ object is stored in <tt>dbody</tt> and <tt>dbody_derived</tt>. You can override them for specific types.</p>
|
||||
|
||||
|
||||
<H3><a name="D_special_variables"></a>21.3.7 Special variable macros</H3>
|
||||
|
||||
|
||||
<p>The standard SWIG special variables are available for use within typemaps as described in the <a href="Typemaps.html#Typemaps">Typemaps documentation</a>, for example <tt>$1</tt>, <tt>$input</tt>, <tt>$result</tt> etc.</p>
|
||||
|
||||
<p>When generating D wrappers, a few additional macros are available:</p>
|
||||
<dl>
|
||||
<dt><tt>$dclassname</tt> (C#: <tt>$csclassname</tt>)</dt>
|
||||
<dd>
|
||||
<p>This special variable works similar to <a href="Typemaps.html#Typemaps_special_variables"><tt>$n_type</tt></a> in that it returns the name of a type - it expands to the D proxy class name of the type being wrapped. If the type does not have an associated proxy class, it expands to the type wrapper class name, for example, <tt>SWIGTYPE_p_p_SomeCppClass</tt> is generated when wrapping <tt>SomeCppClass **</tt>.</p>
|
||||
<p>There are two other variants available, <tt>$&dclassname</tt> and <tt>$*dclassname</tt>. The former adds a level of indirection, while the latter removes one. For instance, when wrapping <tt>Foo **</tt>, <tt>$*dclassname</tt> would be replaced by the proxy class name corresponding to <tt>Foo *</tt>.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>$dclazzname</tt> (C#: <tt>$csclazzname</tt>)</dt>
|
||||
<dd>
|
||||
<p>This special variable expands the fully qualified C++ class into the package name, if used by the <a href="SWIGPlus.html#SWIGPlus_nspace"><tt>nspace</tt> feature</a>, and the proxy class name, mangled for use as a function name. For example, <tt>Namespace1::Namespace2::Klass</tt> is expanded into <tt>Namespace1_Namespace2_Klass_</tt>.</p>
|
||||
<p>This special variable might be useful for calling certain functions in the wrapper layer (e.g. upcast wrappers) which are mangled like this.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>$null</tt></dt>
|
||||
<dd><p>In code inserted into the generated C/C++ wrapper functions, this variable is replaced by either <tt>0</tt> or nothing at all, depending on whether the function has a return value or not. It can be used to bail out early e.g. in case of errors (<tt>return $null;</tt>).</p></dd>
|
||||
|
||||
<dt id="D_dinput"><tt>$dinput</tt> (C#: <tt>$csinput</tt>)</dt>
|
||||
<dd>
|
||||
<p>This variable is used in <tt><a href="D.html#D_din">din</a></tt> typemaps and is replaced by the expression which is to be passed to C/C++.</p>
|
||||
<p>For example, this input</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(din) SomeClass * "SomeClass.getCPointer($dinput)"
|
||||
|
||||
%inline %{
|
||||
class SomeClass {};
|
||||
void foo(SomeClass *arg);
|
||||
%}</pre></div>
|
||||
<p>leads to the following D proxy code being generated:</p>
|
||||
<div class="targetlang"><pre>
|
||||
void foo(SomeClass arg) {
|
||||
example_im.foo(SomeClass.getCPointer(arg));
|
||||
}</pre></div></dd>
|
||||
|
||||
<dt id="D_imcall"><tt>$imcall</tt> and <tt>$owner</tt> (C#: <tt>$imcall</tt>)</dt>
|
||||
<dd>
|
||||
<p>These variables are used in <tt><a href="D.html#D_dout">dout</a></tt> typemaps. <tt>$imcall</tt> contains the call to the intermediary module which provides the value to be used, and <tt>$owner</tt> signals if the caller is responsible for managing the object lifetime (that is, if the called method is a constructor or has been marked via <tt>%newobject</tt>).</p>
|
||||
<p>Consider the following example:</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(dout) SomeClass * {
|
||||
return new SomeClass($imcall, $owner);
|
||||
}
|
||||
|
||||
%inline %{
|
||||
class SomeClass;
|
||||
SomeClass *foo();
|
||||
|
||||
%newobject bar();
|
||||
SomeClass *bar();
|
||||
%}</pre></div>
|
||||
<p>The code generated for <tt>foo()</tt> and <tt>bar()</tt> looks like this:</p>
|
||||
<div class="targetlang"><pre>
|
||||
SomeClass foo() {
|
||||
return new SomeClass(example_im.foo(), false);
|
||||
}
|
||||
|
||||
SomeClass bar() {
|
||||
return new SomeClass(example_im.bar(), true);
|
||||
}
|
||||
</pre></div>
|
||||
</dd>
|
||||
|
||||
<dt><tt>$dcall</tt> and <tt>$winput</tt> (C#: <tt>$cscall</tt>, <tt>$iminput</tt>)</dt>
|
||||
<dd id="D_dpcall"><p>These variables are used in the director-specific typemaps <a href="D.html#D_ddirectorinout"><tt>ddirectorin</tt></a> and <a href="D.html#D_ddirectorinout"><tt>ddirectorout</tt></a>. They are more or less the reverse of the <tt>$imcall</tt> and <tt>$dinput</tt> macros: <tt>$dcall</tt> contains the invocation of the D proxy method of which the return value is to be passed back to C++, <tt>$winput</tt> contains the parameter value from C++.</p></dd>
|
||||
|
||||
<dt><tt>$excode</tt></dt>
|
||||
<dd><p>This variable is used in <tt>dout</tt> and <tt>dconstructor</tt> typemaps and is filled with the contents of the <tt>excode</tt> typemap attribute if an exception could be thrown from the C++ side. See the <a href="CSharp.html#CSharp_exceptions">C# documentation</a> for details.</p></dd>
|
||||
|
||||
<dt><tt>$dbaseclass</tt></dt>
|
||||
<dd><p>Currently for internal use only, it contains the D name of the C++ base class (if any) inside proxy classes.</p></dd>
|
||||
|
||||
<dt><tt>$directorconnect</tt></dt>
|
||||
<dd>
|
||||
<p>This macro is only valid inside the <tt><a href="D.html#D_class_code_typemaps">dconstructor</a></tt> typemap and contains the value of the <tt>dconstructor</tt> typemap attribute if the currently wrapped class has directors enabled.</p>
|
||||
<p>This is how the default <tt>dconstructor</tt> typemap looks like (you usually do not want to specify a custom one):</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(dconstructor, excode=SWIGEXCODE,
|
||||
directorconnect="\n swigDirectorConnect();") SWIGTYPE {
|
||||
this($imcall, true);$excode$directorconnect
|
||||
}
|
||||
</pre></div>
|
||||
</dd>
|
||||
|
||||
<dt id="D_importtype"><tt>$importtype(SomeDType)</tt></dt>
|
||||
<dd>
|
||||
<p>This macro is used in the <tt>dimports</tt> typemap if a dependency on another D type generated by SWIG is added by a custom typemap.</p>
|
||||
<p>Consider the following code snippet:</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(dinterfaces) SomeClass "AnInterface, AnotherInterface";
|
||||
</pre></div>
|
||||
<p>This causes SWIG to add <tt>AnInterface</tt> and <tt>AnotherInterface</tt> to the base class list of <tt>SomeClass</tt>:</p>
|
||||
<div class="targetlang"><pre>
|
||||
class SomeClass : AnInterface, AnotherInterface {
|
||||
...
|
||||
}
|
||||
</pre></div>
|
||||
<p>For this to work, <tt>AnInterface</tt> and <tt>AnotherInterface</tt> have to be in scope. If SWIG is not in split proxy mode, this is already the case, but it it is, they have to be added to the import list via the <tt>dimports</tt> typemap. Additionally, the import statement depends on the package SWIG is configured to emit the modules to.</p>
|
||||
<p>The <tt>$importtype</tt> macro helps you to elegantly solve this problem:</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(dimports) RemoteMpe %{
|
||||
$importtype(AnInterface)
|
||||
$importtype(AnotherInterface)
|
||||
%}
|
||||
</pre></div>
|
||||
<p>If SWIG is in split proxy mode, it expands to an <tt>import</tt> statement for the specified type, to nothing if not.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>$module</tt></dt>
|
||||
<dd><p>Expands to the name of the main proxy D module.</p></dd>
|
||||
|
||||
<dt><tt>$imdmodule</tt></dt>
|
||||
<dd><p>Contains the fully qualified name of the intermediary D module.</p></dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_features"></a>21.4 <tt>%feature</tt>s</H2>
|
||||
|
||||
|
||||
<p>The D module defines a number of directives which modify the <a href="Customization.html#Customization_features">SWIG features</a> set globally or for a specific declaration:</p>
|
||||
|
||||
|
||||
<dl>
|
||||
<dt><tt>%dmanifestconst</tt> and <tt>%dconstvalue(value)</tt></dt>
|
||||
<dd>
|
||||
<p>Out of the box, SWIG generates accessor methods for C <tt>#defines</tt> and C++ constants. The <tt>%dmanifestconst</tt> directive enables wrapping these constants as D manifest constants (<tt>const</tt> in D1, <tt>enum</tt> in D2).</p>
|
||||
<p>For this to work, the C/C++ code for the constant value must directly compile as D code, though. If this is not the case, you can manually override the expression written to the D proxy module using the <tt>%dconstvalue</tt> directive, passing the new value as parameter.</p>
|
||||
<p>For <tt>enum</tt>s, again <tt>%dconstvalue</tt> can be used to override the value of an enum item if the initializer should not compile in D.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>%dmethodmodifiers</tt></dt>
|
||||
<dd>
|
||||
<p>This directive can be used to override the modifiers for a proxy function. For instance, you could make a <tt>public</tt> C++ member function <tt>private</tt> in D like this:</p>
|
||||
<div class="code"><pre>
|
||||
%dmethodmodifiers A::foo "private";
|
||||
|
||||
%inline %{
|
||||
struct A {
|
||||
void foo();
|
||||
};
|
||||
%}
|
||||
</pre></div>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_pragmas"></a>21.5 Pragmas</H2>
|
||||
|
||||
|
||||
<p>There are a few SWIG pragmas specific to the D module, which you can use to influence the D code SWIG generates:</p>
|
||||
|
||||
<dl>
|
||||
<dt><tt>%pragma(d) imdmodulecode</tt></dt>
|
||||
<dd><p>The passed text (D code) is copied verbatim to the intermediary D module. For example, it can be (and is, internally) used to emit additional private helper code for the use by proxy typemaps.</p></dd>
|
||||
|
||||
<dt><tt>%pragma(d) imdmoduleimports</tt></dt>
|
||||
<dd><p>Additional code to be emitted to the imports section of the intermediary D module (the <a href="D.html#D_importtype">$importtype</a> macro can be used here). You probably want to use this in conjunction with the <tt>imdmodulecode</tt> pragma.</p></dd>
|
||||
|
||||
<dt><tt>%pragma(d) proxydmodulecode</tt></dt>
|
||||
<dd><p>Just like <tt>proxydmodulecode</tt>, the argument is copied to the proxy D module (if SWIG is in <a href="D.html#D_splitproxy">split proxy mode</a> and/or the <tt>nspace</tt> feature is used, it is emitted to the main proxy D module only).</p></dd>
|
||||
|
||||
<dt><tt>%pragma(d) globalproxyimports</tt></dt>
|
||||
<dd>
|
||||
<p>The D module currently does not support specifying dependencies on external modules (e.g. from the standard library) for the D typemaps. To add the import statements to the proxy modules (resp. to <em>all</em> proxy modules if in split proxy mode), you can use the <tt>globalproxyimports</tt> directive.</p>
|
||||
<p>For example:</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(din) char[] "($dinput ? tango.stdc.stringz.toStringz($dinput) : null)"
|
||||
%pragma(d) globalproxyimports = "static import tango.stdc.stringz;";
|
||||
</pre></div>
|
||||
</dd>
|
||||
|
||||
<dt><tt>%pragma(d) wrapperloadercode</tt></dt>
|
||||
<dd>
|
||||
<p>The D code for loading the wrapper library (it is copied to the intermediary D module). The <tt>$wrapperloaderbindcode</tt> variable is replaced by the list of commands for binding the functions from the wrapper library to the symbols in the intermediary D module.</p>
|
||||
<p>Each time this pragma is specified, the previous value is overwritten.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>%pragma(d) wrapperloaderbindcommand</tt></dt>
|
||||
<dd>
|
||||
<p>The D command to use for binding the wrapper functions from the C/C++ library to the symbols in the intermediary D module. The <tt>$function</tt> variable contains the name of the D function in the wrap module, the <tt>$symbol</tt> variable is replaced by the name of the symbol in the library.</p>
|
||||
<p>Each time this pragma is specified, the previous value is overwritten.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_exceptions"></a>21.6 D Exceptions</H2>
|
||||
|
||||
|
||||
<p>Out of the box, C++ exceptions are fundamentally incompatible to their equivalent in the D world and cannot simply be propagated to a calling D method. There is, however, an easy way to solve this problem: Just catch the exception in the C/C++ wrapper layer, pass the contents to D, and make the wrapper code rethrow the exception in the D world.</p>
|
||||
|
||||
<p>The implementation details of this are a bit crude, but the SWIG D module automatically takes care of this, as long as it is able to detect that an exception could potentially be thrown (e.g. because the C++ method has a <tt>throw(...)</tt> exception specification).</p>
|
||||
|
||||
<p>As this feature is implemented in exactly the same way it is for C#, please see the <a href="CSharp.html#CSharp_exceptions">C# documentation</a> for a more detailed explanation.</p>
|
||||
|
||||
|
||||
<H2><a name="D_directors"></a>21.7 D Directors</H2>
|
||||
|
||||
|
||||
<p>When the directors feature is activated, SWIG generates extra code on both the C++ and the D side to enable cross-language polymorphism. Essentially, this means that if you subclass a proxy class in D, C++ code can access any overridden virtual methods just as if you created a derived class in C++.</p>
|
||||
|
||||
<p>There is no D specific documentation yet, but the way the feature is implemented is very similar to how it is done in <a href="Java.html#Java_directors">Java</a> and <a href="CSharp.html#CSharp_directors">C#</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<H2><a name="D_other_features"></a>21.8 Other features</H2>
|
||||
|
||||
|
||||
<H3><a name="D_nspace"></a>21.8.1 Extended namespace support (<tt>nspace</tt>)</H3>
|
||||
|
||||
|
||||
<p>By default, SWIG flattens all C++ namespaces into a single target language namespace, but as for Java and C#, the <a href="SWIGPlus.html#SWIGPlus_nspace"><tt>nspace</tt></a> feature is supported for D. If it is active, C++ namespaces are mapped to D packages/modules. Note, however, that like for the other languages, <em>free</em> variables and functions are not supported yet; currently, they are all allows written to the main proxy D module.</p>
|
||||
|
||||
|
||||
<H3><a name="D_native_pointer_support"></a>21.8.2 Native pointer support</H3>
|
||||
|
||||
|
||||
<p>Contrary to many of the scripting languages supported by SWIG, D fully supports C-style pointers. The D module thus includes a custom mechanism to wrap C pointers directly as D pointers where applicable, that is, if the type that is pointed to is represented the same in C and D (on the bit-level), dubbed a <em>primitive type</em> below.</p>
|
||||
|
||||
<p>Central to this custom pointer handling scheme are two typemap attributes: the <tt>cprimitive</tt> attribute on the <tt>dtype</tt> typemap and the <tt>nativepointer</tt> attribute on all the typemaps which influence the D side of the code (<tt>dtype</tt>, <tt>din</tt>, <tt>dout</tt>, ...). When a D typemap is looked up, the following happens behind the scenes:</p>
|
||||
|
||||
<p>First, the matching typemap is determined by the usual typemap lookup rules. Then, it is checked if the result has the <tt>nativepointer</tt> attribute set. If it is present, it means that its value should replace the typemap value <em>if and only if</em> the actual type the typemap is looked up for is a primitive type, a pointer to a primitive type (through an arbitrary level of indirections), or a function pointer with only primitive types in its signature.</p>
|
||||
|
||||
<p>To determine if a type should be considered primitive, the <tt>cprimitive</tt> attribute on its <tt>dtype</tt> attribute is used. For example, the <tt>dtype</tt> typemap for <tt>float</tt> has <tt>cprimitive="1"</tt>, so the code from the <tt>nativepointer</tt> attribute is taken into account e.g. for <tt>float **</tt> or the function pointer <tt>float (*)(float *)</tt>.</p>
|
||||
|
||||
|
||||
<H3><a name="D_operator_overloading"></a>21.8.3 Operator overloading</H3>
|
||||
|
||||
|
||||
<p>The D module comes with basic operator overloading support for both D1 and D2. There are, however, a few limitations arising from conceptual differences between C++ and D:</p>
|
||||
|
||||
<p>The first key difference is that C++ supports free functions as operators (along with argument-dependent lookup), while D requires operators to be member functions of the class they are operating on. SWIG can only automatically generate wrapping code for member function operators; if you want to use operators defined as free functions in D, you need to handle them manually.</p>
|
||||
|
||||
<p>Another set of differences between C++ and D concerns individual operators. For example, there are quite a few operators which are overloadable in C++, but not in D, for example <tt>&&</tt> and <tt>||</tt>, but also <tt>!</tt>, and prefix increment/decrement operators in <a href="http://www.digitalmars.com/d/1.0/operatoroverloading.html">D1</a> resp. their postfix pendants in <a href="http://www.digitalmars.com/d/2.0/operatoroverloading.html">D2</a>.</p>
|
||||
|
||||
<p>There are also some cases where the operators can be translated to D, but the differences in the implementation details are big enough that a rather involved scheme would be required for automatic wrapping them, which has not been implemented yet. This affects, for example, the array subscript operator, <tt>[]</tt>, in combination with assignments - while <tt>operator []</tt> in C++ simply returns a reference which is then written to, D resorts to a separate <tt>opIndexAssign</tt> method -, or implicit casting (which was introduced in D2 via <tt>alias this</tt>). Despite the lack of automatic support, manually handling these cases should be perfectly possible.</p>
|
||||
|
||||
|
||||
<H3><a name="D_test_suite"></a>21.8.4 Running the test-suite</H3>
|
||||
|
||||
|
||||
<p>As with any other language, the SWIG test-suite can be built for D using the <tt>*-d-test-suite</tt> targets of the top-level Makefile. By default, D1 is targeted, to build it with D2, use the optional <tt>D_VERSION</tt> variable, e.g. <tt>make check-d-test-suite D_VERSION=2</tt>.</p>
|
||||
|
||||
<p>Note: If you want to use GDC on Linux or another platform which requires you to link <tt>libdl</tt> for dynamically loading the shared library, you might have to add <tt>-ldl</tt> manually to the <tt>d_compile</tt> target in <tt>Examples/Makefile</tt>, because GDC does not currently honor the <tt>pragma(lib,...)</tt> statement.</p>
|
||||
|
||||
|
||||
<H2><a name="D_typemap_examples"></a>21.9 D Typemap examples</H2>
|
||||
|
||||
|
||||
<p>There are no D-specific typemap examples yet. However, with the above <a href="D.html#D_typemap_name_comparison">name comparison table</a>, you should be able to get an idea what can be done by looking at the <a href="CSharp.html#CSharp_typemap_examples">corresponding C# section</a>.</p>
|
||||
|
||||
|
||||
|
||||
<H2><a name="D_planned_features"></a>21.10 Work in progress and planned features</H2>
|
||||
|
||||
|
||||
<p>There are a couple of features which are not implemented yet, but would be very useful and might be added in the near future:</p>
|
||||
|
||||
<ul>
|
||||
<li><em>Static linking:</em> Currently, the C wrapper code is compiled into a dynamic library, out of which the symbol addresses are looked up at runtime by the D part. If statically linking the different languages into one binary was supported, a tool-chain capable of performing IPO at link time could inline the wrapping code, effectively reducing the overhead for simple calls to zero.</li>
|
||||
<li><em>C array handling:</em> Many data structures in some C/C++ libraries contain array containing of a pointer to the first element and the element count. Currently, one must manually writing wrapper code to be able to access these from D. It should be possible to add a set of SWIG macros to semi-automatically generate conversion code.</li>
|
||||
</ul>
|
||||
|
||||
<p>Some generated code might also be a bit rough around the edges, particularly in the following areas:</p>
|
||||
|
||||
<ul>
|
||||
<li><em>Memory management:</em> Although the currently generated wrapper code works fine with regard to the GC for the test-suite, there might be issues coming up in real-world multi-threaded usage.</li>
|
||||
<li><em>D2 support</em>: Originally, the module has been developed for the use with D1, D2/Phobos support has been added in later. The basic features should work equally well for both, but there <em>could</em> be issues concerning const-correctness etc.</li>
|
||||
</ul>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Extending"></a>36 Extending SWIG to support new languages</H1>
|
||||
<H1><a name="Extending"></a>38 Extending SWIG to support new languages</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -75,7 +75,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="Extending_nn2"></a>36.1 Introduction</H2>
|
||||
<H2><a name="Extending_nn2"></a>38.1 Introduction</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -91,7 +91,7 @@ Also, this chapter is not meant to be a hand-holding tutorial. As a starting po
|
|||
you should probably look at one of SWIG's existing modules.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn3"></a>36.2 Prerequisites</H2>
|
||||
<H2><a name="Extending_nn3"></a>38.2 Prerequisites</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -121,7 +121,7 @@ obvious, but almost all SWIG directives as well as the low-level generation of
|
|||
wrapper code are driven by C++ datatypes.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn4"></a>36.3 The Big Picture</H2>
|
||||
<H2><a name="Extending_nn4"></a>38.3 The Big Picture</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -158,7 +158,7 @@ role in making the system work. For example, both typemaps and declaration anno
|
|||
based on pattern matching and interact heavily with the underlying type system.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn5"></a>36.4 Execution Model</H2>
|
||||
<H2><a name="Extending_nn5"></a>38.4 Execution Model</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -203,7 +203,7 @@ latter stage of compilation.
|
|||
The next few sections briefly describe some of these stages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn6"></a>36.4.1 Preprocessing</H3>
|
||||
<H3><a name="Extending_nn6"></a>38.4.1 Preprocessing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -284,7 +284,7 @@ been expanded as well as everything else that goes into the low-level
|
|||
construction of the wrapper code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn7"></a>36.4.2 Parsing</H3>
|
||||
<H3><a name="Extending_nn7"></a>38.4.2 Parsing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -385,7 +385,7 @@ returning a <tt>foo</tt> and taking types <tt>a</tt> and <tt>b</tt> as
|
|||
arguments).
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn8"></a>36.4.3 Parse Trees</H3>
|
||||
<H3><a name="Extending_nn8"></a>38.4.3 Parse Trees</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -640,7 +640,7 @@ $ swig -c++ -python -debug-module 4 example.i
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn9"></a>36.4.4 Attribute namespaces</H3>
|
||||
<H3><a name="Extending_nn9"></a>38.4.4 Attribute namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -659,7 +659,7 @@ that matches the name of the target language. For example, <tt>python:foo</tt>
|
|||
<tt>perl:foo</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn10"></a>36.4.5 Symbol Tables</H3>
|
||||
<H3><a name="Extending_nn10"></a>38.4.5 Symbol Tables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -750,7 +750,7 @@ example.i:5. Previous declaration is foo_i(int )
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn11"></a>36.4.6 The %feature directive</H3>
|
||||
<H3><a name="Extending_nn11"></a>38.4.6 The %feature directive</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -806,7 +806,7 @@ For example, the exception code above is simply
|
|||
stored without any modifications.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn12"></a>36.4.7 Code Generation</H3>
|
||||
<H3><a name="Extending_nn12"></a>38.4.7 Code Generation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -928,7 +928,7 @@ public :
|
|||
The role of these functions is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn13"></a>36.4.8 SWIG and XML</H3>
|
||||
<H3><a name="Extending_nn13"></a>38.4.8 SWIG and XML</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -941,7 +941,7 @@ internal data structures, it may be useful to keep XML in the back of
|
|||
your mind as a model.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn14"></a>36.5 Primitive Data Structures</H2>
|
||||
<H2><a name="Extending_nn14"></a>38.5 Primitive Data Structures</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -987,7 +987,7 @@ typedef Hash Typetab;
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn15"></a>36.5.1 Strings</H3>
|
||||
<H3><a name="Extending_nn15"></a>38.5.1 Strings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1128,7 +1128,7 @@ Returns the number of replacements made (if any).
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn16"></a>36.5.2 Hashes</H3>
|
||||
<H3><a name="Extending_nn16"></a>38.5.2 Hashes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1205,7 +1205,7 @@ Returns the list of hash table keys.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn17"></a>36.5.3 Lists</H3>
|
||||
<H3><a name="Extending_nn17"></a>38.5.3 Lists</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1294,7 +1294,7 @@ If <tt>t</tt> is not a standard object, it is assumed to be a <tt>char *</tt>
|
|||
and is used to create a String object.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn18"></a>36.5.4 Common operations</H3>
|
||||
<H3><a name="Extending_nn18"></a>38.5.4 Common operations</H3>
|
||||
|
||||
|
||||
The following operations are applicable to all datatypes.
|
||||
|
|
@ -1349,7 +1349,7 @@ objects and report errors.
|
|||
Gets the line number associated with <tt>x</tt>.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn19"></a>36.5.5 Iterating over Lists and Hashes</H3>
|
||||
<H3><a name="Extending_nn19"></a>38.5.5 Iterating over Lists and Hashes</H3>
|
||||
|
||||
|
||||
To iterate over the elements of a list or a hash table, the following functions are used:
|
||||
|
|
@ -1394,7 +1394,7 @@ for (j = First(j); j.item; j= Next(j)) {
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn20"></a>36.5.6 I/O</H3>
|
||||
<H3><a name="Extending_nn20"></a>38.5.6 I/O</H3>
|
||||
|
||||
|
||||
Special I/O functions are used for all internal I/O. These operations
|
||||
|
|
@ -1531,7 +1531,7 @@ Similarly, the preprocessor and parser all operate on string-files.
|
|||
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn21"></a>36.6 Navigating and manipulating parse trees</H2>
|
||||
<H2><a name="Extending_nn21"></a>38.6 Navigating and manipulating parse trees</H2>
|
||||
|
||||
|
||||
Parse trees are built as collections of hash tables. Each node is a hash table in which
|
||||
|
|
@ -1665,7 +1665,7 @@ Deletes a node from the parse tree. Deletion reconnects siblings and properly u
|
|||
the parent so that sibling nodes are unaffected.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn22"></a>36.7 Working with attributes</H2>
|
||||
<H2><a name="Extending_nn22"></a>38.7 Working with attributes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1782,7 +1782,7 @@ the attribute is optional. <tt>Swig_restore()</tt> must always be called after
|
|||
function.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn23"></a>36.8 Type system</H2>
|
||||
<H2><a name="Extending_nn23"></a>38.8 Type system</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1791,7 +1791,7 @@ pointers, references, and pointers to members. A detailed discussion of
|
|||
type theory is impossible here. However, let's cover the highlights.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn24"></a>36.8.1 String encoding of types</H3>
|
||||
<H3><a name="Extending_nn24"></a>38.8.1 String encoding of types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1892,7 +1892,7 @@ make the final type, the two parts are just joined together using
|
|||
string concatenation.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn25"></a>36.8.2 Type construction</H3>
|
||||
<H3><a name="Extending_nn25"></a>38.8.2 Type construction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2061,7 +2061,7 @@ Returns the prefix of a type. For example, if <tt>ty</tt> is
|
|||
<tt>ty</tt> is unmodified.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn26"></a>36.8.3 Type tests</H3>
|
||||
<H3><a name="Extending_nn26"></a>38.8.3 Type tests</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2148,7 +2148,7 @@ Checks if <tt>ty</tt> is a varargs type.
|
|||
Checks if <tt>ty</tt> is a templatized type.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn27"></a>36.8.4 Typedef and inheritance</H3>
|
||||
<H3><a name="Extending_nn27"></a>38.8.4 Typedef and inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2250,7 +2250,7 @@ Fully reduces <tt>ty</tt> according to typedef rules. Resulting datatype
|
|||
will consist only of primitive typenames.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn28"></a>36.8.5 Lvalues</H3>
|
||||
<H3><a name="Extending_nn28"></a>38.8.5 Lvalues</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2287,7 +2287,7 @@ Literal y; // type = 'Literal', ltype='p.char'
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn29"></a>36.8.6 Output functions</H3>
|
||||
<H3><a name="Extending_nn29"></a>38.8.6 Output functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2349,7 +2349,7 @@ SWIG, but is most commonly associated with type-descriptor objects
|
|||
that appear in wrappers (e.g., <tt>SWIGTYPE_p_double</tt>).
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn30"></a>36.9 Parameters</H2>
|
||||
<H2><a name="Extending_nn30"></a>38.9 Parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2448,7 +2448,7 @@ included. Used to emit prototypes.
|
|||
Returns the number of required (non-optional) arguments in <tt>p</tt>.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn31"></a>36.10 Writing a Language Module</H2>
|
||||
<H2><a name="Extending_nn31"></a>38.10 Writing a Language Module</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2463,7 +2463,7 @@ describes the creation of a minimal Python module. You should be able to extra
|
|||
this to other languages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn32"></a>36.10.1 Execution model</H3>
|
||||
<H3><a name="Extending_nn32"></a>38.10.1 Execution model</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2473,7 +2473,7 @@ the parsing of command line options, all aspects of code generation are controll
|
|||
different methods of the <tt>Language</tt> that must be defined by your module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_starting_out"></a>36.10.2 Starting out</H3>
|
||||
<H3><a name="Extending_starting_out"></a>38.10.2 Starting out</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2581,7 +2581,7 @@ that activates your module. For example, <tt>swig -python foo.i</tt>. The
|
|||
messages from your new module should appear.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn34"></a>36.10.3 Command line options</H3>
|
||||
<H3><a name="Extending_nn34"></a>38.10.3 Command line options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2640,7 +2640,7 @@ to mark the option as valid. If you forget to do this, SWIG will terminate wit
|
|||
unrecognized command line option error.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn35"></a>36.10.4 Configuration and preprocessing</H3>
|
||||
<H3><a name="Extending_nn35"></a>38.10.4 Configuration and preprocessing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2689,7 +2689,7 @@ an implementation file <tt>python.cxx</tt> and a configuration file
|
|||
<tt>python.swg</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn36"></a>36.10.5 Entry point to code generation</H3>
|
||||
<H3><a name="Extending_nn36"></a>38.10.5 Entry point to code generation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2747,22 +2747,23 @@ int Python::top(Node *n) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn37"></a>36.10.6 Module I/O and wrapper skeleton</H3>
|
||||
<H3><a name="Extending_nn37"></a>38.10.6 Module I/O and wrapper skeleton</H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to mgossage -->
|
||||
|
||||
|
||||
<p>
|
||||
Within SWIG wrappers, there are four main sections. These are (in order)
|
||||
Within SWIG wrappers, there are five main sections. These are (in order)
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>runtime: This section has most of the common SWIG runtime code
|
||||
<li>header: This section holds declarations and inclusions from the .i file
|
||||
<li>wrapper: This section holds all the wrappering code
|
||||
<li>begin: This section is a placeholder for users to put code at the beginning of the C/C++ wrapper file.
|
||||
<li>runtime: This section has most of the common SWIG runtime code.
|
||||
<li>header: This section holds declarations and inclusions from the .i file.
|
||||
<li>wrapper: This section holds all the wrappering code.
|
||||
<li>init: This section holds the module initalisation function
|
||||
(the entry point for the interpreter)
|
||||
(the entry point for the interpreter).
|
||||
</ul>
|
||||
<p>
|
||||
Different parts of the SWIG code will fill different sections,
|
||||
|
|
@ -2895,7 +2896,7 @@ functionWrapper : void Shape_y_set(Shape *self,double y)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn38"></a>36.10.7 Low-level code generators</H3>
|
||||
<H3><a name="Extending_nn38"></a>38.10.7 Low-level code generators</H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to mgossage -->
|
||||
|
|
@ -2974,7 +2975,7 @@ There are a lot of issues to address.
|
|||
<div class="code">
|
||||
<pre>
|
||||
virtual int functionWrapper(Node *n) {
|
||||
/* get useful atributes */
|
||||
/* get useful attributes */
|
||||
String *name = Getattr(n,"sym:name");
|
||||
SwigType *type = Getattr(n,"type");
|
||||
ParmList *parms = Getattr(n,"parms");
|
||||
|
|
@ -3049,7 +3050,7 @@ but without the typemaps, there is still work to do.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Extending_configuration_files"></a>36.10.8 Configuration files</H3>
|
||||
<H3><a name="Extending_configuration_files"></a>38.10.8 Configuration files</H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to ttn -->
|
||||
|
|
@ -3193,7 +3194,7 @@ politely displays the ignoring language message.
|
|||
</dl>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn40"></a>36.10.9 Runtime support</H3>
|
||||
<H3><a name="Extending_nn40"></a>38.10.9 Runtime support</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3202,7 +3203,7 @@ Discuss the kinds of functions typically needed for SWIG runtime support (e.g.
|
|||
the SWIG files that implement those functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn41"></a>36.10.10 Standard library files</H3>
|
||||
<H3><a name="Extending_nn41"></a>38.10.10 Standard library files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3221,7 +3222,7 @@ The following are the minimum that are usually supported:
|
|||
Please copy these and modify for any new language.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn42"></a>36.10.11 User examples</H3>
|
||||
<H3><a name="Extending_nn42"></a>38.10.11 User examples</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3250,7 +3251,7 @@ during this process, see the section on <a href="#Extending_configuration_files"
|
|||
files</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_test_suite"></a>36.10.12 Test driven development and the test-suite</H3>
|
||||
<H3><a name="Extending_test_suite"></a>38.10.12 Test driven development and the test-suite</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3309,7 +3310,7 @@ It is therefore essential that the runtime tests are written in a manner that di
|
|||
but error/exception out with an error message on stderr on failure.
|
||||
</p>
|
||||
|
||||
<H4><a name="Extending_running_test_suite"></a>36.10.12.1 Running the test-suite</H4>
|
||||
<H4><a name="Extending_running_test_suite"></a>38.10.12.1 Running the test-suite</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3477,7 +3478,25 @@ A debugger can also be invoked easily on an individual test, for example gdb:
|
|||
make ret_by_value.ctest RUNTOOL="gdb --args"
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Extending_nn43"></a>36.10.13 Documentation</H3>
|
||||
<p>
|
||||
SWIG reads the <tt>SWIG_FEATURES</tt> environment variable to obtain options in addition to those passed on the command line.
|
||||
This is particularly useful as the entire test-suite or a particular testcase can be run customized by using additional
|
||||
arguments, for example the -O optimization flag can be added in, as shown below for the bash shell:
|
||||
</p>
|
||||
|
||||
<div class="shell"><pre>
|
||||
env SWIG_FEATURES=-O make check-python-test-suite
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The syntax for setting environment variables varies from one shell to the next, but it also works as shown in the example below, where some typemap debugging is added in:
|
||||
</p>
|
||||
|
||||
<div class="shell"><pre>
|
||||
make ret_by_value.ctest SWIG_FEATURES="-debug-tmsearch"
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Extending_nn43"></a>38.10.13 Documentation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3509,7 +3528,7 @@ Some topics that you'll want to be sure to address include:
|
|||
if available.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Extending_prerequisites"></a>36.10.14 Prerequisites for adding a new language module to the SWIG distribution</H3>
|
||||
<H3><a name="Extending_prerequisites"></a>38.10.14 Prerequisites for adding a new language module to the SWIG distribution</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3517,7 +3536,7 @@ If you wish for a new language module to be distributed with SWIG,
|
|||
which we encourage for all popular languages, there are a few requirements.
|
||||
While we appreciate that getting all aspects of a new language working
|
||||
won't happen at the outset, there are a set of minimum requirements before
|
||||
a module can be committed into the SVN repository for distribution with future
|
||||
a module can be committed into the official Github repository for distribution with future
|
||||
versions of SWIG. The following are really a summary of this whole section with
|
||||
details being outlined earlier on.
|
||||
</p>
|
||||
|
|
@ -3559,14 +3578,14 @@ details being outlined earlier on.
|
|||
</ol>
|
||||
|
||||
<p>
|
||||
Once accepted into SVN, development efforts should concentrate on
|
||||
Once accepted into the official Git repository, development efforts should concentrate on
|
||||
getting the entire test-suite to work with plenty of runtime tests.
|
||||
Runtime tests should be for existing testcases and new test cases
|
||||
should be added should there be an area not already covered by
|
||||
the existing tests.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_coding_style_guidelines"></a>36.10.15 Coding style guidelines</H3>
|
||||
<H3><a name="Extending_coding_style_guidelines"></a>38.10.15 Coding style guidelines</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3590,7 +3609,7 @@ The generated C/C++ code should also follow this style as close as possible. How
|
|||
should be avoided as unlike the SWIG developers, users will never have consistent tab settings.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_debugging_options"></a>36.11 Debugging Options</H2>
|
||||
<H2><a name="Extending_debugging_options"></a>38.11 Debugging Options</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3609,13 +3628,15 @@ There are various command line options which can aid debugging a SWIG interface
|
|||
-debug-top <n> - Display entire parse tree at stages 1-4, <n> is a csv list of stages
|
||||
-debug-typedef - Display information about the types and typedefs in the interface
|
||||
-debug-typemap - Display information for debugging typemaps
|
||||
-debug-tmsearch - Display typemap search debugging information
|
||||
-debug-tmused - Display typemaps used debugging information
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The complete list of command line options for SWIG are available by running <tt>swig -help</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn46"></a>36.12 Guide to parse tree nodes</H2>
|
||||
<H2><a name="Extending_nn46"></a>38.12 Guide to parse tree nodes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4023,7 +4044,7 @@ extern "X" { ... } declaration.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_further_info"></a>36.13 Further Development Information</H2>
|
||||
<H2><a name="Extending_further_info"></a>38.13 Further Development Information</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Go"></a>20 SWIG and Go</H1>
|
||||
<H1><a name="Go"></a>22 SWIG and Go</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -28,6 +28,8 @@
|
|||
<li><a href="#Go_templates">Go Templates</a>
|
||||
<li><a href="#Go_director_classes">Go Director Classes</a>
|
||||
<li><a href="#Go_primitive_type_mappings">Default Go primitive type mappings</a>
|
||||
<li><a href="#Go_output_arguments">Output arguments</a>
|
||||
<li><a href="#Go_adding_additional_code">Adding additional go code</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
|
|
@ -41,7 +43,7 @@ the Go programming language
|
|||
see <a href="http://golang.org/">golang.org</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Go_overview"></a>20.1 Overview</H2>
|
||||
<H2><a name="Go_overview"></a>22.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -65,7 +67,7 @@ checking and runtime library are not used with Go. This should be
|
|||
borne in mind when reading the rest of the SWIG documentation.
|
||||
</p>
|
||||
|
||||
<H2><a name="Go_running_swig"></a>20.2 Running SWIG with Go</H2>
|
||||
<H2><a name="Go_running_swig"></a>22.2 Running SWIG with Go</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -74,7 +76,7 @@ default SWIG will generate code for the gc compilers. To generate
|
|||
code for gccgo, you should also use the <tt>-gccgo</tt> option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_commandline"></a>20.2.1 Additional Commandline Options</H3>
|
||||
<H3><a name="Go_commandline"></a>22.2.1 Additional Commandline Options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -91,10 +93,22 @@ swig -go -help
|
|||
<th>Go specific options</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-intgo-type-size %lt;s%gt;</td>
|
||||
<td>Set the size for the Go type <tt>int</tt>. This controls the size
|
||||
that the C/C++ code expects to see. The %lt;s%gt; argument should
|
||||
be 32 or 64. This option is currently required during the
|
||||
transition from Go 1.0 to Go 1.1, as the size of <tt>int</tt> on
|
||||
64-bit x86 systems changes between those releases (from 32 bits to
|
||||
64 bits). In the future the option may become optional, and SWIG
|
||||
will assume that the size of <tt>int</tt> is the size of a C
|
||||
pointer.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-gccgo</td>
|
||||
<td>Generate code for gccgo. The default is to generate code for
|
||||
6g/8g/6g.</td>
|
||||
6g/8g/5g.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
|
@ -103,6 +117,15 @@ swig -go -help
|
|||
package name is the SWIG module name.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-soname %lt;name%gt;</td>
|
||||
<td>Set the runtime name of the shared library that the dynamic linker
|
||||
should include at runtime. The default is the package name with
|
||||
".so" appended. This is only used when generating code for
|
||||
6g/8g/5g; when using gccgo, the equivalent name will be taken from
|
||||
the <code>-soname</code> option passed to the linker.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-go-prefix <prefix></td>
|
||||
<td>When generating code for gccgo, set the prefix to use. This
|
||||
|
|
@ -118,7 +141,7 @@ swig -go -help
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Go_outputs"></a>20.2.2 Go Output Files</H3>
|
||||
<H3><a name="Go_outputs"></a>22.2.2 Go Output Files</H3>
|
||||
|
||||
|
||||
<p> When generating Go code, SWIG will generate the following
|
||||
|
|
@ -163,7 +186,7 @@ A typical command sequence would look like this:
|
|||
% 6l main.6
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Go_basic_tour"></a>20.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Go_basic_tour"></a>22.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -173,7 +196,7 @@ modifications have to occur. This section briefly covers the
|
|||
essential aspects of this wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_package"></a>20.3.1 Go Package Name</H3>
|
||||
<H3><a name="Go_package"></a>22.3.1 Go Package Name</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -183,7 +206,7 @@ directive. You may override this by using SWIG's <tt>-package</tt>
|
|||
command line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_names"></a>20.3.2 Go Names</H3>
|
||||
<H3><a name="Go_names"></a>22.3.2 Go Names</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -215,7 +238,7 @@ followed by that name, and the destructor will be
|
|||
named <tt>Delete</tt> followed by that name.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_constants"></a>20.3.3 Go Constants</H3>
|
||||
<H3><a name="Go_constants"></a>22.3.3 Go Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -223,7 +246,7 @@ C/C++ constants created via <tt>#define</tt> or the <tt>%constant</tt>
|
|||
directive become Go constants, declared with a <tt>const</tt>
|
||||
declaration.
|
||||
|
||||
<H3><a name="Go_enumerations"></a>20.3.4 Go Enumerations</H3>
|
||||
<H3><a name="Go_enumerations"></a>22.3.4 Go Enumerations</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -233,7 +256,7 @@ usual). The values of the enumeration will become variables in Go;
|
|||
code should avoid modifying those variables.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_classes"></a>20.3.5 Go Classes</H3>
|
||||
<H3><a name="Go_classes"></a>22.3.5 Go Classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -264,7 +287,7 @@ class.
|
|||
|
||||
<p>
|
||||
SWIG will represent static methods of C++ classes as ordinary Go
|
||||
functions. SWIG will use names like <tt>ClassName_MethodName</tt>.
|
||||
functions. SWIG will use names like <tt>ClassNameMethodName</tt>.
|
||||
SWIG will give static members getter and setter functions with names
|
||||
like <tt>GetClassName_VarName</tt>.
|
||||
</p>
|
||||
|
|
@ -280,7 +303,38 @@ to <tt>reinterpret_cast</tt>. This should only be used for very
|
|||
special cases, such as where C++ would use a <tt>dynamic_cast</tt>.
|
||||
</p>
|
||||
|
||||
<H4><a name="Go_class_inheritance"></a>20.3.5.1 Go Class Inheritance</H4>
|
||||
<p>Note that C++ pointers to compound objects are represented in go as objects
|
||||
themselves, not as go pointers. So, for example, if you wrap the following
|
||||
function:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
class MyClass {
|
||||
int MyMethod();
|
||||
static MyClass *MyFactoryFunction();
|
||||
};
|
||||
|
||||
</pre>
|
||||
</div>
|
||||
<p>You will get go code that looks like this:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
type MyClass interface {
|
||||
Swigcptr() uintptr
|
||||
SwigIsMyClass()
|
||||
MyMethod() int
|
||||
}
|
||||
|
||||
MyClassMyFactoryFunction() MyClass {
|
||||
// swig magic here
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
<p>Note that the factory function does not return a go pointer; it actually
|
||||
returns a go interface. If the returned pointer can be null, you can check
|
||||
for this by calling the Swigcptr() method.
|
||||
</p>
|
||||
|
||||
<H4><a name="Go_class_inheritance"></a>22.3.5.1 Go Class Inheritance</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -292,7 +346,7 @@ Doing the reverse will require an explicit type assertion, which will
|
|||
be checked dynamically.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_templates"></a>20.3.6 Go Templates</H3>
|
||||
<H3><a name="Go_templates"></a>22.3.6 Go Templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -300,7 +354,7 @@ In order to use C++ templates in Go, you must tell SWIG to create
|
|||
wrappers for a particular template instantation. To do this, use
|
||||
the <tt>%template</tt> directive.
|
||||
|
||||
<H3><a name="Go_director_classes"></a>20.3.7 Go Director Classes</H3>
|
||||
<H3><a name="Go_director_classes"></a>22.3.7 Go Director Classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -343,7 +397,7 @@ method defined in Go. The Go code may of course call other methods on
|
|||
itself, and those methods may be defined either in Go or in C++.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_primitive_type_mappings"></a>20.3.8 Default Go primitive type mappings</H3>
|
||||
<H3><a name="Go_primitive_type_mappings"></a>22.3.8 Default Go primitive type mappings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -450,5 +504,131 @@ that typemap, or add new values, to control how C/C++ types are mapped
|
|||
into Go types.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_output_arguments"></a>22.3.9 Output arguments</H3>
|
||||
|
||||
|
||||
<p>Because of limitations in the way output arguments are processed in swig,
|
||||
a function with output arguments will not have multiple return values.
|
||||
Instead, you must pass a pointer into the C++ function to tell it where to
|
||||
store the output value. In go, you supply a slice in the place of the output
|
||||
argument.</p>
|
||||
|
||||
<p>For example, suppose you were trying to wrap the modf() function in the
|
||||
C math library which splits x into integral and fractional parts (and
|
||||
returns the integer part in one of its parameters):</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
double modf(double x, double *ip);
|
||||
</pre>
|
||||
</div>
|
||||
<p>You could wrap it with SWIG as follows:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%include <typemaps.i>
|
||||
double modf(double x, double *OUTPUT);
|
||||
</pre>
|
||||
</div>
|
||||
<p>or you can use the <code>%apply</code> directive:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%include <typemaps.i>
|
||||
%apply double *OUTPUT { double *ip };
|
||||
double modf(double x, double *ip);
|
||||
</pre>
|
||||
</div>
|
||||
<p>In Go you would use it like this:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
ptr := []float64{0.0}
|
||||
fraction := modulename.Modf(5.0, ptr)
|
||||
</pre>
|
||||
</div>
|
||||
<p>Since this is ugly, you may want to wrap the swig-generated API with
|
||||
some <a href="#Embedded_go_code">additional functions written in go</a> that
|
||||
hide the ugly details.</p>
|
||||
|
||||
<p>There are no <code>char *OUTPUT</code> typemaps. However you can
|
||||
apply the <code>signed char *</code> typemaps instead:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%include <typemaps.i>
|
||||
%apply signed char *OUTPUT {char *output};
|
||||
void f(char *output);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Go_adding_additional_code"></a>22.3.10 Adding additional go code</H3>
|
||||
|
||||
|
||||
<p>Often the APIs generated by swig are not very natural in go, especially if
|
||||
there are output arguments. You can
|
||||
insert additional go wrapping code to add new APIs
|
||||
with <code>%insert(go_wrapper)</code>, like this:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%include <typemaps.i>
|
||||
// Change name of what swig generates to Wrapped_modf. This function will
|
||||
// have the following signature in go:
|
||||
// func Wrapped_modf(float64, []float64) float64
|
||||
%rename(wrapped_modf) modf(double x, double *ip);
|
||||
|
||||
%apply double *OUTPUT { double *ip };
|
||||
double modf(double x, double *ip);
|
||||
|
||||
%insert(go_wrapper) %{
|
||||
|
||||
// The improved go interface to this function, which has two return values,
|
||||
// in the more natural go idiom:
|
||||
func Modf(x float64) (fracPart float64, intPart float64) {
|
||||
ip := []float64{0.0}
|
||||
fracPart = Wrapped_modf(x, ip)
|
||||
intPart = ip[0]
|
||||
return
|
||||
}
|
||||
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>For classes, since swig generates an interface, you can add additional
|
||||
methods by defining another interface that includes the swig-generated
|
||||
interface. For example,</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename(Wrapped_MyClass) MyClass;
|
||||
%rename(Wrapped_GetAValue) MyClass::GetAValue(int *x);
|
||||
%apply int *OUTPUT { int *x };
|
||||
|
||||
class MyClass {
|
||||
public:
|
||||
MyClass();
|
||||
int AFineMethod(const char *arg); // Swig's wrapping is fine for this one.
|
||||
bool GetAValue(int *x);
|
||||
};
|
||||
|
||||
%insert(go_wrapper) %{
|
||||
|
||||
type MyClass interface {
|
||||
Wrapped_MyClass
|
||||
GetAValue() (int, bool)
|
||||
}
|
||||
|
||||
func (arg SwigcptrWrapped_MyClass) GetAValue() (int, bool) {
|
||||
ip := []int{0}
|
||||
ok := arg.Wrapped_GetAValue(ip)
|
||||
return ip[0], ok
|
||||
}
|
||||
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
<p>Of course, if you have to rewrite most of the methods, instead of just a
|
||||
few, then you might as well define your own struct that includes the
|
||||
swig-wrapped object, instead of adding methods to the swig-generated object.</p>
|
||||
|
||||
<p>This only works if your wrappers do not need to import other go modules.
|
||||
There is at present no way to insert import statements in the correct place
|
||||
in swig-generated go. If you need to do that, you must put your go code
|
||||
in a separate file.</p>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Guile"></a>21 SWIG and Guile</H1>
|
||||
<H1><a name="Guile"></a>23 SWIG and Guile</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -47,7 +47,7 @@
|
|||
<p>
|
||||
This section details guile-specific support in SWIG.
|
||||
|
||||
<H2><a name="Guile_nn2"></a>21.1 Meaning of "Module"</H2>
|
||||
<H2><a name="Guile_nn2"></a>23.1 Meaning of "Module"</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -55,7 +55,7 @@ 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".
|
||||
|
||||
<H2><a name="Guile_nn3"></a>21.2 Using the SCM or GH Guile API</H2>
|
||||
<H2><a name="Guile_nn3"></a>23.2 Using the SCM or GH Guile API</H2>
|
||||
|
||||
|
||||
<p>The guile module can currently export wrapper files that use the guile GH interface or the
|
||||
|
|
@ -103,7 +103,7 @@ for the specific API. Currently only the guile language module has created a ma
|
|||
but there is no reason other languages (like mzscheme or chicken) couldn't also use this.
|
||||
If that happens, there is A LOT less code duplication in the standard typemaps.</p>
|
||||
|
||||
<H2><a name="Guile_nn4"></a>21.3 Linkage</H2>
|
||||
<H2><a name="Guile_nn4"></a>23.3 Linkage</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -111,7 +111,7 @@ 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>.
|
||||
|
||||
<H3><a name="Guile_nn5"></a>21.3.1 Simple Linkage</H3>
|
||||
<H3><a name="Guile_nn5"></a>23.3.1 Simple Linkage</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -206,7 +206,7 @@ placed between the <code>define-module</code> form and the
|
|||
<code>SWIG_init</code> via a preprocessor define to avoid symbol
|
||||
clashes. For this case, however, passive linkage is available.
|
||||
|
||||
<H3><a name="Guile_nn6"></a>21.3.2 Passive Linkage</H3>
|
||||
<H3><a name="Guile_nn6"></a>23.3.2 Passive Linkage</H3>
|
||||
|
||||
|
||||
<p>Passive linkage is just like simple linkage, but it generates an
|
||||
|
|
@ -216,7 +216,7 @@ package name (see below).
|
|||
<p>You should use passive linkage rather than simple linkage when you
|
||||
are using multiple modules.
|
||||
|
||||
<H3><a name="Guile_nn7"></a>21.3.3 Native Guile Module Linkage</H3>
|
||||
<H3><a name="Guile_nn7"></a>23.3.3 Native Guile Module Linkage</H3>
|
||||
|
||||
|
||||
<p>SWIG can also generate wrapper code that does all the Guile module
|
||||
|
|
@ -257,7 +257,7 @@ Newer Guile versions have a shorthand procedure for this:
|
|||
</div>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Guile_nn8"></a>21.3.4 Old Auto-Loading Guile Module Linkage</H3>
|
||||
<H3><a name="Guile_nn8"></a>23.3.4 Old Auto-Loading Guile Module Linkage</H3>
|
||||
|
||||
|
||||
<p>Guile used to support an autoloading facility for object-code
|
||||
|
|
@ -283,7 +283,7 @@ option, SWIG generates an exported module initialization function with
|
|||
an appropriate name.
|
||||
|
||||
|
||||
<H3><a name="Guile_nn9"></a>21.3.5 Hobbit4D Linkage</H3>
|
||||
<H3><a name="Guile_nn9"></a>23.3.5 Hobbit4D Linkage</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -308,7 +308,7 @@ my/lib/libfoo.so.X.Y.Z and friends. This scheme is still very
|
|||
experimental; the (hobbit4d link) conventions are not well understood.
|
||||
</p>
|
||||
|
||||
<H2><a name="Guile_nn10"></a>21.4 Underscore Folding</H2>
|
||||
<H2><a name="Guile_nn10"></a>23.4 Underscore Folding</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -320,7 +320,7 @@ complained so far.
|
|||
<code>%rename</code> to specify the Guile name of the wrapped
|
||||
functions and variables (see CHANGES).
|
||||
|
||||
<H2><a name="Guile_nn11"></a>21.5 Typemaps</H2>
|
||||
<H2><a name="Guile_nn11"></a>23.5 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -412,7 +412,7 @@ constant will appear as a scheme variable. See
|
|||
<a href="Customization.html#Customization_features">Features and the %feature directive</a>
|
||||
for info on how to apply the %feature.</p>
|
||||
|
||||
<H2><a name="Guile_nn12"></a>21.6 Representation of pointers as smobs</H2>
|
||||
<H2><a name="Guile_nn12"></a>23.6 Representation of pointers as smobs</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -429,11 +429,11 @@ upper half of the CAR is read from this struct.
|
|||
To get the pointer represented by a smob, the wrapper code calls the
|
||||
function <code>SWIG_ConvertPtr()</code>, passing a pointer to a struct
|
||||
representing the expected pointer type. See also
|
||||
<a href="Typemaps.html#runtime_type_checker">The run-time type checker</a>.
|
||||
<a href="Typemaps.html#Typemaps_runtime_type_checker">The run-time type checker</a>.
|
||||
If the Scheme object passed was not a SWIG smob representing a compatible
|
||||
pointer, a <code>wrong-type-arg</code> exception is raised.
|
||||
|
||||
<H3><a name="Guile_nn13"></a>21.6.1 GH Smobs</H3>
|
||||
<H3><a name="Guile_nn13"></a>23.6.1 GH Smobs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -462,7 +462,7 @@ that created them, so the first module we check will most likely be correct.
|
|||
Once we have a swig_type_info structure, we loop through the linked list of
|
||||
casts, using pointer comparisons.</p>
|
||||
|
||||
<H3><a name="Guile_nn14"></a>21.6.2 SCM Smobs</H3>
|
||||
<H3><a name="Guile_nn14"></a>23.6.2 SCM Smobs</H3>
|
||||
|
||||
|
||||
<p>The SCM interface (using the "-scm" argument to swig) uses swigrun.swg.
|
||||
|
|
@ -477,7 +477,7 @@ in the smob tag. If a generated GOOPS module has been loaded, smobs will be wra
|
|||
GOOPS class.</p>
|
||||
|
||||
|
||||
<H3><a name="Guile_nn15"></a>21.6.3 Garbage Collection</H3>
|
||||
<H3><a name="Guile_nn15"></a>23.6.3 Garbage Collection</H3>
|
||||
|
||||
|
||||
<p>Garbage collection is a feature of the new SCM interface, and it is automatically included
|
||||
|
|
@ -491,7 +491,7 @@ is exactly like described in <a href="Customization.html#Customization_ownership
|
|||
Object ownership and %newobject</a> in the SWIG manual. All typemaps use an $owner var, and
|
||||
the guile module replaces $owner with 0 or 1 depending on feature:new.</p>
|
||||
|
||||
<H2><a name="Guile_nn16"></a>21.7 Exception Handling</H2>
|
||||
<H2><a name="Guile_nn16"></a>23.7 Exception Handling</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -517,7 +517,7 @@ mapping:
|
|||
The default when not specified here is to use "swig-error".
|
||||
See Lib/exception.i for details.
|
||||
|
||||
<H2><a name="Guile_nn17"></a>21.8 Procedure documentation</H2>
|
||||
<H2><a name="Guile_nn17"></a>23.8 Procedure documentation</H2>
|
||||
|
||||
|
||||
<p>If invoked with the command-line option <code>-procdoc
|
||||
|
|
@ -553,7 +553,7 @@ like this:
|
|||
typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
|
||||
details.
|
||||
|
||||
<H2><a name="Guile_nn18"></a>21.9 Procedures with setters</H2>
|
||||
<H2><a name="Guile_nn18"></a>23.9 Procedures with setters</H2>
|
||||
|
||||
|
||||
<p>For global variables, SWIG creates a single wrapper procedure
|
||||
|
|
@ -581,7 +581,7 @@ struct members, the procedures <code>(<var>struct</var>-<var>member</var>-get
|
|||
pointer)</code> and <code>(<var>struct-member</var>-set pointer
|
||||
value)</code> are <em>not</em> generated.
|
||||
|
||||
<H2><a name="Guile_nn19"></a>21.10 GOOPS Proxy Classes</H2>
|
||||
<H2><a name="Guile_nn19"></a>23.10 GOOPS Proxy Classes</H2>
|
||||
|
||||
|
||||
<p>SWIG can also generate classes and generic functions for use with
|
||||
|
|
@ -730,7 +730,7 @@ Notice that <Foo> is used before it is defined. The fix is to just put th
|
|||
<code>%import "foo.h"</code> before the <code>%inline</code> block.
|
||||
</p>
|
||||
|
||||
<H3><a name="Guile_nn20"></a>21.10.1 Naming Issues</H3>
|
||||
<H3><a name="Guile_nn20"></a>23.10.1 Naming Issues</H3>
|
||||
|
||||
|
||||
<p>As you can see in the example above, there are potential naming conflicts. The default exported
|
||||
|
|
@ -767,7 +767,7 @@ guile-modules. For example,</p>
|
|||
(use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:)))
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Guile_nn21"></a>21.10.2 Linking</H3>
|
||||
<H3><a name="Guile_nn21"></a>23.10.2 Linking</H3>
|
||||
|
||||
|
||||
<p>The guile-modules generated above all need to be linked together. GOOPS support requires
|
||||
|
|
|
|||
|
|
@ -195,9 +195,9 @@ extern int my_mod(int n, int m);
|
|||
<p>
|
||||
The interface file contains ANSI C function prototypes and variable
|
||||
declarations. The <tt>%module</tt> directive defines the name of the
|
||||
module that will be created by SWIG. The <tt>%{,%}</tt> block
|
||||
provides a location for inserting additional code such as C header
|
||||
files or additional C declarations.
|
||||
module that will be created by SWIG. The <tt>%{ %}</tt> block
|
||||
provides a location for inserting additional code, such as C header
|
||||
files or additional C declarations, into the generated C wrapper code.
|
||||
|
||||
<H3><a name="Introduction_nn6"></a>2.3.2 The swig command</H3>
|
||||
|
||||
|
|
@ -372,9 +372,9 @@ Microsoft Visual Studio.
|
|||
|
||||
<p>
|
||||
If you are using the GNU Autotools
|
||||
(<a href="http://www.gnu.org/software/autoconf">Autoconf</a>/
|
||||
<a href="http://www.gnu.org/software/automake">Automake</a>/
|
||||
<a href="http://www.gnu.org/software/libtool">Libtool</a>)
|
||||
(<a href="http://www.gnu.org/software/autoconf/">Autoconf</a>/
|
||||
<a href="http://www.gnu.org/software/automake/">Automake</a>/
|
||||
<a href="http://www.gnu.org/software/libtool/">Libtool</a>)
|
||||
to configure SWIG use in your project, the SWIG Autoconf macros can be used.
|
||||
The primary macro is <tt>ax_pkg_swig</tt>, see
|
||||
<a href="http://www.gnu.org/software/autoconf-archive/ax_pkg_swig.html#ax_pkg_swig">http://www.gnu.org/software/autoconf-archive/ax_pkg_swig.html#ax_pkg_swig</a>.
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -66,18 +66,19 @@ Library files are included using the <tt>%include</tt> directive.
|
|||
When searching for files, directories are searched in the following order:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<ol>
|
||||
<li>The current directory
|
||||
<li>Directories specified with the <tt>-I</tt> command line option
|
||||
<li>.<tt>/swig_lib</tt>
|
||||
<li>SWIG library install location as reported by <tt>swig -swiglib</tt>, for example <tt>/usr/local/share/swig/1.3.30</tt>
|
||||
<li>On Windows, a directory <tt>Lib</tt> relative to the location of <tt>swig.exe</tt> is also searched.
|
||||
</ul>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
Within each directory, SWIG first looks for a subdirectory corresponding to a target language (e.g., <tt>python</tt>,
|
||||
<tt>tcl</tt>, etc.). If found, SWIG will search the language specific directory first. This allows
|
||||
for language-specific implementations of library files.
|
||||
Within directories mentioned in points 3-5, SWIG first looks for a subdirectory
|
||||
corresponding to a target language (e.g., <tt>python</tt>, <tt>tcl</tt>, etc.).
|
||||
If found, SWIG will search the language specific directory first. This allows
|
||||
for language-specific implementations of library files.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -682,8 +683,12 @@ pointer.
|
|||
|
||||
<div class="indent"><p>
|
||||
Copies all of the string data in <tt>s</tt> into the memory pointed to by
|
||||
<tt>ptr</tt>. The string may contain embedded NULL bytes. The length of
|
||||
the string is implicitly determined in the underlying wrapper code.
|
||||
<tt>ptr</tt>. The string may contain embedded NULL bytes.
|
||||
This is actually a wrapper to the standard C library <tt>memmove</tt> function, which is
|
||||
declared as
|
||||
<b><tt>void memmove(void *ptr, const void *src, size_t n)</tt></b>.
|
||||
The <tt>src</tt> and length <tt>n</tt> parameters are
|
||||
extracted from the language specific string <tt>s</tt> in the underlying wrapper code.
|
||||
</p></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -824,20 +829,20 @@ If you have a function that expects binary data,
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
int parity(char *str, int len, int initial);
|
||||
size_t parity(char *str, size_t len, size_t initial);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
you can wrap the parameters <tt>(char *str, int len)</tt> as a single
|
||||
you can wrap the parameters <tt>(char *str, size_t len)</tt> as a single
|
||||
argument using a typemap. Just do this:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%apply (char *STRING, int LENGTH) { (char *str, int len) };
|
||||
%apply (char *STRING, size_t LENGTH) { (char *str, size_t len) };
|
||||
...
|
||||
int parity(char *str, int len, int initial);
|
||||
size_t parity(char *str, size_t len, size_t initial);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -854,6 +859,7 @@ Now, in the target language, you can use binary string data like this:
|
|||
|
||||
<p>
|
||||
In the wrapper function, the passed string will be expanded to a pointer and length parameter.
|
||||
The <tt>(char *STRING, int LENGTH)</tt> multi-argument typemap is also available in addition to <tt>(char *STRING, size_t LENGTH)</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_nn11"></a>8.3.3 Using %newobject to release memory</H3>
|
||||
|
|
@ -1801,19 +1807,6 @@ struct DerivedIntValue : IntValue {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Note that if the <tt>%shared_ptr</tt> macro is omitted for any class in the inheritance hierarchy, it will
|
||||
result in a C++ compiler error.
|
||||
For example if the above <tt>%shared_ptr(DerivedIntValue)</tt> is omitted, the following is typical of the compiler error that will result:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
example_wrap.cxx: In function 'void Java_exampleJNI_delete_1DerivedIntValue(JNIEnv*, _jclass*, jlong)':
|
||||
example_wrap.cxx:3169: error: 'smartarg1' was not declared in this scope
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
A shared_ptr of the derived class can now be passed to a method where the base is expected in the target language, just as it can in C++:
|
||||
</p>
|
||||
|
|
@ -1826,6 +1819,61 @@ int val4 = example.extractValueSmart(div);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
If the <tt>%shared_ptr</tt> macro is omitted for any class in the inheritance hierarchy, SWIG will warn about this and the generated code may or may not result in a C++ compilation error.
|
||||
For example, the following input:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%include "boost_shared_ptr.i"
|
||||
%shared_ptr(Parent);
|
||||
|
||||
%inline %{
|
||||
#include <boost/shared_ptr.hpp>
|
||||
struct GrandParent {
|
||||
virtual ~GrandParent() {}
|
||||
};
|
||||
|
||||
struct Parent : GrandParent {
|
||||
virtual ~Parent() {}
|
||||
};
|
||||
|
||||
struct Child : Parent {
|
||||
virtual ~Child() {}
|
||||
};
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
warns about the missing smart pointer information:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
example.i:12: Warning 520: Base class 'GrandParent' of 'Parent' is not similarly marked as a smart pointer.
|
||||
example.i:16: Warning 520: Derived class 'Child' of 'Parent' is not similarly marked as a smart pointer.
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Adding the missing <tt>%shared_ptr</tt> macros will fix this:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%include "boost_shared_ptr.i"
|
||||
%shared_ptr(GrandParent);
|
||||
%shared_ptr(Parent);
|
||||
%shared_ptr(Child);
|
||||
|
||||
... as before ...
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<b>Note:</b> There is currently no support for <tt>%shared_ptr</tt> and the director feature.
|
||||
|
||||
<H2><a name="Library_nn16"></a>8.5 Utility Libraries</H2>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Lisp"></a>23 SWIG and Common Lisp</H1>
|
||||
<H1><a name="Lisp"></a>25 SWIG and Common Lisp</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -41,7 +41,7 @@
|
|||
Lisp, Common Foreign Function Interface(CFFI), CLisp and UFFI
|
||||
foreign function interfaces.
|
||||
</p>
|
||||
<H2><a name="Lisp_nn2"></a>23.1 Allegro Common Lisp</H2>
|
||||
<H2><a name="Lisp_nn2"></a>25.1 Allegro Common Lisp</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -50,7 +50,7 @@
|
|||
<a href="Allegrocl.html#Allegrocl">here</a>
|
||||
</p>
|
||||
|
||||
<H2><a name="Lisp_nn3"></a>23.2 Common Foreign Function Interface(CFFI)</H2>
|
||||
<H2><a name="Lisp_nn3"></a>25.2 Common Foreign Function Interface(CFFI)</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -77,7 +77,7 @@ swig -cffi -module <i>module-name</i> <i>file-name</i>
|
|||
files and the various things which you can do with them.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lisp_nn4"></a>23.2.1 Additional Commandline Options </H3>
|
||||
<H3><a name="Lisp_nn4"></a>25.2.1 Additional Commandline Options </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -118,7 +118,7 @@ swig -cffi -help
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lisp_nn5"></a>23.2.2 Generating CFFI bindings</H3>
|
||||
<H3><a name="Lisp_nn5"></a>25.2.2 Generating CFFI bindings</H3>
|
||||
|
||||
|
||||
As we mentioned earlier the ideal way to use SWIG is to use interface
|
||||
|
|
@ -392,7 +392,7 @@ The feature <i>intern_function</i> ensures that all C names are
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lisp_nn6"></a>23.2.3 Generating CFFI bindings for C++ code</H3>
|
||||
<H3><a name="Lisp_nn6"></a>25.2.3 Generating CFFI bindings for C++ code</H3>
|
||||
|
||||
|
||||
<p>This feature to SWIG (for CFFI) is very new and still far from
|
||||
|
|
@ -568,7 +568,7 @@ If you have any questions, suggestions, patches, etc., related to CFFI
|
|||
module feel free to contact us on the SWIG mailing list, and
|
||||
also please add a "[CFFI]" tag in the subject line.
|
||||
|
||||
<H3><a name="Lisp_nn7"></a>23.2.4 Inserting user code into generated files</H3>
|
||||
<H3><a name="Lisp_nn7"></a>25.2.4 Inserting user code into generated files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -608,7 +608,7 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Lisp_nn8"></a>23.3 CLISP</H2>
|
||||
<H2><a name="Lisp_nn8"></a>25.3 CLISP</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -638,7 +638,7 @@ swig -clisp -module <i>module-name</i> <i>file-name</i>
|
|||
interface file for the CLISP module. The CLISP module tries to
|
||||
produce code which is both human readable and easily modifyable.
|
||||
</p>
|
||||
<H3><a name="Lisp_nn9"></a>23.3.1 Additional Commandline Options </H3>
|
||||
<H3><a name="Lisp_nn9"></a>25.3.1 Additional Commandline Options </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -671,7 +671,7 @@ and global variables will be created otherwise only definitions for<br/>
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lisp_nn10"></a>23.3.2 Details on CLISP bindings</H3>
|
||||
<H3><a name="Lisp_nn10"></a>25.3.2 Details on CLISP bindings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -795,7 +795,7 @@ struct bar {
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lisp_nn11"></a>23.4 UFFI </H2>
|
||||
<H2><a name="Lisp_nn11"></a>25.4 UFFI </H2>
|
||||
|
||||
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -6,13 +6,14 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Lua"></a>24 SWIG and Lua</H1>
|
||||
<H1><a name="Lua"></a>26 SWIG and Lua</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#Lua_nn2">Preliminaries</a>
|
||||
<li><a href="#Lua_nn3">Running SWIG</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_commandline">Additional command line options</a>
|
||||
<li><a href="#Lua_nn4">Compiling and Linking and Interpreter</a>
|
||||
<li><a href="#Lua_nn5">Compiling a dynamic module</a>
|
||||
<li><a href="#Lua_nn6">Using your module</a>
|
||||
|
|
@ -31,32 +32,33 @@
|
|||
<li><a href="#Lua_nn17">C++ overloaded functions</a>
|
||||
<li><a href="#Lua_nn18">C++ operators</a>
|
||||
<li><a href="#Lua_nn19">Class extension with %extend</a>
|
||||
<li><a href="#Lua_nn20">C++ templates</a>
|
||||
<li><a href="#Lua_nn21">C++ Smart Pointers</a>
|
||||
<li><a href="#Lua_nn22">C++ Exceptions</a>
|
||||
<li><a href="#Lua_nn20">Using %newobject to release memory</a>
|
||||
<li><a href="#Lua_nn21">C++ templates</a>
|
||||
<li><a href="#Lua_nn22">C++ Smart Pointers</a>
|
||||
<li><a href="#Lua_nn23">C++ Exceptions</a>
|
||||
</ul>
|
||||
<li><a href="#Lua_nn23">Typemaps</a>
|
||||
<li><a href="#Lua_nn24">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_nn24">What is a typemap?</a>
|
||||
<li><a href="#Lua_nn25">Using typemaps</a>
|
||||
<li><a href="#Lua_nn26">Typemaps and arrays</a>
|
||||
<li><a href="#Lua_nn27">Typemaps and pointer-pointer functions</a>
|
||||
<li><a href="#Lua_nn25">What is a typemap?</a>
|
||||
<li><a href="#Lua_nn26">Using typemaps</a>
|
||||
<li><a href="#Lua_nn27">Typemaps and arrays</a>
|
||||
<li><a href="#Lua_nn28">Typemaps and pointer-pointer functions</a>
|
||||
</ul>
|
||||
<li><a href="#Lua_nn28">Writing typemaps</a>
|
||||
<li><a href="#Lua_nn29">Writing typemaps</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_nn29">Typemaps you can write</a>
|
||||
<li><a href="#Lua_nn30">SWIG's Lua-C API</a>
|
||||
<li><a href="#Lua_nn30">Typemaps you can write</a>
|
||||
<li><a href="#Lua_nn31">SWIG's Lua-C API</a>
|
||||
</ul>
|
||||
<li><a href="#Lua_nn31">Customization of your Bindings</a>
|
||||
<li><a href="#Lua_nn32">Customization of your Bindings</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_nn32">Writing your own custom wrappers</a>
|
||||
<li><a href="#Lua_nn33">Adding additional Lua code</a>
|
||||
<li><a href="#Lua_nn33">Writing your own custom wrappers</a>
|
||||
<li><a href="#Lua_nn34">Adding additional Lua code</a>
|
||||
</ul>
|
||||
<li><a href="#Lua_nn34">Details on the Lua binding</a>
|
||||
<li><a href="#Lua_nn35">Details on the Lua binding</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_nn35">Binding global data into the module.</a>
|
||||
<li><a href="#Lua_nn36">Userdata and Metatables</a>
|
||||
<li><a href="#Lua_nn37">Memory management</a>
|
||||
<li><a href="#Lua_nn36">Binding global data into the module.</a>
|
||||
<li><a href="#Lua_nn37">Userdata and Metatables</a>
|
||||
<li><a href="#Lua_nn38">Memory management</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
|
|
@ -65,15 +67,20 @@
|
|||
|
||||
|
||||
<p>
|
||||
Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in clean C (that is, in the common subset of ANSI C and C++). Its also a <em>really</em> tiny language, less than 6000 lines of code, which compiles to <100 kilobytes of binary code. It can be found at <a href="http://www.lua.org">http://www.lua.org</a>
|
||||
Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in clean C (that is, in the common subset of ANSI C and C++). It's also a <em>really</em> tiny language, less than 6000 lines of code, which compiles to <100 kilobytes of binary code. It can be found at <a href="http://www.lua.org">http://www.lua.org</a>
|
||||
</p>
|
||||
<H2><a name="Lua_nn2"></a>24.1 Preliminaries</H2>
|
||||
<p>
|
||||
eLua stands for Embedded Lua (can be thought of as a flavor of Lua) and offers the full implementation of the Lua programming language to the embedded world, extending it with specific features for efficient and portable software embedded development. eLua runs on smaller devices like microcontrollers and provides the full features of the regular Lua desktop version. More information on eLua can be found here: <a href="http://www.eluaproject.net">http://www.eluaproject.net</a>
|
||||
</p>
|
||||
|
||||
<H2><a name="Lua_nn2"></a>26.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
The current SWIG implementation is designed to work with Lua 5.0.x and Lua 5.1.x. It should work with later versions of Lua, but certainly not with Lua 4.0 due to substantial API changes. ((Currently SWIG generated code has only been tested on Windows with MingW, though given the nature of Lua, is should not have problems on other OS's)). It is possible to either static link or dynamic link a Lua module into the interpreter (normally Lua static links its libraries, as dynamic linking is not available on all platforms).
|
||||
The current SWIG implementation is designed to work with Lua 5.0.x, 5.1.x and 5.2.x. It should work with later versions of Lua, but certainly not with Lua 4.0 due to substantial API changes. It is possible to either static link or dynamic link a Lua module into the interpreter (normally Lua static links its libraries, as dynamic linking is not available on all platforms). SWIG also supports eLua and works with eLua 0.8. SWIG generated code for eLua has been tested on Stellaris ARM Cortex-M3 LM3S and Infineon TriCore.
|
||||
</p>
|
||||
<H2><a name="Lua_nn3"></a>24.2 Running SWIG</H2>
|
||||
|
||||
<H2><a name="Lua_nn3"></a>26.2 Running SWIG</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -103,9 +110,58 @@ $ swig -c++ -lua example.i
|
|||
This creates a C/C++ source file <tt>example_wrap.c</tt> or <tt>example_wrap.cxx</tt>. The generated C source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application to create an extension module.
|
||||
</p>
|
||||
<p>
|
||||
The name of the wrapper file is derived from the name of the input file. For example, if the input file is <tt>example.i</tt>, the name of the wrapper file is <tt>example_wrap.c</tt>. To change this, you can use the -o option. The wrappered module will export one function <tt>"int luaopen_example(lua_State* L)"</tt> which must be called to register the module with the Lua interpreter. The name "luaopen_example" depends upon the name of the module.
|
||||
The name of the wrapper file is derived from the name of the input file. For example, if the input file is <tt>example.i</tt>, the name of the wrapper file is <tt>example_wrap.c</tt>. To change this, you can use the -o option. The wrapped module will export one function <tt>"int luaopen_example(lua_State* L)"</tt> which must be called to register the module with the Lua interpreter. The name "luaopen_example" depends upon the name of the module.
|
||||
</p>
|
||||
<H3><a name="Lua_nn4"></a>24.2.1 Compiling and Linking and Interpreter</H3>
|
||||
<p>
|
||||
To build an eLua module, run SWIG using <tt>-lua</tt> and add either <tt>-elua</tt> or <tt>-eluac</tt>.
|
||||
</p>
|
||||
<div class="shell"><pre>
|
||||
$ swig -lua -elua example.i
|
||||
</pre></div>
|
||||
<p>
|
||||
or
|
||||
</p>
|
||||
<div class="shell"><pre>
|
||||
$ swig -lua -eluac example.i
|
||||
</pre></div>
|
||||
<p>
|
||||
The <tt>-elua</tt> option puts all the C function wrappers and variable get/set wrappers in rotables. It also generates a metatable which will control the access to these variables from eLua. It also offers a significant amount of module size compression. On the other hand, the <tt>-eluac</tt> option puts all the wrappers in a single rotable. With this option, no matter how huge the module, it will consume no additional microcontroller SRAM (crass compression). There is a catch though: Metatables are not generated with <tt>-eluac</tt>. To access any value from eLua, one must directly call the wrapper function associated with that value.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_commandline"></a>26.2.1 Additional command line options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The following table list the additional commandline options available for the Lua module. They can also be seen by using:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
swig -lua -help
|
||||
</pre></div>
|
||||
|
||||
<table summary="Lua specific options">
|
||||
<tr>
|
||||
<th>Lua specific options</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-elua</td>
|
||||
<td>Generates LTR compatible wrappers for smaller devices running elua.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-eluac</td>
|
||||
<td>LTR compatible wrappers in "crass compress" mode for elua.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-nomoduleglobal</td>
|
||||
<td>Do not register the module name as a global variable but return the module table from calls to require.</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lua_nn4"></a>26.2.2 Compiling and Linking and Interpreter</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -129,7 +185,7 @@ int main(int argc,char* argv[])
|
|||
}
|
||||
L=lua_open();
|
||||
luaopen_base(L); // load basic libs (eg. print)
|
||||
luaopen_example(L); // load the wrappered module
|
||||
luaopen_example(L); // load the wrapped module
|
||||
if (luaL_loadfile(L,argv[1])==0) // load and run the file
|
||||
lua_pcall(L,0,0,0);
|
||||
else
|
||||
|
|
@ -151,12 +207,36 @@ $ gcc -I/usr/include/lua -c example_wrap.c -o example_wrap.o
|
|||
$ gcc -c example.c -o example.o
|
||||
$ gcc -I/usr/include/lua -L/usr/lib/lua min.o example_wrap.o example.o -o my_lua
|
||||
</pre></div>
|
||||
<p>
|
||||
For eLua, the source must be built along with the wrappers generated by SWIG. Make sure the eLua source files <tt>platform_conf.h</tt> and <tt>auxmods.h</tt> are updated with the entries of your new module. Please note: <tt>"mod"</tt> is the module name.
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
/* Sample platform_conf.h */
|
||||
#define LUA_PLATFORM_LIBS_ROM\
|
||||
_ROM( AUXLIB_PIO, luaopen_pio, pio_map )\
|
||||
_ROM( AUXLIB_TMR, luaopen_tmr, tmr_map )\
|
||||
_ROM( AUXLIB_MOD, luaopen_mod, mod_map )\
|
||||
....
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn5"></a>24.2.2 Compiling a dynamic module</H3>
|
||||
<div class="code"><pre>
|
||||
/* Sample auxmods.h */
|
||||
#define AUXLIB_PIO "pio"
|
||||
LUALIB_API int ( luaopen_pio )(lua_State *L );
|
||||
|
||||
#define AUXLIB_MOD "mod"
|
||||
LUALIB_API int ( luaopen_mod )(lua_State *L );
|
||||
....
|
||||
</pre></div>
|
||||
<p>
|
||||
More information on building and configuring eLua can be found here: <a href="http://www.eluaproject.net/doc/v0.8/en_building.html">http://www.eluaproject.net/doc/v0.8/en_building.html</a>
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn5"></a>26.2.3 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Most, but not all platforms support the dynamic loading of modules (Windows & Linux do). Refer to the Lua manual to determine if your platform supports it. For compiling a dynamically loaded module the same wrapper can be used. The commands will be something like this:
|
||||
Most, but not all platforms support the dynamic loading of modules (Windows & Linux do). Refer to the Lua manual to determine if your platform supports it. For compiling a dynamically loaded module the same wrapper can be used. Assuming you have code you need to link to in a file called <tt>example.c</tt>, the commands will be something like this:
|
||||
</p>
|
||||
<div class="shell"><pre>
|
||||
$ swig -lua example.i -o example_wrap.c
|
||||
|
|
@ -165,7 +245,7 @@ $ gcc -c example.c -o example.o
|
|||
$ gcc -shared -I/usr/include/lua -L/usr/lib/lua example_wrap.o example.o -o example.so
|
||||
</pre></div>
|
||||
<p>
|
||||
The wrappers produced by SWIG can be compiled and linked with Lua 5.1.x. The loading is extremely simple.
|
||||
The wrappers produced by SWIG can be compiled and linked with Lua 5.1.x and later. The loading is extremely simple.
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
require("example")
|
||||
|
|
@ -176,7 +256,7 @@ For those using Lua 5.0.x, you will also need an interpreter with the loadlib fu
|
|||
<div class="targetlang"><pre>
|
||||
my_init=loadlib("example.so","luaopen_example") -- for Unix/Linux
|
||||
--my_init=loadlib("example.dll","luaopen_example") -- for Windows
|
||||
assert(my_init) -- name sure its not nil
|
||||
assert(my_init) -- make sure it's not nil
|
||||
my_init() -- call the init fn of the lib
|
||||
</pre></div>
|
||||
<p>
|
||||
|
|
@ -197,10 +277,10 @@ print(a,b,c)
|
|||
</pre></div>
|
||||
<p>
|
||||
Note: for Lua 5.0:<br>
|
||||
The loadlib() function is in the global namespace, not in package. So its just loadlib().
|
||||
The loadlib() function is in the global namespace, not in a package. So it's just loadlib().
|
||||
</p>
|
||||
<p>
|
||||
if 'a' is a function, this its all working fine, all you need to do is call it
|
||||
if 'a' is a function, this is all working fine, all you need to do is call it
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
a()
|
||||
|
|
@ -209,7 +289,7 @@ if 'a' is a function, this its all working fine, all you need to do is call it
|
|||
to load your library which will add a table 'example' with all the functions added.
|
||||
</p>
|
||||
<p>
|
||||
If it doesn't work, look at the error messages, in particular mesage 'b'<br>
|
||||
If it doesn't work, look at the error messages, in particular message 'b'<br>
|
||||
<tt> The specified module could not be found.</tt><br>
|
||||
Means that is cannot find the module, check your the location and spelling of the module.<br>
|
||||
<tt> The specified procedure could not be found.</tt><br>
|
||||
|
|
@ -220,7 +300,7 @@ Is quite obvious (Go back and consult the Lua documents on how to enable loadlib
|
|||
|
||||
|
||||
|
||||
<H3><a name="Lua_nn6"></a>24.2.3 Using your module</H3>
|
||||
<H3><a name="Lua_nn6"></a>26.2.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -238,19 +318,19 @@ $ ./my_lua
|
|||
>
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_nn7"></a>24.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Lua_nn7"></a>26.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
By default, SWIG tries to build a very natural Lua interface to your C/C++ code. This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
<H3><a name="Lua_nn8"></a>24.3.1 Modules</H3>
|
||||
<H3><a name="Lua_nn8"></a>26.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The SWIG module directive specifies the name of the Lua module. If you specify `module example', then everything is wrapped into a Lua table 'example' containing all the functions and variables. When choosing a module name, make sure you don't use the same name as a built-in Lua command or standard module name.
|
||||
</p>
|
||||
<H3><a name="Lua_nn9"></a>24.3.2 Functions</H3>
|
||||
<H3><a name="Lua_nn9"></a>26.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -288,7 +368,7 @@ It is also possible to rename the module with an assignment.
|
|||
24
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn10"></a>24.3.3 Global variables</H3>
|
||||
<H3><a name="Lua_nn10"></a>26.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -314,7 +394,7 @@ SWIG will effectively generate two functions <tt>example.Foo_set()</tt> and <tt>
|
|||
4 5
|
||||
</pre></div>
|
||||
<p>
|
||||
Its is therefore not possible to 'move' the global variable into the global namespace as it is with functions. It is however, possible to rename the module with an assignment, to make it more convenient.
|
||||
It is therefore not possible to 'move' the global variable into the global namespace as it is with functions. It is however, possible to rename the module with an assignment, to make it more convenient.
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> e=example
|
||||
|
|
@ -325,7 +405,7 @@ Its is therefore not possible to 'move' the global variable into the global name
|
|||
4
|
||||
</pre></div>
|
||||
<p>
|
||||
If a variable is marked with the %immutable directive then any attempts to set this variable will cause an Lua error. Given a global variable:
|
||||
If a variable is marked with the %immutable directive then any attempts to set this variable will cause a Lua error. Given a global variable:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>%module example
|
||||
|
|
@ -361,8 +441,22 @@ nil
|
|||
> print(example.PI)
|
||||
3.142
|
||||
</pre></div>
|
||||
<p>
|
||||
If you have used the <tt>-eluac</tt> option for your eLua module, you will have to follow a different approach while manipulating global variables. (This is not applicable for wrappers generated with <tt>-elua</tt>)
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> -- Applicable only with -eluac. (num is defined)
|
||||
> print(example.num_get())
|
||||
20
|
||||
> example.num_set(50) -- new value added
|
||||
> print(example.num_get())
|
||||
50
|
||||
</pre></div>
|
||||
<p>
|
||||
In general, functions of the form <tt>"variable_get()"</tt> and <tt>"variable_set()"</tt> are automatically generated by SWIG for use with <tt>-eluac</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn11"></a>24.3.4 Constants and enums</H3>
|
||||
<H3><a name="Lua_nn11"></a>26.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -385,7 +479,18 @@ example.SUNDAY=0
|
|||
<p>
|
||||
Constants are not guaranteed to remain constant in Lua. The name of the constant could be accidentally reassigned to refer to some other object. Unfortunately, there is no easy way for SWIG to generate code that prevents this. You will just have to be careful.
|
||||
</p>
|
||||
<H3><a name="Lua_nn12"></a>24.3.5 Pointers</H3>
|
||||
<p>
|
||||
If you're using eLua and have used <tt>-elua</tt> or <tt>-eluac</tt> to generate your wrapper, macro constants and enums should be accessed through a rotable called <tt>"const"</tt>. In eLua, macro constants and enums are guaranteed to remain constants since they are all contained within a rotable. A regular C constant is accessed from eLua just as if it were a regular global variable, just that the property of value immutability is demonstrated if an attempt at modifying a C constant is made.
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> print(example.ICONST)
|
||||
10
|
||||
> print(example.const.SUNDAY)
|
||||
0
|
||||
> print(example.const.SCONST)
|
||||
Hello World
|
||||
</pre></div>
|
||||
<H3><a name="Lua_nn12"></a>26.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -406,13 +511,13 @@ When wrapped, you will be able to use the functions in a natural way from Lua. F
|
|||
> example.fclose(f)
|
||||
</pre></div>
|
||||
<p>
|
||||
Unlike many scripting languages, Lua has had support for pointers to C/C++ object built in for a long time. They are called 'userdata'. Unlike many other SWIG versions which use some kind of encoded character string, all objects will be represented as a userdata. The SWIG-Lua bindings provides a special function <tt>swig_type()</tt>, which if given a userdata object will return the type of object pointed to as a string (assuming it was a SWIG wrappered object).
|
||||
Unlike many scripting languages, Lua has had support for pointers to C/C++ object built in for a long time. They are called 'userdata'. Unlike many other SWIG versions which use some kind of encoded character string, all objects will be represented as a userdata. The SWIG-Lua bindings provides a special function <tt>swig_type()</tt>, which if given a userdata object will return the type of object pointed to as a string (assuming it was a SWIG wrapped object).
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> print(f)
|
||||
userdata: 003FDA80
|
||||
> print(swig_type(f))
|
||||
FILE * -- its a FILE*
|
||||
FILE * -- it's a FILE*
|
||||
</pre></div>
|
||||
<p>
|
||||
Lua enforces the integrity of its userdata, so it is virtually impossible to corrupt the data. But as the user of the pointer, you are responsible for freeing it, or closing any resources associated with it (just as you would in a C program). This does not apply so strictly to classes & structs (see below). One final note: if a function returns a NULL pointer, this is not encoded as a userdata, but as a Lua nil.
|
||||
|
|
@ -423,7 +528,7 @@ Lua enforces the integrity of its userdata, so it is virtually impossible to cor
|
|||
nil
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn13"></a>24.3.6 Structures</H3>
|
||||
<H3><a name="Lua_nn13"></a>26.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -456,10 +561,10 @@ If you print out the value of p in the above example, you will see something lik
|
|||
userdata: 003FA320
|
||||
</pre></div>
|
||||
<p>
|
||||
Like the pointer in the previous section, this is held as a userdata. However, additional features have been added to make this more usable. SWIG effectivly creates some accessor/mutator functions to get and set the data. These functions will be added to the userdata's metatable. This provides the natural access to the member variables that were shown above (see end of the document for full details).
|
||||
Like the pointer in the previous section, this is held as a userdata. However, additional features have been added to make this more usable. SWIG effectively creates some accessor/mutator functions to get and set the data. These functions will be added to the userdata's metatable. This provides the natural access to the member variables that were shown above (see end of the document for full details).
|
||||
</p>
|
||||
<p>
|
||||
<tt>const</tt> members of a structure are read-only. Data members can also be forced to be read-only using the immutable directive. As with other immutable's, setting attempts will be cause an error. For example:
|
||||
<tt>const</tt> members of a structure are read-only. Data members can also be forced to be read-only using the immutable directive. As with other immutables, setting attempts will be cause an error. For example:
|
||||
</p>
|
||||
<div class="code"><pre>struct Foo {
|
||||
...
|
||||
|
|
@ -508,8 +613,26 @@ Because the pointer points inside the structure, you can modify the contents and
|
|||
> x = b.f
|
||||
> x.a = 3 -- Modifies the same structure
|
||||
</pre></div>
|
||||
<p>
|
||||
For eLua with the <tt>-eluac</tt> option, structure manipulation has to be performed with specific structure functions generated by SWIG. Let's say you have the following structure definition:
|
||||
</p>
|
||||
<div class="code"><pre>struct data {
|
||||
int x, y;
|
||||
double z;
|
||||
};
|
||||
|
||||
<H3><a name="Lua_nn14"></a>24.3.7 C++ classes</H3>
|
||||
> --From eLua
|
||||
> a = example.new_data()
|
||||
> example.data_x_set(a, 10)
|
||||
> example.data_y_set(a, 20)
|
||||
> print(example.data_x_get(a), example.data_y_get(a))
|
||||
10 20
|
||||
</pre></div>
|
||||
<p>
|
||||
In general, functions of the form <tt>"new_struct()"</tt>, <tt>"struct_member_get()"</tt>, <tt>"struct_member_set()"</tt> and <tt>"free_struct()"</tt> are automatically generated by SWIG for each structure defined in C. (Please note: This doesn't apply for modules generated with the <tt>-elua</tt> option)
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn14"></a>26.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -541,7 +664,7 @@ Stout
|
|||
>
|
||||
</pre></div>
|
||||
<p>
|
||||
(Note: for calling methods of a class, you use <tt>class:method(args)</tt>, not <tt>class.method(args)</tt>, its an easy mistake to make. However for data attributes it is <tt>class.attribute</tt>)
|
||||
(Note: for calling methods of a class, you use <tt>class:method(args)</tt>, not <tt>class.method(args)</tt>, it's an easy mistake to make. However for data attributes it is <tt>class.attribute</tt>)
|
||||
</p>
|
||||
<p>
|
||||
Class data members are accessed in the same manner as C structures. Static class members present a special problem for Lua, as Lua doesn't have support for such features. Therefore, SWIG generates wrappers that try to work around some of these issues. To illustrate, suppose you have a class like this:
|
||||
|
|
@ -550,7 +673,6 @@ Class data members are accessed in the same manner as C structures. Static class
|
|||
public:
|
||||
static void foo();
|
||||
static int bar;
|
||||
|
||||
};
|
||||
</pre></div>
|
||||
<p>
|
||||
|
|
@ -565,12 +687,12 @@ In Lua, the static members can be accessed as follows:
|
|||
It is not (currently) possible to access static members of an instance:
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> s=example.Spam() -- s is a Spam instance
|
||||
> s=example.Spam() -- s is a Spam instance
|
||||
> s.foo() -- Spam::foo() via an instance
|
||||
-- does NOT work
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn15"></a>24.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Lua_nn15"></a>26.3.8 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -595,7 +717,7 @@ then the function <tt>spam()</tt> accepts a Foo pointer or a pointer to any clas
|
|||
<p>
|
||||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
<H3><a name="Lua_nn16"></a>24.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Lua_nn16"></a>26.3.9 Pointers, references, values, and arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -626,7 +748,7 @@ Foo spam7();
|
|||
<p>
|
||||
then all three functions will return a pointer to some Foo object. Since the third function (spam7) returns a value, newly allocated memory is used to hold the result and a pointer is returned (Lua will release this memory when the return value is garbage collected). The other two are pointers which are assumed to be managed by the C code and so will not be garbage collected.
|
||||
</p>
|
||||
<H3><a name="Lua_nn17"></a>24.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Lua_nn17"></a>26.3.10 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -712,7 +834,7 @@ Please refer to the "SWIG and C++" chapter for more information about overloadin
|
|||
<p>
|
||||
Dealing with the Lua coercion mechanism, the priority is roughly (integers, floats, strings, userdata). But it is better to rename the functions rather than rely upon the ordering.
|
||||
</p>
|
||||
<H3><a name="Lua_nn18"></a>24.3.11 C++ operators</H3>
|
||||
<H3><a name="Lua_nn18"></a>26.3.11 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -824,7 +946,7 @@ It is also possible to overload the operator<tt>[]</tt>, but currently this cann
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn19"></a>24.3.12 Class extension with %extend</H3>
|
||||
<H3><a name="Lua_nn19"></a>26.3.12 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -879,7 +1001,32 @@ true
|
|||
<p>
|
||||
Extend works with both C and C++ code, on classes and structs. It does not modify the underlying object in any way---the extensions only show up in the Lua interface. The only item to take note of is the code has to use the '$self' instead of 'this', and that you cannot access protected/private members of the code (as you are not officially part of the class).
|
||||
</p>
|
||||
<H3><a name="Lua_nn20"></a>24.3.13 C++ templates</H3>
|
||||
|
||||
<H3><a name="Lua_nn20"></a>26.3.13 Using %newobject to release memory</H3>
|
||||
|
||||
|
||||
<p> If you have a function that allocates memory like this,</p>
|
||||
<div class="code">
|
||||
<pre>char *foo() {
|
||||
char *result = (char *) malloc(...);
|
||||
...
|
||||
return result;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
<p> then the SWIG generated wrappers will have a memory leak--the
|
||||
returned data will be copied into a string object and the old contents
|
||||
ignored.</p>
|
||||
<p> To fix the memory leak, use the <a href="Customization.html#Customization_ownership">%newobject directive</a>.</p>
|
||||
<div class="code">
|
||||
<pre>%newobject foo;
|
||||
...
|
||||
char *foo();
|
||||
</pre>
|
||||
</div>
|
||||
<p> This will release the allocated memory.</p>
|
||||
|
||||
<H3><a name="Lua_nn21"></a>26.3.14 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -914,7 +1061,7 @@ In Lua:
|
|||
<p>
|
||||
Obviously, there is more to template wrapping than shown in this example. More details can be found in the SWIG and C++ chapter. Some more complicated examples will appear later.
|
||||
</p>
|
||||
<H3><a name="Lua_nn21"></a>24.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Lua_nn22"></a>26.3.15 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -966,7 +1113,7 @@ If you ever need to access the underlying pointer returned by <tt>operator->(
|
|||
> f = p:__deref__() -- Returns underlying Foo *
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn22"></a>24.3.15 C++ Exceptions</H3>
|
||||
<H3><a name="Lua_nn23"></a>26.3.16 C++ Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -985,13 +1132,13 @@ SWIG will automatically convert this to a Lua error.
|
|||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
> message()
|
||||
> message()
|
||||
I died.
|
||||
stack traceback:
|
||||
[C]: in function 'message'
|
||||
stdin:1: in main chunk
|
||||
[C]: ?
|
||||
>
|
||||
>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -1000,13 +1147,13 @@ Using xpcall will allow you to obtain additional debug information (such as a st
|
|||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
> function a() b() end -- function a() calls function b()
|
||||
> function b() message() end -- function b() calls C++ function message(), which throws
|
||||
> ok,res=pcall(a) -- call the function
|
||||
> print(ok,res)
|
||||
> function a() b() end -- function a() calls function b()
|
||||
> function b() message() end -- function b() calls C++ function message(), which throws
|
||||
> ok,res=pcall(a) -- call the function
|
||||
> print(ok,res)
|
||||
false I died.
|
||||
> ok,res=xpcall(a,debug.traceback) -- call the function
|
||||
> print(ok,res)
|
||||
> ok,res=xpcall(a,debug.traceback) -- call the function
|
||||
> print(ok,res)
|
||||
false I died.
|
||||
stack traceback:
|
||||
[C]: in function 'message'
|
||||
|
|
@ -1018,12 +1165,12 @@ stack traceback:
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
SWIG is able to throw numeric types, enums, chars, char*'s and std::string's without problem. It has also written typemaps for std::exception and its derived classes, which convert the exception into and error string. </p>
|
||||
SWIG is able to throw numeric types, enums, chars, char*'s and std::string's without problem. It has also written typemaps for std::exception and its derived classes, which convert the exception into an error string. </p>
|
||||
<p>
|
||||
However its not so simple for to throw other types of objects.
|
||||
However it's not so simple to throw other types of objects.
|
||||
Thrown objects are not valid outside the 'catch' block. Therefore they cannot be
|
||||
returned to the interpreter.
|
||||
The obvious ways to overcome this would be to either return a copy of the object, or so convert the object to a string and
|
||||
The obvious ways to overcome this would be to either return a copy of the object, or to convert the object to a string and
|
||||
return that. Though it seems obvious to perform the former, in some cases this is not possible, most notably when
|
||||
SWIG has no information about the object, or the object is not copyable/creatable.
|
||||
</p>
|
||||
|
|
@ -1037,17 +1184,17 @@ void throw_A() throw(A*) {
|
|||
}
|
||||
</pre></div>
|
||||
<p>
|
||||
SWIG will just convert it (poorly) to a string and use that as its error. (Yes its not that useful, but it always works).
|
||||
SWIG will just convert it (poorly) to a string and use that as its error. (This is not that useful, but it always works).
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
> throw_A()
|
||||
> throw_A()
|
||||
object exception:A *
|
||||
stack traceback:
|
||||
[C]: in function 'unknown'
|
||||
stdin:1: in main chunk
|
||||
[C]: ?
|
||||
>
|
||||
>
|
||||
</pre></div>
|
||||
<p>
|
||||
To get a more useful behaviour out of SWIG you must either: provide a way to convert your exceptions into strings, or
|
||||
|
|
@ -1064,8 +1211,8 @@ If you have your own class which you want output as a string you will need to ad
|
|||
%}
|
||||
</pre></div>
|
||||
<p>
|
||||
If you wish your exception to be returned to the interpreter, it must firstly be copyable. Then you must have and additional
|
||||
<tt>%apply</tt> statement, to inform SWIG to return a copy of this object to the interpreter. For example:
|
||||
If you wish your exception to be returned to the interpreter, it must firstly be copyable. Then you must have an additional
|
||||
<tt>%apply</tt> statement, to tell SWIG to return a copy of this object to the interpreter. For example:
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
%apply SWIGTYPE EXCEPTION_BY_VAL {Exc}; // tell SWIG to return Exc by value to interpreter
|
||||
|
|
@ -1088,14 +1235,14 @@ void throw_exc() throw(Exc) {
|
|||
Then the following code can be used (note: we use pcall to catch the error so we can process the exception).
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> ok,res=pcall(throw_exc)
|
||||
> print(ok)
|
||||
> ok,res=pcall(throw_exc)
|
||||
> print(ok)
|
||||
false
|
||||
> print(res)
|
||||
> print(res)
|
||||
userdata: 0003D880
|
||||
> print(res.code,res.msg)
|
||||
> print(res.code,res.msg)
|
||||
42 Hosed
|
||||
>
|
||||
>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -1110,12 +1257,12 @@ add exception specification to functions or globally (respectively).
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Lua_nn23"></a>24.4 Typemaps</H2>
|
||||
<H2><a name="Lua_nn24"></a>26.4 Typemaps</H2>
|
||||
|
||||
|
||||
<p>This section explains what typemaps are and the usage of them. The default wrappering behaviour of SWIG is enough in most cases. However sometimes SWIG may need a little additional assistance to know which typemap to apply to provide the best wrappering. This section will be explaining how to use typemaps to best effect</p>
|
||||
<p>This section explains what typemaps are and how to use them. The default wrapping behaviour of SWIG is enough in most cases. However sometimes SWIG may need a little additional assistance to know which typemap to apply to provide the best wrapping. This section will be explaining how to use typemaps to best effect</p>
|
||||
|
||||
<H3><a name="Lua_nn24"></a>24.4.1 What is a typemap?</H3>
|
||||
<H3><a name="Lua_nn25"></a>26.4.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>A typemap is nothing more than a code generation rule that is attached to a specific C datatype. For example, to convert integers from Lua to C, you might define a typemap like this:</p>
|
||||
|
|
@ -1143,7 +1290,7 @@ Received an integer : 6
|
|||
720
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn25"></a>24.4.2 Using typemaps</H3>
|
||||
<H3><a name="Lua_nn26"></a>26.4.2 Using typemaps</H3>
|
||||
|
||||
|
||||
<p>There are many ready written typemaps built into SWIG for all common types (int, float, short, long, char*, enum and more), which SWIG uses automatically, with no effort required on your part.</p>
|
||||
|
|
@ -1196,7 +1343,7 @@ void swap(int *sx, int *sy);
|
|||
|
||||
<p>Note: C++ references must be handled exactly the same way. However SWIG will automatically wrap a <tt>const int&</tt> as an input parameter (since that it obviously input).</p>
|
||||
|
||||
<H3><a name="Lua_nn26"></a>24.4.3 Typemaps and arrays</H3>
|
||||
<H3><a name="Lua_nn27"></a>26.4.3 Typemaps and arrays</H3>
|
||||
|
||||
|
||||
<p>Arrays present a challenge for SWIG, because like pointers SWIG does not know whether these are input or output values, nor
|
||||
|
|
@ -1209,8 +1356,8 @@ extern void sort_double(double* arr, int len);
|
|||
</pre></div>
|
||||
|
||||
<p>There are basically two ways that SWIG can deal with this. The first way, uses the <tt><carrays.i></tt> library
|
||||
to create an array in C/C++ then this can be filled within Lua and passed into the function. It works, but its a bit tedious.
|
||||
More details can be found in the <a href="Library.html#Library_carrays">carrays.i</a> documention.</p>
|
||||
to create an array in C/C++ then this can be filled within Lua and passed into the function. It works, but it's a bit tedious.
|
||||
More details can be found in the <a href="Library.html#Library_carrays">carrays.i</a> documentation.</p>
|
||||
|
||||
<p>The second and more intuitive way, would be to pass a Lua table directly into the function, and have SWIG automatically convert between Lua-table and C-array. Within the <tt><typemaps.i></tt> file there are typemaps ready written to perform this task. To use them is again a matter of using %appy in the correct manner.</p>
|
||||
|
||||
|
|
@ -1230,7 +1377,7 @@ extern void sort_int(int* arr, int len); // the function to wrap
|
|||
extern void sort_double(double* arr, int len); // the function to wrap
|
||||
</pre></div>
|
||||
|
||||
<p>Once wrappered, the functions can both be called, though with different ease of use:</p>
|
||||
<p>Once wrapped, the functions can both be called, though with different ease of use:</p>
|
||||
|
||||
<div class="targetlang"><pre>require "example"
|
||||
ARRAY_SIZE=10
|
||||
|
|
@ -1260,7 +1407,7 @@ and Lua tables to be 1..N, (the indexing follows the norm for the language). In
|
|||
|
||||
<p>Note: SWIG also can support arrays of pointers in a similar manner.</p>
|
||||
|
||||
<H3><a name="Lua_nn27"></a>24.4.4 Typemaps and pointer-pointer functions</H3>
|
||||
<H3><a name="Lua_nn28"></a>26.4.4 Typemaps and pointer-pointer functions</H3>
|
||||
|
||||
|
||||
<p>Several C++ libraries use a pointer-pointer functions to create its objects. These functions require a pointer to a pointer which is then filled with the pointer to the new object. Microsoft's COM and DirectX as well as many other libraries have this kind of function. An example is given below:</p>
|
||||
|
|
@ -1279,10 +1426,10 @@ ok=Create_Math(&ptr);
|
|||
free(ptr); // dispose of iMath
|
||||
</pre></div>
|
||||
|
||||
<p>SWIG has a ready written typemap to deal with such a kind of function in <typemaps.i>. It provides the correct wrappering as well as setting the flag to inform Lua that the object in question should be garbage collected. Therefore the code is simply:</p>
|
||||
<p>SWIG has a ready written typemap to deal with such a kind of function in <typemaps.i>. It provides the correct wrapping as well as setting the flag to inform Lua that the object in question should be garbage collected. Therefore the code is simply:</p>
|
||||
|
||||
<div class="code"><pre>%include <typemaps.i>
|
||||
%apply SWIGTYPE** OUTPUT{iMath **pptr }; // tell SWIG its an output
|
||||
%apply SWIGTYPE** OUTPUT{iMath **pptr }; // tell SWIG it's an output
|
||||
|
||||
struct iMath; // some structure
|
||||
int Create_Math(iMath** pptr); // its creator (assume it mallocs)
|
||||
|
|
@ -1290,20 +1437,20 @@ int Create_Math(iMath** pptr); // its creator (assume it mallocs)
|
|||
|
||||
<p>The usage is as follows:</p>
|
||||
|
||||
<div class="targetlang"><pre>ok,ptr=Create_Math() -- ptr is a iMath* which is returned with the int (ok)
|
||||
<div class="targetlang"><pre>ok,ptr=Create_Math() -- ptr is an iMath* which is returned with the int (ok)
|
||||
ptr=nil -- the iMath* will be GC'ed as normal
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_nn28"></a>24.5 Writing typemaps</H2>
|
||||
<H2><a name="Lua_nn29"></a>26.5 Writing typemaps</H2>
|
||||
|
||||
|
||||
<p>This section describes how you can modify SWIG's default wrapping behavior for various C/C++ datatypes using the <tt>%typemap</tt> directive. This is an advanced topic that assumes familiarity with the Lua C API as well as the material in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter.</p>
|
||||
|
||||
<p>Before proceeding, it should be stressed that writing typemaps is rarely needed unless you want to change some aspect of the wrappering, or to achieve an effect which in not available with the default bindings.</p>
|
||||
<p>Before proceeding, it should be stressed that writing typemaps is rarely needed unless you want to change some aspect of the wrapping, or to achieve an effect which in not available with the default bindings.</p>
|
||||
|
||||
<p>Before proceeding, you should read the previous section on using typemaps, as well as read the ready written typemaps found in luatypemaps.swg and typemaps.i. These are both well documented and fairly easy to read. You should not attempt to write your own typemaps until you have read and can understand both of these files (they may well also give you a idea to base your worn on).</p>
|
||||
<p>Before proceeding, you should read the previous section on using typemaps, and look at the existing typemaps found in luatypemaps.swg and typemaps.i. These are both well documented and fairly easy to read. You should not attempt to write your own typemaps until you have read and can understand both of these files (they may well also give you an idea to base your work on).</p>
|
||||
|
||||
<H3><a name="Lua_nn29"></a>24.5.1 Typemaps you can write</H3>
|
||||
<H3><a name="Lua_nn30"></a>26.5.1 Typemaps you can write</H3>
|
||||
|
||||
|
||||
<p>There are many different types of typemap that can be written, the full list can be found in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter. However the following are the most commonly used ones.</p>
|
||||
|
|
@ -1316,7 +1463,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
|
|||
(the syntax for the typecheck is different from the typemap, see typemaps for details).</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Lua_nn30"></a>24.5.2 SWIG's Lua-C API</H3>
|
||||
<H3><a name="Lua_nn31"></a>26.5.2 SWIG's Lua-C API</H3>
|
||||
|
||||
|
||||
<p>This section explains the SWIG specific Lua-C API. It does not cover the main Lua-C api, as this is well documented and not worth covering.</p>
|
||||
|
|
@ -1324,7 +1471,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
|
|||
<p><tt>int SWIG_ConvertPtr(lua_State* L,int index,void** ptr,swig_type_info *type,int flags);</tt></p>
|
||||
|
||||
<div class="indent">
|
||||
This is the standard function used for converting a Lua userdata to a void*. It takes the value at the given index in the Lua state and converts it to a userdata. It will then provide the neccesary type checks, confirming that the pointer is compatible with the type given in 'type'. Then finally setting '*ptr' to the pointer.
|
||||
This is the standard function used for converting a Lua userdata to a void*. It takes the value at the given index in the Lua state and converts it to a userdata. It will then provide the necessary type checks, confirming that the pointer is compatible with the type given in 'type'. Then finally setting '*ptr' to the pointer.
|
||||
If flags is set to SWIG_POINTER_DISOWN, this is will clear any ownership flag set on the object.<br>
|
||||
The returns a value which can be checked with the macro SWIG_IsOK()
|
||||
</div>
|
||||
|
|
@ -1345,7 +1492,7 @@ This function is a version of SWIG_ConvertPtr(), except that it will either work
|
|||
<p><tt>SWIG_fail</tt></p>
|
||||
|
||||
<div class="indent">
|
||||
This macro, when called within the context of a SWIG wrappered function, will jump to the error handler code. This will call any cleanup code (freeing any temp variables) and then triggers a lua_error.<br>
|
||||
This macro, when called within the context of a SWIG wrapped function, will jump to the error handler code. This will call any cleanup code (freeing any temp variables) and then triggers a lua_error.<br>
|
||||
A common use for this code is:<br><pre>
|
||||
if (!SWIG_IsOK(SWIG_ConvertPtr( .....)){
|
||||
lua_pushstring(L,"something bad happened");
|
||||
|
|
@ -1355,7 +1502,7 @@ if (!SWIG_IsOK(SWIG_ConvertPtr( .....)){
|
|||
<p><tt>SWIG_fail_arg(char* func_name,int argnum,char* type)</tt></p>
|
||||
|
||||
<div class="indent">
|
||||
This macro, when called within the context of a SWIG wrappered function, will display the error message and jump to the error handler code. The error message is of the form
|
||||
This macro, when called within the context of a SWIG wrapped function, will display the error message and jump to the error handler code. The error message is of the form
|
||||
<pre>
|
||||
"Error in <i>func_name</i> (arg <i>argnum</i>), expected '<i>type</i>' got '<i>whatever the type was</i>'"
|
||||
</pre></div>
|
||||
|
|
@ -1365,7 +1512,7 @@ This macro, when called within the context of a SWIG wrappered function, will di
|
|||
<div class="indent">
|
||||
Similar to SWIG_fail_arg, except that it will display the swig_type_info information instead.</div>
|
||||
|
||||
<H2><a name="Lua_nn31"></a>24.6 Customization of your Bindings</H2>
|
||||
<H2><a name="Lua_nn32"></a>26.6 Customization of your Bindings</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1374,11 +1521,11 @@ This section covers adding of some small extra bits to your module to add the la
|
|||
|
||||
|
||||
|
||||
<H3><a name="Lua_nn32"></a>24.6.1 Writing your own custom wrappers</H3>
|
||||
<H3><a name="Lua_nn33"></a>26.6.1 Writing your own custom wrappers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Sometimes, it may be neccesary to add your own special functions, which bypass the normal SWIG wrappering method, and just use the native Lua API calls. These 'native' functions allow direct adding of your own code into the module. This is performed with the <tt>%native</tt> directive as follows:
|
||||
Sometimes, it may be necessary to add your own special functions, which bypass the normal SWIG wrapper method, and just use the native Lua API calls. These 'native' functions allow direct adding of your own code into the module. This is performed with the <tt>%native</tt> directive as follows:
|
||||
</p>
|
||||
<div class="code"><pre>%native(my_func) int native_function(lua_State*L); // registers native_function() with SWIG
|
||||
...
|
||||
|
|
@ -1390,14 +1537,14 @@ int native_function(lua_State*L) // my native code
|
|||
%}
|
||||
</pre></div>
|
||||
<p>
|
||||
The <tt>%native</tt> directive in the above example, tells SWIG that there is a function <tt>int native_function(lua_State*L);</tt> which is to be added into the module under the name '<tt>my_func</tt>'. SWIG will not add any wrappering for this function, beyond adding it into the function table. How you write your code is entirely up to you.
|
||||
The <tt>%native</tt> directive in the above example, tells SWIG that there is a function <tt>int native_function(lua_State*L);</tt> which is to be added into the module under the name '<tt>my_func</tt>'. SWIG will not add any wrapper for this function, beyond adding it into the function table. How you write your code is entirely up to you.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn33"></a>24.6.2 Adding additional Lua code</H3>
|
||||
<H3><a name="Lua_nn34"></a>26.6.2 Adding additional Lua code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
As well as adding additional C/C++ code, its also possible to add your own Lua code to the module as well.
|
||||
As well as adding additional C/C++ code, it's also possible to add your own Lua code to the module as well.
|
||||
This code is executed once all other initialisation, including the %init code has been called.
|
||||
</p>
|
||||
<p>
|
||||
|
|
@ -1422,7 +1569,7 @@ module name added.
|
|||
</p>
|
||||
<p>
|
||||
Should there be an error in the Lua code, this will <em>not</em> stop loading of the module.
|
||||
The default behaviour of SWIG is to print a error message to stderr and then continue.
|
||||
The default behaviour of SWIG is to print an error message to stderr and then continue.
|
||||
It is possible to change this behaviour by using a <tt>#define SWIG_DOSTRING_FAIL(STR)</tt> to
|
||||
define a different behaviour should the code fail.
|
||||
</p>
|
||||
|
|
@ -1431,18 +1578,18 @@ Good uses for this feature is adding of new code, or writing helper functions to
|
|||
See Examples/lua/arrays for an example of this code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Lua_nn34"></a>24.7 Details on the Lua binding</H2>
|
||||
<H2><a name="Lua_nn35"></a>26.7 Details on the Lua binding</H2>
|
||||
|
||||
|
||||
<p>
|
||||
In the previous section, a high-level view of Lua wrapping was presented. Obviously a lot of stuff happens behind the scenes to make this happen. This section will explain some of the low-level details on how this is achieved.
|
||||
</p>
|
||||
<p>
|
||||
<i>If you just want to use SWIG and don't care how it works, then stop reading here. This is going into the guts of the code and how it works. Its mainly for people who need to know whats going on within the code.
|
||||
<i>If you just want to use SWIG and don't care how it works, then stop reading here. This is going into the guts of the code and how it works. It's mainly for people who need to know what's going on within the code.
|
||||
</i>
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn35"></a>24.7.1 Binding global data into the module.</H3>
|
||||
<H3><a name="Lua_nn36"></a>26.7.1 Binding global data into the module.</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1502,14 +1649,14 @@ end
|
|||
<p>
|
||||
That way when you call '<tt>a=example.Foo</tt>', the interpreter looks at the table 'example' sees that there is no field 'Foo' and calls __index. This will in turn check in '.get' table and find the existence of 'Foo' and then return the value of the C function call 'Foo_get()'. Similarly for the code '<tt>example.Foo=10</tt>', the interpreter will check the table, then call the __newindex which will then check the '.set' table and call the C function 'Foo_set(10)'.
|
||||
</p>
|
||||
<H3><a name="Lua_nn36"></a>24.7.2 Userdata and Metatables</H3>
|
||||
<H3><a name="Lua_nn37"></a>26.7.2 Userdata and Metatables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
As mentioned earlier, classes and structures, are all held as pointer, using the Lua 'userdata' structure. This structure is actually a pointer to a C structure 'swig_lua_userdata', which contains the pointer to the data, a pointer to the swig_type_info (an internal SWIG struct) and a flag which marks if the object is to be disposed of when the interpreter no longer needs it. The actual accessing of the object is done via the metatable attached to this userdata.
|
||||
</p>
|
||||
<p>
|
||||
The metatable is a Lua 5.0 feature (which is also why SWIG cannot wrap Lua 4.0). Its a table which holds a list of functions, operators and attributes. This is what gives the userdata the feeling that it is a real object and not just a hunk of memory.
|
||||
The metatable is a Lua 5.0 feature (which is also why SWIG cannot wrap Lua 4.0). It's a table which holds a list of functions, operators and attributes. This is what gives the userdata the feeling that it is a real object and not just a hunk of memory.
|
||||
</p>
|
||||
<p>
|
||||
Given a class
|
||||
|
|
@ -1526,10 +1673,10 @@ public:
|
|||
};
|
||||
</pre></div>
|
||||
<p>
|
||||
SWIG will create a module excpp, with all the various function inside. However to allow the intuitive use of the userdata is also creates up a set of metatables. As seen in the above section on global variables, use of the metatables allows for wrappers to be used intuitively. To save effort, the code creates one metatable per class and stores it inside Lua's registry. Then when an new object is instantiated, the metatable is found in the registry and the userdata associated to the metatable. Currently derived classes make a complete copy of the base classes table and then add on their own additional function.
|
||||
SWIG will create a module excpp, with all the various functions inside. However to allow the intuitive use of the userdata, SWIG also creates up a set of metatables. As seen in the above section on global variables, use of the metatables allows for wrappers to be used intuitively. To save effort, the code creates one metatable per class and stores it inside Lua's registry. Then when a new object is instantiated, the metatable is found in the registry and the userdata associated with the metatable. Currently, derived classes make a complete copy of the base class' table and then add on their own additional functions.
|
||||
</p>
|
||||
<p>
|
||||
Some of the internals can be seen by looking at a classes metatable.
|
||||
Some of the internals can be seen by looking at the metatable of a class:
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> p=excpp.Point()
|
||||
|
|
@ -1546,7 +1693,7 @@ __index function: 003FB698
|
|||
.fn table: 003FB528
|
||||
</pre></div>
|
||||
<p>
|
||||
The '.type' attribute is the name of the class. The '.get' and '.set' tables work in a similar manner to the modules, the main difference is the '.fn' table which also holds all the member functions. (The '__gc' function is the classes destructor function)
|
||||
The '.type' attribute is the name of the class. The '.get' and '.set' tables work in a similar manner to the modules, the main difference is the '.fn' table which also holds all the member functions. (The '__gc' function is the class' destructor function)
|
||||
</p>
|
||||
<p>
|
||||
The Lua equivalent of the code for enabling functions looks a little like this
|
||||
|
|
@ -1560,7 +1707,7 @@ function __index(obj,name)
|
|||
local f=g[name] -- looks for the get_attribute function
|
||||
-- calls it & returns the value
|
||||
if type(f)=="function" then return f() end
|
||||
-- ok, so it not an attribute, maybe its a function
|
||||
-- ok, so it not an attribute, maybe it's a function
|
||||
local fn=m['.fn'] -- gets the function table
|
||||
if not fn then return nil end
|
||||
local f=fn[name] -- looks for the function
|
||||
|
|
@ -1577,22 +1724,22 @@ So when 'p:Print()' is called, the __index looks on the object metatable for a '
|
|||
In theory, you can play with this usertable & add new features, but remember that it is a shared table between all instances of one class, and you could very easily corrupt the functions in all the instances.
|
||||
</p>
|
||||
<p>
|
||||
Note: Both the opaque structures (like the FILE*) and normal wrappered classes/structs use the same 'swig_lua_userdata' structure. Though the opaque structures has do not have a metatable attached, or any information on how to dispose of them when the interpreter has finished with them.
|
||||
Note: Both the opaque structures (like the FILE*) and normal wrapped classes/structs use the same 'swig_lua_userdata' structure. Though the opaque structures has do not have a metatable attached, or any information on how to dispose of them when the interpreter has finished with them.
|
||||
</p>
|
||||
<p>
|
||||
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' & '__call' to the classes metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming its an operator overload.
|
||||
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' & '__call' to the class' metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming its an operator overload.
|
||||
</p>
|
||||
<H3><a name="Lua_nn37"></a>24.7.3 Memory management</H3>
|
||||
<H3><a name="Lua_nn38"></a>26.7.3 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Lua is very helpful with the memory management. The 'swig_lua_userdata' is fully managed by the interpreter itself. This means that neither the C code nor the Lua code can damage it. Once a piece of userdata has no references to it, it is not instantly collected, but will be collected when Lua deems is necessary. (You can force collection by calling the Lua function <tt>collectgarbage()</tt>). Once the userdata is about to be free'ed, the interpreter will check the userdata for a metatable and for a function '__gc'. If this exists this is called. For all complete types (ie normal wrappered classes & structs) this should exist. The '__gc' function will check the 'swig_lua_userdata' to check for the 'own' field and if this is true (which is will be for all owned data's) it will then call the destructor on the pointer.
|
||||
Lua is very helpful with the memory management. The 'swig_lua_userdata' is fully managed by the interpreter itself. This means that neither the C code nor the Lua code can damage it. Once a piece of userdata has no references to it, it is not instantly collected, but will be collected when Lua deems is necessary. (You can force collection by calling the Lua function <tt>collectgarbage()</tt>). Once the userdata is about to be free'ed, the interpreter will check the userdata for a metatable and for a function '__gc'. If this exists this is called. For all complete types (ie normal wrapped classes & structs) this should exist. The '__gc' function will check the 'swig_lua_userdata' to check for the 'own' field and if this is true (which is will be for all owned data) it will then call the destructor on the pointer.
|
||||
</p>
|
||||
<p>
|
||||
It is currently not recommended to edit this field or add some user code, to change the behaviour. Though for those who wish to try, here is where to look.
|
||||
</p>
|
||||
<p>
|
||||
It is also currently not possible to change the ownership flag on the data (unlike most other scripting languages, Lua does not permit access to the data from within the interpreter)
|
||||
It is also currently not possible to change the ownership flag on the data (unlike most other scripting languages, Lua does not permit access to the data from within the interpreter).
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
# Note the # and " are escaped
|
||||
HTMLDOC_OPTIONS = "--book --toclevels 4 --no-numbered --toctitle \"Table of Contents\" --title --titleimage swig16.png --linkcolor \#0000ff --linkstyle underline --size Universal --left 0.50in --right 0.50in --top 0.50in --bottom 0.50in --header .t. --footer h.1 --nup 1 --tocheader .t. --tocfooter ..i --portrait --color --no-pscommands --no-xrxcomments --compression=1 --jpeg=0 --fontsize 10.0 --fontspacing 1.2 --headingfont Helvetica --bodyfont Times --headfootsize 10.0 --headfootfont Helvetica --charset iso-8859-1 --links --no-embedfonts --pagemode outline --pagelayout single --firstpage c1 --pageeffect none --pageduration 10 --effectduration 1.0 --no-encryption --permissions all --owner-password \"\" --user-password \"\" --browserwidth 680"
|
||||
|
||||
.PHONY: maketoc check generate all clean validate test
|
||||
.PHONY: maketoc check generate all maintainer-clean validate test
|
||||
|
||||
all: maketoc check generate
|
||||
|
||||
|
|
@ -38,13 +38,13 @@ generate: swightml.book swigpdf.book
|
|||
htmldoc --batch swigpdf.book || true
|
||||
python fixstyle.py SWIGDocumentation.html
|
||||
|
||||
swigpdf.book:
|
||||
swigpdf.book: chapters Sections.html
|
||||
echo "#HTMLDOC 1.8.24" > swigpdf.book
|
||||
echo -t pdf13 -f SWIGDocumentation.pdf $(HTMLDOC_OPTIONS) --stylesheet style.css >> swigpdf.book
|
||||
echo "Sections.html" >> swigpdf.book
|
||||
cat chapters >> swigpdf.book
|
||||
|
||||
swightml.book:
|
||||
swightml.book: chapters Sections.html
|
||||
echo "#HTMLDOC 1.8.24" > swightml.book
|
||||
echo -t html -f SWIGDocumentation.html $(HTMLDOC_OPTIONS) >> swightml.book
|
||||
echo "Sections.html" >> swightml.book
|
||||
|
|
@ -69,7 +69,10 @@ test:
|
|||
validate:
|
||||
all=`sed '/^#/d' chapters`; for a in $$all; do validate --emacs $$a; done;
|
||||
|
||||
# Link checking using linkchecker (can take a while - 30 mins)
|
||||
# Link checking using linkchecker
|
||||
linkchecker:
|
||||
linkchecker --anchors Contents.html
|
||||
@echo -----------------------------------------------------------------------
|
||||
@echo Note linkchecker versions prior to 6.1 do not work properly wrt anchors
|
||||
@echo -----------------------------------------------------------------------
|
||||
linkchecker --config=./linkchecker.config index.html
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Modula3"></a>25 SWIG and Modula-3</H1>
|
||||
<H1><a name="Modula3"></a>27 SWIG and Modula-3</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -54,7 +54,7 @@ especially
|
|||
<a href="Typemaps.html#Typemaps">typemaps</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_modula3_overview"></a>25.1 Overview</H2>
|
||||
<H2><a name="Modula3_modula3_overview"></a>27.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -84,7 +84,7 @@ FFTW
|
|||
</li>
|
||||
</ol>
|
||||
|
||||
<H3><a name="Modula3_motivation"></a>25.1.1 Motivation</H3>
|
||||
<H3><a name="Modula3_motivation"></a>27.1.1 Motivation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -131,10 +131,10 @@ functions), but it doesn't allow you to easily integrate a Module-3 module into
|
|||
a C/C++ project.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_conception"></a>25.2 Conception</H2>
|
||||
<H2><a name="Modula3_conception"></a>27.2 Conception</H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_cinterface"></a>25.2.1 Interfaces to C libraries</H3>
|
||||
<H3><a name="Modula3_cinterface"></a>27.2.1 Interfaces to C libraries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -142,7 +142,7 @@ Modula-3 has integrated support for calling C functions.
|
|||
This is also extensively used by the standard Modula-3 libraries
|
||||
to call OS functions.
|
||||
The Modula-3 part of SWIG and the corresponding SWIG library
|
||||
<a href="../../Lib/modula3/modula3.swg"><tt>modula3.swg</tt></a>
|
||||
modula3.swg
|
||||
contain code that uses these features.
|
||||
Because of the built-in support there is no need
|
||||
for calling the SWIG kernel to generate wrappers written in C.
|
||||
|
|
@ -283,7 +283,7 @@ and the principal type must be renamed (<tt>%typemap</tt>).
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_cppinterface"></a>25.2.2 Interfaces to C++ libraries</H3>
|
||||
<H3><a name="Modula3_cppinterface"></a>27.2.2 Interfaces to C++ libraries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -384,24 +384,23 @@ There is no C++ library I wrote a SWIG interface for,
|
|||
so I'm not sure if this is possible or sensible, yet.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_preliminaries"></a>25.3 Preliminaries</H2>
|
||||
<H2><a name="Modula3_preliminaries"></a>27.3 Preliminaries</H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_compilers"></a>25.3.1 Compilers</H3>
|
||||
<H3><a name="Modula3_compilers"></a>27.3.1 Compilers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
There are different Modula-3 compilers around:
|
||||
cm3, pm3, ezm3, Klagenfurth Modula-3, Cambridge Modula-3.
|
||||
SWIG itself does not contain compiler specific code
|
||||
but the library file
|
||||
<a href="../../Lib/modula3/modula3.swg"><tt>modula3.swg</tt></a>
|
||||
but the modula3.swg library file
|
||||
may do so.
|
||||
For testing examples I use Critical Mass cm3.
|
||||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_commandline"></a>25.3.2 Additional Commandline Options</H3>
|
||||
<H3><a name="Modula3_commandline"></a>27.3.2 Additional Commandline Options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -478,10 +477,10 @@ Instead generate templates for some basic typemaps.
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H2><a name="Modula3_typemaps"></a>25.4 Modula-3 typemaps</H2>
|
||||
<H2><a name="Modula3_typemaps"></a>27.4 Modula-3 typemaps</H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_inoutparam"></a>25.4.1 Inputs and outputs</H3>
|
||||
<H3><a name="Modula3_inoutparam"></a>27.4.1 Inputs and outputs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -499,9 +498,7 @@ or for a return value.
|
|||
A further typemap may specify
|
||||
the direction that is used for certain parameters.
|
||||
I have chosen this separation
|
||||
in order to be able to write general typemaps for the typemap library
|
||||
<a href="../../Lib/modula3/modula3.swg"><tt>modula3.swg</tt></a>
|
||||
.
|
||||
in order to be able to write general typemaps for the modula3.swg typemap library.
|
||||
In the library code the final usage of the type is not known.
|
||||
Using separate typemaps for each possible use
|
||||
allows appropriate definitions for each case.
|
||||
|
|
@ -697,7 +694,7 @@ consist of the following parts:
|
|||
</table>
|
||||
|
||||
|
||||
<H3><a name="Modula3_ordinals"></a>25.4.2 Subranges, Enumerations, Sets</H3>
|
||||
<H3><a name="Modula3_ordinals"></a>27.4.2 Subranges, Enumerations, Sets</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -749,7 +746,7 @@ that I'd like to automate.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_class"></a>25.4.3 Objects</H3>
|
||||
<H3><a name="Modula3_class"></a>27.4.3 Objects</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -762,7 +759,7 @@ is not really useful, yet.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_imports"></a>25.4.4 Imports</H3>
|
||||
<H3><a name="Modula3_imports"></a>27.4.4 Imports</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -782,9 +779,7 @@ Unqualified import is not supported.
|
|||
<p>
|
||||
It is cumbersome to add this typemap to each piece of Modula-3 code.
|
||||
It is especially useful when writing general typemaps
|
||||
for the typemap library
|
||||
<a href="../../Lib/modula3/modula3.swg"><tt>modula3.swg</tt></a>
|
||||
.
|
||||
for the modula3.swg typemap library.
|
||||
For a monolithic module you might be better off
|
||||
if you add the imports directly:
|
||||
</p>
|
||||
|
|
@ -797,7 +792,7 @@ IMPORT M3toC;
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Modula3_exceptions"></a>25.4.5 Exceptions</H3>
|
||||
<H3><a name="Modula3_exceptions"></a>27.4.5 Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -821,7 +816,7 @@ you should declare
|
|||
<tt>%typemap("m3wrapinconv:throws") blah * %{OSError.E%}</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Modula3_typemap_example"></a>25.4.6 Example</H3>
|
||||
<H3><a name="Modula3_typemap_example"></a>27.4.6 Example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -868,10 +863,10 @@ where almost everything is generated by a typemap:
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H2><a name="Modula3_hints"></a>25.5 More hints to the generator</H2>
|
||||
<H2><a name="Modula3_hints"></a>27.5 More hints to the generator</H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_features"></a>25.5.1 Features</H3>
|
||||
<H3><a name="Modula3_features"></a>27.5.1 Features</H3>
|
||||
|
||||
|
||||
<table border summary="Modula-3 features">
|
||||
|
|
@ -908,7 +903,7 @@ where almost everything is generated by a typemap:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Modula3_pragmas"></a>25.5.2 Pragmas</H3>
|
||||
<H3><a name="Modula3_pragmas"></a>27.5.2 Pragmas</H3>
|
||||
|
||||
|
||||
<table border summary="Modula-3 pragmas">
|
||||
|
|
@ -931,7 +926,7 @@ where almost everything is generated by a typemap:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H2><a name="Modula3_remarks"></a>25.6 Remarks</H2>
|
||||
<H2><a name="Modula3_remarks"></a>27.6 Remarks</H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -138,7 +138,8 @@ base class's methods. Typically you will get a warning when the module name is m
|
|||
</p>
|
||||
|
||||
<div class="shell"> <pre>
|
||||
derived_module.i:8: Warning 401: Base class 'base' ignored - unknown module name for base. Either import
|
||||
derived_module.i:8: Warning 401: Base class 'base' ignored - unknown module name for base. Either
|
||||
import
|
||||
the appropriate module interface file or specify the name of the module in the %import directive.
|
||||
</pre></div>
|
||||
|
||||
|
|
|
|||
|
|
@ -2,17 +2,19 @@
|
|||
<!-- Hand-written HTML -->
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG and MzScheme</title>
|
||||
<title>SWIG and MzScheme/Racket</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Mzscheme"></a>26 SWIG and MzScheme</H1>
|
||||
<H1><a name="Mzscheme"></a>28 SWIG and MzScheme/Racket</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#MzScheme_nn2">Creating native MzScheme structures</a>
|
||||
<li><a href="#MzScheme_nn2">Creating native structures</a>
|
||||
<li><a href="#MzScheme_simple">Simple example</a>
|
||||
<li><a href="#MzScheme_external_docs">External documentation</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -20,9 +22,9 @@
|
|||
|
||||
|
||||
<p>
|
||||
This section contains information on SWIG's support of MzScheme.
|
||||
This section contains information on SWIG's support of Racket, formally known as MzScheme.
|
||||
|
||||
<H2><a name="MzScheme_nn2"></a>26.1 Creating native MzScheme structures</H2>
|
||||
<H2><a name="MzScheme_nn2"></a>28.1 Creating native structures</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -63,8 +65,116 @@ Then in scheme, you can use regular struct access procedures like
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="MzScheme_simple"></a>28.2 Simple example</H2>
|
||||
|
||||
|
||||
<p>
|
||||
That's pretty much it. It works with nested structs as well.
|
||||
A few examples are available in the Examples/mzscheme directory.
|
||||
The code and log of a session using SWIG below should help getting started.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
C header file:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
// example.h
|
||||
int fact(int n);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
C source code:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
// File: example.c
|
||||
#include "example.h"
|
||||
|
||||
int fact(int n) {
|
||||
if (n < 0) { /* This should probably return an error, but this is simpler */
|
||||
return 0;
|
||||
}
|
||||
if (n == 0) {
|
||||
return 1;
|
||||
}
|
||||
else {
|
||||
/* testing for overflow would be a good idea here */
|
||||
return n * fact(n-1);
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
SWIG interface file:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File: example.i */
|
||||
%module example
|
||||
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
|
||||
int fact(int n);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The session below using the above files is on an OS X machine, but the points to be made are more general. On OS X, libtool is the tool which creates libraries, which are named .dylib, rather than .so on other unixes, or .dll on Windows.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
% swig -mzscheme -declaremodule example.i
|
||||
% gcc -c -m32 -o example.o example.c # force 32-bit object file (mzscheme is 32-bit only)
|
||||
% libtool -dynamic -o libexample.dylib example.o # make it into a library
|
||||
% ls # what've we got so far?
|
||||
example.c example.o
|
||||
example.h example_wrap.c
|
||||
example.i libexample.dylib*
|
||||
% mzc --cgc --cc example_wrap.c # compile the wrapping code
|
||||
% LDFLAGS="-L. -lexample" mzc --ld example_wrap.dylib example_wrap.o # ...and link it
|
||||
% mzscheme -e '(path->string (build-path "compiled" "native" (system-library-subpath)))'
|
||||
"compiled/native/i386-macosx/3m"
|
||||
% mkdir -p compiled/native/i386-macosx/3m # move the extension library to a magic place
|
||||
% mv example_wrap.dylib compiled/native/i386-macosx/3m/example_ss.dylib
|
||||
% mzscheme
|
||||
Welcome to MzScheme v4.2.4 [3m], Copyright (c) 2004-2010 PLT Scheme Inc.
|
||||
> (require "example.ss")
|
||||
> (fact 5)
|
||||
120
|
||||
> ^D
|
||||
% echo 'It works!'
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<p>
|
||||
Some points of interest:
|
||||
</p>
|
||||
<ul>
|
||||
<li> This is on a 64-bit machine, so we have to include the -m32 option when building the object file
|
||||
<li> If you want to declare a scheme module (and you probably do), it's important that you include the -declaremodule option to swig (if you miss this out, it'll appear to work, but fail later).
|
||||
<li> Use mzc to compile and then link the wrapped code. You'll probably need to adjust the link flags to refer to the library you're wrapping (you can either do this with an LDFLAGS declaration, as here, or with multiple ++ldf options to mzc).
|
||||
<li> Create the directory with path (build-path "compiled" "native" (system-library-subpath)) and move the freshly-generated .dylib to there, changing its name to module-name_ss.dylib. After that, you can REQUIRE the new module with (require "module-name.ss").
|
||||
<li> The above requests mzc to create an extension using the CGC garbage-collector. The alternative -- the 3m collector -- has generally better performance, but work is still required for SWIG to emit code which is compatible with it.
|
||||
</ul>
|
||||
|
||||
<H2><a name="MzScheme_external_docs"></a>28.3 External documentation</H2>
|
||||
|
||||
|
||||
<p>
|
||||
See the <a href="http://docs.racket-lang.org/inside/index.html">C API</a> for more description of using the mechanism for adding extensions. The main documentation is <a href="http://docs.racket-lang.org/">here</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Tip: mzc's --vv option is very useful for debugging the inevitable library problems you'll encounter.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
<body bgcolor="#ffffff">
|
||||
<a name="n1"></a>
|
||||
<H1><a name="Ocaml"></a>27 SWIG and Ocaml</H1>
|
||||
<H1><a name="Ocaml"></a>29 SWIG and Ocaml</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -80,7 +80,7 @@ If you're not familiar with the Objective Caml language, you can visit
|
|||
<a href="http://www.ocaml.org/">The Ocaml Website</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn2"></a>27.1 Preliminaries</H2>
|
||||
<H2><a name="Ocaml_nn2"></a>29.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -93,13 +93,13 @@ examples and test-suite which come with SWIG. You can do this by running
|
|||
The Ocaml module has been tested using the system's dynamic linking (the
|
||||
usual -lxxx against libxxx.so, as well as with Gerd Stolpmann's
|
||||
<a
|
||||
href="http://www.ocaml-programming.de/packages/documentation/dl/">Dl package
|
||||
href="http://download.camlcity.org/download/">Dl package
|
||||
</a>. The ocaml_dynamic and ocaml_dynamic_cpp targets in the
|
||||
file Examples/Makefile illustrate how to compile and link SWIG modules that
|
||||
will be loaded dynamically. This has only been tested on Linux so far.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn3"></a>27.1.1 Running SWIG</H3>
|
||||
<H3><a name="Ocaml_nn3"></a>29.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,11 +122,11 @@ you will compile the file <tt>example_wrap.c</tt> with <tt>ocamlc</tt> or
|
|||
the resulting .ml and .mli files as well, and do the final link with -custom
|
||||
(not needed for native link). </p>
|
||||
|
||||
<H3><a name="Ocaml_nn4"></a>27.1.2 Compiling the code</H3>
|
||||
<H3><a name="Ocaml_nn4"></a>29.1.2 Compiling the code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The O'Caml SWIG module now requires you to compile a module (<tt>Swig</tt>)
|
||||
The OCaml SWIG module now requires you to compile a module (<tt>Swig</tt>)
|
||||
separately. In addition to aggregating common SWIG functionality, the Swig
|
||||
module contains the data structure that represents C/C++ values. This allows
|
||||
easier data sharing between modules if two or more are combined, because
|
||||
|
|
@ -158,7 +158,7 @@ the user more freedom with respect to custom typing.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ocaml_nn5"></a>27.1.3 The camlp4 module</H3>
|
||||
<H3><a name="Ocaml_nn5"></a>29.1.3 The camlp4 module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -234,7 +234,7 @@ let b = C_string (getenv "PATH")
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn6"></a>27.1.4 Using your module</H3>
|
||||
<H3><a name="Ocaml_nn6"></a>29.1.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -248,7 +248,7 @@ When linking any ocaml bytecode with your module, use the -custom
|
|||
option is not needed when you build native code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn7"></a>27.1.5 Compilation problems and compiling with C++</H3>
|
||||
<H3><a name="Ocaml_nn7"></a>29.1.5 Compilation problems and compiling with C++</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -259,7 +259,7 @@ liberal with pointer types may not compile under the C++ compiler.
|
|||
Most code meant to be compiled as C++ will not have problems.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn8"></a>27.2 The low-level Ocaml/C interface</H2>
|
||||
<H2><a name="Ocaml_nn8"></a>29.2 The low-level Ocaml/C interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -360,7 +360,7 @@ is that you must append them to the return list with swig_result = caml_list_a
|
|||
signature for a function that uses value in this way.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn9"></a>27.2.1 The generated module</H3>
|
||||
<H3><a name="Ocaml_nn9"></a>29.2.1 The generated module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -394,7 +394,7 @@ it describes the output SWIG will generate for class definitions.
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn10"></a>27.2.2 Enums</H3>
|
||||
<H3><a name="Ocaml_nn10"></a>29.2.2 Enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -457,7 +457,7 @@ val x : Enum_test.c_obj = C_enum `a
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ocaml_nn11"></a>27.2.2.1 Enum typing in Ocaml</H4>
|
||||
<H4><a name="Ocaml_nn11"></a>29.2.2.1 Enum typing in Ocaml</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -470,10 +470,10 @@ functions imported from different modules. You must convert values to master
|
|||
values using the swig_val function before sharing them with another module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn12"></a>27.2.3 Arrays</H3>
|
||||
<H3><a name="Ocaml_nn12"></a>29.2.3 Arrays</H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn13"></a>27.2.3.1 Simple types of bounded arrays</H4>
|
||||
<H4><a name="Ocaml_nn13"></a>29.2.3.1 Simple types of bounded arrays</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -494,7 +494,7 @@ arrays of simple types with known bounds in your code, but this only works
|
|||
for arrays whose bounds are completely specified.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn14"></a>27.2.3.2 Complex and unbounded arrays</H4>
|
||||
<H4><a name="Ocaml_nn14"></a>29.2.3.2 Complex and unbounded arrays</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -507,7 +507,7 @@ SWIG can't predict which of these methods will be used in the array,
|
|||
so you have to specify it for yourself in the form of a typemap.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn15"></a>27.2.3.3 Using an object</H4>
|
||||
<H4><a name="Ocaml_nn15"></a>29.2.3.3 Using an object</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -521,7 +521,7 @@ Consider writing an object when the ending condition of your array is complex,
|
|||
such as using a required sentinel, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn16"></a>27.2.3.4 Example typemap for a function taking float * and int</H4>
|
||||
<H4><a name="Ocaml_nn16"></a>29.2.3.4 Example typemap for a function taking float * and int</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -572,7 +572,7 @@ void printfloats( float *tab, int len );
|
|||
</pre></td></tr></table>
|
||||
|
||||
|
||||
<H3><a name="Ocaml_nn17"></a>27.2.4 C++ Classes</H3>
|
||||
<H3><a name="Ocaml_nn17"></a>29.2.4 C++ Classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -615,7 +615,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the
|
|||
returned value for the same object.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn18"></a>27.2.4.1 STL vector and string Example</H4>
|
||||
<H4><a name="Ocaml_nn18"></a>29.2.4.1 STL vector and string Example</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -695,7 +695,7 @@ baz
|
|||
#
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn19"></a>27.2.4.2 C++ Class Example</H4>
|
||||
<H4><a name="Ocaml_nn19"></a>29.2.4.2 C++ Class Example</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -725,7 +725,7 @@ public:
|
|||
};
|
||||
</pre></td></tr></table>
|
||||
|
||||
<H4><a name="Ocaml_nn20"></a>27.2.4.3 Compiling the example</H4>
|
||||
<H4><a name="Ocaml_nn20"></a>29.2.4.3 Compiling the example</H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -743,7 +743,7 @@ bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
|
|||
-L$QTPATH/lib -cclib -lqt
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn21"></a>27.2.4.4 Sample Session</H4>
|
||||
<H4><a name="Ocaml_nn21"></a>29.2.4.4 Sample Session</H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -770,10 +770,10 @@ Assuming you have a working installation of QT, you will see a window
|
|||
containing the string "hi" in a button.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn22"></a>27.2.5 Director Classes</H3>
|
||||
<H3><a name="Ocaml_nn22"></a>29.2.5 Director Classes</H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn23"></a>27.2.5.1 Director Introduction</H4>
|
||||
<H4><a name="Ocaml_nn23"></a>29.2.5.1 Director Introduction</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -800,7 +800,7 @@ class foo {
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn24"></a>27.2.5.2 Overriding Methods in Ocaml</H4>
|
||||
<H4><a name="Ocaml_nn24"></a>29.2.5.2 Overriding Methods in Ocaml</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -828,7 +828,7 @@ In this example, I'll examine the objective caml code involved in providing
|
|||
an overloaded class. This example is contained in Examples/ocaml/shapes.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn25"></a>27.2.5.3 Director Usage Example</H4>
|
||||
<H4><a name="Ocaml_nn25"></a>29.2.5.3 Director Usage Example</H4>
|
||||
|
||||
|
||||
<table border="1" bgcolor="#dddddd" summary="Director usage example">
|
||||
|
|
@ -887,7 +887,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the
|
|||
program in C++.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn26"></a>27.2.5.4 Creating director objects</H4>
|
||||
<H4><a name="Ocaml_nn26"></a>29.2.5.4 Creating director objects</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -928,7 +928,7 @@ object from causing a core dump, as long as the object is destroyed
|
|||
properly.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn27"></a>27.2.5.5 Typemaps for directors, <tt>directorin, directorout, directorargout</tt></H4>
|
||||
<H4><a name="Ocaml_nn27"></a>29.2.5.5 Typemaps for directors, <tt>directorin, directorout, directorargout</tt></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -939,7 +939,7 @@ well as a function return value in the same way you provide function arguments,
|
|||
and to receive arguments the same way you normally receive function returns.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn28"></a>27.2.5.6 <tt>directorin</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn28"></a>29.2.5.6 <tt>directorin</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -950,7 +950,7 @@ code receives when you are called. In general, a simple <tt>directorin</tt> typ
|
|||
can use the same body as a simple <tt>out</tt> typemap.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn29"></a>27.2.5.7 <tt>directorout</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn29"></a>29.2.5.7 <tt>directorout</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -961,7 +961,7 @@ for the same type, except when there are special requirements for object
|
|||
ownership, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn30"></a>27.2.5.8 <tt>directorargout</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn30"></a>29.2.5.8 <tt>directorargout</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -978,7 +978,7 @@ In the event that you don't specify all of the necessary values, integral
|
|||
values will read zero, and struct or object returns have undefined results.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn31"></a>27.2.6 Exceptions</H3>
|
||||
<H3><a name="Ocaml_nn31"></a>29.2.6 Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -8,13 +8,14 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Octave"></a>28 SWIG and Octave</H1>
|
||||
<H1><a name="Octave"></a>30 SWIG and Octave</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#Octave_nn2">Preliminaries</a>
|
||||
<li><a href="#Octave_nn3">Running SWIG</a>
|
||||
<ul>
|
||||
<li><a href="#Octave_nn4">Command-line options</a>
|
||||
<li><a href="#Octave_nn5">Compiling a dynamic module</a>
|
||||
<li><a href="#Octave_nn6">Using your module</a>
|
||||
</ul>
|
||||
|
|
@ -46,7 +47,7 @@
|
|||
|
||||
<p>
|
||||
Octave is a high-level language intended for numerical programming that is mostly compatible with MATLAB.
|
||||
More information can be found at <a href="http://www.octave.org">www.octave.org</a>.
|
||||
More information can be found at <a href="http://www.gnu.org/software/octave/">Octave web site</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -54,14 +55,18 @@ More information can be found at <a href="http://www.octave.org">www.octave.org<
|
|||
Also, there are a dozen or so examples in the Examples/octave directory, and hundreds in the test suite (Examples/test-suite and Examples/test-suite/octave).
|
||||
</p>
|
||||
|
||||
<H2><a name="Octave_nn2"></a>28.1 Preliminaries</H2>
|
||||
<H2><a name="Octave_nn2"></a>30.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
The SWIG implemention was first based on Octave 2.9.12, so this is the minimum version required. Testing has only been done on Linux.
|
||||
</p>
|
||||
|
||||
<H2><a name="Octave_nn3"></a>28.2 Running SWIG</H2>
|
||||
<p>
|
||||
As of SWIG 2.0.7, the Octave module has been tested with Octave versions 3.0.5, 3.2.4, 3.4.3, and 3.6.1.
|
||||
</p>
|
||||
|
||||
<H2><a name="Octave_nn3"></a>30.2 Running SWIG</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -80,24 +85,43 @@ extern double Foo; </pre></div>
|
|||
To build an Octave module when wrapping C code, run SWIG using the <tt>-octave</tt> option:
|
||||
</p>
|
||||
|
||||
<div class="shell"><pre>$ swig -octave example.i </pre></div>
|
||||
<div class="shell"><pre>$ swig -octave -o example_wrap.cpp example.i </pre></div>
|
||||
|
||||
<p>
|
||||
The <tt>-c++</tt> option is also required when wrapping C++ code:
|
||||
</p>
|
||||
|
||||
|
||||
<div class="shell"><pre>$ swig -octave -c++ example.i </pre></div>
|
||||
<div class="shell"><pre>$ swig -octave -c++ -o example_wrap.cpp example.i </pre></div>
|
||||
|
||||
<p>
|
||||
This creates a C++ source file <tt>example_wrap.cxx</tt>. A C++ file is generated even when wrapping C code as Octave is itself written in C++ and requires wrapper code to be in the same language. The generated C++ source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application (in this case, the gcd implementation) to create an extension module.
|
||||
This creates a C++ source file "example_wrap.cpp". A C++ file is generated even when wrapping C code as Octave is itself written in C++ and requires wrapper code to be in the same language. The generated C++ source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application (in this case, the gcd implementation) to create an extension module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn4"></a>30.2.1 Command-line options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The swig command line has a number of options you can use, like to redirect it's output. Use <tt>swig --help</tt> to learn about these.
|
||||
The swig command line has a number of options you can use, like to redirect its output. Use <tt>swig -help</tt> to learn about these.
|
||||
Options specific to the Octave module are:
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn5"></a>28.2.1 Compiling a dynamic module</H3>
|
||||
<div class="shell">
|
||||
<pre>$ swig -octave -help
|
||||
...
|
||||
Octave Options (available with -octave)
|
||||
-globals <em>name</em> - Set <em>name</em> used to access C global variables [default: 'cvar']
|
||||
Use '.' to load C global variables into module namespace
|
||||
-opprefix <em>str</em> - Prefix <em>str</em> for global operator functions [default: 'op_']
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The <em>-globals</em> option sets the name of the variable which is the namespace for C global variables exported by the module.
|
||||
The special name "." loads C global variables into the module namespace, i.e. alongside C functions and structs exported by the module.
|
||||
The <em>-opprefix</em> options sets the prefix of the names of global/friend <a href="#Octave_nn18">operator</a> functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn5"></a>30.2.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -106,12 +130,12 @@ Building an oct file is usually done with the mkoctfile command (either within O
|
|||
</p>
|
||||
|
||||
<div class="shell"><pre>
|
||||
$ swig -octave -c++ example.i -o example_wrap.cxx
|
||||
$ mkoctfile example_wrap.cxx example.c
|
||||
$ swig -octave -c++ -o example_wrap.cpp example.i
|
||||
$ mkoctfile example_wrap.cpp example.c
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
where example.c is the file containing the gcd() implementation.
|
||||
where "example.c" is the file containing the gcd() implementation.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -119,12 +143,12 @@ $ mkoctfile example_wrap.cxx example.c
|
|||
</p>
|
||||
|
||||
<p>
|
||||
mkoctfile will produce example.oct, which contains the compiled extension module. Loading it into Octave is then a matter of invoking
|
||||
mkoctfile will produce "example.oct", which contains the compiled extension module. Loading it into Octave is then a matter of invoking
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>octave:1> example</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn6"></a>28.2.2 Using your module</H3>
|
||||
<H3><a name="Octave_nn6"></a>30.2.3 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -142,52 +166,55 @@ octave:4> example.cvar.Foo=4;
|
|||
octave:5> example.cvar.Foo
|
||||
ans = 4 </pre></div>
|
||||
|
||||
<H2><a name="Octave_nn7"></a>28.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Octave_nn7"></a>30.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<H3><a name="Octave_nn8"></a>28.3.1 Modules</H3>
|
||||
<H3><a name="Octave_nn8"></a>30.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The SWIG module directive specifies the name of the Octave module. If you specify `module example', then in Octave everything in the module will be accessible under "example", as in the above example. When choosing a module name, make sure you don't use the same name as a built-in Octave command or standard module name.
|
||||
The SWIG module directive specifies the name of the Octave module. If you specify "module example", then in Octave everything in the module will be accessible under "example", as in the above example. When choosing a module name, make sure you don't use the same name as a built-in Octave command or standard module name.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When Octave is asked to invoke <tt>example</tt>, it will try to find the .m or .oct file that defines the function "example". It will thusly find example.oct, that upon loading will register all of the module's symbols.
|
||||
When Octave is asked to invoke <tt>example</tt>, it will try to find the ".m" or ".oct" file that defines the function "example". You therefore need to make sure that "example.oct" is in Octave's search path, which can be specified with the environment variable "OCTAVE_PATH".
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Giving this function a parameter "global" will cause it to load all symbols into the global namespace in addition to the <tt>example</tt> namespace. For example:
|
||||
To load an Octave module, simply type its name:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>$ octave -q
|
||||
octave:1> example("global")
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> example;
|
||||
octave:2> gcd(4,6)
|
||||
ans = 2
|
||||
octave:3> cvar.Foo
|
||||
ans = 3
|
||||
octave:4> cvar.Foo=4;
|
||||
octave:5> cvar.Foo
|
||||
ans = 4
|
||||
ans = 4
|
||||
</pre></div>
|
||||
<p>
|
||||
It is also possible to rename the module namespace with an assignment, as in: <br>
|
||||
<div class="targetlang"><pre>octave:1> example;
|
||||
octave:2> c=example;
|
||||
octave:3> c.gcd(10,4)
|
||||
ans = 2 </pre></div>
|
||||
|
||||
<p>
|
||||
All global variables are put into the cvar namespace object. This is accessible either as <tt>my_module.cvar</tt>, or just <tt>cvar</tt> (if the module is imported into the global namespace).
|
||||
</p>
|
||||
<p>
|
||||
One can also rename it by simple assignment, e.g.,
|
||||
Modules can also be loaded from within functions, even before being loaded in the base context.
|
||||
If the module is also used in the base context, however, it must first be loaded again:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> some_vars = cvar;
|
||||
octave:1> function l = my_lcm(a,b)
|
||||
> example
|
||||
> l = abs(a*b)/example.gcd(a,b);
|
||||
> endfunction
|
||||
octave:2> my_lcm(4,6)
|
||||
ans = 12
|
||||
octave:3> example.gcd(4,6)
|
||||
error: can't perform indexing operations for <unknown type> type
|
||||
octave:3> example;
|
||||
octave:4> example.gcd(4,6)
|
||||
ans = 2
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn9"></a>28.3.2 Functions</H3>
|
||||
<H3><a name="Octave_nn9"></a>30.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -204,16 +231,16 @@ int fact(int n); </pre></div>
|
|||
<div class="targetlang"><pre>octave:1> example.fact(4)
|
||||
24 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn10"></a>28.3.3 Global variables</H3>
|
||||
<H3><a name="Octave_nn10"></a>30.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Global variables are a little special in Octave. Given a global variable:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>%module example
|
||||
<div class="code"><pre>%module example
|
||||
extern double Foo;
|
||||
</pre></div>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
To expose variables, SWIG actually generates two functions, to get and set the value. In this case, Foo_set and Foo_set would be generated. SWIG then automatically calls these functions when you get and set the variable-- in the former case creating a local copy in the interpreter of the C variables, and in the latter case copying an interpreter variables onto the C variable.
|
||||
|
|
@ -257,7 +284,7 @@ octave:2> example.PI=3.142;
|
|||
octave:3> example.PI
|
||||
ans = 3.1420 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn11"></a>28.3.4 Constants and enums</H3>
|
||||
<H3><a name="Octave_nn11"></a>30.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -279,7 +306,7 @@ example.SCONST="Hello World"
|
|||
example.SUNDAY=0
|
||||
.... </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn12"></a>28.3.5 Pointers</H3>
|
||||
<H3><a name="Octave_nn12"></a>30.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -326,7 +353,7 @@ octave:2> f=example.fopen("not there","r");
|
|||
error: value on right hand side of assignment is undefined
|
||||
error: evaluating assignment expression near line 2, column 2 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn13"></a>28.3.6 Structures and C++ classes</H3>
|
||||
<H3><a name="Octave_nn13"></a>30.3.6 Structures and C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -461,7 +488,7 @@ ans = 1
|
|||
Depending on the ownership setting of a <tt>swig_ref</tt>, it may call C++ destructors when its reference count goes to zero. See the section on memory management below for details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn15"></a>28.3.7 C++ inheritance</H3>
|
||||
<H3><a name="Octave_nn15"></a>30.3.7 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -470,7 +497,7 @@ This information contains the full class hierarchy. When an indexing operation (
|
|||
the tree is walked to find a match in the current class as well as any of its bases. The lookup is then cached in the <tt>swig_ref</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn17"></a>28.3.8 C++ overloaded functions</H3>
|
||||
<H3><a name="Octave_nn17"></a>30.3.8 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -480,7 +507,7 @@ The dispatch function selects which overload to call (if any) based on the passe
|
|||
<tt>typecheck</tt> typemaps are used to analyze each argument, as well as assign precedence. See the chapter on typemaps for details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn18"></a>28.3.9 C++ operators</H3>
|
||||
<H3><a name="Octave_nn18"></a>30.3.9 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -580,7 +607,11 @@ On the C++ side, the default mappings are as follows:
|
|||
%rename(__brace) *::operator[];
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn19"></a>28.3.10 Class extension with %extend</H3>
|
||||
<p>
|
||||
Octave can also utilise friend (i.e. non-member) operators with a simple %rename: see the example in the Examples/octave/operator directory.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn19"></a>30.3.10 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -610,7 +641,7 @@ octave:3> printf("%s\n",a);
|
|||
octave:4> a.__str()
|
||||
4
|
||||
</pre></div>
|
||||
<H3><a name="Octave_nn20"></a>28.3.11 C++ templates</H3>
|
||||
<H3><a name="Octave_nn20"></a>30.3.11 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -687,14 +718,14 @@ ans =
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Octave_nn21"></a>28.3.12 C++ Smart Pointers</H3>
|
||||
<H3><a name="Octave_nn21"></a>30.3.12 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
C++ smart pointers are fully supported as in other modules.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn22"></a>28.3.13 Directors (calling Octave from C++ code)</H3>
|
||||
<H3><a name="Octave_nn22"></a>30.3.13 Directors (calling Octave from C++ code)</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -755,7 +786,8 @@ Note that you have to enable directors via the %feature directive (see other mod
|
|||
<tt>subclass()</tt> will accept any number of C++ bases or other <tt>subclass()</tt>'ed objects, <tt>(string,octave_value)</tt> pairs, and <tt>function_handles</tt>. In the first case, these are taken as base classes; in the second case, as named members (either variables or functions, depending on whether the given value is a function handle); in the third case, as member functions whose name is taken from the given function handle. E.g.,
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> B=@(some_var=2) subclass(A(),'some_var',some_var,@some_func,'another_func',@(self) do_stuff())
|
||||
octave:1> B=@(some_var=2) subclass(A(),'some_var',some_var,@some_func,'another_func',
|
||||
@(self) do_stuff())
|
||||
</pre></div>
|
||||
<p>
|
||||
You can also assign non-C++ member variables and functions after construct time. There is no support for non-C++ static members.
|
||||
|
|
@ -774,14 +806,14 @@ c-side routine called
|
|||
octave-side routine called
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn23"></a>28.3.14 Threads</H3>
|
||||
<H3><a name="Octave_nn23"></a>30.3.14 Threads</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The use of threads in wrapped Director code is not supported; i.e., an Octave-side implementation of a C++ class must be called from the Octave interpreter's thread. Anything fancier (apartment/queue model, whatever) is left to the user. Without anything fancier, this amounts to the limitation that Octave must drive the module... like, for example, an optimization package that calls Octave to evaluate an objective function.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn24"></a>28.3.15 Memory management</H3>
|
||||
<H3><a name="Octave_nn24"></a>30.3.15 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -815,14 +847,14 @@ The %newobject directive may be used to control this behavior for pointers retur
|
|||
In the case where one wishes for the C++ side to own an object that was created in Octave (especially a Director object), one can use the __disown() method to invert this logic. Then letting the Octave reference count go to zero will not destroy the object, but destroying the object will invalidate the Octave-side object if it still exists (and call destructors of other C++ bases in the case of multiple inheritance/<tt>subclass()</tt>'ing).
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn25"></a>28.3.16 STL support</H3>
|
||||
<H3><a name="Octave_nn25"></a>30.3.16 STL support</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Various STL library files are provided for wrapping STL containers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn26"></a>28.3.17 Matrix typemaps</H3>
|
||||
<H3><a name="Octave_nn26"></a>30.3.17 Matrix typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Perl5"></a>29 SWIG and Perl5</H1>
|
||||
<H1><a name="Perl5"></a>31 SWIG and Perl5</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -82,12 +82,12 @@
|
|||
This chapter describes SWIG's support of Perl5. Although the Perl5
|
||||
module is one of the earliest SWIG modules, it has continued to evolve
|
||||
and has been improved greatly with the help of SWIG users. For the
|
||||
best results, it is recommended that SWIG be used with Perl5.003 or
|
||||
later. Earlier versions are problematic and SWIG generated extensions
|
||||
may not compile or run correctly.
|
||||
best results, it is recommended that SWIG be used with Perl 5.8 or
|
||||
later. We're no longer testing regularly with older versions, but
|
||||
Perl 5.6 seems to mostly work, while older versions don't.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn2"></a>29.1 Overview</H2>
|
||||
<H2><a name="Perl5_nn2"></a>31.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -108,12 +108,12 @@ described. Advanced customization features, typemaps, and other
|
|||
options are found near the end of the chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn3"></a>29.2 Preliminaries</H2>
|
||||
<H2><a name="Perl5_nn3"></a>31.2 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
To build a Perl5 module, run SWIG using the <tt>-perl</tt> option as
|
||||
follows :
|
||||
follows:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -133,11 +133,11 @@ To build the module, you will need to compile the file
|
|||
<tt>example_wrap.c</tt> and link it with the rest of your program.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn4"></a>29.2.1 Getting the right header files</H3>
|
||||
<H3><a name="Perl5_nn4"></a>31.2.1 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
In order to compile, SWIG extensions need the following Perl5 header files :</p>
|
||||
In order to compile, SWIG extensions need the following Perl5 header files:</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
#include "Extern.h"
|
||||
|
|
@ -149,36 +149,36 @@ In order to compile, SWIG extensions need the following Perl5 header files :</p>
|
|||
These are typically located in a directory like this</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
/usr/lib/perl5/5.00503/i386-linux/CORE
|
||||
/usr/lib/perl/5.14/CORE
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The SWIG configuration script automatically tries to locate this directory so
|
||||
that it can compile examples. However, if you need to find out where the directory is
|
||||
loaded, an easy way to find out is to run Perl itself.
|
||||
located, an easy way to find out is to ask Perl itself:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
% perl -e 'use Config; print $Config{archlib};'
|
||||
/usr/lib/perl5/5.00503/i386-linux
|
||||
$ perl -e 'use Config; print "$Config{archlib}\n";'
|
||||
/usr/lib/perl/5.14
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn5"></a>29.2.2 Compiling a dynamic module</H3>
|
||||
<H3><a name="Perl5_nn5"></a>31.2.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The preferred approach to building an extension module is to compile it into
|
||||
a shared object file or DLL. To do this, you will need to compile your program
|
||||
using commands like this (shown for Linux):
|
||||
a shared object file or DLL. Assuming you have code you need to link to in a file called <tt>example.c</tt>,
|
||||
you will need to compile your program using commands like this (shown for Linux):
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
$ swig -perl example.i
|
||||
% gcc example.c
|
||||
% gcc -c example_wrap.c -I/usr/lib/perl5/5.00503/i386-linux/CORE -Dbool=char
|
||||
% gcc -shared example.o example_wrap.o -o example.so
|
||||
$ gcc -fPIC example.c
|
||||
$ gcc -fPIC -c example_wrap.c -I/usr/lib/perl/5.14/CORE -Dbool=char
|
||||
$ gcc -shared example.o example_wrap.o -o example.so
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -198,13 +198,13 @@ the target should be named `<tt>example.so</tt>',
|
|||
`<tt>example.sl</tt>', or the appropriate dynamic module name on your system.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn6"></a>29.2.3 Building a dynamic module with MakeMaker</H3>
|
||||
<H3><a name="Perl5_nn6"></a>31.2.3 Building a dynamic module with MakeMaker</H3>
|
||||
|
||||
|
||||
<p>
|
||||
It is also possible to use Perl to build dynamically loadable modules
|
||||
for you using the MakeMaker utility. To do this, write a Perl
|
||||
script such as the following :</p>
|
||||
script such as the following:</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
# File : Makefile.PL
|
||||
|
|
@ -218,12 +218,12 @@ WriteMakefile(
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
Now, to build a module, simply follow these steps :</p>
|
||||
Now, to build a module, simply follow these steps:</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% perl Makefile.PL
|
||||
% make
|
||||
% make install
|
||||
$ perl Makefile.PL
|
||||
$ make
|
||||
$ make install
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -232,17 +232,17 @@ the preferred approach to compilation. More information about MakeMaker can be
|
|||
found in "Programming Perl, 2nd ed." by Larry Wall, Tom Christiansen,
|
||||
and Randal Schwartz.</p>
|
||||
|
||||
<H3><a name="Perl5_nn7"></a>29.2.4 Building a static version of Perl</H3>
|
||||
<H3><a name="Perl5_nn7"></a>31.2.4 Building a static version of Perl</H3>
|
||||
|
||||
|
||||
<p>
|
||||
If you machine does not support dynamic loading or if you've tried to
|
||||
use it without success, you can build a new version of the Perl
|
||||
interpreter with your SWIG extensions added to it. To build a static
|
||||
extension, you first need to invoke SWIG as follows :</p>
|
||||
extension, you first need to invoke SWIG as follows:</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -perl -static example.i
|
||||
$ swig -perl -static example.i
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -253,7 +253,7 @@ By default SWIG includes code for dynamic loading, but the
|
|||
Next, you will need to supply a <tt>main()</tt> function that
|
||||
initializes your extension and starts the Perl interpreter. While,
|
||||
this may sound daunting, SWIG can do this for you automatically as
|
||||
follows :</p>
|
||||
follows:</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
%module example
|
||||
|
|
@ -268,10 +268,10 @@ extern int fact(int);
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
The same thing can be accomplished by running SWIG as follows :</p>
|
||||
The same thing can be accomplished by running SWIG as follows:</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -perl -static -lperlmain.i example.i
|
||||
$ swig -perl -static -lperlmain.i example.i
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -290,7 +290,7 @@ for a dynamic module, but change the link line to something like this:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% gcc example.o example_wrap.o -L/usr/lib/perl5/5.00503/i386-linux/CORE \
|
||||
$ gcc example.o example_wrap.o -L/usr/lib/perl/5.14/CORE \
|
||||
-lperl -lsocket -lnsl -lm -o myperl
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -301,7 +301,7 @@ added to it. Depending on your machine, you may need to link with
|
|||
additional libraries such as <tt>-lsocket, -lnsl, -ldl</tt>, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn8"></a>29.2.5 Using the module</H3>
|
||||
<H3><a name="Perl5_nn8"></a>31.2.5 Using the module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -323,9 +323,7 @@ A common error received by first-time users is the following:
|
|||
<div class="targetlang">
|
||||
<pre>
|
||||
use example;
|
||||
Can't locate example.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-lin
|
||||
ux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/pe
|
||||
rl5/site_perl/5.005 .) at - line 1.
|
||||
Can't locate example.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at - line 1.
|
||||
BEGIN failed--compilation aborted at - line 1.
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -363,7 +361,7 @@ Another common error is the following:
|
|||
<pre>
|
||||
use example;
|
||||
Can't load './example.so' for module example: ./example.so:
|
||||
undefined symbol: Foo at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169.
|
||||
undefined symbol: Foo at /usr/lib/perl/5.14/i386-linux/DynaLoader.pm line 169.
|
||||
|
||||
at - line 1
|
||||
BEGIN failed--compilation aborted at - line 1.
|
||||
|
|
@ -409,7 +407,7 @@ error when you try to use your module:
|
|||
<pre>
|
||||
use example;
|
||||
Can't load './example.so' for module example: libfoo.so: cannot open shared object file:
|
||||
No such file or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169.
|
||||
No such file or directory at /usr/lib/perl/5.14/i386-linux/DynaLoader.pm line 169.
|
||||
|
||||
at - line 1
|
||||
BEGIN failed--compilation aborted at - line 1.
|
||||
|
|
@ -456,7 +454,7 @@ system configuration (this requires root access and you will need to
|
|||
read the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn9"></a>29.2.6 Compilation problems and compiling with C++</H3>
|
||||
<H3><a name="Perl5_nn9"></a>31.2.6 Compilation problems and compiling with C++</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -472,10 +470,10 @@ compiler. For example:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -c++ -perl example.i
|
||||
% g++ -c example.cxx
|
||||
% g++ -c example_wrap.cxx -I/usr/lib/perl5/5.00503/i386-linux/CORE
|
||||
% <b>g++ -shared example.o example_wrap.o -o example.so</b>
|
||||
$ swig -c++ -perl example.i
|
||||
$ g++ -fPIC -c example.cxx
|
||||
$ g++ -fPIC -c example_wrap.cxx -I/usr/lib/perl/5.14/i386-linux/CORE
|
||||
$ <b>g++ -shared example.o example_wrap.o -o example.so</b>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -485,10 +483,10 @@ Solaris, you often need to add an extra library <tt>-lCrun</tt> like this:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -c++ -perl example.i
|
||||
% g++ -c example.cxx
|
||||
% g++ -c example_wrap.cxx -I/usr/lib/perl5/5.00503/i386-linux/CORE
|
||||
% g++ -shared example.o example_wrap.o -o example.so <b>-lCrun</b>
|
||||
$ swig -c++ -perl example.i
|
||||
$ CC -c example.cxx
|
||||
$ CC -c example_wrap.cxx -I/usr/lib/perl/5.14/i386-linux/CORE
|
||||
$ CC -shared example.o example_wrap.o -o example.so <b>-lCrun</b>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -503,7 +501,7 @@ it needs to be. So you should compile the wrapper like:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% g++ -c example_wrap.cxx -I/usr/lib/perl/5.8.0/CORE -D_GNU_SOURCE
|
||||
$ g++ -fPIC -c example_wrap.cxx -I/usr/lib/perl/5.8.0/CORE -D_GNU_SOURCE
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -511,7 +509,7 @@ it needs to be. So you should compile the wrapper like:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% perl -e 'use Config; print $Config{ccflags};'
|
||||
$ perl -e 'use Config; print "$Config{ccflags}\n";'
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -519,8 +517,8 @@ So you could also compile the wrapper like
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% g++ -c example_wrap.cxx -I/usr/lib/perl/5.8.0/CORE \
|
||||
`perl -e 'use Config; print $Config{ccflags}'`
|
||||
$ g++ -fPIC -c example_wrap.cxx -I/usr/lib/perl/5.8.0/CORE \
|
||||
`perl -MConfig -e 'print $Config{ccflags}'`
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -568,8 +566,8 @@ can behave strangely when working with multiple modules.
|
|||
|
||||
<p>
|
||||
It should be noted that you may get a lot of error messages
|
||||
about the `<tt>bool</tt>' datatype when compiling a C++ Perl module. If
|
||||
you experience this problem, you can try the following :</p>
|
||||
about the '<tt>bool</tt>' datatype when compiling a C++ Perl module. If
|
||||
you experience this problem, you can try the following:</p>
|
||||
|
||||
<ul>
|
||||
<li>Use <tt>-DHAS_BOOL</tt> when compiling the SWIG wrapper code
|
||||
|
|
@ -599,7 +597,7 @@ have to find the macro that conflicts and add an #undef into the .i file. Pleas
|
|||
any conflicting macros you find to <a href="http://www.swig.org/mail.html">swig-user mailing list</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn10"></a>29.2.7 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Perl5_nn10"></a>31.2.7 Compiling for 64-bit platforms</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -626,7 +624,7 @@ also introduce problems on platforms that support more than one
|
|||
linking standard (e.g., -o32 and -n32 on Irix).
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn11"></a>29.3 Building Perl Extensions under Windows</H2>
|
||||
<H2><a name="Perl5_nn11"></a>31.3 Building Perl Extensions under Windows</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -637,13 +635,13 @@ section assumes you are using SWIG with Microsoft Visual C++
|
|||
although the procedure may be similar with other compilers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn12"></a>29.3.1 Running SWIG from Developer Studio</H3>
|
||||
<H3><a name="Perl5_nn12"></a>31.3.1 Running SWIG from Developer Studio</H3>
|
||||
|
||||
|
||||
<p>
|
||||
If you are developing your application within Microsoft developer
|
||||
studio, SWIG can be invoked as a custom build option. The process
|
||||
roughly requires these steps :</p>
|
||||
roughly requires these steps:</p>
|
||||
|
||||
<ul>
|
||||
<li>Open up a new workspace and use the AppWizard to select a DLL
|
||||
|
|
@ -651,7 +649,7 @@ project.
|
|||
|
||||
<li>Add both the SWIG interface file (the .i file), any supporting C
|
||||
files, and the name of the wrapper file that will be created by SWIG
|
||||
(ie. <tt>example_wrap.c</tt>). Note : If using C++, choose a
|
||||
(ie. <tt>example_wrap.c</tt>). Note: If using C++, choose a
|
||||
different suffix for the wrapper file such as
|
||||
<tt>example_wrap.cxx</tt>. Don't worry if the wrapper file doesn't
|
||||
exist yet--Developer studio will keep a reference to it around.
|
||||
|
|
@ -689,7 +687,7 @@ Now, assuming you made it this far, SWIG will be automatically invoked when
|
|||
you build your project. Any changes made to the interface file will
|
||||
result in SWIG being automatically invoked to produce a new version of
|
||||
the wrapper file. To run your new Perl extension, simply run Perl and
|
||||
use the use command as normal. For example :
|
||||
use the use command as normal. For example:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -700,7 +698,7 @@ print "$a\n";
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn13"></a>29.3.2 Using other compilers</H3>
|
||||
<H3><a name="Perl5_nn13"></a>31.3.2 Using other compilers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -708,7 +706,7 @@ SWIG is known to work with Cygwin and may work with other compilers on Windows.
|
|||
For general hints and suggestions refer to the <a href="Windows.html#Windows">Windows</a> chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn14"></a>29.4 The low-level interface</H2>
|
||||
<H2><a name="Perl5_nn14"></a>31.4 The low-level interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -718,7 +716,7 @@ can be used to control your application. However, it is also used to
|
|||
construct more user-friendly proxy classes as described in the next section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn15"></a>29.4.1 Functions</H3>
|
||||
<H3><a name="Perl5_nn15"></a>31.4.1 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -741,7 +739,7 @@ use example;
|
|||
$a = &example::fact(2);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn16"></a>29.4.2 Global variables</H3>
|
||||
<H3><a name="Perl5_nn16"></a>31.4.2 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -758,7 +756,7 @@ double Spam;
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
is accessed as follows :</p>
|
||||
is accessed as follows:</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
use example;
|
||||
|
|
@ -811,7 +809,7 @@ extern char *path; // Declared later in the input
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn17"></a>29.4.3 Constants</H3>
|
||||
<H3><a name="Perl5_nn17"></a>31.4.3 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -851,14 +849,14 @@ print example::FOO,"\n";
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn18"></a>29.4.4 Pointers</H3>
|
||||
<H3><a name="Perl5_nn18"></a>31.4.4 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG represents pointers as blessed references. A blessed reference
|
||||
is the same as a Perl reference except that it has additional
|
||||
information attached to it indicating what kind of reference it
|
||||
is. That is, if you have a C declaration like this :</p>
|
||||
is. That is, if you have a C declaration like this:</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
Matrix *new_Matrix(int n, int m);
|
||||
|
|
@ -880,7 +878,7 @@ generated.</p>
|
|||
|
||||
<p>
|
||||
To check to see if a value is the NULL pointer, use the
|
||||
<tt>defined()</tt> command :</p>
|
||||
<tt>defined()</tt> command:</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
if (defined($ptr)) {
|
||||
|
|
@ -904,7 +902,7 @@ In general, <tt>$a</tt> and <tt>$b</tt> will be different--since they
|
|||
are different references. Thus, it is a mistake to check the equality
|
||||
of <tt>$a</tt> and <tt>$b</tt> to check the equality of two C
|
||||
pointers. The correct method to check equality of C pointers is to
|
||||
dereference them as follows :
|
||||
dereference them as follows:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -960,7 +958,7 @@ as XS and <tt>xsubpp</tt>. Given the advancement of the SWIG typesystem and the
|
|||
SWIG and XS, this is no longer supported.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn19"></a>29.4.5 Structures</H3>
|
||||
<H3><a name="Perl5_nn19"></a>31.4.5 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1094,12 +1092,12 @@ void Bar_f_set(Bar *b, Foo *val) {
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn20"></a>29.4.6 C++ classes</H3>
|
||||
<H3><a name="Perl5_nn20"></a>31.4.6 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
C++ classes are wrapped by building a set of low level accessor functions.
|
||||
Consider the following class :
|
||||
Consider the following class:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -1117,7 +1115,7 @@ static void print(List *l);
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
When wrapped by SWIG, the following functions are created :
|
||||
When wrapped by SWIG, the following functions are created:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -1159,7 +1157,7 @@ provides direct access to C++ objects. A higher level interface using Perl prox
|
|||
can be built using these low-level accessors. This is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn21"></a>29.4.7 C++ classes and type-checking</H3>
|
||||
<H3><a name="Perl5_nn21"></a>31.4.7 C++ classes and type-checking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1195,7 +1193,7 @@ If necessary, the type-checker also adjusts the value of the pointer (as is nece
|
|||
multiple inheritance is used).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn22"></a>29.4.8 C++ overloaded functions</H3>
|
||||
<H3><a name="Perl5_nn22"></a>31.4.8 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1239,7 +1237,7 @@ example::Spam_foo_d($s,3.14);
|
|||
Please refer to the "SWIG Basics" chapter for more information.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn23"></a>29.4.9 Operators</H3>
|
||||
<H3><a name="Perl5_nn23"></a>31.4.9 Operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1266,17 +1264,17 @@ The following C++ operators are currently supported by the Perl module:
|
|||
<li>operator or </li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Perl5_nn24"></a>29.4.10 Modules and packages</H3>
|
||||
<H3><a name="Perl5_nn24"></a>31.4.10 Modules and packages</H3>
|
||||
|
||||
|
||||
<p>
|
||||
When you create a SWIG extension, everything gets placed into
|
||||
a single Perl module. The name of the module is determined by the
|
||||
<tt>%module</tt> directive. To use the module, do the following :
|
||||
<tt>%module</tt> directive. To use the module, do the following:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
% perl5
|
||||
$ perl5
|
||||
use example; # load the example module
|
||||
print example::fact(4),"\n" # Call a function in it
|
||||
24
|
||||
|
|
@ -1342,17 +1340,17 @@ nested namespace simply provide the fully qualified name in your
|
|||
<!--
|
||||
<p>
|
||||
This can be changed by giving SWIG the -package
|
||||
option :
|
||||
option:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -perl -package Foo example.i
|
||||
$ swig -perl -package Foo example.i
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
In this case, you still create a module called `<tt>example</tt>' exactly as before, but
|
||||
all of the functions in that module will be installed into the package
|
||||
`<tt>Foo</tt>.' For example :
|
||||
`<tt>Foo</tt>.' For example:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -1361,7 +1359,7 @@ print Foo::fact(4),"\n"; # Call a function in package FooBar
|
|||
</pre></div>
|
||||
-->
|
||||
|
||||
<H2><a name="Perl5_nn25"></a>29.5 Input and output parameters</H2>
|
||||
<H2><a name="Perl5_nn25"></a>31.5 Input and output parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1580,7 +1578,7 @@ print "$c\n";
|
|||
<b>Note:</b> The <tt>REFERENCE</tt> feature is only currently supported for numeric types (integers and floating point).
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn26"></a>29.6 Exception handling</H2>
|
||||
<H2><a name="Perl5_nn26"></a>31.6 Exception handling</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1588,7 +1586,7 @@ The SWIG <tt>%exception</tt> directive can be used to create a
|
|||
user-definable exception handler for converting exceptions in your
|
||||
C/C++ program into Perl exceptions. The chapter on customization features
|
||||
contains more details, but suppose you have a C++ class like the
|
||||
following :
|
||||
following:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -1745,7 +1743,7 @@ This is still supported, but it is deprecated. The newer <tt>%exception</tt> di
|
|||
functionality, but it has additional capabilities that make it more powerful.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn27"></a>29.7 Remapping datatypes with typemaps</H2>
|
||||
<H2><a name="Perl5_nn27"></a>31.7 Remapping datatypes with typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1762,7 +1760,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Perl interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn28"></a>29.7.1 A simple typemap example</H3>
|
||||
<H3><a name="Perl5_nn28"></a>31.7.1 A simple typemap example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1796,7 +1794,7 @@ The <tt>$input</tt> variable is the input object (usually a <tt>SV *</tt>).
|
|||
</p>
|
||||
|
||||
<p>
|
||||
When this example is used in Perl5, it will operate as follows :
|
||||
When this example is used in Perl5, it will operate as follows:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -1805,7 +1803,7 @@ $n = example::fact(6);
|
|||
print "$n\n";
|
||||
...
|
||||
|
||||
Output :
|
||||
Output:
|
||||
Received an integer : 6
|
||||
720
|
||||
</pre></div>
|
||||
|
|
@ -1866,7 +1864,7 @@ example::count("e","Hello World");
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn29"></a>29.7.2 Perl5 typemaps</H3>
|
||||
<H3><a name="Perl5_nn29"></a>31.7.2 Perl5 typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1971,7 +1969,7 @@ Return of C++ member data (all languages).
|
|||
Check value of input parameter.
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn30"></a>29.7.3 Typemap variables</H3>
|
||||
<H3><a name="Perl5_nn30"></a>31.7.3 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2042,7 +2040,7 @@ properly assigned.
|
|||
The Perl name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn31"></a>29.7.4 Useful functions</H3>
|
||||
<H3><a name="Perl5_nn31"></a>31.7.4 Useful functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2111,7 +2109,7 @@ int sv_isa(SV *, char *0;
|
|||
</div>
|
||||
|
||||
|
||||
<H2><a name="Perl5_nn32"></a>29.8 Typemap Examples</H2>
|
||||
<H2><a name="Perl5_nn32"></a>31.8 Typemap Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2120,7 +2118,7 @@ might look at the files "<tt>perl5.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn33"></a>29.8.1 Converting a Perl5 array to a char **</H3>
|
||||
<H3><a name="Perl5_nn33"></a>31.8.1 Converting a Perl5 array to a char **</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2200,7 +2198,7 @@ char **get_args() {
|
|||
|
||||
<p>
|
||||
When this module is compiled, the wrapped C functions can be used in a
|
||||
Perl script as follows :
|
||||
Perl script as follows:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -2212,7 +2210,7 @@ print @$b,"\n"; # Print it out
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn34"></a>29.8.2 Return values</H3>
|
||||
<H3><a name="Perl5_nn34"></a>31.8.2 Return values</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2227,7 +2225,7 @@ number of output values.
|
|||
<p>
|
||||
The total number of return values should not exceed the number of
|
||||
input values unless you explicitly extend the argument stack. This
|
||||
can be done using the <tt>EXTEND()</tt> macro as in :
|
||||
can be done using the <tt>EXTEND()</tt> macro as in:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2241,7 +2239,7 @@ can be done using the <tt>EXTEND()</tt> macro as in :
|
|||
}
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn35"></a>29.8.3 Returning values from arguments</H3>
|
||||
<H3><a name="Perl5_nn35"></a>31.8.3 Returning values from arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2286,7 +2284,7 @@ int multout(double a, double b, double *OUTPUT, double *OUTPUT);
|
|||
<p>
|
||||
When this function is called, the output arguments are appended to the stack used
|
||||
to return results. This shows up an array in Perl.
|
||||
For example :
|
||||
For example:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -2295,11 +2293,11 @@ print "multout(7,13) = @r\n";
|
|||
($x,$y) = multout(7,13);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn36"></a>29.8.4 Accessing array structure members</H3>
|
||||
<H3><a name="Perl5_nn36"></a>31.8.4 Accessing array structure members</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Consider the following data structure :
|
||||
Consider the following data structure:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2358,13 +2356,13 @@ the "in" typemap in the previous section would be used to convert an
|
|||
to copy the converted array into a C data structure.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn37"></a>29.8.5 Turning Perl references into C pointers</H3>
|
||||
<H3><a name="Perl5_nn37"></a>31.8.5 Turning Perl references into C pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
A frequent confusion on the SWIG mailing list is errors caused by the
|
||||
mixing of Perl references and C pointers. For example, suppose you
|
||||
have a C function that modifies its arguments like this :
|
||||
have a C function that modifies its arguments like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2374,7 +2372,7 @@ void add(double a, double b, double *c) {
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
A common misinterpretation of this function is the following Perl script :
|
||||
A common misinterpretation of this function is the following Perl script:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -2411,7 +2409,7 @@ To make this work with a reference, you can use a typemap such as this:
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
Now, if you place this before the add function, you can do this :
|
||||
Now, if you place this before the add function, you can do this:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -2423,7 +2421,7 @@ print "$c\n";
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn38"></a>29.8.6 Pointer handling</H3>
|
||||
<H3><a name="Perl5_nn38"></a>31.8.6 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2502,7 +2500,7 @@ For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Perl5_nn39"></a>29.9 Proxy classes</H2>
|
||||
<H2><a name="Perl5_nn39"></a>31.9 Proxy classes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2518,7 +2516,7 @@ to the underlying code. This section describes the implementation
|
|||
details of the proxy interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn40"></a>29.9.1 Preliminaries</H3>
|
||||
<H3><a name="Perl5_nn40"></a>31.9.1 Preliminaries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2540,11 +2538,11 @@ SWIG creates a collection of high-level Perl wrappers. In your scripts, you wil
|
|||
high level wrappers. The wrappers, in turn, interact with the low-level procedural module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn41"></a>29.9.2 Structure and class wrappers</H3>
|
||||
<H3><a name="Perl5_nn41"></a>31.9.2 Structure and class wrappers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Suppose you have the following SWIG interface file :
|
||||
Suppose you have the following SWIG interface file:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2666,13 +2664,13 @@ $v->DESTROY();
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn42"></a>29.9.3 Object Ownership</H3>
|
||||
<H3><a name="Perl5_nn42"></a>31.9.3 Object Ownership</H3>
|
||||
|
||||
|
||||
<p>
|
||||
In order for proxy classes to work properly, it is necessary for Perl
|
||||
to manage some mechanism of object ownership. Here's the crux of the
|
||||
problem---suppose you had a function like this :
|
||||
problem---suppose you had a function like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2685,7 +2683,7 @@ Vector *Vector_get(Vector *v, int index) {
|
|||
This function takes a Vector pointer and returns a pointer to another
|
||||
Vector. Such a function might be used to manage arrays or lists of
|
||||
vectors (in C). Now contrast this function with the constructor for a
|
||||
Vector object :
|
||||
Vector object:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2753,11 +2751,11 @@ counting, garbage collection, or advanced features one might find in
|
|||
sophisticated languages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn43"></a>29.9.4 Nested Objects</H3>
|
||||
<H3><a name="Perl5_nn43"></a>31.9.4 Nested Objects</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Suppose that we have a new object that looks like this :
|
||||
Suppose that we have a new object that looks like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2774,7 +2772,7 @@ struct Particle {
|
|||
In this case, the members of the structure are complex objects that
|
||||
have already been encapsulated in a Perl proxy class. To handle
|
||||
these correctly, we use the <tt>%BLESSEDMEMBERS</tt> hash which would
|
||||
look like this (along with some supporting code) :
|
||||
look like this (along with some supporting code):
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -2796,7 +2794,7 @@ unmodified.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
This implementation allows us to operate on nested structures as follows :
|
||||
This implementation allows us to operate on nested structures as follows:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -2806,12 +2804,12 @@ $p->{f}->{x} = 0.0;
|
|||
%${$p->{v}} = ( x=>0, y=>0, z=>0);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn44"></a>29.9.5 Proxy Functions</H3>
|
||||
<H3><a name="Perl5_nn44"></a>31.9.5 Proxy Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
When functions take arguments involving a complex object, it is
|
||||
sometimes necessary to write a proxy function. For example :
|
||||
sometimes necessary to write a proxy function. For example:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2822,7 +2820,7 @@ double dot_product(Vector *v1, Vector *v2);
|
|||
Since Vector is an object already wrapped into a proxy class, we need
|
||||
to modify this function to accept arguments that are given in the form
|
||||
of tied hash tables. This is done by creating a Perl function like
|
||||
this :
|
||||
this:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -2840,13 +2838,13 @@ This function replaces the original function, but operates in an
|
|||
identical manner.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn45"></a>29.9.6 Inheritance</H3>
|
||||
<H3><a name="Perl5_nn45"></a>31.9.6 Inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Simple C++ inheritance is handled using the Perl <tt>@ISA</tt> array
|
||||
in each class package. For example, if you have the following
|
||||
interface file :
|
||||
interface file:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2881,7 +2879,7 @@ public:
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
The resulting, Perl wrapper class will create the following code :
|
||||
The resulting, Perl wrapper class will create the following code:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -2916,7 +2914,7 @@ particular, inheritance of data members is extremely tricky (and I'm
|
|||
not even sure if it really works).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn46"></a>29.9.7 Modifying the proxy methods</H3>
|
||||
<H3><a name="Perl5_nn46"></a>31.9.7 Modifying the proxy methods</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2944,7 +2942,7 @@ public:
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Perl5_nn47"></a>29.10 Adding additional Perl code</H2>
|
||||
<H2><a name="Perl5_nn47"></a>31.10 Adding additional Perl code</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Php"></a>30 SWIG and PHP</H1>
|
||||
<H1><a name="Php"></a>32 SWIG and PHP</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -49,19 +49,23 @@
|
|||
|
||||
|
||||
<p>
|
||||
SWIG supports generating wrappers for PHP5. Support for PHP4 has been removed
|
||||
as of SWIG 1.3.37. The PHP developers are no longer making new PHP4 releases,
|
||||
SWIG supports generating wrappers for PHP5. Support for PHP4 was removed
|
||||
in SWIG 1.3.37. The PHP developers are no longer making new PHP4 releases,
|
||||
and won't even be patching critical security issues after 2008-08-08, so it
|
||||
doesn't make much sense for SWIG to continue to support PHP4 at this point.
|
||||
If you need to continue to use PHP4, stick with SWIG 1.3.36.
|
||||
doesn't make much sense for SWIG to continue to support PHP4 now. If you
|
||||
really need to continue to use PHP4, just stick with SWIG 1.3.36.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Currently any PHP5 release should work, but we don't regularly test with
|
||||
PHP < 5.3.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this chapter, we discuss SWIG's support of PHP. The PHP module
|
||||
was extensively rewritten in release 1.3.26, and support for generating
|
||||
OO wrappers for PHP5 was added in 1.3.30. The PHP module works fairly
|
||||
well, but currently does not implement all the
|
||||
features available in some of the other languages.
|
||||
OO wrappers for PHP5 was added in 1.3.30. The PHP module now supports most
|
||||
of the features available in some of the other languages.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -75,7 +79,7 @@ your extension into php directly, you will need the complete PHP source tree
|
|||
available.
|
||||
</p>
|
||||
|
||||
<H2><a name="Php_nn1"></a>30.1 Generating PHP Extensions</H2>
|
||||
<H2><a name="Php_nn1"></a>32.1 Generating PHP Extensions</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,7 +126,7 @@ and it doesn't play nicely with package system. We don't recommend
|
|||
this approach, or provide explicit support for it.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn1_1"></a>30.1.1 Building a loadable extension</H3>
|
||||
<H3><a name="Php_nn1_1"></a>32.1.1 Building a loadable extension</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -137,12 +141,12 @@ least work for Linux though):
|
|||
gcc -shared example_wrap.o -o example.so
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Php_nn1_3"></a>30.1.2 Using PHP Extensions</H3>
|
||||
<H3><a name="Php_nn1_3"></a>32.1.2 Using PHP Extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
To test the extension from a PHP script, you need to load it first. You
|
||||
can load it for every script by adding this line the <tt>[PHP]</tt> section of
|
||||
can load it for every script by adding this line to the <tt>[PHP]</tt> section of
|
||||
<tt>php.ini</tt>:
|
||||
</p>
|
||||
|
||||
|
|
@ -152,7 +156,7 @@ can load it for every script by adding this line the <tt>[PHP]</tt> section of
|
|||
|
||||
<p>
|
||||
Alternatively, you can load it explicitly only for scripts which need it
|
||||
by adding this line:
|
||||
by adding this line to the start of each such PHP script::
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -160,7 +164,7 @@ by adding this line:
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
to the start of each PHP file. SWIG also generates a php module, which
|
||||
SWIG also generates a php module, which
|
||||
attempts to do the <tt>dl()</tt> call for you:
|
||||
</p>
|
||||
|
||||
|
|
@ -168,21 +172,22 @@ attempts to do the <tt>dl()</tt> call for you:
|
|||
include("example.php");
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Php_nn2"></a>30.2 Basic PHP interface</H2>
|
||||
<H2><a name="Php_nn2"></a>32.2 Basic PHP interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
It is important to understand that PHP uses a single global namespace
|
||||
into which all symbols from extension modules are loaded. It is quite
|
||||
possible for names of symbols in one extension module to clash with
|
||||
other symbols unless care is taken to <tt>%rename</tt> them.
|
||||
other symbols unless care is taken to <tt>%rename</tt> them. At present
|
||||
SWIG doesn't have support for the namespace feature added in PHP 5.3.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_1"></a>30.2.1 Constants</H3>
|
||||
<H3><a name="Php_nn2_1"></a>32.2.1 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
These work in much the same way as in C/C++, constants can be defined
|
||||
These work in much the same way as in C/C++. Constants can be defined
|
||||
by using either the normal C pre-processor declarations, or the
|
||||
<tt>%constant</tt> SWIG directive. These will then be available from
|
||||
your PHP script as a PHP constant, (i.e. no dollar sign is needed to
|
||||
|
|
@ -199,7 +204,7 @@ access them.) For example, with a swig interface file like this,
|
|||
</div>
|
||||
|
||||
<p>
|
||||
you can access the constants in your php script like this,
|
||||
you can access the constants in your PHP script like this,
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -213,9 +218,16 @@ echo "E = " . E . "\n";
|
|||
</div>
|
||||
|
||||
<p>
|
||||
There are two peculiarities with using constants in PHP. The first is that
|
||||
if you try to use an undeclared constant, it will evaluate to a string
|
||||
set to the constant's name. For example,
|
||||
There's one peculiarity of how constants work in PHP which it is useful
|
||||
to note (this is not specific to SWIG though) - if you try to use an undeclared
|
||||
constant, PHP will issue a warning and then expand the constant to a string
|
||||
version of the constant's name. The warning will often be missed though as
|
||||
if you're using PHP in a webserver, it will probably end up in error.log or
|
||||
similar.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example,
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -243,67 +255,12 @@ if(EASY_TO_MISPEL) {
|
|||
</div>
|
||||
|
||||
<p>
|
||||
will issue a warning about the undeclared constant, but will then
|
||||
evaluate it and turn it into a string ('EASY_TO_MISPEL'), which
|
||||
evaluates to true, rather than the value of the constant which would
|
||||
be false. This is a feature!
|
||||
The mis-spelled constant will become the string 'EASY_TO_MISPEL', which
|
||||
is treated as true by the if test, when the value of the intended constant
|
||||
would be treated as false!
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The second 'feature' is that although constants are case sensitive (by
|
||||
default), you cannot declare a constant twice with alternative
|
||||
cases. E.g.,
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%module example
|
||||
|
||||
#define TEST Hello
|
||||
#define Test World
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
accessed from PHP,
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
include("example.php");
|
||||
|
||||
echo TEST, Test;
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
will output "Hello Test" rather than "Hello World". This is because
|
||||
internally, all constants are stored in a hash table by their lower
|
||||
case name, so 'TEST' and 'Test' will map to the same hash element
|
||||
('Test'). But, because we declared them case sensitive, the Zend
|
||||
engine will test if the case matches with the case the constant was
|
||||
declared with first.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
So, in the example above, the TEST constant was declared first, and
|
||||
will be stored under the hash element 'test'. The 'Test' constant will
|
||||
also map to the same hash element 'test', but will not overwrite
|
||||
it. When called from the script, the TEST constant will again be
|
||||
mapped to the hash element 'test' so the constant will be
|
||||
retrieved. The case will then be checked, and will match up, so the
|
||||
value ('Hello') will be returned. When 'Test' is evaluated, it will
|
||||
also map to the same hash element 'test'. The same constant will be
|
||||
retrieved, this time though the case check will fail as 'Test' !=
|
||||
'TEST'. So PHP will assume that Test is a undeclared constant, and as
|
||||
explained above, will return it as a string set to the constant name
|
||||
('Test'). Hence the script above will print 'Hello Test'. If they were
|
||||
declared non-case sensitive, the output would be 'Hello Hello', as
|
||||
both point to the same value, without the case test taking place. (
|
||||
Apologies, this paragraph needs rewriting to make some sense. )
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_2"></a>30.2.2 Global Variables</H3>
|
||||
<H3><a name="Php_nn2_2"></a>32.2.2 Global Variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -352,7 +309,7 @@ undefined.
|
|||
At this time SWIG does not support custom accessor methods.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_3"></a>30.2.3 Functions</H3>
|
||||
<H3><a name="Php_nn2_3"></a>32.2.3 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -405,7 +362,7 @@ print $s; # The value of $s was not changed.
|
|||
-->
|
||||
|
||||
|
||||
<H3><a name="Php_nn2_4"></a>30.2.4 Overloading</H3>
|
||||
<H3><a name="Php_nn2_4"></a>32.2.4 Overloading</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -461,7 +418,7 @@ taking the integer argument.
|
|||
</p>
|
||||
-->
|
||||
|
||||
<H3><a name="Php_nn2_5"></a>30.2.5 Pointers and References</H3>
|
||||
<H3><a name="Php_nn2_5"></a>32.2.5 Pointers and References</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -549,6 +506,12 @@ this, one needs to include <b>phppointers.i</b> which defines the
|
|||
named typemap REFERENCE.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
However, this relies on call-time pass-by-reference, which has been
|
||||
deprecated in PHP for some time, and was finally <b>removed in PHP 5.4</b>.
|
||||
So you should avoid creating new wrappers which rely on this approach.
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%module example
|
||||
%include "phppointers.i"
|
||||
|
|
@ -593,13 +556,15 @@ PHP in a number of ways: by using <tt>unset</tt> on an existing
|
|||
variable, or assigning <tt>NULL</tt> to a variable.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_6"></a>30.2.6 Structures and C++ classes</H3>
|
||||
<H3><a name="Php_nn2_6"></a>32.2.6 Structures and C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG defaults to wrapping C++ structs and classes with PHP classes
|
||||
unless "-noproxy" is specified. For PHP5, a PHP wrapper
|
||||
class is generated which calls a set of flat functions wrapping the C++ class.
|
||||
SWIG defaults to wrapping C++ structs and classes with PHP classes - this
|
||||
is done by generating a PHP wrapper script which defines proxy classes
|
||||
which calls a set of flat functions which actually wrap the C++ class.
|
||||
You can disable this wrapper layer by passing the command-line option
|
||||
"-noproxy" in which case you'll just get the flat functions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -652,7 +617,7 @@ Would be used in the following way from PHP5:
|
|||
Member variables and methods are accessed using the <tt>-></tt> operator.
|
||||
</p>
|
||||
|
||||
<H4><a name="Php_nn2_6_1"></a>30.2.6.1 Using <tt>-noproxy</tt></H4>
|
||||
<H4><a name="Php_nn2_6_1"></a>32.2.6.1 Using <tt>-noproxy</tt></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -678,7 +643,7 @@ Complex_im_set($obj,$d);
|
|||
Complex_im_get($obj);
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Php_nn2_6_2"></a>30.2.6.2 Constructors and Destructors</H4>
|
||||
<H4><a name="Php_nn2_6_2"></a>32.2.6.2 Constructors and Destructors</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -719,7 +684,7 @@ the programmer can either reassign the variable or call
|
|||
<tt>unset($v)</tt>
|
||||
</p>
|
||||
|
||||
<H4><a name="Php_nn2_6_3"></a>30.2.6.3 Static Member Variables</H4>
|
||||
<H4><a name="Php_nn2_6_3"></a>32.2.6.3 Static Member Variables</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -746,7 +711,7 @@ would be accessed in PHP as,
|
|||
<div class="code"><pre>
|
||||
include("example.php");
|
||||
|
||||
echo "There has now been " . Ko::threats() . " threats\n";
|
||||
echo "There have now been " . Ko::threats() . " threats\n";
|
||||
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -759,10 +724,10 @@ function, e.g.
|
|||
|
||||
Ko::threats(10);
|
||||
|
||||
echo "There has now been " . Ko::threats() . " threats\n";
|
||||
echo "There have now been " . Ko::threats() . " threats\n";
|
||||
|
||||
</pre></div>
|
||||
<H4><a name="Php_nn2_6_4"></a>30.2.6.4 Static Member Functions</H4>
|
||||
<H4><a name="Php_nn2_6_4"></a>32.2.6.4 Static Member Functions</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -784,7 +749,7 @@ Ko::threats();
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Php_nn2_7"></a>30.2.7 PHP Pragmas, Startup and Shutdown code</H3>
|
||||
<H3><a name="Php_nn2_7"></a>32.2.7 PHP Pragmas, Startup and Shutdown code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -872,7 +837,7 @@ The <tt>%rinit</tt> and <tt>%rshutdown</tt> statements are very similar but inse
|
|||
into the request init (PHP_RINIT_FUNCTION) and request shutdown (PHP_RSHUTDOWN_FUNCTION) code respectively.
|
||||
</p>
|
||||
|
||||
<H2><a name="Php_nn3"></a>30.3 Cross language polymorphism</H2>
|
||||
<H2><a name="Php_nn3"></a>32.3 Cross language polymorphism</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -907,7 +872,7 @@ wrapper functions takes care of all the cross-language method routing
|
|||
transparently.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_1"></a>30.3.1 Enabling directors</H3>
|
||||
<H3><a name="Php_nn3_1"></a>32.3.1 Enabling directors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -936,9 +901,6 @@ globally, to specific classes, and to specific methods, like this:
|
|||
|
||||
// generate directors for all virtual methods in class Foo
|
||||
%feature("director") Foo;
|
||||
|
||||
// generate a director for just Foo::bar()
|
||||
%feature("director") Foo::bar;
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -999,7 +961,7 @@ class MyFoo extends Foo {
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Php_nn3_2"></a>30.3.2 Director classes</H3>
|
||||
<H3><a name="Php_nn3_2"></a>32.3.2 Director classes</H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -1079,7 +1041,7 @@ so there is no need for the extra overhead involved with routing the
|
|||
calls through PHP.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_3"></a>30.3.3 Ownership and object destruction</H3>
|
||||
<H3><a name="Php_nn3_3"></a>32.3.3 Ownership and object destruction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1135,7 +1097,7 @@ In this example, we are assuming that FooContainer will take care of
|
|||
deleting all the Foo pointers it contains at some point.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_4"></a>30.3.4 Exception unrolling</H3>
|
||||
<H3><a name="Php_nn3_4"></a>32.3.4 Exception unrolling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1194,7 +1156,7 @@ Swig::DirectorMethodException is thrown, PHP will register the exception
|
|||
as soon as the C wrapper function returns.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_5"></a>30.3.5 Overhead and code bloat</H3>
|
||||
<H3><a name="Php_nn3_5"></a>32.3.5 Overhead and code bloat</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1227,7 +1189,7 @@ optimized by selectively enabling director methods (using the %feature
|
|||
directive) for only those methods that are likely to be extended in PHP.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_6"></a>30.3.6 Typemaps</H3>
|
||||
<H3><a name="Php_nn3_6"></a>32.3.6 Typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1241,7 +1203,7 @@ need to be supported.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Php_nn3_7"></a>30.3.7 Miscellaneous</H3>
|
||||
<H3><a name="Php_nn3_7"></a>32.3.7 Miscellaneous</H3>
|
||||
|
||||
|
||||
<p> Director typemaps for STL classes are mostly in place, and hence you
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Pike"></a>31 SWIG and Pike</H1>
|
||||
<H1><a name="Pike"></a>33 SWIG and Pike</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -46,10 +46,10 @@ least, make sure you read the "<a href="SWIG.html#SWIG">SWIG Basics</a>"
|
|||
chapter.<br>
|
||||
</p>
|
||||
|
||||
<H2><a name="Pike_nn2"></a>31.1 Preliminaries</H2>
|
||||
<H2><a name="Pike_nn2"></a>33.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<H3><a name="Pike_nn3"></a>31.1.1 Running SWIG</H3>
|
||||
<H3><a name="Pike_nn3"></a>33.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -94,7 +94,7 @@ can use the <tt>-o</tt> option:
|
|||
<div class="code">
|
||||
<pre>$ <b>swig -pike -o pseudonym.c example.i</b><br></pre>
|
||||
</div>
|
||||
<H3><a name="Pike_nn4"></a>31.1.2 Getting the right header files</H3>
|
||||
<H3><a name="Pike_nn4"></a>33.1.2 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -114,7 +114,7 @@ You're looking for files with the names <tt>global.h</tt>, <tt>program.h</tt>
|
|||
and so on.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn5"></a>31.1.3 Using your module</H3>
|
||||
<H3><a name="Pike_nn5"></a>33.1.3 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -129,10 +129,10 @@ Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
|
|||
(1) Result: 24
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Pike_nn6"></a>31.2 Basic C/C++ Mapping</H2>
|
||||
<H2><a name="Pike_nn6"></a>33.2 Basic C/C++ Mapping</H2>
|
||||
|
||||
|
||||
<H3><a name="Pike_nn7"></a>31.2.1 Modules</H3>
|
||||
<H3><a name="Pike_nn7"></a>33.2.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -143,7 +143,7 @@ concerned), SWIG's <tt>%module</tt> directive doesn't really have any
|
|||
significance.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn8"></a>31.2.2 Functions</H3>
|
||||
<H3><a name="Pike_nn8"></a>33.2.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -168,7 +168,7 @@ exactly as you'd expect it to:
|
|||
(1) Result: 24
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Pike_nn9"></a>31.2.3 Global variables</H3>
|
||||
<H3><a name="Pike_nn9"></a>33.2.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -197,7 +197,7 @@ will result in two functions, <tt>Foo_get()</tt> and <tt>Foo_set()</tt>:
|
|||
(3) Result: 3.141590
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Pike_nn10"></a>31.2.4 Constants and enumerated types</H3>
|
||||
<H3><a name="Pike_nn10"></a>33.2.4 Constants and enumerated types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -205,7 +205,7 @@ Enumerated types in C/C++ declarations are wrapped as Pike constants,
|
|||
not as Pike enums.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn11"></a>31.2.5 Constructors and Destructors</H3>
|
||||
<H3><a name="Pike_nn11"></a>33.2.5 Constructors and Destructors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -213,7 +213,7 @@ Constructors are wrapped as <tt>create()</tt> methods, and destructors are
|
|||
wrapped as <tt>destroy()</tt> methods, for Pike classes.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn12"></a>31.2.6 Static Members</H3>
|
||||
<H3><a name="Pike_nn12"></a>33.2.6 Static Members</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -93,12 +93,12 @@ SWIG along with information about beta releases and future work.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
Subversion access to the latest version of SWIG is also available. More information
|
||||
Git and Subversion access to the latest version of SWIG is also available. More information
|
||||
about this can be obtained at:
|
||||
</p>
|
||||
|
||||
<div class="shell"><pre>
|
||||
<a href="http://www.swig.org/svn.html">http://www.swig.org/svn.html</a>
|
||||
<a href="http://www.swig.org/svn.html">SWIG Bleeding Edge</a>
|
||||
</pre></div>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -16,8 +16,11 @@
|
|||
<li><a href="#Preprocessor_nn5">Macro Expansion</a>
|
||||
<li><a href="#Preprocessor_nn6">SWIG Macros</a>
|
||||
<li><a href="#Preprocessor_nn7">C99 and GNU Extensions</a>
|
||||
<li><a href="#Preprocessor_delimiters">Preprocessing and delimiters</a>
|
||||
<ul>
|
||||
<li><a href="#Preprocessor_nn8">Preprocessing and %{ ... %} & " ... " delimiters</a>
|
||||
<li><a href="#Preprocessor_nn9">Preprocessing and { ... } delimiters</a>
|
||||
</ul>
|
||||
<li><a href="#Preprocessor_typemap_delimiters">Preprocessor and Typemaps</a>
|
||||
<li><a href="#Preprocessor_nn10">Viewing preprocessor output</a>
|
||||
<li><a href="#Preprocessor_warning_error">The #error and #warning directives</a>
|
||||
|
|
@ -306,7 +309,14 @@ interface building. However, they are used internally to implement a number of
|
|||
SWIG directives and are provided to make SWIG more compatible with C99 code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_nn8"></a>7.7 Preprocessing and %{ ... %} & " ... " delimiters</H2>
|
||||
<H2><a name="Preprocessor_delimiters"></a>7.7 Preprocessing and delimiters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
The preprocessor handles { }, " " and %{ %} delimiters differently.
|
||||
</p>
|
||||
|
||||
<H3><a name="Preprocessor_nn8"></a>7.7.1 Preprocessing and %{ ... %} & " ... " delimiters</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -331,7 +341,7 @@ the contents of the <tt>%{ ... %}</tt> block are copied without
|
|||
modification to the output (including all preprocessor directives).
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_nn9"></a>7.8 Preprocessing and { ... } delimiters</H2>
|
||||
<H3><a name="Preprocessor_nn9"></a>7.7.2 Preprocessing and { ... } delimiters</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -373,7 +383,7 @@ to actually go into the wrapper file, prefix the preprocessor directives with <t
|
|||
SWIG will strip the extra <tt>%</tt> and leave the preprocessor directive in the code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_typemap_delimiters"></a>7.9 Preprocessor and Typemaps</H2>
|
||||
<H2><a name="Preprocessor_typemap_delimiters"></a>7.8 Preprocessor and Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -444,7 +454,7 @@ would generate
|
|||
</div>
|
||||
|
||||
|
||||
<H2><a name="Preprocessor_nn10"></a>7.10 Viewing preprocessor output</H2>
|
||||
<H2><a name="Preprocessor_nn10"></a>7.9 Viewing preprocessor output</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -454,7 +464,7 @@ Instead the results after the preprocessor has run are displayed.
|
|||
This might be useful as an aid to debugging and viewing the results of macro expansions.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_warning_error"></a>7.11 The #error and #warning directives</H2>
|
||||
<H2><a name="Preprocessor_warning_error"></a>7.10 The #error and #warning directives</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -44,6 +44,12 @@
|
|||
<li><a href="#SWIG_nn26">Arrays</a>
|
||||
<li><a href="#SWIG_readonly_variables">Creating read-only variables</a>
|
||||
<li><a href="#SWIG_rename_ignore">Renaming and ignoring declarations</a>
|
||||
<ul>
|
||||
<li><a href="#SWIG_nn29">Simple renaming of specific identifiers</a>
|
||||
<li><a href="#SWIG_advanced_renaming">Advanced renaming support</a>
|
||||
<li><a href="#SWIG_limiting_renaming">Limiting global renaming rules</a>
|
||||
<li><a href="#SWIG_chosen_unignore">Ignoring everything then wrapping a few selected symbols</a>
|
||||
</ul>
|
||||
<li><a href="#SWIG_default_args">Default/optional arguments</a>
|
||||
<li><a href="#SWIG_nn30">Pointers to functions and callbacks</a>
|
||||
</ul>
|
||||
|
|
@ -142,6 +148,7 @@ can be obtained by typing <tt>swig -help</tt> or <tt>swig
|
|||
-o <em>outfile</em> Name of output file
|
||||
-outcurrentdir Set default output dir to current dir instead of input file's path
|
||||
-outdir <em>dir</em> Set language specific files output directory
|
||||
-pcreversion Display PCRE version information
|
||||
-swiglib Show location of SWIG library
|
||||
-version Show SWIG version number
|
||||
|
||||
|
|
@ -1662,6 +1669,9 @@ generate a warning message. Simply change the directives to <tt>%immutable;</t
|
|||
<H3><a name="SWIG_rename_ignore"></a>5.4.7 Renaming and ignoring declarations</H3>
|
||||
|
||||
|
||||
<H4><a name="SWIG_nn29"></a>5.4.7.1 Simple renaming of specific identifiers</H4>
|
||||
|
||||
|
||||
<p>
|
||||
Normally, the name of a C declaration is used when that declaration is
|
||||
wrapped into the target language. However, this may generate a
|
||||
|
|
@ -1741,12 +1751,6 @@ to add conditional compilation to the header. However, it should be stressed t
|
|||
declarations. If you need to remove a whole section of problematic code, the SWIG preprocessor should be used instead.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
More powerful variants of <tt>%rename</tt> and <tt>%ignore</tt> directives can be used to help
|
||||
wrap C++ overloaded functions and methods or C++ methods which use default arguments. This is described in the
|
||||
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a> section in the C++ chapter.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Compatibility note: </b> Older versions of SWIG provided a special <tt>%name</tt> directive for renaming declarations.
|
||||
For example:
|
||||
|
|
@ -1763,6 +1767,337 @@ This directive is still supported, but it is deprecated and should probably be a
|
|||
directive is more powerful and better supports wrapping of raw header file information.
|
||||
</p>
|
||||
|
||||
<H4><a name="SWIG_advanced_renaming"></a>5.4.7.2 Advanced renaming support</H4>
|
||||
|
||||
|
||||
<p>
|
||||
While writing <tt>%rename</tt> for specific declarations is simple enough,
|
||||
sometimes the same renaming rule needs to be applied to many, maybe all,
|
||||
identifiers in the SWIG input. For example, it may be necessary to apply some
|
||||
transformation to all the names in the target language to better follow its
|
||||
naming conventions, like adding a specific prefix to all wrapped functions. Doing it individually
|
||||
for each function is impractical so SWIG supports applying a renaming rule to
|
||||
all declarations if the name of the identifier to be renamed is not specified:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("myprefix_%s") ""; // print -> myprefix_print
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
This also shows that the argument of <tt>%rename</tt> doesn't have to be a
|
||||
literal string but can be a <tt>printf()</tt>-like format string. In the
|
||||
simplest form, <tt>"%s"</tt> is replaced with the name of the original
|
||||
declaration, as shown above. However this is not always enough and SWIG
|
||||
provides extensions to the usual format string syntax to allow applying a
|
||||
(SWIG-defined) function to the argument. For example, to wrap all C functions
|
||||
<tt>do_something_long()</tt> as more Java-like <tt>doSomethingLong()</tt> you
|
||||
can use the <tt>"lowercamelcase"</tt> extended format specifier like this:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("%(lowercamelcase)s") ""; // foo_bar -> fooBar; FooBar -> fooBar
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Some functions can be parametrized, for example the <tt>"strip"</tt> one
|
||||
strips the provided prefix from its argument. The prefix is specified as part
|
||||
of the format string, following a colon after the function name:
|
||||
</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("%(strip:[wx])s") ""; // wxHello -> Hello; FooBar -> FooBar
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Below is the table summarizing all currently defined functions with an example
|
||||
of applying each one. Note that some of them have two names, a shorter one
|
||||
and a more descriptive one, but the two functions are otherwise equivalent:
|
||||
</p>
|
||||
<table summary="Format string functions" border="1" cellpadding="5">
|
||||
<tr>
|
||||
<th>Function</th><th>Returns</th><th colspan=2>Example (in/out)</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>uppercase</tt> or <tt>upper</tt></td>
|
||||
<td>Upper case version of the string.</td>
|
||||
<td><tt>Print</tt></td><td><tt>PRINT</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>lowercase</tt> or <tt>lower</tt></td>
|
||||
<td>Lower case version of the string.</td>
|
||||
<td><tt>Print</tt></td><td><tt>print</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>title</tt></td>
|
||||
<td>String with first letter capitalized and the rest in lower case.</td>
|
||||
<td><tt>print</tt></td><td><tt>Print</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>firstuppercase</tt></td>
|
||||
<td>String with the first letter capitalized and the rest unchanged.</td>
|
||||
<td><tt>printIt</tt></td><td><tt>PrintIt</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>firstlowercase</tt></td>
|
||||
<td>String with the first letter in lower case and the rest unchanged.</td>
|
||||
<td><tt>PrintIt</tt></td><td><tt>printIt</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>camelcase</tt> or <tt>ctitle</tt></td>
|
||||
<td>String with capitalized first letter and any letter following an
|
||||
underscore (which are removed in the process) and rest in lower case.</td>
|
||||
<td><tt>print_it</tt></td><td><tt>PrintIt</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>lowercamelcase</tt> or <tt>lctitle</tt></td>
|
||||
<td>String with every letter following an underscore (which is removed in
|
||||
the process) capitalized and rest, including the first letter, in lower
|
||||
case.</td>
|
||||
<td><tt>print_it</tt></td><td><tt>printIt</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>undercase</tt> or <tt>utitle</tt></td>
|
||||
<td>Lower case string with underscores inserted before every upper case
|
||||
letter in the original string and any number not at the end of string.
|
||||
Logically, this is the reverse of <tt>camelcase</tt>.</td>
|
||||
<td><tt>PrintIt</tt></td><td><tt>print_it</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>schemify</tt></td>
|
||||
<td>String with all underscores replaced with dashes, resulting in more
|
||||
Lispers/Schemers-pleasing name.</td>
|
||||
<td><tt>print_it</tt></td><td><tt>print-it</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>strip:[prefix]</tt></td>
|
||||
<td>String without the given prefix or the original string if it doesn't
|
||||
start with this prefix. Note that square brackets should be used
|
||||
literally, e.g. <tt>%rename("strip:[wx]")</tt></td>
|
||||
<td><tt>wxPrint</tt></td><td><tt>Print</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><span style="white-space: nowrap;"><tt>regex:/pattern/subst/</tt></span></td>
|
||||
<td>String after (Perl-like) regex substitution operation. This function
|
||||
allows to apply arbitrary regular expressions to the identifier names. The
|
||||
<i>pattern</i> part is a regular expression in Perl syntax (as supported
|
||||
by the <a href="http://www.pcre.org/">Perl Compatible Regular Expressions (PCRE)</a>)
|
||||
library and the <i>subst</i> string
|
||||
can contain back-references introduced by <tt>'\'</tt> or, as backslashes need
|
||||
to be escaped in C strings, rather by <tt>"\\"</tt>. For example, to remove
|
||||
any alphabetic prefix before an underscore you could use the following directive:
|
||||
<tt>%rename("regex:/(\\w+)_(.*)/\\2/")</tt></td>
|
||||
<td><tt>Prefix_Print</tt></td><td><tt>Print</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tt>command:cmd</tt></td>
|
||||
<td>Output of an external command <tt>cmd</tt> with the string passed to
|
||||
it as input. Notice that this function is extremely slow compared to all
|
||||
the other ones as it involves spawning a separate process and using it for
|
||||
many declarations is not recommended. The <i>cmd</i> is not enclosed in
|
||||
square brackets but must be terminated with a triple <tt>'<'</tt> sign,
|
||||
e.g. <tt>%rename("command:tr -d aeiou <<<")</tt>
|
||||
(nonsensical example removing all vowels)</td>
|
||||
<td><tt>Print</tt></td><td><tt>Prnt</tt></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<p>
|
||||
The most general function of all of the above ones (not counting
|
||||
<tt>command</tt> which is even more powerful in principle but which should
|
||||
generally be avoided because of performance considerations) is the
|
||||
<tt>regex</tt> one. Here are some more examples of its use:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
// Strip the wx prefix from all identifiers except those starting with wxEVT
|
||||
%rename("%(regex:/wx(?!EVT)(.*)/\\1/)s") ""; // wxSomeWidget -> SomeWidget
|
||||
// wxEVT_PAINT -> wxEVT_PAINT
|
||||
|
||||
// Apply a rule for renaming the enum elements to avoid the common prefixes
|
||||
// which are redundant in C#/Java
|
||||
%rename("%(regex:/^([A-Z][a-z]+)+_(.*)/\\2/)s", %$isenumitem) ""; // Colour_Red -> Red
|
||||
|
||||
// Remove all "Set/Get" prefixes.
|
||||
%rename("%(regex:/^(Set|Get)(.*)/\\2/)s") ""; // SetValue -> Value
|
||||
// GetValue -> Value
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
As before, everything that was said above about <tt>%rename</tt> also applies to
|
||||
<tt>%ignore</tt>. In fact, the latter is just a special case of the former and
|
||||
ignoring an identifier is the same as renaming it to the special
|
||||
<tt>"$ignore"</tt> value. So the following snippets
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%ignore print;
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
and
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("$ignore") print;
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
are exactly equivalent and <tt>%rename</tt> can be used to selectively ignore
|
||||
multiple declarations using the previously described matching possibilities.
|
||||
</p>
|
||||
|
||||
<H4><a name="SWIG_limiting_renaming"></a>5.4.7.3 Limiting global renaming rules</H4>
|
||||
|
||||
|
||||
<p>
|
||||
As explained in the previous sections, it is possible to either rename
|
||||
individual declarations or apply a rename rule to all of them at once. In
|
||||
practice, the latter is however rarely appropriate as there are always some
|
||||
exceptions to the general rules. To deal with them, the scope of an unnamed
|
||||
<tt>%rename</tt> can be limited using subsequent <tt>match</tt> parameters.
|
||||
They can be applied to any of the attributes associated by SWIG with the
|
||||
declarations appearing in its input. For example:
|
||||
</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("foo", match$name="bar") "";
|
||||
</pre>
|
||||
</div>
|
||||
<p>
|
||||
can be used to achieve the same effect as the simpler
|
||||
</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("foo") bar;
|
||||
</pre>
|
||||
</div>
|
||||
<p>
|
||||
and so is not very interesting on its own. However <tt>match</tt> can also be
|
||||
applied to the declaration type, for example <tt>match="class"</tt> restricts
|
||||
the match to class declarations only (in C++) and <tt>match="enumitem"</tt>
|
||||
restricts it to the enum elements. SWIG also provides convenience macros for
|
||||
such match expressions, for example
|
||||
</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("%(title)s", %$isenumitem) "";
|
||||
</pre>
|
||||
</div>
|
||||
<p>
|
||||
will capitalize the names of all the enum elements but not change the case of
|
||||
the other declarations. Similarly, <tt>%$isclass</tt>, <tt>%$isfunction</tt>,
|
||||
<tt>%$isconstructor</tt>, <tt>%$isunion</tt>, <tt>%$istemplate</tt>,
|
||||
and <tt>%$isvariable</tt> can be used. Many other checks are possible and this
|
||||
documentation is not exhaustive, see the "%rename predicates" section in
|
||||
<tt>swig.swg</tt> for the full list of supported match expressions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In addition to literally matching some string with <tt>match</tt> you can
|
||||
also use <tt>regexmatch</tt> or <tt>notregexmatch</tt> to match a string
|
||||
against a regular expression. For example, to ignore all functions having
|
||||
"Old" as a suffix you could use
|
||||
</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("$ignore", regexmatch$name="Old$") "";
|
||||
</pre>
|
||||
</div>
|
||||
<p>
|
||||
For simple cases like this, specifying the regular expression for the
|
||||
declaration name directly can be preferable and can also be done using
|
||||
<tt>regextarget</tt>:
|
||||
</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("$ignore", regextarget=1) "Old$";
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Notice that the check is done only against the name of the declaration
|
||||
itself, if you need to match the full name of a C++ declaration you
|
||||
must use <tt>fullname</tt> attribute:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("$ignore", regextarget=1, fullname=1) "NameSpace::ClassName::.*Old$";
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
As for <tt>notregexmatch</tt>, it restricts the match only to the strings not
|
||||
matching the specified regular expression. So to rename all declarations to lower case
|
||||
except those consisting of capital letters only:
|
||||
</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("$(lower)s", notregexmatch$name="^[A-Z]+$") "";
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Finally, variants of <tt>%rename</tt> and <tt>%ignore</tt> directives can be used to help
|
||||
wrap C++ overloaded functions and methods or C++ methods which use default arguments. This is described in the
|
||||
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a> section in the C++ chapter.
|
||||
</p>
|
||||
|
||||
|
||||
<H4><a name="SWIG_chosen_unignore"></a>5.4.7.4 Ignoring everything then wrapping a few selected symbols</H4>
|
||||
|
||||
|
||||
<p>
|
||||
Using the techniques described above it is possible to ignore everything in a header and then
|
||||
selectively wrap a few chosen methods or classes. For example, consider a header, <tt>myheader.h</tt>
|
||||
which has many classes in it and just the one class called <tt>Star</tt> is wanted within this header,
|
||||
the following approach could be taken:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%ignore ""; // Ignore everything
|
||||
|
||||
// Unignore chosen class 'Star'
|
||||
%rename("%s") Star;
|
||||
|
||||
// As the ignore everything will include the constructor, destructor, methods etc
|
||||
// in the class, these have to be explicitly unignored too:
|
||||
%rename("%s") Star::Star;
|
||||
%rename("%s") Star::~Star;
|
||||
%rename("%s") Star::shine; // named method
|
||||
|
||||
%include "myheader.h"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Another approach which might be more suitable as it does not require naming all the methods in the
|
||||
chosen class is to begin by ignoring just the classes. This does not add an explicit ignore to any
|
||||
members of the class, so when the chosen class is unignored, all of its methods will be wrapped.
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename($ignore, %$isclass) ""; // Only ignore all classes
|
||||
%rename("%s") Star; // Unignore 'Star'
|
||||
%include "myheader.h"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<H3><a name="SWIG_default_args"></a>5.4.8 Default/optional arguments</H3>
|
||||
|
||||
|
||||
|
|
@ -1926,13 +2261,13 @@ normally, just use the original function name such as <tt>add()</tt>.
|
|||
<p>
|
||||
SWIG provides a number of extensions to standard C printf formatting
|
||||
that may be useful in this context. For instance, the following
|
||||
variation installs the callbacks as all upper-case constants such as
|
||||
variation installs the callbacks as all upper case constants such as
|
||||
<tt>ADD</tt>, <tt>SUB</tt>, and <tt>MUL</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
/* Some callback functions */
|
||||
%callback("%(upper)s");
|
||||
%callback("%(uppercase)s");
|
||||
int add(int,int);
|
||||
int sub(int,int);
|
||||
int mul(int,int);
|
||||
|
|
@ -1940,7 +2275,7 @@ int mul(int,int);
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
A format string of <tt>"%(lower)s"</tt> converts all characters to lower-case.
|
||||
A format string of <tt>"%(lowercase)s"</tt> converts all characters to lower case.
|
||||
A string of <tt>"%(title)s"</tt> capitalizes the first character and converts the
|
||||
rest to lower case.
|
||||
</p>
|
||||
|
|
@ -1949,7 +2284,8 @@ rest to lower case.
|
|||
And now, a final note about function pointer support. Although SWIG
|
||||
does not normally allow callback functions to be written in the target language, this
|
||||
can be accomplished with the use of typemaps and other advanced SWIG features.
|
||||
This is described in a later chapter.
|
||||
See the <a href="Typemaps.html#Typemaps">Typemaps chapter</a> for more about typemaps
|
||||
and individual target language chapters for more on callbacks and the 'director' feature.
|
||||
</p>
|
||||
|
||||
<H2><a name="SWIG_nn31"></a>5.5 Structures and unions</H2>
|
||||
|
|
@ -2746,14 +3082,15 @@ output of SWIG is structured first.</p>
|
|||
|
||||
|
||||
<p>
|
||||
When SWIG creates its output file, it is broken up into four sections
|
||||
When SWIG creates its output file, it is broken up into five sections
|
||||
corresponding to runtime code, headers, wrapper functions, and module
|
||||
initialization code (in that order).
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><b>Begin section</b>. <br>
|
||||
A placeholder to put code at the beginning of the C/C++ wrapper file.
|
||||
A placeholder for users to put code at the beginning of the C/C++ wrapper file.
|
||||
This is most often used to define preprocessor macros that are used in later sections.
|
||||
</li>
|
||||
|
||||
<li><b>Runtime code</b>. <br>
|
||||
|
|
|
|||
|
|
@ -57,6 +57,7 @@
|
|||
<li><a href="#SWIGPlus_catches">Exception handling with %catches</a>
|
||||
<li><a href="#SWIGPlus_nn33">Pointers to Members</a>
|
||||
<li><a href="#SWIGPlus_smart_pointers">Smart pointers and operator->()</a>
|
||||
<li><a href="#SWIGPlus_ref_unref">C++ reference counted objects - ref/unref feature</a>
|
||||
<li><a href="#SWIGPlus_nn35">Using declarations and inheritance</a>
|
||||
<li><a href="#SWIGPlus_nested_classes">Nested classes</a>
|
||||
<li><a href="#SWIGPlus_const">A brief rant about const-correctness</a>
|
||||
|
|
@ -2837,6 +2838,12 @@ struct Derived : Base {
|
|||
}
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The following special variables are expanded if used within a %extend block:
|
||||
$name, $symname, $overname, $decl, $fulldecl, $parentname and $parentsymname.
|
||||
The <a href="Customization.html#Customization_exception_special_variables">Special variables</a> section provides more information each of these special variables.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The<tt> %extend</tt> directive follows all of the same conventions
|
||||
as its use with C structures. Please refer to the <a href="SWIG.html#SWIG_adding_member_functions">Adding member functions to C structures</a>
|
||||
|
|
@ -3120,8 +3127,8 @@ nothing is known about <tt>List<int></tt>, you will get a warning message
|
|||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
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: Warning 401. Nothing known about class 'List<int >'. Ignored.
|
||||
example.h:42: Warning 401. Maybe you forgot to instantiate 'List<int >' using %template.
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -3162,7 +3169,7 @@ Don't worry--if you get the order wrong, SWIG should generate a warning message.
|
|||
Occasionally, you may need to tell SWIG about base classes that are defined by templates,
|
||||
but which aren't supposed to be wrapped. Since SWIG is not able to automatically
|
||||
instantiate templates for this purpose, you must do it manually. To do this, simply
|
||||
use <tt>%template</tt> with no name. For example:
|
||||
use the empty template instantiation, that is, <tt>%template</tt> with no name. For example:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -3356,7 +3363,7 @@ public:
|
|||
|
||||
<p>
|
||||
In this case, the <tt>%extend</tt> directive is not needed, and
|
||||
<tt>%template</tt> does the exactly same job, i.e., it adds two new
|
||||
<tt>%template</tt> does exactly the same job, i.e., it adds two new
|
||||
methods to the Foo class.
|
||||
</p>
|
||||
|
||||
|
|
@ -4192,8 +4199,9 @@ In the example below, the generic template type is used to rename to <tt>bbb</tt
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename(bbb) Space::ABC::aaa(T t); // will match but with lower precedence than ccc
|
||||
%rename(ccc) Space::ABC<Space::XYZ>::aaa(Space::XYZ t); // will match but with higher precedence than bbb
|
||||
%rename(bbb) Space::ABC::aaa(T t); // will match but with lower precedence than ccc
|
||||
%rename(ccc) Space::ABC<Space::XYZ>::aaa(Space::XYZ t);// will match but with higher precedence
|
||||
// than bbb
|
||||
|
||||
namespace Space {
|
||||
class XYZ {};
|
||||
|
|
@ -4214,9 +4222,9 @@ Below shows how %rename can be placed inside a namespace.
|
|||
<div class="code">
|
||||
<pre>
|
||||
namespace Space {
|
||||
%rename(bbb) ABC::aaa(T t); // will match but with lower precedence than ccc
|
||||
%rename(ccc) ABC<Space::XYZ>::aaa(Space::XYZ t); // will match but with higher precedence than bbb
|
||||
%rename(ddd) ABC<Space::XYZ>::aaa(XYZ t); // will not match
|
||||
%rename(bbb) ABC::aaa(T t); // will match but with lower precedence than ccc
|
||||
%rename(ccc) ABC<Space::XYZ>::aaa(Space::XYZ t);// will match but with higher precedence than bbb
|
||||
%rename(ddd) ABC<Space::XYZ>::aaa(XYZ t); // will not match
|
||||
}
|
||||
|
||||
namespace Space {
|
||||
|
|
@ -4238,11 +4246,11 @@ The following example shows how %rename can be placed within %extend.
|
|||
<pre>
|
||||
namespace Space {
|
||||
%extend ABC {
|
||||
%rename(bbb) aaa(T t); // will match but with lower precedence than ccc
|
||||
%rename(bbb) aaa(T t); // will match but with lower precedence than ccc
|
||||
}
|
||||
%extend ABC<Space::XYZ> {
|
||||
%rename(ccc) aaa(Space::XYZ t); // will match but with higher precedence than bbb
|
||||
%rename(ddd) aaa(XYZ t); // will not match
|
||||
%rename(ccc) aaa(Space::XYZ t);// will match but with higher precedence than bbb
|
||||
%rename(ddd) aaa(XYZ t); // will not match
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -4617,8 +4625,179 @@ p = f.__deref__() # Raw pointer from operator->
|
|||
<b>Note:</b> Smart pointer support was first added in SWIG-1.3.14.
|
||||
</p>
|
||||
|
||||
<H2><a name="SWIGPlus_ref_unref"></a>6.25 C++ reference counted objects - ref/unref feature</H2>
|
||||
|
||||
<H2><a name="SWIGPlus_nn35"></a>6.25 Using declarations and inheritance</H2>
|
||||
|
||||
<p>
|
||||
Another similar idiom in C++ is the use of reference counted objects. Consider for example:
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
class RCObj {
|
||||
// implement the ref counting mechanism
|
||||
int add_ref();
|
||||
int del_ref();
|
||||
int ref_count();
|
||||
|
||||
public:
|
||||
virtual ~RCObj() = 0;
|
||||
|
||||
int ref() const {
|
||||
return add_ref();
|
||||
}
|
||||
|
||||
int unref() const {
|
||||
if (ref_count() == 0 || del_ref() == 0 ) {
|
||||
delete this;
|
||||
return 0;
|
||||
}
|
||||
return ref_count();
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
class A : RCObj {
|
||||
public:
|
||||
A();
|
||||
int foo();
|
||||
};
|
||||
|
||||
|
||||
class B {
|
||||
A *_a;
|
||||
|
||||
public:
|
||||
B(A *a) : _a(a) {
|
||||
a->ref();
|
||||
}
|
||||
|
||||
~B() {
|
||||
a->unref();
|
||||
}
|
||||
};
|
||||
|
||||
int main() {
|
||||
A *a = new A(); // (count: 0)
|
||||
a->ref(); // 'a' ref here (count: 1)
|
||||
|
||||
B *b1 = new B(a); // 'a' ref here (count: 2)
|
||||
if (1 + 1 == 2) {
|
||||
B *b2 = new B(a); // 'a' ref here (count: 3)
|
||||
delete b2; // 'a' unref, but not deleted (count: 2)
|
||||
}
|
||||
|
||||
delete b1; // 'a' unref, but not deleted (count: 1)
|
||||
a->unref(); // 'a' unref and deleted (count: 0)
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In the example above, the 'A' class instance 'a' is a reference counted
|
||||
object, which can't be deleted arbitrarily since it is shared between
|
||||
the objects 'b1' and 'b2'. 'A' is derived from a <i>Reference Counted
|
||||
Object</i> 'RCObj', which implements the ref/unref idiom.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To tell SWIG that 'RCObj' and all its derived classes are reference
|
||||
counted objects, use the "ref" and "unref" <a href="Customization.html#Customization_features">features</a>.
|
||||
These are also available as <tt>%refobject</tt> and <tt>%unrefobject</tt>, respectively.
|
||||
For example:
|
||||
</p>
|
||||
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%module example
|
||||
...
|
||||
|
||||
%feature("ref") RCObj "$this->ref();"
|
||||
%feature("unref") RCObj "$this->unref();"
|
||||
|
||||
%include "rcobj.h"
|
||||
%include "A.h"
|
||||
...
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
where the code passed to the "ref" and "unref" features will be
|
||||
executed as needed whenever a new object is passed to python, or when
|
||||
python tries to release the proxy object instance, respectively.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
On the python side, the use of a reference counted object is no
|
||||
different to any other regular instance:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
def create_A():
|
||||
a = A() # SWIG ref 'a' - new object is passed to python (count: 1)
|
||||
b1 = B(a) # C++ ref 'a (count: 2)
|
||||
if 1 + 1 == 2:
|
||||
b2 = B(a) # C++ ref 'a' (count: 3)
|
||||
return a # 'b1' and 'b2' are released and deleted, C++ unref 'a' twice (count: 1)
|
||||
|
||||
a = create_A() # (count: 1)
|
||||
exit # 'a' is released, SWIG unref 'a' called in the destructor wrapper (count: 0)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Note that the user doesn't explicitly need to call 'a->ref()' nor 'a->unref()'
|
||||
(and neither 'delete a'). Instead, SWIG takes cares of executing the "ref"
|
||||
and "unref" calls as needed. If the user doesn't specify the
|
||||
"ref/unref" feature for a type, SWIG will produce code equivalent to defining these
|
||||
features:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%feature("ref") ""
|
||||
%feature("unref") "delete $this;"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In other words, SWIG will not do anything special when a new object
|
||||
is passed to python, and it will always 'delete' the underlying object when
|
||||
python releases the proxy instance.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="Customization.html#Customization_ownership">%newobject feature</a> is designed to indicate to
|
||||
the target language that it should take ownership of the returned object.
|
||||
When used in conjunction with a type that has the "ref" feature associated with it, it additionally emits the
|
||||
code in the "ref" feature into the C++ wrapper.
|
||||
Consider wrapping the following factory function in addition to the above:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%newobject AFactory;
|
||||
A *AFactory() {
|
||||
return new A();
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The <tt>AFactory</tt> function now acts much like a call to the <tt>A</tt> constructor with respect to memory handling:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
a = AFactory() # SWIG ref 'a' due to %newobject (count: 1)
|
||||
exit # 'a' is released, SWIG unref 'a' called in the destructor wrapper (count: 0)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
<H2><a name="SWIGPlus_nn35"></a>6.26 Using declarations and inheritance</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4781,7 +4960,7 @@ public:
|
|||
</div>
|
||||
</ul>
|
||||
|
||||
<H2><a name="SWIGPlus_nested_classes"></a>6.26 Nested classes</H2>
|
||||
<H2><a name="SWIGPlus_nested_classes"></a>6.27 Nested classes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4925,7 +5104,7 @@ Nested class warnings could also not be suppressed using %warnfilter.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="SWIGPlus_const"></a>6.27 A brief rant about const-correctness</H2>
|
||||
<H2><a name="SWIGPlus_const"></a>6.28 A brief rant about const-correctness</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4983,7 +5162,7 @@ using another tool if maintaining constness is the most important part
|
|||
of your project.
|
||||
</p>
|
||||
|
||||
<H2><a name="SWIGPlus_nn42"></a>6.28 Where to go for more information</H2>
|
||||
<H2><a name="SWIGPlus_nn42"></a>6.29 Where to go for more information</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Sections"></a>SWIG-2.0 Documentation</H1>
|
||||
|
||||
Last update : SWIG-2.0.1 (in progress)
|
||||
Last update : SWIG-2.0.10 (in progress)
|
||||
|
||||
<H2>Sections</H2>
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ Last update : SWIG-2.0.1 (in progress)
|
|||
<li><a href="SWIG.html#SWIG">SWIG Basics</a> (Read this!)</li>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a></li>
|
||||
<li><a href="Preprocessor.html#Preprocessor">The SWIG preprocessor</a></li>
|
||||
<li><a href="Library.html#Library">The SWIG Library</a></li>
|
||||
<li><a href="Library.html#Library">The SWIG library</a></li>
|
||||
<li><a href="Arguments.html#Arguments">Argument handling</a></li>
|
||||
<li><a href="Typemaps.html#Typemaps">Typemaps</a></li>
|
||||
<li><a href="Customization.html#Customization">Customization features</a></li>
|
||||
|
|
@ -33,24 +33,26 @@ Last update : SWIG-2.0.1 (in progress)
|
|||
<H3>Language Module Documentation</H3>
|
||||
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl">Allegro CL support</a></li>
|
||||
<li><a href="Allegrocl.html#Allegrocl">Allegro Common Lisp support</a></li>
|
||||
<li><a href="Android.html#Android">Android support</a></li>
|
||||
<li><a href="CSharp.html#CSharp">C# support</a></li>
|
||||
<li><a href="Chicken.html#Chicken">Chicken support</a></li>
|
||||
<li><a href="D.html#D">D support</a></li>
|
||||
<li><a href="Go.html#Go">Go support</a></li>
|
||||
<li><a href="Guile.html#Guile">Guile support</a></li>
|
||||
<li><a href="Java.html#Java">Java support</a></li>
|
||||
<li><a href="Lua.html#Lua">Lua support</a></li>
|
||||
<li><a href="Lisp.html#Lisp">Common Lisp support</a></li>
|
||||
<li><a href="Lua.html#Lua">Lua support</a></li>
|
||||
<li><a href="Modula3.html#Modula3">Modula3 support</a></li>
|
||||
<li><a href="Mzscheme.html#MzScheme">MzScheme support</a></li>
|
||||
<li><a href="Mzscheme.html#Mzscheme">MzScheme/Racket support</a></li>
|
||||
<li><a href="Ocaml.html#Ocaml">Ocaml support</a></li>
|
||||
<li><a href="Octave.html#Octave">Octave support</a></li>
|
||||
<li><a href="Perl5.html#Perl5">Perl5 support</a></li>
|
||||
<li><a href="Php.html#Php">PHP support</a></li>
|
||||
<li><a href="Pike.html#Pike">Pike support</a></li>
|
||||
<li><a href="Python.html#Python">Python support</a></li>
|
||||
<li><a href="Ruby.html#Ruby">Ruby support</a></li>
|
||||
<li><a href="R.html#R">R support</a></li>
|
||||
<li><a href="Ruby.html#Ruby">Ruby support</a></li>
|
||||
<li><a href="Tcl.html#Tcl">Tcl support</a></li>
|
||||
</ul>
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Tcl"></a>34 SWIG and Tcl</H1>
|
||||
<H1><a name="Tcl"></a>37 SWIG and Tcl</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -83,7 +83,7 @@ Tcl 8.0 or a later release. Earlier releases of SWIG supported Tcl 7.x, but
|
|||
this is no longer supported.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn2"></a>34.1 Preliminaries</H2>
|
||||
<H2><a name="Tcl_nn2"></a>37.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -109,7 +109,7 @@ build a Tcl extension module. To finish building the module, you
|
|||
need to compile this file and link it with the rest of your program.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn3"></a>34.1.1 Getting the right header files</H3>
|
||||
<H3><a name="Tcl_nn3"></a>37.1.1 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -127,12 +127,13 @@ this is the case, you should probably make a symbolic link so that <tt>tcl.h</tt
|
|||
header file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn4"></a>34.1.2 Compiling a dynamic module</H3>
|
||||
<H3><a name="Tcl_nn4"></a>37.1.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The preferred approach to building an extension module is to compile it into
|
||||
a shared object file or DLL. To do this, you will need to compile your program
|
||||
a shared object file or DLL. Assuming you have code you need to link to in a file
|
||||
called <tt>example.c</tt>, you will need to compile your program
|
||||
using commands like this (shown for Linux):
|
||||
</p>
|
||||
|
||||
|
|
@ -162,7 +163,7 @@ The name of the module is specified using the <tt>%module</tt> directive or the
|
|||
<tt> -module</tt> command line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn5"></a>34.1.3 Static linking</H3>
|
||||
<H3><a name="Tcl_nn5"></a>37.1.3 Static linking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -228,7 +229,7 @@ minimal in most situations (and quite frankly not worth the extra
|
|||
hassle in the opinion of this author).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn6"></a>34.1.4 Using your module</H3>
|
||||
<H3><a name="Tcl_nn6"></a>37.1.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -356,7 +357,7 @@ to the default system configuration (this requires root access and you will need
|
|||
the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn7"></a>34.1.5 Compilation of C++ extensions</H3>
|
||||
<H3><a name="Tcl_nn7"></a>37.1.5 Compilation of C++ extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -439,7 +440,7 @@ erratic program behavior. If working with lots of software components, you
|
|||
might want to investigate using a more formal standard such as COM.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn8"></a>34.1.6 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Tcl_nn8"></a>37.1.6 Compiling for 64-bit platforms</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -466,7 +467,7 @@ also introduce problems on platforms that support more than one
|
|||
linking standard (e.g., -o32 and -n32 on Irix).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn9"></a>34.1.7 Setting a package prefix</H3>
|
||||
<H3><a name="Tcl_nn9"></a>37.1.7 Setting a package prefix</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -485,7 +486,7 @@ option will append the prefix to the name when creating a command and
|
|||
call it "<tt>Foo_bar</tt>".
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn10"></a>34.1.8 Using namespaces</H3>
|
||||
<H3><a name="Tcl_nn10"></a>37.1.8 Using namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -507,7 +508,7 @@ When the<tt> -namespace</tt> option is used, objects in the module
|
|||
are always accessed with the namespace name such as <tt>Foo::bar</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn11"></a>34.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
|
||||
<H2><a name="Tcl_nn11"></a>37.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -518,7 +519,7 @@ covers the process of using SWIG with Microsoft Visual C++.
|
|||
although the procedure may be similar with other compilers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn12"></a>34.2.1 Running SWIG from Developer Studio</H3>
|
||||
<H3><a name="Tcl_nn12"></a>37.2.1 Running SWIG from Developer Studio</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -576,7 +577,7 @@ MSDOS > tclsh80
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn13"></a>34.2.2 Using NMAKE</H3>
|
||||
<H3><a name="Tcl_nn13"></a>37.2.2 Using NMAKE</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -639,7 +640,7 @@ to get you started. With a little practice, you'll be making lots of
|
|||
Tcl extensions.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn14"></a>34.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Tcl_nn14"></a>37.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -650,7 +651,7 @@ classes. This section briefly covers the essential aspects of this
|
|||
wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn15"></a>34.3.1 Modules</H3>
|
||||
<H3><a name="Tcl_nn15"></a>37.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -684,7 +685,7 @@ To fix this, supply an extra argument to <tt>load</tt> like this:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn16"></a>34.3.2 Functions</H3>
|
||||
<H3><a name="Tcl_nn16"></a>37.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -709,7 +710,7 @@ like you think it does:
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn17"></a>34.3.3 Global variables</H3>
|
||||
<H3><a name="Tcl_nn17"></a>37.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -789,7 +790,7 @@ extern char *path; // Read-only (due to %immutable)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn18"></a>34.3.4 Constants and enums</H3>
|
||||
<H3><a name="Tcl_nn18"></a>37.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -873,7 +874,7 @@ When an identifier name is given, it is used to perform an implicit hash-table l
|
|||
conversion. This allows the <tt>global</tt> statement to be omitted.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn19"></a>34.3.5 Pointers</H3>
|
||||
<H3><a name="Tcl_nn19"></a>37.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -969,7 +970,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
|
|||
<tt>None</tt> if the conversion can't be performed.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn20"></a>34.3.6 Structures</H3>
|
||||
<H3><a name="Tcl_nn20"></a>37.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1251,7 +1252,7 @@ Note: Tcl only destroys the underlying object if it has ownership. See the
|
|||
memory management section that appears shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn21"></a>34.3.7 C++ classes</H3>
|
||||
<H3><a name="Tcl_nn21"></a>37.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1318,7 +1319,7 @@ In Tcl, the static member is accessed as follows:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn22"></a>34.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Tcl_nn22"></a>37.3.8 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1367,7 +1368,7 @@ For instance:
|
|||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn23"></a>34.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Tcl_nn23"></a>37.3.9 Pointers, references, values, and arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1421,7 +1422,7 @@ to hold the result and a pointer is returned (Tcl will release this memory
|
|||
when the return value is garbage collected).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn24"></a>34.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Tcl_nn24"></a>37.3.10 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1544,7 +1545,7 @@ first declaration takes precedence.
|
|||
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn25"></a>34.3.11 C++ operators</H3>
|
||||
<H3><a name="Tcl_nn25"></a>37.3.11 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1646,7 +1647,7 @@ There are ways to make this operator appear as part of the class using the <tt>%
|
|||
Keep reading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn26"></a>34.3.12 C++ namespaces</H3>
|
||||
<H3><a name="Tcl_nn26"></a>37.3.12 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1710,7 +1711,7 @@ utilizes thousands of small deeply nested namespaces each with
|
|||
identical symbol names, well, then you get what you deserve.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn27"></a>34.3.13 C++ templates</H3>
|
||||
<H3><a name="Tcl_nn27"></a>37.3.13 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1762,7 +1763,7 @@ More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</
|
|||
examples will appear later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn28"></a>34.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Tcl_nn28"></a>37.3.14 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1846,7 +1847,7 @@ simply use the <tt>__deref__()</tt> method. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn29"></a>34.4 Further details on the Tcl class interface</H2>
|
||||
<H2><a name="Tcl_nn29"></a>37.4 Further details on the Tcl class interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1859,7 +1860,7 @@ of low-level details were omitted. This section provides a brief overview
|
|||
of how the proxy classes work.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn30"></a>34.4.1 Proxy classes</H3>
|
||||
<H3><a name="Tcl_nn30"></a>37.4.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1924,7 +1925,7 @@ function. This allows objects to be encapsulated objects that look a lot like
|
|||
as shown in the last section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn31"></a>34.4.2 Memory management</H3>
|
||||
<H3><a name="Tcl_nn31"></a>37.4.2 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2112,7 +2113,7 @@ typemaps--an advanced topic discussed later.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Tcl_nn32"></a>34.5 Input and output parameters</H2>
|
||||
<H2><a name="Tcl_nn32"></a>37.5 Input and output parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2300,7 +2301,7 @@ set c [lindex $dim 1]
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn33"></a>34.6 Exception handling </H2>
|
||||
<H2><a name="Tcl_nn33"></a>37.6 Exception handling </H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2434,7 +2435,7 @@ Since SWIG's exception handling is user-definable, you are not limited to C++ ex
|
|||
See the chapter on "<a href="Customization.html#Customization">Customization Features</a>" for more examples.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn34"></a>34.7 Typemaps</H2>
|
||||
<H2><a name="Tcl_nn34"></a>37.7 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2451,7 +2452,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Tcl interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn35"></a>34.7.1 What is a typemap?</H3>
|
||||
<H3><a name="Tcl_nn35"></a>37.7.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2568,7 +2569,7 @@ parameter is omitted):
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn36"></a>34.7.2 Tcl typemaps</H3>
|
||||
<H3><a name="Tcl_nn36"></a>37.7.2 Tcl typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2706,7 +2707,7 @@ Initialize an argument to a value before any conversions occur.
|
|||
Examples of these methods will appear shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn37"></a>34.7.3 Typemap variables</H3>
|
||||
<H3><a name="Tcl_nn37"></a>37.7.3 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2777,7 +2778,7 @@ properly assigned.
|
|||
The Tcl name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn38"></a>34.7.4 Converting a Tcl list to a char ** </H3>
|
||||
<H3><a name="Tcl_nn38"></a>37.7.4 Converting a Tcl list to a char ** </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2839,7 +2840,7 @@ argv[2] = Larry
|
|||
3
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn39"></a>34.7.5 Returning values in arguments</H3>
|
||||
<H3><a name="Tcl_nn39"></a>37.7.5 Returning values in arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2881,7 +2882,7 @@ result, a Tcl function using these typemaps will work like this :
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn40"></a>34.7.6 Useful functions</H3>
|
||||
<H3><a name="Tcl_nn40"></a>37.7.6 Useful functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2958,7 +2959,7 @@ int Tcl_IsShared(Tcl_Obj *obj);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn41"></a>34.7.7 Standard typemaps</H3>
|
||||
<H3><a name="Tcl_nn41"></a>37.7.7 Standard typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3042,7 +3043,7 @@ work)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn42"></a>34.7.8 Pointer handling</H3>
|
||||
<H3><a name="Tcl_nn42"></a>37.7.8 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3118,7 +3119,7 @@ For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn43"></a>34.8 Turning a SWIG module into a Tcl Package.</H2>
|
||||
<H2><a name="Tcl_nn43"></a>37.8 Turning a SWIG module into a Tcl Package.</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3190,7 +3191,7 @@ As a final note, most SWIG examples do not yet use the
|
|||
to use the <tt>load</tt> command instead.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn44"></a>34.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
|
||||
<H2><a name="Tcl_nn44"></a>37.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3289,7 +3290,7 @@ danger of blowing something up (although it is easily accomplished
|
|||
with an out of bounds array access).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn45"></a>34.9.1 Proxy classes</H3>
|
||||
<H3><a name="Tcl_nn45"></a>37.9.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3410,7 +3411,7 @@ short, but clever Tcl script can be combined with SWIG to do many
|
|||
interesting things.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn46"></a>34.10 Tcl/Tk Stubs</H2>
|
||||
<H2><a name="Tcl_nn46"></a>37.10 Tcl/Tk Stubs</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -73,6 +73,7 @@
|
|||
<li><a href="#Typemaps_nn43">Typemaps for multiple target languages</a>
|
||||
<li><a href="#Typemaps_optimal">Optimal code generation when returning by value</a>
|
||||
<li><a href="#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a>
|
||||
<li><a href="#Typemaps_warnings">Typemap warnings</a>
|
||||
<li><a href="#Typemaps_fragments">Typemap fragments</a>
|
||||
<ul>
|
||||
<li><a href="#Typemaps_fragment_type_specialization">Fragment type specialization</a>
|
||||
|
|
@ -1711,7 +1712,8 @@ you'll find the full typemap contents (example shown below for Python):
|
|||
%typemap(in, noblock=1) SWIGTYPE [] (void *argp = 0, int res = 0) {
|
||||
res = SWIG_ConvertPtr($input, &argp,$descriptor, $disown | 0 );
|
||||
if (!SWIG_IsOK(res)) {
|
||||
SWIG_exception_fail(SWIG_ArgError(res), "in method '" "$symname" "', argument " "$argnum"" of type '" "$type""'");
|
||||
SWIG_exception_fail(SWIG_ArgError(res), "in method '" "$symname" "', argument "
|
||||
"$argnum"" of type '" "$type""'");
|
||||
}
|
||||
$1 = ($ltype)(argp);
|
||||
}
|
||||
|
|
@ -1732,7 +1734,8 @@ SWIGINTERN PyObject *_wrap_foo(PyObject *SWIGUNUSEDPARM(self), PyObject *args) {
|
|||
...
|
||||
res1 = SWIG_ConvertPtr(obj0, &argp1,SWIGTYPE_p_a_4__int, 0 | 0 );
|
||||
if (!SWIG_IsOK(res1)) {
|
||||
SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "foo" "', argument " "1"" of type '" "int [10][4]""'");
|
||||
SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "foo" "', argument "
|
||||
"1"" of type '" "int [10][4]""'");
|
||||
}
|
||||
arg1 = (int (*)[4])(argp1);
|
||||
...
|
||||
|
|
@ -1791,7 +1794,8 @@ void set_value(const char* val) {}
|
|||
}
|
||||
}
|
||||
|
||||
%apply SWIGTYPE * { const char* val, const char* another_value } // use default pointer handling instead of strings
|
||||
// use default pointer handling instead of strings
|
||||
%apply SWIGTYPE * { const char* val, const char* another_value }
|
||||
|
||||
%typemap(check) const char* val = char* NON_NULL;
|
||||
|
||||
|
|
@ -3296,7 +3300,8 @@ SWIG can detect when the "optimal" attribute cannot be used and will ignore it a
|
|||
<div class="targetlang">
|
||||
<pre>
|
||||
example.i:28: Warning 474: Method XX::create() usage of the optimal attribute ignored
|
||||
example.i:14: Warning 474: in the out typemap as the following cannot be used to generate optimal code:
|
||||
example.i:14: Warning 474: in the out typemap as the following cannot be used to generate
|
||||
optimal code:
|
||||
try {
|
||||
result = XX::create();
|
||||
} catch(const std::exception &e) {
|
||||
|
|
@ -3317,8 +3322,8 @@ In fact SWIG attempts to detect this and will issue a warning something like:
|
|||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
example.i:21: Warning 475: Multiple calls to XX::create() might be generated due to optimal attribute usage in
|
||||
example.i:7: Warning 475: the out typemap.
|
||||
example.i:21: Warning 475: Multiple calls to XX::create() might be generated due to
|
||||
example.i:7: Warning 475: optimal attribute usage in the out typemap.
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -3593,7 +3598,16 @@ with non-consecutive C/C++ arguments; a workaround such as a helper function re-
|
|||
the arguments to make them consecutive will need to be written.
|
||||
</p>
|
||||
|
||||
<H2><a name="Typemaps_fragments"></a>10.10 Typemap fragments</H2>
|
||||
<H2><a name="Typemaps_warnings"></a>10.10 Typemap warnings</H2>
|
||||
|
||||
|
||||
<p>
|
||||
Warnings can be added to typemaps so that SWIG generates a warning message whenever the typemap is used.
|
||||
See the information in the <a href="Warnings.html#Warnings_nn5">issuing warnings</a> section.
|
||||
</p>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_fragments"></a>10.11 Typemap fragments</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3659,17 +3673,21 @@ generated into the wrapper code before any typemap code that calls it.
|
|||
<p>
|
||||
To define a fragment you need a fragment name, a section name for generating the fragment code into, and the code itself.
|
||||
See <a href="SWIG.html#SWIG_nn42">Code insertion blocks</a> for a full list of section names.
|
||||
Usually the section name used is "header". Both string and curly braces can be used:
|
||||
Usually the section name used is "header". Different delimiters can be used:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%fragment("my_name", "header") %{ ... %}
|
||||
%fragment("my_name", "header") { ... }
|
||||
%fragment("my_name", "header") " ... "
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
and these follow the usual preprocessing rules mentioned in the
|
||||
<a href="Preprocessor.html#Preprocessor_delimiters">Preprocessing delimiters</a>
|
||||
section.
|
||||
The following are some rules and guidelines for using fragments:
|
||||
</p>
|
||||
|
||||
|
|
@ -3747,8 +3765,8 @@ A fragment can use one or more additional fragments, for example:
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%fragment("<limits.h>", "header") {
|
||||
#include <limits.h>
|
||||
%fragment("<limits.h>", "header") {
|
||||
%#include <limits.h>
|
||||
}
|
||||
|
||||
|
||||
|
|
@ -3842,7 +3860,7 @@ fragment usage unless a desire to really get to grips
|
|||
with some powerful but tricky macro and fragment usage that is used in parts of the SWIG typemap library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Typemaps_fragment_type_specialization"></a>10.10.1 Fragment type specialization</H3>
|
||||
<H3><a name="Typemaps_fragment_type_specialization"></a>10.11.1 Fragment type specialization</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3875,7 +3893,7 @@ struct A {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Typemaps_automatic_specialization"></a>10.10.2 Fragments and automatic typemap specialization</H3>
|
||||
<H3><a name="Typemaps_automatic_specialization"></a>10.11.2 Fragments and automatic typemap specialization</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3921,7 +3939,7 @@ The interested (or very brave) reader can take a look at the fragments.swg file
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_runtime_type_checker"></a>10.11 The run-time type checker</H2>
|
||||
<H2><a name="Typemaps_runtime_type_checker"></a>10.12 The run-time type checker</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3947,7 +3965,7 @@ language modules.</li>
|
|||
<li>Modules can be unloaded from the type system.</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Typemaps_nn45"></a>10.11.1 Implementation</H3>
|
||||
<H3><a name="Typemaps_nn45"></a>10.12.1 Implementation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4133,7 +4151,7 @@ structures rather than creating new ones. These <tt>swig_module_info</tt>
|
|||
structures are chained together in a circularly linked list.
|
||||
</p>
|
||||
|
||||
<H3><a name="Typemaps_runtime_type_checker_usage"></a>10.11.2 Usage</H3>
|
||||
<H3><a name="Typemaps_runtime_type_checker_usage"></a>10.12.2 Usage</H3>
|
||||
|
||||
|
||||
<p>This section covers how to use these functions from typemaps. To learn how to
|
||||
|
|
@ -4227,7 +4245,7 @@ probably just look at the output of SWIG to get a better sense for how types are
|
|||
managed.
|
||||
</p>
|
||||
|
||||
<H2><a name="Typemaps_overloading"></a>10.12 Typemaps and overloading</H2>
|
||||
<H2><a name="Typemaps_overloading"></a>10.13 Typemaps and overloading</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4538,7 +4556,7 @@ Subsequent "in" typemaps would then perform more extensive type-checking.
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H2><a name="Typemaps_nn48"></a>10.13 More about <tt>%apply</tt> and <tt>%clear</tt></H2>
|
||||
<H2><a name="Typemaps_nn48"></a>10.14 More about <tt>%apply</tt> and <tt>%clear</tt></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4624,7 +4642,7 @@ example:
|
|||
</div>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_nn47"></a>10.14 Passing data between typemaps</H2>
|
||||
<H2><a name="Typemaps_nn47"></a>10.15 Passing data between typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4661,7 +4679,7 @@ sure that the typemaps sharing information have exactly the same types and names
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_nn52"></a>10.15 C++ "this" pointer</H2>
|
||||
<H2><a name="Typemaps_nn52"></a>10.16 C++ "this" pointer</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4721,7 +4739,7 @@ will also match the typemap. One work around is to create an interface file tha
|
|||
the method, but gives the argument a name other than <tt>self</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Typemaps_nn51"></a>10.16 Where to go for more information?</H2>
|
||||
<H2><a name="Typemaps_nn51"></a>10.17 Where to go for more information?</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -331,33 +331,82 @@ int open(const char *path, int oflags, int mode = 0);
|
|||
<p>
|
||||
In this case, <tt>%varargs</tt> is simply providing more specific information about the
|
||||
extra arguments that might be passed to a function.
|
||||
If the parameters to a varargs function are of uniform type, <tt>%varargs</tt> can also
|
||||
If the arguments to a varargs function are of uniform type, <tt>%varargs</tt> can also
|
||||
accept a numerical argument count as follows:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%varargs(10,char *arg = NULL) execlp;
|
||||
%varargs(3, char *str = NULL) execlp;
|
||||
...
|
||||
int execlp(const char *path, const char *arg1, ...);
|
||||
int execlp(const char *path, const char *arg, ...);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
This would wrap <tt>execlp()</tt> as a function that accepted up to 10 optional arguments.
|
||||
and is effectively seen as:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
int execlp(const char *path, const char *arg,
|
||||
char *str1 = NULL,
|
||||
char *str2 = NULL,
|
||||
char *str3 = NULL);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
This would wrap <tt>execlp()</tt> as a function that accepted up to 3 optional arguments.
|
||||
Depending on the application, this may be more than enough for practical purposes.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Argument replacement is most appropriate in cases where the types of
|
||||
the extra arguments is uniform and the maximum number of arguments is
|
||||
known. When replicated argument replacement is used, at least one extra
|
||||
argument is added to the end of the arguments when making the function call.
|
||||
This argument serves as a sentinel to make sure the list is properly terminated.
|
||||
It has the same value as that supplied to the <tt>%varargs</tt> directive.
|
||||
The handling of <a href="SWIGPlus.html#SWIGPlus_default_args">default arguments</a> can be changed via the
|
||||
<tt>compactdefaultargs</tt> feature. If this feature is used, for example
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%feature("compactdefaultargs") execlp;
|
||||
%varargs(3, char *str = NULL) execlp;
|
||||
...
|
||||
int execlp(const char *path, const char *arg, ...);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
a call from the target language which does not provide the maximum number of arguments, such as,
|
||||
<tt>execlp("a", "b", "c")</tt>
|
||||
will generate C code which includes the missing default values, that is, <tt>execlp("a", "b", "c", NULL, NULL)</tt>.
|
||||
If <tt>compactdefaultargs</tt> is not used, then the generated code will be
|
||||
<tt>execlp("a", "b", "c")</tt>. The former is useful for helping providing a sentinel to terminate the argument list.
|
||||
However, this is not guaranteed, for example when a user passes a non-NULL value for all the parameters.
|
||||
When using <tt>compactdefaultargs</tt> it is possible to guarantee the NULL sentinel is passed through the,
|
||||
<tt>numinputs=0</tt> <a href="Typemaps.html#Typemaps_nn26">'in' typemap attribute</a>, naming the <b>last parameter</b>.
|
||||
For example,
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%feature("compactdefaultargs") execlp;
|
||||
%varargs(3, char *str = NULL) execlp;
|
||||
%typemap(in, numinputs=0) char *str3 ""
|
||||
...
|
||||
int execlp(const char *path, const char *arg, ...);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Note that <tt>str3</tt> is the name of the last argument, as we have used <tt>%vargars</tt> with 3.
|
||||
Now <tt>execlp("a", "b", "c", "d", "e")</tt> will result in an error as one too many arguments has been passed,
|
||||
as now only 2 additional 'str' arguments can be passed with the 3rd one always using the specified default <tt>NULL</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Argument replacement is most appropriate in cases where the types of
|
||||
the extra arguments are uniform and the maximum number of arguments are
|
||||
known.
|
||||
Argument replacement is not as useful when working with functions that accept
|
||||
mixed argument types such as <tt>printf()</tt>. Providing general purpose
|
||||
wrappers to such functions presents special problems (covered shortly).
|
||||
|
|
@ -461,23 +510,36 @@ like this:
|
|||
<div class="code">
|
||||
<pre>
|
||||
%typemap(in) (...)(char *args[10]) {
|
||||
int i;
|
||||
int argc;
|
||||
for (i = 0; i < 10; i++) args[i] = 0;
|
||||
argc = PyTuple_Size(varargs);
|
||||
if (argc > 10) {
|
||||
PyErr_SetString(PyExc_ValueError,"Too many arguments");
|
||||
int i;
|
||||
int argc;
|
||||
for (i = 0; i < 10; i++) args[i] = 0;
|
||||
argc = PyTuple_Size(varargs);
|
||||
if (argc > 10) {
|
||||
PyErr_SetString(PyExc_ValueError, "Too many arguments");
|
||||
return NULL;
|
||||
}
|
||||
for (i = 0; i < argc; i++) {
|
||||
PyObject *pyobj = PyTuple_GetItem(varargs, i);
|
||||
char *str = 0;
|
||||
%#if PY_VERSION_HEX>=0x03000000
|
||||
PyObject *pystr;
|
||||
if (!PyUnicode_Check(pyobj)) {
|
||||
PyErr_SetString(PyExc_ValueError, "Expected a string");
|
||||
return NULL;
|
||||
}
|
||||
for (i = 0; i < argc; i++) {
|
||||
PyObject *o = PyTuple_GetItem(varargs,i);
|
||||
if (!PyString_Check(o)) {
|
||||
PyErr_SetString(PyExc_ValueError,"Expected a string");
|
||||
return NULL;
|
||||
}
|
||||
args[i] = PyString_AsString(o);
|
||||
pystr = PyUnicode_AsUTF8String(pyobj);
|
||||
str = PyBytes_AsString(pystr);
|
||||
Py_XDECREF(pystr);
|
||||
%#else
|
||||
if (!PyString_Check(pyobj)) {
|
||||
PyErr_SetString(PyExc_ValueError, "Expected a string");
|
||||
return NULL;
|
||||
}
|
||||
$1 = (void *) args;
|
||||
str = PyString_AsString(pyobj);
|
||||
%#endif
|
||||
args[i] = str;
|
||||
}
|
||||
$1 = (void *) args;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -777,13 +839,13 @@ of type <tt>va_list</tt>. For example:
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
int vfprintf(FILE *f, const char *fmt, va_list ap);
|
||||
int vprintf(const char *fmt, va_list ap);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
As far as we know, there is no obvious way to wrap these functions
|
||||
with SWIG. This is because there is no documented way to assemble the
|
||||
As far as we know, there is no obvious way to wrap these functions with
|
||||
SWIG. This is because there is no documented way to assemble the
|
||||
proper va_list structure (there are no C library functions to do it
|
||||
and the contents of va_list are opaque). Not only that, the contents
|
||||
of a <tt>va_list</tt> structure are closely tied to the underlying
|
||||
|
|
@ -791,6 +853,36 @@ call-stack. It's not clear that exporting a <tt>va_list</tt> would
|
|||
have any use or that it would work at all.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A workaround can be implemented by writing a simple varargs C wrapper and then using the techniques
|
||||
discussed earlier in this chapter for varargs. Below is a simple wrapper for <tt>vprintf</tt> renamed so that
|
||||
it can still be called as <tt>vprintf</tt> from your target language. The <tt>%varargs</tt>
|
||||
used in the example restricts the function to taking one string argument.
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%{
|
||||
int vprintf(const char *fmt, va_list ap);
|
||||
%}
|
||||
|
||||
%varargs(const char *) my_vprintf;
|
||||
%rename(vprintf) my_vprintf;
|
||||
|
||||
%inline %{
|
||||
int my_vprintf(const char *fmt, ...) {
|
||||
va_list ap;
|
||||
int result;
|
||||
|
||||
va_start(ap, fmt);
|
||||
result = vprintf(fmt, ap);
|
||||
va_end(ap);
|
||||
return result;
|
||||
}
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Varargs_nn9"></a>13.8 C++ Issues</H2>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
<li><a href="#Warnings_nn12">C/C++ Parser (300-399)</a>
|
||||
<li><a href="#Warnings_nn13">Types and typemaps (400-499) </a>
|
||||
<li><a href="#Warnings_nn14">Code generation (500-599)</a>
|
||||
<li><a href="#Warnings_nn15">Language module specific (800-899) </a>
|
||||
<li><a href="#Warnings_nn15">Language module specific (700-899) </a>
|
||||
<li><a href="#Warnings_nn16">User defined (900-999)</a>
|
||||
</ul>
|
||||
<li><a href="#Warnings_nn17">History</a>
|
||||
|
|
@ -257,16 +257,23 @@ Warning messages can be associated with typemaps using the
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%typemap(in, warning="901:You are really going to regret this") blah * {
|
||||
%typemap(in, warning="901:You are really going to regret this usage of $1_type $1_name") blah * {
|
||||
...
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In this case, the warning message will be printed whenever the typemap is actually used.
|
||||
In this case, the warning message will be printed whenever the typemap is actually used and the <a href="Typemaps.html#Typemaps_special_variables">special variables</a> will be expanded as appropriate, for example:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
example.i:23: Warning 901: You are really going to regret this usage of blah * self
|
||||
example.i:24: Warning 901: You are really going to regret this usage of blah * stuff
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Warnings_symbolic_symbols"></a>14.5 Symbolic symbols</H2>
|
||||
|
||||
|
||||
|
|
@ -381,8 +388,12 @@ example.i(4) : Syntax error in input.
|
|||
|
||||
|
||||
<ul>
|
||||
<li>201. Unable to find 'filename'.
|
||||
<li>202. Could not evaluate 'expr'.
|
||||
<li>201. Unable to find <em>filename</em>.
|
||||
<li>202. Could not evaluate expression <em>expr</em>.
|
||||
<li>203. Both includeall and importall are defined: using includeall.
|
||||
<li>204. CPP #warning, "<em>warning</em>".
|
||||
<li>205. CPP #error, "<em>error</em>".
|
||||
<li>206. Unexpected tokens after #<em>directive</em> directive.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn12"></a>14.9.3 C/C++ Parser (300-399)</H3>
|
||||
|
|
@ -497,7 +508,7 @@ example.i(4) : Syntax error in input.
|
|||
<li>501. Overloaded declaration ignored. <em>decl</em>. Previous declaration is <em>decl</em>.
|
||||
<li>502. Overloaded constructor ignored. <em>decl</em>. Previous declaration is <em>decl</em>.
|
||||
<li>503. Can't wrap '<em>identifier</em>' unless renamed to a valid identifier.
|
||||
<li>504. Function <em>name</em> must have a return type.
|
||||
<li>504. Function <em>name</em> must have a return type. Ignored.
|
||||
<li>505. Variable length arguments discarded.
|
||||
<li>506. Can't wrap varargs with keyword arguments enabled.
|
||||
<li>507. Adding native function <em>name</em> not supported (ignored).
|
||||
|
|
@ -513,9 +524,11 @@ example.i(4) : Syntax error in input.
|
|||
<li>517.
|
||||
<li>518. Portability warning: File <em>file1</em> will be overwritten by <em>file2</em> on case insensitive filesystems such as Windows' FAT32 and NTFS unless the class/module name is renamed.
|
||||
<li>519. %template() contains no name. Template method ignored: <em>declaration</em>
|
||||
<li>520. <em>Base/Derived</em> class '<em>classname1</em>' of '<em>classname2</em>' is not similarly marked as a smart pointer.
|
||||
<li>521. Illegal destructor name <em>name</em>. Ignored.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn15"></a>14.9.6 Language module specific (800-899) </H3>
|
||||
<H3><a name="Warnings_nn15"></a>14.9.6 Language module specific (700-899) </H3>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -538,6 +551,8 @@ example.i(4) : Syntax error in input.
|
|||
<li>822. Covariant return types not supported in Java. Proxy method will return <em>basetype</em> (Java).
|
||||
<li>823. No javaconstruct typemap defined for <em>type</em> (Java).
|
||||
<li>824. Missing JNI descriptor in directorin typemap defined for <em>type</em> (Java).
|
||||
<li>825. "directorconnect" attribute missing in <em>type</em> "javaconstruct" typemap. (Java).
|
||||
<li>826. The nspace feature is used on '<em>type</em>' without -package. The generated code may not compile as Java does not support types declared in a named package accessing types declared in an unnamed package. (Java).
|
||||
</ul>
|
||||
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -236,8 +236,8 @@ The short abbreviated instructions follow...
|
|||
</ul>
|
||||
|
||||
<p>
|
||||
The step by step instructions to download and install MinGW and MSYS, then download and build the latest version of SWIG from SVN follow...
|
||||
Note that the instructions for obtaining SWIG from SVN are also online at <a href="http://www.swig.org/svn.html">SWIG SVN</a>.
|
||||
The step by step instructions to download and install MinGW and MSYS, then download and build the latest version of SWIG from Github follow...
|
||||
Note that the instructions for obtaining SWIG from Github are also online at <a href="http://www.swig.org/svn.html">SWIG Bleeding Edge</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -300,19 +300,35 @@ tar -zxf bison-2.0-MSYS.tar.gz
|
|||
</li>
|
||||
|
||||
<li>
|
||||
To get the latest SWIG SVN (version from Subversion source control), type in the following:
|
||||
The very latest development version of SWIG is available from <a href="https://github.com/swig/swig">SWIG on Github</a>
|
||||
and can be downloaded as a zip file or if you have Git installed, via Git.
|
||||
Either download the latest <a href="https://github.com/swig/swig/archive/master.zip">Zip file</a> snapshot and unzip and rename the top level folder to /usr/src/swig.
|
||||
|
||||
Otherwise if using Git, type in the following:
|
||||
<div class="shell"><pre>
|
||||
mkdir /usr/src
|
||||
cd /usr/src
|
||||
svn co https://swig.svn.sourceforge.net/svnroot/swig/trunk swig
|
||||
git clone https://github.com/swig/swig.git
|
||||
</pre></div>
|
||||
|
||||
<b>Pitfall note:</b>
|
||||
If you want to check out SWIG to a different folder to the proposed
|
||||
If you want to place SWIG in a different folder to the proposed
|
||||
/usr/src/swig, do not use MSYS emulated windows drive letters, because
|
||||
the autotools will fail miserably on those.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The PCRE third party library needs to be built next.
|
||||
Download the latest PCRE source tarball, such as <tt>pcre-8.10.tar.bz2</tt>, from
|
||||
<a href=http://www.pcre.org>PCRE</a> and place in the <tt>/usr/src/swig</tt> directory.
|
||||
Build PCRE as a static library using the Tools/pcre-build.sh script as follows:
|
||||
|
||||
<div class="shell"><pre>
|
||||
cd /usr/src/swig
|
||||
Tools/pcre-build.sh
|
||||
</pre></div>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
You are now ready to build SWIG. Execute the following commands to build swig.exe:
|
||||
<div class="shell"><pre>
|
||||
|
|
|
|||
BIN
Doc/Manual/android-class.png
Normal file
BIN
Doc/Manual/android-class.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
Doc/Manual/android-simple.png
Normal file
BIN
Doc/Manual/android-simple.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.7 KiB |
|
|
@ -16,8 +16,10 @@ Warnings.html
|
|||
Modules.html
|
||||
CCache.html
|
||||
Allegrocl.html
|
||||
Android.html
|
||||
CSharp.html
|
||||
Chicken.html
|
||||
D.html
|
||||
Go.html
|
||||
Guile.html
|
||||
Java.html
|
||||
|
|
@ -31,8 +33,7 @@ Perl5.html
|
|||
Php.html
|
||||
Pike.html
|
||||
Python.html
|
||||
R.html
|
||||
Ruby.html
|
||||
Tcl.html
|
||||
R.html
|
||||
Extending.html
|
||||
|
||||
|
|
|
|||
5
Doc/Manual/linkchecker.config
Normal file
5
Doc/Manual/linkchecker.config
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
[checking]
|
||||
anchors=1
|
||||
|
||||
[filtering]
|
||||
ignorewarnings=http-robots-denied
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
#!/usr/local/bin/python
|
||||
#!/usr/bin/env python
|
||||
|
||||
###############################################################################
|
||||
# Takes a chapter as input and adds internal links and numbering to all
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
#!/usr/local/bin/python
|
||||
#!/usr/bin/env python
|
||||
|
||||
import sys
|
||||
import os
|
||||
|
|
@ -12,7 +12,7 @@ print >>f, """
|
|||
<TITLE>SWIG Users Manual</TITLE>
|
||||
</HEAD>
|
||||
<BODY BGCOLOR="#ffffff">
|
||||
<H1>SWIG Users Manual</H1>
|
||||
<H1><a name="Contents"></a>SWIG Users Manual</H1>
|
||||
|
||||
<p>
|
||||
"""
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
# certain packages have been installed. Set the prefixes
|
||||
# accordingly.
|
||||
#
|
||||
# 2. To use this makefile, set required varibles, eg SRCS, INTERFACE,
|
||||
# 2. To use this makefile, set required variables, eg SRCS, INTERFACE,
|
||||
# INTERFACEDIR, INCLUDES, LIBS, TARGET, and do a
|
||||
# $(MAKE) -f Makefile.template.in SRCS='$(SRCS)' \
|
||||
# INCLUDES='$(INCLUDES) LIBS='$(LIBS)' INTERFACE='$(INTERFACE)' \
|
||||
|
|
@ -70,7 +70,7 @@ IOBJS = $(IWRAP:.i=.@OBJEXT@)
|
|||
CPP_DLLIBS = #-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2 \
|
||||
-L/usr/local/lib -lg++ -lstdc++ -lgcc
|
||||
|
||||
# Solaris workshop 5.0
|
||||
# Solaris workshop 5.0
|
||||
# CPP_DLLIBS = -L/opt/SUNWspro/lib -lCrun
|
||||
|
||||
# Symbols used for using shared libraries
|
||||
|
|
@ -160,7 +160,7 @@ tcl_cpp: $(SRCS)
|
|||
# -----------------------------------------------------------------
|
||||
|
||||
tcl_clean:
|
||||
rm -f *_wrap* *~ .~* mytclsh@EXEEXT@
|
||||
rm -f *_wrap* *~ .~* mytclsh@EXEEXT@
|
||||
rm -f core @EXTRA_CLEAN@
|
||||
rm -f *.@OBJEXT@ *@SO@
|
||||
|
||||
|
|
@ -297,9 +297,9 @@ python_static_cpp: $(SRCS)
|
|||
$(CXX) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES) \
|
||||
$(PYTHON_INCLUDE) $(LIBS) -L$(PYTHON_LIB) $(PYTHON_LIBOPTS) -o $(TARGET)
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# -----------------------------------------------------------------
|
||||
# Running a Python example
|
||||
# -----------------------------------------------------------------
|
||||
# -----------------------------------------------------------------
|
||||
|
||||
ifeq (,$(PY3))
|
||||
PYSCRIPT = runme.py
|
||||
|
|
@ -314,13 +314,14 @@ python_run: $(PYSCRIPT)
|
|||
|
||||
runme3.py: runme.py
|
||||
cp $< $@
|
||||
$(PY2TO3) -w $@ >/dev/null 2>&1
|
||||
$(PY2TO3) -w $@ >/dev/null 2>&1
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Cleaning the python examples
|
||||
# -----------------------------------------------------------------
|
||||
|
||||
python_clean:
|
||||
rm -rf __pycache__
|
||||
rm -f *_wrap* *~ .~* mypython@EXEEXT@ *.pyc
|
||||
rm -f core @EXTRA_CLEAN@
|
||||
rm -f *.@OBJEXT@ *@SO@ *@PYTHON_SO@
|
||||
|
|
@ -332,11 +333,11 @@ python_clean:
|
|||
##################################################################
|
||||
|
||||
# Make sure these locate your Octave installation
|
||||
OCTAVE_INCLUDE= $(DEFS) @OCTAVEEXT@
|
||||
OCTAVE_LIB =
|
||||
OCTAVE = OCTAVE_HISTFILE=/dev/null @OCTAVE@ -qfH
|
||||
OCTAVE_CXX = $(DEFS) @OCTAVE_CPPFLAGS@ @OCTAVE_CXXFLAGS@
|
||||
|
||||
# Extra Octave specific dynamic linking options
|
||||
OCTAVE_DLNK = @OCTAVEDYNAMICLINKING@
|
||||
OCTAVE_DLNK = @OCTAVE_LDFLAGS@
|
||||
OCTAVE_SO = @OCTAVE_SO@
|
||||
|
||||
# ----------------------------------------------------------------
|
||||
|
|
@ -346,7 +347,7 @@ OCTAVE_SO = @OCTAVE_SO@
|
|||
|
||||
octave: $(SRCS)
|
||||
$(SWIG) -octave $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CXX) -g -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(CXXSRCS) $(INCLUDES) -I$(OCTAVE_INCLUDE)
|
||||
$(CXX) -g -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(INCLUDES) $(OCTAVE_CXX)
|
||||
$(CC) -g -c $(CCSHARED) $(CFLAGS) $(SRCS) $(CSRCS) $(INCLUDES)
|
||||
$(LDSHARED) $(CFLAGS) $(OBJS) $(IOBJS) $(OCTAVE_DLNK) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(OCTAVE_SO)
|
||||
|
||||
|
|
@ -356,14 +357,24 @@ octave: $(SRCS)
|
|||
|
||||
octave_cpp: $(SRCS)
|
||||
$(SWIG) -c++ -octave $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CXX) -g -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES) -I$(OCTAVE_INCLUDE)
|
||||
$(CXX) -g -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES) $(OCTAVE_CXX)
|
||||
$(CXXSHARED) -g $(CXXFLAGS) $(OBJS) $(IOBJS) $(OCTAVE_DLNK) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(OCTAVE_SO)
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Running an Octave example
|
||||
# -----------------------------------------------------------------
|
||||
|
||||
OCTSCRIPT = runme.m
|
||||
|
||||
octave_run: $(OCTSCRIPT)
|
||||
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH OCTAVE_PATH=$(srcdir):$$OCTAVE_PATH $(OCTAVE) $(OCTSCRIPT) >/dev/null
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Cleaning the octave examples
|
||||
# -----------------------------------------------------------------
|
||||
|
||||
octave_clean:
|
||||
rm -rf __pycache__
|
||||
rm -f *_wrap* *~ .~* myoctave@EXEEXT@ *.pyc
|
||||
rm -f core @EXTRA_CLEAN@
|
||||
rm -f *.@OBJEXT@ *@SO@ *@OCTAVE_SO@
|
||||
|
|
@ -549,14 +560,14 @@ mzscheme: $(SRCS)
|
|||
mzscheme_cpp: $(SRCS)
|
||||
$(SWIG) -mzscheme -c++ $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(COMPILETOOL) $(MZC) `echo $(INCLUDES) | sed 's/-I/++ccf -I/g'` --cc $(ICXXSRCS) $(SRCS) $(CXXSRCS)
|
||||
$(CXXSHARED) $(CXXFLAGS) -o $(LIBPREFIX)$(TARGET)$(MZSCHEME_SO) $(OBJS) $(IOBJS) $(MZDYNOBJ) $(CPP_DLLIBS)
|
||||
$(CXXSHARED) $(CXXFLAGS) -o $(LIBPREFIX)$(TARGET)$(MZSCHEME_SO) $(OBJS) $(IOBJS) $(MZDYNOBJ) $(CPP_DLLIBS)
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Cleaning the mzscheme examples
|
||||
# -----------------------------------------------------------------
|
||||
|
||||
mzscheme_clean:
|
||||
rm -f *_wrap* *~ .~*
|
||||
rm -f *_wrap* *~ .~*
|
||||
rm -f core @EXTRA_CLEAN@
|
||||
rm -f *.@OBJEXT@ *@SO@
|
||||
|
||||
|
|
@ -633,7 +644,7 @@ ocaml_static_cpp: $(SRCS)
|
|||
$(OCAMLCORE)
|
||||
$(SWIG) -ocaml -c++ $(SWIGOPT) $(INTERFACEPATH)
|
||||
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
||||
$(OCC) -cc '$(CXX)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
||||
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
||||
$(ICXXSRCS:%.cxx=%.c) $(SRCS) $(CXXSRCS)
|
||||
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
||||
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
|
||||
|
|
@ -644,13 +655,13 @@ ocaml_static_cpp: $(SRCS)
|
|||
$(INTERFACE:%.i=%.cmo) \
|
||||
$(PROGFILE:%.ml=%.cmo) \
|
||||
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) \
|
||||
-cclib "$(LIBS)" -cc '$(CXX)'
|
||||
-cclib "$(LIBS)" -cc '$(CXX) -Wno-write-strings'
|
||||
|
||||
ocaml_static_cpp_toplevel: $(SRCS)
|
||||
$(OCAMLCORE)
|
||||
$(SWIG) -ocaml -c++ $(SWIGOPT) $(INTERFACEPATH)
|
||||
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
||||
$(OCC) -cc '$(CXX)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
||||
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
||||
$(ICXXSRCS:%.cxx=%.c) $(SRCS) $(CXXSRCS)
|
||||
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
||||
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
|
||||
|
|
@ -658,17 +669,17 @@ ocaml_static_cpp_toplevel: $(SRCS)
|
|||
$(OCC) $(OCAMLPP) -c $(PROGFILE)
|
||||
$(NOLINK) || $(OCAMLMKTOP) \
|
||||
swig.cmo \
|
||||
-I $(OCAMLP4WHERE) camlp4o.cma swigp4.cmo \
|
||||
-I $(OCAMLP4WHERE) dynlink.cma camlp4o.cma swigp4.cmo \
|
||||
-g -ccopt -g -cclib -g -custom -o $(TARGET)_top \
|
||||
$(INTERFACE:%.i=%.cmo) \
|
||||
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) \
|
||||
-cclib "$(LIBS)" -cc '$(CXX)'
|
||||
-cclib "$(LIBS)" -cc '$(CXX) -Wno-write-strings'
|
||||
|
||||
ocaml_dynamic_cpp: $(SRCS)
|
||||
$(OCAMLCORE)
|
||||
$(SWIG) -ocaml -c++ $(SWIGOPT) $(INTERFACEPATH)
|
||||
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
||||
$(OCC) -cc '$(CXX)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
||||
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
||||
$(ICXXSRCS:%.cxx=%.c) $(SRCS) $(CXXSRCS) -ccopt -fPIC
|
||||
$(CXXSHARED) $(CXXFLAGS) -o $(INTERFACE:%.i=%@SO@) \
|
||||
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) \
|
||||
|
|
@ -685,7 +696,7 @@ ocaml_dynamic_cpp: $(SRCS)
|
|||
$(OCC) -cclib -export-dynamic -g -ccopt -g -cclib -g -custom \
|
||||
-o $(TARGET) \
|
||||
-package dl -linkpkg \
|
||||
$(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo) -cc '$(CXX)'
|
||||
$(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo) -cc '$(CXX) -Wno-write-strings'
|
||||
|
||||
ocaml_clean:
|
||||
rm -f *_wrap* *~ .~* *.cmo *.cmi $(MLFILE) $(MLFILE)i swig.mli swig.cmi swig.ml swig.cmo swigp4.ml swigp4.cmo
|
||||
|
|
@ -782,7 +793,7 @@ PHP=@PHP@
|
|||
PHPSCRIPT ?= runme.php
|
||||
|
||||
php_run:
|
||||
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH $(RUNTOOL) $(PHP) -n -q -d extension_dir=. -d safe_mode=Off $(PHPSCRIPT)
|
||||
$(RUNTOOL) $(PHP) -n -q -d extension_dir=. -d safe_mode=Off $(PHPSCRIPT)
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Cleaning the PHP examples
|
||||
|
|
@ -845,7 +856,7 @@ pike_cpp_static: $(SRCS)
|
|||
# -----------------------------------------------------------------
|
||||
|
||||
pike_clean:
|
||||
rm -f *_wrap* *~ .~* mypike@EXEEXT@
|
||||
rm -f *_wrap* *~ .~* mypike@EXEEXT@
|
||||
rm -f core @EXTRA_CLEAN@
|
||||
rm -f *.@OBJEXT@ *@SO@
|
||||
|
||||
|
|
@ -862,7 +873,7 @@ CHICKEN_CFLAGS = @CHICKENOPTS@
|
|||
CHICKENOPTS = -quiet
|
||||
CHICKEN_MAIN =
|
||||
|
||||
# SWIG produces $(ISRCS) (the C wrapper file)
|
||||
# SWIG produces $(ISRCS) (the C wrapper file)
|
||||
# and $(CHICKEN_GENERATED_SCHEME) (the Scheme wrapper file):
|
||||
CHICKEN_GENERATED_SCHEME = $(INTERFACE:.i=.scm)
|
||||
CHICKEN_COMPILED_SCHEME = $(INTERFACE:.i=_chicken.c)
|
||||
|
|
@ -1054,12 +1065,12 @@ lua_clean:
|
|||
|
||||
allegrocl: $(SRCS)
|
||||
$(SWIG) -allegrocl -cwrap $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CC) -c $(CCSHARED) $(CFLAGS) $(ISRCS) $(INCLUDES) $(SRCS)
|
||||
$(CC) -c $(CCSHARED) $(CFLAGS) $(ISRCS) $(INCLUDES) $(SRCS)
|
||||
$(LDSHARED) $(CFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
|
||||
|
||||
allegrocl_cpp: $(SRCS)
|
||||
$(SWIG) -c++ -allegrocl $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CXX) -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES)
|
||||
$(CXX) -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES)
|
||||
$(CXXSHARED) $(CXXFLAGS) $(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
|
||||
|
||||
allegrocl_clean:
|
||||
|
|
@ -1088,12 +1099,12 @@ clisp_clean:
|
|||
|
||||
cffi: $(SRCS)
|
||||
$(SWIG) -cffi $(SWIGOPT) $(INTERFACEPATH)
|
||||
# $(CC) -c $(CCSHARED) $(CFLAGS) $(ISRCS) $(INCLUDES) $(SRCS)
|
||||
# $(CC) -c $(CCSHARED) $(CFLAGS) $(ISRCS) $(INCLUDES) $(SRCS)
|
||||
# $(LDSHARED) $(CFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
|
||||
|
||||
cffi_cpp: $(SRCS)
|
||||
$(SWIG) -c++ -cffi $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CXX) -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES)
|
||||
$(CXX) -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES)
|
||||
$(CXXSHARED) $(CXXFLAGS) $(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
|
||||
|
||||
cffi_clean:
|
||||
|
|
@ -1107,12 +1118,12 @@ cffi_clean:
|
|||
|
||||
uffi: $(SRCS)
|
||||
$(SWIG) -uffi $(SWIGOPT) $(INTERFACEPATH)
|
||||
# $(CC) -c $(CCSHARED) $(CFLAGS) $(ISRCS) $(INCLUDES) $(SRCS)
|
||||
# $(CC) -c $(CCSHARED) $(CFLAGS) $(ISRCS) $(INCLUDES) $(SRCS)
|
||||
# $(LDSHARED) $(CFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
|
||||
|
||||
uffi_cpp: $(SRCS)
|
||||
$(SWIG) -c++ -uffi $(SWIGOPT) $(INTERFACEPATH)
|
||||
# $(CXX) -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES)
|
||||
# $(CXX) -c $(CCSHARED) $(CXXFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES)
|
||||
# $(CXXSHARED) $(CXXFLAGS) $(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
|
||||
|
||||
uffi_clean:
|
||||
|
|
@ -1127,14 +1138,25 @@ uffi_clean:
|
|||
R = R
|
||||
RCXXSRCS = $(INTERFACE:.i=_wrap.cpp) #Need to use _wrap.cpp for R build system as it does not understand _wrap.cxx
|
||||
RRSRC = $(INTERFACE:.i=.R)
|
||||
R_CFLAGS=-fPIC
|
||||
|
||||
# need to compile .cxx files outside of R build system to make sure that
|
||||
# we get -fPIC
|
||||
# CMD SHLIB stdout is piped to /dev/null to prevent echo of compiler command
|
||||
|
||||
r: $(SRCS)
|
||||
$(SWIG) -r $(SWIGOPT) $(INTERFACEPATH)
|
||||
+( PKG_CPPFLAGS="$(INCLUDES)" $(COMPILETOOL) $(R) CMD SHLIB -o $(LIBPREFIX)$(TARGET)$(SO) $(ISRCS) $(SRCS) )
|
||||
ifneq ($(SRCS),)
|
||||
$(CC) -g -c $(CFLAGS) $(R_CFLAGS) $(SRCS) $(INCLUDES)
|
||||
endif
|
||||
+( PKG_CPPFLAGS="$(INCLUDES)" $(COMPILETOOL) $(R) CMD SHLIB -o $(LIBPREFIX)$(TARGET)$(SO) $(ISRCS) $(OBJS) > /dev/null )
|
||||
|
||||
r_cpp: $(CXXSRCS)
|
||||
$(SWIG) -c++ -r $(SWIGOPT) -o $(RCXXSRCS) $(INTERFACEPATH)
|
||||
+( PKG_CPPFLAGS="$(INCLUDES)" $(COMPILETOOL) $(R) CMD SHLIB -o $(LIBPREFIX)$(TARGET)$(SO) $(RCXXSRCS) $(SRCS) $(CXXSRCS))
|
||||
ifneq ($(CXXSRCS),)
|
||||
$(CXX) -g -c $(CFLAGS) $(R_CFLAGS) $(CXXSRCS) $(INCLUDES)
|
||||
endif
|
||||
+( PKG_CPPFLAGS="$(INCLUDES)" $(COMPILETOOL) $(R) CMD SHLIB -o $(LIBPREFIX)$(TARGET)$(SO) $(RCXXSRCS) $(OBJS) > /dev/null )
|
||||
|
||||
r_clean:
|
||||
rm -f *_wrap* *~ .~*
|
||||
|
|
@ -1148,19 +1170,23 @@ r_clean:
|
|||
|
||||
GO = @GO@
|
||||
GOGCC = @GOGCC@
|
||||
GO1 = @GO1@
|
||||
GOC = @GOC@
|
||||
GOOPT = @GOOPT@
|
||||
|
||||
GOSWIGARG = `if $(GOGCC) ; then echo -gccgo; fi`
|
||||
GOCOMPILEARG = `if $(GOGCC) ; then echo -c -g; fi`
|
||||
GOCOMPILEARG = `if $(GOGCC) ; then echo -c -g; elif $(GO1) ; then echo tool $(GOC:c=g) ; fi`
|
||||
|
||||
GOSRCS = $(INTERFACE:.i=.go)
|
||||
GOCSRCS = $(INTERFACE:.i=_gc.c)
|
||||
|
||||
GOC = $(GO:g=c)
|
||||
GOLD = $(GO:g=l)
|
||||
GOLD = $(GOC:c=l)
|
||||
GOTOOL = `if $(GO1) ; then echo go tool; fi`
|
||||
GOPACK = `if $(GO1) ; then echo go tool pack; else echo gopack; fi`
|
||||
|
||||
GOPACKAGE = $(INTERFACE:.i=.a)
|
||||
|
||||
GOOBJEXT = $(GO:g=)
|
||||
GOOBJEXT = $(GOC:c=)
|
||||
GOGCOBJS = $(GOSRCS:.go=.$(GOOBJEXT))
|
||||
GOGCCOBJS = $(GOSRCS:.go=.@OBJEXT@)
|
||||
|
||||
|
|
@ -1169,13 +1195,13 @@ GOGCCOBJS = $(GOSRCS:.go=.@OBJEXT@)
|
|||
# ----------------------------------------------------------------
|
||||
|
||||
go: $(SRCS)
|
||||
$(SWIG) -go $(GOSWIGARG) $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(SWIG) -go $(GOOPT) $(GOSWIGARG) $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CC) -g -c $(CCSHARED) $(CFLAGS) $(SRCS) $(ISRCS) $(INCLUDES)
|
||||
$(LDSHARED) $(CFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
|
||||
$(COMPILETOOL) $(GO) -I . $(GOCOMPILEARG) $(GOSRCS)
|
||||
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -I . $(GOSRCS)
|
||||
if ! $(GOGCC) ; then \
|
||||
$(COMPILETOOL) $(GOC) -I $${GOROOT}/pkg/$${GOOS}_$${GOARCH} $(GOCSRCS) && \
|
||||
$(COMPILETOOL) gopack grc $(GOPACKAGE) $(GOGCOBJS) $(GOCSRCS:.c=.$(GOOBJEXT)); \
|
||||
$(COMPILETOOL) $(GOTOOL) $(GOC) -I $${GOROOT}/pkg/$${GOOS}_$${GOARCH} $(GOCSRCS) && \
|
||||
$(COMPILETOOL) $(GOPACK) grc $(GOPACKAGE) $(GOGCOBJS) $(GOCSRCS:.c=.$(GOOBJEXT)); \
|
||||
fi
|
||||
|
||||
# ----------------------------------------------------------------
|
||||
|
|
@ -1183,13 +1209,13 @@ go: $(SRCS)
|
|||
# ----------------------------------------------------------------
|
||||
|
||||
go_cpp: $(SRCS)
|
||||
$(SWIG) -go -c++ $(GOSWIGARG) $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(SWIG) -go -c++ $(GOOPT) $(GOSWIGARG) $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CXX) -g -c $(CCSHARED) $(CXXFLAGS) $(SRCS) $(CXXSRCS) $(ICXXSRCS) $(INCLUDES)
|
||||
$(CXXSHARED) $(CXXFLAGS) $(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
|
||||
$(COMPILETOOL) $(GO) -I . $(GOCOMPILEARG) $(GOSRCS)
|
||||
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -I . $(GOSRCS)
|
||||
if ! $(GOGCC) ; then \
|
||||
$(COMPILETOOL) $(GOC) -I $${GOROOT}/pkg/$${GOOS}_$${GOARCH} $(GOCSRCS) && \
|
||||
$(COMPILETOOL) gopack grc $(GOPACKAGE) $(GOGCOBJS) $(GOCSRCS:.c=.$(GOOBJEXT)); \
|
||||
$(COMPILETOOL) $(GOTOOL) $(GOC) -I $${GOROOT}/pkg/$${GOOS}_$${GOARCH} $(GOCSRCS) && \
|
||||
$(COMPILETOOL) $(GOPACK) grc $(GOPACKAGE) $(GOGCOBJS) $(GOCSRCS:.c=.$(GOOBJEXT)); \
|
||||
fi
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
|
|
@ -1201,7 +1227,7 @@ go_run: runme.go
|
|||
if $(GOGCC) ; then \
|
||||
$(COMPILETOOL) $(GO) -o runme runme.@OBJEXT@ $(GOGCCOBJS) $(LIBPREFIX)$(TARGET)$(SO); \
|
||||
else \
|
||||
$(COMPILETOOL) $(GOLD) -r $${GOROOT}/pkg/$${GOOS}_$${GOARCH}:. -o runme runme.$(GOOBJEXT); \
|
||||
$(COMPILETOOL) $(GOTOOL) $(GOLD) -r $${GOROOT}/pkg/$${GOOS}_$${GOARCH}:. -o runme runme.$(GOOBJEXT); \
|
||||
fi
|
||||
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH $(RUNTOOL) ./runme
|
||||
|
||||
|
|
@ -1213,3 +1239,64 @@ go_clean:
|
|||
rm -f *_wrap* *_gc* .~* runme
|
||||
rm -f core @EXTRA_CLEAN@
|
||||
rm -f *.@OBJEXT@ *.[568] *.a *@SO@
|
||||
|
||||
##################################################################
|
||||
##### D ######
|
||||
##################################################################
|
||||
|
||||
DLIBPREFIX = @DLIBPREFIX@
|
||||
|
||||
ifeq (,$(D_VERSION))
|
||||
D_VERSION = @DDEFAULTVERSION@
|
||||
endif
|
||||
|
||||
ifeq (2,$(D_VERSION))
|
||||
SWIGD = $(SWIG) -d -d2
|
||||
DCOMPILER = @D2COMPILER@
|
||||
else
|
||||
SWIGD = $(SWIG) -d
|
||||
DCOMPILER = @D1COMPILER@
|
||||
endif
|
||||
|
||||
# ----------------------------------------------------------------
|
||||
# Build a dynamically loadable D wrapper for a C module
|
||||
# ----------------------------------------------------------------
|
||||
|
||||
d: $(SRCS)
|
||||
$(SWIGD) $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CC) -c $(CCSHARED) $(CFLAGS) $(DCFLAGS) $(EXTRA_CFLAGS) $(SRCS) $(ISRCS) $(INCLUDES)
|
||||
$(LDSHARED) $(CFLAGS) $(DCFLAGS) $(EXTRA_LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(DLIBPREFIX)$(TARGET)$(SO)
|
||||
|
||||
# ----------------------------------------------------------------
|
||||
# Build a dynamically loadable D wrapper for a C++ module
|
||||
# ----------------------------------------------------------------
|
||||
|
||||
d_cpp: $(SRCS)
|
||||
$(SWIGD) -c++ $(SWIGOPT) $(INTERFACEPATH)
|
||||
$(CXX) -c $(CCSHARED) $(CFLAGS) $(DCFLAGS) $(EXTRA_CFLAGS) $(SRCS) $(CXXSRCS) $(ICXXSRCS) $(INCLUDES)
|
||||
$(CXXSHARED) $(CFLAGS) $(DCFLAGS) $(EXTRA_LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) -o $(DLIBPREFIX)$(TARGET)$(SO)
|
||||
|
||||
# ----------------------------------------------------------------
|
||||
# Compile D files
|
||||
# ----------------------------------------------------------------
|
||||
|
||||
# Clear the DFLAGS environment variable for the compiler call itself
|
||||
# to work around a discrepancy in argument handling between DMD and LDC.
|
||||
d_compile: $(SRCS)
|
||||
DFLAGS="" $(COMPILETOOL) $(DCOMPILER) $(DFLAGS) $(DSRCS)
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Run D example
|
||||
# -----------------------------------------------------------------
|
||||
|
||||
d_run:
|
||||
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH $(RUNTOOL) ./runme
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Clean the D examples
|
||||
# -----------------------------------------------------------------
|
||||
|
||||
d_clean:
|
||||
rm -f *_wrap* *~ .~* runme runme.exe `find . -name \*.d | grep -v runme.d`
|
||||
rm -f core @EXTRA_CLEAN@
|
||||
rm -f *.@OBJEXT@ *@SO@
|
||||
|
|
|
|||
4
Examples/android/check.list
Normal file
4
Examples/android/check.list
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
# see top-level Makefile.in
|
||||
class
|
||||
extend
|
||||
simple
|
||||
15
Examples/android/class/AndroidManifest.xml
Normal file
15
Examples/android/class/AndroidManifest.xml
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
package="org.swig.classexample"
|
||||
android:versionCode="1"
|
||||
android:versionName="1.0">
|
||||
<application android:label="@string/app_name" >
|
||||
<activity android:name="SwigClass"
|
||||
android:label="@string/app_name">
|
||||
<intent-filter>
|
||||
<action android:name="android.intent.action.MAIN" />
|
||||
<category android:name="android.intent.category.LAUNCHER" />
|
||||
</intent-filter>
|
||||
</activity>
|
||||
</application>
|
||||
</manifest>
|
||||
30
Examples/android/class/Makefile
Normal file
30
Examples/android/class/Makefile
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
TOP = ../..
|
||||
SWIG = $(TOP)/../preinst-swig
|
||||
TARGET = example
|
||||
INTERFACE = example.i
|
||||
PACKAGEDIR = src/org/swig
|
||||
PACKAGENAME= org.swig.classexample
|
||||
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/classexample
|
||||
PROJECTNAME= SwigClass
|
||||
TARGETID = 1
|
||||
#INSTALLOPTIONS = -s # To install on SD Card
|
||||
|
||||
all:: android
|
||||
|
||||
android::
|
||||
android update project --target $(TARGETID) --name $(PROJECTNAME) --path .
|
||||
$(SWIG) -c++ -java $(SWIGOPT) -o jni/$(TARGET)_wrap.cpp jni/$(INTERFACE)
|
||||
ndk-build
|
||||
ant debug
|
||||
|
||||
install::
|
||||
-adb uninstall $(PACKAGENAME)
|
||||
adb install $(INSTALLOPTIONS) bin/$(PROJECTNAME)-debug.apk
|
||||
|
||||
clean::
|
||||
ant clean
|
||||
rm -f jni/$(TARGET)_wrap.cpp
|
||||
rm -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
|
||||
|
||||
|
||||
check: all
|
||||
17
Examples/android/class/ant.properties
Normal file
17
Examples/android/class/ant.properties
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# This file is used to override default values used by the Ant build system.
|
||||
#
|
||||
# This file must be checked in Version Control Systems, as it is
|
||||
# integral to the build system of your project.
|
||||
|
||||
# This file is only used by the Ant script.
|
||||
|
||||
# You can use this to override default values such as
|
||||
# 'source.dir' for the location of your java source folder and
|
||||
# 'out.dir' for the location of your output folder.
|
||||
|
||||
# You can also use it define how the release builds are signed by declaring
|
||||
# the following properties:
|
||||
# 'key.store' for the location of your keystore and
|
||||
# 'key.alias' for the name of the key to use.
|
||||
# The password will be asked during the build when you use the 'release' target.
|
||||
|
||||
85
Examples/android/class/build.xml
Normal file
85
Examples/android/class/build.xml
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project name="SwigClass" default="help">
|
||||
|
||||
<!-- The local.properties file is created and updated by the 'android' tool.
|
||||
It contains the path to the SDK. It should *NOT* be checked into
|
||||
Version Control Systems. -->
|
||||
<loadproperties srcFile="local.properties" />
|
||||
|
||||
<!-- The ant.properties file can be created by you. It is only edited by the
|
||||
'android' tool to add properties to it.
|
||||
This is the place to change some Ant specific build properties.
|
||||
Here are some properties you may want to change/update:
|
||||
|
||||
source.dir
|
||||
The name of the source directory. Default is 'src'.
|
||||
out.dir
|
||||
The name of the output directory. Default is 'bin'.
|
||||
|
||||
For other overridable properties, look at the beginning of the rules
|
||||
files in the SDK, at tools/ant/build.xml
|
||||
|
||||
Properties related to the SDK location or the project target should
|
||||
be updated using the 'android' tool with the 'update' action.
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems.
|
||||
|
||||
-->
|
||||
<property file="ant.properties" />
|
||||
|
||||
<!-- The project.properties file is created and updated by the 'android'
|
||||
tool, as well as ADT.
|
||||
|
||||
This contains project specific properties such as project target, and library
|
||||
dependencies. Lower level build properties are stored in ant.properties
|
||||
(or in .classpath for Eclipse projects).
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems. -->
|
||||
<loadproperties srcFile="project.properties" />
|
||||
|
||||
<!-- quick check on sdk.dir -->
|
||||
<fail
|
||||
message="sdk.dir is missing. Make sure to generate local.properties using 'android update project'"
|
||||
unless="sdk.dir"
|
||||
/>
|
||||
|
||||
|
||||
<!-- extension targets. Uncomment the ones where you want to do custom work
|
||||
in between standard targets -->
|
||||
<!--
|
||||
<target name="-pre-build">
|
||||
</target>
|
||||
<target name="-pre-compile">
|
||||
</target>
|
||||
|
||||
/* This is typically used for code obfuscation.
|
||||
Compiled code location: ${out.classes.absolute.dir}
|
||||
If this is not done in place, override ${out.dex.input.absolute.dir} */
|
||||
<target name="-post-compile">
|
||||
</target>
|
||||
-->
|
||||
|
||||
<!-- Import the actual build file.
|
||||
|
||||
To customize existing targets, there are two options:
|
||||
- Customize only one target:
|
||||
- copy/paste the target into this file, *before* the
|
||||
<import> task.
|
||||
- customize it to your needs.
|
||||
- Customize the whole content of build.xml
|
||||
- copy/paste the content of the rules files (minus the top node)
|
||||
into this file, replacing the <import> task.
|
||||
- customize to your needs.
|
||||
|
||||
***********************
|
||||
****** IMPORTANT ******
|
||||
***********************
|
||||
In all cases you must update the value of version-tag below to read 'custom' instead of an integer,
|
||||
in order to avoid having your file be overridden by tools such as "android update project"
|
||||
-->
|
||||
<!-- version-tag: 1 -->
|
||||
<import file="${sdk.dir}/tools/ant/build.xml" />
|
||||
|
||||
</project>
|
||||
10
Examples/android/class/jni/Android.mk
Normal file
10
Examples/android/class/jni/Android.mk
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.cpp example.cpp
|
||||
LOCAL_CFLAGS := -frtti
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
28
Examples/android/class/jni/example.cpp
Normal file
28
Examples/android/class/jni/example.cpp
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
/* File : example.cpp */
|
||||
|
||||
#include "example.h"
|
||||
#define M_PI 3.14159265358979323846
|
||||
|
||||
/* Move the shape to a new location */
|
||||
void Shape::move(double dx, double dy) {
|
||||
x += dx;
|
||||
y += dy;
|
||||
}
|
||||
|
||||
int Shape::nshapes = 0;
|
||||
|
||||
double Circle::area(void) {
|
||||
return M_PI*radius*radius;
|
||||
}
|
||||
|
||||
double Circle::perimeter(void) {
|
||||
return 2*M_PI*radius;
|
||||
}
|
||||
|
||||
double Square::area(void) {
|
||||
return width*width;
|
||||
}
|
||||
|
||||
double Square::perimeter(void) {
|
||||
return 4*width;
|
||||
}
|
||||
34
Examples/android/class/jni/example.h
Normal file
34
Examples/android/class/jni/example.h
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
/* File : example.h */
|
||||
|
||||
class Shape {
|
||||
public:
|
||||
Shape() {
|
||||
nshapes++;
|
||||
}
|
||||
virtual ~Shape() {
|
||||
nshapes--;
|
||||
};
|
||||
double x, y;
|
||||
void move(double dx, double dy);
|
||||
virtual double area(void) = 0;
|
||||
virtual double perimeter(void) = 0;
|
||||
static int nshapes;
|
||||
};
|
||||
|
||||
class Circle : public Shape {
|
||||
private:
|
||||
double radius;
|
||||
public:
|
||||
Circle(double r) : radius(r) { };
|
||||
virtual double area(void);
|
||||
virtual double perimeter(void);
|
||||
};
|
||||
|
||||
class Square : public Shape {
|
||||
private:
|
||||
double width;
|
||||
public:
|
||||
Square(double w) : width(w) { };
|
||||
virtual double area(void);
|
||||
virtual double perimeter(void);
|
||||
};
|
||||
9
Examples/android/class/jni/example.i
Normal file
9
Examples/android/class/jni/example.i
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
|
||||
/* Let's just grab the original header file here */
|
||||
%include "example.h"
|
||||
10
Examples/android/class/local.properties
Normal file
10
Examples/android/class/local.properties
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must *NOT* be checked in Version Control Systems,
|
||||
# as it contains information specific to your local configuration.
|
||||
|
||||
# location of the SDK. This is only used by Ant
|
||||
# For customization when using a Version Control System, please read the
|
||||
# header note.
|
||||
sdk.dir=/home/william/android/android-sdk-linux_x86
|
||||
40
Examples/android/class/proguard.cfg
Normal file
40
Examples/android/class/proguard.cfg
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
-optimizationpasses 5
|
||||
-dontusemixedcaseclassnames
|
||||
-dontskipnonpubliclibraryclasses
|
||||
-dontpreverify
|
||||
-verbose
|
||||
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*
|
||||
|
||||
-keep public class * extends android.app.Activity
|
||||
-keep public class * extends android.app.Application
|
||||
-keep public class * extends android.app.Service
|
||||
-keep public class * extends android.content.BroadcastReceiver
|
||||
-keep public class * extends android.content.ContentProvider
|
||||
-keep public class * extends android.app.backup.BackupAgentHelper
|
||||
-keep public class * extends android.preference.Preference
|
||||
-keep public class com.android.vending.licensing.ILicensingService
|
||||
|
||||
-keepclasseswithmembernames class * {
|
||||
native <methods>;
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet);
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet, int);
|
||||
}
|
||||
|
||||
-keepclassmembers class * extends android.app.Activity {
|
||||
public void *(android.view.View);
|
||||
}
|
||||
|
||||
-keepclassmembers enum * {
|
||||
public static **[] values();
|
||||
public static ** valueOf(java.lang.String);
|
||||
}
|
||||
|
||||
-keep class * implements android.os.Parcelable {
|
||||
public static final android.os.Parcelable$Creator *;
|
||||
}
|
||||
11
Examples/android/class/project.properties
Normal file
11
Examples/android/class/project.properties
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must be checked in Version Control Systems.
|
||||
#
|
||||
# To customize properties used by the Ant build system use,
|
||||
# "ant.properties", and override values to adapt the script to your
|
||||
# project structure.
|
||||
|
||||
# Project target.
|
||||
target=android-8
|
||||
25
Examples/android/class/res/layout/main.xml
Normal file
25
Examples/android/class/res/layout/main.xml
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
android:orientation="vertical"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<Button
|
||||
android:id="@+id/RunButton"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
android:text="Run..."
|
||||
android:onClick="onRunButtonClick"
|
||||
/>
|
||||
<ScrollView
|
||||
android:id="@+id/Scroller"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<TextView
|
||||
android:id="@+id/OutputText"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
/>
|
||||
</ScrollView>
|
||||
</LinearLayout>
|
||||
4
Examples/android/class/res/values/strings.xml
Normal file
4
Examples/android/class/res/values/strings.xml
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<resources>
|
||||
<string name="app_name">SwigClass</string>
|
||||
</resources>
|
||||
106
Examples/android/class/src/org/swig/classexample/SwigClass.java
Normal file
106
Examples/android/class/src/org/swig/classexample/SwigClass.java
Normal file
|
|
@ -0,0 +1,106 @@
|
|||
package org.swig.classexample;
|
||||
|
||||
import android.app.Activity;
|
||||
import android.os.Bundle;
|
||||
import android.view.View;
|
||||
import android.widget.Button;
|
||||
import android.widget.TextView;
|
||||
import android.widget.ScrollView;
|
||||
import android.text.method.ScrollingMovementMethod;
|
||||
|
||||
public class SwigClass extends Activity
|
||||
{
|
||||
TextView outputText = null;
|
||||
ScrollView scroller = null;
|
||||
|
||||
/** Called when the activity is first created. */
|
||||
@Override
|
||||
public void onCreate(Bundle savedInstanceState)
|
||||
{
|
||||
super.onCreate(savedInstanceState);
|
||||
setContentView(R.layout.main);
|
||||
|
||||
outputText = (TextView)findViewById(R.id.OutputText);
|
||||
outputText.setText("Press 'Run' to start...\n");
|
||||
outputText.setMovementMethod(new ScrollingMovementMethod());
|
||||
|
||||
scroller = (ScrollView)findViewById(R.id.Scroller);
|
||||
}
|
||||
|
||||
public void onRunButtonClick(View view)
|
||||
{
|
||||
outputText.append("Started...\n");
|
||||
nativeCall();
|
||||
outputText.append("Finished!\n");
|
||||
|
||||
// Ensure scroll to end of text
|
||||
scroller.post(new Runnable() {
|
||||
public void run() {
|
||||
scroller.fullScroll(ScrollView.FOCUS_DOWN);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// ----- Object creation -----
|
||||
|
||||
outputText.append( "Creating some objects:\n" );
|
||||
Circle c = new Circle(10);
|
||||
outputText.append( " Created circle " + c + "\n");
|
||||
Square s = new Square(10);
|
||||
outputText.append( " Created square " + s + "\n");
|
||||
|
||||
// ----- Access a static member -----
|
||||
|
||||
outputText.append( "\nA total of " + Shape.getNshapes() + " shapes were created\n" );
|
||||
|
||||
// ----- Member data access -----
|
||||
|
||||
// Notice how we can do this using functions specific to
|
||||
// the 'Circle' class.
|
||||
c.setX(20);
|
||||
c.setY(30);
|
||||
|
||||
// Now use the same functions in the base class
|
||||
Shape shape = s;
|
||||
shape.setX(-10);
|
||||
shape.setY(5);
|
||||
|
||||
outputText.append( "\nHere is their current position:\n" );
|
||||
outputText.append( " Circle = (" + c.getX() + " " + c.getY() + ")\n" );
|
||||
outputText.append( " Square = (" + s.getX() + " " + s.getY() + ")\n" );
|
||||
|
||||
// ----- Call some methods -----
|
||||
|
||||
outputText.append( "\nHere are some properties of the shapes:\n" );
|
||||
Shape[] shapes = {c,s};
|
||||
for (int i=0; i<shapes.length; i++)
|
||||
{
|
||||
outputText.append( " " + shapes[i].toString() + "\n" );
|
||||
outputText.append( " area = " + shapes[i].area() + "\n" );
|
||||
outputText.append( " perimeter = " + shapes[i].perimeter() + "\n" );
|
||||
}
|
||||
|
||||
// Notice how the area() and perimeter() functions really
|
||||
// invoke the appropriate virtual method on each object.
|
||||
|
||||
// ----- Delete everything -----
|
||||
|
||||
outputText.append( "\nGuess I'll clean up now\n" );
|
||||
|
||||
// Note: this invokes the virtual destructor
|
||||
// You could leave this to the garbage collector
|
||||
c.delete();
|
||||
s.delete();
|
||||
|
||||
outputText.append( Shape.getNshapes() + " shapes remain\n" );
|
||||
outputText.append( "Goodbye\n" );
|
||||
}
|
||||
|
||||
/** static constructor */
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
}
|
||||
15
Examples/android/extend/AndroidManifest.xml
Normal file
15
Examples/android/extend/AndroidManifest.xml
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
package="org.swig.extendexample"
|
||||
android:versionCode="1"
|
||||
android:versionName="1.0">
|
||||
<application android:label="@string/app_name" >
|
||||
<activity android:name="SwigExtend"
|
||||
android:label="@string/app_name">
|
||||
<intent-filter>
|
||||
<action android:name="android.intent.action.MAIN" />
|
||||
<category android:name="android.intent.category.LAUNCHER" />
|
||||
</intent-filter>
|
||||
</activity>
|
||||
</application>
|
||||
</manifest>
|
||||
30
Examples/android/extend/Makefile
Normal file
30
Examples/android/extend/Makefile
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
TOP = ../..
|
||||
SWIG = $(TOP)/../preinst-swig
|
||||
TARGET = example
|
||||
INTERFACE = example.i
|
||||
PACKAGEDIR = src/org/swig
|
||||
PACKAGENAME= org.swig.extendexample
|
||||
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/extendexample
|
||||
PROJECTNAME= SwigExtend
|
||||
TARGETID = 1
|
||||
#INSTALLOPTIONS = -s # To install on SD Card
|
||||
|
||||
all:: android
|
||||
|
||||
android::
|
||||
android update project --target $(TARGETID) --name $(PROJECTNAME) --path .
|
||||
$(SWIG) -c++ -java $(SWIGOPT) -o jni/$(TARGET)_wrap.cpp jni/$(INTERFACE)
|
||||
ndk-build
|
||||
ant debug
|
||||
|
||||
install::
|
||||
-adb uninstall $(PACKAGENAME)
|
||||
adb install $(INSTALLOPTIONS) bin/$(PROJECTNAME)-debug.apk
|
||||
|
||||
clean::
|
||||
ant clean
|
||||
rm -f jni/$(TARGET)_wrap.cpp
|
||||
rm -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
|
||||
|
||||
|
||||
check: all
|
||||
17
Examples/android/extend/ant.properties
Normal file
17
Examples/android/extend/ant.properties
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# This file is used to override default values used by the Ant build system.
|
||||
#
|
||||
# This file must be checked in Version Control Systems, as it is
|
||||
# integral to the build system of your project.
|
||||
|
||||
# This file is only used by the Ant script.
|
||||
|
||||
# You can use this to override default values such as
|
||||
# 'source.dir' for the location of your java source folder and
|
||||
# 'out.dir' for the location of your output folder.
|
||||
|
||||
# You can also use it define how the release builds are signed by declaring
|
||||
# the following properties:
|
||||
# 'key.store' for the location of your keystore and
|
||||
# 'key.alias' for the name of the key to use.
|
||||
# The password will be asked during the build when you use the 'release' target.
|
||||
|
||||
85
Examples/android/extend/build.xml
Normal file
85
Examples/android/extend/build.xml
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project name="SwigExtend" default="help">
|
||||
|
||||
<!-- The local.properties file is created and updated by the 'android' tool.
|
||||
It contains the path to the SDK. It should *NOT* be checked into
|
||||
Version Control Systems. -->
|
||||
<loadproperties srcFile="local.properties" />
|
||||
|
||||
<!-- The ant.properties file can be created by you. It is only edited by the
|
||||
'android' tool to add properties to it.
|
||||
This is the place to change some Ant specific build properties.
|
||||
Here are some properties you may want to change/update:
|
||||
|
||||
source.dir
|
||||
The name of the source directory. Default is 'src'.
|
||||
out.dir
|
||||
The name of the output directory. Default is 'bin'.
|
||||
|
||||
For other overridable properties, look at the beginning of the rules
|
||||
files in the SDK, at tools/ant/build.xml
|
||||
|
||||
Properties related to the SDK location or the project target should
|
||||
be updated using the 'android' tool with the 'update' action.
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems.
|
||||
|
||||
-->
|
||||
<property file="ant.properties" />
|
||||
|
||||
<!-- The project.properties file is created and updated by the 'android'
|
||||
tool, as well as ADT.
|
||||
|
||||
This contains project specific properties such as project target, and library
|
||||
dependencies. Lower level build properties are stored in ant.properties
|
||||
(or in .classpath for Eclipse projects).
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems. -->
|
||||
<loadproperties srcFile="project.properties" />
|
||||
|
||||
<!-- quick check on sdk.dir -->
|
||||
<fail
|
||||
message="sdk.dir is missing. Make sure to generate local.properties using 'android update project'"
|
||||
unless="sdk.dir"
|
||||
/>
|
||||
|
||||
|
||||
<!-- extension targets. Uncomment the ones where you want to do custom work
|
||||
in between standard targets -->
|
||||
<!--
|
||||
<target name="-pre-build">
|
||||
</target>
|
||||
<target name="-pre-compile">
|
||||
</target>
|
||||
|
||||
/* This is typically used for code obfuscation.
|
||||
Compiled code location: ${out.classes.absolute.dir}
|
||||
If this is not done in place, override ${out.dex.input.absolute.dir} */
|
||||
<target name="-post-compile">
|
||||
</target>
|
||||
-->
|
||||
|
||||
<!-- Import the actual build file.
|
||||
|
||||
To customize existing targets, there are two options:
|
||||
- Customize only one target:
|
||||
- copy/paste the target into this file, *before* the
|
||||
<import> task.
|
||||
- customize it to your needs.
|
||||
- Customize the whole content of build.xml
|
||||
- copy/paste the content of the rules files (minus the top node)
|
||||
into this file, replacing the <import> task.
|
||||
- customize to your needs.
|
||||
|
||||
***********************
|
||||
****** IMPORTANT ******
|
||||
***********************
|
||||
In all cases you must update the value of version-tag below to read 'custom' instead of an integer,
|
||||
in order to avoid having your file be overridden by tools such as "android update project"
|
||||
-->
|
||||
<!-- version-tag: 1 -->
|
||||
<import file="${sdk.dir}/tools/ant/build.xml" />
|
||||
|
||||
</project>
|
||||
10
Examples/android/extend/jni/Android.mk
Normal file
10
Examples/android/extend/jni/Android.mk
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.cpp example.cpp
|
||||
LOCAL_CFLAGS := -frtti
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
2
Examples/android/extend/jni/Application.mk
Normal file
2
Examples/android/extend/jni/Application.mk
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
# File: Application.mk
|
||||
APP_STL := gnustl_static
|
||||
14
Examples/android/extend/jni/example.cpp
Normal file
14
Examples/android/extend/jni/example.cpp
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
/* File : example.cxx */
|
||||
|
||||
#include "example.h"
|
||||
|
||||
static Streamer * streamerInstance = 0;
|
||||
|
||||
void setStreamer(Streamer* streamer) {
|
||||
streamerInstance = streamer;
|
||||
}
|
||||
|
||||
Streamer& getStreamer() {
|
||||
return *streamerInstance;
|
||||
}
|
||||
|
||||
71
Examples/android/extend/jni/example.h
Normal file
71
Examples/android/extend/jni/example.h
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
/* File : example.h */
|
||||
|
||||
#include <cstdio>
|
||||
#include <iostream>
|
||||
#include <vector>
|
||||
#include <string>
|
||||
#include <cmath>
|
||||
#include <sstream>
|
||||
|
||||
struct Streamer {
|
||||
virtual void display(std::string text) const = 0;
|
||||
virtual ~Streamer() {}
|
||||
};
|
||||
void setStreamer(Streamer* streamer);
|
||||
Streamer& getStreamer();
|
||||
|
||||
template<typename T> Streamer& operator<<(Streamer& stream, T const& val) {
|
||||
std::ostringstream s;
|
||||
s << val;
|
||||
stream.display(s.str());
|
||||
return stream;
|
||||
}
|
||||
|
||||
class Employee {
|
||||
private:
|
||||
std::string name;
|
||||
public:
|
||||
Employee(const char* n): name(n) {}
|
||||
virtual std::string getTitle() { return getPosition() + " " + getName(); }
|
||||
virtual std::string getName() { return name; }
|
||||
virtual std::string getPosition() const { return "Employee"; }
|
||||
virtual ~Employee() { getStreamer() << "~Employee() @ " << this << "\n"; }
|
||||
};
|
||||
|
||||
|
||||
class Manager: public Employee {
|
||||
public:
|
||||
Manager(const char* n): Employee(n) {}
|
||||
virtual std::string getPosition() const { return "Manager"; }
|
||||
};
|
||||
|
||||
|
||||
class EmployeeList {
|
||||
std::vector<Employee*> list;
|
||||
public:
|
||||
EmployeeList() {
|
||||
list.push_back(new Employee("Bob"));
|
||||
list.push_back(new Employee("Jane"));
|
||||
list.push_back(new Manager("Ted"));
|
||||
}
|
||||
void addEmployee(Employee *p) {
|
||||
list.push_back(p);
|
||||
getStreamer() << "New employee added. Current employees are:" << "\n";
|
||||
std::vector<Employee*>::iterator i;
|
||||
for (i=list.begin(); i!=list.end(); i++) {
|
||||
getStreamer() << " " << (*i)->getTitle() << "\n";
|
||||
}
|
||||
}
|
||||
const Employee *get_item(int i) {
|
||||
return list[i];
|
||||
}
|
||||
~EmployeeList() {
|
||||
std::vector<Employee*>::iterator i;
|
||||
getStreamer() << "~EmployeeList, deleting " << list.size() << " employees." << "\n";
|
||||
for (i=list.begin(); i!=list.end(); i++) {
|
||||
delete *i;
|
||||
}
|
||||
getStreamer() << "~EmployeeList empty." << "\n";
|
||||
}
|
||||
};
|
||||
|
||||
18
Examples/android/extend/jni/example.i
Normal file
18
Examples/android/extend/jni/example.i
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
/* File : example.i */
|
||||
%module(directors="1") example
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
|
||||
%include "std_vector.i"
|
||||
%include "std_string.i"
|
||||
|
||||
/* turn on director wrapping for Manager */
|
||||
%feature("director") Employee;
|
||||
%feature("director") Manager;
|
||||
|
||||
/* A base class for callbacks from C++ to output text on the Java side */
|
||||
%feature("director") Streamer;
|
||||
|
||||
%include "example.h"
|
||||
|
||||
10
Examples/android/extend/local.properties
Normal file
10
Examples/android/extend/local.properties
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must *NOT* be checked in Version Control Systems,
|
||||
# as it contains information specific to your local configuration.
|
||||
|
||||
# location of the SDK. This is only used by Ant
|
||||
# For customization when using a Version Control System, please read the
|
||||
# header note.
|
||||
sdk.dir=/home/william/android/android-sdk-linux_x86
|
||||
40
Examples/android/extend/proguard.cfg
Normal file
40
Examples/android/extend/proguard.cfg
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
-optimizationpasses 5
|
||||
-dontusemixedcaseclassnames
|
||||
-dontskipnonpubliclibraryclasses
|
||||
-dontpreverify
|
||||
-verbose
|
||||
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*
|
||||
|
||||
-keep public class * extends android.app.Activity
|
||||
-keep public class * extends android.app.Application
|
||||
-keep public class * extends android.app.Service
|
||||
-keep public class * extends android.content.BroadcastReceiver
|
||||
-keep public class * extends android.content.ContentProvider
|
||||
-keep public class * extends android.app.backup.BackupAgentHelper
|
||||
-keep public class * extends android.preference.Preference
|
||||
-keep public class com.android.vending.licensing.ILicensingService
|
||||
|
||||
-keepclasseswithmembernames class * {
|
||||
native <methods>;
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet);
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet, int);
|
||||
}
|
||||
|
||||
-keepclassmembers class * extends android.app.Activity {
|
||||
public void *(android.view.View);
|
||||
}
|
||||
|
||||
-keepclassmembers enum * {
|
||||
public static **[] values();
|
||||
public static ** valueOf(java.lang.String);
|
||||
}
|
||||
|
||||
-keep class * implements android.os.Parcelable {
|
||||
public static final android.os.Parcelable$Creator *;
|
||||
}
|
||||
11
Examples/android/extend/project.properties
Normal file
11
Examples/android/extend/project.properties
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must be checked in Version Control Systems.
|
||||
#
|
||||
# To customize properties used by the Ant build system use,
|
||||
# "ant.properties", and override values to adapt the script to your
|
||||
# project structure.
|
||||
|
||||
# Project target.
|
||||
target=android-8
|
||||
25
Examples/android/extend/res/layout/main.xml
Normal file
25
Examples/android/extend/res/layout/main.xml
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
android:orientation="vertical"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<Button
|
||||
android:id="@+id/RunButton"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
android:text="Run..."
|
||||
android:onClick="onRunButtonClick"
|
||||
/>
|
||||
<ScrollView
|
||||
android:id="@+id/Scroller"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<TextView
|
||||
android:id="@+id/OutputText"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
/>
|
||||
</ScrollView>
|
||||
</LinearLayout>
|
||||
4
Examples/android/extend/res/values/strings.xml
Normal file
4
Examples/android/extend/res/values/strings.xml
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<resources>
|
||||
<string name="app_name">SwigExtend</string>
|
||||
</resources>
|
||||
|
|
@ -0,0 +1,129 @@
|
|||
package org.swig.extendexample;
|
||||
|
||||
import android.app.Activity;
|
||||
import android.os.Bundle;
|
||||
import android.view.View;
|
||||
import android.widget.Button;
|
||||
import android.widget.TextView;
|
||||
import android.widget.ScrollView;
|
||||
import android.text.method.ScrollingMovementMethod;
|
||||
|
||||
// CEO class, which overrides Employee::getPosition().
|
||||
class CEO extends Manager {
|
||||
public CEO(String name) {
|
||||
super(name);
|
||||
}
|
||||
public String getPosition() {
|
||||
return "CEO";
|
||||
}
|
||||
// Public method to stop the SWIG proxy base class from thinking it owns the underlying C++ memory.
|
||||
public void disownMemory() {
|
||||
swigCMemOwn = false;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
public class SwigExtend extends Activity
|
||||
{
|
||||
TextView outputText = null;
|
||||
ScrollView scroller = null;
|
||||
|
||||
/** Handles upcalls from C++ so that C++ code can display text on the TextView */
|
||||
class TextViewStreamer extends Streamer {
|
||||
public void display(String text) {
|
||||
outputText.append(text);
|
||||
}
|
||||
}
|
||||
|
||||
TextViewStreamer textViewStreamer = new TextViewStreamer();
|
||||
|
||||
/** Called when the activity is first created. */
|
||||
@Override
|
||||
public void onCreate(Bundle savedInstanceState)
|
||||
{
|
||||
super.onCreate(savedInstanceState);
|
||||
setContentView(R.layout.main);
|
||||
|
||||
outputText = (TextView)findViewById(R.id.OutputText);
|
||||
outputText.setText("Press 'Run' to start...\n");
|
||||
outputText.setMovementMethod(new ScrollingMovementMethod());
|
||||
|
||||
scroller = (ScrollView)findViewById(R.id.Scroller);
|
||||
|
||||
example.setStreamer(textViewStreamer);
|
||||
}
|
||||
|
||||
public void onRunButtonClick(View view)
|
||||
{
|
||||
outputText.append("Started...\n");
|
||||
nativeCall();
|
||||
outputText.append("Finished!\n");
|
||||
|
||||
// Ensure scroll to end of text
|
||||
scroller.post(new Runnable() {
|
||||
public void run() {
|
||||
scroller.fullScroll(ScrollView.FOCUS_DOWN);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
|
||||
// Create an instance of CEO, a class derived from the Java proxy of the
|
||||
// underlying C++ class. The calls to getName() and getPosition() are standard,
|
||||
// the call to getTitle() uses the director wrappers to call CEO.getPosition().
|
||||
|
||||
CEO e = new CEO("Alice");
|
||||
outputText.append( e.getName() + " is a " + e.getPosition() + "\n");
|
||||
outputText.append( "Just call her \"" + e.getTitle() + "\"\n" );
|
||||
outputText.append( "----------------------\n" );
|
||||
|
||||
|
||||
// Create a new EmployeeList instance. This class does not have a C++
|
||||
// director wrapper, but can be used freely with other classes that do.
|
||||
|
||||
EmployeeList list = new EmployeeList();
|
||||
|
||||
// EmployeeList owns its items, so we must surrender ownership of objects we add.
|
||||
e.disownMemory();
|
||||
list.addEmployee(e);
|
||||
outputText.append( "----------------------\n" );
|
||||
|
||||
// Now we access the first four items in list (three are C++ objects that
|
||||
// EmployeeList's constructor adds, the last is our CEO). The virtual
|
||||
// methods of all these instances are treated the same. For items 0, 1, and
|
||||
// 2, all methods resolve in C++. For item 3, our CEO, getTitle calls
|
||||
// getPosition which resolves in Java. The call to getPosition is
|
||||
// slightly different, however, because of the overidden getPosition() call, since
|
||||
// now the object reference has been "laundered" by passing through
|
||||
// EmployeeList as an Employee*. Previously, Java resolved the call
|
||||
// immediately in CEO, but now Java thinks the object is an instance of
|
||||
// class Employee. So the call passes through the
|
||||
// Employee proxy class and on to the C wrappers and C++ director,
|
||||
// eventually ending up back at the Java CEO implementation of getPosition().
|
||||
// The call to getTitle() for item 3 runs the C++ Employee::getTitle()
|
||||
// method, which in turn calls getPosition(). This virtual method call
|
||||
// passes down through the C++ director class to the Java implementation
|
||||
// in CEO. All this routing takes place transparently.
|
||||
|
||||
outputText.append( "(position, title) for items 0-3:\n" );
|
||||
|
||||
outputText.append( " " + list.get_item(0).getPosition() + ", \"" + list.get_item(0).getTitle() + "\"\n" );
|
||||
outputText.append( " " + list.get_item(1).getPosition() + ", \"" + list.get_item(1).getTitle() + "\"\n" );
|
||||
outputText.append( " " + list.get_item(2).getPosition() + ", \"" + list.get_item(2).getTitle() + "\"\n" );
|
||||
outputText.append( " " + list.get_item(3).getPosition() + ", \"" + list.get_item(3).getTitle() + "\"\n" );
|
||||
outputText.append( "----------------------\n" );
|
||||
|
||||
// Time to delete the EmployeeList, which will delete all the Employee*
|
||||
// items it contains. The last item is our CEO, which gets destroyed as well.
|
||||
list.delete();
|
||||
outputText.append( "----------------------\n" );
|
||||
}
|
||||
|
||||
/** static constructor */
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
}
|
||||
15
Examples/android/simple/AndroidManifest.xml
Normal file
15
Examples/android/simple/AndroidManifest.xml
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
package="org.swig.simple"
|
||||
android:versionCode="1"
|
||||
android:versionName="1.0">
|
||||
<application android:label="@string/app_name" >
|
||||
<activity android:name="SwigSimple"
|
||||
android:label="@string/app_name">
|
||||
<intent-filter>
|
||||
<action android:name="android.intent.action.MAIN" />
|
||||
<category android:name="android.intent.category.LAUNCHER" />
|
||||
</intent-filter>
|
||||
</activity>
|
||||
</application>
|
||||
</manifest>
|
||||
30
Examples/android/simple/Makefile
Normal file
30
Examples/android/simple/Makefile
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
TOP = ../..
|
||||
SWIG = $(TOP)/../preinst-swig
|
||||
TARGET = example
|
||||
INTERFACE = example.i
|
||||
PACKAGEDIR = src/org/swig
|
||||
PACKAGENAME= org.swig.simple
|
||||
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/simple
|
||||
PROJECTNAME= SwigSimple
|
||||
TARGETID = 1
|
||||
#INSTALLOPTIONS = -s # To install on SD Card
|
||||
|
||||
all:: android
|
||||
|
||||
android::
|
||||
android update project --target $(TARGETID) --name $(PROJECTNAME) --path .
|
||||
$(SWIG) -java $(SWIGOPT) -o jni/$(TARGET)_wrap.c jni/$(INTERFACE)
|
||||
ndk-build
|
||||
ant debug
|
||||
|
||||
install::
|
||||
-adb uninstall $(PACKAGENAME)
|
||||
adb install $(INSTALLOPTIONS) bin/$(PROJECTNAME)-debug.apk
|
||||
|
||||
clean::
|
||||
ant clean
|
||||
rm -f jni/$(TARGET)_wrap.c
|
||||
rm -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
|
||||
|
||||
|
||||
check: all
|
||||
17
Examples/android/simple/ant.properties
Normal file
17
Examples/android/simple/ant.properties
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# This file is used to override default values used by the Ant build system.
|
||||
#
|
||||
# This file must be checked in Version Control Systems, as it is
|
||||
# integral to the build system of your project.
|
||||
|
||||
# This file is only used by the Ant script.
|
||||
|
||||
# You can use this to override default values such as
|
||||
# 'source.dir' for the location of your java source folder and
|
||||
# 'out.dir' for the location of your output folder.
|
||||
|
||||
# You can also use it define how the release builds are signed by declaring
|
||||
# the following properties:
|
||||
# 'key.store' for the location of your keystore and
|
||||
# 'key.alias' for the name of the key to use.
|
||||
# The password will be asked during the build when you use the 'release' target.
|
||||
|
||||
85
Examples/android/simple/build.xml
Normal file
85
Examples/android/simple/build.xml
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project name="SwigSimple" default="help">
|
||||
|
||||
<!-- The local.properties file is created and updated by the 'android' tool.
|
||||
It contains the path to the SDK. It should *NOT* be checked into
|
||||
Version Control Systems. -->
|
||||
<loadproperties srcFile="local.properties" />
|
||||
|
||||
<!-- The ant.properties file can be created by you. It is only edited by the
|
||||
'android' tool to add properties to it.
|
||||
This is the place to change some Ant specific build properties.
|
||||
Here are some properties you may want to change/update:
|
||||
|
||||
source.dir
|
||||
The name of the source directory. Default is 'src'.
|
||||
out.dir
|
||||
The name of the output directory. Default is 'bin'.
|
||||
|
||||
For other overridable properties, look at the beginning of the rules
|
||||
files in the SDK, at tools/ant/build.xml
|
||||
|
||||
Properties related to the SDK location or the project target should
|
||||
be updated using the 'android' tool with the 'update' action.
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems.
|
||||
|
||||
-->
|
||||
<property file="ant.properties" />
|
||||
|
||||
<!-- The project.properties file is created and updated by the 'android'
|
||||
tool, as well as ADT.
|
||||
|
||||
This contains project specific properties such as project target, and library
|
||||
dependencies. Lower level build properties are stored in ant.properties
|
||||
(or in .classpath for Eclipse projects).
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems. -->
|
||||
<loadproperties srcFile="project.properties" />
|
||||
|
||||
<!-- quick check on sdk.dir -->
|
||||
<fail
|
||||
message="sdk.dir is missing. Make sure to generate local.properties using 'android update project'"
|
||||
unless="sdk.dir"
|
||||
/>
|
||||
|
||||
|
||||
<!-- extension targets. Uncomment the ones where you want to do custom work
|
||||
in between standard targets -->
|
||||
<!--
|
||||
<target name="-pre-build">
|
||||
</target>
|
||||
<target name="-pre-compile">
|
||||
</target>
|
||||
|
||||
/* This is typically used for code obfuscation.
|
||||
Compiled code location: ${out.classes.absolute.dir}
|
||||
If this is not done in place, override ${out.dex.input.absolute.dir} */
|
||||
<target name="-post-compile">
|
||||
</target>
|
||||
-->
|
||||
|
||||
<!-- Import the actual build file.
|
||||
|
||||
To customize existing targets, there are two options:
|
||||
- Customize only one target:
|
||||
- copy/paste the target into this file, *before* the
|
||||
<import> task.
|
||||
- customize it to your needs.
|
||||
- Customize the whole content of build.xml
|
||||
- copy/paste the content of the rules files (minus the top node)
|
||||
into this file, replacing the <import> task.
|
||||
- customize to your needs.
|
||||
|
||||
***********************
|
||||
****** IMPORTANT ******
|
||||
***********************
|
||||
In all cases you must update the value of version-tag below to read 'custom' instead of an integer,
|
||||
in order to avoid having your file be overridden by tools such as "android update project"
|
||||
-->
|
||||
<!-- version-tag: 1 -->
|
||||
<import file="${sdk.dir}/tools/ant/build.xml" />
|
||||
|
||||
</project>
|
||||
9
Examples/android/simple/jni/Android.mk
Normal file
9
Examples/android/simple/jni/Android.mk
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.c example.c
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
17
Examples/android/simple/jni/example.c
Normal file
17
Examples/android/simple/jni/example.c
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
/* File : example.c */
|
||||
|
||||
/* A global variable */
|
||||
double Foo = 3.0;
|
||||
|
||||
/* Compute the greatest common divisor of positive integers */
|
||||
int gcd(int x, int y) {
|
||||
int g;
|
||||
g = y;
|
||||
while (x > 0) {
|
||||
g = x;
|
||||
x = y % x;
|
||||
y = g;
|
||||
}
|
||||
return g;
|
||||
}
|
||||
|
||||
7
Examples/android/simple/jni/example.i
Normal file
7
Examples/android/simple/jni/example.i
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%inline %{
|
||||
extern int gcd(int x, int y);
|
||||
extern double Foo;
|
||||
%}
|
||||
10
Examples/android/simple/local.properties
Normal file
10
Examples/android/simple/local.properties
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must *NOT* be checked in Version Control Systems,
|
||||
# as it contains information specific to your local configuration.
|
||||
|
||||
# location of the SDK. This is only used by Ant
|
||||
# For customization when using a Version Control System, please read the
|
||||
# header note.
|
||||
sdk.dir=/home/william/android/android-sdk-linux_x86
|
||||
40
Examples/android/simple/proguard.cfg
Normal file
40
Examples/android/simple/proguard.cfg
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
-optimizationpasses 5
|
||||
-dontusemixedcaseclassnames
|
||||
-dontskipnonpubliclibraryclasses
|
||||
-dontpreverify
|
||||
-verbose
|
||||
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*
|
||||
|
||||
-keep public class * extends android.app.Activity
|
||||
-keep public class * extends android.app.Application
|
||||
-keep public class * extends android.app.Service
|
||||
-keep public class * extends android.content.BroadcastReceiver
|
||||
-keep public class * extends android.content.ContentProvider
|
||||
-keep public class * extends android.app.backup.BackupAgentHelper
|
||||
-keep public class * extends android.preference.Preference
|
||||
-keep public class com.android.vending.licensing.ILicensingService
|
||||
|
||||
-keepclasseswithmembernames class * {
|
||||
native <methods>;
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet);
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet, int);
|
||||
}
|
||||
|
||||
-keepclassmembers class * extends android.app.Activity {
|
||||
public void *(android.view.View);
|
||||
}
|
||||
|
||||
-keepclassmembers enum * {
|
||||
public static **[] values();
|
||||
public static ** valueOf(java.lang.String);
|
||||
}
|
||||
|
||||
-keep class * implements android.os.Parcelable {
|
||||
public static final android.os.Parcelable$Creator *;
|
||||
}
|
||||
11
Examples/android/simple/project.properties
Normal file
11
Examples/android/simple/project.properties
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must be checked in Version Control Systems.
|
||||
#
|
||||
# To customize properties used by the Ant build system use,
|
||||
# "ant.properties", and override values to adapt the script to your
|
||||
# project structure.
|
||||
|
||||
# Project target.
|
||||
target=android-8
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue