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

Merge branch 'master' into gsoc2012-scilab

Browse source 
Conflicts:
	.gitignore
	.travis.yml
	COPYRIGHT
	Examples/Makefile.in
	Examples/test-suite/constructor_copy.i
	Makefile.in
	configure.ac
This commit is contained in:
Simon Marchetto 2014-06-06 16:33:16 +02:00
commit 07b06a4089
1502 changed files with 46955 additions and 11374 deletions
Download patch file Download diff file Expand all files Collapse all files

34
.gitignore vendored
View file

@ -3,8 +3,10 @@
*.class
# Editor files and various other junk
*.sw?
.*.sw?
*.bak
*.log
.DS_Store
# Local PCRE
pcre
@ -23,6 +25,7 @@ pcre
*.so
*.so.*
*.dylib
*.bundle
# C/C++ static libraries, based on:
# https://github.com/github/gitignore/blob/master/C.gitignore
@ -67,11 +70,11 @@ 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
Tools/javascript/Makefile
.deps
config.log
config.status
@ -82,10 +85,14 @@ swig.spec
.dirstamp
CCache/ccache-swig
CCache/ccache-swig.1
CCache/web/ccache-man.html
Lib/swigwarn.swg
Source/CParse/parser.c
Source/CParse/parser.h
Source/eswig
Source/TAGS
swig
Tools/javascript/javascript
# Generated documentation
Doc/Manual/CCache.html
@ -103,6 +110,7 @@ Examples/test-suite/d/*/
Examples/test-suite/go/*/
Examples/test-suite/guile/*/
Examples/test-suite/java/*/
Examples/test-suite/javascript/*/
Examples/test-suite/lua/*/
Examples/test-suite/mzscheme/*/
Examples/test-suite/ocaml/*/
@ -115,11 +123,19 @@ Examples/test-suite/r/*/
Examples/test-suite/ruby/*/
Examples/test-suite/tcl/*/
Examples/test-suite/uffi/*/
*_wrap.c
*_wrap.cxx
*-gypcopy.cxx
# SWIG generated files in examples
Examples/**/*_wrap.c
Examples/**/*_wrap.cxx
Examples/**/*_wrap.cpp
# C# generated files
*_runme.exe.mdb
*_runme.exe
# Javascript generated files
*.gyp
# Octave generated files
swigexample*.oct
# Python generated files, based on:
# https://github.com/github/gitignore/blob/master/Python.gitignore
@ -127,10 +143,6 @@ Examples/**/*_wrap.cpp
*/__pycache__/
/__pycache__/
# C# generated files
*_runme.exe.mdb
*_runme.exe
# Scilab generated files
builder.sce
loader.sce
@ -143,3 +155,5 @@ lib*.hxx
# Scratch directories
Examples/scratch
# Out of source tree build directories
*build*/

100
.travis.yml
View file

@ -7,33 +7,117 @@ env:
matrix:
include:
- compiler: gcc
env: SWIGLANG=python
env: SWIGLANG=csharp
- compiler: gcc
env: SWIGLANG=go
- compiler: gcc
env: SWIGLANG=guile
- compiler: gcc
env: SWIGLANG=java
- compiler: gcc
env: SWIGLANG=javascript ENGINE=node
- compiler: gcc
env: SWIGLANG=javascript ENGINE=jsc
- compiler: gcc
env: SWIGLANG=javascript ENGINE=v8
- compiler: gcc
env: SWIGLANG=lua
- compiler: gcc
env: SWIGLANG=octave SWIGJOBS=-j4
- compiler: gcc
env: SWIGLANG=perl5
- compiler: gcc
env: SWIGLANG=php
- compiler: gcc
env: SWIGLANG=python VER=2.4
- compiler: gcc
env: SWIGLANG=python VER=2.5
- compiler: gcc
env: SWIGLANG=python VER=2.6
- compiler: gcc
env: SWIGLANG=python # 2.7
- compiler: gcc
env: SWIGLANG=python PY3=3 # 3.2
- compiler: gcc
env: SWIGLANG=python PY3=3 VER=3.3
- compiler: gcc
env: SWIGLANG=python PY3=3 VER=3.4
- compiler: gcc
env: SWIGLANG=ruby
- compiler: gcc
env: SWIGLANG=tcl
- compiler: gcc
env: SWIGLANG=scilab SWIGJOBS=-j4
allow_failures:
# None
# None
before_install:
- lsb_release -a
- date -u
- uname -a
- lsb_release -a
- sudo apt-get -qq update
- time sudo apt-get -qq install libboost-dev
- if test -z "$SWIGLANG"; then sudo apt-get -qq install yodl; fi
- if test "$SWIGLANG" = "csharp"; then sudo apt-get -qq install mono-devel; fi
- if test "$SWIGLANG" = "go"; then go env | sed -e 's/^/export /' > goenvsetup && source goenvsetup && rm -f goenvsetup; fi # Until configure.ac is fixed
- if test "$SWIGLANG" = "javascript" -a "$ENGINE" = "node"; then sudo apt-get install -qq rlwrap python-software-properties && echo 'yes' | sudo add-apt-repository ppa:chris-lea/node.js && sudo apt-get -qq update && sudo apt-get install -qq nodejs && sudo npm install -g node-gyp; fi
- if test "$SWIGLANG" = "javascript" -a "$ENGINE" = "jsc"; then sudo apt-get install -qq libwebkitgtk-dev; fi
- if test "$SWIGLANG" = "javascript" -a "$ENGINE" = "v8"; then sudo apt-get install -qq libv8-dev; fi
- if test "$SWIGLANG" = "guile"; then sudo apt-get -qq install guile-2.0-dev; fi
- if test "$SWIGLANG" = "lua"; then sudo apt-get -qq install lua5.1 liblua5.1-dev; fi
- if test "$SWIGLANG" = "octave"; then sudo apt-get -qq install octave3.2 octave3.2-headers; fi
- if test "$SWIGLANG" = "scilab"; then sudo apt-get -qq install scilab; fi
- if test "$SWIGLANG" = "php"; then sudo apt-get install php5-cli php5-dev; fi
- if test "$SWIGLANG" = "python" -a "$PY3"; then sudo apt-get install python3-dev; fi
- if test "$SWIGLANG" = "python" -a "$PY3" -a -z "$VER"; then sudo apt-get install -qq python3-dev; fi
- if test "$SWIGLANG" = "python" -a "$VER"; then sudo add-apt-repository -y ppa:fkrull/deadsnakes && sudo apt-get -qq update && sudo apt-get -qq install python${VER}-dev && export CONFIGOPTS="--with-python${PY3}=python${VER}"; fi
- if test "$SWIGLANG" = "tcl"; then sudo apt-get -qq install tcl8.4-dev; fi
# Stricter compile flags for examples. Various headers and SWIG generated code prevents full use of -pedantic.
- declare -A CFLAGS_EXAMPLES && CFLAGS_EXAMPLES=(
["csharp"]="-Werror -std=gnu89 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["go"]="-Werror -std=gnu89 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["guile"]="-Werror -std=gnu89 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["java"]="-Werror -std=gnu89 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["javascript"]="-Werror -std=gnu89 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["lua"]="-Werror -std=gnu89 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["octave"]="-Werror -std=gnu89 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["perl5"]="-Werror -std=gnu89 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["php"]="-Werror -std=gnu89 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["python"]="-Werror -std=gnu89 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["ruby"]="-Werror -std=gnu89 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["tcl"]="-Werror -std=gnu89 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
)
- declare -A CXXFLAGS_EXAMPLES && CXXFLAGS_EXAMPLES=(
["csharp"]="-Werror -std=c++98 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["go"]="-Werror -std=c++98 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["guile"]="-Werror -std=c++98 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["java"]="-Werror -std=c++98 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["javascript"]="-Werror -std=c++98 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["lua"]="-Werror -std=c++98 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["octave"]="-Werror -std=c++98 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["perl5"]="-Werror -std=c++98 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
["php"]="-Werror -std=c++98 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["python"]="-Werror -std=c++98 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["ruby"]="-Werror -std=c++98 -fdiagnostics-show-option -pedantic -Wno-long-long -Wreturn-type"
["tcl"]="-Werror -std=c++98 -fdiagnostics-show-option -Wno-long-long -Wreturn-type"
)
- $CC --version
- $CXX --version
script:
- ./autogen.sh && ./configure
- echo 'Configuring...' && echo -en 'travis_fold:start:script.1\\r'
- ./autogen.sh && mkdir -p build/build && cd build/build && ../../configure $CONFIGOPTS
- echo -en 'travis_fold:end:script.1\\r'
- make -s $SWIGJOBS
- if test -z "$SWIGLANG"; then make -s check-ccache; fi
- ./swig -version
- ./swig -version && ./swig -pcreversion
- if test -z "$SWIGLANG"; then make -s $SWIGJOBS check-ccache; fi
- if test -z "$SWIGLANG"; then make -s $SWIGJOBS check-errors-test-suite; fi
- echo 'Installing...' && echo -en 'travis_fold:start:script.2\\r'
- if test -z "$SWIGLANG"; then sudo make -s install && swig -version && ccache-swig -V; fi
- echo -en 'travis_fold:end:script.2\\r'
- if test -n "$SWIGLANG"; then make -s check-$SWIGLANG-version; fi
- if test -n "$SWIGLANG"; then make -k $SWIGJOBS check-$SWIGLANG-examples; fi
- if test -n "$SWIGLANG"; then make -k $SWIGJOBS check-$SWIGLANG-examples CFLAGS="${CFLAGS_EXAMPLES[$SWIGLANG]}" CXXFLAGS="${CXXFLAGS_EXAMPLES[$SWIGLANG]}"; fi
- if test -n "$SWIGLANG"; then make -k $SWIGJOBS check-$SWIGLANG-test-suite; fi
- echo 'Cleaning...' && echo -en 'travis_fold:start:script.3\\r'
- make check-maintainer-clean && ../../configure $CONFIGOPTS
- echo -en 'travis_fold:end:script.3\\r'
branches:
only:
- master

18
ANNOUNCE
View file

@ -1,8 +1,8 @@
*** ANNOUNCE: SWIG 3.0.0 (in progress) ***
*** ANNOUNCE: SWIG 3.0.2 (4 Jun 2014) ***
http://www.swig.org
We're pleased to announce SWIG-3.0.0, the latest SWIG release.
We're pleased to announce SWIG-3.0.2, the latest SWIG release.
What is SWIG?
=============
@ -10,22 +10,22 @@ 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 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,
PHP, C#, Go, Java, Javascript, 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-3.0.0.tar.gz
http://prdownloads.sourceforge.net/swig/swig-3.0.2.tar.gz
A Windows version is also available at
http://prdownloads.sourceforge.net/swig/swigwin-3.0.0.zip
http://prdownloads.sourceforge.net/swig/swigwin-3.0.2.zip
Please report problems with this release to the swig-devel mailing list,
details at http://www.swig.org/mail.html.

32
CCache/Makefile.in
View file

@ -14,7 +14,7 @@ NOSOFTLINKSTEST=
CC=@CC@
CFLAGS=@CFLAGS@ -I.
SWIG=swig
SWIG_LIB=../../Lib
SWIG_LIB=../$(srcdir)/../Lib
EXEEXT=@EXEEXT@
# Use standard autoconf approach to transform executable name using --program-prefix and --program-suffix
@ -27,38 +27,40 @@ HEADERS = ccache.h mdfour.h
all: $(PACKAGE_NAME)$(EXEEXT)
# Regenerate Makefile if Makefile.in or config.status have changed.
Makefile: $(srcdir)/Makefile.in ./config.status
$(SHELL) ./config.status
# Note that HTML documentation is actually generated and used from the main SWIG documentation Makefile
docs: $(PACKAGE_NAME).1 web/ccache-man.html
docs: $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/ccache-man.html
$(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
$(PACKAGE_NAME).1: ccache.yo
-yodl2man -o $(PACKAGE_NAME).1 ccache.yo
$(srcdir)/$(PACKAGE_NAME).1: $(srcdir)/ccache.yo
-yodl2man -o $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/ccache.yo
web/ccache-man.html: ccache.yo
yodl2html -o web/ccache-man.html ccache.yo
$(srcdir)/web/ccache-man.html: $(srcdir)/ccache.yo
yodl2html -o $(srcdir)/web/ccache-man.html $(srcdir)/ccache.yo
install: $(PACKAGE_NAME)$(EXEEXT) $(PACKAGE_NAME).1
install: $(PACKAGE_NAME)$(EXEEXT) $(srcdir)/$(PACKAGE_NAME).1
@echo "Installing $(PACKAGE_NAME)"
@echo "Installing $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)"
${INSTALLCMD} -d $(DESTDIR)${bindir}
${INSTALLCMD} -m 755 $(PACKAGE_NAME)$(EXEEXT) $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
@echo "Installing $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1"
${INSTALLCMD} -d $(DESTDIR)${mandir}/man1
${INSTALLCMD} -m 644 ${srcdir}/$(PACKAGE_NAME).1 $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
${INSTALLCMD} -m 644 $(srcdir)/$(PACKAGE_NAME).1 $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
uninstall: $(PACKAGE_NAME)$(EXEEXT) $(PACKAGE_NAME).1
uninstall: $(PACKAGE_NAME)$(EXEEXT) $(srcdir)/$(PACKAGE_NAME).1
rm -f $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
rm -f $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
clean:
/bin/rm -f $(OBJS) *~ $(PACKAGE_NAME)$(EXEEXT)
check : test
test: test.sh
SWIG_LIB='$(SWIG_LIB)' PATH=../..:$$PATH SWIG='$(SWIG)' CC='$(CC)' NOSOFTLINKSTEST='$(NOSOFTLINKSTEST)' ./test.sh
SWIG_LIB='$(SWIG_LIB)' PATH=../..:$$PATH SWIG='$(SWIG)' CC='$(CC)' NOSOFTLINKSTEST='$(NOSOFTLINKSTEST)' $(srcdir)/test.sh
check: test
@ -67,11 +69,11 @@ distclean: clean
/bin/rm -rf autom4te.cache
maintainer-clean: distclean
/bin/rm -f $(PACKAGE_NAME).1 web/ccache-man.html
/bin/rm -f $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/ccache-man.html
# FIXME: To fix this, test.sh needs to be able to take ccache from the
# installed prefix, not from the source dir.
installcheck:
installcheck:
@echo "WARNING! This is not really \"installcheck\" yet."
$(MAKE) check

525
CHANGES
View file

@ -3,6 +3,513 @@ SWIG (Simplified Wrapper and Interface Generator)
See the CHANGES.current file for changes in the current version.
See the RELEASENOTES file for a summary of changes in each release.
Version 3.0.1 (27 May 2014)
===========================
2014-05-25: hfalcic
[Python] Python 3 byte string output: use errors="surrogateescape"
if available on the version of Python that's in use. This allows
obtaining the original byte string (and potentially trying a fallback
encoding) if the bytes can't be decoded as UTF-8.
Previously, a UnicodeDecodeError would be raised with no way to treat
the data as bytes or try another codec.
2014-05-18: vkalinin
Bug #175 - Restore %extend to work for unnamed nested structures by using a C
symbol comprising the outer structure name and unnamed variable instance name.
2014-05-15: kwwette
Add #166 - 'make check' now works out of source. This required te examples to build
out of source. The main languages have been tested - C#, Go, Guile, Java, Javascript,
Lua, Octave, Perl, PHP, Python, Ruby and Tcl.
2014-05-01: Oliver Buchtala
Javascript support added, see Javascript chapter in the documentation.
2014-05-01: olly
[PHP] The generated __isset() method now returns true for read-only properties.
2014-04-24: kwwette
[Go] Fix go ./configure parsing of gccgo --version, and
goruntime.swg typo in __GNUC_PATCHLEVEL__ (SF Bug #1298)
2014-04-24: kwwette
Fix {python|perl5|ruby|tcl}/java examples
In Lib/gcj/cni.i, for compatibility with newer gcj versions:
- remove JvAllocObject() which gcj no longer defines, from gcj Changelog:
2004-04-16 Bryce McKinlay <mckinlay@redhat.com>
* gcj/cni.h (JvAllocObject): Remove these obsolete,
undocumented CNI calls.
- change JvCreateJavaVM() argument from void* to JvVMInitArgs*, from gcj Changelog:
2005-02-23 Thomas Fitzsimmons <fitzsim@redhat.com>
PR libgcj/16923
...
(JvCreateJavaVM): Declare vm_args as JvVMInitArgs* rather than void*.
*** POTENTIAL INCOMPATIBILITY ***
2014-04-08: wsfulton
SF Bug #1366 - Remove duplicate declarations of strtoimax and strtoumax in inttypes.i
2014-04-08: wsfulton
[Java C#] Enums which have been ignored via %ignore and are subsequently
used are handled slightly differently. Type wrapper classes are now generated
which are effectively a wrapper of an empty enum. Previously in Java uncompilable
code was generated and in C# an int was used.
2014-04-04: wsfulton
Fix regression in 3.0.0 where legal code following an operator<< definition might
give a syntax error. SF Bug #1365.
2014-04-03: olly
[PHP] Fix wrapping director constructors with default parameters
with a ZTS-enabled build of PHP.
2014-04-02: olly
[PHP] Pass the ZTS context we already have to avoid needing to
call TSRMLS_FETCH, which is relatively expensive.
2014-04-02: olly
[PHP] Pass ZTS context through to t_output_helper() so it works
with a ZTS-enabled build of PHP. Reported by Pierre Labastie in
github PR#155.
2014-03-28: wsfulton
[Java C# D Go] Fixes for C enums used in an API and the definition of the enum
has not been parsed. For D, this fixes a segfault in SWIG. The other languages
now produce code that compiles, although the definition of the enum is needed
in order to use the enum properly from the target language.
2014-03-23: v-for-vandal
[Lua] Fix for usage of snprintf in Lua runtime which Visual Studio does not have.
Version 3.0.0 (16 Mar 2014)
===========================
2014-03-16: wsfulton
C++11 support initially developed as C++0x support by Matevz Jekovec as a Google Summer of Code
project has been further extended. The C++11 support is comprehensive, but by no means complete
or without limitations. Full details for each new feature in C++11 is covered in the
CPlusPlus11.html chapter in the documentation which is included in SWIG and also available
online at http://www.swig.org/Doc3.0/CPlusPlus11.html.
2014-03-14: v-for-vandal
[Lua] Numerous Lua improvements:
1. %nspace support has been added. Namespaces are mapped to tables in the module, with the same
name as the C++ namespace.
2. Inheritance is now handled differently. Each class metatable keeps a list of class bases instead
of merging all members of all bases into the derived class.
3. The new metatables result in differences in accessing class members. For example:
%module example
struct Test {
enum { TEST1 = 10, TEST2 = 20 };
static const int ICONST = 12;
};
Now this can be used as follows:
print(example.Test.TEST1)
print(example.Test.ICONST)
The old way was:
print(example.Test_TEST1)
print(example.Test_ICONST)
4. The special class metatable member ".constructor" was removed. Now SWIG generates the proxy
function by itself and assigns it directly to the class table "__call" method.
5. eLua should also now support inheritance.
6. 'const' subtable in eLua is considered deprecated.
Changes in behaviour:
a. You can no longer assign to non-existing class members in classes without a __setitem__ method.
It will cause a Lua error.
b. You can no longer iterate over a module table and copy everything into the global namespace.
Actually, this was never the case, but it is now explicitly prohibited.
c. Now changing a base class will immediately affect all derived classes.
d. There might be some issues with inheritance. Although the bases iteration scheme is the same
as was used for merging base classes into derived one, some unknown issues may arise.
The old metatable behaviour can be restored by using the -no-old-metatable-bindings option.
*** POTENTIAL INCOMPATIBILITY ***
2014-03-06: wsfulton
[Python] Change in default behaviour wrapping C++ bool. Only a Python True or False
will now work for C++ bool parameters. This fixes overloading bool with other types.
Python 2.3 minimum is now required for wrapping bool.
When wrapping:
const char* overloaded(bool value) { return "bool"; }
const char* overloaded(int value) { return "int"; }
Previous behaviour:
>>> overloaded(False)
'int'
>>> overloaded(True)
'int'
>>> overloaded(0)
'int'
Now we get the expected behaviour:
>>> overloaded(False)
'bool'
>>> overloaded(0)
'int'
The consequence is when wrapping bool in non-overloaded functions:
const char* boolfunction(bool value) { return value ? "true" : "false"; }
The previous behaviour was very Pythonic:
>>> boolfunction("")
'false'
>>> boolfunction("hi")
'true'
>>> boolfunction(12.34)
'true'
>>> boolfunction(0)
'false'
>>> boolfunction(1)
'true'
Now the new behaviour more along the lines of C++ due to stricter type checking. The
above calls result in an exception and need to be explicitly converted into a bool as
follows:
>>> boolfunction(0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: in method 'boolfunction', argument 1 of type 'bool'
>>> boolfunction(bool(0))
'false'
The old behaviour can be resurrected by passing the -DSWIG_PYTHON_LEGACY_BOOL command line
parameter when executing SWIG. Typemaps can of course be written to customise the behaviour
for specific parameters.
*** POTENTIAL INCOMPATIBILITY ***
2014-03-06: wsfulton
Fix SF Bug #1363 - Problem with method overloading when some methods are added by %extend
and others are real methods and using template default parameters with smart pointers.
This is noticeable as a regression since 2.0.12 when using the default smart pointer
handling for some languages when the smart pointer wraps std::map and other STL containers.
2014-03-02: wsfulton
[Python] SF Patch #346 from Jens Krueger. Correct exception thrown attempting to
access a non-existent C/C++ global variable on the 'cvar' object. The exception thrown
used to be a NameError. However, as this access is via a primary, an AttributeError
is more correct and so the exception thrown now is an AttributeError. Reference:
http://docs.python.org/2/reference/expressions.html#attribute-references
*** POTENTIAL INCOMPATIBILITY ***
2014-03-01: wsfulton
[Python] Patch #143 Fix type shown when using type() to include the module and package
name when using -builtin.
2014-03-01: wsfulton
[Python] SF patch #347 Fix missing argument count checking with -modern.
Fixes regression introduced when builtin changes were introduced in SWIG-2.0.3.
2014-02-21: wsfulton
[PHP] Fix warning suppression using %warnfilter for PHP reserved class names.
2014-02-19: olly
[Lua] Add keyword warnings for Lua keywords and Basic Functions.
2014-02-19: olly
-Wallkw now includes keywords for all languages with keyword
warnings (previously Go and R were missing).
2014-02-19: olly
[PHP] Update the lists of PHP keywords with new ones from PHP 5.4
and newer (and some missing ones from 5.3). Reserved PHP constants
names are now checked against enum values and constants, instead
of against function and method names. Built-in PHP function names
no longer match methods added by %extend. Functions and methods
named '__sleep', '__wakeup', 'not', 'parent', or 'virtual' are no
longer needlessly renamed.
2014-02-15: wsfulton
Fix the %$ismember %rename predicates to also apply to members added via %extend.
Add %$isextendmember for %rename of members added via %extend. This can be used to
distinguish between normal class/struct members and %extend members. For example
'%$ismember, %$not %$isextendmember' will now identify just class/struct members.
*** POTENTIAL INCOMPATIBILITY ***
2014-02-16: hfalcic
[Python] Patch #137 - fix crashes/exceptions in exception handling in Python 3.3
2014-02-15: wsfulton
[Java] Add support for the cdata library.
2014-02-08: vkalinin
Nested class support added. This primarily allows SWIG to properly parse nested
classes and keep the nested class information in the parse tree. Java and C#
have utilised this information wrapping the C++ nested classes as Java/C#
nested classes. The remaining target languages ignore nested classes as in
previous versions. Help is needed by users of these remaining languages to
design how C++ nested classes can be best wrapped. Please talk to us on the
swig-devel mailing list if you think you can help.
Previously, there was limited nested class support. Nested classes were treated
as opaque pointers. However, the "nestedworkaround" feature provided a way to
wrap a nested class as if it was a global class. This feature no longer exists
and is replaced by the new "flatnested" feature. This effectively does the same
thing with less manual code to be written. Please see the 'Nested classes'
section in the documentation in SWIGPlus.html if you were previously using this
feature.
SWIG now parses the contents of nested classes where previously it did not. You
may find that you will need to make adjustments to your interface file as
effectively extra code is being wrapped.
*** POTENTIAL INCOMPATIBILITY ***
2014-02-06: gjanssens
[Guile] Patch #133. Make scm to string conversion work with non-ascii strings.
Guile 2 has a completely rewritten string implementation. SWIG made some assumptions
that are no longer valid as to the internals of guile's string representation.
2014-01-30: wsfulton
[C#] Add new swigtype_inout.i library containing SWIGTYPE *& OUTPUT typemaps.
Example usage wrapping:
void f(XXX *& x) { x = new XXX(111); }
would be:
XXX x = null;
f(out x);
// use x
x.Dispose(); // manually clear memory or otherwise leave out and leave it to the garbage collector
2014-01-21: ianlancetaylor
[Go] Add %go_import directive.
2014-01-21: ianlancetaylor
[Go] Add support for Go 1.3, not yet released.
2014-01-20: wsfulton
Director exceptions (Swig::DirectorException) now derive from std::exception
and hence provide the what() method. In Python and Ruby, this replaces the now
deprecated DirectorException::getMessage() method.
2014-01-14: diorcety
Patch #112 - Fix symbol resolution involving scopes that have multiple levels
of typedefs - fixes some template resolutions as well as some typemap searches.
2014-01-11: wsfulton
Fix and document the naturalvar feature override behaviour - the naturalvar
feature attached to a variable name has precedence over the naturalvar
feature attached to the variable's type. The overriding was not working
when turning the feature off on the variable's name.
Fix so that any use of the naturalvar feature will override the global
setting. Previously when set globally by -naturalvar or %module(naturalvar=1),
use of the naturalvar feature was not always honoured.
2014-01-06: ianlancetaylor
[Go] Fix bug that broke using directors from a thread not
created by Go.
2013-12-24: ptomulik
[Python] SF Bug #1297
Resolve several issues related to python imports.
For example, it's now possible to import modules having the same module
names, but belonging in different packages.
From the user's viewpoint, this patch gives a little bit more control on
import statements generated by SWIG. The user may choose to use relative
or absolute imports.
Some details:
- we (still) generate import statements in the form 'import a.b.c' which
corresponds to absolute imports in python3 and (the only available)
ambiguous one in python2.
- added -relativeimport option to use explicit relative import syntax
(python3),
The "Python Packages" section in the documentation discusses how to work
with importing packages including the new -relativeimport command line option.
2013-12-23: vadz
[Octave, Perl, Python, R, Ruby, Tcl] Change the length of strings created from fixed-size char
buffers in C code.
This is a potential backwards compatibility break: a "char buf[5]" containing "ho\0la" was
returned as a string of length 5 before, but is returned as a string of length 2 now. Also,
it was possible to assign a (non-NUL-terminated) string "hello" to such a buffer before but
now this fails and only "helo" can fit.
Apply "char FIXSIZE[ANY]" typemaps to explicitly choose the old behaviour.
*** POTENTIAL INCOMPATIBILITY ***
2013-12-23: talby
[Perl] Add support for directors.
2013-12-18: ianlancetaylor
[Go] Don't require that Go environment variables be set
when running examples or testsuite when using Go 1 or
later.
2013-12-17: ianlancetaylor
[Go] Remove -longsize option (for backward compatibility,
ignore it if seen).
2013-12-17: ianlancetaylor
[Go] Add -go-pkgpath option.
2013-12-16: ianlancetaylor
[Go] Update for Go 1.2 release. Add support for linking
SWIG code directly into executable, rather than using a
shared library.
2013-12-13: ianlancetaylor
[Go] Add SWIG source file name as comments in generated
files. This can be used by Go documentation tools.
2013-12-12: jleveque
[Lua] Fix typo (wchar instead of wchar_t) which made wchar.i
for Lua useless.
2013-12-12: vmiklos
[PHP] PHP's peculiar call-time pass-by-reference feature was
deprecated in PHP 5.3 and removed in PHP 5.4, so update the REF
typemaps in phppointers.i to specify pass-by-reference in the
function definition. Examples/php/pointer has been updated
accordingly.
2013-12-12: olly
[PHP] The usage of $input in PHP directorout typemaps has been
changed to be consistent with other languages. The typemaps
provided by SWIG have been updated accordingly, but if you
have written your own directorout typemaps, you'll need to
update $input to &$input (or make equivalent changes).
*** POTENTIAL INCOMPATIBILITY ***
2013-11-27: vadz
[C#, Java, Python] Add std_auto_ptr.i defining typemaps for returning std::auto_ptr<>.
2013-11-09: wsfulton
[C#] Apply patch #79 from Brant Kyser
- Remove using directives from the generated C# code and fully qualify the use of all .NET
framework types in order to minimize potential name collisions from input files defining
types, namespace, etc with the same name as .NET framework members.
- Globally qualify the use of .NET framework types in the System namespace
- Remove .NET 1.1 support, .NET 2 is the minimum for the C# module
This is a potential backwards compatibility break if code has been added relying on these using
statements that used to be generated:
using System;
using System.Runtime.InteropServices;
The quick fix to add these back in is to add the -DSWIG2_CSHARP command line option when
executing SWIG. See CSharp.html documentation for more info.
*** POTENTIAL INCOMPATIBILITY ***
2013-11-05: wsfulton
[Java] Fix some corner cases for the $packagepath/$javaclassname special variable substitution.
2013-11-05: wsfulton
[Java] Apply patch #91 from Marvin Greenberg - Add director:except feature for improved
exception handling in director methods for Java.
2013-10-15: vadz
Allow using \l, \L, \u, \U and \E in the substitution part of %(regex:/pattern/subst/)
inside %rename to change the case of the text being replaced.
2013-10-12: wsfulton
[CFFI] Apply #96 - superclass not lispify
2013-10-12: wsfulton
Merge in C++11 support from the gsoc2009-matevz branch where Matevz Jekovec first
started the C++0x additions. Documentation of the C++11 features supported is in a
new Chapter of the documentation, "SWIG and C++11" in Doc/Manual/CPlusPlus11.html.
2013-10-04: wsfulton
Fix %naturalvar not having any affect on templated classes instantiated with an
enum as the template parameter type. Problem reported by Vadim Zeitlin.
2013-09-20: wsfulton
[Java] Fix a memory leak for the java char **STRING_ARRAY typemaps.
Version 2.0.12 (9 Feb 2014)
===========================
2014-01-16: wsfulton
[PHP] Fix compilation error in ZTS mode (64 bit windows) due to incorrect placement
of TSRMLS_FETCH() in SWIG_Php_GetModule() as reported by Mark Dawson-Butterworth.
2014-01-13: kwwette
[Octave] update support to Octave version 3.8.0
- Octave 3.8.0 no longer defines OCTAVE_API_VERSION_NUMBER, but 3.8.1
will define OCTAVE_{MAJOR,MINOR,PATCH}_VERSION instead: see
http://hg.savannah.gnu.org/hgweb/octave/rev/b6b6e0dc700e
So we now use a new macro SWIG_OCTAVE_PREREQ(major,minor,patch) to
enable features requiring Octave version major.minor.patch or later.
For Octave versions prior to 3.8.1, we reconstruct values for
OCTAVE_{MAJOR,MINOR,PATCH}_VERSION based on OCTAVE_API_VERSION_NUMBER,
extracted from Octave's ChangeLogs. An additional hack is needed to
distinguish between Octave <= 3.2.x and 3.8.0, neither of which define
OCTAVE_API_VERSION_NUMBER.
- Octave 3.8.0 deprecates symbol_table::varref(), so remove its use
for this and future versions of Octave.
- Octave 3.8.0 removes octave_value::is_real_nd_array(), used in
octave_swig_type::dims(). Its use is not required here, so remove it.
- Retested against Octave versions 3.0.5, 3.2.4, 3.4.3, 3.6.4, and 3.8.0.
- Updated Octave documentation with tested Octave versions, and added a
warning against using versions <= 3.x.x, which are no longer tested.
2013-12-22: wsfulton
C++11 support for new versions of erase and insert in the STL containers.
The erase and insert methods in the containers use const_iterator instead
of iterator in C++11. There are times when the methods wrapped must match
the parameters exactly. Specifically when full type information for
template types is missing or SWIG fails to look up the type correctly,
for example:
%include <std_vector.i>
typedef float Real;
%template(RealVector) std::vector<Real>;
SWIG does not find std::vector<Real>::iterator because %template using
typedefs does not always work and so SWIG doesn't know if the type is
copyable and so uses SwigValueWrapper<iterator> which does
not support conversion to another type (const_iterator). This resulted
in compilation errors when using the C++11 version of the containers.
Closes #73
2013-10-17: wsfulton
[R] Fix SF #1340 - Visual Studio compile error in C++ wrappers due to #include <exception>
within extern "C" block.
2013-10-17: wsfulton
[Python] Fix SF #1345 - Missing #include <stddef.h> for offsetof when using -builtin.
2013-10-12: wsfulton
[Lua] Apply #92 - missing return statements for SWIG_Lua_add_namespace_details()
and SWIG_Lua_namespace_register().
Version 2.0.11 (15 Sep 2013)
============================
@ -201,7 +708,7 @@ Version 2.0.10 (27 May 2013)
The macros are silently ignored.
2013-04-17: wsfulton
[C#] Pull patch #34 from BrantKyser to fix smart pointers in conjuction with directors.
[C#] Pull patch #34 from BrantKyser to fix smart pointers in conjunction with directors.
2013-04-15: kwwette
[Octave] Fix bugs in output of cleanup code.
@ -5206,7 +5713,7 @@ Version 1.3.29 (March 21, 2006)
6146 _std_containers.so
174 _std_containers.so.hidden
Excecution times:
Execution times:
real 0m0.050s user 0m0.039s sys 0m0.005s _std_containers.so
real 0m0.039s user 0m0.026s sys 0m0.007s _std_containers.so.hidden
@ -5292,7 +5799,7 @@ Version 1.3.29 (March 21, 2006)
protected methods by default.
In previous releases, you needed to use the 'dirprot'
option to acheive the same.
option to achieve the same.
If you want, you can disable the new default behaviour,
use the 'nodirprot' option:
@ -5619,7 +6126,7 @@ Version 1.3.28 (February 12, 2006)
%rename("%(utitle)s",%$isfunction,%$ismember) "";
to avoid clashings with other swig macros/directives.
to avoid clashes with other swig macros/directives.
01/14/2006: cfisavage
[Ruby]
@ -9547,7 +10054,7 @@ Version 1.3.23 (November 11, 2004)
- Remove the ability to share type information by using c linking.
All type sharing happens through a global variable in the target language.
+ Remove SWIG_NOIMPORT, SWIG_RUNTIME, and related defines.
+ Depreciate -runtime, -noruntime command line options
+ Deprecate -runtime, -noruntime command line options
+ Update test-suite common.mk to correctly build multicpptest
+ Remove reference to precommon.swg
+ Update the guile_gh interface to share data by a global var instead
@ -11722,7 +12229,7 @@ Version 1.3.20 (December 17, 2003)
11/30/2003: cheetah (William Fulton)
[Java] Fixed [ 766409 ] missing symbol SWIG_JavaThrowException during module load
SWIGs internal functions are all static as there is no need for different SWIG
SWIG's internal functions are all static as there is no need for different SWIG
generated modules to share any code at runtime.
11/30/2003: beazley
@ -20789,9 +21296,9 @@ Version 1.3 Alpha 1 (February 11, 2000)
*** POTENTIAL INCOMPATIBILITY ***
1/30/00 : loic
Conditionaly compile experimental code with --enable-experiment
Conditionally compile experimental code with --enable-experiment
configure flag.
Fix .cvsignore to ignore configrue & yacc generated files
Fix .cvsignore to ignore configure & yacc generated files
1/28/00 : loic
Apply automake everywhere
@ -21303,7 +21810,7 @@ Version 1.1 Patch 4 (January 4, 1998)
12/29/97: Fixed configure script and a few makefiles to support Python 1.5
12/29/97: Added 'embed15.i' library file. This file should be used to
staticly link versions of Python 1.5. To make it the default,
statically link versions of Python 1.5. To make it the default,
simply copy 'swig_lib/python/embed15.i' to 'swig_lib/python/embed.i'
Version 1.1 Patch 3 (November 24, 1997)

23
CHANGES.current
View file

@ -2,13 +2,22 @@ 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 3.0.0 (in progress)
============================
Version 3.0.2 (4 Jun 2014)
===========================
2013-10-04: wsfulton
Fix %naturalvar not having any affect on templated classes instantiated with an
enum as the template parameter type. Problem reported by Vadim Zeitlin.
2014-06-02: v-for-vandal
[Lua] Pull request #176:
If class has no __eq implemented, then default __eq is generated.
Default __eq compares actual pointers stored inside Lua userdata.
2013-09-20: wsfulton
[Java] Fix a memory leak for the java char **STRING_ARRAY typemaps.
2014-06-02: vkalinin
Fix #183 - %extend and unnamed nested structs
2014-05-28: kwwette
Fix install failure when using an 'out of source' build using the shipped
tarball - regression introduced in swig-3.0.1.
2014-05-24: kwwette
[Octave] Remove deprecated -global/-noglobal command-line arguments
*** POTENTIAL INCOMPATIBILITY ***

104
COPYRIGHT
View file

@ -11,60 +11,62 @@ Portions also copyrighted by:
Information-technology Promotion Agency, Japan
Active SWIG Developers:
William Fulton (wsf@fultondesigns.co.uk) (SWIG core, Java, C#, Windows, Cygwin)
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)
William Fulton (wsf@fultondesigns.co.uk) (SWIG core, Java, C#, Windows, Cygwin)
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)
Oliver Buchtala (oliver.buchtala@gmail.com) (Javascript)
Neha Narang (narangneha03@gmail.com) (Javascript)
Simon Marchetto (simon.marchetto@scilab-enterprises.com) (Scilab)
Past SWIG developers and major contributors include:
Dave Beazley (dave-swig@dabeaz.com) (SWIG core, Python, Tcl, Perl)
Henning Thielemann (swig@henning-thielemann.de) (Modula3)
Matthias Köppe (mkoeppe@mail.math.uni-magdeburg.de) (Guile, MzScheme)
Luigi Ballabio (luigi.ballabio@fastwebnet.it) (STL wrapping)
Mikel Bancroft (mikel@franz.com) (Allegro CL)
Surendra Singhi (efuzzyone@netscape.net) (CLISP, CFFI)
Marcelo Matus (mmatus@acms.arizona.edu) (SWIG core, Python, UTL[python,perl,tcl,ruby])
Art Yerkes (ayerkes@speakeasy.net) (Ocaml)
Lyle Johnson (lyle@users.sourceforge.net) (Ruby)
Charlie Savage (cfis@interserv.com) (Ruby)
Thien-Thi Nguyen (ttn@glug.org) (build/test/misc)
Richard Palmer (richard@magicality.org) (PHP)
Sam Liddicott - Ananova Ltd (saml@liddicott.com) (PHP)
Tim Hockin - Sun Microsystems (thockin@sun.com) (PHP)
Kevin Ruland (PHP)
Shibukawa Yoshiki (Japanese Translation)
Jason Stewart (jason@openinformatics.com) (Perl5)
Loic Dachary (Perl5)
David Fletcher (Perl5)
Gary Holt (Perl5)
Masaki Fukushima (Ruby)
Scott Michel (scottm@cs.ucla.edu) (Java directors)
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)
Dirk Gerrits (Allegro CL)
Neil Cawse (C#)
Harco de Hilster (Java)
Alexey Dyachenko (dyachenko@fromru.com) (Tcl)
Bob Techentin (Tcl)
Martin Froehlich <MartinFroehlich@ACM.org> (Guile)
Marcio Luis Teixeira <marciot@holly.colostate.edu> (Guile)
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)
Baozeng Ding <sploving1@163.com> (Scilab)
Ian Lance Taylor (Go)
Vadim Zeitlin (PCRE)
Stefan Zager (szager@gmail.com) (Python)
Vincent Couvert (Scilab)
Sylvestre Ledru (Scilab)
Wolfgang Frisch (Scilab)
Dave Beazley (dave-swig@dabeaz.com) (SWIG core, Python, Tcl, Perl)
Henning Thielemann (swig@henning-thielemann.de) (Modula3)
Matthias Köppe (mkoeppe@mail.math.uni-magdeburg.de) (Guile, MzScheme)
Luigi Ballabio (luigi.ballabio@fastwebnet.it) (STL wrapping)
Mikel Bancroft (mikel@franz.com) (Allegro CL)
Surendra Singhi (efuzzyone@netscape.net) (CLISP, CFFI)
Marcelo Matus (mmatus@acms.arizona.edu) (SWIG core, Python, UTL[python,perl,tcl,ruby])
Art Yerkes (ayerkes@speakeasy.net) (Ocaml)
Lyle Johnson (lyle@users.sourceforge.net) (Ruby)
Charlie Savage (cfis@interserv.com) (Ruby)
Thien-Thi Nguyen (ttn@glug.org) (build/test/misc)
Richard Palmer (richard@magicality.org) (PHP)
Sam Liddicott - Ananova Ltd (saml@liddicott.com) (PHP)
Tim Hockin - Sun Microsystems (thockin@sun.com) (PHP)
Kevin Ruland (PHP)
Shibukawa Yoshiki (Japanese Translation)
Jason Stewart (jason@openinformatics.com) (Perl5)
Loic Dachary (Perl5)
David Fletcher (Perl5)
Gary Holt (Perl5)
Masaki Fukushima (Ruby)
Scott Michel (scottm@cs.ucla.edu) (Java directors)
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)
Dirk Gerrits (Allegro CL)
Neil Cawse (C#)
Harco de Hilster (Java)
Alexey Dyachenko (dyachenko@fromru.com) (Tcl)
Bob Techentin (Tcl)
Martin Froehlich <MartinFroehlich@ACM.org> (Guile)
Marcio Luis Teixeira <marciot@holly.colostate.edu> (Guile)
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)
Baozeng Ding <sploving1@163.com> (Scilab)
Ian Lance Taylor (Go)
Vadim Zeitlin (PCRE)
Stefan Zager (szager@gmail.com) (Python)
Vincent Couvert (Scilab)
Sylvestre Ledru (Scilab)
Wolfgang Frisch (Scilab)
Past contributors include:
James Michael DuPont, Clark McGrew, Dustin Mitchell, Ian Cooke, Catalin Dumitrescu, Baran

788
Doc/Devel/cpp11.html Normal file
View file

@ -0,0 +1,788 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
<TITLE></TITLE>
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.0 (Unix)">
<META NAME="CREATED" CONTENT="20090712;16061100">
<META NAME="CHANGED" CONTENT="20090817;17311900">
<META NAME="Podatek 1" CONTENT="">
<META NAME="Podatek 2" CONTENT="">
<META NAME="Podatek 3" CONTENT="">
<META NAME="Podatek 4" CONTENT="">
<STYLE TYPE="text/css">
<!--
@page { margin: 2cm }
H1 { margin-bottom: 0.21cm }
H1.western { font-family: "Liberation Serif", serif }
H1.cjk { font-family: "DejaVu Sans" }
H1.ctl { font-family: "DejaVu Sans" }
P { margin-bottom: 0.21cm }
H2 { margin-bottom: 0.21cm }
A:link { so-language: zxx }
-->
</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
<H1 CLASS="western"><U>C++0x/C++11 support for SWIG</U></H1>
<H1 CLASS="western">Summary</H1>
<P>This is a technical overview of the C++0x/C++11 support for the Swig.
This area of Swig is a work in progress. Initial C++0x/C++11 support for
Swig was written during the Google Summer of Code 2009 period by
Matevž Jekovec.</P>
<H1 CLASS="western">SVN branch</H1>
<P>branches/gsoc2009-matevz</P>
<H1 CLASS="western">New C++11 features status</H1>
<P>Wikipedia article: <A HREF="http://en.wikipedia.org/wiki/C++0x">http://en.wikipedia.org/wiki/C%2B%2B0x</A>
</P>
<H2>Rvalue reference and move semantics [done]</H2>
<P>The Rvalues are used in practice to speed up the move operations
on different containers.</P>
<P>In the following example, we want to swap the given elements:</P>
<PRE>template &lt;class T&gt; swap(T&amp; a, T&amp; b) {
T tmp(a); // now we have two copies of a
a = b; // now we have two copies of b
b = tmp; // now we have two copies of tmp (aka a)
}</PRE><P>
This can now be solved using the new function std::move():</P>
<PRE>template &lt;class T&gt; swap(T&amp; a, T&amp; b) {
T tmp(std::move(a));
a = std::move(b);
b = std::move(tmp);
}</PRE><P STYLE="margin-bottom: 0cm">
For the move function to take effect, user needs to reimplement the
move constructor (taking ClassType&amp;&amp; as an argument) and
operator=(ClassType&amp;&amp;):</P>
<PRE>class MyClass {
MyClass(MyClass&amp;&amp; p) : ptr(p.ptr) {p.ptr = 0;}
MyClass&amp; operator=(MyClass&amp;&amp; p) {
std::swap(ptr, p.ptr);
return *this;
}
};</PRE><P>
In practice, the Rvalues are used for temporaries (when passing the
result of one function as an argument to another).</P>
<P>Done: Added type&amp;&amp; to Swig parser. Added testcase
cpp11_rvalue_reference.i. Operator &amp;&amp; is treated the same as
operator &amp;. R11450</P>
<P STYLE="margin-bottom: 0cm">Article:
<A HREF="http://www.artima.com/cppsource/rvalue.html">http://www.artima.com/cppsource/rvalue.html</A></P>
<H2>Generalized constant expressions [done]</H2>
<P>In C++11 you can define functions as constant expressions.
Functions need to return constant value in form &quot;return expr&quot;,
where expr is a constant expression.
</P>
<P>A keyword &quot;constexpr&quot; is introduced for this. eg.:
constexpr int getNumber() { return 5; } const int MY_CONSTANT =
getNumber();
</P>
<P>Constants are treated as normal variables in interpreted languages
because they are not compiled into the executable. Java &quot;final&quot;
constants are defined runtime as well. C++ constants need to be
declared in the header file and defined in the implementation file,
so swig doesn't need to know about the constant values when parsing
the header file.
</P>
<P>Done: Added the “constexpr “ keyword to Swig. Added testcase
cpp11_constexpr. R11322</P>
<P>Problem: No compilers were known to support constexpr yet, so the
testcase was temporarily commented out in common.mk.
</P>
<H2>Extern template [done]</H2>
<P>Extern template forces the GCC compiler to not instantiate the
template in the translation unit at that time. It's a feature
specifically aimed at compilers to speed up the compilation process.
</P>
<P>Done: Added support for 'extern template class
std::vector&lt;MyClass&gt;;'. Added testcase cpp11_template_explicit.
R11385 , R11386</P>
<H2>Initializer lists [done]</H2>
<P>Initializer list is a new type in standard library:
std::initializer_list&lt;T&gt;. New symbols {} are introduced for the
initializer lists.
</P>
<P>One can now use:
</P>
<PRE> class A {
public:
A( std::initializer_list&lt;int&gt; );
};
A a1 = {1,2,3,4};</PRE><P>
Languages like Java, C# and Python already support direct creation of
lists natively.</P>
<P>Problem: initializer_list cannot be treated as an ordinary list.
The constructor containing initializer_list can only be accessed by
assigning the value using the {} brackets. I also don't think there
is a simple way to convert an ordinary list or a vector to the
initializer_list.</P>
<P>Done: Ignored the constructor having initializer_list as its
argument. Show warning to the user. Added testcase
cpp11_initializer_list. R11450</P>
<P>Article:
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1919.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1919.pdf</A></P>
<H2>Uniform initialization [done]</H2>
<P>The new C++11 standard will allow the following:</P>
<PRE>struct IdString {
std::string name;
int identifier;
};
IdString GetString() {
return {&quot;SomeName&quot;, 4}; //Note the lack of explicit type.
}</PRE><P>
The feature works exactly as it did now for POD types only (eg. int
a[] = {1,2,3};). The following declarations are the same in the new
C++11:</P>
<PRE>IdString str1 = {„SomeName“, 4};
IdString str2{„SomeName“, 4};</PRE><P>
The new way of using uniform initialization allows the following:</P>
<PRE>struct BasicStruct {
int x;
double y;
};
struct AltStruct {
AltStruct(int x, double y) : x_{x}, y_{y} {}
private:
int x_;
double y_;
};
BasicStruct var1{5, 3.2}; // only fills the struct components
AltStruct var2{2, 4.3}; // calls the constructor</PRE><P>
The new syntax is specific to C++. Java, C# and scripting languages
do not support this behaviour, but always need constructors. They
support {} brackets for declaration of arrays as C does + they add
support for creation of arrays on-the-fly (what C++11 introduced with
this feature and more).</P>
<P>Done: Added syntax for {} member initialization in class
constructor. Added testcase cpp11_uniform_initialization. R11413</P>
<H2>Type inference [partially done]</H2>
<P>A new keyword 'auto' is introduced in C++11:</P>
<PRE>auto a1 = 100;
auto a2 = myFunc();</PRE><P>
The type of a1 and a2 is automatically determined according to the
initialization value during the semantic phase of the compiler.</P>
<P>Another macro 'decltype()' is introduced. The macro takes the
concrete object as an argument and returns its type. User could use
this as:</P>
<PRE>int i = 100;
decltype(i) j = 200; // decltype(i) = int</PRE><P STYLE="margin-bottom: 0cm">
Calling operators are allowed as well:</P>
<PRE STYLE="margin-bottom: 0.5cm">decltype(i+j) k = 300;</PRE><P>
Done: Added support for decltype() syntax. Test cases for normal
decltype members and alternate function members work fine. Currently
only syntax in form decltype(variable name) work. No support for
custom expresions eg. decltype(i+j) yet. R11525</P>
<P>TODO: William proposed to support the hidden variables as well
(ones not parsed by Swig and added to symbol table). This also allows
Swig to parse custom expressions like decltype(i+j). The idea is to
introduce a new SwigType for this.</P>
<H2>Range-based for-loop [ignored]</H2>
<P>This feature is always present inside the implementation block
only.
</P>
<H2>Lambda functions and expressions [done]</H2>
<P>C++11 introduces lambda functions defined as:</P>
<PRE STYLE="margin-bottom: 0.5cm">[](int x, int y) -&gt; int { return x + y; }</PRE><P>
If the lambda function contains a single return statement only or the
function doesn't return any type, the return type '-&gt;' can be
omitted. Lambda functions are function objects.</P>
<P>The following example prints the number of items stored in a list:</P>
<PRE>std::vector&lt;int&gt; someList;
int total = 0;
std::for_each( someList.begin(), someList.end(), [&amp;total](int x) {total += x} );
std::cout &lt;&lt; total;</PRE><P>
Parameters inside the [] are the visible parameters of the lambda
functions. These can be &amp; (references), = (copies), variable name
(variable copy), &amp;variable name (variable reference) or this
(copy of the current object).</P>
<P>Lambda functions can be stored using:</P>
<PRE STYLE="margin-bottom: 0.5cm">auto myLambdaFunc = [this]() { this-&gt;SomePrivateMemberFunction() };</PRE><P>
Proposal: Lambda functions are most commonly used inside the function
block to quickly define how the sort, find and similar functions
should work (the other way would be overriding a class – the Java
style). The latest GCC does not support lambda functions yet so it is
difficult to test the feature once implemented. I would implement the
syntax support for this feature, but produce no wrapper code. Lambda
functions still work inside the function block though.</P>
<P>Article:
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf</A></P>
<P>Done: Added syntax support for the lambda functions. Added
testcase cpp11_lambda_functions.i. R11491, R11492</P>
<H2>Alternate function syntax [done]</H2>
<P>The problem with decltype() is that the parameters need to be
defined before the decltype. The following syntax is not valid,
because lhs and rhs hasn't been defined at the time of decltype:</P>
<PRE>template&lt; typename LHS, typename RHS&gt;
decltype(lhs+rhs) AddingFunc(const LHS &amp;lhs, const RHS &amp;rhs) {return lhs + rhs;} //Not legal C++11</PRE><P>
The solution C++11 offers is the combination of the 'auto' keyword
before and '-&gt; rettype' after the function declaration:</P>
<PRE>template&lt; typename LHS, typename RHS&gt;
auto AddingFunc(const LHS &amp;lhs, const RHS &amp;rhs) -&gt; decltype(lhs+rhs) {return lhs + rhs;}</PRE><P>
The new syntax only makes the job for the C++ compilers easier when
parsing such functions. The new syntax can be used for ordinary
functions as well:</P>
<PRE>struct SomeStruct {
auto FuncName(int x, int y) -&gt; int;
};
auto SomeStruct::FuncName(int x, int y) -&gt; int {
return x + y;
}</PRE><P>
Done: Added support for the 'auto' return type. Added support for the
'-&gt; type' after the funtion declaration. Added testcases
cpp11_alternate_function_syntax.i and
cpp11_alternate_function_syntax_runme.py. R11414</P>
<H2>Concepts, Axioms [ignored]</H2>
<P>In C++ there is a common problem when you use a template in the
class which doesn't support all the operations the functions in the
class actually do on the type. Compiler errors are usually very long
and unreadable. C++11 adds support for the &quot;concepts&quot;. The
idea is to define what operations and attributes should the template
have. In contrast to class inheritance and polimorphism, all lookups
are done in compile-time.
</P>
<P>Basic syntax (note LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&amp;id=LessThanComparable">?</A>
instead of &quot;class&quot; or &quot;typename&quot;):
</P>
<PRE> template&lt;LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&amp;id=LessThanComparable">?</A> T&gt;
const T&amp; min(const T &amp;x, const T &amp;y) {
return y &lt; x ? y : x;
}</PRE><P>
Extended syntax (requires conditions are separated with &amp;&amp;,
|| or !):
</P>
<PRE> template&lt; typename T&gt; requires LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&amp;id=LessThanComparable">?</A>&lt;T&gt;
const T&amp; min(const T &amp;x, const T &amp;y) {
return y &lt; x ? y : x;
}</PRE><P>
Definition of the concepts:
</P>
<PRE> concept LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&amp;id=LessThanComparable">?</A>&lt; typename T &gt; {
bool operator&lt;(T,T);
requires GreaterThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&amp;id=GreaterThanComparable">?</A>&lt;T&gt;;
typename value_type;
typename reference;
};</PRE><P>
Concept maps allow usage of a specific type:
</P>
<PRE> template&lt; typename T&gt;
concept_map InputIterator<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&amp;id=InputIterator">?</A>&lt;T*&gt; {
typedef T value_type ;
typedef T&amp; reference ;
typedef T* pointer ;
typedef std::ptrdiff_t difference_type ;
};</PRE><P>
Concept maps can act as mini-types, with function definitions and
other constructs commonly associated with classes:
</P>
<PRE> concept Stack&lt; typename X&gt; {
typename value_type;
void push(X&amp;, const value_type&amp;);
void pop(X&amp;);
value_type top(const X&amp;);
bool empty(const X&amp;);
};
template&lt; typename T&gt;
concept_map Stack&lt;std::vector&lt;T&gt; &gt; {
typedef T value_type;
void push(std::vector&lt;T&gt;&amp; v, const T&amp; x) { v.push_back(x); }
void pop(std::vector&lt;T&gt;&amp; v) { v.pop_back(); }
T top(const std::vector&lt;T&gt;&amp; v) { return v.back(); }
bool empty(const std::vector&lt;T&gt;&amp; v) { return v.empty(); }
};</PRE><P>
Axioms are a facility pertaining to concepts supplied by C++11 to
express the semantic properties of concepts. For example, the concept
Semigroup can be defined with an axiom Associativity as:
</P>
<PRE> concept Semigroup&lt; typename Op, typename T&gt; : CopyConstructible<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&amp;id=CopyConstructible">?</A>&lt;T&gt; {
T operator()(Op, T, T);
axiom Associativity(Op op, T x, T y, T z) {
op(x, op(y, z)) == op(op(x, y), z);
}
};</PRE><P>
Axioms are more like hints to the compiler to speed-up the process of
compilation.
</P>
<P>Ignored: Concepts and axioms were removed from the C++11 standard.
</P>
<H2>Object construction improvement [done]</H2>
<P>This feature allows classes constructors to call other
constructors with different arguments (similar to Java and C#
behaviour).
</P>
<P>The syntax is as follows:
</P>
<PRE> class SomeType {
int number;
public:
SomeType(int newNumber) : number(newNumber) {}
SomeType() : SomeType(42) {}
};</PRE><P>
Also when using the inheritance, the feature introduces inheritance
of all superclass constructors without being defined separately in
the inherited class:
</P>
<PRE> class BaseClass {
public:
BaseClass(int iValue);
};
class DerivedClass: public BaseClass {
public:
using BaseClass::BaseClass; // Adds DerivedClass(int) constructor
};</PRE><P>
Swig already correctly parses and produces the correct wrapper for
the “using” keyword.</P>
<P>Done: Added testcase cpp11_constructors.i which covers both
constructor delegation and constructor inheritance. R11532</P>
<P>Problem: Constructor delegation and constructor inheritance is not
supported by any compiler yet, so it's impossible to try and test
this feature.</P>
<H2>Null pointer constant [done]</H2>
<P>nullptr is part of the standard library.
</P>
<P>It's defined as typedef decltype(nullptr) nullptr_t;
</P>
<P>nullptr_t is defined in &lt;cstddef&gt;.
</P>
<P>As far as the C++ is compatible with 0 as the pointer value, swig
values will work for the C++. And the other way around, nullptr
behaves as the ordinary pointer (false, if empty, true, if not
empty), so it's ok for swig to compare it.</P>
<P>Done: Written a testcase cpp11_null_pointer_constant.i and
cpp11_null_pointer_constant_runme.py to prove the nullptr
functionality. R11484</P>
<H2>Strongly typed enumerations [partially done]</H2>
<P>C++11 introduces a new syntax for strongly typed enum declaration:
</P>
<PRE> enum class Enumeration {
Val1,
Val2,
Val3 = 100,
Val4 /* = 101 */
};</PRE><P>
Typing if (Val4 == 101) will result in compilation error.
</P>
<P>The enum itself can now be explicitely of type int, long, unsigned
int etc.:
</P>
<PRE STYLE="margin-bottom: 0.5cm"> enum class Enum2 : unsigned int {Val1, Val2};</PRE><P>
And it can be forward declared as well:
</P>
<PRE> enum Enum1; //Illegal in C++ and C++11; no size is explicitly specified.
enum Enum2 : unsigned int; //Legal in C++11.
enum class Enum3; //Legal in C++11, because enum class declarations have a default type of &quot;int&quot;.
enum class Enum4: unsigned int; //Legal C++11.
enum Enum2 : unsigned short; //Illegal in C++11, because Enum2 was previously declared with a different type.</PRE><P>
Done: Added syntax 'enum class Name' and forward declarators 'enum
Name : inherited type' or 'enum class Name : inherited type' in
R11449.</P>
<P>TODO: Add semantic support for enum elements not clashing with
enum elements in other enum classes. See cpp11_strongly_typed_enums.i
warnings.</P>
<P>Problem: Swig currently doesn't support nested classes. This
feature should be implemented using a new nested class when using
“enum class” with a single anonymous “enum {elements}”
element inside. For example:</P>
<PRE STYLE="margin-bottom: 0.5cm">class A { enum class EA { a,b,c,d }; };</PRE><P>
should be mapped to</P>
<PRE STYLE="margin-bottom: 0.5cm">class A { class EA { enum {a,b,c,d}; }; };</PRE><H2>
Angle bracket [done]</H2>
<P>Support for right angled brackets was implemented using the
following article as a base:
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html</A>
</P>
<P>Done: Added support for angle brackets. Used the preferred
&quot;Approach 1&quot;. Added a testcase named
cpp11_template_double_brackets. R11245</P>
<H2>Explicit conversion operators [done]</H2>
<P>This is used when converting one type to another (eg. if
(myObject) {}, where myObject is your custom class converted to
bool).
</P>
<P>Requires both operator and function overloading which is not
supported in any target language (eg. python, php).
</P>
<P>Done: Swig already supports the keyword &quot;explicit&quot; for
function types as well. Added test case
cpp11_explicit_conversion_operators. R11323</P>
<H2>Template typedefs [partially done]</H2>
<P>The new C++11 will allow creation of wrapper around the template.
For example, if we want to do this:</P>
<PRE>template&lt; typename first, typename second, int third&gt;
class SomeType;
template&lt; typename second&gt;
typedef SomeType&lt;OtherType, second, 5&gt; TypedefName; //Illegal in C++</PRE><P>
This is still illegal! But we can now use the new syntax for
achieving the same effect:</P>
<PRE>template&lt; typename first, typename second, int third&gt;
class SomeType;
template&lt; typename second&gt;
using TypedefName = SomeType&lt;OtherType, second, 5&gt;;</PRE><P>
Here we created a new wrapper TypedefName taking one template
argument &lt;second&gt; which creates a type SomeType&lt;OtherType,
second, 5&gt;. OtherType and 5 are predefined here and hidden from
the user – the user only uses TypedefName type.</P>
<P>The same goes for the following example:</P>
<PRE>typedef void (*PFD)(double); // Old style
using PF = void (*)(double); // New introduced syntax</PRE><P>
Swig supports parsing typedefs for templates as well for example:</P>
<PRE STYLE="margin-bottom: 0.5cm">typedef List&lt;int&gt; intList;</PRE><P>
Done: Expanded support for the new 'using' syntax and template
aliasing. Added testcase cpp11_template_typedefs. R11533</P>
<P>TODO: Make Swig aware of the newly defined typedef. The TYPEDEF
keyword is part of the storage_class rule and type+declarator (see
c_decl rule) is the right part of the definition – for example void
(*PFD)(double) cannot be transformed to void *(double) easily. To
fully support the new 'using' form, we'll probably have to change the
type, type_right rules and declarator, direct_declarator,
notso_direct_declarator etc., which is PITA.</P>
<H2>Unrestricted unions [done]</H2>
<P>C++ currently offers usage of unions for types with trivial
constructors only. The new C++11 standard allows usage of types with
non-trivial constructors as well:</P>
<PRE> struct point {
point() {}
point(int x, int y): x_(x), y_(y) {}
int x_, y_;
};
union P {
int z;
double w;
point p; // Illegal in C++; point has a non-trivial constructor. However, this is legal in C++11.
} p1;</PRE><P>
Swig already parses the given syntax.</P>
<P>Done: Added testcase cpp11_unrestricted_unions. R11435, R11447</P>
<P>Problem: GCC doesn't support unrestricted unions yet so there is
no way to actually test, if it works.</P>
<H2>Variadic templates [partially done]</H2>
<P>The new C++11 offers the following syntax:</P>
<PRE STYLE="margin-bottom: 0.5cm">template&lt;typename... Values&gt; class tuple;</PRE><P>
This can be used for example:</P>
<PRE STYLE="margin-bottom: 0.5cm">class tuple&lt;int, std::vector&lt;int&gt;, std::map&lt;std::string, std::vector&lt;int&gt;&gt;&gt; someInstanceName;</PRE><P>
The ... is used in two cases. One is in the template header where it
marks on the left the keywords 'typename' or 'class' and a type name
on the right. The second case is usually in the function block to
decompose typename on the left of the ... . For example:</P>
<PRE>void printf(const char *s) {
while (*s) {
if (*s == '%' &amp;&amp; *(++s) != '%')
throw std::runtime_error(&quot;invalid format string: missing arguments&quot;);
std::cout &lt;&lt; *s++;
}
}
template&lt;typename T, typename... Args&gt;
void printf(const char* s, T value, Args... args) { // recursive action – split previous args to value + args
while (*s) {
if (*s == '%' &amp;&amp; *(++s) != '%') {
std::cout &lt;&lt; value;
printf(*s ? ++s : s, args...); // call even when *s == 0 to detect extra arguments
return;
}
std::cout &lt;&lt; *s++;
}
throw std::logic_error(&quot;extra arguments provided to printf&quot;);
}</PRE><P>
The tricky part is that variadic templates can unpack actually
anywhere – including the class inheritance :(</P>
<PRE>template &lt;typename... BaseClasses&gt; class ClassName : public BaseClasses... {
public:
ClassName (BaseClasses&amp;&amp;... baseClasses) : BaseClasses(baseClasses)... {}
}</PRE><P>
A new extension to sizeof is also introduced with this feature. The
... after sizeof returns number of arguments:</P>
<PRE>template&lt;typename ...Args&gt; struct SomeStruct {
static const int size = sizeof...(Args);
}
// SomeStruct&lt;Type1, Type2&gt;::size is 2 and SomeStruct&lt;&gt;::size is 0</PRE><P>
Done: Added syntax support for 'typename' or 'class' + ... + id.
Added testcase cpp11_variadic_templates. R11458</P>
<P>Done: Added syntax support for BaseClass + ..., type + ... + id in
parameters and baseclass + ... for intializers after constructor.
Extended Swig syntax to support sizeof...(Args). R11467</P>
<P>Done: Fixed %template to support variadic number of templates.</P>
<P>TODO: Only (if present) first variadically defined argument is
currently used in %template directive. The next ones are ignored.</P>
<H2>New string literals [partially done]</H2>
<P>Beside the implementation, the new C++11 Unicode and custom
delimeter constants can occur in templates in the header file.
</P>
<P>Done: Added symbols 'u', 'u8' and 'U' to mark the beginning of the
UTF string. Also added test case cpp11_raw_string_literals. R11327</P>
<P>Done: Added R&quot;DELIMITER[, ]DELIMITER&quot; for a custom
delimiter for the beginning/end of the string. R11328</P>
<P>TODO: Fix the Swig's C++ preprocessor bug when parsing an odd
number of “ inside the string brackets. See
Source/Preprocessor/cpp.c.</P>
<H2>User-defined literals [partially done]</H2>
<P>C++ has different suffix literals. eg. 12.5f marks the number 12.5
as float.
</P>
<P>C++11 allows user to define his own suffix for the strings always
starting with the underscore (_). eg. int a = &quot;hello&quot;_mySuffix;
</P>
<P>The syntax is similar to other operator overloading functions:
</P>
<PRE STYLE="margin-bottom: 0.5cm"> OutputType operator &quot;&quot; _mySuffix(const char * string_values);</PRE><P>
The null terminated const char* is the string between the &quot;&quot;.
The _mySuffix is the name of the suffix operator. And the OutputType
is the outputType the operator returns.
</P>
<P>Other forms are:
</P>
<PRE> OutputType operator &quot;&quot; _mySuffix(const char * string_values, size_t num_chars);
OutputType operator &quot;&quot; _mySuffix(const wchar_t * string_values, size_t num_chars);
OutputType operator &quot;&quot; _mySuffix(const char16_t * string_values, size_t num_chars);
OutputType operator &quot;&quot; _mySuffix(const char32_t * string_values, size_t num_chars);
OutputType operator &quot;&quot; _mySuffix(int value); /* cooked version - ie. atoi() of string */</PRE><P>
Another possibility is to use variadic templates:
</P>
<PRE> template&lt;char...&gt; OutputType operator &quot;&quot; _mySuffix();
OutputType someVariable = &quot;1234&quot;_mySuffix;</PRE><P>
This instantiates the literal processing function as
operator&quot;&quot;_Suffix&lt;'1', '2', '3', '4'&gt;. In this form,
there is no terminating null character to the string. The main
purpose to doing this is to use C++11's constexpr keyword and the
compiler to allow the literal to be transformed entirely at compile
time, assuming OutputType is a constexpr-constructable and copyable
type, and the literal processing function is a constexpr function.</P>
<P>Article:
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf</A></P>
<P>Done: Added syntax support for userdefined literals. Added
testcase cpp11_userdefined_literals.i. R11494</P>
<P>TODO: %rename doesn't parse operator”” yet.</P>
<H2>Thread-local storage [done]
</H2>
<P>New C++11 introduces keyword &quot;thread_local&quot; which marks
the following variable dynamically located depending on the current
thread when using the address-of (&amp;) operator.
</P>
<P>Syntax:
</P>
<PRE> struct A {
thread_local int val;
};</PRE><P>
Done: Add &quot;thread_local&quot; keyword to Swig. Added testcase
cpp11_thread_local. R11393</P>
<H2>Defaulting/deleting of standard functions on C++ objects [done]</H2>
<P>C++ automatically creates default constructor with empty
parameters, copy constructor, operator= and destructor for any class.
Sometimes user wants to explicitly remove one of them or enable them
(eg. default constructor with empty parameters doesn't work any more,
if any other constructor is defined).
</P>
<P>Words &quot;default&quot; and &quot;delete&quot; are introduced.
The syntax is similar to declaration of pure virtual function:
</P>
<PRE> struct NonCopyable {
NonCopyable &amp; operator=(const NonCopyable&amp;) = delete; /* Removes operator= */
NonCopyable(const NonCopyable&amp;) = delete; /* Removed copy constructor */
NonCopyable() = default; /* Explicitly allows the empty constructor */
void *operator new(std::size_t) = delete; /* Removes new NonCopyable */
};</PRE><P>
User has the ability by using keyword delete to disallow calling of
the standard functions brought by C++ itself.
</P>
<PRE> struct A1 {
void f(int i);
void f(double i) = delete; /* Don't cast double to int. Compiler returns an error */
};
struct A2 {
void f(int i);
template&lt;class T&gt; void f(T) = delete; /* Only accept int */
};</PRE><P>
Ignored: Swig already parses the keywords &quot;= delete&quot; and &quot;=
default&quot;. These keywords are used for built-in functions (copy
constructor, operator= etc.), which are ignored by Swig anyway.</P>
<P>Done: Added testcase cpp11_default_delete. R11535</P>
<H2>Type long long int [done]</H2>
<P>Type long long int is an integer type that has at least 64 useful
bits. C99 added it to its standard, but the C++ didn't adopt it until
C++11. Most C++ compilers supported it though.
</P>
<P>Done: Swig already parses the C code including the long long type.
</P>
<H2>Static assertions [done]</H2>
<P>static_assert() can be used at class scope as well eg.:
</P>
<PRE> template &lt;typename T&gt;
struct Check {
static_assert(sizeof(int) &lt;= sizeof(T), &quot;not big enough&quot;);
};</PRE><P>
Done: Added syntax support for &quot;static_assert()&quot;. Added
test case cpp11_static_assert. R11369</P>
<H2>Allow sizeof to work on members of classes without an explicit
object [done]</H2>
<P>C++11 allows calls of sizeof to concrete objects as well:
</P>
<PRE> struct A { int member; };
sizeof(A::member); //Does not work with C++03. Okay with C++11</PRE><P>
This kind of syntax is already supported by Swig.</P>
<P>Done: Added testcase cpp11_sizeof_objects. R11538
</P>
<H2>Threading facilities [ignored]</H2>
<P>C++11 will add the following classes to the standard library:
</P>
<PRE> * std::thread
* std::mutex, std::recursive_mutex
* std::condition_variable, std::condition_variable_any
* std::lock_guard, std::unique_lock
* std::packaged_task</PRE><P>
Ignored: No changes to the language itself is made.
</P>
<H2>Tuple types [TODO]</H2>
<P>Tuple is array of various types. C++11 introduced this feature
using variadic templates. Tuple is defined as:</P>
<PRE STYLE="margin-bottom: 0.5cm">template &lt;class ...Types&gt; class tuple;</PRE><P>
Constructor is automatically generated filling the tuple elements.
get&lt;X&gt; function is introduced to get the Xth element in the
tuple.</P>
<PRE>typedef tuple&lt; int, double, long &amp;, const char * &gt; test_tuple ;
long lengthy = 12 ;
test_tuple proof( 18, 6.5, lengthy, &quot;Ciao!&quot; ) ;
lengthy = get&lt;0&gt;(proof) ; // Assign to 'lengthy' the value 18.
get&lt;3&gt;(proof) = &quot; Beautiful!&quot; ; // Modify the tuple’s fourth element.</PRE><P>
Tuples can be copied to each other, if all the elements are copiable:</P>
<PRE>typedef tuple&lt; int , double, string &gt; tuple_1 t1 ;
typedef tuple&lt; char, short , const char * &gt; tuple_2 t2( 'X', 2, &quot;Hola!&quot; ) ;
t1 = t2 ; // Ok, first two elements can be converted,
// the third one can be constructed from a 'const char *'.</PRE><P>
TODO: Implement wrappers for the tuplet&lt;&gt; class.</P>
<H2>Hash tables [TODO]</H2>
<P>C++11 introduces the &quot;unordered&quot; version of existing
types, which in practice work faster than the linear types:
</P>
<PRE> - unordered set
- unordered multiset
- unordered map
- unordered multimap</PRE><P>
Swig should use the &quot;unordered&quot; types exactly the same as
the original linear types.</P>
<P>Problem: Unordered types do not contain exactly same members as
ordered ones (eg. _Hashtable_iterator does not offer operator--() and
constructor with compare function which is required). So simply
aliasing unordered classes to ordered ones doesn't work.</P>
<P>TODO: Implement wrappers for unordered_ types. Initial work is
already done in Lib/std/unordered_*.i files.</P>
<H2>Regular expressions [ignored]</H2>
<P>Two new classes are introduced in C++11: basic_regex and
match_results. Both are defined in regex header file.
</P>
<P>Ignored: The new feature extends the standardy library only. No
changes to Swig needed.
</P>
<H2>General-purpose smart pointers [done]</H2>
<P>This feature deprecates auto_ptr and adds shared_ptr, weak_ptr and
unique_ptr to the standard library.
</P>
<P>This feature only adds the smart pointers to the standard library
and doesn't effect the C++ syntax.</P>
<P>Done: Added test case which uses all three smart pointers in the
class. R11394</P>
<P>Problem: GCC standard library doesn't contain the new smart
pointers yet.
</P>
<H2>Extensible random number facility [ignored]</H2>
<P>This feature standardize the pseudo random number algorithm
(currently, the random number generator was dependent on the
platform/compiler). It adds functions linear_congruential,
subtract_with_carry and mersenne_twister and symbols
uniform_int_distribution, bernoulli_distribution,
geometric_distribution, poisson_distribution, binomial_distribution,
uniform_real_distribution, exponential_distribution,
normal_distribution and gamma_distribution to the standard library.
</P>
<P>Ignored: The new feature extends the standardy library only. No
changes to Swig needed.
</P>
<H2>Wrapper reference [ignored]</H2>
<P>This feature adds ref and cref classes to the standard library
(#include &lt;utility&gt;) usually used in tempalte functions.
</P>
<P>Ignored: The new feature extends the standardy library only. No
changes to Swig needed.
</P>
<H2>Polymorphous wrappers for function objects [done]</H2>
<P>Two features are introduced:
</P>
<UL>
<LI><P>The function template wrapper:
</P>
</UL>
<PRE STYLE="margin-bottom: 0.5cm"> function&lt;int ( int, int )&gt; pF;</PRE>
<UL>
<LI><P>and the function object:
</P>
</UL>
<PRE> struct Test {
bool operator()( short x, short y );
};</PRE><P>
Swig already supports the two.</P>
<P>Done: Added a runtime testcase for function objects
cpp11_function_objects. R11419.</P>
<H2>Type traits for metaprogramming [ignored]</H2>
<P>C++11 adds a new header file &lt;type_traits&gt; which includes
helper functions to determine the template type while initializing
the object at compile time.
</P>
<P>Swig already supports the following code:
</P>
<PRE> template&lt; int B, int N &gt;
struct Pow {
// recursive call and recombination.
enum{ value = B*Pow&lt; B, N-1 &gt;::value };
};
template&lt; int B &gt; struct Pow&lt; B, 0 &gt; // <EM>N == 0</EM> condition of termination.
{
enum{ value = 1 };
};
int quartic_of_three = Pow&lt; 3, 4 &gt;::value ;</PRE><P>
Functions is_convertible, is_integral, is_integral_const etc. are
part of the new header:
</P>
<PRE>// First way of operating.
template&lt; bool B &gt; struct algorithm {
template&lt; class T1, class T2 &gt; int do_it( T1 &amp;, T2 &amp; ) { /*...*/ }
};
// Second way of operating.
template&lt;&gt; struct algorithm&lt;true&gt; {
template&lt; class T1, class T2 &gt; int do_it( T1, T2 ) { /*...*/ }
};
// Instantiating 'elaborate' will automatically instantiate the correct way to operate.
template&lt; class T1, class T2 &gt; int elaborate( T1 A, T2 B ) {
// Use the second way only if 'T1' is an integer and if 'T2' is
// in floating point, otherwise use the first way.
return algorithm&lt; is_integral&lt;T1&gt;::value &amp;&amp; is_floating_point&lt;T2&gt;::value &gt;::do_it( A, B );
}</PRE><P>
Swig correctly parses the syntax for template&lt;bool&gt;,
template&lt;class T&gt; and template&lt;&gt;.
</P>
<P>Ignored: Swig requires explicitly defined template class
(%template directive) to export it to the target language.</P>
<H2>Uniform method for computing return type of function objects
[partially done]</H2>
<P>The template function is introduced: std::result_of() which
depends on decltype:
</P>
<PRE>template&lt; class Obj &gt;
class calculus_ver2 {
public:
template&lt; class Arg &gt;
typename std::result_of&lt;Obj(Arg)&gt;::type operator()( Arg&amp; a ) const {
return member(a);
}
private:
Obj member;
};</PRE><P>
Swig correctly parses the result_of class.</P>
<P>TODO: The return type (the result_of::type member) is not
calculated by Swig. This needs a much more complex semantic parser.</P>
<P>Done: Added testcase cpp11_result_of. R11534</P>
</BODY>
</HTML>

4
Doc/Devel/internals.html
View file

@ -347,7 +347,7 @@ Delete(a); /* Destroy a */
All objects are referenced counted and given a reference count of 1 when initially created. The
<tt>Delete()</tt> function only destroys an object when the reference count reaches zero. When
an object is placed in a list or hash table, it's reference count is automatically increased. For example:
an object is placed in a list or hash table, its reference count is automatically increased. For example:
<blockquote>
<pre>
@ -844,7 +844,7 @@ Returns a type object corresponding to the type string produced by the Swig_cloc
<li><tt>char *Swig_clocal_deref(DataType *t, char *name)</tt><br>
This function is the inverse of the <tt>clocal()</tt> function. Given a type and a name,
it produces a string containing the code needed to cast/convert the type produced by
<tt>Swig_clocal()</tt> back into it's original type.
<tt>Swig_clocal()</tt> back into its original type.
<p>
<li><tt>char *Swig_clocal_assign(DataType *t, char *name)</tt><br>

2
Doc/Devel/tree.html
View file

@ -185,7 +185,7 @@ this function merely records that those attributes did not exist in the original
<blockquote>
This function is similar to <tt>Swig_save()</tt> except that adds additional attribute checking. There are different interpretations
of the attribute names. A name of "attr" merely requests that the function check for the presence of an attribute. If the attribute is missing, SWIG will exit with a failed assertion. An attribute name of "?attr" specifies that the attribute "attr" is optional and
that it's old value must be saved (if any). An attribute name of "*attr" specifies that the attribute is required and that
that its old value must be saved (if any). An attribute name of "*attr" specifies that the attribute is required and that
its value must be saved. The saving of attributes is performed in the same manner as with <tt>Swig_save()</tt>. Here is an example:
<pre>

126
Doc/Manual/Allegrocl.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Allegrocl"></a>17 SWIG and Allegro Common Lisp</H1>
<H1><a name="Allegrocl"></a>18 SWIG and Allegro Common Lisp</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -135,10 +135,10 @@ be unhappy to see some enterprising folk use this work to add
to it.
</p>
<H2><a name="Allegrocl_nn2"></a>17.1 Basics</H2>
<H2><a name="Allegrocl_nn2"></a>18.1 Basics</H2>
<H3><a name="Allegrocl_nn3"></a>17.1.1 Running SWIG</H3>
<H3><a name="Allegrocl_nn3"></a>18.1.1 Running SWIG</H3>
<p>
@ -360,7 +360,7 @@ need to link in the Allegro shared library. The library you create from
the C++ wrapper will be what you then load into Allegro CL.
</p>
<H3><a name="Allegrocl_nn4"></a>17.1.2 Command Line Options</H3>
<H3><a name="Allegrocl_nn4"></a>18.1.2 Command Line Options</H3>
<p>
@ -396,7 +396,7 @@ See <a href="#Allegrocl_nn47">Section 17.5 Identifier converter
functions</a> for more details.
</p>
<H3><a name="Allegrocl_nn5"></a>17.1.3 Inserting user code into generated files</H3>
<H3><a name="Allegrocl_nn5"></a>18.1.3 Inserting user code into generated files</H3>
<p>
@ -436,7 +436,7 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
</p>
<H2><a name="Allegrocl_nn6"></a>17.2 Wrapping Overview</H2>
<H2><a name="Allegrocl_nn6"></a>18.2 Wrapping Overview</H2>
<p>
@ -446,7 +446,7 @@ New users to SWIG are encouraged to read
interested in generating an interface to C++.
</p>
<H3><a name="Allegrocl_nn7"></a>17.2.1 Function Wrapping</H3>
<H3><a name="Allegrocl_nn7"></a>18.2.1 Function Wrapping</H3>
<p>
@ -499,7 +499,7 @@ interested in generating an interface to C++.
</pre>
</div>
<H3><a name="Allegrocl_nn8"></a>17.2.2 Foreign Wrappers</H3>
<H3><a name="Allegrocl_nn8"></a>18.2.2 Foreign Wrappers</H3>
<p>
@ -512,7 +512,7 @@ interested in generating an interface to C++.
typemap.
</p>
<H3><a name="Allegrocl_nn9"></a>17.2.3 FFI Wrappers</H3>
<H3><a name="Allegrocl_nn9"></a>18.2.3 FFI Wrappers</H3>
<p>
@ -593,7 +593,7 @@ char *xxx();
ff:def-foreign-call's.
</p>
<H3><a name="Allegrocl_nn10"></a>17.2.4 Non-overloaded Defuns</H3>
<H3><a name="Allegrocl_nn10"></a>18.2.4 Non-overloaded Defuns</H3>
<p>
@ -606,7 +606,7 @@ char *xxx();
this function can be manipulated via the <tt>lout</tt> typemap.
</p>
<H3><a name="Allegrocl_nn11"></a>17.2.5 Overloaded Defuns</H3>
<H3><a name="Allegrocl_nn11"></a>18.2.5 Overloaded Defuns</H3>
<p>
@ -622,7 +622,7 @@ char *xxx();
can be manipulated via the <tt>lout</tt> typemap.
</p>
<H3><a name="Allegrocl_nn12"></a>17.2.6 What about constant and variable access?</H3>
<H3><a name="Allegrocl_nn12"></a>18.2.6 What about constant and variable access?</H3>
<p>
@ -635,7 +635,7 @@ char *xxx();
into the foreign module.
</p>
<H3><a name="Allegrocl_nn13"></a>17.2.7 Object Wrapping</H3>
<H3><a name="Allegrocl_nn13"></a>18.2.7 Object Wrapping</H3>
<p>
@ -657,7 +657,7 @@ char *xxx();
foreign function interface.
</p>
<H2><a name="Allegrocl_nn14"></a>17.3 Wrapping Details</H2>
<H2><a name="Allegrocl_nn14"></a>18.3 Wrapping Details</H2>
<p>
@ -665,7 +665,7 @@ char *xxx();
translated into lisp.
</p>
<H3><a name="Allegrocl_nn15"></a>17.3.1 Namespaces</H3>
<H3><a name="Allegrocl_nn15"></a>18.3.1 Namespaces</H3>
<p>
@ -742,13 +742,13 @@ namespace car {
function such as <tt>(car '(1 2 3)</tt>.
</p>
<H3><a name="Allegrocl_nn16"></a>17.3.2 Constants</H3>
<H3><a name="Allegrocl_nn16"></a>18.3.2 Constants</H3>
<p>
Constants, as declared by the preprocessor #define macro or SWIG
<tt>%constant</tt> directive, are included in SWIGs parse tree
<tt>%constant</tt> directive, are included in SWIG's parse tree
when it can be determined that they are, or could be reduced to,
a literal value. Such values are translated into defconstant
forms in the generated lisp wrapper when the -nocwrap command-line
@ -803,7 +803,7 @@ namespace car {
not use the <tt>-nocwrap</tt> command-line option.
</p>
<H3><a name="Allegrocl_nn17"></a>17.3.3 Variables</H3>
<H3><a name="Allegrocl_nn17"></a>18.3.3 Variables</H3>
<p>
@ -881,13 +881,13 @@ globalvar&gt; (globalvar.nnn::glob_float)
</pre>
</div>
<H3><a name="Allegrocl_nn18"></a>17.3.4 Enumerations</H3>
<H3><a name="Allegrocl_nn18"></a>18.3.4 Enumerations</H3>
<p>
In C, an enumeration value is an integer value, while in C++ an
enumeration value is implicitly convertible to an integer value,
but can also be distinguished by it's enum type. For each enum
but can also be distinguished by its enum type. For each enum
declaration a def-foreign-type is generated, assigning the enum
a default type of :int. Users may adjust the foreign type of
enums via SWIG <tt>typemaps</tt>.
@ -901,7 +901,7 @@ globalvar&gt; (globalvar.nnn::glob_float)
of it not being necessary to probe into foreign space to retrieve enum
values. When generating a .cxx wrapper file, a more general solution is
employed. A wrapper variable is created in the module_wrap.cxx file, and
a ff:def-foreign-variable call is generated to retrieve it's value into lisp.
a ff:def-foreign-variable call is generated to retrieve its value into lisp.
</p>
<p>For example, the following header file
@ -957,7 +957,7 @@ EXPORT const int ACL_ENUM___FOO3__SWIG_0 = FOO3;
</pre>
</div>
<H3><a name="Allegrocl_nn19"></a>17.3.5 Arrays</H3>
<H3><a name="Allegrocl_nn19"></a>18.3.5 Arrays</H3>
<p>
@ -1105,10 +1105,10 @@ namespace BAR {
</pre>
</div>
<H3><a name="Allegrocl_nn20"></a>17.3.6 Classes and Structs and Unions (oh my!)</H3>
<H3><a name="Allegrocl_nn20"></a>18.3.6 Classes and Structs and Unions (oh my!)</H3>
<H4><a name="Allegrocl_nn21"></a>17.3.6.1 CLOS wrapping of</H4>
<H4><a name="Allegrocl_nn21"></a>18.3.6.1 CLOS wrapping of</H4>
<p>
@ -1123,7 +1123,7 @@ namespace BAR {
integer values.
</p>
<H4><a name="Allegrocl_nn22"></a>17.3.6.2 CLOS Inheritance</H4>
<H4><a name="Allegrocl_nn22"></a>18.3.6.2 CLOS Inheritance</H4>
<p>
@ -1131,12 +1131,12 @@ namespace BAR {
inheritance of the classes in foreign code, with the
ff:foreign-pointer class at its root. ff:foreign-pointer is a thin
wrapper for pointers that is made available by the foreign function
interface. It's key benefit is that it may be passed as an argument
interface. Its key benefit is that it may be passed as an argument
to any ff:def-foreign-call that is expecting a pointer as the
parameter.
</p>
<H4><a name="Allegrocl_nn23"></a>17.3.6.3 Member fields and functions</H4>
<H4><a name="Allegrocl_nn23"></a>18.3.6.3 Member fields and functions</H4>
<p>
@ -1152,7 +1152,7 @@ namespace BAR {
the interface does nothing for <tt>friend</tt> directives,
</p>
<H4><a name="Allegrocl_nn24"></a>17.3.6.4 Why not directly access C++ classes using foreign types?</H4>
<H4><a name="Allegrocl_nn24"></a>18.3.6.4 Why not directly access C++ classes using foreign types?</H4>
<p>
@ -1170,11 +1170,11 @@ namespace BAR {
use the more robust wrapper functions.
</p>
<H3><a name="Allegrocl_nn25"></a>17.3.7 Templates</H3>
<H3><a name="Allegrocl_nn25"></a>18.3.7 Templates</H3>
<H4><a name="Allegrocl_nn26"></a>17.3.7.1 Generating wrapper code for templates</H4>
<H4><a name="Allegrocl_nn26"></a>18.3.7.1 Generating wrapper code for templates</H4>
<p>
@ -1187,7 +1187,7 @@ namespace BAR {
directive.
</p>
<H4><a name="Allegrocl_nn27"></a>17.3.7.2 Implicit Template instantiation</H4>
<H4><a name="Allegrocl_nn27"></a>18.3.7.2 Implicit Template instantiation</H4>
<p>
@ -1197,7 +1197,7 @@ namespace BAR {
class schema.
</p>
<H3><a name="Allegrocl_nn28"></a>17.3.8 Typedef, Templates, and Synonym Types</H3>
<H3><a name="Allegrocl_nn28"></a>18.3.8 Typedef, Templates, and Synonym Types</H3>
<p>
@ -1277,7 +1277,7 @@ synonym&gt;
</pre>
</div>
<H4><a name="Allegrocl_nn29"></a>17.3.8.1 Choosing a primary type</H4>
<H4><a name="Allegrocl_nn29"></a>18.3.8.1 Choosing a primary type</H4>
<p>
@ -1298,7 +1298,7 @@ synonym&gt;
</li>
</ul>
<H3><a name="Allegrocl_nn30"></a>17.3.9 Function overloading/Parameter defaulting</H3>
<H3><a name="Allegrocl_nn30"></a>18.3.9 Function overloading/Parameter defaulting</H3>
<p>
@ -1461,7 +1461,7 @@ overload&gt;
</pre>
</div>
<H3><a name="Allegrocl_nn31"></a>17.3.10 Operator wrapping and Operator overloading</H3>
<H3><a name="Allegrocl_nn31"></a>18.3.10 Operator wrapping and Operator overloading</H3>
<p>
@ -1607,7 +1607,7 @@ opoverload&gt;
</pre>
</div>
<H3><a name="Allegrocl_nn32"></a>17.3.11 Varargs</H3>
<H3><a name="Allegrocl_nn32"></a>18.3.11 Varargs</H3>
<p>
@ -1617,7 +1617,7 @@ opoverload&gt;
directive. This directive allows you to specify a (finite)
argument list which will be inserted into the wrapper in place
of the variable length argument indicator. As an example,
consider the function <tt>printf()</tt>. It's declaration would
consider the function <tt>printf()</tt>. Its declaration would
appear as follows:
</p>
@ -1628,7 +1628,7 @@ opoverload&gt;
with other ways such functions can be wrapped.
</p>
<H3><a name="Allegrocl_nn33"></a>17.3.12 C++ Exceptions</H3>
<H3><a name="Allegrocl_nn33"></a>18.3.12 C++ Exceptions</H3>
<p>
@ -1640,7 +1640,7 @@ opoverload&gt;
implemented.
</p>
<H3><a name="Allegrocl_nn34"></a>17.3.13 Pass by value, pass by reference</H3>
<H3><a name="Allegrocl_nn34"></a>18.3.13 Pass by value, pass by reference</H3>
<p>
@ -1652,7 +1652,7 @@ opoverload&gt;
newly defined types.
</p>
<H2><a name="Allegrocl_nn35"></a>17.4 Typemaps</H2>
<H2><a name="Allegrocl_nn35"></a>18.4 Typemaps</H2>
<p>
@ -1663,7 +1663,7 @@ opoverload&gt;
on <a href="Typemaps.html#Typemaps">Typemaps</a> for more information.
</p>
<H3><a name="Allegrocl_nn36"></a>17.4.1 Code Generation in the C++ Wrapper</H3>
<H3><a name="Allegrocl_nn36"></a>18.4.1 Code Generation in the C++ Wrapper</H3>
@ -1693,7 +1693,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn37"></a>17.4.1.1 IN Typemap</H4>
<H4><a name="Allegrocl_nn37"></a>18.4.1.1 IN Typemap</H4>
<p>
@ -1728,14 +1728,14 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn38"></a>17.4.1.2 OUT Typemap</H4>
<H4><a name="Allegrocl_nn38"></a>18.4.1.2 OUT Typemap</H4>
<p>
The <tt>out</tt> typemap is used to generate code to form the
return value of the wrapper from the return value of the wrapped
function. This code is placed in the &lt;convert and bind result to lresult&gt;
section of the above code diagram. It's default mapping is as follows:
section of the above code diagram. Its default mapping is as follows:
</p>
<div class="code">
@ -1752,13 +1752,13 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn39"></a>17.4.1.3 CTYPE Typemap</H4>
<H4><a name="Allegrocl_nn39"></a>18.4.1.3 CTYPE Typemap</H4>
<p>
This typemap is not used for code generation, but purely for the
transformation of types in the parameter list of the wrapper function.
It's primary use is to handle by-value to by-reference conversion in the
Its primary use is to handle by-value to by-reference conversion in the
wrappers parameter list. Its default settings are:
</p>
@ -1784,7 +1784,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
these <a href="Typemaps.html#Typemaps_nn25">common typemaps</a> here.
</p>
<H3><a name="Allegrocl_nn40"></a>17.4.2 Code generation in Lisp wrappers</H3>
<H3><a name="Allegrocl_nn40"></a>18.4.2 Code generation in Lisp wrappers</H3>
<p>
@ -1803,7 +1803,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
<a href="#Allegrocl_nn15">16.3.1 Namespaces</a> for details.
</p>
<H4><a name="Allegrocl_nn41"></a>17.4.2.1 LIN Typemap</H4>
<H4><a name="Allegrocl_nn41"></a>18.4.2.1 LIN Typemap</H4>
<p>
@ -1846,7 +1846,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn42"></a>17.4.2.2 LOUT Typemap</H4>
<H4><a name="Allegrocl_nn42"></a>18.4.2.2 LOUT Typemap</H4>
<p>
@ -1889,7 +1889,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn43"></a>17.4.2.3 FFITYPE Typemap</H4>
<H4><a name="Allegrocl_nn43"></a>18.4.2.3 FFITYPE Typemap</H4>
@ -1939,7 +1939,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn44"></a>17.4.2.4 LISPTYPE Typemap</H4>
<H4><a name="Allegrocl_nn44"></a>18.4.2.4 LISPTYPE Typemap</H4>
<p>
@ -1959,7 +1959,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn45"></a>17.4.2.5 LISPCLASS Typemap</H4>
<H4><a name="Allegrocl_nn45"></a>18.4.2.5 LISPCLASS Typemap</H4>
<p>
@ -1983,7 +1983,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H3><a name="Allegrocl_nn46"></a>17.4.3 Modifying SWIG behavior using typemaps</H3>
<H3><a name="Allegrocl_nn46"></a>18.4.3 Modifying SWIG behavior using typemaps</H3>
<p>
@ -2017,10 +2017,10 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H2><a name="Allegrocl_nn47"></a>17.5 Identifier Converter functions</H2>
<H2><a name="Allegrocl_nn47"></a>18.5 Identifier Converter functions</H2>
<H3><a name="Allegrocl_nn48"></a>17.5.1 Creating symbols in the lisp environment</H3>
<H3><a name="Allegrocl_nn48"></a>18.5.1 Creating symbols in the lisp environment</H3>
<p>
@ -2041,11 +2041,11 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
of arguments.
</p>
<H3><a name="Allegrocl_nn49"></a>17.5.2 Existing identifier-converter functions</H3>
<H3><a name="Allegrocl_nn49"></a>18.5.2 Existing identifier-converter functions</H3>
<p>Two basic identifier routines have been defined.
<H4><a name="Allegrocl_nn50"></a>17.5.2.1 identifier-convert-null</H4>
<H4><a name="Allegrocl_nn50"></a>18.5.2.1 identifier-convert-null</H4>
<p>
@ -2054,7 +2054,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
strings, from which a symbol will be created.
</p>
<H4><a name="Allegrocl_nn51"></a>17.5.2.2 identifier-convert-lispify</H4>
<H4><a name="Allegrocl_nn51"></a>18.5.2.2 identifier-convert-lispify</H4>
<p>
@ -2063,7 +2063,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
same symbol transformations.
</p>
<H4><a name="Allegrocl_nn52"></a>17.5.2.3 Default identifier to symbol conversions</H4>
<H4><a name="Allegrocl_nn52"></a>18.5.2.3 Default identifier to symbol conversions</H4>
<p>
@ -2072,7 +2072,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
default naming conventions.
</p>
<H3><a name="Allegrocl_nn53"></a>17.5.3 Defining your own identifier-converter</H3>
<H3><a name="Allegrocl_nn53"></a>18.5.3 Defining your own identifier-converter</H3>
<p>
@ -2093,7 +2093,7 @@ foreign environment.
<p>
The :type keyword argument provides more information on the type of
identifier. It's value is a symbol. This allows the
identifier. Its value is a symbol. This allows the
identifier-converter to apply different heuristics when mapping
different types of identifiers to symbols. SWIG will generate calls
to your identifier-converter using the following types.
@ -2123,12 +2123,12 @@ scope in the specified class.
<p>
The :arity keyword argument only appears in swig:swig-defmethod forms
generated for overloaded functions. It's value is an integer
generated for overloaded functions. Its value is an integer
indicating the number of arguments passed to the routine indicated by
this identifier.
</p>
<H3><a name="Allegrocl_nn54"></a>17.5.4 Instructing SWIG to use a particular identifier-converter</H3>
<H3><a name="Allegrocl_nn54"></a>18.5.4 Instructing SWIG to use a particular identifier-converter</H3>
<p>

42
Doc/Manual/Android.html
View file

@ -5,7 +5,7 @@
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body bgcolor="#FFFFFF">
<H1><a name="Android"></a>18 SWIG and Android</H1>
<H1><a name="Android"></a>19 SWIG and Android</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -30,7 +30,7 @@ This chapter describes SWIG's support of Android.
<H2><a name="Android_overview"></a>18.1 Overview</H2>
<H2><a name="Android_overview"></a>19.1 Overview</H2>
<p>
@ -40,10 +40,10 @@ Everything in the <a href="Java.html">Java chapter</a> applies to generating cod
This chapter contains a few Android specific notes and examples.
</p>
<H2><a name="Android_examples"></a>18.2 Android examples</H2>
<H2><a name="Android_examples"></a>19.2 Android examples</H2>
<H3><a name="Android_examples_intro"></a>18.2.1 Examples introduction</H3>
<H3><a name="Android_examples_intro"></a>19.2.1 Examples introduction</H3>
<p>
@ -76,7 +76,7 @@ $ android list targets
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>
<H3><a name="Android_example_simple"></a>19.2.2 Simple C example</H3>
<p>
@ -398,7 +398,7 @@ Run the app again and this time you will see the output pictured below, showing
<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>
<H3><a name="Android_example_class"></a>19.2.3 C++ class example</H3>
<p>
@ -435,11 +435,11 @@ public:
}
virtual ~Shape() {
nshapes--;
};
}
double x, y;
void move(double dx, double dy);
virtual double area(void) = 0;
virtual double perimeter(void) = 0;
virtual double area() = 0;
virtual double perimeter() = 0;
static int nshapes;
};
@ -447,18 +447,18 @@ class Circle : public Shape {
private:
double radius;
public:
Circle(double r) : radius(r) { };
virtual double area(void);
virtual double perimeter(void);
Circle(double r) : radius(r) { }
virtual double area();
virtual double perimeter();
};
class Square : public Shape {
private:
double width;
public:
Square(double w) : width(w) { };
virtual double area(void);
virtual double perimeter(void);
Square(double w) : width(w) { }
virtual double area();
virtual double perimeter();
};
</pre>
</div>
@ -482,19 +482,19 @@ void Shape::move(double dx, double dy) {
int Shape::nshapes = 0;
double Circle::area(void) {
double Circle::area() {
return M_PI*radius*radius;
}
double Circle::perimeter(void) {
double Circle::perimeter() {
return 2*M_PI*radius;
}
double Square::area(void) {
double Square::area() {
return width*width;
}
double Square::perimeter(void) {
double Square::perimeter() {
return 4*width;
}
</pre>
@ -746,7 +746,7 @@ Run the app to see the result of calling the C++ code from Java:
<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>
<H3><a name="Android_examples_other"></a>19.2.4 Other examples</H3>
<p>
@ -758,7 +758,7 @@ 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>
<H2><a name="Android_stl"></a>19.3 C++ STL</H2>
<p>

22
Doc/Manual/Arguments.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Arguments"></a>9 Argument Handling</H1>
<H1><a name="Arguments"></a>10 Argument Handling</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -42,7 +42,7 @@ return multiple values through the arguments of a function. This chapter
describes some of the techniques for doing this.
</p>
<H2><a name="Arguments_nn2"></a>9.1 The typemaps.i library</H2>
<H2><a name="Arguments_nn2"></a>10.1 The typemaps.i library</H2>
<p>
@ -50,7 +50,7 @@ This section describes the <tt>typemaps.i</tt> library file--commonly used to
change certain properties of argument conversion.
</p>
<H3><a name="Arguments_nn3"></a>9.1.1 Introduction</H3>
<H3><a name="Arguments_nn3"></a>10.1.1 Introduction</H3>
<p>
@ -194,7 +194,7 @@ else. To clear a typemap, the <tt>%clear</tt> directive should be used. For e
</pre>
</div>
<H3><a name="Arguments_nn4"></a>9.1.2 Input parameters</H3>
<H3><a name="Arguments_nn4"></a>10.1.2 Input parameters</H3>
<p>
@ -247,7 +247,7 @@ When the function is used in the scripting language interpreter, it will work li
result = add(3,4)
</pre></div>
<H3><a name="Arguments_nn5"></a>9.1.3 Output parameters</H3>
<H3><a name="Arguments_nn5"></a>10.1.3 Output parameters</H3>
<p>
@ -314,7 +314,7 @@ iresult, dresult = foo(3.5, 2)
</pre>
</div>
<H3><a name="Arguments_nn6"></a>9.1.4 Input/Output parameters</H3>
<H3><a name="Arguments_nn6"></a>10.1.4 Input/Output parameters</H3>
<p>
@ -379,7 +379,7 @@ rather than directly overwriting the value of the original input object.
SWIG. Backwards compatibility is preserved, but deprecated.
</p>
<H3><a name="Arguments_nn7"></a>9.1.5 Using different names</H3>
<H3><a name="Arguments_nn7"></a>10.1.5 Using different names</H3>
<p>
@ -413,7 +413,7 @@ Typemap declarations are lexically scoped so a typemap takes effect from the poi
file or a matching <tt>%clear</tt> declaration.
</p>
<H2><a name="Arguments_nn8"></a>9.2 Applying constraints to input values</H2>
<H2><a name="Arguments_nn8"></a>10.2 Applying constraints to input values</H2>
<p>
@ -423,7 +423,7 @@ insure that a value is positive, or that a pointer is non-NULL. This
can be accomplished including the <tt>constraints.i</tt> library file.
</p>
<H3><a name="Arguments_nn9"></a>9.2.1 Simple constraint example</H3>
<H3><a name="Arguments_nn9"></a>10.2.1 Simple constraint example</H3>
<p>
@ -449,7 +449,7 @@ the arguments violate the constraint condition, a scripting language
exception will be raised. As a result, it is possible to catch bad
values, prevent mysterious program crashes and so on.</p>
<H3><a name="Arguments_nn10"></a>9.2.2 Constraint methods</H3>
<H3><a name="Arguments_nn10"></a>10.2.2 Constraint methods</H3>
<p>
@ -465,7 +465,7 @@ NONNULL Non-NULL pointer (pointers only).
</pre></div>
<H3><a name="Arguments_nn11"></a>9.2.3 Applying constraints to new datatypes</H3>
<H3><a name="Arguments_nn11"></a>10.2.3 Applying constraints to new datatypes</H3>
<p>

1182
Doc/Manual/CPlusPlus11.html Normal file
View file

File diff suppressed because it is too large Load diff

203
Doc/Manual/CSharp.html
View file

@ -5,11 +5,14 @@
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body bgcolor="#FFFFFF">
<H1><a name="CSharp"></a>19 SWIG and C#</H1>
<H1><a name="CSharp"></a>20 SWIG and C#</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="#CSharp_introduction">Introduction</a>
<ul>
<li><a href="#CSharp_introduction_swig2_compatibility">SWIG 2 Compatibility</a>
</ul>
<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>
@ -49,7 +52,7 @@
<H2><a name="CSharp_introduction"></a>19.1 Introduction</H2>
<H2><a name="CSharp_introduction"></a>20.1 Introduction</H2>
<p>
@ -69,7 +72,14 @@ 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>19.2 Differences to the Java module</H2>
<H3><a name="CSharp_introduction_swig2_compatibility"></a>20.1.1 SWIG 2 Compatibility</H3>
<p>
In order to minimize name collisions between names generated based on input to SWIG and names used in the generated code from the .NET framework, SWIG 3 fully qualifies the use of all .NET types. Furthermore, SWIG 3 avoids <tt>using</tt> directives in generated code. This breaks backwards compatibility with typemaps, pragmas, etc written for use with SWIG 2 that assume the presence of <tt>using System;</tt> or <tt>using System.Runtime.InteropServices;</tt> directives in the intermediate class imports, module imports, or proxy imports. SWIG 3 supports backwards compatibility though the use of the <tt>SWIG2_CSHARP</tt> macro. If <tt>SWIG2_CSHARP</tt> is defined, SWIG 3 generates <tt>using</tt> directives in the intermediate class, module class, and proxy class code similar to those generated by SWIG 2. This can be done without modifying any of the input code by passing the <tt>-DSWIG2_CSHARP</tt> commandline parameter when executing <tt>swig</tt>.
</p>
<H2><a name="CSharp_differences_java"></a>20.2 Differences to the Java module</H2>
<p>
@ -262,7 +272,7 @@ An example shows that <tt>char *</tt> could be marshalled in different ways,
<div class="code">
<pre>
%typemap(imtype, out="IntPtr") char * "string"
%typemap(imtype, out="global::System.IntPtr") char * "string"
char * function(char *);
</pre>
</div>
@ -273,7 +283,7 @@ The output type is thus IntPtr and the input type is string. The resulting inter
<div class="code">
<pre>
public static extern IntPtr function(string jarg1);
public static extern global::System.IntPtr function(string jarg1);
</pre>
</div>
@ -294,8 +304,8 @@ For example:
<div class="code">
<pre>
%typemap(imtype,
inattributes="[MarshalAs(UnmanagedType.LPStr)]",
outattributes="[return: MarshalAs(UnmanagedType.LPStr)]") const char * "String"
inattributes="[global::System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPStr)]",
outattributes="[return: global::System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPStr)]") const char * "String"
const char * GetMsg() {}
void SetMsg(const char *msg) {}
@ -310,12 +320,12 @@ The intermediary class will then have the marshalling as specified by everything
<pre>
class examplePINVOKE {
...
[DllImport("example", EntryPoint="CSharp_GetMsg")]
[return: MarshalAs(UnmanagedType.LPStr)]
[global::System.Runtime.InteropServices.DllImport("example", EntryPoint="CSharp_GetMsg")]
[return: global::System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPStr)]
public static extern String GetMsg();
[DllImport("example", EntryPoint="CSharp_SetMsg")]
public static extern void SetMsg([MarshalAs(UnmanagedType.LPStr)]String jarg1);
[global::System.Runtime.InteropServices.DllImport("example", EntryPoint="CSharp_SetMsg")]
public static extern void SetMsg([global::System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPStr)]String jarg1);
}
</pre>
</div>
@ -368,7 +378,7 @@ will generate a C# proxy class:
<div class="code">
<pre>
[ThreadSafe]
public class AClass : IDisposable {
public class AClass : global::System.IDisposable {
...
[ThreadSafe(false)]
public AClass(double a) ...
@ -392,9 +402,9 @@ An example for attaching attributes to the enum and enum values is shown below.
<div class="code">
<pre>
%typemap(csattributes) Couleur "[System.ComponentModel.Description(\"Colours\")]"
%csattributes Rouge "[System.ComponentModel.Description(\"Red\")]"
%csattributes Vert "[System.ComponentModel.Description(\"Green\")]"
%typemap(csattributes) Couleur "[global::System.ComponentModel.Description(\"Colours\")]"
%csattributes Rouge "[global::System.ComponentModel.Description(\"Red\")]"
%csattributes Vert "[global::System.ComponentModel.Description(\"Green\")]"
%inline %{
enum Couleur { Rouge, Orange, Vert };
%}
@ -407,12 +417,12 @@ which will result in the following C# enum:
<div class="code">
<pre>
[System.ComponentModel.Description("Colours")]
[global::System.ComponentModel.Description("Colours")]
public enum Couleur {
[System.ComponentModel.Description("Red")]
[global::System.ComponentModel.Description("Red")]
Rouge,
Orange,
[System.ComponentModel.Description("Green")]
[global::System.ComponentModel.Description("Green")]
Vert
}
</pre>
@ -482,7 +492,7 @@ 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_void_pointers"></a>19.3 Void pointers</H2>
<H2><a name="CSharp_void_pointers"></a>20.3 Void pointers</H2>
<p>
@ -500,7 +510,7 @@ void * f(void *v);
</pre>
</div>
<H2><a name="CSharp_arrays"></a>19.4 C# Arrays</H2>
<H2><a name="CSharp_arrays"></a>20.4 C# Arrays</H2>
<p>
@ -512,7 +522,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>19.4.1 The SWIG C arrays library</H3>
<H3><a name="CSharp_arrays_swig_library"></a>20.4.1 The SWIG C arrays library</H3>
<p>
@ -549,7 +559,7 @@ example.print_array(c.cast()); // Pass to C
</div>
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling"></a>19.4.2 Managed arrays using P/Invoke default array marshalling</H3>
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling"></a>20.4.2 Managed arrays using P/Invoke default array marshalling</H3>
<p>
@ -618,9 +628,9 @@ marshalling for the arrays:
<div class="code">
<pre>
[DllImport("example", EntryPoint="CSharp_myArrayCopy")]
public static extern void myArrayCopy([In, MarshalAs(UnmanagedType.LPArray)]int[] jarg1,
[Out, MarshalAs(UnmanagedType.LPArray)]int[] jarg2,
[global::System.Runtime.InteropServices.DllImport("example", EntryPoint="CSharp_myArrayCopy")]
public static extern void myArrayCopy([global::System.Runtime.InteropServices.In, global::System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPArray)]int[] jarg1,
[global::System.Runtime.InteropServices.Out, global::System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPArray)]int[] jarg2,
int jarg3);
</pre>
</div>
@ -668,15 +678,15 @@ and intermediary class method
<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,
[global::System.Runtime.InteropServices.DllImport("example", EntryPoint="CSharp_myArraySwap")]
public static extern void myArraySwap([global::System.Runtime.InteropServices.In, global::System.Runtime.InteropServices.Out, global::System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPArray)]int[] jarg1,
[global::System.Runtime.InteropServices.In, global::System.Runtime.InteropServices.Out, global::System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPArray)]int[] jarg2,
int jarg3);
</pre>
</div>
<H3><a name="CSharp_arrays_pinning"></a>19.4.3 Managed arrays using pinning</H3>
<H3><a name="CSharp_arrays_pinning"></a>20.4.3 Managed arrays using pinning</H3>
<p>
@ -743,7 +753,7 @@ 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,
examplePINVOKE.myArrayCopy((global::System.IntPtr)swig_ptrTo_sourceArray, (global::System.IntPtr)swig_ptrTo_targetArray,
nitems);
}
}
@ -764,14 +774,14 @@ example - the method is expecting an IntPtr as the parameter type.
<div class="code">
<pre>
[DllImport("example", EntryPoint="CSharp_myArrayCopy")]
public static extern void myArrayCopy(IntPtr jarg1, IntPtr jarg2, int jarg3);
[global::System.Runtime.InteropServices.DllImport("example", EntryPoint="CSharp_myArrayCopy")]
public static extern void myArrayCopy(global::System.IntPtr jarg1, global::System.IntPtr jarg2, int jarg3);
</pre>
</div>
<H2><a name="CSharp_exceptions"></a>19.5 C# Exceptions</H2>
<H2><a name="CSharp_exceptions"></a>20.5 C# Exceptions</H2>
<p>
@ -868,11 +878,11 @@ set so should only be used when a C# exception is not created.
</p>
<H3><a name="CSharp_exception_example_check_typemap"></a>19.5.1 C# exception example using "check" typemap</H3>
<H3><a name="CSharp_exception_example_check_typemap"></a>20.5.1 C# exception example using "check" typemap</H3>
<p>
Lets say we have the following simple C++ method:
Let's say we have the following simple C++ method:
</p>
@ -1050,7 +1060,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>19.5.2 C# exception example using %exception</H3>
<H3><a name="CSharp_exception_example_percent_exception"></a>20.5.2 C# exception example using %exception</H3>
<p>
@ -1115,7 +1125,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>19.5.3 C# exception example using exception specifications</H3>
<H3><a name="CSharp_exception_example_exception_specifications"></a>20.5.3 C# exception example using exception specifications</H3>
<p>
@ -1172,7 +1182,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>19.5.4 Custom C# ApplicationException example</H3>
<H3><a name="CSharp_custom_application_exception"></a>20.5.4 Custom C# ApplicationException example</H3>
<p>
@ -1220,7 +1230,7 @@ the C# code can be generated into the intermediary class using the <tt>imclassco
static CustomExceptionDelegate customDelegate =
new CustomExceptionDelegate(SetPendingCustomException);
[DllImport("$dllimport", EntryPoint="CustomExceptionRegisterCallback")]
[global::System.Runtime.InteropServices.DllImport("$dllimport", EntryPoint="CustomExceptionRegisterCallback")]
public static extern
void CustomExceptionRegisterCallback(CustomExceptionDelegate customCallback);
@ -1264,7 +1274,7 @@ The boiler plate code above must be used in addition to a handcrafted <tt>Custom
<div class="code">
<pre>
// Custom C# Exception
class CustomApplicationException : System.ApplicationException {
class CustomApplicationException : global::System.ApplicationException {
public CustomApplicationException(string message)
: base(message) {
}
@ -1306,7 +1316,7 @@ try {
</pre>
</div>
<H2><a name="CSharp_directors"></a>19.6 C# Directors</H2>
<H2><a name="CSharp_directors"></a>20.6 C# Directors</H2>
<p>
@ -1319,7 +1329,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>19.6.1 Directors example</H3>
<H3><a name="CSharp_directors_example"></a>20.6.1 Directors example</H3>
<p>
@ -1440,7 +1450,7 @@ CSharpDerived - UIntMethod(123)
</pre>
</div>
<H3><a name="CSharp_directors_implementation"></a>19.6.2 Directors implementation</H3>
<H3><a name="CSharp_directors_implementation"></a>20.6.2 Directors implementation</H3>
<p>
@ -1457,20 +1467,17 @@ Below is the generated C# <tt>Base</tt> director class.
<div class="code">
<pre>
using System;
using System.Runtime.InteropServices;
public class Base : IDisposable {
private HandleRef swigCPtr;
public class Base : global::System.IDisposable {
private global::System.Runtime.InteropServices.HandleRef swigCPtr;
protected bool swigCMemOwn;
internal Base(IntPtr cPtr, bool cMemoryOwn) {
internal Base(global::System.IntPtr cPtr, bool cMemoryOwn) {
swigCMemOwn = cMemoryOwn;
swigCPtr = new HandleRef(this, cPtr);
swigCPtr = new global::System.Runtime.InteropServices.HandleRef(this, cPtr);
}
internal static HandleRef getCPtr(Base obj) {
return (obj == null) ? new HandleRef(null, IntPtr.Zero) : obj.swigCPtr;
internal static global::System.Runtime.InteropServices.HandleRef getCPtr(Base obj) {
return (obj == null) ? new global::System.Runtime.InteropServices.HandleRef(null, global::System.IntPtr.Zero) : obj.swigCPtr;
}
~Base() {
@ -1479,12 +1486,12 @@ public class Base : IDisposable {
public virtual void Dispose() {
lock(this) {
if(swigCPtr.Handle != IntPtr.Zero &amp;&amp; swigCMemOwn) {
if(swigCPtr.Handle != global::System.IntPtr.Zero &amp;&amp; swigCMemOwn) {
swigCMemOwn = false;
examplePINVOKE.delete_Base(swigCPtr);
}
swigCPtr = new HandleRef(null, IntPtr.Zero);
GC.SuppressFinalize(this);
swigCPtr = new global::System.Runtime.InteropServices.HandleRef(null, global::System.IntPtr.Zero);
global::System.GC.SuppressFinalize(this);
}
}
@ -1511,7 +1518,7 @@ public class Base : IDisposable {
examplePINVOKE.Base_director_connect(swigCPtr, swigDelegate0, swigDelegate1);
}
private bool SwigDerivedClassHasMethod(string methodName, Type[] methodTypes) {
private bool SwigDerivedClassHasMethod(string methodName, global::System.global::System.Type[] methodTypes) {
System.Reflection.MethodInfo methodInfo = this.GetType().GetMethod(methodName, methodTypes);
bool hasDerivedMethod = methodInfo.DeclaringType.IsSubclassOf(typeof(Base));
return hasDerivedMethod;
@ -1521,18 +1528,18 @@ public class Base : IDisposable {
return UIntMethod(x);
}
private void SwigDirectorBaseBoolMethod(IntPtr b, bool flag) {
private void SwigDirectorBaseBoolMethod(global::System.IntPtr b, bool flag) {
BaseBoolMethod(new Base(b, false), flag);
}
internal delegate uint SwigDelegateBase_0(uint x);
internal delegate void SwigDelegateBase_1(IntPtr b, bool flag);
internal delegate void SwigDelegateBase_1(global::System.IntPtr b, bool flag);
private SwigDelegateBase_0 swigDelegate0;
private SwigDelegateBase_1 swigDelegate1;
private static Type[] swigMethodTypes0 = new Type[] { typeof(uint) };
private static Type[] swigMethodTypes1 = new Type[] { typeof(Base), typeof(bool) };
private static global::System.Type[] swigMethodTypes0 = new global::System.Type[] { typeof(uint) };
private static global::System.Type[] swigMethodTypes1 = new global::System.Type[] { typeof(Base), typeof(bool) };
}
</pre>
</div>
@ -1626,7 +1633,7 @@ void SwigDirector_Base::BaseBoolMethod(Base const &amp;b, bool flag) {
</pre>
</div>
<H3><a name="CSharp_director_caveats"></a>19.6.3 Director caveats</H3>
<H3><a name="CSharp_director_caveats"></a>20.6.3 Director caveats</H3>
<p>
@ -1674,7 +1681,7 @@ 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_multiple_modules"></a>19.7 Multiples modules</H2>
<H2><a name="CSharp_multiple_modules"></a>20.7 Multiples modules</H2>
<p>
@ -1709,7 +1716,7 @@ the <tt>[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrows
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>
<H2><a name="CSharp_typemap_examples"></a>20.8 C# Typemap examples</H2>
This section includes a few examples of typemaps. For more examples, you
@ -1717,7 +1724,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>19.8.1 Memory management when returning references to member variables</H3>
<H3><a name="CSharp_memory_management_member_variables"></a>20.8.1 Memory management when returning references to member variables</H3>
<p>
@ -1755,9 +1762,9 @@ and the following usage from C# after running the code through SWIG:
Wheel wheel = new Bike(10).getWheel();
Console.WriteLine("wheel size: " + wheel.size);
// Simulate a garbage collection
System.GC.Collect();
System.GC.WaitForPendingFinalizers();
Console.WriteLine("wheel size: " + wheel.size);
global::System.GC.Collect();
global::System.GC.WaitForPendingFinalizers();
global::System.Console.WriteLine("wheel size: " + wheel.size);
</pre>
</div>
@ -1795,9 +1802,9 @@ is called using the following typemaps.
// of dangling C++ pointer. Intended for methods that return pointers or
// references to a member variable.
%typemap(csout, excode=SWIGEXCODE) Wheel&amp; getWheel {
IntPtr cPtr = $imcall;$excode
global::System.IntPtr cPtr = $imcall;$excode
$csclassname ret = null;
if (cPtr != IntPtr.Zero) {
if (cPtr != global::System.IntPtr.Zero) {
ret = new $csclassname(cPtr, $owner);
ret.addReference(this);
}
@ -1813,7 +1820,7 @@ The code in the second typemap constitutes the bulk of the code in the generated
<div class="code">
<pre>
public class Wheel : IDisposable {
public class Wheel : global::System.IDisposable {
...
// Ensure that the GC doesn't collect any Bike instance set from C#
private Bike bikeReference;
@ -1822,12 +1829,12 @@ public class Wheel : IDisposable {
}
}
public class Bike : IDisposable {
public class Bike : global::System.IDisposable {
...
public Wheel getWheel() {
IntPtr cPtr = examplePINVOKE.Bike_getWheel(swigCPtr);
global::System.IntPtr cPtr = examplePINVOKE.Bike_getWheel(swigCPtr);
Wheel ret = null;
if (cPtr != IntPtr.Zero) {
if (cPtr != global::System.IntPtr.Zero) {
ret = new Wheel(cPtr, false);
ret.addReference(this);
}
@ -1841,7 +1848,7 @@ public class Bike : IDisposable {
Note the <tt>addReference</tt> call.
</p>
<H3><a name="CSharp_memory_management_objects"></a>19.8.2 Memory management for objects passed to the C++ layer</H3>
<H3><a name="CSharp_memory_management_objects"></a>20.8.2 Memory management for objects passed to the C++ layer</H3>
<p>
@ -1904,9 +1911,9 @@ In order to understand why, consider a garbage collection occuring...
container.setElement(element);
Console.WriteLine("element.value: " + container.getElement().value);
// Simulate a garbage collection
System.GC.Collect();
System.GC.WaitForPendingFinalizers();
Console.WriteLine("element.value: " + container.getElement().value);
global::System.GC.Collect();
global::System.GC.WaitForPendingFinalizers();
global::System.Console.WriteLine("element.value: " + container.getElement().value);
</pre>
</div>
@ -1918,14 +1925,14 @@ One solution is to add in the appropriate references in the C# layer...
<div class="code">
<pre>
public class Container : IDisposable {
public class Container : global::System.IDisposable {
...
// Ensure that the GC doesn't collect any Element set from C#
// as the underlying C++ class stores a shallow copy
private Element elementReference;
private HandleRef getCPtrAndAddReference(Element element) {
private global::System.Runtime.InteropServices.HandleRef getCPtrAndAddReference(Element element) {
elementReference = element;
return Element.getCPtr(element);
}
@ -1951,7 +1958,7 @@ The 'cscode' typemap simply adds in the specified code into the C# proxy class.
// Ensure that the GC doesn't collect any Element set from C#
// as the underlying C++ class stores a shallow copy
private Element elementReference;
private HandleRef getCPtrAndAddReference(Element element) {
private global::System.Runtime.InteropServices.HandleRef getCPtrAndAddReference(Element element) {
elementReference = element;
return Element.getCPtr(element);
}
@ -1960,7 +1967,7 @@ The 'cscode' typemap simply adds in the specified code into the C# proxy class.
</div>
<H3><a name="CSharp_date_marshalling"></a>19.8.3 Date marshalling using the csin typemap and associated attributes</H3>
<H3><a name="CSharp_date_marshalling"></a>20.8.3 Date marshalling using the csin typemap and associated attributes</H3>
<p>
@ -2000,7 +2007,7 @@ First let's look at the code that is generated by default, where the C# proxy cl
<div class="code">
<pre>
public class Action : IDisposable {
public class Action : global::System.IDisposable {
...
public Action(CDate dateIn, CDate dateOut)
: this(examplePINVOKE.new_Action(CDate.getCPtr(dateIn), CDate.getCPtr(dateOut)), true) {
@ -2081,7 +2088,7 @@ The resulting generated proxy code in the <tt>Action</tt> class follows:
<div class="code">
<pre>
public class Action : IDisposable {
public class Action : global::System.IDisposable {
...
public int doSomething(System.DateTime dateIn, out System.DateTime dateOut) {
CDate tempdateIn = new CDate(dateIn.Year, dateIn.Month, dateIn.Day);
@ -2099,7 +2106,7 @@ public class Action : IDisposable {
}
}
static private IntPtr SwigConstructAction(System.DateTime dateIn, out System.DateTime dateOut) {
static private global::System.IntPtr SwigConstructAction(System.DateTime dateIn, out System.DateTime dateOut) {
CDate tempdateIn = new CDate(dateIn.Year, dateIn.Month, dateIn.Day);
CDate tempdateOut = new CDate();
try {
@ -2246,7 +2253,7 @@ public class example {
</pre>
</div>
<H3><a name="CSharp_date_properties"></a>19.8.4 A date example demonstrating marshalling of C# properties</H3>
<H3><a name="CSharp_date_properties"></a>20.8.4 A date example demonstrating marshalling of C# properties</H3>
<p>
@ -2299,8 +2306,8 @@ The typemap type required is thus <tt>CDate *</tt>. Given that the previous sect
%typemap(csvarout, excode=SWIGEXCODE2) CDate * %{
/* csvarout typemap code */
get {
IntPtr cPtr = $imcall;
CDate tempDate = (cPtr == IntPtr.Zero) ? null : new CDate(cPtr, $owner);$excode
global::System.IntPtr cPtr = $imcall;
CDate tempDate = (cPtr == global::System.IntPtr.Zero) ? null : new CDate(cPtr, $owner);$excode
return new System.DateTime(tempDate.getYear(), tempDate.getMonth(), tempDate.getDay(),
0, 0, 0);
} %}
@ -2322,8 +2329,8 @@ public class example {
}
/* csvarout typemap code */
get {
IntPtr cPtr = examplePINVOKE.ImportantDate_get();
CDate tempDate = (cPtr == IntPtr.Zero) ? null : new CDate(cPtr, false);
global::System.IntPtr cPtr = examplePINVOKE.ImportantDate_get();
CDate tempDate = (cPtr == global::System.IntPtr.Zero) ? null : new CDate(cPtr, false);
return new System.DateTime(tempDate.getYear(), tempDate.getMonth(), tempDate.getDay(),
0, 0, 0);
}
@ -2346,7 +2353,7 @@ 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_date_pre_post_directors"></a>20.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</H3>
<p>
@ -2389,7 +2396,7 @@ The generated proxy class code will then contain the following wrapper for calli
<div class="code"><pre>
...
private void SwigDirectorsomeCallback(IntPtr date) {
private void SwigDirectorsomeCallback(global::System.IntPtr date) {
System.DateTime tempdate = new System.DateTime();
try {
someCallback(out tempdate);
@ -2408,7 +2415,7 @@ 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>
<H3><a name="CSharp_partial_classes"></a>20.8.6 Turning wrapped classes into partial classes</H3>
<p>
@ -2432,7 +2439,7 @@ The default C# proxy class generated is:
<div class="code">
<pre>
public class ExtendMe : IDisposable {
public class ExtendMe : global::System.IDisposable {
...
public int Part1() {
...
@ -2468,7 +2475,7 @@ The C# proxy class becomes a partial class:
<div class="code">
<pre>
public partial class ExtendMe : IDisposable {
public partial class ExtendMe : global::System.IDisposable {
...
public int Part1() {
...
@ -2483,7 +2490,7 @@ You can then of course declare another part of the partial class elsewhere, for
<div class="code">
<pre>
public partial class ExtendMe : IDisposable {
public partial class ExtendMe : global::System.IDisposable {
public int Part2() {
return 2;
}
@ -2508,7 +2515,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>19.8.7 Extending proxy classes with additional C# code</H3>
<H3><a name="CSharp_extending_proxy_class"></a>20.8.7 Extending proxy classes with additional C# code</H3>
<p>
@ -2535,7 +2542,7 @@ The generated C# proxy class will instead be:
<div class="code">
<pre>
public class ExtendMe : IDisposable {
public class ExtendMe : global::System.IDisposable {
...
public int Part3() {
return 3;
@ -2547,7 +2554,7 @@ public class ExtendMe : IDisposable {
</pre>
</div>
<H3><a name="CSharp_enum_underlying_type"></a>19.8.8 Underlying type for enums</H3>
<H3><a name="CSharp_enum_underlying_type"></a>20.8.8 Underlying type for enums</H3>
<P>

40
Doc/Manual/Chicken.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Chicken"></a>20 SWIG and Chicken</H1>
<H1><a name="Chicken"></a>21 SWIG and Chicken</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -72,7 +72,7 @@
</p>
<H2><a name="Chicken_nn2"></a>20.1 Preliminaries</H2>
<H2><a name="Chicken_nn2"></a>21.1 Preliminaries</H2>
<p>
@ -89,7 +89,7 @@
directory for the basic steps to run SWIG CHICKEN.
</p>
<H3><a name="Chicken_nn3"></a>20.1.1 Running SWIG in C mode</H3>
<H3><a name="Chicken_nn3"></a>21.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>20.1.2 Running SWIG in C++ mode</H3>
<H3><a name="Chicken_nn4"></a>21.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>20.2 Code Generation</H2>
<H2><a name="Chicken_nn5"></a>21.2 Code Generation</H2>
<H3><a name="Chicken_nn6"></a>20.2.1 Naming Conventions</H3>
<H3><a name="Chicken_nn6"></a>21.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>20.2.2 Modules</H3>
<H3><a name="Chicken_nn7"></a>21.2.2 Modules</H3>
<p>
@ -192,7 +192,7 @@
(uses <i>modulename</i>))</code> CHICKEN Scheme form.
</p>
<H3><a name="Chicken_nn8"></a>20.2.3 Constants and Variables</H3>
<H3><a name="Chicken_nn8"></a>21.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>20.2.4 Functions</H3>
<H3><a name="Chicken_nn9"></a>21.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>20.2.5 Exceptions</H3>
<H3><a name="Chicken_nn10"></a>21.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>20.3 TinyCLOS</H2>
<H2><a name="Chicken_nn11"></a>21.3 TinyCLOS</H2>
<p>
@ -333,7 +333,7 @@
</p>
<H2><a name="Chicken_nn12"></a>20.4 Linkage</H2>
<H2><a name="Chicken_nn12"></a>21.4 Linkage</H2>
<p>
@ -354,7 +354,7 @@
</p>
<H3><a name="Chicken_nn13"></a>20.4.1 Static binary or shared library linked at compile time</H3>
<H3><a name="Chicken_nn13"></a>21.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>20.4.2 Building chicken extension libraries</H3>
<H3><a name="Chicken_nn14"></a>21.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>20.4.3 Linking multiple SWIG modules with TinyCLOS</H3>
<H3><a name="Chicken_nn15"></a>21.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>20.5 Typemaps</H2>
<H2><a name="Chicken_nn16"></a>21.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>20.6 Pointers</H2>
<H2><a name="Chicken_nn17"></a>21.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>20.6.1 Garbage collection</H3>
<H3><a name="Chicken_collection"></a>21.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>20.7 Unsupported features and known problems</H2>
<H2><a name="Chicken_nn18"></a>21.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>20.7.1 TinyCLOS problems with Chicken version &lt;= 1.92</H3>
<H3><a name="Chicken_nn19"></a>21.7.1 TinyCLOS problems with Chicken version &lt;= 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

200
Doc/Manual/Contents.html
View file

@ -262,7 +262,61 @@
</div>
<!-- INDEX -->
<h3><a href="Preprocessor.html#Preprocessor">7 Preprocessing</a></h3>
<h3><a href="CPlusPlus11.html#CPlusPlus11">7 SWIG and C++11</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="CPlusPlus11.html#CPlusPlus11_introduction">Introduction</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_core_language_changes">Core language changes</a>
<ul>
<li><a href="CPlusPlus11.html#CPlusPlus11_rvalue_reference_and_move_semantics">Rvalue reference and move semantics</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_generalized_constant_expressions">Generalized constant expressions</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_extern_template">Extern template</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_initializer_lists">Initializer lists</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_uniform_initialization">Uniform initialization</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_type_inference">Type inference</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_range_based_for_loop">Range-based for-loop</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_lambda_functions_and_expressions">Lambda functions and expressions</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_alternate_function_syntax">Alternate function syntax</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_object_construction_improvement">Object construction improvement</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_explicit_overrides_final">Explicit overrides and final</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_null_pointer_constant">Null pointer constant</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_strongly_typed_enumerations">Strongly typed enumerations</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_double_angle_brackets">Double angle brackets</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_explicit_conversion_operators">Explicit conversion operators</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_alias_templates">Alias templates</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_unrestricted_unions">Unrestricted unions</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_variadic_templates">Variadic templates</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_new_string_literals">New string literals</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_user_defined_literals">User-defined literals</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_thread_local_storage">Thread-local storage</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_defaulted_deleted">Explicitly defaulted functions and deleted functions</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_type_long_long_int">Type long long int</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_static_assertions">Static assertions</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_sizeof">Allow sizeof to work on members of classes without an explicit object</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_noexcept">Exception specifications and noexcept</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_alignment">Control and query object alignment</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_attributes">Attributes</a>
</ul>
<li><a href="CPlusPlus11.html#CPlusPlus11_standard_library_changes">Standard library changes</a>
<ul>
<li><a href="CPlusPlus11.html#CPlusPlus11_threading_facilities">Threading facilities</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_tuple_types">Tuple types</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_hash_tables">Hash tables</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_regular_expressions">Regular expressions</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_general_purpose_smart_pointers">General-purpose smart pointers</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_extensible_random_number_facility">Extensible random number facility</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_wrapper_reference">Wrapper reference</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_polymorphous_wrappers_for_function_objects">Polymorphous wrappers for function objects</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_type_traits_for_metaprogramming">Type traits for metaprogramming</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_uniform_method_for_computing_return_type_of_function_objects">Uniform method for computing return type of function objects</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Preprocessor.html#Preprocessor">8 Preprocessing</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -285,7 +339,7 @@
</div>
<!-- INDEX -->
<h3><a href="Library.html#Library">8 SWIG library</a></h3>
<h3><a href="Library.html#Library">9 SWIG library</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -311,6 +365,7 @@
<li><a href="Library.html#Library_std_vector">std::vector</a>
<li><a href="Library.html#Library_stl_exceptions">STL exceptions</a>
<li><a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a>
<li><a href="Library.html#Library_std_auto_ptr">auto_ptr smart pointer</a>
</ul>
<li><a href="Library.html#Library_nn16">Utility Libraries</a>
<ul>
@ -320,7 +375,7 @@
</div>
<!-- INDEX -->
<h3><a href="Arguments.html#Arguments">9 Argument Handling</a></h3>
<h3><a href="Arguments.html#Arguments">10 Argument Handling</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -343,7 +398,7 @@
</div>
<!-- INDEX -->
<h3><a href="Typemaps.html#Typemaps">10 Typemaps</a></h3>
<h3><a href="Typemaps.html#Typemaps">11 Typemaps</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -431,7 +486,7 @@
</div>
<!-- INDEX -->
<h3><a href="Customization.html#Customization">11 Customization Features</a></h3>
<h3><a href="Customization.html#Customization">12 Customization Features</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -459,7 +514,7 @@
</div>
<!-- INDEX -->
<h3><a href="Contract.html#Contract">12 Contracts</a></h3>
<h3><a href="Contract.html#Contract">13 Contracts</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -472,7 +527,7 @@
</div>
<!-- INDEX -->
<h3><a href="Varargs.html#Varargs">13 Variable Length Arguments</a></h3>
<h3><a href="Varargs.html#Varargs">14 Variable Length Arguments</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -490,7 +545,7 @@
</div>
<!-- INDEX -->
<h3><a href="Warnings.html#Warnings">14 Warning Messages</a></h3>
<h3><a href="Warnings.html#Warnings">15 Warning Messages</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -518,7 +573,7 @@
</div>
<!-- INDEX -->
<h3><a href="Modules.html#Modules">15 Working with Modules</a></h3>
<h3><a href="Modules.html#Modules">16 Working with Modules</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -534,7 +589,7 @@
</div>
<!-- INDEX -->
<h3><a href="CCache.html#CCache">16 Using SWIG with ccache - ccache-swig(1) manpage</a></h3>
<h3><a href="CCache.html#CCache">17 Using SWIG with ccache - ccache-swig(1) manpage</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -560,7 +615,7 @@
</div>
<!-- INDEX -->
<h3><a href="Allegrocl.html#Allegrocl">17 SWIG and Allegro Common Lisp</a></h3>
<h3><a href="Allegrocl.html#Allegrocl">18 SWIG and Allegro Common Lisp</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -644,7 +699,7 @@
</div>
<!-- INDEX -->
<h3><a href="Android.html#Android">18 SWIG and Android</a></h3>
<h3><a href="Android.html#Android">19 SWIG and Android</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -662,12 +717,15 @@
</div>
<!-- INDEX -->
<h3><a href="CSharp.html#CSharp">19 SWIG and C#</a></h3>
<h3><a href="CSharp.html#CSharp">20 SWIG and C#</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="CSharp.html#CSharp_introduction">Introduction</a>
<ul>
<li><a href="CSharp.html#CSharp_introduction_swig2_compatibility">SWIG 2 Compatibility</a>
</ul>
<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>
@ -705,7 +763,7 @@
</div>
<!-- INDEX -->
<h3><a href="Chicken.html#Chicken">20 SWIG and Chicken</a></h3>
<h3><a href="Chicken.html#Chicken">21 SWIG and Chicken</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -743,7 +801,7 @@
</div>
<!-- INDEX -->
<h3><a href="D.html#D">21 SWIG and D</a></h3>
<h3><a href="D.html#D">22 SWIG and D</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -777,7 +835,7 @@
</div>
<!-- INDEX -->
<h3><a href="Go.html#Go">22 SWIG and Go</a></h3>
<h3><a href="Go.html#Go">23 SWIG and Go</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -808,7 +866,7 @@
</div>
<!-- INDEX -->
<h3><a href="Guile.html#Guile">23 SWIG and Guile</a></h3>
<h3><a href="Guile.html#Guile">24 SWIG and Guile</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -843,7 +901,7 @@
</div>
<!-- INDEX -->
<h3><a href="Java.html#Java">24 SWIG and Java</a></h3>
<h3><a href="Java.html#Java">25 SWIG and Java</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -926,6 +984,7 @@
<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>
<li><a href="Java.html#Java_exceptions_from_directors">Java exceptions from directors</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>
@ -987,7 +1046,49 @@
</div>
<!-- INDEX -->
<h3><a href="Lisp.html#Lisp">25 SWIG and Common Lisp</a></h3>
<h3><a href="Javascript.html#Javascript">26 SWIG and Javascript</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Javascript.html#Javascript_overview">Overview</a>
<li><a href="Javascript.html#Javascript_preliminaries">Preliminaries</a>
<ul>
<li><a href="Javascript.html#Javascript_running_swig">Running SWIG</a>
<li><a href="Javascript.html#Javascript_running_tests_examples">Running Tests and Examples</a>
<li><a href="Javascript.html#Javascript_known_issues">Known Issues</a>
</ul>
<li><a href="Javascript.html#Javascript_integration">Integration</a>
<ul>
<li><a href="Javascript.html#Javascript_node_extensions">Creating node.js Extensions</a>
<ul>
<li><a href="Javascript.html#Javascript_troubleshooting">Troubleshooting</a>
</ul>
<li><a href="Javascript.html#Javascript_embedded_webkit">Embedded Webkit</a>
<ul>
<li><a href="Javascript.html#Javascript_osx">OSX</a>
<li><a href="Javascript.html#Javascript_gtk">GTK</a>
</ul>
<li><a href="Javascript.html#Javascript_applications_webkit">Creating Applications with node-webkit</a>
</ul>
<li><a href="Javascript.html#Javascript_nn14">Examples</a>
<ul>
<li><a href="Javascript.html#Javascript_simple_example">Simple</a>
<li><a href="Javascript.html#Javascript_class_example">Class</a>
</ul>
<li><a href="Javascript.html#Javascript_implementation">Implementation</a>
<ul>
<li><a href="Javascript.html#Javascript_source_code">Source Code</a>
<li><a href="Javascript.html#Javascript_code_templates">Code Templates</a>
<li><a href="Javascript.html#Javascript_emitter">Emitter</a>
<li><a href="Javascript.html#Javascript_emitter_states">Emitter states</a>
<li><a href="Javascript.html#Javascript_jsc_exceptions">Handling Exceptions in JavascriptCore</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Lisp.html#Lisp">27 SWIG and Common Lisp</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1010,7 +1111,7 @@
</div>
<!-- INDEX -->
<h3><a href="Lua.html#Lua">26 SWIG and Lua</a></h3>
<h3><a href="Lua.html#Lua">28 SWIG and Lua</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1029,8 +1130,11 @@
<li><a href="Lua.html#Lua_nn9">Functions</a>
<li><a href="Lua.html#Lua_nn10">Global variables</a>
<li><a href="Lua.html#Lua_nn11">Constants and enums</a>
<ul>
<li><a href="Lua.html#Lua_nn13">Constants/enums and classes/structures</a>
</ul>
<li><a href="Lua.html#Lua_nn12">Pointers</a>
<li><a href="Lua.html#Lua_nn13">Structures</a>
<li><a href="Lua.html#Lua_structures">Structures</a>
<li><a href="Lua.html#Lua_nn14">C++ classes</a>
<li><a href="Lua.html#Lua_nn15">C++ inheritance</a>
<li><a href="Lua.html#Lua_nn16">Pointers, references, values, and arrays</a>
@ -1041,17 +1145,23 @@
<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>
<li><a href="Lua.html#Lua_namespaces">Namespaces </a>
<ul>
<li><a href="Lua.html#Lua_nn27">Compatibility Note </a>
<li><a href="Lua.html#Lua_nn29">Names </a>
<li><a href="Lua.html#Lua_nn30">Inheritance </a>
</ul>
</ul>
<li><a href="Lua.html#Lua_nn24">Typemaps</a>
<ul>
<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>
<li><a href="Lua.html#Lua_typemap_arrays">Typemaps and arrays</a>
<li><a href="Lua.html#Lua_typemaps_ptr_ptr_functions">Typemaps and pointer-pointer functions</a>
</ul>
<li><a href="Lua.html#Lua_nn29">Writing typemaps</a>
<li><a href="Lua.html#Lua_writing_typemaps">Writing typemaps</a>
<ul>
<li><a href="Lua.html#Lua_nn30">Typemaps you can write</a>
<li><a href="Lua.html#Lua_typemaps_write">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_nn32">Customization of your Bindings</a>
@ -1069,7 +1179,7 @@
</div>
<!-- INDEX -->
<h3><a href="Modula3.html#Modula3">27 SWIG and Modula-3</a></h3>
<h3><a href="Modula3.html#Modula3">29 SWIG and Modula-3</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1107,7 +1217,7 @@
</div>
<!-- INDEX -->
<h3><a href="Mzscheme.html#Mzscheme">28 SWIG and MzScheme/Racket</a></h3>
<h3><a href="Mzscheme.html#Mzscheme">30 SWIG and MzScheme/Racket</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1119,7 +1229,7 @@
</div>
<!-- INDEX -->
<h3><a href="Ocaml.html#Ocaml">29 SWIG and Ocaml</a></h3>
<h3><a href="Ocaml.html#Ocaml">31 SWIG and Ocaml</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1170,7 +1280,7 @@
</div>
<!-- INDEX -->
<h3><a href="Octave.html#Octave">30 SWIG and Octave</a></h3>
<h3><a href="Octave.html#Octave">32 SWIG and Octave</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1206,7 +1316,7 @@
</div>
<!-- INDEX -->
<h3><a href="Perl5.html#Perl5">31 SWIG and Perl5</a></h3>
<h3><a href="Perl5.html#Perl5">33 SWIG and Perl5</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1269,11 +1379,20 @@
<li><a href="Perl5.html#Perl5_nn46">Modifying the proxy methods</a>
</ul>
<li><a href="Perl5.html#Perl5_nn47">Adding additional Perl code</a>
<li><a href="Perl5.html#Perl5_directors">Cross language polymorphism</a>
<ul>
<li><a href="Perl5.html#Perl5_nn48">Enabling directors</a>
<li><a href="Perl5.html#Perl5_nn49">Director classes</a>
<li><a href="Perl5.html#Perl5_nn50">Ownership and object destruction</a>
<li><a href="Perl5.html#Perl5_nn51">Exception unrolling</a>
<li><a href="Perl5.html#Perl5_nn52">Overhead and code bloat</a>
<li><a href="Perl5.html#Perl5_nn53">Typemaps</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Php.html#Php">32 SWIG and PHP</a></h3>
<h3><a href="Php.html#Php">34 SWIG and PHP</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1313,7 +1432,7 @@
</div>
<!-- INDEX -->
<h3><a href="Pike.html#Pike">33 SWIG and Pike</a></h3>
<h3><a href="Pike.html#Pike">35 SWIG and Pike</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1337,7 +1456,7 @@
</div>
<!-- INDEX -->
<h3><a href="Python.html#Python">34 SWIG and Python</a></h3>
<h3><a href="Python.html#Python">36 SWIG and Python</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1437,17 +1556,24 @@
<li><a href="Python.html#Python_nn71">%feature("docstring")</a>
</ul>
<li><a href="Python.html#Python_nn72">Python Packages</a>
<ul>
<li><a href="Python.html#Python_modulepackage">Setting the Python package</a>
<li><a href="Python.html#Python_absrelimports">Absolute and relative imports</a>
<li><a href="Python.html#Python_absimport">Enforcing absolute import semantics</a>
<li><a href="Python.html#Python_importfrominit">Importing from __init__.py</a>
</ul>
<li><a href="Python.html#Python_python3support">Python 3 Support</a>
<ul>
<li><a href="Python.html#Python_nn74">Function annotation</a>
<li><a href="Python.html#Python_nn75">Buffer interface</a>
<li><a href="Python.html#Python_nn76">Abstract base classes</a>
<li><a href="Python.html#Python_nn77">Byte string output conversion</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="R.html#R">35 SWIG and R</a></h3>
<h3><a href="R.html#R">37 SWIG and R</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1463,7 +1589,7 @@
</div>
<!-- INDEX -->
<h3><a href="Ruby.html#Ruby">36 SWIG and Ruby</a></h3>
<h3><a href="Ruby.html#Ruby">38 SWIG and Ruby</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1597,7 +1723,7 @@
</div>
<!-- INDEX -->
<h3><a href="Tcl.html#Tcl">37 SWIG and Tcl</a></h3>
<h3><a href="Tcl.html#Tcl">39 SWIG and Tcl</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1663,7 +1789,7 @@
</div>
<!-- INDEX -->
<h3><a href="Extending.html#Extending">38 Extending SWIG to support new languages</a></h3>
<h3><a href="Extending.html#Extending">40 Extending SWIG to support new languages</a></h3>
<!-- INDEX -->
<div class="sectiontoc">

10
Doc/Manual/Contract.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Contract"></a>12 Contracts</H1>
<H1><a name="Contract"></a>13 Contracts</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -38,7 +38,7 @@ When one of the rules is violated by a script, a runtime exception is
generated rather than having the program continue to execute.
</p>
<H2><a name="Contract_nn2"></a>12.1 The %contract directive</H2>
<H2><a name="Contract_nn2"></a>13.1 The %contract directive</H2>
<p>
@ -94,7 +94,7 @@ RuntimeError: Contract violation: require: (arg1&gt;=0)
</pre>
</div>
<H2><a name="Contract_nn3"></a>12.2 %contract and classes</H2>
<H2><a name="Contract_nn3"></a>13.2 %contract and classes</H2>
<p>
@ -173,7 +173,7 @@ specified for the derived class all must hold. In the above example,
this means that both the arguments to <tt>Spam::bar</tt> must be positive.
</p>
<H2><a name="Contract_nn4"></a>12.3 Constant aggregation and %aggregate_check</H2>
<H2><a name="Contract_nn4"></a>13.3 Constant aggregation and %aggregate_check</H2>
<p>
@ -262,7 +262,7 @@ Regrettably, there is no automatic way to perform similar checks with enums valu
release.
</p>
<H2><a name="Contract_nn5"></a>12.4 Notes</H2>
<H2><a name="Contract_nn5"></a>13.4 Notes</H2>
<p>

32
Doc/Manual/Customization.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Customization"></a>11 Customization Features</H1>
<H1><a name="Customization"></a>12 Customization Features</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -45,7 +45,7 @@ of exception handling is presented. Then, a more general-purpose
customization mechanism known as "features" is described.
</p>
<H2><a name="Customization_exception"></a>11.1 Exception handling with %exception</H2>
<H2><a name="Customization_exception"></a>12.1 Exception handling with %exception</H2>
<p>
@ -100,7 +100,7 @@ for exception handling. That directive is deprecated--<tt>%exception</tt>
provides the same functionality, but is substantially more flexible.
</p>
<H3><a name="Customization_nn3"></a>11.1.1 Handling exceptions in C code</H3>
<H3><a name="Customization_nn3"></a>12.1.1 Handling exceptions in C code</H3>
<p>
@ -166,7 +166,7 @@ Each target language has its own approach to creating a runtime error/exception
and for Perl it is the <tt>croak</tt> method shown above.
</p>
<H3><a name="Customization_nn4"></a>11.1.2 Exception handling with longjmp()</H3>
<H3><a name="Customization_nn4"></a>12.1.2 Exception handling with longjmp()</H3>
<p>
@ -240,7 +240,7 @@ Note: This implementation is only intended to illustrate the general idea. To m
modify it to handle nested <tt>try</tt> declarations.
</p>
<H3><a name="Customization_nn5"></a>11.1.3 Handling C++ exceptions</H3>
<H3><a name="Customization_nn5"></a>12.1.3 Handling C++ exceptions</H3>
<p>
@ -275,7 +275,7 @@ class OutOfMemory {};
</pre>
</div>
<H3><a name="Customization_allowexcept"></a>11.1.4 Exception handlers for variables</H3>
<H3><a name="Customization_allowexcept"></a>12.1.4 Exception handlers for variables</H3>
<p>
@ -300,7 +300,7 @@ The <tt>%allowexception</tt> feature works like any other feature and so can be
</pre>
</div>
<H3><a name="Customization_nn6"></a>11.1.5 Defining different exception handlers</H3>
<H3><a name="Customization_nn6"></a>12.1.5 Defining different exception handlers</H3>
<p>
@ -437,7 +437,7 @@ declarations. However, it never really worked that well and the new
%exception directive is much better.
</p>
<H3><a name="Customization_exception_special_variables"></a>11.1.6 Special variables for %exception</H3>
<H3><a name="Customization_exception_special_variables"></a>12.1.6 Special variables for %exception</H3>
<p>
@ -540,7 +540,7 @@ Below shows the expansions for the 1st of the overloaded <tt>something</tt> wrap
</pre></div>
<H3><a name="Customization_nn7"></a>11.1.7 Using The SWIG exception library</H3>
<H3><a name="Customization_nn7"></a>12.1.7 Using The SWIG exception library</H3>
<p>
@ -595,7 +595,7 @@ SWIG_NullReferenceError
The <tt>SWIG_exception()</tt> function can also be used in typemaps.
</p>
<H2><a name="Customization_ownership"></a>11.2 Object ownership and %newobject</H2>
<H2><a name="Customization_ownership"></a>12.2 Object ownership and %newobject</H2>
<p>
@ -752,7 +752,7 @@ char *strdup(const char *s);
The results might not be what you expect.
</p>
<H2><a name="Customization_features"></a>11.3 Features and the %feature directive</H2>
<H2><a name="Customization_features"></a>12.3 Features and the %feature directive</H2>
<p>
@ -834,7 +834,7 @@ The following are all equivalent:
The syntax in the first variation will generate the <tt>{ }</tt> delimiters used whereas the other variations will not.
</p>
<H3><a name="Customization_feature_attributes"></a>11.3.1 Feature attributes</H3>
<H3><a name="Customization_feature_attributes"></a>12.3.1 Feature attributes</H3>
<p>
@ -875,7 +875,7 @@ In the following example, <tt>MyExceptionClass</tt> is the name of the Java clas
Further details can be obtained from the <a href="Java.html#Java_exception_handling">Java exception handling</a> section.
</p>
<H3><a name="Customization_feature_flags"></a>11.3.2 Feature flags</H3>
<H3><a name="Customization_feature_flags"></a>12.3.2 Feature flags</H3>
<p>
@ -973,7 +973,7 @@ in the <tt>swig.swg</tt> Library file. The following shows the alternative synta
The concept of clearing features is discussed next.
</p>
<H3><a name="Customization_clearing_features"></a>11.3.3 Clearing features</H3>
<H3><a name="Customization_clearing_features"></a>12.3.3 Clearing features</H3>
<p>
@ -1066,7 +1066,7 @@ The three macros below show this for the "except" feature:
</pre>
</div>
<H3><a name="Customization_features_default_args"></a>11.3.4 Features and default arguments</H3>
<H3><a name="Customization_features_default_args"></a>12.3.4 Features and default arguments</H3>
<p>
@ -1141,7 +1141,7 @@ specifying or not specifying default arguments in a feature is not applicable as
in SWIG-1.3.23 when the approach to wrapping methods with default arguments was changed.
</p>
<H3><a name="Customization_features_example"></a>11.3.5 Feature example</H3>
<H3><a name="Customization_features_example"></a>12.3.5 Feature example</H3>
<p>

44
Doc/Manual/D.html
View file

@ -6,7 +6,7 @@
<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>
<H1><a name="D"></a>22 SWIG and D</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -41,7 +41,7 @@
<H2><a name="D_introduction"></a>21.1 Introduction</H2>
<H2><a name="D_introduction"></a>22.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>
@ -53,7 +53,7 @@
<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>
<H2><a name="D_command_line_invocation"></a>22.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>
@ -83,10 +83,10 @@
</dl>
<H2><a name="D_typemaps"></a>21.3 Typemaps</H2>
<H2><a name="D_typemaps"></a>22.3 Typemaps</H2>
<H3><a name="D_typemap_name_comparison"></a>21.3.1 C# &lt;-&gt; D name comparison</H3>
<H3><a name="D_typemap_name_comparison"></a>22.3.1 C# &lt;-&gt; D name comparison</H3>
<p>If you already know the SWIG C# module, you might find the following name comparison table useful:</p>
@ -112,7 +112,7 @@
</pre></div>
<H3><a name="D_ctype_imtype_dtype"></a>21.3.2 ctype, imtype, dtype</H3>
<H3><a name="D_ctype_imtype_dtype"></a>22.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>
@ -120,7 +120,7 @@
<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>
<H3><a name="D_in_out_directorin_direcetorout"></a>22.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>
@ -130,7 +130,7 @@
<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>
<H3><a name="D_din_dout_ddirectorin_ddirectorout"></a>22.3.4 din, dout, ddirectorin, ddirectorout</H3>
<p>Typemaps for code generation in D proxy and type wrapper classes.</p>
@ -157,13 +157,13 @@
dtype DClass.method(dtype a)</pre></div>
<H3><a name="D_typecheck_typemaps"></a>21.3.5 typecheck typemaps</H3>
<H3><a name="D_typecheck_typemaps"></a>22.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>
<H3><a name="D_code_injection_typemaps"></a>22.3.6 Code injection typemaps</H3>
<p>These typemaps are used for generating the skeleton of proxy classes for C++ types.</p>
@ -175,7 +175,7 @@
<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>
<H3><a name="D_special_variables"></a>22.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>
@ -295,7 +295,7 @@ $importtype(AnotherInterface)
</dl>
<H2><a name="D_features"></a>21.4 <tt>%feature</tt>s</H2>
<H2><a name="D_features"></a>22.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>
@ -325,7 +325,7 @@ struct A {
</dl>
<H2><a name="D_pragmas"></a>21.5 Pragmas</H2>
<H2><a name="D_pragmas"></a>22.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>
@ -364,7 +364,7 @@ struct A {
</dl>
<H2><a name="D_exceptions"></a>21.6 D Exceptions</H2>
<H2><a name="D_exceptions"></a>22.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>
@ -374,7 +374,7 @@ struct A {
<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>
<H2><a name="D_directors"></a>22.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>
@ -383,16 +383,16 @@ struct A {
</p>
<H2><a name="D_other_features"></a>21.8 Other features</H2>
<H2><a name="D_other_features"></a>22.8 Other features</H2>
<H3><a name="D_nspace"></a>21.8.1 Extended namespace support (<tt>nspace</tt>)</H3>
<H3><a name="D_nspace"></a>22.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>
<H3><a name="D_native_pointer_support"></a>22.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>
@ -404,7 +404,7 @@ struct A {
<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>
<H3><a name="D_operator_overloading"></a>22.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>
@ -416,7 +416,7 @@ struct A {
<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>
<H3><a name="D_test_suite"></a>22.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>
@ -424,14 +424,14 @@ struct A {
<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>
<H2><a name="D_typemap_examples"></a>22.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>
<H2><a name="D_planned_features"></a>22.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>

130
Doc/Manual/Extending.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Extending"></a>38 Extending SWIG to support new languages</H1>
<H1><a name="Extending"></a>40 Extending SWIG to support new languages</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -75,7 +75,7 @@
<H2><a name="Extending_nn2"></a>38.1 Introduction</H2>
<H2><a name="Extending_nn2"></a>40.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>38.2 Prerequisites</H2>
<H2><a name="Extending_nn3"></a>40.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>38.3 The Big Picture</H2>
<H2><a name="Extending_nn4"></a>40.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>38.4 Execution Model</H2>
<H2><a name="Extending_nn5"></a>40.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>38.4.1 Preprocessing</H3>
<H3><a name="Extending_nn6"></a>40.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>38.4.2 Parsing</H3>
<H3><a name="Extending_nn7"></a>40.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>38.4.3 Parse Trees</H3>
<H3><a name="Extending_nn8"></a>40.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>38.4.4 Attribute namespaces</H3>
<H3><a name="Extending_nn9"></a>40.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>38.4.5 Symbol Tables</H3>
<H3><a name="Extending_nn10"></a>40.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>38.4.6 The %feature directive</H3>
<H3><a name="Extending_nn11"></a>40.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>38.4.7 Code Generation</H3>
<H3><a name="Extending_nn12"></a>40.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>38.4.8 SWIG and XML</H3>
<H3><a name="Extending_nn13"></a>40.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>38.5 Primitive Data Structures</H2>
<H2><a name="Extending_nn14"></a>40.5 Primitive Data Structures</H2>
<p>
@ -987,7 +987,7 @@ typedef Hash Typetab;
</pre>
</div>
<H3><a name="Extending_nn15"></a>38.5.1 Strings</H3>
<H3><a name="Extending_nn15"></a>40.5.1 Strings</H3>
<p>
@ -1128,7 +1128,7 @@ Returns the number of replacements made (if any).
</div>
<H3><a name="Extending_nn16"></a>38.5.2 Hashes</H3>
<H3><a name="Extending_nn16"></a>40.5.2 Hashes</H3>
<p>
@ -1205,7 +1205,7 @@ Returns the list of hash table keys.
</div>
<H3><a name="Extending_nn17"></a>38.5.3 Lists</H3>
<H3><a name="Extending_nn17"></a>40.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>38.5.4 Common operations</H3>
<H3><a name="Extending_nn18"></a>40.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>38.5.5 Iterating over Lists and Hashes</H3>
<H3><a name="Extending_nn19"></a>40.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>38.5.6 I/O</H3>
<H3><a name="Extending_nn20"></a>40.5.6 I/O</H3>
Special I/O functions are used for all internal I/O. These operations
@ -1500,12 +1500,11 @@ Create a File object wrapper around an existing <tt>FILE *</tt> object.
</div>
<p>
<b><tt>int Close(String_or_FILE *f)</tt></b>
There's no explicit function to close a file, just call <tt>Delete(f)</tt> -
this decreases the reference count, and the file will be closed when the
reference count reaches zero.
</p>
<div class="indent">
<p>Closes a file. Has no effect on strings.</p>
<p>
The use of the above I/O functions and strings play a critical role in SWIG. It is
common to see small code fragments of code generated using code like this:
@ -1529,9 +1528,7 @@ Printf(f, "%s\n", s);
Similarly, the preprocessor and parser all operate on string-files.
</p>
</div>
<H2><a name="Extending_nn21"></a>38.6 Navigating and manipulating parse trees</H2>
<H2><a name="Extending_nn21"></a>40.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 +1662,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>38.7 Working with attributes</H2>
<H2><a name="Extending_nn22"></a>40.7 Working with attributes</H2>
<p>
@ -1782,7 +1779,7 @@ the attribute is optional. <tt>Swig_restore()</tt> must always be called after
function.
</div>
<H2><a name="Extending_nn23"></a>38.8 Type system</H2>
<H2><a name="Extending_nn23"></a>40.8 Type system</H2>
<p>
@ -1791,7 +1788,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>38.8.1 String encoding of types</H3>
<H3><a name="Extending_nn24"></a>40.8.1 String encoding of types</H3>
<p>
@ -1892,7 +1889,7 @@ make the final type, the two parts are just joined together using
string concatenation.
</p>
<H3><a name="Extending_nn25"></a>38.8.2 Type construction</H3>
<H3><a name="Extending_nn25"></a>40.8.2 Type construction</H3>
<p>
@ -2061,7 +2058,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>38.8.3 Type tests</H3>
<H3><a name="Extending_nn26"></a>40.8.3 Type tests</H3>
<p>
@ -2148,7 +2145,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>38.8.4 Typedef and inheritance</H3>
<H3><a name="Extending_nn27"></a>40.8.4 Typedef and inheritance</H3>
<p>
@ -2250,7 +2247,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>38.8.5 Lvalues</H3>
<H3><a name="Extending_nn28"></a>40.8.5 Lvalues</H3>
<p>
@ -2287,7 +2284,7 @@ Literal y; // type = 'Literal', ltype='p.char'
</pre>
</div>
<H3><a name="Extending_nn29"></a>38.8.6 Output functions</H3>
<H3><a name="Extending_nn29"></a>40.8.6 Output functions</H3>
<p>
@ -2349,7 +2346,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>38.9 Parameters</H2>
<H2><a name="Extending_nn30"></a>40.9 Parameters</H2>
<p>
@ -2448,7 +2445,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>38.10 Writing a Language Module</H2>
<H2><a name="Extending_nn31"></a>40.10 Writing a Language Module</H2>
<p>
@ -2463,7 +2460,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>38.10.1 Execution model</H3>
<H3><a name="Extending_nn32"></a>40.10.1 Execution model</H3>
<p>
@ -2473,7 +2470,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>38.10.2 Starting out</H3>
<H3><a name="Extending_starting_out"></a>40.10.2 Starting out</H3>
<p>
@ -2581,7 +2578,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>38.10.3 Command line options</H3>
<H3><a name="Extending_nn34"></a>40.10.3 Command line options</H3>
<p>
@ -2640,7 +2637,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>38.10.4 Configuration and preprocessing</H3>
<H3><a name="Extending_nn35"></a>40.10.4 Configuration and preprocessing</H3>
<p>
@ -2689,7 +2686,7 @@ an implementation file <tt>python.cxx</tt> and a configuration file
<tt>python.swg</tt>.
</p>
<H3><a name="Extending_nn36"></a>38.10.5 Entry point to code generation</H3>
<H3><a name="Extending_nn36"></a>40.10.5 Entry point to code generation</H3>
<p>
@ -2747,7 +2744,7 @@ int Python::top(Node *n) {
</pre>
</div>
<H3><a name="Extending_nn37"></a>38.10.6 Module I/O and wrapper skeleton</H3>
<H3><a name="Extending_nn37"></a>40.10.6 Module I/O and wrapper skeleton</H3>
<!-- please report bugs in this section to mgossage -->
@ -2761,8 +2758,8 @@ Within SWIG wrappers, there are five main sections. These are (in order)
<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
<li>wrapper: This section holds all the wrapper code.
<li>init: This section holds the module initialisation function
(the entry point for the interpreter).
</ul>
<p>
@ -2832,7 +2829,6 @@ int Python::top(Node *n) {
Delete(f_header);
Delete(f_wrappers);
Delete(f_init);
Close(f_begin);
Delete(f_begin);
return SWIG_OK;
@ -2896,7 +2892,7 @@ functionWrapper : void Shape_y_set(Shape *self,double y)
</pre>
</div>
<H3><a name="Extending_nn38"></a>38.10.7 Low-level code generators</H3>
<H3><a name="Extending_nn38"></a>40.10.7 Low-level code generators</H3>
<!-- please report bugs in this section to mgossage -->
@ -3005,7 +3001,7 @@ virtual int functionWrapper(Node *n) {
/* write typemaps(in) */
....
/* write constriants */
/* write constraints */
....
/* Emit the function call */
@ -3050,7 +3046,7 @@ but without the typemaps, there is still work to do.
</p>
<H3><a name="Extending_configuration_files"></a>38.10.8 Configuration files</H3>
<H3><a name="Extending_configuration_files"></a>40.10.8 Configuration files</H3>
<!-- please report bugs in this section to ttn -->
@ -3194,7 +3190,7 @@ politely displays the ignoring language message.
</dl>
<H3><a name="Extending_nn40"></a>38.10.9 Runtime support</H3>
<H3><a name="Extending_nn40"></a>40.10.9 Runtime support</H3>
<p>
@ -3203,7 +3199,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>38.10.10 Standard library files</H3>
<H3><a name="Extending_nn41"></a>40.10.10 Standard library files</H3>
<p>
@ -3222,7 +3218,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>38.10.11 User examples</H3>
<H3><a name="Extending_nn42"></a>40.10.11 User examples</H3>
<p>
@ -3251,7 +3247,7 @@ during this process, see the section on <a href="#Extending_configuration_files"
files</a>.
</p>
<H3><a name="Extending_test_suite"></a>38.10.12 Test driven development and the test-suite</H3>
<H3><a name="Extending_test_suite"></a>40.10.12 Test driven development and the test-suite</H3>
<p>
@ -3310,7 +3306,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>38.10.12.1 Running the test-suite</H4>
<H4><a name="Extending_running_test_suite"></a>40.10.12.1 Running the test-suite</H4>
<p>
@ -3350,10 +3346,10 @@ Note that if a runtime test is available, a message "(with run test)" is display
<div class="shell"><pre>
$ make check-python-test-suite
checking python test-suite
checking testcase argcargvtest (with run test) under python
checking testcase python_autodoc under python
checking testcase python_append (with run test) under python
checking testcase callback (with run test) under python
checking python testcase argcargvtest (with run test)
checking python testcase python_autodoc
checking python testcase python_append (with run test)
checking python testcase callback (with run test)
</pre></div>
<p>
@ -3496,7 +3492,13 @@ The syntax for setting environment variables varies from one shell to the next,
make ret_by_value.ctest SWIG_FEATURES="-debug-tmsearch"
</pre></div>
<H3><a name="Extending_nn43"></a>38.10.13 Documentation</H3>
<p>
There is also a special 'errors' test-suite which is a set of regression tests checking SWIG warning and error messages.
It can be run in the same way as the other language test-suites, replacing [lang] with errors, such as <tt>make check-errors-test-suite</tt>.
The test cases used and the way it works is described in <tt>Examples/test-suite/errors/Makefile.in</tt>.
</p>
<H3><a name="Extending_nn43"></a>40.10.13 Documentation</H3>
<p>
@ -3528,7 +3530,7 @@ Some topics that you'll want to be sure to address include:
if available.
</ul>
<H3><a name="Extending_prerequisites"></a>38.10.14 Prerequisites for adding a new language module to the SWIG distribution</H3>
<H3><a name="Extending_prerequisites"></a>40.10.14 Prerequisites for adding a new language module to the SWIG distribution</H3>
<p>
@ -3585,7 +3587,7 @@ should be added should there be an area not already covered by
the existing tests.
</p>
<H3><a name="Extending_coding_style_guidelines"></a>38.10.15 Coding style guidelines</H3>
<H3><a name="Extending_coding_style_guidelines"></a>40.10.15 Coding style guidelines</H3>
<p>
@ -3609,7 +3611,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>38.11 Debugging Options</H2>
<H2><a name="Extending_debugging_options"></a>40.11 Debugging Options</H2>
<p>
@ -3636,7 +3638,7 @@ There are various command line options which can aid debugging a SWIG interface
The complete list of command line options for SWIG are available by running <tt>swig -help</tt>.
</p>
<H2><a name="Extending_nn46"></a>38.12 Guide to parse tree nodes</H2>
<H2><a name="Extending_nn46"></a>40.12 Guide to parse tree nodes</H2>
<p>
@ -4044,7 +4046,7 @@ extern "X" { ... } declaration.
</pre>
</div>
<H2><a name="Extending_further_info"></a>38.13 Further Development Information</H2>
<H2><a name="Extending_further_info"></a>40.13 Further Development Information</H2>
<p>

158
Doc/Manual/Go.html
View file

@ -5,7 +5,7 @@
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body bgcolor="#FFFFFF">
<H1><a name="Go"></a>22 SWIG and Go</H1>
<H1><a name="Go"></a>23 SWIG and Go</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -43,7 +43,7 @@ the Go programming language
see <a href="http://golang.org/">golang.org</a>.
</p>
<H2><a name="Go_overview"></a>22.1 Overview</H2>
<H2><a name="Go_overview"></a>23.1 Overview</H2>
<p>
@ -55,7 +55,7 @@ there is no convenient way to call C++ code. SWIG fills this gap.
<p>
There are (at least) two different Go compilers. One is the gc
compiler, normally invoked under the names 6g, 8g, or 5g. The other
compiler, normally invoked via the go tool. The other
is the gccgo compiler, which is a frontend to the gcc compiler suite.
The interface to C/C++ code is completely different for the two Go
compilers. SWIG supports both, selected by a command line option.
@ -67,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>22.2 Running SWIG with Go</H2>
<H2><a name="Go_running_swig"></a>23.2 Running SWIG with Go</H2>
<p>
@ -76,11 +76,11 @@ 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>22.2.1 Additional Commandline Options</H3>
<H3><a name="Go_commandline"></a>23.2.1 Additional Commandline Options</H3>
<p>
These are the command line options for SWIG's GO module. They can
These are the command line options for SWIG's Go module. They can
also be seen by using:
</p>
@ -94,9 +94,9 @@ swig -go -help
</tr>
<tr>
<td>-intgo-type-size %lt;s%gt;</td>
<td>-intgosize &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
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
@ -108,7 +108,7 @@ swig -go -help
<tr>
<td>-gccgo</td>
<td>Generate code for gccgo. The default is to generate code for
6g/8g/5g.</td>
the gc compiler.</td>
</tr>
<tr>
@ -118,30 +118,39 @@ swig -go -help
</tr>
<tr>
<td>-soname %lt;name%gt;</td>
<td>-use-shlib</td>
<td>Tell SWIG to emit code that uses a shared library. This is only
meaningful for the gc compiler, which needs to know at compile time
whether a shared library will be used.</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>
the gc compiler; when using gccgo, the equivalent name will be taken from
the <code>-soname</code> option passed to the linker. Using this
option implies the -use-shlib option.</td>
</tr>
<tr>
<td>-go-pkgpath &lt;pkgpath&gt;</td>
<td>When generating code for gccgo, set the pkgpath to use. This
corresponds to the <tt>-fgo-pkgpath</tt> option to gccgo.</td>
</tr>
<tr>
<td>-go-prefix &lt;prefix&gt;</td>
<td>When generating code for gccgo, set the prefix to use. This
corresponds to the <tt>-fgo-prefix</tt> option to gccgo.</td>
</tr>
<tr>
<td>-long-type-size &lt;s&gt;</td>
<td>Set the size for the C/C++ type <tt>long</tt>. This controls
whether <tt>long</tt> is converted to the Go type <tt>int32</tt>
or <tt>int64</tt>. The &lt;s&gt; argument should be 32 or 64.</td>
corresponds to the <tt>-fgo-prefix</tt> option to gccgo.
If <tt>-go-pkgpath</tt> is used, <tt>-go-prefix</tt> will be
ignored.</td>
</tr>
</table>
<H3><a name="Go_outputs"></a>22.2.2 Go Output Files</H3>
<H3><a name="Go_outputs"></a>23.2.2 Go Output Files</H3>
<p> When generating Go code, SWIG will generate the following
@ -165,28 +174,59 @@ may be helpful to include it in your code, compiled with the usual C
or C++ compiler.
<li>
If using the gc compiler, MODULE_gc.c will contain C code which should
be compiled with the C compiler distributed as part of the gc compiler: 6c, 8c,
or 5c. It should then be combined with the compiled MODULE.go using
gopack. This file will not be generated when using gccgo.
be compiled with the C compiler distributed as part of the gc
compiler. It should then be combined with the compiled MODULE.go
using gopack. This file will not be generated when using gccgo.
</ul>
<p>
A typical command sequence would look like this:
Most Go programs are built using the go tool. The go tool has limited
support for SWIG. To use it, put your SWIG interface into a file with
the extension .swig, or, if you are wrapping C++ code, .swigcxx. Put
that file in a GOPATH/src directory as usual for Go sources. Put
other interface code in the same directory with extensions of .c and
.cxx. The go build command and go install commands will automatically
run SWIG for you and will build the interface code.
</p>
<p>
You can also use SWIG directly yourself. When using the gc compiler
version 1.2 or later, or when using gccgo, the code generated by SWIG
can be linked directly into the Go program. A typical command
sequence when using the gc compiler would look like this:
</p>
<div class="code"><pre>
% swig -go example.i
% gcc -c code.c # The C library being wrapped.
% gcc -c example_wrap.c
% go tool 6g example.go
% go tool 6c example_gc.c
% go tool pack grc example.a example.6 example_gc.6 code.o example_wrap.o
% go tool 6g main.go
% go tool 6l main.6
</pre></div>
<p>
You can also put the wrapped code into a shared library, and when
using the gc compiler before version 1.2 this is the only supported
option. A typical command sequence for this approach would look like
this:
</p>
<div class="code"><pre>
% swig -go -use-shlib example.i
% gcc -c -fpic example.c
% gcc -c -fpic example_wrap.c
% gcc -shared example.o example_wrap.o -o example.so
% 6g example.go
% 6c example_gc.c
% gopack grc example.a example.6 example_gc.6
% 6g main.go # your code, not generated by SWIG
% 6l main.6
% go tool 6g example.go
% go tool 6c example_gc.c
% go tool pack grc example.a example.6 example_gc.6
% go tool 6g main.go # your code, not generated by SWIG
% go tool 6l main.6
</pre></div>
<H2><a name="Go_basic_tour"></a>22.3 A tour of basic C/C++ wrapping</H2>
<H2><a name="Go_basic_tour"></a>23.3 A tour of basic C/C++ wrapping</H2>
<p>
@ -196,7 +236,7 @@ modifications have to occur. This section briefly covers the
essential aspects of this wrapping.
</p>
<H3><a name="Go_package"></a>22.3.1 Go Package Name</H3>
<H3><a name="Go_package"></a>23.3.1 Go Package Name</H3>
<p>
@ -206,7 +246,7 @@ directive. You may override this by using SWIG's <tt>-package</tt>
command line option.
</p>
<H3><a name="Go_names"></a>22.3.2 Go Names</H3>
<H3><a name="Go_names"></a>23.3.2 Go Names</H3>
<p>
@ -238,7 +278,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>22.3.3 Go Constants</H3>
<H3><a name="Go_constants"></a>23.3.3 Go Constants</H3>
<p>
@ -246,7 +286,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>22.3.4 Go Enumerations</H3>
<H3><a name="Go_enumerations"></a>23.3.4 Go Enumerations</H3>
<p>
@ -256,7 +296,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>22.3.5 Go Classes</H3>
<H3><a name="Go_classes"></a>23.3.5 Go Classes</H3>
<p>
@ -334,7 +374,7 @@ 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>
<H4><a name="Go_class_inheritance"></a>23.3.5.1 Go Class Inheritance</H4>
<p>
@ -346,7 +386,7 @@ Doing the reverse will require an explicit type assertion, which will
be checked dynamically.
</p>
<H3><a name="Go_templates"></a>22.3.6 Go Templates</H3>
<H3><a name="Go_templates"></a>23.3.6 Go Templates</H3>
<p>
@ -354,7 +394,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>22.3.7 Go Director Classes</H3>
<H3><a name="Go_director_classes"></a>23.3.7 Go Director Classes</H3>
<p>
@ -397,7 +437,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>22.3.8 Default Go primitive type mappings</H3>
<H3><a name="Go_primitive_type_mappings"></a>23.3.8 Default Go primitive type mappings</H3>
<p>
@ -454,12 +494,12 @@ uses a given C/C++ type.
<tr>
<td>long</td>
<td>int32 or int64, depending on <tt>-long-type-size</tt></td>
<td>int64</td>
</tr>
<tr>
<td>unsigned long</td>
<td>uint32 or uint64, depending on <tt>-long-type-size</tt></td>
<td>uint64</td>
</tr>
<tr>
@ -504,7 +544,7 @@ 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>
<H3><a name="Go_output_arguments"></a>23.3.9 Output arguments</H3>
<p>Because of limitations in the way output arguments are processed in swig,
@ -557,7 +597,7 @@ void f(char *output);
</pre>
</div>
<H3><a name="Go_adding_additional_code"></a>22.3.10 Adding additional go code</H3>
<H3><a name="Go_adding_additional_code"></a>23.3.10 Adding additional go code</H3>
<p>Often the APIs generated by swig are not very natural in go, especially if
@ -626,9 +666,31 @@ func (arg SwigcptrWrapped_MyClass) GetAValue() (int, bool) {
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>
<p>If you need to import other go packages, you can do this with
<code>%go_import</code>. For example,</p>
<div class="code">
<pre>
%go_import("fmt", _ "unusedPackage", rp "renamed/package")
%insert(go_wrapper) %{
func foo() {
fmt.Println("Some string:", rp.GetString())
}
// Importing the same package twice is permitted,
// Go code will be generated with only the first instance of the import.
%go_import("fmt")
%insert(go_wrapper) %{
func bar() {
fmt.Println("Hello world!")
}
%}
</pre>
</div>
</body>
</html>

42
Doc/Manual/Guile.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Guile"></a>23 SWIG and Guile</H1>
<H1><a name="Guile"></a>24 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_nn1"></a>23.1 Supported Guile Versions</H2>
<H2><a name="Guile_nn1"></a>24.1 Supported Guile Versions</H2>
<p>
@ -61,7 +61,7 @@ improved performance. This is currently not tested with swig
so your mileage may vary. To be safe set environment variable
GUILE_AUTO_COMPILE to 0 when using swig generated guile code.
<H2><a name="Guile_nn2"></a>23.2 Meaning of "Module"</H2>
<H2><a name="Guile_nn2"></a>24.2 Meaning of "Module"</H2>
<p>
@ -69,7 +69,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>23.3 Old GH Guile API</H2>
<H2><a name="Guile_nn3"></a>24.3 Old GH Guile API</H2>
<p>Guile 1.8 and older could be interfaced using two different api's, the SCM
@ -80,7 +80,7 @@ or the GH API. The GH interface to guile is deprecated. Read more about why in
version of SWIG that can still generate guile GH wrapper code is 2.0.9. Please
use that version if you really need the GH wrapper code.
<H2><a name="Guile_nn4"></a>23.4 Linkage</H2>
<H2><a name="Guile_nn4"></a>24.4 Linkage</H2>
<p>
@ -88,7 +88,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>23.4.1 Simple Linkage</H3>
<H3><a name="Guile_nn5"></a>24.4.1 Simple Linkage</H3>
<p>
@ -193,7 +193,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>23.4.2 Passive Linkage</H3>
<H3><a name="Guile_nn6"></a>24.4.2 Passive Linkage</H3>
<p>Passive linkage is just like simple linkage, but it generates an
@ -203,7 +203,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>23.4.3 Native Guile Module Linkage</H3>
<H3><a name="Guile_nn7"></a>24.4.3 Native Guile Module Linkage</H3>
<p>SWIG can also generate wrapper code that does all the Guile module
@ -244,7 +244,7 @@ Newer Guile versions have a shorthand procedure for this:
</div>
</ul>
<H3><a name="Guile_nn8"></a>23.4.4 Old Auto-Loading Guile Module Linkage</H3>
<H3><a name="Guile_nn8"></a>24.4.4 Old Auto-Loading Guile Module Linkage</H3>
<p>Guile used to support an autoloading facility for object-code
@ -270,7 +270,7 @@ option, SWIG generates an exported module initialization function with
an appropriate name.
<H3><a name="Guile_nn9"></a>23.4.5 Hobbit4D Linkage</H3>
<H3><a name="Guile_nn9"></a>24.4.5 Hobbit4D Linkage</H3>
<p>
@ -295,7 +295,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>23.5 Underscore Folding</H2>
<H2><a name="Guile_nn10"></a>24.5 Underscore Folding</H2>
<p>
@ -307,7 +307,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>23.6 Typemaps</H2>
<H2><a name="Guile_nn11"></a>24.6 Typemaps</H2>
<p>
@ -399,7 +399,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>23.7 Representation of pointers as smobs</H2>
<H2><a name="Guile_nn12"></a>24.7 Representation of pointers as smobs</H2>
<p>
@ -420,7 +420,7 @@ representing the expected pointer type. See also
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_nn14"></a>23.7.1 Smobs</H3>
<H3><a name="Guile_nn14"></a>24.7.1 Smobs</H3>
<p>
@ -439,7 +439,7 @@ structure describing this type. If a generated GOOPS module has been loaded, sm
the corresponding GOOPS class.</p>
<H3><a name="Guile_nn15"></a>23.7.2 Garbage Collection</H3>
<H3><a name="Guile_nn15"></a>24.7.2 Garbage Collection</H3>
<p>Garbage collection is a feature of Guile since version 1.6. As SWIG now requires Guile &gt; 1.8,
@ -453,7 +453,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>23.8 Exception Handling</H2>
<H2><a name="Guile_nn16"></a>24.8 Exception Handling</H2>
<p>
@ -479,7 +479,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>23.9 Procedure documentation</H2>
<H2><a name="Guile_nn17"></a>24.9 Procedure documentation</H2>
<p>If invoked with the command-line option <code>-procdoc
@ -514,7 +514,7 @@ like this:
typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
details.
<H2><a name="Guile_nn18"></a>23.10 Procedures with setters</H2>
<H2><a name="Guile_nn18"></a>24.10 Procedures with setters</H2>
<p>For global variables, SWIG creates a single wrapper procedure
@ -542,7 +542,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>23.11 GOOPS Proxy Classes</H2>
<H2><a name="Guile_nn19"></a>24.11 GOOPS Proxy Classes</H2>
<p>SWIG can also generate classes and generic functions for use with
@ -688,7 +688,7 @@ Notice that &lt;Foo&gt; 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>23.11.1 Naming Issues</H3>
<H3><a name="Guile_nn20"></a>24.11.1 Naming Issues</H3>
<p>As you can see in the example above, there are potential naming conflicts. The default exported
@ -725,7 +725,7 @@ guile-modules. For example,</p>
(use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:)))
</pre></div>
<H3><a name="Guile_nn21"></a>23.11.2 Linking</H3>
<H3><a name="Guile_nn21"></a>24.11.2 Linking</H3>
<p>The guile-modules generated above all need to be linked together. GOOPS support requires

14
Doc/Manual/Introduction.html
View file

@ -38,7 +38,7 @@
SWIG is a software development tool that simplifies the task of
interfacing different languages to C and C++ programs. In a
nutshell, SWIG is a compiler that takes C/C++ declarations and creates
the wrappers needed to access those declarations from other languages including
the wrappers needed to access those declarations from other languages
including Perl, Python, Tcl, Ruby, Guile, and Java. SWIG normally
requires no modifications to existing code and can often be used to
build a usable interface in only a few minutes. Possible applications
@ -49,7 +49,7 @@ of SWIG include:
<li>Building interpreted interfaces to existing C programs.
<li>Rapid prototyping and application development.
<li>Interactive debugging.
<li>Reengineering or refactoring of legacy software into a scripting language components.
<li>Reengineering or refactoring of legacy software into scripting language components.
<li>Making a graphical user interface (using Tk for example).
<li>Testing of C libraries and programs (using scripts).
<li>Building high performance C modules for scripting languages.
@ -98,7 +98,7 @@ of other libraries).
<li>Testing is time consuming (the compile/debug cycle).
<li>Not easy to reconfigure or customize without recompilation.
<li>Modularization can be tricky.
<li>Security concerns (buffer overflow for instance).
<li>Security concerns (buffer overflows for instance).
</ul>
<p>
To address these limitations, many programmers have arrived at the
@ -345,7 +345,7 @@ not only parses C++, it implements the full C++ type system and it is
able to understand C++ semantics. SWIG generates its wrappers with
full knowledge of this information. As a result, you will find SWIG
to be just as capable of dealing with nasty corner cases as it is in
wrapping simple C++ code. In fact, SWIG is able handle C++ code that
wrapping simple C++ code. In fact, SWIG is able to handle C++ code that
stresses the very limits of many C++ compilers.
@ -388,8 +388,8 @@ There is growing support for SWIG in some build tools, for example <a href="http
is a cross-platform, open-source build manager with built in support for SWIG. CMake can detect the SWIG executable
and many of the target language libraries for linking against.
CMake knows how to build shared libraries and loadable modules on many different operating systems.
This allows easy cross platform SWIG development. It also can generate the custom commands necessary for
driving SWIG from IDE's and makefiles. All of this can be done from a single cross platform input file.
This allows easy cross platform SWIG development. It can also generate the custom commands necessary for
driving SWIG from IDEs and makefiles. All of this can be done from a single cross platform input file.
The following example is a CMake input file for creating a python wrapper for the SWIG interface file, example.i:
</p>
@ -449,7 +449,7 @@ to work with complicated and unusual C/C++ applications.
<p>
Ironically, the freedom that SWIG provides is countered by an
extremely conservative approach to code generation. At it's core, SWIG
extremely conservative approach to code generation. At its core, SWIG
tries to distill even the most advanced C++ code down to a small
well-defined set of interface building techniques based on ANSI C
programming. Because of this, you will find that SWIG interfaces can

565
Doc/Manual/Java.html
View file

File diff suppressed because it is too large Load diff

976
Doc/Manual/Javascript.html Normal file
View file

@ -0,0 +1,976 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<link rel="stylesheet" type="text/css" href="./style.css">
<title></title>
</head>
<body>
<H1><a name="Javascript"></a>26 SWIG and Javascript</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="#Javascript_overview">Overview</a>
<li><a href="#Javascript_preliminaries">Preliminaries</a>
<ul>
<li><a href="#Javascript_running_swig">Running SWIG</a>
<li><a href="#Javascript_running_tests_examples">Running Tests and Examples</a>
<li><a href="#Javascript_known_issues">Known Issues</a>
</ul>
<li><a href="#Javascript_integration">Integration</a>
<ul>
<li><a href="#Javascript_node_extensions">Creating node.js Extensions</a>
<ul>
<li><a href="#Javascript_troubleshooting">Troubleshooting</a>
</ul>
<li><a href="#Javascript_embedded_webkit">Embedded Webkit</a>
<ul>
<li><a href="#Javascript_osx">OSX</a>
<li><a href="#Javascript_gtk">GTK</a>
</ul>
<li><a href="#Javascript_applications_webkit">Creating Applications with node-webkit</a>
</ul>
<li><a href="#Javascript_nn14">Examples</a>
<ul>
<li><a href="#Javascript_simple_example">Simple</a>
<li><a href="#Javascript_class_example">Class</a>
</ul>
<li><a href="#Javascript_implementation">Implementation</a>
<ul>
<li><a href="#Javascript_source_code">Source Code</a>
<li><a href="#Javascript_code_templates">Code Templates</a>
<li><a href="#Javascript_emitter">Emitter</a>
<li><a href="#Javascript_emitter_states">Emitter states</a>
<li><a href="#Javascript_jsc_exceptions">Handling Exceptions in JavascriptCore</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<p>This chapter describes SWIG's support of Javascript. It does not cover SWIG basics, but only information that is specific to this module.</p>
<H2><a name="Javascript_overview"></a>26.1 Overview</H2>
<p>Javascript is a prototype-based scripting language that is dynamic, weakly typed and has first-class functions. Its arguably the most popular language for web development.
Javascript has gone beyond being a browser-based scripting language and with <a href="http://nodejs.org">node.js</a>, it is also used as a backend development language.</p>
<p>Native Javascript extensions can be used for applications that embed a web-browser view or that embed a Javascript engine (such as <em>node.js</em>). Extending a general purpose web-browser is not possible as this would be a severe security issue.</p>
<p>SWIG Javascript currently supports <strong>JavascriptCore</strong>, the Javascript engine used by <code>Safari/Webkit</code>, and <a href="https://developers.google.com/v8"><strong>v8</strong></a>, which is used by <code>Chromium</code> and <code>node.js</code>.</p>
<p><a href="http://www.webkit.org/">WebKit</a> is a modern browser implementation available as open-source which can be embedded into an application.
With <a href="https://github.com/rogerwang/node-webkit">node-webkit</a> there is a platform which uses Google's <code>Chromium</code> as Web-Browser widget and <code>node.js</code> for javascript extensions.
</p>
<H2><a name="Javascript_preliminaries"></a>26.2 Preliminaries</H2>
<H3><a name="Javascript_running_swig"></a>26.2.1 Running SWIG</H3>
<p>Suppose that you defined a SWIG module such as the following:</p>
<div class="code">
<pre>
%module example
%{
#include "example.h"
%}
int gcd(int x, int y);
extern double Foo;</pre>
</div>
<p>To build a Javascript module, run SWIG using the <code>-javascript</code> option and a desired target engine <code>-jsc</code>, <code>-v8</code>, or <code>-node</code>. The generator for <code>node</code> is essentially delegating to the <code>v8</code> generator and adds some necessary preprocessor definitions.</p>
<div class="shell">
<pre>
$ swig -javascript -jsc example.i</pre>
</div>
<p>If building a C++ extension, add the -c++ option:</p>
<div class="shell">
<pre>
$ swig -c++ -javascript -jsc example.i</pre>
</div>
<p>This creates a C/C++ source file <code>example_wrap.c</code> or <code>example_wrap.cxx</code>. The generated C source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application to create an extension module.</p>
<p>The name of the wrapper file is derived from the name of the input file. For example, if the input file is <code>example.i</code>, the name of the wrapper file is <code>example_wrap.c</code>. To change this, you can use the -o option. The wrapped module will export one function which must be called to register the module with the Javascript interpreter. For example, if your module is named <code>example</code> the corresponding initializer for JavascriptCore would be</p>
<div class="code">
<pre>
bool example_initialize(JSGlobalContextRef context, JSObjectRef *exports)</pre>
</div>
<p>and for v8:</p>
<div class="code">
<pre>
void example_initialize(v8::Handle&lt;v8::Object&gt; exports)</pre>
</div>
<p>
<b>Note</b>: be aware that <code>v8</code> has a C++ API, and thus, the generated modules must be compiled as C++.
</p>
<H3><a name="Javascript_running_tests_examples"></a>26.2.2 Running Tests and Examples</H3>
<p>The configuration for tests and examples currently supports Linux and Mac only and not MinGW (Windows) yet.</p>
<p>The default interpreter is <code>node.js</code> as it is available on all platforms and convenient to use.</p>
<p>Running the examples with JavascriptCore requires <code>libjavascriptcoregtk-1.0</code> to be installed, e.g., under Ubuntu with</p>
<div class="shell">
<pre>
$ sudo apt-get install libjavascriptcoregtk-1.0-dev</pre>
</div>
<p>Running with <code>V8</code> requires <code>libv8</code>:</p>
<div class="shell">
<pre>
$ sudo apt-get install libv8-dev</pre>
</div>
<p>Examples can be run using</p>
<div class="shell">
<pre>
$ make check-javascript-examples ENGINE=jsc</pre>
</div>
<p><code>ENGINE</code> can be <code>node</code>, <code>jsc</code>, or <code>v8</code>.</p>
<p>The test-suite can be run using</p>
<div class="shell">
<pre>
$ make check-javascript-test-suite ENGINE=jsc</pre>
</div>
<H3><a name="Javascript_known_issues"></a>26.2.3 Known Issues</H3>
<p>At the moment, the Javascript generators pass all tests syntactically, i.e., the generated source code compiles. However, there are still remaining runtime issues.</p>
<ul>
<li><p>Default optional arguments do not work for all targeted interpreters</p></li>
<li><p>Multiple output arguments do not work for JSC</p></li>
<li><p>C89 incompatibily: the JSC generator might still generate C89 violating code</p></li>
<li><p><code>long long</code> is not supported</p></li>
<li><p><code>%native</code> is not supported</p></li>
<li><p>Javascript callbacks are not supported</p></li>
<li><p><code>instanceOf</code> does not work under JSC</p></li>
</ul>
<p>The primary development environment has been Linux (Ubuntu 12.04). Windows and OSX have been tested sporadically. Therefore, the generators might have more issues on those platforms. Please report back any problem you observe to help us improving this module quickly.</p>
<H2><a name="Javascript_integration"></a>26.3 Integration</H2>
<p>This chapter gives a short introduction how to use a native Javascript extension: as a <code>node.js</code> module, and as an extension for an embedded Webkit.</p>
<H3><a name="Javascript_node_extensions"></a>26.3.1 Creating node.js Extensions</H3>
<p>To install <code>node.js</code> you can download an installer from their <a href="https://launchpad.net/~chris-lea/+archive/node.js">web-site</a> for OSX and Windows. For Linux you can either build the source yourself and run <code>sudo checkinstall</code> or keep to the (probably stone-age) packaged version. For Ubuntu there is a <a href="https://launchpad.net/~chris-lea/+archive/node.js/">PPA</a> available.</p>
<div class="shell">
<pre>
$ sudo add-apt-repository ppa:chris-lea/node.js
$ sudo apt-get update
$ sudo apt-get install nodejs</pre>
</div>
<p>As <code>v8</code> is written in C++ and comes as a C++ library it is crucial to compile your module using the same compiler flags as used for building v8. To make things easier, <code>node.js</code> provides a build tool called <code>node-gyp</code>.</p>
<p>You have to install it using <code>npm</code>:</p>
<div class="shell">
<pre>
$ sudo npm install -g node-gyp</pre>
</div>
<p><code>node-gyp</code> expects a configuration file named <code>binding.gyp</code> which is basically in JSON format and conforms to the same format that is used with Google's build-tool <code>gyp</code>.</p>
<p><code>binding.gyp</code>:</p>
<div class="code">
<pre>
{
"targets": [
{
"target_name": "example",
"sources": [ "example.cxx", "example_wrap.cxx" ]
}
]
}</pre>
</div>
<p>First create the wrapper using SWIG:</p>
<div class="shell">
<pre>
$ swig -javascript -node -c++ example.cxx</pre>
</div>
<p>Then run <code>node-gyp</code></p>
<div class="shell">
<pre>
$ node-gyp</pre>
</div>
<p>This will create a <code>build</code> folder containing the native module. To use the extension you need to 'require' it in your Javascript source file:</p>
<div class="code">
<pre>
require("./build/Release/example")</pre>
</div>
<p>A more detailed explanation is given in the <a href="#Javascript_examples">Examples</a> section.</p>
<H4><a name="Javascript_troubleshooting"></a>26.3.1.1 Troubleshooting</H4>
<ul>
<li><em>'module' object has no attribute 'script_main'</em></li>
</ul>
<p>This error happens when <code>gyp</code> is installed as a distribution package. It seems to be outdated. Removing it resolves the problem.</p>
<div class="shell">
<pre>
$ sudo apt-get remove gyp</pre>
</div>
<H3><a name="Javascript_embedded_webkit"></a>26.3.2 Embedded Webkit</H3>
<p>Webkit is pre-installed on OSX and available as a library for GTK.</p>
<H4><a name="Javascript_osx"></a>26.3.2.1 OSX</H4>
<p>There is general information about programming with WebKit on <a href="https://developer.apple.com/library/mac/documentation/cocoa/conceptual/DisplayWebContent/DisplayWebContent.html">Apple Developer Documentation</a>. Details about <code>Cocoa</code> programming are not covered here.</p>
<p>An integration of a native extension 'example' would look like this:</p>
<div class="code">
<pre>
#import "appDelegate.h"
extern bool example_initialize(JSGlobalContextRef context, JSObjectRef* exports);
@implementation ExampleAppDelegate
@synthesize webView;
- (void)addGlobalObject:(JSContextRef) context:(NSString *)objectName:(JSObjectRef) theObject {
JSObjectRef global = JSContextGetGlobalObject(context);
JSStringRef objectJSName = JSStringCreateWithCFString( (CFStringRef) objectName )
if ( objectJSName != NULL ) {
JSObjectSetProperty(context, global, objectJSName, theObject, kJSPropertyAttributeReadOnly, NULL);
JSStringRelease( objectJSName );
}
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Start a webview with the bundled index.html file
NSString *path = [[NSBundle mainBundle] bundlePath];
NSString *url = [NSString stringWithFormat: @"file://%@/Contents/Assets/index.html", path];
WebFrame *webframe = [webView mainFrame];
JSGlobalContextRef context = [webframe globalContext];
JSObjectRef example;
example_initialize(context, &amp;example);
[self addGlobalObject:context:@"example":example]
JSObjectSetProperty(context, global, JSStringRef propertyName, example, JSPropertyAttributes attributes, NULL);
[ [webView mainFrame] loadRequest:
[NSURLRequest requestWithURL: [NSURL URLWithString:url] ]
];
}
@end</pre>
</div>
<H4><a name="Javascript_gtk"></a>26.3.2.2 GTK</H4>
<p>There is general information about programming GTK at <a href="https://developer.gnome.org/gtk2/">GTK documentation</a> and in the <a href="https://developer.gnome.org/gtk-tutorial">GTK tutorial</a>, and for Webkit there is a <a href="http://webkitgtk.org/reference/webkitgtk/stable/index.html">Webkit GTK+ API Reference</a>.</p>
<p>An integration of a native extension 'example' would look like this:</p>
<div class="code">
<pre>
#include &lt;gtk/gtk.h&gt;
#include &lt;webkit/webkit.h&gt;
extern bool example_initialize(JSGlobalContextRef context);
int main(int argc, char* argv[])
{
// Initialize GTK+
gtk_init(&amp;argc, &amp;argv);
...
// Create a browser instance
WebKitWebView *webView = WEBKIT_WEB_VIEW(webkit_web_view_new());
WebFrame *webframe = webkit_web_view_get_main_frame(webView);
JSGlobalContextRef context = webkit_web_frame_get_global_context(webFrame);
JSObjectRef global = JSContextGetGlobalObject(context);
JSObjectRef exampleModule;
example_initialize(context, &amp;exampleModule);
JSStringRef jsName = JSStringCreateWithUTF8CString("example");
JSObjectSetProperty(context, global, jsName, exampleModule, kJSPropertyAttributeReadOnly, NULL);
JSStringRelease(jsName);
...
// Load a web page into the browser instance
webkit_web_view_load_uri(webView, "http://www.webkitgtk.org/");
...
// Run the main GTK+ event loop
gtk_main();
return 0;
}</pre>
</div>
<H3><a name="Javascript_applications_webkit"></a>26.3.3 Creating Applications with node-webkit</H3>
<p>To get started with <code>node-webkit</code> there is a very informative set of <a href="https://github.com/rogerwang/node-webkit/wiki">wiki pages</a>.</p>
<p>Similar to <code>node.js</code>, <code>node-webkit</code> is started from command line within a <code>node.js</code> project directory.
Native extensions are created in the very same way as for <code>node.js</code>, except that a customized <code>gyp</code> derivate has to be used: <a href="https://github.com/rogerwang/nw-gyp">nw-gyp</a>.
</p>
<p>
A simple example would have the following structure:
</p>
<div class="code">
<pre>
- package.json
- app.html
- app.js
- node_modules
/ example
... (as known from node.js)
</pre>
</div>
<p>
The configuration file essentially conforms to <code>node.js</code> syntax.
It has some extras to configure <code>node-webkit</code>. See the <a href="https://github.com/rogerwang/node-webkit/wiki/Manifest-format">Manifest</a> specification for more details.
</p>
<p>
<code>package.json</code>:
</p>
<div class="code">
<pre>
{
"name": "example"
"main": "app.html"
"window": {
"show": true,
"width": 800,
"height": 600
}
}</pre>
</div>
<p>
The <code>'main'</code> property of <code>package.json</code> specifies a web-page to be rendered in
the main window.</p>
<p>
<code>app.html</code>:
</p>
<div class="code">
<pre>
&lt;html&gt;
&lt;head&gt;
&lt;script src="app.js"&gt;&lt;/script&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;div&gt;
The greatest common divisor of
&lt;span id="x"&gt;&lt;/span&gt; and
&lt;span id="y"&gt;&lt;/span&gt; is
&lt;span id="z"&gt;&lt;/span&gt;.
&lt;/div&gt;
&lt;/body&gt;
&lt;/html&gt;</pre>
</div>
<p>
As known from <code>node.js</code> one can use <code>require</code> to load javascript modules.
Additionally, <code>node-webkit</code> provides an API that allows to manipulate the window's menu,
open new windows, and many more things.
</p>
<p>
<code>app.js</code>:
</p>
<div class="code">
<pre>window.onload = function() {
var example = require("example");
var x = 18;
var y = 24;
var z = example.gcd(x,y);
document.querySelector('#x').innerHTML = x;
document.querySelector('#y').innerHTML = y;
document.querySelector('#z').innerHTML = z;
};</pre>
</div>
<H2><a name="Javascript_nn14"></a>26.4 Examples</H2>
<p>Some basic examples are shown here in more detail.</p>
<H3><a name="Javascript_simple_example"></a>26.4.1 Simple</H3>
<p>The common example <code>simple</code> looks like this:</p>
<div class="code">
<pre>
/* File : example.i */
%module example
%inline %{
extern int gcd(int x, int y);
extern double Foo;
%}</pre>
</div>
<p>To make this available as a node extension a <code>binding.gyp</code> has to be created:</p>
<div class="code">
<pre>
{
"targets": [
{
"target_name": "example",
"sources": [ "example.cxx", "example_wrap.cxx" ]
}
]
}</pre>
</div>
<p>Then <code>node-gyp</code> is used to build the extension:</p>
<div class="shell">
<pre>
$ node-gyp configure build</pre>
</div>
<p>From a 'nodejs` application the extension would be used like this:</p>
<div class="code">
<pre>
// import the extension via require
var example = require("./build/Release/example");
// calling the global method
var x = 42;
var y = 105;
var g = example.gcd(x,y);
// Accessing the globak variable
var f = example.Foo;
example.Foo = 3.1415926;</pre>
</div>
<p>First the module <code>example</code> is loaded from the previously built extension. Global methods and variables are available in the scope of the module.</p>
<p><b>Note</b>: ECMAScript 5, the currently implemented Javascript standard, does not have modules. <code>node.js</code> and other implementations provide this mechanism defined by the <a href="http://wiki.commonjs.org/wiki/CommonJS">CommonJS</a> group. For browsers this is provided by <a href="http://browserify.org">Browserify</a>, for instance.</p>
<H3><a name="Javascript_class_example"></a>26.4.2 Class</H3>
<p>The common example <code>class</code> defines three classes, <code>Shape</code>, <code>Circle</code>, and <code>Square</code>:</p>
<div class="code">
<pre>
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><code>Circle</code> and <code>Square</code> inherit from <code>Shape</code>. <code>Shape</code> has a static variable <code>nshapes</code>, a function <code>move</code> that can't be overridden (non-virtual), and two abstract functions <code>area</code> and <code>perimeter</code> (pure virtual) that must be overridden by the sub-classes.</p>
<p>A <code>nodejs</code> extension is built the same way as for the <code>simple</code> example.</p>
<p>In Javascript it can be used as follows:</p>
<div class="code">
<pre>
var example = require("./build/Release/example");
// local aliases for convenience
var Shape = example.Shape;
var Circle = example.Circle;
var Square = example.Square;
// creating new instances using the 'new' operator
var c = new Circle(10);
var s = new Square(10);
// accessing a static member
Shape.nshapes;
// accessing member variables
c.x = 20;
c.y = 30;
s.x = -10;
s.y = 5;
// calling some methods
c.area();
c.perimeter();
s.area();
s.perimeter();
// instantiation of Shape is not permitted
new Shape();</pre>
</div>
<p>Running these commands in an interactive node shell results in the following output:</p>
<div class="shell">
<pre>
$ node -i
&amp; var example = require("./build/Release/example");
undefined
&amp; var Shape = example.Shape;
undefined
&amp; var Circle = example.Circle;
undefined
&amp; var Square = example.Square;
undefined
&amp; var c = new Circle(10);
undefined
&amp; var s = new Square(10);
undefined
&amp; Shape.nshapes;
2
&amp; c.x = 20;
20
&amp; c.y = 30;
30
&amp; s.x = -10;
-10
&amp; s.y = 5;
5
&amp; c.area();
314.1592653589793
&amp; c.perimeter();
62.83185307179586
&amp; s.area();
100
&amp; s.perimeter();
40
&amp; c.move(40, 40)
undefined
&amp; c.x
60
&amp; c.y
70
&amp; new Shape()
Error: Class Shape can not be instantiated
at repl:1:2
at REPLServer.self.eval (repl.js:110:21)
at Interface.&lt;anonymous&gt; (repl.js:239:12)
at Interface.EventEmitter.emit (events.js:95:17)
at Interface._onLine (readline.js:202:10)
at Interface._line (readline.js:531:8)
at Interface._ttyWrite (readline.js:760:14)
at ReadStream.onkeypress (readline.js:99:10)
at ReadStream.EventEmitter.emit (events.js:98:17)
at emitKey (readline.js:1095:12)</pre>
</div>
<p>
<b>Note</b>: In ECMAScript 5 there is no concept for classes. Instead each function can be used as a constructor function which is executed by the 'new' operator. Furthermore, during construction the key property <code>prototype</code> of the constructor function is used to attach a prototype instance to the created object. A prototype is essentially an object itself that is the first-class delegate of a class used whenever the access to a property of an object fails. The very same prototype instance is shared among all instances of one type. Prototypal inheritance is explained in more detail on in <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain">Inheritance and the prototype chain</a>, for instance.
</p>
<H2><a name="Javascript_implementation"></a>26.5 Implementation</H2>
<p>The Javascript Module implementation has taken a very different approach compared to other language modules in order to support different Javascript interpreters.</p>
<H3><a name="Javascript_source_code"></a>26.5.1 Source Code</H3>
<p>The Javascript module is implemented in <code>Source/Modules/javascript.cxx</code>. It dispatches the code generation to a <code>JSEmitter</code> instance, <code>V8Emitter</code> or <code>JSCEmitter</code>. Additionally there are some helpers: <code>Template</code>, for templated code generation, and <code>JSEmitterState</code>, which is used to manage state information during AST traversal. This rough map shall make it easier to find a way through this huge source file:</p>
<div class="code">
<pre>
// module wide defines
#define NAME "name"
...
// ###############################
// # Helper class declarations
class JSEmitterState { ... };
class Template { ... };
// ###############################
// # JSEmitter declaration
class JSEmitter { ... };
// Emitter factory declarations
JSEmitter *swig_javascript_create_JSCEmitter();
JSEmitter *swig_javascript_create_V8Emitter();
// ###############################
// # Javascript module
// Javascript module declaration
class JAVASCRIPT:public Language { ... };
// Javascript module implementation
int JAVASCRIPT::functionWrapper(Node *n) { ... }
...
// Module factory implementation
static Language *new_swig_javascript() { ... }
extern "C" Language *swig_javascript(void) { ... }
// ###############################
// # JSEmitter base implementation
JSEmitter::JSEmitter() { ... }
Template JSEmitter::getTemplate(const String *name) { ... }
...
// ###############################
// # JSCEmitter
// JSCEmitter declaration
class JSCEmitter: public JSEmitter { ... };
// JSCEmitter implementation
JSCEmitter::JSCEmitter() { ... }
void JSCEmitter::marshalInputArgs(Node *n, ParmList *parms, Wrapper *wrapper, MarshallingMode mode, bool is_member, bool is_static) { ... }
...
// JSCEmitter factory
JSEmitter *swig_javascript_create_JSCEmitter() { ... }
// ###############################
// # V8Emitter
// V8Emitter declaration
class V8Emitter: public JSEmitter { ... };
// V8Emitter implementation
V8Emitter::V8Emitter() { ... }
int V8Emitter::initialize(Node *n) { ... }
// V8Emitter factory
JSEmitter *swig_javascript_create_V8Emitter() { ... }
// ###############################
// # Helper implementation (JSEmitterState, Template)
JSEmitterState::JSEmitterState() { ... }
...
Template::Template(const String *code_) { ... }
...</pre>
</div>
<H3><a name="Javascript_code_templates"></a>26.5.2 Code Templates</H3>
<p>All generated code is created on the basis of code templates. The templates for <em>JavascriptCore</em> can be found in <code>Lib/javascript/jsc/javascriptcode.swg</code>, for <em>v8</em> in <code>Lib/javascript/v8/javascriptcode.swg</code>.</p>
<p>To track the originating code template for generated code you can run</p>
<div class="shell">
<pre>
$ swig -javascript -jsc -debug-codetemplates</pre>
</div>
<p>which wraps generated code with a descriptive comment</p>
<div class="code">
<pre>
/* begin fragment("template_name") */
...generated code ...
/* end fragment("template_name") */</pre>
</div>
<p>The Template class is used like this:</p>
<div class="code">
<pre>
Template t_register = getTemplate("jsv8_register_static_variable");
t_register.replace("$jsparent", state.clazz(NAME_MANGLED))
.replace("$jsname", state.variable(NAME))
.replace("$jsgetter", state.variable(GETTER))
.replace("$jssetter", state.variable(SETTER))
.trim().
print(f_init_static_wrappers);</pre>
</div>
<p>A code template is registered with the <em>JSEmitter</em> via <code>fragment(name, &quot;template&quot;)</code>, e.g.,</p>
<div class="code">
<pre>
%fragment ("jsc_variable_declaration", "templates")
%{
{"$jsname", $jsgetter, $jssetter, kJSPropertyAttributeNone},
%}</pre>
</div>
<p><code>Template</code> creates a copy of that string and <code>Template::replace</code> uses Swig's <code>Replaceall</code> to replace variables in the template. <code>Template::trim</code> can be used to eliminate leading and trailing whitespaces. <code>Template::print</code> is used to write the final template string to a Swig <code>DOH</code> (based on <code>Printv</code>). All methods allow chaining.</p>
<H3><a name="Javascript_emitter"></a>26.5.3 Emitter</H3>
<p>The Javascript module delegates code generation to a <code>JSEmitter</code> instance. The following extract shows the essential interface:</p>
<div class="code">
<pre>
class JSEmitter {
...
/**
* Opens output files and temporary output DOHs.
*/
virtual int initialize(Node *n);
/**
* Writes all collected code into the output file(s).
*/
virtual int dump(Node *n) = 0;
/**
* Cleans up all open output DOHs.
*/
virtual int close() = 0;
...
/**
* Invoked at the beginning of the classHandler.
*/
virtual int enterClass(Node *);
/**
* Invoked at the end of the classHandler.
*/
virtual int exitClass(Node *) {
return SWIG_OK;
};
/**
* Invoked at the beginning of the variableHandler.
*/
virtual int enterVariable(Node *);
/**
* Invoked at the end of the variableHandler.
*/
virtual int exitVariable(Node *) {
return SWIG_OK;
};
/**
* Invoked at the beginning of the functionHandler.
*/
virtual int enterFunction(Node *);
/**
* Invoked at the end of the functionHandler.
*/
virtual int exitFunction(Node *) {
return SWIG_OK;
};
/**
* Invoked by functionWrapper callback after call to Language::functionWrapper.
*/
virtual int emitWrapperFunction(Node *n);
/**
* Invoked from constantWrapper after call to Language::constantWrapper.
**/
virtual int emitConstant(Node *n);
/**
* Registers a given code snippet for a given key name.
*
* This method is called by the fragmentDirective handler
* of the JAVASCRIPT language module.
**/
int registerTemplate(const String *name, const String *code);
/**
* Retrieve the code template registered for a given name.
*/
Template getTemplate(const String *name);
State &amp;getState();
...
}</pre>
</div>
<p>The module calls <code>initialize</code>, <code>dump</code>, and <code>close</code> from within the <code>top</code> method:</p>
<div class="code">
<pre>
int JAVASCRIPT::top(Node *n) {
emitter-&gt;initialize(n);
Language::top(n);
emitter-&gt;dump(n);
emitter-&gt;close();
return SWIG_OK;
}</pre>
</div>
<p>The methods <code>enterClass</code> and <code>exitClass</code> are called from within the <code>classHandler</code> method:</p>
<div class="code">
<pre>
int JAVASCRIPT::classHandler(Node *n) {
emitter-&gt;enterClass(n);
Language::classHandler(n);
emitter-&gt;exitClass(n);
return SWIG_OK;
}</pre>
</div>
<p>In <code>enterClass</code> the emitter stores state information that is necessary when processing class members. In <code>exitClass</code> the wrapper code for the whole class is generated.</p>
<H3><a name="Javascript_emitter_states"></a>26.5.4 Emitter states</H3>
<p>For storing information during the AST traversal the emitter provides a <code>JSEmitterState</code> with different slots to store data representing the scopes global, class, function, and variable.</p>
<div class="code">
<pre>
class JSEmitterState {
public:
JSEmitterState();
~JSEmitterState();
DOH *global();
DOH *global(const char* key, DOH *initial = 0);
DOH *clazz(bool reset = false);
DOH *clazz(const char* key, DOH *initial = 0);
DOH *function(bool reset = false);
DOH *function(const char* key, DOH *initial = 0);
DOH *variable(bool reset = false);
DOH *variable(const char* key, DOH *initial = 0);
static int IsSet(DOH *val);
...
};</pre>
</div>
<p>When entering a scope, such as in <code>enterClass</code>, the corresponding state is reset and new data is stored:</p>
<div class="code">
<pre>
state.clazz(RESET);
state.clazz(NAME, Getattr(n, "sym:name"));</pre>
</div>
<p>State information can be retrieved using <code>state.clazz(NAME)</code> or with <code>Getattr</code> on <code>state.clazz()</code> which actually returns a <code>Hash</code> instance.</p>
<H3><a name="Javascript_jsc_exceptions"></a>26.5.5 Handling Exceptions in JavascriptCore</H3>
<p>Applications with an embedded JavascriptCore should be able to present detailed exception messages that occur in the Javascript engine. Below is an example derived from code provided by Brian Barnes on how these exception details can be extracted.</p>
<div class="code">
<pre>
void script_exception_to_string(JSContextRef js_context,JSValueRef exception_value_ref,char* return_error_string, int return_error_string_max_length)
{
JSObjectRef exception_object;
JSValueRef value_ref;
JSStringRef jsstring_property_name = NULL;
JSValueRef temporary_exception = NULL;
JSStringRef js_return_string = NULL;
size_t bytes_needed;
char* c_result_string = NULL;
exception_object = JSValueToObject(js_context, exception_value_ref, NULL);
/* source url */
strcpy(return_error_string,&quot;[&quot;);
jsstring_property_name = JSStringCreateWithUTF8CString(&quot;sourceURL&quot;);
value_ref = JSObjectGetProperty(js_context, exception_object, jsstring_property_name, &amp;temporary_exception);
JSStringRelease(jsstring_property_name);
js_return_string = JSValueToStringCopy(js_context, value_ref, NULL);
bytes_needed = JSStringGetMaximumUTF8CStringSize(js_return_string);
c_result_string = (char*)calloc(bytes_needed, sizeof(char));
JSStringGetUTF8CString(js_return_string, c_result_string, bytes_needed);
JSStringRelease(js_return_string);
strncat(return_error_string, c_result_string, return_error_string_max_length-1);
free(c_result_string);
strncat(return_error_string, &quot;:&quot;, return_error_string_max_length-1);
/* line number */
jsstring_property_name = JSStringCreateWithUTF8CString(&quot;line&quot;);
value_ref = JSObjectGetProperty(js_context, exception_object, jsstring_property_name, &amp;temporary_exception);
JSStringRelease(jsstring_property_name);
js_return_string = JSValueToStringCopy(js_context, value_ref, NULL);
bytes_needed = JSStringGetMaximumUTF8CStringSize(js_return_string);
c_result_string = (char*)calloc(bytes_needed, sizeof(char));
JSStringGetUTF8CString(js_return_string, c_result_string, bytes_needed);
JSStringRelease(js_return_string);
strncat(return_error_string, c_result_string, return_error_string_max_length-1);
free(c_result_string);
strncat(return_error_string, &quot;]&quot;, return_error_string_max_length-1);
/* error message */
jsstring_property_name = JSStringCreateWithUTF8CString(&quot;message&quot;);
value_ref = JSObjectGetProperty(js_context, exception_object, jsstring_property_name, &amp;temporary_exception);
JSStringRelease(jsstring_property_name);
if(NULL == value_ref)
{
strncat(return_error_string, &quot;Unknown Error&quot;, return_error_string_max_length-1);
}
else
{
js_return_string = JSValueToStringCopy(js_context, value_ref, NULL);
bytes_needed = JSStringGetMaximumUTF8CStringSize(js_return_string);
c_result_string = (char*)calloc(bytes_needed, sizeof(char));
JSStringGetUTF8CString(js_return_string, c_result_string, bytes_needed);
JSStringRelease(js_return_string);
strncat(return_error_string, c_result_string, return_error_string_max_length-1);
free(c_result_string);
}
}</pre>
</div>
<p>It would be used in the following way:</p>
<div class="code">
<pre>
if(js_exception)
{
char return_error_string[256];
script_exception_to_string(js_context, js_exception, return_error_string, 256);
printf("Compile error is %s", return_error_string);
}</pre>
</div>
</body>
</html>

125
Doc/Manual/Library.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Library"></a>8 SWIG library</H1>
<H1><a name="Library"></a>9 SWIG library</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -31,6 +31,7 @@
<li><a href="#Library_std_vector">std::vector</a>
<li><a href="#Library_stl_exceptions">STL exceptions</a>
<li><a href="#Library_std_shared_ptr">shared_ptr smart pointer</a>
<li><a href="#Library_std_auto_ptr">auto_ptr smart pointer</a>
</ul>
<li><a href="#Library_nn16">Utility Libraries</a>
<ul>
@ -58,7 +59,7 @@ Alternative libraries provide similar functionality. Please read this chapter
carefully if you used the old libraries.
</p>
<H2><a name="Library_nn2"></a>8.1 The %include directive and library search path</H2>
<H2><a name="Library_nn2"></a>9.1 The %include directive and library search path</H2>
<p>
@ -90,7 +91,7 @@ Set the environment variable to hold an alternative library directory.
The directories that are searched are displayed when using <tt>-verbose</tt> commandline option.
</p>
<H2><a name="Library_nn3"></a>8.2 C Arrays and Pointers</H2>
<H2><a name="Library_nn3"></a>9.2 C Arrays and Pointers</H2>
<p>
@ -102,7 +103,7 @@ pointers as class-like objects. Since these functions provide direct access to
memory, their use is potentially unsafe and you should exercise caution.
</p>
<H3><a name="Library_nn4"></a>8.2.1 cpointer.i</H3>
<H3><a name="Library_nn4"></a>9.2.1 cpointer.i</H3>
<p>
@ -318,7 +319,7 @@ In this example, the function <tt>int_to_uint()</tt> would be used to cast type
<b>Note:</b> When working with simple pointers, typemaps can often be used to provide more seamless operation.
</p>
<H3><a name="Library_carrays"></a>8.2.2 carrays.i</H3>
<H3><a name="Library_carrays"></a>9.2.2 carrays.i</H3>
<p>
@ -496,7 +497,7 @@ you should consider using a special array object rather than a bare pointer.
used with types of <tt>char</tt> or <tt>char *</tt>.
</p>
<H3><a name="Library_nn6"></a>8.2.3 cmalloc.i</H3>
<H3><a name="Library_nn6"></a>9.2.3 cmalloc.i</H3>
<p>
@ -657,7 +658,7 @@ Now, in a script:
</pre>
</div>
<H3><a name="Library_nn7"></a>8.2.4 cdata.i</H3>
<H3><a name="Library_nn7"></a>9.2.4 cdata.i</H3>
<p>
@ -759,7 +760,7 @@ char *cdata_<em>name</em>(type* ptr, int nitems)
Clearly they are unsafe.
</p>
<H2><a name="Library_nn8"></a>8.3 C String Handling</H2>
<H2><a name="Library_nn8"></a>9.3 C String Handling</H2>
<p>
@ -779,7 +780,7 @@ morality. The modules in this section provide basic functionality
for manipulating raw C strings.
</p>
<H3><a name="Library_nn9"></a>8.3.1 Default string handling</H3>
<H3><a name="Library_nn9"></a>9.3.1 Default string handling</H3>
<p>
@ -820,7 +821,7 @@ interpreter and lead to a crash). Furthermore, the default behavior does
not work well with binary data. Instead, strings are assumed to be NULL-terminated.
</p>
<H3><a name="Library_nn10"></a>8.3.2 Passing binary data</H3>
<H3><a name="Library_nn10"></a>9.3.2 Passing binary data</H3>
<p>
@ -862,7 +863,7 @@ In the wrapper function, the passed string will be expanded to a pointer and len
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>
<H3><a name="Library_nn11"></a>9.3.3 Using %newobject to release memory</H3>
<p>
@ -903,7 +904,7 @@ however, you may need to provide your own "newfree" typemap for other types.
See <a href="Customization.html#Customization_ownership">Object ownership and %newobject</a> for more details.
</p>
<H3><a name="Library_nn12"></a>8.3.4 cstring.i</H3>
<H3><a name="Library_nn12"></a>9.3.4 cstring.i</H3>
<p>
@ -1363,7 +1364,7 @@ structure or class instead.
</li>
</ul>
<H2><a name="Library_stl_cpp_library"></a>8.4 STL/C++ Library</H2>
<H2><a name="Library_stl_cpp_library"></a>9.4 STL/C++ Library</H2>
<p>
@ -1383,6 +1384,7 @@ The following table shows which C++ classes are supported and the equivalent SWI
<td><b>SWIG Interface library file</b></td>
</tr>
<tr> <td>std::auto_ptr</td> <td>memory</td> <td>std_auto_ptr.i</td> </tr>
<tr> <td>std::deque</td> <td>deque</td> <td>std_deque.i</td> </tr>
<tr> <td>std::list</td> <td>list</td> <td>std_list.i</td> </tr>
<tr> <td>std::map</td> <td>map</td> <td>std_map.i</td> </tr>
@ -1400,7 +1402,7 @@ Please look for the library files in the appropriate language library directory.
</p>
<H3><a name="Library_std_string"></a>8.4.1 std::string</H3>
<H3><a name="Library_std_string"></a>9.4.1 std::string</H3>
<p>
@ -1484,7 +1486,7 @@ void foo(string s, const String &amp;t); // std_string typemaps still applie
</pre>
</div>
<H3><a name="Library_std_vector"></a>8.4.2 std::vector</H3>
<H3><a name="Library_std_vector"></a>9.4.2 std::vector</H3>
<p>
@ -1663,7 +1665,7 @@ if you want to make their head explode.
details and the public API exposed to the interpreter vary.
</p>
<H3><a name="Library_stl_exceptions"></a>8.4.3 STL exceptions</H3>
<H3><a name="Library_stl_exceptions"></a>9.4.3 STL exceptions</H3>
<p>
@ -1713,13 +1715,28 @@ The <tt>%exception</tt> directive can be used by placing the following code befo
Any thrown STL exceptions will then be gracefully handled instead of causing a crash.
</p>
<H3><a name="Library_std_shared_ptr"></a>8.4.4 shared_ptr smart pointer</H3>
<H3><a name="Library_std_shared_ptr"></a>9.4.4 shared_ptr smart pointer</H3>
<p>
Some target languages have support for handling the widely used <tt>boost::shared_ptr</tt> smart pointer.
This smart pointer is also available as <tt>std::tr1::shared_ptr</tt> before it becomes fully standardized as <tt>std::shared_ptr</tt>.
The <tt>boost_shared_ptr.i</tt> library provides support for <tt>boost::shared_ptr</tt> and <tt>std_shared_ptr.i</tt> provides support for <tt>std::shared_ptr</tt>, but if the following macro is defined as shown, it can be used for <tt>std::tr1::shared_ptr</tt>:
Some target languages have support for handling the shared_ptr reference counted smart pointer.
This smart pointer is available in the standard C++11 library as <tt>std::shared_ptr</tt>.
It was also in TR1 as <tt>std::tr1::shared_ptr</tt> before it was fully standardized.
Support for the widely used <tt>boost::shared_ptr</tt> is also available.
</p>
<p>
In order to use <tt>std::shared_ptr</tt>, the <tt>std_shared_ptr.i</tt> library file should be included:
</p>
<div class="code">
<pre>
%include &lt;std_shared_ptr.i&gt;
</pre>
</div>
<p>
The pre-standard <tt>std::tr1::shared_ptr</tt> can be used by including the following macro before including the <tt>std_shared_ptr.i</tt> library file:
</p>
<div class="code">
@ -1729,6 +1746,16 @@ The <tt>boost_shared_ptr.i</tt> library provides support for <tt>boost::shared_p
</pre>
</div>
<p>
In order to use <tt>boost::shared_ptr</tt>, the <tt>boost_shared_ptr.i</tt> library file should be included:
</p>
<div class="code">
<pre>
%include &lt;boost_shared_ptr.i&gt;
</pre>
</div>
<p>
You can only use one of these variants of shared_ptr in your interface file at a time.
and all three variants must be used in conjunction with the <tt>%shared_ptr(T)</tt> macro,
@ -1872,12 +1899,64 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
</pre>
</div>
<p>
<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>
</p>
<H3><a name="Library_nn17"></a>8.5.1 exception.i</H3>
<H3><a name="Library_std_auto_ptr"></a>9.4.5 auto_ptr smart pointer</H3>
<p>
While <tt>std::auto_ptr</tt> is deprecated in C++11, some existing code may
still be using it, so SWIG provides limited support for this class:
<tt>std_auto_ptr.i</tt> defines the typemaps which apply to the functions
returning objects of this type. Any other use of <tt>std_auto_ptr.i</tt> is not
directly supported.
</p>
<p>
A typical example of use would be
</p>
<div class="code">
<pre>
%include &lt;std_auto_ptr.i&gt;
%auto_ptr(Klass)
%inline %{
class Klass {
public:
// Factory function creating objects of this class:
static std::auto_ptr&lt;Klass&gt; Create(int value) {
return std::auto_ptr&lt;Klass&gt;(new Klass(value));
}
int getValue() const { return m_value; }
private:
DerivedIntValue(int value) : m_value(value) {}
int m_value;
};
%}
</pre>
</div>
<p>
The returned objects can be used naturally from the target language, e.g. from
C#:
</p>
<div class="targetlang">
<pre>
Klass k = Klass.Create(17);
int value = k.getValue();
</pre>
</div>
<H2><a name="Library_nn16"></a>9.5 Utility Libraries</H2>
<H3><a name="Library_nn17"></a>9.5.1 exception.i</H3>
<p>

24
Doc/Manual/Lisp.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Lisp"></a>25 SWIG and Common Lisp</H1>
<H1><a name="Lisp"></a>27 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>25.1 Allegro Common Lisp</H2>
<H2><a name="Lisp_nn2"></a>27.1 Allegro Common Lisp</H2>
<p>
@ -50,7 +50,7 @@
<a href="Allegrocl.html#Allegrocl">here</a>
</p>
<H2><a name="Lisp_nn3"></a>25.2 Common Foreign Function Interface(CFFI)</H2>
<H2><a name="Lisp_nn3"></a>27.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>25.2.1 Additional Commandline Options </H3>
<H3><a name="Lisp_nn4"></a>27.2.1 Additional Commandline Options </H3>
<p>
@ -118,11 +118,11 @@ swig -cffi -help
</table>
<H3><a name="Lisp_nn5"></a>25.2.2 Generating CFFI bindings</H3>
<H3><a name="Lisp_nn5"></a>27.2.2 Generating CFFI bindings</H3>
As we mentioned earlier the ideal way to use SWIG is to use interface
files. To illustrate the use of it, lets assume that we have a
files. To illustrate the use of it, let's assume that we have a
file named <i>test.h</i> with the following C code:
<div class="code"><pre>
@ -392,7 +392,7 @@ The feature <i>intern_function</i> ensures that all C names are
</pre></div>
<H3><a name="Lisp_nn6"></a>25.2.3 Generating CFFI bindings for C++ code</H3>
<H3><a name="Lisp_nn6"></a>27.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>25.2.4 Inserting user code into generated files</H3>
<H3><a name="Lisp_nn7"></a>27.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>25.3 CLISP</H2>
<H2><a name="Lisp_nn8"></a>27.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>25.3.1 Additional Commandline Options </H3>
<H3><a name="Lisp_nn9"></a>27.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>25.3.2 Details on CLISP bindings</H3>
<H3><a name="Lisp_nn10"></a>27.3.2 Details on CLISP bindings</H3>
<p>
@ -795,7 +795,7 @@ struct bar {
</pre></div>
<H2><a name="Lisp_nn11"></a>25.4 UFFI </H2>
<H2><a name="Lisp_nn11"></a>27.4 UFFI </H2>
</body>

379
Doc/Manual/Lua.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Lua"></a>26 SWIG and Lua</H1>
<H1><a name="Lua"></a>28 SWIG and Lua</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -24,8 +24,11 @@
<li><a href="#Lua_nn9">Functions</a>
<li><a href="#Lua_nn10">Global variables</a>
<li><a href="#Lua_nn11">Constants and enums</a>
<ul>
<li><a href="#Lua_nn13">Constants/enums and classes/structures</a>
</ul>
<li><a href="#Lua_nn12">Pointers</a>
<li><a href="#Lua_nn13">Structures</a>
<li><a href="#Lua_structures">Structures</a>
<li><a href="#Lua_nn14">C++ classes</a>
<li><a href="#Lua_nn15">C++ inheritance</a>
<li><a href="#Lua_nn16">Pointers, references, values, and arrays</a>
@ -36,17 +39,23 @@
<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>
<li><a href="#Lua_namespaces">Namespaces </a>
<ul>
<li><a href="#Lua_nn27">Compatibility Note </a>
<li><a href="#Lua_nn29">Names </a>
<li><a href="#Lua_nn30">Inheritance </a>
</ul>
</ul>
<li><a href="#Lua_nn24">Typemaps</a>
<ul>
<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>
<li><a href="#Lua_typemap_arrays">Typemaps and arrays</a>
<li><a href="#Lua_typemaps_ptr_ptr_functions">Typemaps and pointer-pointer functions</a>
</ul>
<li><a href="#Lua_nn29">Writing typemaps</a>
<li><a href="#Lua_writing_typemaps">Writing typemaps</a>
<ul>
<li><a href="#Lua_nn30">Typemaps you can write</a>
<li><a href="#Lua_typemaps_write">Typemaps you can write</a>
<li><a href="#Lua_nn31">SWIG's Lua-C API</a>
</ul>
<li><a href="#Lua_nn32">Customization of your Bindings</a>
@ -73,14 +82,14 @@ Lua is an extension programming language designed to support general procedural
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>
<H2><a name="Lua_nn2"></a>28.1 Preliminaries</H2>
<p>
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.
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 has support for eLua starting from eLua 0.8. Due to substantial changes between SWIG 2.x and SWIG 3.0 and unavailability of testing platform, eLua status was downgraded to 'experimental'.
</p>
<H2><a name="Lua_nn3"></a>26.2 Running SWIG</H2>
<H2><a name="Lua_nn3"></a>28.2 Running SWIG</H2>
<p>
@ -128,7 +137,7 @@ $ swig -lua -eluac example.i
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>
<H3><a name="Lua_commandline"></a>28.2.1 Additional command line options</H3>
<p>
@ -159,9 +168,17 @@ swig -lua -help
<td>Do not register the module name as a global variable but return the module table from calls to require.</td>
</tr>
<tr>
<td>-no-old-metatable-bindings</td>
<td>Disable backward compatibility: old-style binding names generations and a few other things. Explanations are included in appropriate later sections.</td>
</tr>
<tr>
<td>-squash-bases</td>
<td>Squashes symbols from all inheritance tree of a given class into itself. Emulates pre-SWIG3.0 inheritance. Insignificantly speeds things up, but increases memory consumption.</td>
</tr>
</table>
<H3><a name="Lua_nn4"></a>26.2.2 Compiling and Linking and Interpreter</H3>
<H3><a name="Lua_nn4"></a>28.2.2 Compiling and Linking and Interpreter</H3>
<p>
@ -232,7 +249,7 @@ LUALIB_API int ( luaopen_mod )(lua_State *L );
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>
<H3><a name="Lua_nn5"></a>28.2.3 Compiling a dynamic module</H3>
<p>
@ -240,8 +257,8 @@ Most, but not all platforms support the dynamic loading of modules (Windows &amp
</p>
<div class="shell"><pre>
$ swig -lua example.i -o example_wrap.c
$ gcc -I/usr/include/lua -c example_wrap.c -o example_wrap.o
$ gcc -c example.c -o example.o
$ gcc -fPIC -I/usr/include/lua -c example_wrap.c -o example_wrap.o
$ gcc -fPIC -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>
@ -300,7 +317,7 @@ Is quite obvious (Go back and consult the Lua documents on how to enable loadlib
<H3><a name="Lua_nn6"></a>26.2.4 Using your module</H3>
<H3><a name="Lua_nn6"></a>28.2.4 Using your module</H3>
<p>
@ -318,19 +335,19 @@ $ ./my_lua
&gt;
</pre></div>
<H2><a name="Lua_nn7"></a>26.3 A tour of basic C/C++ wrapping</H2>
<H2><a name="Lua_nn7"></a>28.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>26.3.1 Modules</H3>
<H3><a name="Lua_nn8"></a>28.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>26.3.2 Functions</H3>
<H3><a name="Lua_nn9"></a>28.3.2 Functions</H3>
<p>
@ -349,7 +366,10 @@ creates a built-in function <tt>example.fact(n)</tt> that works exactly like you
&gt;
</pre></div>
<p>
To avoid name collisions, SWIG create a Lua table which it keeps all the functions and global variables in. It is possible to copy the functions out of this and into the global environment with the following code. This can easily overwrite existing functions, so this must be used with care.
To avoid name collisions, SWIG create a Lua table which keeps all the functions, constants, classes and global variables in.
It is possible to copy the functions, constants and classes (but not variables) out of this and into the global environment with the following code.
This can easily overwrite existing functions, so this must be used with care.
This option is considered deprecated and will be removed in the near future.
</p>
<div class="targetlang"><pre>
&gt; for k,v in pairs(example) do _G[k]=v end
@ -368,7 +388,7 @@ It is also possible to rename the module with an assignment.
24
</pre></div>
<H3><a name="Lua_nn10"></a>26.3.3 Global variables</H3>
<H3><a name="Lua_nn10"></a>28.3.3 Global variables</H3>
<p>
@ -456,7 +476,7 @@ If you have used the <tt>-eluac</tt> option for your eLua module, you will have
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>26.3.4 Constants and enums</H3>
<H3><a name="Lua_nn11"></a>28.3.4 Constants and enums</H3>
<p>
@ -490,7 +510,64 @@ If you're using eLua and have used <tt>-elua</tt> or <tt>-eluac</tt> to generate
&gt; print(example.const.SCONST)
Hello World
</pre></div>
<H3><a name="Lua_nn12"></a>26.3.5 Pointers</H3>
<H4><a name="Lua_nn13"></a>28.3.4.1 Constants/enums and classes/structures</H4>
<p>
Enums are exported into a class table. For example, given some enums:
</p>
<div class="code"><pre>%module example
enum Days { SUNDAY = 0, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY };
struct Test {
enum { TEST1 = 10, TEST2 = 20 };
#ifdef __cplusplus // There are no static members in C
static const int ICONST = 12;
#endif
};
</pre></div>
<p>
There is a slight difference in behaviour wrapping C and C++ code due to the different scoping rules of C and C++.
The wrapped C++ code is used as follows from Lua code:
</p>
<div class="targetlang"><pre>
&gt; print(example.SUNDAY)
0
&gt; print(example.Test.TEST1)
10
&gt; print(example.Test.ICONST)
12
</pre></div>
<p>Enums within a C struct are in the global namespace and are used as follows from Lua</p>
<div class="targetlang"><pre>
&gt; print(example.SUNDAY)
0
&gt; -- See the difference here
&gt; print(example.TEST1)
10
</pre></div>
<p>
<b>Compatibility Note:</b> Versions of SWIG prior to SWIG-3.0.0 did not generate the class table members above.
There is no change in the C wrappers, but
the following code was the only way to access these constants/enums when wrapping C++ member constants:
</p>
<div class="targetlang"><pre>
&gt; print(example.Test_TEST1)
10
&gt; print(example.Test_ICONST)
12
</pre></div>
<p>
The old-style bindings are still generated in addition to the new ones.
If the <tt>-no-old-metatable-bindings</tt> option is used, then these old-style bindings are not generated.
</p>
<p>
It is worth mentioning, that <tt>example.Test.TEST1</tt> and <tt>example.Test_TEST1</tt> are different entities and changing one does not change the other.
Given the fact that these are constantes and they are not supposed to be changed, it is up to you to avoid such issues.
</p>
<H3><a name="Lua_nn12"></a>28.3.5 Pointers</H3>
<p>
@ -528,7 +605,7 @@ Lua enforces the integrity of its userdata, so it is virtually impossible to cor
nil
</pre></div>
<H3><a name="Lua_nn13"></a>26.3.6 Structures</H3>
<H3><a name="Lua_structures"></a>28.3.6 Structures</H3>
<p>
@ -551,7 +628,7 @@ is used as follows:
</pre></div>
<p>
Similar access is provided for unions and the data members of C++ classes.<br>
C structures are created using a function <tt>new_Point()</tt>, but for C++ classes are created using just the name <tt>Point()</tt>.
C structures can be created using a function <tt>new_Point()</tt>, and both C structures and C++ classes can be created using just the name <tt>Point()</tt>.
</p>
<p>
If you print out the value of p in the above example, you will see something like this:
@ -632,7 +709,7 @@ For eLua with the <tt>-eluac</tt> option, structure manipulation has to be perfo
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>
<H3><a name="Lua_nn14"></a>28.3.7 C++ classes</H3>
<p>
@ -676,12 +753,12 @@ public:
};
</pre></div>
<p>
In Lua, the static members can be accessed as follows:
In Lua, C++ static members can be accessed as follows:
</p>
<div class="code"><pre>
&gt; example.Spam_foo() -- calling Spam::foo()
&gt; a=example.Spam_bar -- reading Spam::bar
&gt; example.Spam_bar=b -- writing to Spam::bar
&gt; example.Spam.foo() -- calling Spam::foo()
&gt; a=example.Spam.bar -- reading Spam::bar
&gt; example.Spam.bar=b -- writing to Spam::bar
</pre></div>
<p>
It is not (currently) possible to access static members of an instance:
@ -692,7 +769,22 @@ It is not (currently) possible to access static members of an instance:
-- does NOT work
</pre></div>
<H3><a name="Lua_nn15"></a>26.3.8 C++ inheritance</H3>
<p>
<b>Compatibility Note:</b> In versions prior to SWIG-3.0.0 only the following names would work:
</p>
<div class="code"><pre>
&gt; example.Spam_foo() -- calling Spam::foo()
&gt; a=example.Spam_bar -- reading Spam::bar
&gt; example.Spam_bar=b -- writing to Spam::bar
</pre></div>
<p>
Both style names are generated by default now.
However, if the <tt>-no-old-metatable-bindings</tt> option is used, then the backward compatible names are not generated in addition to ordinary ones.
</p>
<H3><a name="Lua_nn15"></a>28.3.8 C++ inheritance</H3>
<p>
@ -717,7 +809,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>26.3.9 Pointers, references, values, and arrays</H3>
<H3><a name="Lua_nn16"></a>28.3.9 Pointers, references, values, and arrays</H3>
<p>
@ -748,7 +840,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>26.3.10 C++ overloaded functions</H3>
<H3><a name="Lua_nn17"></a>28.3.10 C++ overloaded functions</H3>
<p>
@ -834,7 +926,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>26.3.11 C++ operators</H3>
<H3><a name="Lua_nn18"></a>28.3.11 C++ operators</H3>
<p>
@ -898,10 +990,10 @@ The current list of operators which can be overloaded (and the alternative funct
<li><tt>__sub__</tt> operator-
<li><tt>__mul__</tt> operator *
<li><tt>__div__</tt> operator/
<li><tt>__neg__</tt> unary minus
<li><tt>__unm__</tt> unary minus
<li><tt>__call__</tt> operator<tt>()</tt> (often used in functor classes)
<li><tt>__pow__</tt> the exponential fn (no C++ equivalent, Lua uses <tt>^</tt>)
<li><tt>__concat__</tt> the concatenation operator (SWIG maps C++'s <tt>~</tt> to Lua's <tt>..</tt>)
<li><tt>__concat__</tt> the concatenation operator (Lua's <tt>..</tt>)
<li><tt>__eq__</tt> operator<tt>==</tt>
<li><tt>__lt__</tt> operator<tt>&lt;</tt>
<li><tt>__le__</tt> operator<tt>&lt;=</tt>
@ -945,8 +1037,30 @@ It is also possible to overload the operator<tt>[]</tt>, but currently this cann
void __setitem__(int i,double d); // i is the index, d is the data
};
</pre></div>
<H3><a name="Lua_nn19"></a>26.3.12 Class extension with %extend</H3>
<p>
C++ operators are mapped to Lua predefined metafunctions. Class inherits from its bases the following list of metafunctions ( thus inheriting the folloging
operators and pseudo-operators):</p>
<ul>
<li><tt>__add__</tt>
<li><tt>__sub__</tt>
<li><tt>__mul__</tt>
<li><tt>__div__</tt>
<li><tt>__unm__</tt>
<li><tt>__mod__</tt>
<li><tt>__call__</tt>
<li><tt>__pow__</tt>
<li><tt>__concat__</tt>
<li><tt>__eq__</tt>
<li><tt>__lt__</tt>
<li><tt>__le__</tt>
<li><tt>__len__</tt>
<li><tt>__getitem__</tt>
<li><tt>__setitem__</tt>
<li><tt>__tostring</tt> used internally by Lua for tostring() function. __str__ is mapped to this function
</ul>
<p>No other lua metafunction is inherited. For example, __gc is not inherited and must be redefined in every class. <tt>__tostring</tt> is subject to a special handling. If absent in class and in class bases, a default one will be provided by SWIG.
</p>
<H3><a name="Lua_nn19"></a>28.3.12 Class extension with %extend</H3>
<p>
@ -981,7 +1095,7 @@ Now we extend it with some new code
return tmp;
}
bool operator==(const Complex&amp; c)
{ return ($self-&gt;re()==c.re() &amp;&amp; $self-&gt;im()==c.im();}
{ return ($self-&gt;re()==c.re() &amp;&amp; $self-&gt;im()==c.im());}
};
</pre></div>
<p>
@ -1002,7 +1116,7 @@ true
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>26.3.13 Using %newobject to release memory</H3>
<H3><a name="Lua_nn20"></a>28.3.13 Using %newobject to release memory</H3>
<p> If you have a function that allocates memory like this,</p>
@ -1026,7 +1140,7 @@ char *foo();
</div>
<p> This will release the allocated memory.</p>
<H3><a name="Lua_nn21"></a>26.3.14 C++ templates</H3>
<H3><a name="Lua_nn21"></a>28.3.14 C++ templates</H3>
<p>
@ -1061,7 +1175,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_nn22"></a>26.3.15 C++ Smart Pointers</H3>
<H3><a name="Lua_nn22"></a>28.3.15 C++ Smart Pointers</H3>
<p>
@ -1113,7 +1227,7 @@ If you ever need to access the underlying pointer returned by <tt>operator-&gt;(
&gt; f = p:__deref__() -- Returns underlying Foo *
</pre></div>
<H3><a name="Lua_nn23"></a>26.3.16 C++ Exceptions</H3>
<H3><a name="Lua_nn23"></a>28.3.16 C++ Exceptions</H3>
<p>
@ -1256,13 +1370,164 @@ and the "<a href="Customization.html#Customization_exception">Exception handling
add exception specification to functions or globally (respectively).
</p>
<H3><a name="Lua_namespaces"></a>28.3.17 Namespaces </H3>
<H2><a name="Lua_nn24"></a>26.4 Typemaps</H2>
<p>
Since SWIG-3.0.0 C++ namespaces are supported via the %nspace feature.
</p>
<p> Namespaces are mapped into Lua tables. Each of those tables contains names that were defined within appropriate namespace. Namespaces structure (a.k.a nested namespaces) is preserved. Consider the following C++ code:
</p>
<div class="code"><pre>%module example
%nspace MyWorld::Nested::Dweller;
%nspace MyWorld::World;
int module_function() { return 7; }
int module_variable = 9;
namespace MyWorld {
class World {
public:
World() : world_max_count(9) {}
int create_world() { return 17; }
const int world_max_count; // = 9
};
namespace Nested {
class Dweller {
public:
enum Gender { MALE = 0, FEMALE = 1 };
static int count() { return 19; }
};
}
}
</pre></div>
<p>
Now, from Lua usage is as follows:
</p>
<div class="targetlang"><pre>
&gt; print(example.module_function())
7
&gt; print(example.module_variable)
9
&gt; print(example.MyWorld.World():create_world())
17
&gt; print(example.MyWorld.World.world_max_count)
9
&gt; print(example.MyWorld.Nested.Dweller.MALE)
0
&gt; print(example.MyWorld.Nested.Dweller.count())
19
&gt;
</pre></div>
<H4><a name="Lua_nn27"></a>28.3.17.1 Compatibility Note </H4>
<p>
If SWIG is running in a backwards compatible way, i.e. without the <tt>-no-old-metatable-bindings</tt> option, then additional old-style names are generated (notice the underscore):
</p>
<div class="targetlang"><pre>
9
&gt; print(example.MyWorld.Nested.Dweller_MALE)
0
&gt; print(example.MyWorld.Nested.Dweller_count())
11
&gt;
</pre></div>
<H4><a name="Lua_nn29"></a>28.3.17.2 Names </H4>
<p> If SWIG is launched without <tt>-no-old-metatable-bindings</tt> option, then it enters backward-compatible mode. While in this mode, it tries
to generate additional names for static functions, class static constants and class enums.
Those names are in a form <tt>$classname_$symbolname</tt> and are added to the scope surrounding the class.
If %nspace is enabled, then class namespace is taken as scope. If there is no namespace, or %nspace is disabled,
then module is considered a class namespace.</p>
<p> Consider the following C++ code </p>
<div class="code"><pre>%module example
%nspace MyWorld::Test;
namespace MyWorld {
class Test {
public:
enum { TEST1 = 10, TEST2 }
static const int ICONST = 12;
};
class Test2 {
public:
enum { TEST3 = 20, TEST4 }
static const int ICONST2 = 23;
}
</pre></div>
<p> When in backward compatible mode, in addition to the usual names, the following ones will be generated (notice the underscore):</p>
<div class="targetlang"><pre>
9
&gt; print(example.MyWorld.Test_TEST1) -- Test has %nspace enabled
10
&gt; print(example.MyWorld.Test_ICONST) -- Test has %nspace enabled
12
&gt; print(example.Test2_TEST3) -- Test2 doesn't have %nspace enabled
20
&gt; print(example.Test2_ICONST2) -- Test2 doesn't have %nspace enabled
23
&gt;
</pre></div>
<p> There is a slight difference with enums when in C mode. As per C standard, enums from C structures are exported to
surrounding scope without any prefixing. Pretending that Test2 is a struct, not class, that would be:</p>
<div class="targetlang"><pre>
&gt; print(example.TEST3) -- NOT Test2_TEST3
20
&gt;
</pre></div>
<H4><a name="Lua_nn30"></a>28.3.17.3 Inheritance </H4>
<p> The internal organization of inheritance has changed.
Consider the following C++ code:</p>
<div class="code"><pre>%module example
class Base {
public:
int base_func()
};
class Derived : public Base {
public:
int derived_func()
}
</pre></div>
<p>Lets assume for a moment that class member functions are stored in <tt>.fn</tt> table. Previously, when classes
were exported to Lua during module initialization, for every derived class all service tables <tt>ST(i.e. ".fn")</tt>
were squashed and added to corresponding derived class <tt>ST</tt>: Everything from <tt>.fn</tt> table of class Base
was copied to <tt>.fn</tt> table of class Derived and so on. This was a recursive procedure, so in the end the whole
inheritance tree of derived class was squashed into derived class. </p>
<p> That means that any changes done to class Base after module initialization wouldn't affect class Derived:</p>
<div class="targetlang"><pre>
base = example.Base()
der = example.Derived()
&gt; print(base.base_func)
function: 0x1367940
&gt; getmetatable(base)[".fn"].new_func = function (x) return x -- Adding new function to class Base (to class, not to an instance!)
&gt; print(base.new_func) -- Checking this function
function
&gt; print(der.new_func) -- Wouldn't work. Derived doesn't check Base any more.
nil
&gt;
</pre></div>
<p> This behaviour was changed. Now unless -squash-bases option is provided, Derived store a list of it's bases and if some symbol is not found in it's own service tables
then its bases are searched for it. Option -squash-bases will effectively return old behaviour.
<div class="targetlang"><pre>
&gt; print(der.new_func) -- Now it works
function
&gt;
</pre></div>
<H2><a name="Lua_nn24"></a>28.4 Typemaps</H2>
<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_nn25"></a>26.4.1 What is a typemap?</H3>
<H3><a name="Lua_nn25"></a>28.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>
@ -1290,7 +1555,7 @@ Received an integer : 6
720
</pre></div>
<H3><a name="Lua_nn26"></a>26.4.2 Using typemaps</H3>
<H3><a name="Lua_nn26"></a>28.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>
@ -1343,7 +1608,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&amp;</tt> as an input parameter (since that it obviously input).</p>
<H3><a name="Lua_nn27"></a>26.4.3 Typemaps and arrays</H3>
<H3><a name="Lua_typemap_arrays"></a>28.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
@ -1407,7 +1672,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_nn28"></a>26.4.4 Typemaps and pointer-pointer functions</H3>
<H3><a name="Lua_typemaps_ptr_ptr_functions"></a>28.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>
@ -1441,7 +1706,7 @@ int Create_Math(iMath** pptr); // its creator (assume it mallocs)
ptr=nil -- the iMath* will be GC'ed as normal
</pre></div>
<H2><a name="Lua_nn29"></a>26.5 Writing typemaps</H2>
<H2><a name="Lua_writing_typemaps"></a>28.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>
@ -1450,7 +1715,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
<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_nn30"></a>26.5.1 Typemaps you can write</H3>
<H3><a name="Lua_typemaps_write"></a>28.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>
@ -1463,7 +1728,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_nn31"></a>26.5.2 SWIG's Lua-C API</H3>
<H3><a name="Lua_nn31"></a>28.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>
@ -1512,7 +1777,7 @@ This macro, when called within the context of a SWIG wrapped function, will disp
<div class="indent">
Similar to SWIG_fail_arg, except that it will display the swig_type_info information instead.</div>
<H2><a name="Lua_nn32"></a>26.6 Customization of your Bindings</H2>
<H2><a name="Lua_nn32"></a>28.6 Customization of your Bindings</H2>
<p>
@ -1521,7 +1786,7 @@ This section covers adding of some small extra bits to your module to add the la
<H3><a name="Lua_nn33"></a>26.6.1 Writing your own custom wrappers</H3>
<H3><a name="Lua_nn33"></a>28.6.1 Writing your own custom wrappers</H3>
<p>
@ -1540,7 +1805,7 @@ int native_function(lua_State*L) // my native code
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_nn34"></a>26.6.2 Adding additional Lua code</H3>
<H3><a name="Lua_nn34"></a>28.6.2 Adding additional Lua code</H3>
<p>
@ -1578,7 +1843,7 @@ 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_nn35"></a>26.7 Details on the Lua binding</H2>
<H2><a name="Lua_nn35"></a>28.7 Details on the Lua binding</H2>
<p>
@ -1589,7 +1854,7 @@ See Examples/lua/arrays for an example of this code.
</i>
</p>
<H3><a name="Lua_nn36"></a>26.7.1 Binding global data into the module.</H3>
<H3><a name="Lua_nn36"></a>28.7.1 Binding global data into the module.</H3>
<p>
@ -1649,7 +1914,7 @@ 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_nn37"></a>26.7.2 Userdata and Metatables</H3>
<H3><a name="Lua_nn37"></a>28.7.2 Userdata and Metatables</H3>
<p>
@ -1729,7 +1994,7 @@ Note: Both the opaque structures (like the FILE*) and normal wrapped classes/str
<p>
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' &amp; '__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_nn38"></a>26.7.3 Memory management</H3>
<H3><a name="Lua_nn38"></a>28.7.3 Memory management</H3>
<p>

1
Doc/Manual/Makefile
View file

@ -75,4 +75,3 @@ linkchecker:
@echo Note linkchecker versions prior to 6.1 do not work properly wrt anchors
@echo -----------------------------------------------------------------------
linkchecker --config=./linkchecker.config index.html

48
Doc/Manual/Modula3.html
View file

@ -5,7 +5,7 @@
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body bgcolor="#FFFFFF">
<H1><a name="Modula3"></a>27 SWIG and Modula-3</H1>
<H1><a name="Modula3"></a>29 SWIG and Modula-3</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -45,7 +45,7 @@
<p>
This chapter describes SWIG's support of
This chapter describes SWIG's support for
<a href="http://modula3.org/">Modula-3</a>.
You should be familiar with the
<a href="SWIG.html#SWIG">basics</a>
@ -54,7 +54,7 @@ especially
<a href="Typemaps.html#Typemaps">typemaps</a>.
</p>
<H2><a name="Modula3_modula3_overview"></a>27.1 Overview</H2>
<H2><a name="Modula3_modula3_overview"></a>29.1 Overview</H2>
<p>
@ -84,7 +84,7 @@ FFTW
</li>
</ol>
<H3><a name="Modula3_motivation"></a>27.1.1 Motivation</H3>
<H3><a name="Modula3_motivation"></a>29.1.1 Motivation</H3>
<p>
@ -109,7 +109,7 @@ into exceptions.
<p>
If the library API is ill designed
writing appropriate typemaps can be still time-consuming.
writing appropriate typemaps can still be time-consuming.
E.g. C programmers are very creative to work-around
missing data types like (real) enumerations and sets.
You should turn such work-arounds back to the Modula-3 way
@ -120,21 +120,21 @@ otherwise you lose static safety and consistency.
Without SWIG you would probably never consider trying to call C++ libraries
from Modula-3, but with SWIG this is becomes feasible.
SWIG can generate C wrappers to C++ functions and object methods
that may throw exceptions, and then wrap these C wrappers for Module-3.
that may throw exceptions, and then wrap these C wrappers for Modula-3.
To make it complete you can then hide the C interface with Modula-3 classes and
exceptions.
</p>
<p>
SWIG allows you to call C and C++ libraries from Modula-3 (even with call back
functions), but it doesn't allow you to easily integrate a Module-3 module into
functions), but it doesn't allow you to easily integrate a Modula-3 module into
a C/C++ project.
</p>
<H2><a name="Modula3_conception"></a>27.2 Conception</H2>
<H2><a name="Modula3_conception"></a>29.2 Conception</H2>
<H3><a name="Modula3_cinterface"></a>27.2.1 Interfaces to C libraries</H3>
<H3><a name="Modula3_cinterface"></a>29.2.1 Interfaces to C libraries</H3>
<p>
@ -283,7 +283,7 @@ and the principal type must be renamed (<tt>%typemap</tt>).
</p>
<H3><a name="Modula3_cppinterface"></a>27.2.2 Interfaces to C++ libraries</H3>
<H3><a name="Modula3_cppinterface"></a>29.2.2 Interfaces to C++ libraries</H3>
<p>
@ -384,10 +384,10 @@ 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>27.3 Preliminaries</H2>
<H2><a name="Modula3_preliminaries"></a>29.3 Preliminaries</H2>
<H3><a name="Modula3_compilers"></a>27.3.1 Compilers</H3>
<H3><a name="Modula3_compilers"></a>29.3.1 Compilers</H3>
<p>
@ -400,7 +400,7 @@ For testing examples I use Critical Mass cm3.
</p>
<H3><a name="Modula3_commandline"></a>27.3.2 Additional Commandline Options</H3>
<H3><a name="Modula3_commandline"></a>29.3.2 Additional Commandline Options</H3>
<p>
@ -477,10 +477,10 @@ Instead generate templates for some basic typemaps.
</tr>
</table>
<H2><a name="Modula3_typemaps"></a>27.4 Modula-3 typemaps</H2>
<H2><a name="Modula3_typemaps"></a>29.4 Modula-3 typemaps</H2>
<H3><a name="Modula3_inoutparam"></a>27.4.1 Inputs and outputs</H3>
<H3><a name="Modula3_inoutparam"></a>29.4.1 Inputs and outputs</H3>
<p>
@ -694,7 +694,7 @@ consist of the following parts:
</table>
<H3><a name="Modula3_ordinals"></a>27.4.2 Subranges, Enumerations, Sets</H3>
<H3><a name="Modula3_ordinals"></a>29.4.2 Subranges, Enumerations, Sets</H3>
<p>
@ -746,7 +746,7 @@ that I'd like to automate.
</p>
<H3><a name="Modula3_class"></a>27.4.3 Objects</H3>
<H3><a name="Modula3_class"></a>29.4.3 Objects</H3>
<p>
@ -759,7 +759,7 @@ is not really useful, yet.
</p>
<H3><a name="Modula3_imports"></a>27.4.4 Imports</H3>
<H3><a name="Modula3_imports"></a>29.4.4 Imports</H3>
<p>
@ -792,7 +792,7 @@ IMPORT M3toC;
</pre></div>
<H3><a name="Modula3_exceptions"></a>27.4.5 Exceptions</H3>
<H3><a name="Modula3_exceptions"></a>29.4.5 Exceptions</H3>
<p>
@ -816,7 +816,7 @@ you should declare
<tt>%typemap("m3wrapinconv:throws") blah * %{OSError.E%}</tt>.
</p>
<H3><a name="Modula3_typemap_example"></a>27.4.6 Example</H3>
<H3><a name="Modula3_typemap_example"></a>29.4.6 Example</H3>
<p>
@ -863,10 +863,10 @@ where almost everything is generated by a typemap:
</pre></div>
<H2><a name="Modula3_hints"></a>27.5 More hints to the generator</H2>
<H2><a name="Modula3_hints"></a>29.5 More hints to the generator</H2>
<H3><a name="Modula3_features"></a>27.5.1 Features</H3>
<H3><a name="Modula3_features"></a>29.5.1 Features</H3>
<table border summary="Modula-3 features">
@ -903,7 +903,7 @@ where almost everything is generated by a typemap:
</tr>
</table>
<H3><a name="Modula3_pragmas"></a>27.5.2 Pragmas</H3>
<H3><a name="Modula3_pragmas"></a>29.5.2 Pragmas</H3>
<table border summary="Modula-3 pragmas">
@ -926,7 +926,7 @@ where almost everything is generated by a typemap:
</tr>
</table>
<H2><a name="Modula3_remarks"></a>27.6 Remarks</H2>
<H2><a name="Modula3_remarks"></a>29.6 Remarks</H2>
<ul>

18
Doc/Manual/Modules.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Modules"></a>15 Working with Modules</H1>
<H1><a name="Modules"></a>16 Working with Modules</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -23,7 +23,7 @@
<H2><a name="Modules_introduction"></a>15.1 Modules Introduction</H2>
<H2><a name="Modules_introduction"></a>16.1 Modules Introduction</H2>
<p>
@ -77,7 +77,7 @@ where you want to create a collection of modules.
Each module in the collection is created via separate invocations of SWIG.
</p>
<H2><a name="Modules_nn1"></a>15.2 Basics</H2>
<H2><a name="Modules_nn1"></a>16.2 Basics</H2>
<p>
@ -130,7 +130,7 @@ public:
<p>To create the wrapper properly, module <tt>derived_module</tt> needs to know about the
<tt>base</tt> class and that its interface is covered in another module. The
line <tt>%import "base_module.i"</tt> lets SWIG know exactly that. Oftentimes
line <tt>%import "base_module.i"</tt> lets SWIG know exactly that. Often
the <tt>.h</tt> file is passed to <tt>%import</tt> instead of the <tt>.i</tt>,
which unfortunately doesn't work for all language modules. For example, Python requires the
name of module that the base class exists in so that the proxy classes can fully inherit the
@ -176,7 +176,7 @@ in parallel from multiple threads as SWIG provides no locking - for more on that
issue, read on.
</p>
<H2><a name="Modules_nn2"></a>15.3 The SWIG runtime code</H2>
<H2><a name="Modules_nn2"></a>16.3 The SWIG runtime code</H2>
<p>
@ -242,7 +242,7 @@ can peacefully coexist. So the type structures are separated by the
is empty. Only modules compiled with the same pair will share type information.
</p>
<H2><a name="Modules_external_run_time"></a>15.4 External access to the runtime</H2>
<H2><a name="Modules_external_run_time"></a>16.4 External access to the runtime</H2>
<p>As described in <a href="Typemaps.html#Typemaps_runtime_type_checker">The run-time type checker</a>,
@ -279,7 +279,7 @@ SWIG_TYPE_TABLE to be the same as the module whose types you are trying to
access.
</p>
<H2><a name="Modules_nn4"></a>15.5 A word of caution about static libraries</H2>
<H2><a name="Modules_nn4"></a>16.5 A word of caution about static libraries</H2>
<p>
@ -290,7 +290,7 @@ into it. This is very often <b>NOT</b> what you want and it can lead to unexpect
behavior. When working with dynamically loadable modules, you should try to work exclusively with shared libraries.
</p>
<H2><a name="Modules_nn5"></a>15.6 References</H2>
<H2><a name="Modules_nn5"></a>16.6 References</H2>
<p>
@ -298,7 +298,7 @@ Due to the complexity of working with shared libraries and multiple modules, it
an outside reference. John Levine's "Linkers and Loaders" is highly recommended.
</p>
<H2><a name="Modules_nn6"></a>15.7 Reducing the wrapper file size</H2>
<H2><a name="Modules_nn6"></a>16.7 Reducing the wrapper file size</H2>
<p>

8
Doc/Manual/Mzscheme.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Mzscheme"></a>28 SWIG and MzScheme/Racket</H1>
<H1><a name="Mzscheme"></a>30 SWIG and MzScheme/Racket</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -24,7 +24,7 @@
<p>
This section contains information on SWIG's support of Racket, formally known as MzScheme.
<H2><a name="MzScheme_nn2"></a>28.1 Creating native structures</H2>
<H2><a name="MzScheme_nn2"></a>30.1 Creating native structures</H2>
<p>
@ -65,7 +65,7 @@ Then in scheme, you can use regular struct access procedures like
</pre>
</div>
<H2><a name="MzScheme_simple"></a>28.2 Simple example</H2>
<H2><a name="MzScheme_simple"></a>30.2 Simple example</H2>
<p>
@ -166,7 +166,7 @@ Some points of interest:
<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>
<H2><a name="MzScheme_external_docs"></a>30.3 External documentation</H2>
<p>

66
Doc/Manual/Ocaml.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<a name="n1"></a>
<H1><a name="Ocaml"></a>29 SWIG and Ocaml</H1>
<H1><a name="Ocaml"></a>31 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>29.1 Preliminaries</H2>
<H2><a name="Ocaml_nn2"></a>31.1 Preliminaries</H2>
<p>
@ -99,7 +99,7 @@ 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>29.1.1 Running SWIG</H3>
<H3><a name="Ocaml_nn3"></a>31.1.1 Running SWIG</H3>
<p>
@ -122,7 +122,7 @@ 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>29.1.2 Compiling the code</H3>
<H3><a name="Ocaml_nn4"></a>31.1.2 Compiling the code</H3>
<p>
@ -158,12 +158,12 @@ the user more freedom with respect to custom typing.
</pre>
</div>
<H3><a name="Ocaml_nn5"></a>29.1.3 The camlp4 module</H3>
<H3><a name="Ocaml_nn5"></a>31.1.3 The camlp4 module</H3>
<p>
The camlp4 module (swigp4.ml -&gt; swigp4.cmo) contains a simple rewriter which
makes C++ code blend more seamlessly with objective caml code. It's use is
makes C++ code blend more seamlessly with objective caml code. Its use is
optional, but encouraged. The source file is included in the Lib/ocaml
directory of the SWIG source distribution. You can checkout this file with
<tt>"swig -ocaml -co swigp4.ml"</tt>. You should compile the file with
@ -234,7 +234,7 @@ let b = C_string (getenv "PATH")
</td></tr>
</table>
<H3><a name="Ocaml_nn6"></a>29.1.4 Using your module</H3>
<H3><a name="Ocaml_nn6"></a>31.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>29.1.5 Compilation problems and compiling with C++</H3>
<H3><a name="Ocaml_nn7"></a>31.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>29.2 The low-level Ocaml/C interface</H2>
<H2><a name="Ocaml_nn8"></a>31.2 The low-level Ocaml/C interface</H2>
<p>
@ -310,7 +310,7 @@ type c_obj =
</li>
<li>caml_val_ptr receives a void * and returns a c_obj.</li>
<li>caml_val_bool receives a C int and returns a c_obj representing
it's bool value.</li>
its bool value.</li>
<li>caml_val_(u)?(char|short|int|long|float|double) receives an
appropriate C value and returns a c_obj representing it.</li>
<li>caml_val_string receives a char * and returns a string value.</li>
@ -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>29.2.1 The generated module</H3>
<H3><a name="Ocaml_nn9"></a>31.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>29.2.2 Enums</H3>
<H3><a name="Ocaml_nn10"></a>31.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>29.2.2.1 Enum typing in Ocaml</H4>
<H4><a name="Ocaml_nn11"></a>31.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>29.2.3 Arrays</H3>
<H3><a name="Ocaml_nn12"></a>31.2.3 Arrays</H3>
<H4><a name="Ocaml_nn13"></a>29.2.3.1 Simple types of bounded arrays</H4>
<H4><a name="Ocaml_nn13"></a>31.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>29.2.3.2 Complex and unbounded arrays</H4>
<H4><a name="Ocaml_nn14"></a>31.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>29.2.3.3 Using an object</H4>
<H4><a name="Ocaml_nn15"></a>31.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>29.2.3.4 Example typemap for a function taking float * and int</H4>
<H4><a name="Ocaml_nn16"></a>31.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>29.2.4 C++ Classes</H3>
<H3><a name="Ocaml_nn17"></a>31.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>29.2.4.1 STL vector and string Example</H4>
<H4><a name="Ocaml_nn18"></a>31.2.4.1 STL vector and string Example</H4>
<p>
@ -695,7 +695,7 @@ baz
#
</pre></div>
<H4><a name="Ocaml_nn19"></a>29.2.4.2 C++ Class Example</H4>
<H4><a name="Ocaml_nn19"></a>31.2.4.2 C++ Class Example</H4>
<p>
@ -725,7 +725,7 @@ public:
};
</pre></td></tr></table>
<H4><a name="Ocaml_nn20"></a>29.2.4.3 Compiling the example</H4>
<H4><a name="Ocaml_nn20"></a>31.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>29.2.4.4 Sample Session</H4>
<H4><a name="Ocaml_nn21"></a>31.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>29.2.5 Director Classes</H3>
<H3><a name="Ocaml_nn22"></a>31.2.5 Director Classes</H3>
<H4><a name="Ocaml_nn23"></a>29.2.5.1 Director Introduction</H4>
<H4><a name="Ocaml_nn23"></a>31.2.5.1 Director Introduction</H4>
<p>
@ -800,7 +800,7 @@ class foo {
};
</pre></div>
<H4><a name="Ocaml_nn24"></a>29.2.5.2 Overriding Methods in Ocaml</H4>
<H4><a name="Ocaml_nn24"></a>31.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>29.2.5.3 Director Usage Example</H4>
<H4><a name="Ocaml_nn25"></a>31.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>29.2.5.4 Creating director objects</H4>
<H4><a name="Ocaml_nn26"></a>31.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>29.2.5.5 Typemaps for directors, <tt>directorin, directorout, directorargout</tt></H4>
<H4><a name="Ocaml_nn27"></a>31.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>29.2.5.6 <tt>directorin</tt> typemap</H4>
<H4><a name="Ocaml_nn28"></a>31.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>29.2.5.7 <tt>directorout</tt> typemap</H4>
<H4><a name="Ocaml_nn29"></a>31.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>29.2.5.8 <tt>directorargout</tt> typemap</H4>
<H4><a name="Ocaml_nn30"></a>31.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>29.2.6 Exceptions</H3>
<H3><a name="Ocaml_nn31"></a>31.2.6 Exceptions</H3>
<p>

57
Doc/Manual/Octave.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Octave"></a>30 SWIG and Octave</H1>
<H1><a name="Octave"></a>32 SWIG and Octave</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -55,18 +55,15 @@ More information can be found at <a href="http://www.gnu.org/software/octave/">O
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>30.1 Preliminaries</H2>
<H2><a name="Octave_nn2"></a>32.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.
As of SWIG 3.0.0, the Octave module has been tested with Octave versions 3.0.5, 3.2.4, 3.4.3, 3.6.4, and 3.8.0.
Use of Octave versions older than 3.x.x is not recommended, as these versions are no longer tested with SWIG.
</p>
<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>
<H2><a name="Octave_nn3"></a>32.2 Running SWIG</H2>
<p>
@ -98,7 +95,7 @@ The <tt>-c++</tt> option is also required when wrapping C++ code:
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>
<H3><a name="Octave_nn4"></a>32.2.1 Command-line options</H3>
<p>
@ -121,7 +118,7 @@ The special name "." loads C global variables into the module namespace, i.e. al
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>
<H3><a name="Octave_nn5"></a>32.2.2 Compiling a dynamic module</H3>
<p>
@ -148,7 +145,7 @@ $ mkoctfile example_wrap.cpp example.c
<div class="targetlang"><pre>octave:1&gt; swigexample</pre></div>
<H3><a name="Octave_nn6"></a>30.2.3 Using your module</H3>
<H3><a name="Octave_nn6"></a>32.2.3 Using your module</H3>
<p>
@ -166,10 +163,10 @@ octave:4&gt; swigexample.cvar.Foo=4;
octave:5&gt; swigexample.cvar.Foo
ans = 4 </pre></div>
<H2><a name="Octave_nn7"></a>30.3 A tour of basic C/C++ wrapping</H2>
<H2><a name="Octave_nn7"></a>32.3 A tour of basic C/C++ wrapping</H2>
<H3><a name="Octave_nn8"></a>30.3.1 Modules</H3>
<H3><a name="Octave_nn8"></a>32.3.1 Modules</H3>
<p>
@ -214,7 +211,7 @@ octave:4&gt; swigexample.gcd(4,6)
ans = 2
</pre></div>
<H3><a name="Octave_nn9"></a>30.3.2 Functions</H3>
<H3><a name="Octave_nn9"></a>32.3.2 Functions</H3>
<p>
@ -231,7 +228,7 @@ int fact(int n); </pre></div>
<div class="targetlang"><pre>octave:1&gt; swigexample.fact(4)
24 </pre></div>
<H3><a name="Octave_nn10"></a>30.3.3 Global variables</H3>
<H3><a name="Octave_nn10"></a>32.3.3 Global variables</H3>
<p>
@ -284,7 +281,7 @@ octave:2&gt; swigexample.PI=3.142;
octave:3&gt; swigexample.PI
ans = 3.1420 </pre></div>
<H3><a name="Octave_nn11"></a>30.3.4 Constants and enums</H3>
<H3><a name="Octave_nn11"></a>32.3.4 Constants and enums</H3>
<p>
@ -306,7 +303,7 @@ swigexample.SCONST="Hello World"
swigexample.SUNDAY=0
.... </pre></div>
<H3><a name="Octave_nn12"></a>30.3.5 Pointers</H3>
<H3><a name="Octave_nn12"></a>32.3.5 Pointers</H3>
<p>
@ -332,7 +329,7 @@ octave:4&gt; swigexample.fclose(f);
</pre></div>
<p>
Simply printing the value of a wrapped C++ type will print it's typename. E.g.,
Simply printing the value of a wrapped C++ type will print its typename. E.g.,
</p>
<div class="targetlang"><pre>octave:1&gt; swigexample;
@ -353,7 +350,7 @@ octave:2&gt; f=swigexample.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>30.3.6 Structures and C++ classes</H3>
<H3><a name="Octave_nn13"></a>32.3.6 Structures and C++ classes</H3>
<p>
@ -488,7 +485,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>30.3.7 C++ inheritance</H3>
<H3><a name="Octave_nn15"></a>32.3.7 C++ inheritance</H3>
<p>
@ -497,7 +494,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>30.3.8 C++ overloaded functions</H3>
<H3><a name="Octave_nn17"></a>32.3.8 C++ overloaded functions</H3>
<p>
@ -507,7 +504,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>30.3.9 C++ operators</H3>
<H3><a name="Octave_nn18"></a>32.3.9 C++ operators</H3>
<p>
@ -611,7 +608,7 @@ On the C++ side, the default mappings are as follows:
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>
<H3><a name="Octave_nn19"></a>32.3.10 Class extension with %extend</H3>
<p>
@ -641,7 +638,7 @@ octave:3&gt; printf("%s\n",a);
octave:4&gt; a.__str()
4
</pre></div>
<H3><a name="Octave_nn20"></a>30.3.11 C++ templates</H3>
<H3><a name="Octave_nn20"></a>32.3.11 C++ templates</H3>
<p>
@ -718,14 +715,14 @@ ans =
</pre></div>
<H3><a name="Octave_nn21"></a>30.3.12 C++ Smart Pointers</H3>
<H3><a name="Octave_nn21"></a>32.3.12 C++ Smart Pointers</H3>
<p>
C++ smart pointers are fully supported as in other modules.
</p>
<H3><a name="Octave_nn22"></a>30.3.13 Directors (calling Octave from C++ code)</H3>
<H3><a name="Octave_nn22"></a>32.3.13 Directors (calling Octave from C++ code)</H3>
<p>
@ -806,14 +803,14 @@ c-side routine called
octave-side routine called
</pre></div>
<H3><a name="Octave_nn23"></a>30.3.14 Threads</H3>
<H3><a name="Octave_nn23"></a>32.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>30.3.15 Memory management</H3>
<H3><a name="Octave_nn24"></a>32.3.15 Memory management</H3>
<p>
@ -847,14 +844,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>30.3.16 STL support</H3>
<H3><a name="Octave_nn25"></a>32.3.16 STL support</H3>
<p>
Various STL library files are provided for wrapping STL containers.
</p>
<H3><a name="Octave_nn26"></a>30.3.17 Matrix typemaps</H3>
<H3><a name="Octave_nn26"></a>32.3.17 Matrix typemaps</H3>
<p>

464
Doc/Manual/Perl5.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Perl5"></a>31 SWIG and Perl5</H1>
<H1><a name="Perl5"></a>33 SWIG and Perl5</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -68,6 +68,15 @@
<li><a href="#Perl5_nn46">Modifying the proxy methods</a>
</ul>
<li><a href="#Perl5_nn47">Adding additional Perl code</a>
<li><a href="#Perl5_directors">Cross language polymorphism</a>
<ul>
<li><a href="#Perl5_nn48">Enabling directors</a>
<li><a href="#Perl5_nn49">Director classes</a>
<li><a href="#Perl5_nn50">Ownership and object destruction</a>
<li><a href="#Perl5_nn51">Exception unrolling</a>
<li><a href="#Perl5_nn52">Overhead and code bloat</a>
<li><a href="#Perl5_nn53">Typemaps</a>
</ul>
</ul>
</div>
<!-- INDEX -->
@ -87,7 +96,7 @@ 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>31.1 Overview</H2>
<H2><a name="Perl5_nn2"></a>33.1 Overview</H2>
<p>
@ -108,7 +117,7 @@ described. Advanced customization features, typemaps, and other
options are found near the end of the chapter.
</p>
<H2><a name="Perl5_nn3"></a>31.2 Preliminaries</H2>
<H2><a name="Perl5_nn3"></a>33.2 Preliminaries</H2>
<p>
@ -133,7 +142,7 @@ 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>31.2.1 Getting the right header files</H3>
<H3><a name="Perl5_nn4"></a>33.2.1 Getting the right header files</H3>
<p>
@ -165,7 +174,7 @@ $ perl -e 'use Config; print "$Config{archlib}\n";'
</pre>
</div>
<H3><a name="Perl5_nn5"></a>31.2.2 Compiling a dynamic module</H3>
<H3><a name="Perl5_nn5"></a>33.2.2 Compiling a dynamic module</H3>
<p>
@ -198,7 +207,7 @@ 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>31.2.3 Building a dynamic module with MakeMaker</H3>
<H3><a name="Perl5_nn6"></a>33.2.3 Building a dynamic module with MakeMaker</H3>
<p>
@ -232,7 +241,7 @@ 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>31.2.4 Building a static version of Perl</H3>
<H3><a name="Perl5_nn7"></a>33.2.4 Building a static version of Perl</H3>
<p>
@ -301,7 +310,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>31.2.5 Using the module</H3>
<H3><a name="Perl5_nn8"></a>33.2.5 Using the module</H3>
<p>
@ -454,7 +463,7 @@ system configuration (this requires root access and you will need to
read the man pages).
</p>
<H3><a name="Perl5_nn9"></a>31.2.6 Compilation problems and compiling with C++</H3>
<H3><a name="Perl5_nn9"></a>33.2.6 Compilation problems and compiling with C++</H3>
<p>
@ -484,8 +493,8 @@ Solaris, you often need to add an extra library <tt>-lCrun</tt> like this:
<div class="code"><pre>
$ swig -c++ -perl example.i
$ CC -c example.cxx
$ CC -c example_wrap.cxx -I/usr/lib/perl/5.14/i386-linux/CORE
$ CC -Kpic -c example.cxx
$ CC -Kpic -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>
@ -597,7 +606,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>31.2.7 Compiling for 64-bit platforms</H3>
<H3><a name="Perl5_nn10"></a>33.2.7 Compiling for 64-bit platforms</H3>
<p>
@ -624,7 +633,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>31.3 Building Perl Extensions under Windows</H2>
<H2><a name="Perl5_nn11"></a>33.3 Building Perl Extensions under Windows</H2>
<p>
@ -635,7 +644,7 @@ 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>31.3.1 Running SWIG from Developer Studio</H3>
<H3><a name="Perl5_nn12"></a>33.3.1 Running SWIG from Developer Studio</H3>
<p>
@ -698,7 +707,7 @@ print "$a\n";
</pre></div>
<H3><a name="Perl5_nn13"></a>31.3.2 Using other compilers</H3>
<H3><a name="Perl5_nn13"></a>33.3.2 Using other compilers</H3>
<p>
@ -706,7 +715,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>31.4 The low-level interface</H2>
<H2><a name="Perl5_nn14"></a>33.4 The low-level interface</H2>
<p>
@ -716,7 +725,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>31.4.1 Functions</H3>
<H3><a name="Perl5_nn15"></a>33.4.1 Functions</H3>
<p>
@ -739,7 +748,7 @@ use example;
$a = &amp;example::fact(2);
</pre></div>
<H3><a name="Perl5_nn16"></a>31.4.2 Global variables</H3>
<H3><a name="Perl5_nn16"></a>33.4.2 Global variables</H3>
<p>
@ -809,7 +818,7 @@ extern char *path; // Declared later in the input
</pre>
</div>
<H3><a name="Perl5_nn17"></a>31.4.3 Constants</H3>
<H3><a name="Perl5_nn17"></a>33.4.3 Constants</H3>
<p>
@ -849,7 +858,7 @@ print example::FOO,"\n";
</pre>
</div>
<H3><a name="Perl5_nn18"></a>31.4.4 Pointers</H3>
<H3><a name="Perl5_nn18"></a>33.4.4 Pointers</H3>
<p>
@ -958,7 +967,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>31.4.5 Structures</H3>
<H3><a name="Perl5_nn19"></a>33.4.5 Structures</H3>
<p>
@ -1092,7 +1101,7 @@ void Bar_f_set(Bar *b, Foo *val) {
</div>
<H3><a name="Perl5_nn20"></a>31.4.6 C++ classes</H3>
<H3><a name="Perl5_nn20"></a>33.4.6 C++ classes</H3>
<p>
@ -1157,7 +1166,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>31.4.7 C++ classes and type-checking</H3>
<H3><a name="Perl5_nn21"></a>33.4.7 C++ classes and type-checking</H3>
<p>
@ -1193,7 +1202,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>31.4.8 C++ overloaded functions</H3>
<H3><a name="Perl5_nn22"></a>33.4.8 C++ overloaded functions</H3>
<p>
@ -1237,7 +1246,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>31.4.9 Operators</H3>
<H3><a name="Perl5_nn23"></a>33.4.9 Operators</H3>
<p>
@ -1264,7 +1273,7 @@ The following C++ operators are currently supported by the Perl module:
<li>operator or </li>
</ul>
<H3><a name="Perl5_nn24"></a>31.4.10 Modules and packages</H3>
<H3><a name="Perl5_nn24"></a>33.4.10 Modules and packages</H3>
<p>
@ -1359,7 +1368,7 @@ print Foo::fact(4),"\n"; # Call a function in package FooBar
</pre></div>
-->
<H2><a name="Perl5_nn25"></a>31.5 Input and output parameters</H2>
<H2><a name="Perl5_nn25"></a>33.5 Input and output parameters</H2>
<p>
@ -1578,7 +1587,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>31.6 Exception handling</H2>
<H2><a name="Perl5_nn26"></a>33.6 Exception handling</H2>
<p>
@ -1743,7 +1752,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>31.7 Remapping datatypes with typemaps</H2>
<H2><a name="Perl5_nn27"></a>33.7 Remapping datatypes with typemaps</H2>
<p>
@ -1760,7 +1769,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>31.7.1 A simple typemap example</H3>
<H3><a name="Perl5_nn28"></a>33.7.1 A simple typemap example</H3>
<p>
@ -1864,7 +1873,7 @@ example::count("e","Hello World");
</div>
<H3><a name="Perl5_nn29"></a>31.7.2 Perl5 typemaps</H3>
<H3><a name="Perl5_nn29"></a>33.7.2 Perl5 typemaps</H3>
<p>
@ -1969,7 +1978,7 @@ Return of C++ member data (all languages).
Check value of input parameter.
</div>
<H3><a name="Perl5_nn30"></a>31.7.3 Typemap variables</H3>
<H3><a name="Perl5_nn30"></a>33.7.3 Typemap variables</H3>
<p>
@ -2040,7 +2049,7 @@ properly assigned.
The Perl name of the wrapper function being created.
</div>
<H3><a name="Perl5_nn31"></a>31.7.4 Useful functions</H3>
<H3><a name="Perl5_nn31"></a>33.7.4 Useful functions</H3>
<p>
@ -2109,7 +2118,7 @@ int sv_isa(SV *, char *0;
</div>
<H2><a name="Perl5_nn32"></a>31.8 Typemap Examples</H2>
<H2><a name="Perl5_nn32"></a>33.8 Typemap Examples</H2>
<p>
@ -2118,7 +2127,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>31.8.1 Converting a Perl5 array to a char **</H3>
<H3><a name="Perl5_nn33"></a>33.8.1 Converting a Perl5 array to a char **</H3>
<p>
@ -2210,7 +2219,7 @@ print @$b,"\n"; # Print it out
</pre></div>
<H3><a name="Perl5_nn34"></a>31.8.2 Return values</H3>
<H3><a name="Perl5_nn34"></a>33.8.2 Return values</H3>
<p>
@ -2239,7 +2248,7 @@ can be done using the <tt>EXTEND()</tt> macro as in:
}
</pre></div>
<H3><a name="Perl5_nn35"></a>31.8.3 Returning values from arguments</H3>
<H3><a name="Perl5_nn35"></a>33.8.3 Returning values from arguments</H3>
<p>
@ -2293,7 +2302,7 @@ print "multout(7,13) = @r\n";
($x,$y) = multout(7,13);
</pre></div>
<H3><a name="Perl5_nn36"></a>31.8.4 Accessing array structure members</H3>
<H3><a name="Perl5_nn36"></a>33.8.4 Accessing array structure members</H3>
<p>
@ -2356,7 +2365,7 @@ 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>31.8.5 Turning Perl references into C pointers</H3>
<H3><a name="Perl5_nn37"></a>33.8.5 Turning Perl references into C pointers</H3>
<p>
@ -2421,7 +2430,7 @@ print "$c\n";
</pre></div>
<H3><a name="Perl5_nn38"></a>31.8.6 Pointer handling</H3>
<H3><a name="Perl5_nn38"></a>33.8.6 Pointer handling</H3>
<p>
@ -2500,7 +2509,7 @@ For example:
</pre>
</div>
<H2><a name="Perl5_nn39"></a>31.9 Proxy classes</H2>
<H2><a name="Perl5_nn39"></a>33.9 Proxy classes</H2>
<p>
@ -2516,7 +2525,7 @@ to the underlying code. This section describes the implementation
details of the proxy interface.
</p>
<H3><a name="Perl5_nn40"></a>31.9.1 Preliminaries</H3>
<H3><a name="Perl5_nn40"></a>33.9.1 Preliminaries</H3>
<p>
@ -2538,7 +2547,7 @@ 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>31.9.2 Structure and class wrappers</H3>
<H3><a name="Perl5_nn41"></a>33.9.2 Structure and class wrappers</H3>
<p>
@ -2664,7 +2673,7 @@ $v-&gt;DESTROY();
</pre></div>
<H3><a name="Perl5_nn42"></a>31.9.3 Object Ownership</H3>
<H3><a name="Perl5_nn42"></a>33.9.3 Object Ownership</H3>
<p>
@ -2751,7 +2760,7 @@ counting, garbage collection, or advanced features one might find in
sophisticated languages.
</p>
<H3><a name="Perl5_nn43"></a>31.9.4 Nested Objects</H3>
<H3><a name="Perl5_nn43"></a>33.9.4 Nested Objects</H3>
<p>
@ -2804,7 +2813,7 @@ $p-&gt;{f}-&gt;{x} = 0.0;
%${$p-&gt;{v}} = ( x=&gt;0, y=&gt;0, z=&gt;0);
</pre></div>
<H3><a name="Perl5_nn44"></a>31.9.5 Proxy Functions</H3>
<H3><a name="Perl5_nn44"></a>33.9.5 Proxy Functions</H3>
<p>
@ -2838,7 +2847,7 @@ This function replaces the original function, but operates in an
identical manner.
</p>
<H3><a name="Perl5_nn45"></a>31.9.6 Inheritance</H3>
<H3><a name="Perl5_nn45"></a>33.9.6 Inheritance</H3>
<p>
@ -2914,7 +2923,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>31.9.7 Modifying the proxy methods</H3>
<H3><a name="Perl5_nn46"></a>33.9.7 Modifying the proxy methods</H3>
<p>
@ -2942,7 +2951,7 @@ public:
};
</pre></div>
<H2><a name="Perl5_nn47"></a>31.10 Adding additional Perl code</H2>
<H2><a name="Perl5_nn47"></a>33.10 Adding additional Perl code</H2>
<p>
@ -2993,6 +3002,363 @@ set_transform($im, $a);
</pre>
</div>
<H2><a name="Perl5_directors"></a>33.11 Cross language polymorphism</H2>
<p>
Proxy classes provide a more natural, object-oriented way to access
extension classes. As described above, each proxy instance has an
associated C++ instance, and method calls to the proxy are passed to the
C++ instance transparently via C wrapper functions.
</p>
<p>
This arrangement is asymmetric in the sense that no corresponding
mechanism exists to pass method calls down the inheritance chain from
C++ to Perl. In particular, if a C++ class has been extended in Perl
(by extending the proxy class), these extensions will not be visible
from C++ code. Virtual method calls from C++ are thus not able access
the lowest implementation in the inheritance chain.
</p>
<p>
Changes have been made to SWIG to address this problem and
make the relationship between C++ classes and proxy classes more
symmetric. To achieve this goal, new classes called directors are
introduced at the bottom of the C++ inheritance chain. The job of the
directors is to route method calls correctly, either to C++
implementations higher in the inheritance chain or to Perl
implementations lower in the inheritance chain. The upshot is that C++
classes can be extended in Perl and from C++ these extensions look
exactly like native C++ classes. Neither C++ code nor Perl code needs
to know where a particular method is implemented: the combination of
proxy classes, director classes, and C wrapper functions takes care of
all the cross-language method routing transparently.
</p>
<H3><a name="Perl5_nn48"></a>33.11.1 Enabling directors</H3>
<p>
The director feature is disabled by default. To use directors you
must make two changes to the interface file. First, add the "directors"
option to the %module directive, like this:
</p>
<div class="code">
<pre>
%module(directors="1") modulename
</pre>
</div>
<p>
Without this option no director code will be generated. Second, you
must use the %feature("director") directive to tell SWIG which classes
and methods should get directors. The %feature directive can be applied
globally, to specific classes, and to specific methods, like this:
</p>
<div class="code">
<pre>
// generate directors for all classes that have virtual methods
%feature("director");
// generate directors for all virtual methods in class Foo
%feature("director") Foo;
</pre>
</div>
<p>
You can use the %feature("nodirector") directive to turn off
directors for specific classes or methods. So for example,
</p>
<div class="code">
<pre>
%feature("director") Foo;
%feature("nodirector") Foo::bar;
</pre>
</div>
<p>
will generate directors for all virtual methods of class Foo except
bar().
</p>
<p>
Directors can also be generated implicitly through inheritance.
In the following, class Bar will get a director class that handles
the methods one() and two() (but not three()):
</p>
<div class="code">
<pre>
%feature("director") Foo;
class Foo {
public:
Foo(int foo);
virtual void one();
virtual void two();
};
class Bar: public Foo {
public:
virtual void three();
};
</pre>
</div>
<p>
then at the Perl side you can define
</p>
<div class="targetlang">
<pre>
use mymodule;
package MyFoo;
use base 'mymodule::Foo';
sub one {
print "one from Perl\n";
}
</pre>
</div>
<H3><a name="Perl5_nn49"></a>33.11.2 Director classes</H3>
<p>
For each class that has directors enabled, SWIG generates a new class
that derives from both the class in question and a special
<tt>Swig::Director</tt> class. These new classes, referred to as director
classes, can be loosely thought of as the C++ equivalent of the Perl
proxy classes. The director classes store a pointer to their underlying
Perl object and handle various issues related to object ownership.
</p>
<p>
For simplicity let's ignore the <tt>Swig::Director</tt> class and refer to the
original C++ class as the director's base class. By default, a director
class extends all virtual methods in the inheritance chain of its base
class (see the preceding section for how to modify this behavior).
Thus all virtual method calls, whether they originate in C++ or in
Perl via proxy classes, eventually end up in at the implementation in
the director class. The job of the director methods is to route these
method calls to the appropriate place in the inheritance chain. By
"appropriate place" we mean the method that would have been called if
the C++ base class and its extensions in Perl were seamlessly
integrated. That seamless integration is exactly what the director
classes provide, transparently skipping over all the messy extension API
glue that binds the two languages together.
</p>
<p>
In reality, the "appropriate place" is one of only two possibilities:
C++ or Perl. Once this decision is made, the rest is fairly easy. If
the correct implementation is in C++, then the lowest implementation of
the method in the C++ inheritance chain is called explicitly. If the
correct implementation is in Perl, the Perl API is used to call the
method of the underlying Perl object (after which the usual virtual
method resolution in Perl automatically finds the right
implementation).
</p>
<p>
Now how does the director decide which language should handle the method call?
The basic rule is to handle the method in Perl, unless there's a good
reason not to. The reason for this is simple: Perl has the most
"extended" implementation of the method. This assertion is guaranteed,
since at a minimum the Perl proxy class implements the method. If the
method in question has been extended by a class derived from the proxy
class, that extended implementation will execute exactly as it should.
If not, the proxy class will route the method call into a C wrapper
function, expecting that the method will be resolved in C++. The wrapper
will call the virtual method of the C++ instance, and since the director
extends this the call will end up right back in the director method. Now
comes the "good reason not to" part. If the director method were to blindly
call the Perl method again, it would get stuck in an infinite loop. We avoid this
situation by adding special code to the C wrapper function that tells
the director method to not do this. The C wrapper function compares the
pointer to the Perl object that called the wrapper function to the
pointer stored by the director. If these are the same, then the C
wrapper function tells the director to resolve the method by calling up
the C++ inheritance chain, preventing an infinite loop.
</p>
<p>
One more point needs to be made about the relationship between director
classes and proxy classes. When a proxy class instance is created in
Perl, SWIG creates an instance of the original C++ class.
This is exactly what happens without directors and
is true even if directors are enabled for the particular class in
question. When a class <i>derived</i> from a proxy class is created,
however, SWIG then creates an instance of the corresponding C++ director
class. The reason for this difference is that user-defined subclasses
may override or extend methods of the original class, so the director
class is needed to route calls to these methods correctly. For
unmodified proxy classes, all methods are ultimately implemented in C++
so there is no need for the extra overhead involved with routing the
calls through Perl.
</p>
<H3><a name="Perl5_nn50"></a>33.11.3 Ownership and object destruction</H3>
<p>
Memory management issues are slightly more complicated with directors
than for proxy classes alone. Perl instances hold a pointer to the
associated C++ director object, and the director in turn holds a pointer
back to a Perl object. By default, proxy classes own their C++
director object and take care of deleting it when they are garbage
collected.
</p>
<p>
This relationship can be reversed by calling the special
<tt>DISOWN()</tt> method of the proxy class. After calling this
method the director
class increments the reference count of the Perl object. When the
director class is deleted it decrements the reference count. Assuming no
outstanding references to the Perl object remain, the Perl object
will be destroyed at the same time. This is a good thing, since
directors and proxies refer to each other and so must be created and
destroyed together. Destroying one without destroying the other will
likely cause your program to segfault.
</p>
<p>
Also note that due to the proxy implementation, the <tt>DESTROY()</tt>
method on directors can be called for several reasons, many of which
have little to do with the teardown of an object instance. To help
disambiguate this, a second argument is added to the <tt>DESTROY()</tt>
call when a C++ director object is being released. So, to avoid running
your clean-up code when an object is not really going away, or after it
has already been reclaimed, it is suggested that custom destructors in
Perl subclasses looks something like:
</p>
<div class="targetlang">
<pre>
sub DESTROY {
my($self, $final) = @_;
if($final) {
# real teardown code
}
shift-&gt;SUPER::DESTROY(@_);
}
</pre>
</div>
<H3><a name="Perl5_nn51"></a>33.11.4 Exception unrolling</H3>
<p>
With directors routing method calls to Perl, and proxies routing them
to C++, the handling of exceptions is an important concern. By default, the
directors ignore exceptions that occur during method calls that are
resolved in Perl. To handle such exceptions correctly, it is necessary
to temporarily translate them into C++ exceptions. This can be done with
the %feature("director:except") directive. The following code should
suffice in most cases:
</p>
<div class="code">
<pre>
%feature("director:except") {
if ($error != NULL) {
throw Swig::DirectorMethodException();
}
}
</pre>
</div>
<p>
This code will check the Perl error state after each method call from
a director into Perl, and throw a C++ exception if an error occurred.
This exception can be caught in C++ to implement an error handler.
</p>
<p>
It may be the case that a method call originates in Perl, travels up
to C++ through a proxy class, and then back into Perl via a director
method. If an exception occurs in Perl at this point, it would be nice
for that exception to find its way back to the original caller. This can
be done by combining a normal %exception directive with the
<tt>director:except</tt> handler shown above. Here is an example of a
suitable exception handler:
</p>
<div class="code">
<pre>
%exception {
try { $action }
catch (Swig::DirectorException &amp;e) { SWIG_fail; }
}
</pre>
</div>
<p>
The class Swig::DirectorException used in this example is actually a
base class of Swig::DirectorMethodException, so it will trap this
exception. Because the Perl error state is still set when
Swig::DirectorMethodException is thrown, Perl will register the
exception as soon as the C wrapper function returns.
</p>
<H3><a name="Perl5_nn52"></a>33.11.5 Overhead and code bloat</H3>
<p>
Enabling directors for a class will generate a new director method for
every virtual method in the class' inheritance chain. This alone can
generate a lot of code bloat for large hierarchies. Method arguments
that require complex conversions to and from target language types can
result in large director methods. For this reason it is recommended that
you selectively enable directors only for specific classes that are
likely to be extended in Perl and used in C++.
</p>
<p>
Compared to classes that do not use directors, the call routing in the
director methods does add some overhead. In particular, at least one
dynamic cast and one extra function call occurs per method call from
Perl. Relative to the speed of Perl execution this is probably
completely negligible. For worst case routing, a method call that
ultimately resolves in C++ may take one extra detour through Perl in
order to ensure that the method does not have an extended Perl
implementation. This could result in a noticeable overhead in some cases.
</p>
<p>
Although directors make it natural to mix native C++ objects with Perl
objects (as director objects) via a common base class pointer, one
should be aware of the obvious fact that method calls to Perl objects
will be much slower than calls to C++ objects. This situation can be
optimized by selectively enabling director methods (using the %feature
directive) for only those methods that are likely to be extended in
Perl.
</p>
<H3><a name="Perl5_nn53"></a>33.11.6 Typemaps</H3>
<p>
Typemaps for input and output of most of the basic types from director
classes have been written. These are roughly the reverse of the usual
input and output typemaps used by the wrapper code. The typemap
operation names are 'directorin', 'directorout', and 'directorargout'.
The director code does not currently use any of the other kinds of typemaps.
It is not clear at this point which kinds are appropriate and
need to be supported.
</p>
</body>

65
Doc/Manual/Php.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Php"></a>32 SWIG and PHP</H1>
<H1><a name="Php"></a>34 SWIG and PHP</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -79,7 +79,7 @@ your extension into php directly, you will need the complete PHP source tree
available.
</p>
<H2><a name="Php_nn1"></a>32.1 Generating PHP Extensions</H2>
<H2><a name="Php_nn1"></a>34.1 Generating PHP Extensions</H2>
<p>
@ -126,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>32.1.1 Building a loadable extension</H3>
<H3><a name="Php_nn1_1"></a>34.1.1 Building a loadable extension</H3>
<p>
@ -141,7 +141,7 @@ least work for Linux though):
gcc -shared example_wrap.o -o example.so
</pre></div>
<H3><a name="Php_nn1_3"></a>32.1.2 Using PHP Extensions</H3>
<H3><a name="Php_nn1_3"></a>34.1.2 Using PHP Extensions</H3>
<p>
@ -172,7 +172,7 @@ attempts to do the <tt>dl()</tt> call for you:
include("example.php");
</pre></div>
<H2><a name="Php_nn2"></a>32.2 Basic PHP interface</H2>
<H2><a name="Php_nn2"></a>34.2 Basic PHP interface</H2>
<p>
@ -183,7 +183,7 @@ 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>32.2.1 Constants</H3>
<H3><a name="Php_nn2_1"></a>34.2.1 Constants</H3>
<p>
@ -260,7 +260,7 @@ is treated as true by the if test, when the value of the intended constant
would be treated as false!
</p>
<H3><a name="Php_nn2_2"></a>32.2.2 Global Variables</H3>
<H3><a name="Php_nn2_2"></a>34.2.2 Global Variables</H3>
<p>
@ -309,7 +309,7 @@ undefined.
At this time SWIG does not support custom accessor methods.
</p>
<H3><a name="Php_nn2_3"></a>32.2.3 Functions</H3>
<H3><a name="Php_nn2_3"></a>34.2.3 Functions</H3>
<p>
@ -362,7 +362,7 @@ print $s; # The value of $s was not changed.
-->
<H3><a name="Php_nn2_4"></a>32.2.4 Overloading</H3>
<H3><a name="Php_nn2_4"></a>34.2.4 Overloading</H3>
<p>
@ -418,7 +418,7 @@ taking the integer argument.
</p>
-->
<H3><a name="Php_nn2_5"></a>32.2.5 Pointers and References</H3>
<H3><a name="Php_nn2_5"></a>34.2.5 Pointers and References</H3>
<p>
@ -503,13 +503,20 @@ echo "The sum $in1 + $in2 = $result\n";
Because PHP has a native concept of reference, it may seem more natural
to the PHP developer to use references to pass pointers. To enable
this, one needs to include <b>phppointers.i</b> which defines the
named typemap REFERENCE.
named typemap REF.
</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.
Prior to SWIG 3.0, the REF typemaps relied on PHP's call-time
pass-by-reference, which was deprecated in PHP 5.3 and removed in PHP 5.4.
So if you use these REF typemaps, you should ensure that SWIG&ge;3.0 is
used to generate wrappers from your interface file.
</p>
<p>
In case you write your own typemaps, SWIG supports an attribute called
<tt>byref</tt>: if you set that, then SWIG will make sure that the generated
wrapper function will want the input parameter as a reference.
</p>
<div class="code"><pre>
@ -532,7 +539,7 @@ include("example.php");
$in1 = 3;
$in2 = 5;
$result = 0;
add(&amp;$in1,&amp;$in2,&amp;$result);
add($in1,$in2,$result);
echo "The sum $in1 + $in2 = $result\n";
?&gt;
@ -556,7 +563,7 @@ 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>32.2.6 Structures and C++ classes</H3>
<H3><a name="Php_nn2_6"></a>34.2.6 Structures and C++ classes</H3>
<p>
@ -617,7 +624,7 @@ Would be used in the following way from PHP5:
Member variables and methods are accessed using the <tt>-&gt;</tt> operator.
</p>
<H4><a name="Php_nn2_6_1"></a>32.2.6.1 Using <tt>-noproxy</tt></H4>
<H4><a name="Php_nn2_6_1"></a>34.2.6.1 Using <tt>-noproxy</tt></H4>
<p>
@ -643,7 +650,7 @@ Complex_im_set($obj,$d);
Complex_im_get($obj);
</pre></div>
<H4><a name="Php_nn2_6_2"></a>32.2.6.2 Constructors and Destructors</H4>
<H4><a name="Php_nn2_6_2"></a>34.2.6.2 Constructors and Destructors</H4>
<p>
@ -684,7 +691,7 @@ the programmer can either reassign the variable or call
<tt>unset($v)</tt>
</p>
<H4><a name="Php_nn2_6_3"></a>32.2.6.3 Static Member Variables</H4>
<H4><a name="Php_nn2_6_3"></a>34.2.6.3 Static Member Variables</H4>
<p>
@ -727,7 +734,7 @@ Ko::threats(10);
echo "There have now been " . Ko::threats() . " threats\n";
</pre></div>
<H4><a name="Php_nn2_6_4"></a>32.2.6.4 Static Member Functions</H4>
<H4><a name="Php_nn2_6_4"></a>34.2.6.4 Static Member Functions</H4>
<p>
@ -749,7 +756,7 @@ Ko::threats();
</pre></div>
<H3><a name="Php_nn2_7"></a>32.2.7 PHP Pragmas, Startup and Shutdown code</H3>
<H3><a name="Php_nn2_7"></a>34.2.7 PHP Pragmas, Startup and Shutdown code</H3>
<p>
@ -837,7 +844,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>32.3 Cross language polymorphism</H2>
<H2><a name="Php_nn3"></a>34.3 Cross language polymorphism</H2>
<p>
@ -872,7 +879,7 @@ wrapper functions takes care of all the cross-language method routing
transparently.
</p>
<H3><a name="Php_nn3_1"></a>32.3.1 Enabling directors</H3>
<H3><a name="Php_nn3_1"></a>34.3.1 Enabling directors</H3>
<p>
@ -961,7 +968,7 @@ class MyFoo extends Foo {
</div>
<H3><a name="Php_nn3_2"></a>32.3.2 Director classes</H3>
<H3><a name="Php_nn3_2"></a>34.3.2 Director classes</H3>
@ -1041,7 +1048,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>32.3.3 Ownership and object destruction</H3>
<H3><a name="Php_nn3_3"></a>34.3.3 Ownership and object destruction</H3>
<p>
@ -1097,7 +1104,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>32.3.4 Exception unrolling</H3>
<H3><a name="Php_nn3_4"></a>34.3.4 Exception unrolling</H3>
<p>
@ -1156,7 +1163,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>32.3.5 Overhead and code bloat</H3>
<H3><a name="Php_nn3_5"></a>34.3.5 Overhead and code bloat</H3>
<p>
@ -1189,7 +1196,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>32.3.6 Typemaps</H3>
<H3><a name="Php_nn3_6"></a>34.3.6 Typemaps</H3>
<p>
@ -1203,7 +1210,7 @@ need to be supported.
</p>
<H3><a name="Php_nn3_7"></a>32.3.7 Miscellaneous</H3>
<H3><a name="Php_nn3_7"></a>34.3.7 Miscellaneous</H3>
<p> Director typemaps for STL classes are mostly in place, and hence you

24
Doc/Manual/Pike.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Pike"></a>33 SWIG and Pike</H1>
<H1><a name="Pike"></a>35 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>33.1 Preliminaries</H2>
<H2><a name="Pike_nn2"></a>35.1 Preliminaries</H2>
<H3><a name="Pike_nn3"></a>33.1.1 Running SWIG</H3>
<H3><a name="Pike_nn3"></a>35.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>33.1.2 Getting the right header files</H3>
<H3><a name="Pike_nn4"></a>35.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>33.1.3 Using your module</H3>
<H3><a name="Pike_nn5"></a>35.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>33.2 Basic C/C++ Mapping</H2>
<H2><a name="Pike_nn6"></a>35.2 Basic C/C++ Mapping</H2>
<H3><a name="Pike_nn7"></a>33.2.1 Modules</H3>
<H3><a name="Pike_nn7"></a>35.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>33.2.2 Functions</H3>
<H3><a name="Pike_nn8"></a>35.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>33.2.3 Global variables</H3>
<H3><a name="Pike_nn9"></a>35.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>33.2.4 Constants and enumerated types</H3>
<H3><a name="Pike_nn10"></a>35.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>33.2.5 Constructors and Destructors</H3>
<H3><a name="Pike_nn11"></a>35.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>33.2.6 Static Members</H3>
<H3><a name="Pike_nn12"></a>35.2.6 Static Members</H3>
<p>

29
Doc/Manual/Preprocessor.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Preprocessor"></a>7 Preprocessing</H1>
<H1><a name="Preprocessor"></a>8 Preprocessing</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -37,7 +37,7 @@ However, a number of modifications and enhancements have been made. This
chapter describes some of these modifications.
</p>
<H2><a name="Preprocessor_nn2"></a>7.1 File inclusion</H2>
<H2><a name="Preprocessor_nn2"></a>8.1 File inclusion</H2>
<p>
@ -63,7 +63,7 @@ By default, the <tt>#include</tt> is ignored unless you run SWIG with the
is that you often don't want SWIG to try and wrap everything included
in standard header system headers and auxiliary files.
<H2><a name="Preprocessor_nn3"></a>7.2 File imports</H2>
<H2><a name="Preprocessor_nn3"></a>8.2 File imports</H2>
<p>
@ -92,7 +92,7 @@ The <tt>-importall</tt> directive tells SWIG to follow all <tt>#include</tt> sta
as imports. This might be useful if you want to extract type definitions from system
header files without generating any wrappers.
<H2><a name="Preprocessor_condition_compilation"></a>7.3 Conditional Compilation</H2>
<H2><a name="Preprocessor_condition_compilation"></a>8.3 Conditional Compilation</H2>
<p>
@ -115,6 +115,9 @@ SWIGCLISP Defined when using CLISP
SWIGCSHARP Defined when using C#
SWIGGUILE Defined when using Guile
SWIGJAVA Defined when using Java
SWIGJAVASCRIPT Defined when using Javascript
SWIG_JAVASCRIPT_JSC Defined when using Javascript for JavascriptCore
SWIG_JAVASCRIPT_V8 Defined when using Javascript for v8 or node.js
SWIGLUA Defined when using Lua
SWIGMODULA3 Defined when using Modula-3
SWIGMZSCHEME Defined when using Mzscheme
@ -153,7 +156,7 @@ SWIG (except for the symbol `<tt>SWIG</tt>' which is only defined
within the SWIG compiler).
</p>
<H2><a name="Preprocessor_nn5"></a>7.4 Macro Expansion</H2>
<H2><a name="Preprocessor_nn5"></a>8.4 Macro Expansion</H2>
<p>
@ -208,7 +211,7 @@ like <tt>#x</tt>. This is a non-standard SWIG extension.
</li>
</ul>
<H2><a name="Preprocessor_nn6"></a>7.5 SWIG Macros</H2>
<H2><a name="Preprocessor_nn6"></a>8.5 SWIG Macros</H2>
<p>
@ -254,7 +257,7 @@ many of SWIG's advanced features and libraries are built using this mechanism (s
support).
</p>
<H2><a name="Preprocessor_nn7"></a>7.6 C99 and GNU Extensions</H2>
<H2><a name="Preprocessor_nn7"></a>8.6 C99 and GNU Extensions</H2>
<p>
@ -310,14 +313,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_delimiters"></a>7.7 Preprocessing and delimiters</H2>
<H2><a name="Preprocessor_delimiters"></a>8.7 Preprocessing and delimiters</H2>
<p>
The preprocessor handles { }, " " and %{ %} delimiters differently.
</p>
<H3><a name="Preprocessor_nn8"></a>7.7.1 Preprocessing and %{ ... %} &amp; " ... " delimiters</H3>
<H3><a name="Preprocessor_nn8"></a>8.7.1 Preprocessing and %{ ... %} &amp; " ... " delimiters</H3>
<p>
@ -342,7 +345,7 @@ the contents of the <tt>%{ ... %}</tt> block are copied without
modification to the output (including all preprocessor directives).
</p>
<H3><a name="Preprocessor_nn9"></a>7.7.2 Preprocessing and { ... } delimiters</H3>
<H3><a name="Preprocessor_nn9"></a>8.7.2 Preprocessing and { ... } delimiters</H3>
<p>
@ -384,7 +387,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.8 Preprocessor and Typemaps</H2>
<H2><a name="Preprocessor_typemap_delimiters"></a>8.8 Preprocessor and Typemaps</H2>
<p>
@ -455,7 +458,7 @@ would generate
</div>
<H2><a name="Preprocessor_nn10"></a>7.9 Viewing preprocessor output</H2>
<H2><a name="Preprocessor_nn10"></a>8.9 Viewing preprocessor output</H2>
<p>
@ -465,7 +468,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.10 The #error and #warning directives</H2>
<H2><a name="Preprocessor_warning_error"></a>8.10 The #error and #warning directives</H2>
<p>

636
Doc/Manual/Python.html
View file

File diff suppressed because it is too large Load diff

16
Doc/Manual/R.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="R"></a>35 SWIG and R</H1>
<H1><a name="R"></a>37 SWIG and R</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -33,7 +33,7 @@ compile and run an R interface to QuantLib running on Mandriva Linux
with gcc. The R bindings also work on Microsoft Windows using Visual C++.
</p>
<H2><a name="R_nn2"></a>35.1 Bugs</H2>
<H2><a name="R_nn2"></a>37.1 Bugs</H2>
<p>
@ -45,7 +45,7 @@ Currently the following features are not implemented or broken:
<li>C Array wrappings
</ul>
<H2><a name="R_nn3"></a>35.2 Using R and SWIG</H2>
<H2><a name="R_nn3"></a>37.2 Using R and SWIG</H2>
<p>
@ -119,7 +119,7 @@ Without it, inheritance of wrapped objects may fail.
These two files can be loaded in any order
</p>
<H2><a name="R_nn4"></a>35.3 Precompiling large R files</H2>
<H2><a name="R_nn4"></a>37.3 Precompiling large R files</H2>
In cases where the R file is large, one make save a lot of loading
@ -137,7 +137,7 @@ will save a large amount of loading time.
<H2><a name="R_nn5"></a>35.4 General policy</H2>
<H2><a name="R_nn5"></a>37.4 General policy</H2>
<p>
@ -146,7 +146,7 @@ wrapping over the underlying functions and rely on the R type system
to provide R syntax.
</p>
<H2><a name="R_language_conventions"></a>35.5 Language conventions</H2>
<H2><a name="R_language_conventions"></a>37.5 Language conventions</H2>
<p>
@ -155,7 +155,7 @@ and [ are overloaded to allow for R syntax (one based indices and
slices)
</p>
<H2><a name="R_nn6"></a>35.6 C++ classes</H2>
<H2><a name="R_nn6"></a>37.6 C++ classes</H2>
<p>
@ -167,7 +167,7 @@ keep track of the pointer object which removes the necessity for a lot
of the proxy class baggage you see in other languages.
</p>
<H2><a name="R_nn7"></a>35.7 Enumerations</H2>
<H2><a name="R_nn7"></a>37.7 Enumerations</H2>
<p>

218
Doc/Manual/Ruby.html
View file

@ -7,7 +7,7 @@
<body bgcolor="#ffffff">
<H1><a name="Ruby"></a>36 SWIG and Ruby</H1>
<H1><a name="Ruby"></a>38 SWIG and Ruby</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -144,7 +144,7 @@
<p>This chapter describes SWIG's support of Ruby.</p>
<H2><a name="Ruby_nn2"></a>36.1 Preliminaries</H2>
<H2><a name="Ruby_nn2"></a>38.1 Preliminaries</H2>
<p> SWIG 1.3 is known to work with Ruby versions 1.6 and later.
@ -159,7 +159,7 @@ read the "<a href="SWIG.html#SWIG">SWIG Basics</a>"
chapter. It is also assumed that the reader has a basic understanding
of Ruby. </p>
<H3><a name="Ruby_nn3"></a>36.1.1 Running SWIG</H3>
<H3><a name="Ruby_nn3"></a>38.1.1 Running SWIG</H3>
<p> To build a Ruby module, run SWIG using the <tt>-ruby</tt>
@ -183,7 +183,7 @@ if compiling a C++ extension) that contains all of the code needed to
build a Ruby 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="Ruby_nn4"></a>36.1.2 Getting the right header files</H3>
<H3><a name="Ruby_nn4"></a>38.1.2 Getting the right header files</H3>
<p> In order to compile the wrapper code, the compiler needs the <tt>ruby.h</tt>
@ -206,7 +206,7 @@ installed, you can run Ruby to find out. For example: </p>
</pre>
</div>
<H3><a name="Ruby_nn5"></a>36.1.3 Compiling a dynamic module</H3>
<H3><a name="Ruby_nn5"></a>38.1.3 Compiling a dynamic module</H3>
<p> Ruby extension modules are typically compiled into shared
@ -259,19 +259,27 @@ operating system would look something like this: </p>
<div class="code shell">
<pre>$ swig -ruby example.i
$ gcc -c example.c
$ gcc -c example_wrap.c -I/usr/local/lib/ruby/1.6/i686-linux
$ gcc -O2 -fPIC -c example.c
$ gcc -O2 -fPIC -c example_wrap.c -I/usr/local/lib/ruby/1.6/i686-linux
$ gcc -shared example.o example_wrap.o -o example.so
</pre>
</div>
<p> For other platforms it may be necessary to compile with the <tt>-fPIC</tt>
option to generate position-independent code. If in doubt, consult the
<p>
The -fPIC option tells GCC to generate position-independent code (PIC)
which is required for most architectures (it's not vital on x86, but
still a good idea as it allows code pages from the library to be shared between
processes). Other compilers may need a different option specified instead of
-fPIC.
</p>
<p>
If in doubt, consult the
manual pages for your compiler and linker to determine the correct set
of options. You might also check the <a href="http://www.dabeaz.com/cgi-bin/wiki.pl">SWIG Wiki</a>
for additional information. </p>
<H3><a name="Ruby_nn6"></a>36.1.4 Using your module</H3>
<H3><a name="Ruby_nn6"></a>38.1.4 Using your module</H3>
<p> Ruby <i>module</i> names must be capitalized,
@ -301,7 +309,7 @@ begins with: </p>
<p> will result in an extension module using the feature name
"example" and Ruby module name "Example". </p>
<H3><a name="Ruby_nn7"></a>36.1.5 Static linking</H3>
<H3><a name="Ruby_nn7"></a>38.1.5 Static linking</H3>
<p> An alternative approach to dynamic linking is to rebuild the
@ -316,7 +324,7 @@ finding the Ruby source, adding an entry to the <tt>ext/Setup</tt>
file, adding your directory to the list of extensions in the file, and
finally rebuilding Ruby. </p>
<H3><a name="Ruby_nn8"></a>36.1.6 Compilation of C++ extensions</H3>
<H3><a name="Ruby_nn8"></a>38.1.6 Compilation of C++ extensions</H3>
<p> On most machines, C++ extension modules should be linked
@ -325,8 +333,8 @@ using the C++ compiler. For example: </p>
<div class="code shell">
<pre>
$ swig -c++ -ruby example.i
$ g++ -c example.cxx
$ g++ -c example_wrap.cxx -I/usr/local/lib/ruby/1.6/i686-linux
$ g++ -fPIC -c example.cxx
$ g++ -fPIC -c example_wrap.cxx -I/usr/local/lib/ruby/1.6/i686-linux
$ g++ -shared example.o example_wrap.o -o example.so
</pre>
</div>
@ -348,7 +356,7 @@ $libs = append_library($libs, "supc++")
create_makefile('example')</pre>
</div>
<H2><a name="Ruby_nn9"></a>36.2 Building Ruby Extensions under Windows 95/NT</H2>
<H2><a name="Ruby_nn9"></a>38.2 Building Ruby Extensions under Windows 95/NT</H2>
<p> Building a SWIG extension to Ruby under Windows 95/NT is
@ -373,7 +381,7 @@ order to build extensions, you may need to download the source
distribution to the Ruby package, as you will need the Ruby header
files. </p>
<H3><a name="Ruby_nn10"></a>36.2.1 Running SWIG from Developer Studio</H3>
<H3><a name="Ruby_nn10"></a>38.2.1 Running SWIG from Developer Studio</H3>
<p> If you are developing your application within Microsoft
@ -437,13 +445,13 @@ Foo = 3.0
</pre>
</div>
<H2><a name="Ruby_nn11"></a>36.3 The Ruby-to-C/C++ Mapping</H2>
<H2><a name="Ruby_nn11"></a>38.3 The Ruby-to-C/C++ Mapping</H2>
<p> This section describes the basics of how SWIG maps C or C++
declarations in your SWIG interface files to Ruby constructs. </p>
<H3><a name="Ruby_nn12"></a>36.3.1 Modules</H3>
<H3><a name="Ruby_nn12"></a>38.3.1 Modules</H3>
<p> The SWIG <tt>%module</tt> directive specifies
@ -515,7 +523,7 @@ option to wrap everything into the global module, take care that the
names of your constants, classes and methods don't conflict with any of
Ruby's built-in names. </p>
<H3><a name="Ruby_nn13"></a>36.3.2 Functions</H3>
<H3><a name="Ruby_nn13"></a>38.3.2 Functions</H3>
<p> Global functions are wrapped as Ruby module methods. For
@ -549,7 +557,7 @@ irb(main):002:0&gt; <b>Example.fact(4)</b>
24</pre>
</div>
<H3><a name="Ruby_nn14"></a>36.3.3 Variable Linking</H3>
<H3><a name="Ruby_nn14"></a>38.3.3 Variable Linking</H3>
<p> C/C++ global variables are wrapped as a pair of singleton
@ -611,7 +619,7 @@ directive. For example: </p>
effect until it is explicitly disabled using <tt>%mutable</tt>.
</p>
<H3><a name="Ruby_nn15"></a>36.3.4 Constants</H3>
<H3><a name="Ruby_nn15"></a>38.3.4 Constants</H3>
<p> C/C++ constants are wrapped as module constants initialized
@ -639,7 +647,7 @@ irb(main):002:0&gt; <b>Example::PI</b>
3.14159</pre>
</div>
<H3><a name="Ruby_nn16"></a>36.3.5 Pointers</H3>
<H3><a name="Ruby_nn16"></a>38.3.5 Pointers</H3>
<p> "Opaque" pointers to arbitrary C/C++ types (i.e. types that
@ -663,7 +671,7 @@ returns an instance of an internally generated Ruby class: </p>
<p> A <tt>NULL</tt> pointer is always represented by
the Ruby <tt>nil</tt> object. </p>
<H3><a name="Ruby_nn17"></a>36.3.6 Structures</H3>
<H3><a name="Ruby_nn17"></a>38.3.6 Structures</H3>
<p> C/C++ structs are wrapped as Ruby classes, with accessor
@ -768,7 +776,7 @@ void Bar_f_set(Bar *b, Foo *val) {
}</pre>
</div>
<H3><a name="Ruby_nn18"></a>36.3.7 C++ classes</H3>
<H3><a name="Ruby_nn18"></a>38.3.7 C++ classes</H3>
<p> Like structs, C++ classes are wrapped by creating a new Ruby
@ -823,7 +831,7 @@ Ale
3</pre>
</div>
<H3><a name="Ruby_nn19"></a>36.3.8 C++ Inheritance</H3>
<H3><a name="Ruby_nn19"></a>38.3.8 C++ Inheritance</H3>
<p> The SWIG type-checker is fully aware of C++ inheritance.
@ -976,7 +984,7 @@ inherit from both <tt>Base1</tt> and <tt>Base2</tt>
(i.e. they exhibit <a href="http://c2.com/cgi/wiki?DuckTyping">"Duck
Typing"</a>). </p>
<H3><a name="Ruby_nn20"></a>36.3.9 C++ Overloaded Functions</H3>
<H3><a name="Ruby_nn20"></a>38.3.9 C++ Overloaded Functions</H3>
<p> C++ overloaded functions, methods, and constructors are
@ -1066,7 +1074,7 @@ arises--in this case, the first declaration takes precedence. </p>
<p>Please refer to the <a href="SWIGPlus.html#SWIGPlus">"SWIG
and C++"</a> chapter for more information about overloading. </p>
<H3><a name="Ruby_nn21"></a>36.3.10 C++ Operators</H3>
<H3><a name="Ruby_nn21"></a>38.3.10 C++ Operators</H3>
<p> For the most part, overloaded operators are handled
@ -1108,7 +1116,7 @@ c = Example.add_complex(a, b)</pre>
is discussed in the <a href="#Ruby_operator_overloading">section
on operator overloading</a>. </p>
<H3><a name="Ruby_nn22"></a>36.3.11 C++ namespaces</H3>
<H3><a name="Ruby_nn22"></a>38.3.11 C++ namespaces</H3>
<p> SWIG is aware of C++ namespaces, but namespace names do not
@ -1165,7 +1173,7 @@ and create extension modules for each namespace separately. If your
program utilizes thousands of small deeply nested namespaces each with
identical symbol names, well, then you get what you deserve. </p>
<H3><a name="Ruby_nn23"></a>36.3.12 C++ templates</H3>
<H3><a name="Ruby_nn23"></a>38.3.12 C++ templates</H3>
<p> C++ templates don't present a huge problem for SWIG. However,
@ -1207,7 +1215,7 @@ irb(main):004:0&gt; <b>p.second</b>
4</pre>
</div>
<H3><a name="Ruby_nn23_1"></a>36.3.13 C++ Standard Template Library (STL)</H3>
<H3><a name="Ruby_nn23_1"></a>38.3.13 C++ Standard Template Library (STL)</H3>
<p> On a related note, the standard SWIG library contains a
@ -1300,7 +1308,7 @@ puts v
shown in these examples. More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a>
chapter.</p>
<H3><a name="Ruby_C_STL_Functors"></a>36.3.14 C++ STL Functors</H3>
<H3><a name="Ruby_C_STL_Functors"></a>38.3.14 C++ STL Functors</H3>
<p>Some containers in the STL allow you to modify their default
@ -1361,7 +1369,7 @@ b
</pre>
</div>
<H3><a name="Ruby_C_Iterators"></a>36.3.15 C++ STL Iterators</H3>
<H3><a name="Ruby_C_Iterators"></a>38.3.15 C++ STL Iterators</H3>
<p>The STL is well known for the use of iterators. There
@ -1444,7 +1452,7 @@ i
<p>If you'd rather have STL classes without any iterators, you should define<tt> -DSWIG_NO_EXPORT_ITERATOR_METHODS </tt>when running swig.</p>
<H3><a name="Ruby_nn24"></a>36.3.16 C++ Smart Pointers</H3>
<H3><a name="Ruby_nn24"></a>38.3.16 C++ Smart Pointers</H3>
<p> In certain C++ programs, it is common to use classes that
@ -1509,7 +1517,7 @@ method. For example: </p>
<pre>irb(main):004:0&gt; <b>f = p.__deref__()</b> # Returns underlying Foo *</pre>
</div>
<H3><a name="Ruby_nn25"></a>36.3.17 Cross-Language Polymorphism</H3>
<H3><a name="Ruby_nn25"></a>38.3.17 Cross-Language Polymorphism</H3>
<p> SWIG's Ruby module supports cross-language polymorphism
@ -1518,7 +1526,7 @@ module. Rather than duplicate the information presented in the <a href="Python.h
section just notes the differences that you need to be aware of when
using this feature with Ruby. </p>
<H4><a name="Ruby_nn26"></a>36.3.17.1 Exception Unrolling</H4>
<H4><a name="Ruby_nn26"></a>38.3.17.1 Exception Unrolling</H4>
<p> Whenever a C++ director class routes one of its virtual
@ -1541,7 +1549,7 @@ method is "wrapped" using the <tt>rb_rescue2()</tt>
function from Ruby's C API. If any Ruby exception is raised, it will be
caught here and a C++ exception is raised in its place. </p>
<H2><a name="Ruby_nn27"></a>36.4 Naming</H2>
<H2><a name="Ruby_nn27"></a>38.4 Naming</H2>
<p>Ruby has several common naming conventions. Constants are
@ -1579,7 +1587,7 @@ generated
by SWIG, it is turned off by default in SWIG 1.3.28. However, it is
planned to become the default option in future releases.</p>
<H3><a name="Ruby_nn28"></a>36.4.1 Defining Aliases</H3>
<H3><a name="Ruby_nn28"></a>38.4.1 Defining Aliases</H3>
<p> It's a fairly common practice in the Ruby built-ins and
@ -1649,7 +1657,7 @@ matching rules used for other kinds of features apply (see the chapter
on <a href="Customization.html#Customization">"Customization
Features"</a>) for more details).</p>
<H3><a name="Ruby_nn29"></a>36.4.2 Predicate Methods</H3>
<H3><a name="Ruby_nn29"></a>38.4.2 Predicate Methods</H3>
<p> Ruby methods that return a boolean value and end in a
@ -1698,7 +1706,7 @@ using SWIG's "features" mechanism and so the same name matching rules
used for other kinds of features apply (see the chapter on <a href="Customization.html#Customization">"Customization
Features"</a>) for more details). </p>
<H3><a name="Ruby_nn30"></a>36.4.3 Bang Methods</H3>
<H3><a name="Ruby_nn30"></a>38.4.3 Bang Methods</H3>
<p> Ruby methods that modify an object in-place and end in an
@ -1730,7 +1738,7 @@ using SWIG's "features" mechanism and so the same name matching rules
used for other kinds of features apply (see the chapter on <a href="Customization.html#Customization">"Customization
Features"</a>) for more details). </p>
<H3><a name="Ruby_nn31"></a>36.4.4 Getters and Setters</H3>
<H3><a name="Ruby_nn31"></a>38.4.4 Getters and Setters</H3>
<p> Often times a C++ library will expose properties through
@ -1765,7 +1773,7 @@ irb(main):003:0&gt; <b>puts foo.value</b></pre>
%rename("value=") Foo::setValue(int value);</pre>
</div>
<H2><a name="Ruby_nn32"></a>36.5 Input and output parameters</H2>
<H2><a name="Ruby_nn32"></a>38.5 Input and output parameters</H2>
<p> A common problem in some C programs is handling parameters
@ -1904,10 +1912,10 @@ void get_dimensions(Matrix *m, int *rows, int*columns);</pre>
<pre>r, c = Example.get_dimensions(m)</pre>
</div>
<H2><a name="Ruby_nn33"></a>36.6 Exception handling </H2>
<H2><a name="Ruby_nn33"></a>38.6 Exception handling </H2>
<H3><a name="Ruby_nn34"></a>36.6.1 Using the %exception directive </H3>
<H3><a name="Ruby_nn34"></a>38.6.1 Using the %exception directive </H3>
<p>The SWIG <tt>%exception</tt> directive can be
@ -2016,7 +2024,7 @@ methods and functions named <tt>getitem</tt> and <tt>setitem</tt>.
limited to C++ exception handling. See the chapter on <a href="Customization.html#Customization">Customization
Features</a> for more examples.</p>
<H3><a name="Ruby_nn34_2"></a>36.6.2 Handling Ruby Blocks </H3>
<H3><a name="Ruby_nn34_2"></a>38.6.2 Handling Ruby Blocks </H3>
<p>One of the highlights of Ruby and most of its standard library
@ -2083,7 +2091,7 @@ a special in typemap, like:</p>
<p>For more information on typemaps, see <a href="#Ruby_nn37">Typemaps</a>.</p>
<H3><a name="Ruby_nn35"></a>36.6.3 Raising exceptions </H3>
<H3><a name="Ruby_nn35"></a>38.6.3 Raising exceptions </H3>
<p>There are three ways to raise exceptions from C++ code to
@ -2240,7 +2248,7 @@ function. The first argument passed to <tt>rb_raise()</tt>
is the exception type. You can raise a custom exception type or one of
the built-in Ruby exception types.</p>
<H3><a name="Ruby_nn36"></a>36.6.4 Exception classes </H3>
<H3><a name="Ruby_nn36"></a>38.6.4 Exception classes </H3>
<p>Starting with SWIG 1.3.28, the Ruby module supports the <tt>%exceptionclass</tt>
@ -2277,7 +2285,7 @@ end </pre>
<p>For another example look at swig/Examples/ruby/exception_class.
</p>
<H2><a name="Ruby_nn37"></a>36.7 Typemaps</H2>
<H2><a name="Ruby_nn37"></a>38.7 Typemaps</H2>
<p> This section describes how you can modify SWIG's default
@ -2292,7 +2300,7 @@ a required part of using SWIG---the default wrapping behavior is enough
in most cases. Typemaps are only used if you want to change some aspect
of the primitive C-Ruby interface.</p>
<H3><a name="Ruby_nn38"></a>36.7.1 What is a typemap?</H3>
<H3><a name="Ruby_nn38"></a>38.7.1 What is a typemap?</H3>
<p> A typemap is nothing more than a code generation rule that is
@ -2449,7 +2457,7 @@ to be used as follows (notice how the length parameter is omitted): </p>
2</pre>
</div>
<H3><a name="Ruby_Typemap_scope"></a>36.7.2 Typemap scope</H3>
<H3><a name="Ruby_Typemap_scope"></a>38.7.2 Typemap scope</H3>
<p> Once defined, a typemap remains in effect for all of the
@ -2495,7 +2503,7 @@ where the class itself is defined. For example:</p>
};</pre>
</div>
<H3><a name="Ruby_Copying_a_typemap"></a>36.7.3 Copying a typemap</H3>
<H3><a name="Ruby_Copying_a_typemap"></a>38.7.3 Copying a typemap</H3>
<p> A typemap is copied by using assignment. For example:</p>
@ -2537,7 +2545,7 @@ rules as for <tt>
%apply (char *buf, int len) { (char *buffer, int size) }; // Multiple arguments</pre>
</div>
<H3><a name="Ruby_Deleting_a_typemap"></a>36.7.4 Deleting a typemap</H3>
<H3><a name="Ruby_Deleting_a_typemap"></a>38.7.4 Deleting a typemap</H3>
<p> A typemap can be deleted by simply defining no code. For
@ -2562,7 +2570,7 @@ defined by typemaps, clearing a fundamental type like <tt>int</tt>
will make that type unusable unless you also define a new set of
typemaps immediately after the clear operation.</p>
<H3><a name="Ruby_Placement_of_typemaps"></a>36.7.5 Placement of typemaps</H3>
<H3><a name="Ruby_Placement_of_typemaps"></a>38.7.5 Placement of typemaps</H3>
<p> Typemap declarations can be declared in the global scope,
@ -2633,13 +2641,13 @@ In this example, this is done using the class declaration <tt>class
string</tt>
.</p>
<H3><a name="Ruby_nn39"></a>36.7.6 Ruby typemaps</H3>
<H3><a name="Ruby_nn39"></a>38.7.6 Ruby typemaps</H3>
<p>The following list details all of the typemap methods that
can be used by the Ruby module: </p>
<H4><a name="Ruby_in_typemap"></a>36.7.6.1 "in" typemap</H4>
<H4><a name="Ruby_in_typemap"></a>38.7.6.1 "in" typemap</H4>
<p>Converts Ruby objects to input
@ -2706,7 +2714,7 @@ arguments to be specified. For example:</p>
<p> At this time, only zero or one arguments may be converted.</p>
<H4><a name="Ruby_typecheck_typemap"></a>36.7.6.2 "typecheck" typemap</H4>
<H4><a name="Ruby_typecheck_typemap"></a>38.7.6.2 "typecheck" typemap</H4>
<p> The "typecheck" typemap is used to support overloaded
@ -2728,7 +2736,7 @@ program uses overloaded methods, you should also define a collection of
"typecheck" typemaps. More details about this follow in a later section
on "Typemaps and Overloading."</p>
<H4><a name="Ruby_out_typemap"></a>36.7.6.3 "out" typemap</H4>
<H4><a name="Ruby_out_typemap"></a>38.7.6.3 "out" typemap</H4>
<p>Converts return value of a C function
@ -2779,7 +2787,7 @@ version of the C datatype matched by the typemap.</td>
</table>
</div>
<H4><a name="Ruby_arginit_typemap"></a>36.7.6.4 "arginit" typemap</H4>
<H4><a name="Ruby_arginit_typemap"></a>38.7.6.4 "arginit" typemap</H4>
<p> The "arginit" typemap is used to set the initial value of a
@ -2794,7 +2802,7 @@ applications. For example:</p>
}</pre>
</div>
<H4><a name="Ruby_default_typemap"></a>36.7.6.5 "default" typemap</H4>
<H4><a name="Ruby_default_typemap"></a>38.7.6.5 "default" typemap</H4>
<p> The "default" typemap is used to turn an argument into a
@ -2819,7 +2827,7 @@ arguments that follow must have default values. See the <a href="http://www.swig
Default/optional arguments</a> section for further information on
default argument wrapping.</p>
<H4><a name="Ruby_check_typemap"></a>36.7.6.6 "check" typemap</H4>
<H4><a name="Ruby_check_typemap"></a>38.7.6.6 "check" typemap</H4>
<p> The "check" typemap is used to supply value checking code
@ -2834,7 +2842,7 @@ arguments have been converted. For example:</p>
}</pre>
</div>
<H4><a name="Ruby_argout_typemap_"></a>36.7.6.7 "argout" typemap</H4>
<H4><a name="Ruby_argout_typemap_"></a>38.7.6.7 "argout" typemap</H4>
<p> The "argout" typemap is used to return values from arguments.
@ -2888,7 +2896,7 @@ some function like SWIG_Ruby_AppendOutput.</p>
<p> See the <tt>typemaps.i</tt> library for examples.</p>
<H4><a name="Ruby_freearg_typemap_"></a>36.7.6.8 "freearg" typemap</H4>
<H4><a name="Ruby_freearg_typemap_"></a>38.7.6.8 "freearg" typemap</H4>
<p> The "freearg" typemap is used to cleanup argument data. It is
@ -2915,7 +2923,7 @@ This code is also placed into a special variable <tt>$cleanup</tt>
that may be used in other typemaps whenever a wrapper function needs to
abort prematurely.</p>
<H4><a name="Ruby_newfree_typemap"></a>36.7.6.9 "newfree" typemap</H4>
<H4><a name="Ruby_newfree_typemap"></a>38.7.6.9 "newfree" typemap</H4>
<p> The "newfree" typemap is used in conjunction with the <tt>%newobject</tt>
@ -2939,7 +2947,7 @@ string *foo();</pre>
<p> See <a href="Customization.html#Customization_ownership">Object
ownership and %newobject</a> for further details.</p>
<H4><a name="Ruby_memberin_typemap"></a>36.7.6.10 "memberin" typemap</H4>
<H4><a name="Ruby_memberin_typemap"></a>38.7.6.10 "memberin" typemap</H4>
<p> The "memberin" typemap is used to copy data from<em> an
@ -2957,21 +2965,21 @@ example:</p>
already provides a default implementation for arrays, strings, and
other objects.</p>
<H4><a name="Ruby_varin_typemap"></a>36.7.6.11 "varin" typemap</H4>
<H4><a name="Ruby_varin_typemap"></a>38.7.6.11 "varin" typemap</H4>
<p> The "varin" typemap is used to convert objects in the target
language to C for the purposes of assigning to a C/C++ global variable.
This is implementation specific.</p>
<H4><a name="Ruby_varout_typemap_"></a>36.7.6.12 "varout" typemap</H4>
<H4><a name="Ruby_varout_typemap_"></a>38.7.6.12 "varout" typemap</H4>
<p> The "varout" typemap is used to convert a C/C++ object to an
object in the target language when reading a C/C++ global variable.
This is implementation specific.</p>
<H4><a name="Ruby_throws_typemap"></a>36.7.6.13 "throws" typemap</H4>
<H4><a name="Ruby_throws_typemap"></a>38.7.6.13 "throws" typemap</H4>
<p> The "throws" typemap is only used when SWIG parses a C++
@ -3012,7 +3020,7 @@ specification yet they do throw exceptions, SWIG cannot know how to
deal with them. For a neat way to handle these, see the <a href="http://www.swig.org/Doc1.3/SWIGDocumentation.html#exception">Exception
handling with %exception</a> section.</p>
<H4><a name="Ruby_directorin_typemap"></a>36.7.6.14 directorin typemap</H4>
<H4><a name="Ruby_directorin_typemap"></a>38.7.6.14 directorin typemap</H4>
<p>Converts C++ objects in director
@ -3071,7 +3079,7 @@ referring to the class itself.</td>
</table>
</div>
<H4><a name="Ruby_directorout_typemap"></a>36.7.6.15 directorout typemap</H4>
<H4><a name="Ruby_directorout_typemap"></a>38.7.6.15 directorout typemap</H4>
<p>Converts Ruby objects in director
@ -3144,7 +3152,7 @@ exception.
</p>
<H4><a name="Ruby_directorargout_typemap"></a>36.7.6.16 directorargout typemap</H4>
<H4><a name="Ruby_directorargout_typemap"></a>38.7.6.16 directorargout typemap</H4>
<p>Output argument processing in director
@ -3202,19 +3210,19 @@ referring to the instance of the class itself</td>
</table>
</div>
<H4><a name="Ruby_ret_typemap"></a>36.7.6.17 ret typemap</H4>
<H4><a name="Ruby_ret_typemap"></a>38.7.6.17 ret typemap</H4>
<p>Cleanup of function return values
</p>
<H4><a name="Ruby_globalin_typemap"></a>36.7.6.18 globalin typemap</H4>
<H4><a name="Ruby_globalin_typemap"></a>38.7.6.18 globalin typemap</H4>
<p>Setting of C global variables
</p>
<H3><a name="Ruby_nn40"></a>36.7.7 Typemap variables</H3>
<H3><a name="Ruby_nn40"></a>38.7.7 Typemap variables</H3>
<p>
@ -3264,7 +3272,7 @@ so that their values can be properly assigned. </div>
<div class="indent">The Ruby name of the wrapper function
being created. </div>
<H3><a name="Ruby_nn41"></a>36.7.8 Useful Functions</H3>
<H3><a name="Ruby_nn41"></a>38.7.8 Useful Functions</H3>
<p> When you write a typemap, you usually have to work directly
@ -3279,7 +3287,7 @@ stick to the swig functions instead of the native Ruby functions.
That should help you avoid having to rewrite a lot of typemaps
across multiple languages.</p>
<H4><a name="Ruby_nn42"></a>36.7.8.1 C Datatypes to Ruby Objects</H4>
<H4><a name="Ruby_nn42"></a>38.7.8.1 C Datatypes to Ruby Objects</H4>
<div class="diagram">
@ -3321,7 +3329,7 @@ SWIG_From_float(float)</td>
</table>
</div>
<H4><a name="Ruby_nn43"></a>36.7.8.2 Ruby Objects to C Datatypes</H4>
<H4><a name="Ruby_nn43"></a>38.7.8.2 Ruby Objects to C Datatypes</H4>
<p>Here, while the Ruby versions return the value directly, the SWIG
@ -3389,7 +3397,7 @@ versions do not, but return a status value to indicate success (<tt>SWIG_OK</tt>
</table>
</div>
<H4><a name="Ruby_nn44"></a>36.7.8.3 Macros for VALUE</H4>
<H4><a name="Ruby_nn44"></a>38.7.8.3 Macros for VALUE</H4>
<p> <tt>RSTRING_LEN(str)</tt> </p>
@ -3412,7 +3420,7 @@ versions do not, but return a status value to indicate success (<tt>SWIG_OK</tt>
<div class="indent">pointer to array storage</div>
<H4><a name="Ruby_nn45"></a>36.7.8.4 Exceptions</H4>
<H4><a name="Ruby_nn45"></a>38.7.8.4 Exceptions</H4>
<p> <tt>void rb_raise(VALUE exception, const char *fmt,
@ -3491,7 +3499,7 @@ message to standard error if Ruby was invoked with the <tt>-w</tt>
flag. The given format string <i>fmt</i> and remaining
arguments are interpreted as with <tt>printf()</tt>. </div>
<H4><a name="Ruby_nn46"></a>36.7.8.5 Iterators</H4>
<H4><a name="Ruby_nn46"></a>38.7.8.5 Iterators</H4>
<p> <tt>void rb_iter_break()</tt> </p>
@ -3537,14 +3545,14 @@ VALUE), VALUE value)</tt></p>
<div class="indent"> Equivalent to Ruby's <tt>throw</tt>.
</div>
<H3><a name="Ruby_nn47"></a>36.7.9 Typemap Examples</H3>
<H3><a name="Ruby_nn47"></a>38.7.9 Typemap Examples</H3>
<p> This section includes a few examples of typemaps. For more
examples, you might look at the examples in the <tt>Example/ruby</tt>
directory. </p>
<H3><a name="Ruby_nn48"></a>36.7.10 Converting a Ruby array to a char **</H3>
<H3><a name="Ruby_nn48"></a>38.7.10 Converting a Ruby array to a char **</H3>
<p> A common problem in many C programs is the processing of
@ -3609,7 +3617,7 @@ array. Since dynamic memory allocation is used to allocate memory for
the array, the "freearg" typemap is used to later release this memory
after the execution of the C function. </p>
<H3><a name="Ruby_nn49"></a>36.7.11 Collecting arguments in a hash</H3>
<H3><a name="Ruby_nn49"></a>38.7.11 Collecting arguments in a hash</H3>
<p> Ruby's solution to the "keyword arguments" capability of some
@ -3823,7 +3831,7 @@ memory leak. Fortunately, this typemap is a lot easier to write: </p>
program that uses the extension, can be found in the <tt>Examples/ruby/hashargs</tt>
directory of the SWIG distribution. </p>
<H3><a name="Ruby_nn50"></a>36.7.12 Pointer handling</H3>
<H3><a name="Ruby_nn50"></a>38.7.12 Pointer handling</H3>
<p> Occasionally, it might be necessary to convert pointer values
@ -3882,7 +3890,7 @@ For example: </p>
}</pre>
</div>
<H4><a name="Ruby_nn51"></a>36.7.12.1 Ruby Datatype Wrapping</H4>
<H4><a name="Ruby_nn51"></a>38.7.12.1 Ruby Datatype Wrapping</H4>
<p> <tt>VALUE Data_Wrap_Struct(VALUE class, void
@ -3909,7 +3917,7 @@ as above. </div>
type <i>c-type</i> from the data object <i>obj</i>
and assigns that pointer to <i>ptr</i>. </div>
<H3><a name="Ruby_nn52"></a>36.7.13 Example: STL Vector to Ruby Array</H3>
<H3><a name="Ruby_nn52"></a>38.7.13 Example: STL Vector to Ruby Array</H3>
<p>Another use for macros and type maps is to create a Ruby array
@ -4001,7 +4009,7 @@ STL with ruby, you are advised to use the standard swig STL library,
which does much more than this. Refer to the section called
the<a href="#Ruby_nn23_1"> C++ Standard Template Library</a>.
<H2><a name="Ruby_nn65"></a>36.8 Docstring Features</H2>
<H2><a name="Ruby_nn65"></a>38.8 Docstring Features</H2>
<p>
@ -4035,7 +4043,7 @@ generate ri documentation from a c wrap file, you could do:</p>
$ rdoc -r file_wrap.c
</pre></div>
<H3><a name="Ruby_nn66"></a>36.8.1 Module docstring</H3>
<H3><a name="Ruby_nn66"></a>38.8.1 Module docstring</H3>
<p>
@ -4065,7 +4073,7 @@ layout of controls on a panel, etc. to be loaded from an XML file."
%module(docstring=DOCSTRING) xrc</pre>
</div>
<H3><a name="Ruby_nn67"></a>36.8.2 %feature("autodoc")</H3>
<H3><a name="Ruby_nn67"></a>38.8.2 %feature("autodoc")</H3>
<p>Since SWIG does know everything about the function it wraps,
@ -4086,7 +4094,7 @@ several options for autodoc controlled by the value given to the
feature, described below.
</p>
<H4><a name="Ruby_nn68"></a>36.8.2.1 %feature("autodoc", "0")</H4>
<H4><a name="Ruby_nn68"></a>38.8.2.1 %feature("autodoc", "0")</H4>
<p>
@ -4110,7 +4118,7 @@ Then Ruby code like this will be generated:
...</pre>
</div>
<H4><a name="Ruby_autodoc1"></a>36.8.2.2 %feature("autodoc", "1")</H4>
<H4><a name="Ruby_autodoc1"></a>38.8.2.2 %feature("autodoc", "1")</H4>
<p>
@ -4130,7 +4138,7 @@ this:
...</pre>
</div>
<H4><a name="Ruby_autodoc2"></a>36.8.2.3 %feature("autodoc", "2")</H4>
<H4><a name="Ruby_autodoc2"></a>38.8.2.3 %feature("autodoc", "2")</H4>
<p>
@ -4142,7 +4150,7 @@ parameter types with the "2" option will result in Ruby code like
this:
</p>
<H4><a name="Ruby_feature_autodoc3"></a>36.8.2.4 %feature("autodoc", "3")</H4>
<H4><a name="Ruby_feature_autodoc3"></a>38.8.2.4 %feature("autodoc", "3")</H4>
<p>
@ -4163,7 +4171,7 @@ Parameters:
bar - Bar</pre>
</div>
<H4><a name="Ruby_nn70"></a>36.8.2.5 %feature("autodoc", "docstring")</H4>
<H4><a name="Ruby_nn70"></a>38.8.2.5 %feature("autodoc", "docstring")</H4>
<p>
@ -4179,7 +4187,7 @@ generated string. For example:
void GetPosition(int* OUTPUT, int* OUTPUT);</pre>
</div>
<H3><a name="Ruby_nn71"></a>36.8.3 %feature("docstring")</H3>
<H3><a name="Ruby_nn71"></a>38.8.3 %feature("docstring")</H3>
<p>
@ -4190,10 +4198,10 @@ docstring associated with classes, function or methods are output.
If an item already has an autodoc string then it is combined with the
docstring and they are output together. </p>
<H2><a name="Ruby_nn53"></a>36.9 Advanced Topics</H2>
<H2><a name="Ruby_nn53"></a>38.9 Advanced Topics</H2>
<H3><a name="Ruby_operator_overloading"></a>36.9.1 Operator overloading</H3>
<H3><a name="Ruby_operator_overloading"></a>38.9.1 Operator overloading</H3>
<p> SWIG allows operator overloading with, by using the <tt>%extend</tt>
@ -4374,7 +4382,7 @@ separate method for handling <i>inequality</i> since Ruby
parses the expression <i>a != b</i> as <i>!(a == b)</i>.
</p>
<H3><a name="Ruby_nn55"></a>36.9.2 Creating Multi-Module Packages</H3>
<H3><a name="Ruby_nn55"></a>38.9.2 Creating Multi-Module Packages</H3>
<p> The chapter on <a href="Modules.html#Modules">Working
@ -4500,7 +4508,7 @@ irb(main):005:0&gt; <b>c.getX()</b>
5.0</pre>
</div>
<H3><a name="Ruby_nn56"></a>36.9.3 Specifying Mixin Modules</H3>
<H3><a name="Ruby_nn56"></a>38.9.3 Specifying Mixin Modules</H3>
<p> The Ruby language doesn't support multiple inheritance, but
@ -4567,7 +4575,7 @@ matching rules used for other kinds of features apply (see the chapter
on <a href="Customization.html#Customization">"Customization
Features"</a>) for more details). </p>
<H2><a name="Ruby_nn57"></a>36.10 Memory Management</H2>
<H2><a name="Ruby_nn57"></a>38.10 Memory Management</H2>
<p>One of the most common issues in generating SWIG bindings for
@ -4590,7 +4598,7 @@ to C++ (or vice versa) depending on what function or methods are
invoked. Clearly, developing a SWIG wrapper requires a thorough
understanding of how the underlying library manages memory.</p>
<H3><a name="Ruby_nn58"></a>36.10.1 Mark and Sweep Garbage Collector </H3>
<H3><a name="Ruby_nn58"></a>38.10.1 Mark and Sweep Garbage Collector </H3>
<p>Ruby uses a mark and sweep garbage collector. When the garbage
@ -4622,7 +4630,7 @@ any memory has been allocated in creating the underlying C struct or
C++ struct, then a "free" function must be defined that deallocates
this memory. </p>
<H3><a name="Ruby_nn59"></a>36.10.2 Object Ownership</H3>
<H3><a name="Ruby_nn59"></a>38.10.2 Object Ownership</H3>
<p>As described above, memory management depends on clearly
@ -4682,7 +4690,7 @@ public:
C++ constructor, thus creating a new <tt>foo</tt> object.
By default, SWIG will assign the new Ruby object a "free" function.
When the Ruby object is garbage collected, the "free" function will be
called. It in turn will call <tt>Foo's</tt> destructor.</p>
called. It in turn will call <tt>Foo</tt>'s destructor.</p>
<p>Next, consider this code: </p>
@ -4767,7 +4775,7 @@ public:
<p> This code can be seen in swig/examples/ruby/tracking.</p>
<H3><a name="Ruby_nn60"></a>36.10.3 Object Tracking</H3>
<H3><a name="Ruby_nn60"></a>38.10.3 Object Tracking</H3>
<p>The remaining parts of this section will use the class library
@ -4992,7 +5000,7 @@ However, if you implement your own free functions (see below) you may
also have to call the<tt> SWIG_RubyRemoveTracking</tt> and <tt>RubyUnlinkObjects</tt>
methods.</p>
<H3><a name="Ruby_nn61"></a>36.10.4 Mark Functions</H3>
<H3><a name="Ruby_nn61"></a>38.10.4 Mark Functions</H3>
<p>With a bit more testing, we see that our class library still
@ -5121,7 +5129,7 @@ irb(main):016:0&gt;</pre>
<p>This code can be seen in swig/examples/ruby/mark_function.</p>
<H3><a name="Ruby_nn62"></a>36.10.5 Free Functions</H3>
<H3><a name="Ruby_nn62"></a>38.10.5 Free Functions</H3>
<p>By default, SWIG creates a "free" function that is called when
@ -5288,7 +5296,7 @@ been freed, and thus raises a runtime exception.</p>
<p>This code can be seen in swig/examples/ruby/free_function.</p>
<H3><a name="Ruby_nn63"></a>36.10.6 Embedded Ruby and the C++ Stack</H3>
<H3><a name="Ruby_nn63"></a>38.10.6 Embedded Ruby and the C++ Stack</H3>
<p>As has been said, the Ruby GC runs and marks objects before

61
Doc/Manual/SWIG.html
View file

@ -224,7 +224,7 @@ $ swig -c++ -python -o example_wrap.cpp example.i
<p>
The C/C++ output file created by SWIG often
contains everything that is needed to construct a extension module
contains everything that is needed to construct an extension module
for the target scripting language. SWIG is not a stub compiler nor is it
usually necessary to edit the output file (and if you look at the output,
you probably won't want to). To build the final extension module, the
@ -233,7 +233,7 @@ program to create a shared library.
</p>
<p>
Many target languages will also generate proxy class files in the
For many target languages SWIG will also generate proxy class files in the
target language. The default output directory for these language
specific files is the same directory as the generated C/C++ file. This
can be modified using the <tt>-outdir</tt> option. For example:
@ -484,7 +484,7 @@ Or in Python:
Whenever possible, SWIG creates an interface that closely matches the underlying C/C++
code. However, due to subtle differences between languages, run-time
environments, and semantics, it is not always possible to do so. The
next few sections describes various aspects of this mapping.
next few sections describe various aspects of this mapping.
</p>
<H3><a name="SWIG_nn10"></a>5.2.1 Basic Type Handling</H3>
@ -728,7 +728,7 @@ However, for the same conservative reasons even a constant with a simple cast wi
<div class="code">
<pre>
#define F_CONST (double) 5 // A floating pointer constant with cast
#define F_CONST (double) 5 // A floating point constant with cast
</pre>
</div>
@ -750,7 +750,7 @@ enum values as assigned by the C compiler.
<p>
The <tt>%constant</tt> directive is used to more precisely create
constants corresponding to different C datatypes. Although it is not
usually not needed for simple values, it is more useful when working
usually needed for simple values, it is more useful when working
with pointers and other more complex datatypes. Typically, <tt>%constant</tt>
is only used when you want to add constants to the scripting language
interface that are not defined in the original header file.
@ -868,7 +868,7 @@ from a scripting language to a C <tt>char *</tt>, the pointer usually
points to string data stored inside the interpreter. It is almost
always a really bad idea to modify this data. Furthermore, some
languages may explicitly disallow it. For instance, in Python,
strings are supposed be immutable. If you violate this, you will probably
strings are supposed to be immutable. If you violate this, you will probably
receive a vast amount of wrath when you unleash your module on the world.
</p>
@ -1483,7 +1483,7 @@ void transpose(double (*a)[20]);
<p>
Like C, SWIG does not perform array bounds checking.
It is up to the
user to make sure the pointer points a suitably allocated region of memory.
user to make sure the pointer points to a suitably allocated region of memory.
</p>
<p>
@ -1888,11 +1888,22 @@ and a more descriptive one, but the two functions are otherwise equivalent:
<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>
can contain back-references of the form <tt>\N</tt> where <tt>N</tt> is a digit
from 0 to 9, or one of the following escape sequences: <tt>\l</tt>, <tt>\L</tt>,
<tt>\u</tt>, <tt>\U</tt> or <tt>\E</tt>. The back-references are replaced with the
contents of the corresponding capture group while the escape sequences perform the
case conversion in the substitution string: <tt>\l</tt> and <tt>\L</tt> convert to
the lower case, while <tt>\u</tt> and <tt>\U</tt> convert to the upper case. The
difference between the elements of each pair is that <tt>\l</tt> and <tt>\u</tt>
change the case of the next character only, while <tt>\L</tt> and <tt>\U</tt> do
it for all the remaining characters or until <tt>\E</tt> is encountered.
Finally please notice that backslashes need to be escaped in C strings, so in
practice <tt>"\\"</tt> must be used in all these escape sequences. For example,
to remove any alphabetic prefix before an underscore and capitalize the remaining
part you could use the following directive:
<tt>%rename("regex:/(\\w+)_(.*)/\\u\\2/")</tt></td>
<td><tt>prefix_print</tt></td><td><tt>Print</tt></td>
</tr>
<tr>
<td><tt>command:cmd</tt></td>
@ -2254,7 +2265,7 @@ disabled using <tt>%nocallback</tt>. When you do this, the interface now works
<p>
Notice that when the function is used as a callback, special names
such as <tt>add_cb</tt> is used instead. To call the function
such as <tt>add_cb</tt> are used instead. To call the function
normally, just use the original function name such as <tt>add()</tt>.
</p>
@ -2300,7 +2311,7 @@ handle C++ are described in the next section.
If SWIG encounters the definition of a structure or union, it
creates a set of accessor functions. Although SWIG does not need
structure definitions to build an interface, providing definitions
make it possible to access structure members. The accessor functions
makes it possible to access structure members. The accessor functions
generated by SWIG simply take a pointer to an object and allow access
to an individual member. For example, the declaration :</p>
@ -2423,7 +2434,7 @@ vector_struct</tt>, SWIG knows that this is the same as
Structures involving character strings require some care. SWIG assumes
that all members of type <tt>char *</tt> have been dynamically
allocated using <tt>malloc()</tt> and that they are NULL-terminated
ASCII strings. When such a member is modified, the previously contents
ASCII strings. When such a member is modified, the previous contents
will be released, and the new contents allocated. For example :</p>
<div class="code"><pre>
@ -2508,7 +2519,7 @@ typedef struct Bar {
<p>
When a structure member is wrapped, it is handled as a pointer, unless the <tt>%naturalvar</tt> directive
is used where it is handled more like a C++ reference (see <a href="SWIGPlus.html#SWIGPlus_member_data">C++ Member data</a>).
The accessors to the member variable as a pointer is effectively wrapped as follows:
The accessors to the member variable as a pointer are effectively wrapped as follows:
</p>
<div class="code">
@ -2645,8 +2656,8 @@ struct Bar { // Default constructor generated.
<p>
Since ignoring the implicit or default destructors most of the times
produce memory leaks, SWIG will always try to generate them. If
Since ignoring the implicit or default destructors most of the time
produces memory leaks, SWIG will always try to generate them. If
needed, however, you can selectively disable the generation of the
default/implicit destructor by using <tt>%nodefaultdtor</tt>
</p>
@ -2676,7 +2687,7 @@ has now been enabled as the default behavior.
<b>Note:</b> There are also the <tt>-nodefault</tt> option and
<tt>%nodefault</tt> directive, which disable both the default or
implicit destructor generation. This could lead to memory leaks across
the target languages, and is highly recommended you don't use them.
the target languages, and it is highly recommended you don't use them.
</p>
@ -3269,7 +3280,7 @@ initialization on module loading, you could write this:
<p>
This section describes the general approach for building interface
This section describes the general approach for building interfaces
with SWIG. The specifics related to a particular scripting language
are found in later chapters.</p>
@ -3284,9 +3295,9 @@ of steps you can follow to make an interface for a C program :</p>
<ul>
<li>Identify the functions that you want to wrap. It's probably not
necessary to access every single function in a C program--thus, a
necessary to access every single function of a C program--thus, a
little forethought can dramatically simplify the resulting scripting
language interface. C header files are particularly good source for
language interface. C header files are a particularly good source for
finding things to wrap.
<li>Create a new interface file to describe the scripting language
@ -3331,7 +3342,7 @@ to the <a href="http://www.swig.org/mail.html">swig-devel mailing list</a> or to
<p>
The preferred method of using SWIG is to generate separate interface
The preferred method of using SWIG is to generate a separate interface
file. Suppose you have the following C header file :</p>
<div class="code"><pre>
@ -3425,7 +3436,7 @@ include certain header files by using a <tt>%{,%}</tt> block like this:
#include &lt;GL/glu.h&gt;
%}
// Put rest of declarations here
// Put the rest of the declarations here
...
</pre></div>
@ -3467,7 +3478,7 @@ program that is more interactive. In many cases, the old
or Tcl script.</p>
<p>
<b>Note:</b> If some cases, you might be inclined to create a
<b>Note:</b> In some cases, you might be inclined to create a
scripting language wrapper for <tt>main()</tt>. If you do this, the
compilation will probably work and your module might even load
correctly. The only trouble is that when you call your

211
Doc/Manual/SWIGPlus.html
View file

@ -185,7 +185,6 @@ The following C++ features are not currently supported:</p>
<ul>
<li>Overloaded versions of certain operators (new, delete, etc.)
<li>Nested classes, see <a href="#SWIGPlus_nested_classes">Nested classes</a> for workarounds.
</ul>
<p>
@ -217,7 +216,7 @@ to use the C++ compiler. For example:
<div class="shell">
<pre>
$ swig -c++ -tcl example.i
$ c++ -c example_wrap.cxx
$ c++ -fPIC -c example_wrap.cxx
$ c++ example_wrap.o $(OBJS) -o example.so
</pre>
</div>
@ -960,8 +959,9 @@ Similarly, all data attributes declared as <tt>const</tt> are wrapped as read-on
</p>
<p>
By default, SWIG uses the const reference typemaps for members that are primitive types.
There are some subtle issues when wrapping data members that are
themselves classes. For instance, if you had another class like this,
not primitive types, such as classes. For instance, if you had another class like this,
</p>
<div class="code">
@ -974,7 +974,8 @@ public:
</div>
<p>
then the low-level accessor to the <tt>items</tt> member actually uses pointers. For example:
then the low-level accessor to the <tt>items</tt> member actually uses pointers.
For example:
</p>
<div class="code">
@ -999,31 +1000,7 @@ This can be somewhat unnatural for some types.
For example, a user would expect the STL std::string class member variables to be wrapped as a string in the target language,
rather than a pointer to this class.
The const reference typemaps offer this type of marshalling, so there is a feature to tell SWIG to use the const reference typemaps rather than the pointer typemaps.
It is the <tt>%naturalvar</tt> directive and is used as follows:
</p>
<div class="code">
<pre>
// All List variables will use const List&amp; typemaps
%naturalvar List;
// Only Foo::myList will use const List&amp; typemaps
%naturalvar Foo::myList;
struct Foo {
List myList;
};
// All variables will use const reference typemaps
%naturalvar;
</pre>
</div>
<p>
The observant reader will notice that <tt>%naturalvar</tt> works like any other
<a href="Customization.html#Customization_feature_flags">feature flag</a> directive,
except it can also be attached to class types.
The first of the example usages above show <tt>%naturalvar</tt> attaching to the <tt>List</tt> class.
Effectively this feature changes the way accessors are generated to the following:
It is the naturalvar feature and can be used to effectively change the way accessors are generated to the following:
</p>
<div class="code">
@ -1038,15 +1015,45 @@ void Foo_items_set(Foo *self, const List &amp;value) {
</div>
<p>
In fact it is generally a good idea to use this feature globally as the reference typemaps have extra NULL checking compared to the pointer typemaps.
The <tt>%naturalvar</tt> directive is a macro for, and hence equivalent to, <tt>%feature("naturalvar")</tt>. It can be used as follows:
</p>
<div class="code">
<pre>
// All List variables will use const List&amp; typemaps
%naturalvar List;
// Only Foo::myList will use const List&amp; typemaps
%naturalvar Foo::myList;
struct Foo {
List myList;
};
// All non-primitive types will use const reference typemaps
%naturalvar;
</pre>
</div>
<p>
The observant reader will notice that <tt>%naturalvar</tt> works like any other
<a href="Customization.html#Customization_feature_flags">feature flag</a> directive but with some extra flexibility.
The first of the example usages above shows <tt>%naturalvar</tt> attaching to the <tt>myList</tt>'s variable type, that is the <tt>List</tt> class.
The second usage shows <tt>%naturalvar</tt> attaching to the variable name.
Hence the naturalvar feature can be used on either the variable's name or type.
Note that using the naturalvar feature on a variable's name overrides any naturalvar feature attached to the variable's type.
</p>
<p>
It is generally a good idea to use this feature globally as the reference typemaps have extra NULL checking compared to the pointer typemaps.
A pointer can be NULL, whereas a reference cannot, so the extra checking ensures that the target language user does not pass in a value that translates
to a NULL pointer and thereby preventing any potential NULL pointer dereferences.
The <tt>%naturalvar</tt> feature will apply to global variables in addition to member variables in some language modules, eg C# and Java.
</p>
<p>
Other alternatives for turning this feature on globally are to use the <tt>swig -naturalvar</tt> commandline option
or the module mode option, <tt>%module(naturalvar=1)</tt>
The naturalvar behavior can also be turned on as a global setting via the <tt>-naturalvar</tt> commandline option
or the module mode option, <tt>%module(naturalvar=1)</tt>.
However, any use of <tt>%feature("naturalvar")</tt> will override the global setting.
</p>
<p>
@ -1522,7 +1529,7 @@ multiple inheritance.
spirit, and target language capabilities, as possible. In most
cases, this means that SWIG will parse the non-public inheritance
declarations, but that will have no effect in the generated code,
besides the implicit policies derived for constructor and
besides the implicit policies derived for constructors and
destructors.
</p>
@ -4967,141 +4974,55 @@ public:
<p>
There is some support for nested structs and unions when wrapping C code,
see <a href="SWIG.html#SWIG_nested_structs">Nested structures</a> for further details.
The added complexity of C++ compared to C means this approach does not work well for
C++ code (when using the -c++ command line option).
For C++, a nested class is treated much like an opaque pointer, so anything useful within the nested class, such as its
methods and variables, are not accessible from the target language.
True nested class support may be added to SWIG in the future, however,
until then some of the following workarounds can be applied to improve the situation.
If the target language supports the nested classes concept (like Java), the nested C++ classes
are wrapped as nested target language proxy classes. (In case of Java - "static" nested classes.)
Only public nested classes are wrapped. Otherwise there is little difference between nested and
normal classes.
</p>
<p>
It might be possible to use partial class information as often you can accept that the nested class is not needed,
especially if it is not actually used in any methods you need from the target language.
Imagine you are wrapping the following <tt>Outer</tt> class which contains a nested class <tt>Inner</tt>.
The easiest thing to do is turn a blind eye to the warning that SWIG generates, or simply suppress it:
If the target language doesn't support nested classes directly, or the support is not implemented in the
language module (like for python currently), then the visible nested classes are moved to the same name
space as the containing class (nesting hierarchy is "flattened"). The same behaviour may be turned on for
C# and Java by the %feature ("flatnested"); If there is a class with the same name in the outer namespace
the inner class (or the global one) may be renamed or ignored:
</p>
<div class="code">
<pre>
%warnfilter(SWIGWARN_PARSE_NAMED_NESTED_CLASS) Outer::Inner;
class Outer {
public:
class Inner {
public:
...
};
Inner getInner();
void useInner(const Inner&amp; inner);
...
};
</pre>
</div>
<p>
Note that if <tt>Inner</tt> can be used as an opaque type, the default wrapping approach suffices.
For example, if the nested class does not need to be created from the target language, but can be obtained via a method
call, such as the <tt>getInner()</tt> method above, the returned value can then be passed around, such as passed into the
<tt>useInner()</tt> method.
</p>
<p>
With some more effort the above situation can be improved somewhat and a nested class can be constructed and used
from the target language much like any other non-nested class. Assuming we have the <tt>Outer</tt> class in a header file:
</p>
<div class="code">
<pre>
// File outer.h
class Outer {
public:
class Inner {
public:
int var;
Inner(int v = 0) : var(v) {}
};
Inner getInner();
void useInner(const Inner&amp; inner);
};
</pre>
</div>
<p>
The following interface file works around the nested class limitations by redefining the nested class as a global class.
A typedef for the compiler and the <tt>nestedworkaround</tt>
<a href="Customization.html#Customization_feature_flags">feature flag</a> is also required in
order for the generated wrappers to compile. This flag simply removes all the type information from SWIG, so SWIG treats
the nested class as if it had not been parsed at all.
</p>
<div class="code">
<pre>
// File : example.i
%module example
// Redefine nested class in global scope in order for SWIG to generate
// a proxy class. Only SWIG parses this definition.
class Inner {
%rename (Bar_Foo) Bar::Foo;
class Foo {};
class Bar {
public:
int var;
Inner(int v = 0) : var(v) {}
class Foo {};
};
%nestedworkaround Outer::Inner;
%{
#include "outer.h"
%}
%include "outer.h"
// We've fooled SWIG into thinking that Inner is a global class, so now we need
// to trick the C++ compiler into understanding this apparent global type.
%{
typedef Outer::Inner Inner;
%}
</pre>
</div>
<p>
The downside to this approach is a more complex interface file and having to maintain two definitions of <tt>Inner</tt>,
the real one and the one in the interface file that SWIG parses.
However, the upside is that all the methods/variables in the nested class are available from the target language
as a proxy class is generated instead of treating the nested class as an opaque type.
The proxy class can be constructed from the target language and passed into any methods accepting the nested class.
Also note that the original header file is parsed unmodified.
</p>
<p>
Finally, conditional compilation can be used as a workaround to comment out nested class definitions in the actual headers,
assuming you are able to modify them.
<b>Compatibility Note:</b>
Prior to SWIG-3.0.0, there was limited nested class support. Nested classes were treated as opaque pointers.
However, there was a workaround for nested class support in these older versions requiring the user to replicate
the nested class in the global scope, adding in a typedef for the nested class in the global scope and
using the "nestedworkaround" feature on the nested class. This resulted in approximately the
same behaviour as the "flatnested" feature. With proper nested class support now available in SWIG-3.0.0, this
feature has been deprecated and no longer works requiring code changes. If you see the following warning:
</p>
<div class="code">
<div class="shell">
<pre>
// File outer.h
class Outer {
public:
#ifndef SWIG
class Inner {
public:
...
};
#endif
...
};
example.i:8: Warning 126: The nestedworkaround feature is deprecated
</pre>
</div>
<p>
This workaround used to be common when SWIG could not deal with nested classes particulary well.
This should just be a last resort for unusual corner cases now as SWIG can parse nested classes and even handle nested template classes fairly well.
consider using the "flatnested" feature discussed above which generates a non-nested proxy class, like the
"nestedworkaround" feature did. Alternatively, use the default nested class code generation, which may generate an
equivalent to a nested proxy class in the target language, depending on the target language support.
</p>
<p>
<b>Compatibility Note:</b> SWIG-1.3.40 and earlier versions did not have the <tt>nestedworkaround</tt> feature
SWIG-1.3.40 and earlier versions did not have the <tt>nestedworkaround</tt> feature
and the generated code resulting from parsing nested classes did not always compile.
Nested class warnings could also not be suppressed using %warnfilter.
</p>

17
Doc/Manual/Scripting.html
View file

@ -293,7 +293,7 @@ A proxy class is a special kind of object that gets created
in a scripting language to access a C/C++ class (or struct) in a way
that looks like the original structure (that is, it proxies the real
C++ class). For example, if you
have the following C definition :</p>
have the following C++ definition :</p>
<div class="code"><pre>
class Vector {
@ -334,12 +334,12 @@ Finally, in Tcl :
<div class="targetlang"><pre>
Vector v
v configure -x 3 -y 4 -z 13
v configure -x 3 -y 4 -z -13
</pre></div>
<p>
When proxy classes are used, two objects are at really work--one in
When proxy classes are used, two objects are really at work--one in
the scripting language, and an underlying C/C++ object. Operations
affect both objects equally and for all practical purposes, it appears
as if you are simply manipulating a C/C++ object.
@ -353,7 +353,7 @@ The final step in using a scripting language with your C/C++
application is adding your extensions to the scripting language
itself. There are two primary approaches for doing
this. The preferred technique is to build a dynamically loadable
extension in the form a shared library. Alternatively, you can
extension in the form of a shared library. Alternatively, you can
recompile the scripting language interpreter with your extensions
added to it.
</p>
@ -364,21 +364,16 @@ added to it.
<p>
To create a shared library or DLL, you often need to look at the
manual pages for your compiler and linker. However, the procedure
for a few common machines is shown below:</p>
for a few common platforms is shown below:</p>
<div class="shell"><pre>
# Build a shared library for Solaris
gcc -c example.c example_wrap.c -I/usr/local/include
gcc -fpic -c example.c example_wrap.c -I/usr/local/include
ld -G example.o example_wrap.o -o example.so
# Build a shared library for Linux
gcc -fpic -c example.c example_wrap.c -I/usr/local/include
gcc -shared example.o example_wrap.o -o example.so
# Build a shared library for Irix
gcc -c example.c example_wrap.c -I/usr/local/include
ld -shared example.o example_wrap.o -o example.so
</pre></div>
<p>

4
Doc/Manual/Sections.html
View file

@ -6,7 +6,7 @@
<body bgcolor="#ffffff">
<H1><a name="Sections"></a>SWIG-3.0 Documentation</H1>
Last update : SWIG-3.0.0 (in progress)
Last update : SWIG-3.0.2 (4 Jun 2014)
<H2>Sections</H2>
@ -18,6 +18,7 @@ Last update : SWIG-3.0.0 (in progress)
<li><a href="Scripting.html#Scripting">Scripting</a></li>
<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="CPlusPlus11.html#CPlusPlus11">SWIG and C++11</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="Arguments.html#Arguments">Argument handling</a></li>
@ -41,6 +42,7 @@ Last update : SWIG-3.0.0 (in progress)
<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="Javascript.html#Javascript">Javascript 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>

104
Doc/Manual/Tcl.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Tcl"></a>37 SWIG and Tcl</H1>
<H1><a name="Tcl"></a>39 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>37.1 Preliminaries</H2>
<H2><a name="Tcl_nn2"></a>39.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>37.1.1 Getting the right header files</H3>
<H3><a name="Tcl_nn3"></a>39.1.1 Getting the right header files</H3>
<p>
@ -127,7 +127,7 @@ 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>37.1.2 Compiling a dynamic module</H3>
<H3><a name="Tcl_nn4"></a>39.1.2 Compiling a dynamic module</H3>
<p>
@ -139,8 +139,8 @@ using commands like this (shown for Linux):
<div class="code"><pre>
$ swig -tcl example.i
$ gcc -c example.c
$ gcc -c example_wrap.c -I/usr/local/include
$ gcc -fPIC -c example.c
$ gcc -fPIC -c example_wrap.c -I/usr/local/include
$ gcc -shared example.o example_wrap.o -o example.so
</pre></div>
@ -163,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>37.1.3 Static linking</H3>
<H3><a name="Tcl_nn5"></a>39.1.3 Static linking</H3>
<p>
@ -229,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>37.1.4 Using your module</H3>
<H3><a name="Tcl_nn6"></a>39.1.4 Using your module</H3>
<p>
@ -357,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>37.1.5 Compilation of C++ extensions</H3>
<H3><a name="Tcl_nn7"></a>39.1.5 Compilation of C++ extensions</H3>
<p>
@ -374,8 +374,8 @@ compiler. For example:
<div class="code"><pre>
% swig -c++ -tcl example.i
% g++ -c example.cxx
% g++ -c example_wrap.cxx -I/usr/local/include
% g++ -fPIC -c example.cxx
% g++ -fPIC -c example_wrap.cxx -I/usr/local/include
% g++ -shared example.o example_wrap.o -o example.so
</pre></div>
@ -387,8 +387,8 @@ Solaris, you often need to add an extra library <tt>-lCrun</tt> like this:
<div class="code"><pre>
% swig -c++ -tcl example.i
% CC -c example.cxx
% CC -c example_wrap.cxx -I/usr/local/include
% CC -KPIC -c example.cxx
% CC -KPIC -c example_wrap.cxx -I/usr/local/include
% CC -G example.o example_wrap.o -L/opt/SUNWspro/lib -o example.so -lCrun
</pre></div>
@ -440,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>37.1.6 Compiling for 64-bit platforms</H3>
<H3><a name="Tcl_nn8"></a>39.1.6 Compiling for 64-bit platforms</H3>
<p>
@ -467,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>37.1.7 Setting a package prefix</H3>
<H3><a name="Tcl_nn9"></a>39.1.7 Setting a package prefix</H3>
<p>
@ -486,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>37.1.8 Using namespaces</H3>
<H3><a name="Tcl_nn10"></a>39.1.8 Using namespaces</H3>
<p>
@ -508,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>37.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
<H2><a name="Tcl_nn11"></a>39.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
<p>
@ -519,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>37.2.1 Running SWIG from Developer Studio</H3>
<H3><a name="Tcl_nn12"></a>39.2.1 Running SWIG from Developer Studio</H3>
<p>
@ -577,7 +577,7 @@ MSDOS &gt; tclsh80
%
</pre></div>
<H3><a name="Tcl_nn13"></a>37.2.2 Using NMAKE</H3>
<H3><a name="Tcl_nn13"></a>39.2.2 Using NMAKE</H3>
<p>
@ -640,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>37.3 A tour of basic C/C++ wrapping</H2>
<H2><a name="Tcl_nn14"></a>39.3 A tour of basic C/C++ wrapping</H2>
<p>
@ -651,7 +651,7 @@ classes. This section briefly covers the essential aspects of this
wrapping.
</p>
<H3><a name="Tcl_nn15"></a>37.3.1 Modules</H3>
<H3><a name="Tcl_nn15"></a>39.3.1 Modules</H3>
<p>
@ -685,7 +685,7 @@ To fix this, supply an extra argument to <tt>load</tt> like this:
</pre>
</div>
<H3><a name="Tcl_nn16"></a>37.3.2 Functions</H3>
<H3><a name="Tcl_nn16"></a>39.3.2 Functions</H3>
<p>
@ -710,7 +710,7 @@ like you think it does:
%
</pre></div>
<H3><a name="Tcl_nn17"></a>37.3.3 Global variables</H3>
<H3><a name="Tcl_nn17"></a>39.3.3 Global variables</H3>
<p>
@ -790,7 +790,7 @@ extern char *path; // Read-only (due to %immutable)
</pre>
</div>
<H3><a name="Tcl_nn18"></a>37.3.4 Constants and enums</H3>
<H3><a name="Tcl_nn18"></a>39.3.4 Constants and enums</H3>
<p>
@ -874,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>37.3.5 Pointers</H3>
<H3><a name="Tcl_nn19"></a>39.3.5 Pointers</H3>
<p>
@ -970,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>37.3.6 Structures</H3>
<H3><a name="Tcl_nn20"></a>39.3.6 Structures</H3>
<p>
@ -1252,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>37.3.7 C++ classes</H3>
<H3><a name="Tcl_nn21"></a>39.3.7 C++ classes</H3>
<p>
@ -1319,7 +1319,7 @@ In Tcl, the static member is accessed as follows:
</pre>
</div>
<H3><a name="Tcl_nn22"></a>37.3.8 C++ inheritance</H3>
<H3><a name="Tcl_nn22"></a>39.3.8 C++ inheritance</H3>
<p>
@ -1368,7 +1368,7 @@ For instance:
It is safe to use multiple inheritance with SWIG.
</p>
<H3><a name="Tcl_nn23"></a>37.3.9 Pointers, references, values, and arrays</H3>
<H3><a name="Tcl_nn23"></a>39.3.9 Pointers, references, values, and arrays</H3>
<p>
@ -1422,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>37.3.10 C++ overloaded functions</H3>
<H3><a name="Tcl_nn24"></a>39.3.10 C++ overloaded functions</H3>
<p>
@ -1545,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>37.3.11 C++ operators</H3>
<H3><a name="Tcl_nn25"></a>39.3.11 C++ operators</H3>
<p>
@ -1647,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>37.3.12 C++ namespaces</H3>
<H3><a name="Tcl_nn26"></a>39.3.12 C++ namespaces</H3>
<p>
@ -1711,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>37.3.13 C++ templates</H3>
<H3><a name="Tcl_nn27"></a>39.3.13 C++ templates</H3>
<p>
@ -1763,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>37.3.14 C++ Smart Pointers</H3>
<H3><a name="Tcl_nn28"></a>39.3.14 C++ Smart Pointers</H3>
<p>
@ -1847,7 +1847,7 @@ simply use the <tt>__deref__()</tt> method. For example:
</pre>
</div>
<H2><a name="Tcl_nn29"></a>37.4 Further details on the Tcl class interface</H2>
<H2><a name="Tcl_nn29"></a>39.4 Further details on the Tcl class interface</H2>
<p>
@ -1860,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>37.4.1 Proxy classes</H3>
<H3><a name="Tcl_nn30"></a>39.4.1 Proxy classes</H3>
<p>
@ -1925,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>37.4.2 Memory management</H3>
<H3><a name="Tcl_nn31"></a>39.4.2 Memory management</H3>
<p>
@ -2113,7 +2113,7 @@ typemaps--an advanced topic discussed later.
</p>
<H2><a name="Tcl_nn32"></a>37.5 Input and output parameters</H2>
<H2><a name="Tcl_nn32"></a>39.5 Input and output parameters</H2>
<p>
@ -2301,7 +2301,7 @@ set c [lindex $dim 1]
</pre>
</div>
<H2><a name="Tcl_nn33"></a>37.6 Exception handling </H2>
<H2><a name="Tcl_nn33"></a>39.6 Exception handling </H2>
<p>
@ -2435,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>37.7 Typemaps</H2>
<H2><a name="Tcl_nn34"></a>39.7 Typemaps</H2>
<p>
@ -2452,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>37.7.1 What is a typemap?</H3>
<H3><a name="Tcl_nn35"></a>39.7.1 What is a typemap?</H3>
<p>
@ -2569,7 +2569,7 @@ parameter is omitted):
</pre>
</div>
<H3><a name="Tcl_nn36"></a>37.7.2 Tcl typemaps</H3>
<H3><a name="Tcl_nn36"></a>39.7.2 Tcl typemaps</H3>
<p>
@ -2707,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>37.7.3 Typemap variables</H3>
<H3><a name="Tcl_nn37"></a>39.7.3 Typemap variables</H3>
<p>
@ -2778,7 +2778,7 @@ properly assigned.
The Tcl name of the wrapper function being created.
</div>
<H3><a name="Tcl_nn38"></a>37.7.4 Converting a Tcl list to a char ** </H3>
<H3><a name="Tcl_nn38"></a>39.7.4 Converting a Tcl list to a char ** </H3>
<p>
@ -2840,7 +2840,7 @@ argv[2] = Larry
3
</pre></div>
<H3><a name="Tcl_nn39"></a>37.7.5 Returning values in arguments</H3>
<H3><a name="Tcl_nn39"></a>39.7.5 Returning values in arguments</H3>
<p>
@ -2882,7 +2882,7 @@ result, a Tcl function using these typemaps will work like this :
%
</pre></div>
<H3><a name="Tcl_nn40"></a>37.7.6 Useful functions</H3>
<H3><a name="Tcl_nn40"></a>39.7.6 Useful functions</H3>
<p>
@ -2959,7 +2959,7 @@ int Tcl_IsShared(Tcl_Obj *obj);
</pre>
</div>
<H3><a name="Tcl_nn41"></a>37.7.7 Standard typemaps</H3>
<H3><a name="Tcl_nn41"></a>39.7.7 Standard typemaps</H3>
<p>
@ -3043,7 +3043,7 @@ work)
</pre>
</div>
<H3><a name="Tcl_nn42"></a>37.7.8 Pointer handling</H3>
<H3><a name="Tcl_nn42"></a>39.7.8 Pointer handling</H3>
<p>
@ -3119,7 +3119,7 @@ For example:
</pre>
</div>
<H2><a name="Tcl_nn43"></a>37.8 Turning a SWIG module into a Tcl Package.</H2>
<H2><a name="Tcl_nn43"></a>39.8 Turning a SWIG module into a Tcl Package.</H2>
<p>
@ -3191,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>37.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
<H2><a name="Tcl_nn44"></a>39.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
<p>
@ -3290,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>37.9.1 Proxy classes</H3>
<H3><a name="Tcl_nn45"></a>39.9.1 Proxy classes</H3>
<p>
@ -3411,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>37.10 Tcl/Tk Stubs</H2>
<H2><a name="Tcl_nn46"></a>39.10 Tcl/Tk Stubs</H2>
<p>

126
Doc/Manual/Typemaps.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Typemaps"></a>10 Typemaps</H1>
<H1><a name="Typemaps"></a>11 Typemaps</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -95,7 +95,7 @@
<H2><a name="Typemaps_nn2"></a>10.1 Introduction</H2>
<H2><a name="Typemaps_nn2"></a>11.1 Introduction</H2>
<p>
@ -112,7 +112,7 @@ to re-read the earlier chapters if you have found your way to this
chapter with only a vague idea of what SWIG already does by default.
</p>
<H3><a name="Typemaps_nn3"></a>10.1.1 Type conversion</H3>
<H3><a name="Typemaps_nn3"></a>11.1.1 Type conversion</H3>
<p>
@ -205,7 +205,7 @@ to read the extension documentation for your favorite language to know
how it works (an exercise left to the reader).
</p>
<H3><a name="Typemaps_nn4"></a>10.1.2 Typemaps</H3>
<H3><a name="Typemaps_nn4"></a>11.1.2 Typemaps</H3>
<p>
@ -306,7 +306,7 @@ parts of the generated wrapper functions. Because arbitrary code can be insert
possible to completely change the way in which values are converted.
</p>
<H3><a name="Typemaps_nn5"></a>10.1.3 Pattern matching</H3>
<H3><a name="Typemaps_nn5"></a>11.1.3 Pattern matching</H3>
<p>
@ -408,7 +408,7 @@ In this case, a single input object is expanded into a pair of C arguments. Thi
provides a hint to the unusual variable naming scheme involving <tt>$1</tt>, <tt>$2</tt>, and so forth.
</p>
<H3><a name="Typemaps_nn6"></a>10.1.4 Reusing typemaps</H3>
<H3><a name="Typemaps_nn6"></a>11.1.4 Reusing typemaps</H3>
<p>
@ -464,7 +464,7 @@ typedef int size_t;
then SWIG already knows that the <tt>int</tt> typemaps apply. You don't have to do anything.
</p>
<H3><a name="Typemaps_nn7"></a>10.1.5 What can be done with typemaps?</H3>
<H3><a name="Typemaps_nn7"></a>11.1.5 What can be done with typemaps?</H3>
<p>
@ -576,7 +576,7 @@ typemaps that expand upon this list. For example, the Java module defines a var
aspects of the Java bindings. Consult language specific documentation for further details.
</p>
<H3><a name="Typemaps_nn8"></a>10.1.6 What can't be done with typemaps?</H3>
<H3><a name="Typemaps_nn8"></a>11.1.6 What can't be done with typemaps?</H3>
<p>
@ -639,7 +639,7 @@ void wrap_foo(char *s, int x) {
</pre>
</div>
<H3><a name="Typemaps_aspects"></a>10.1.7 Similarities to Aspect Oriented Programming</H3>
<H3><a name="Typemaps_aspects"></a>11.1.7 Similarities to Aspect Oriented Programming</H3>
<p>
@ -657,7 +657,7 @@ SWIG can also be viewed as has having a second set of aspects based around <a hr
Features such as <tt>%exception</tt> are also cross-cutting concerns as they encapsulate code that can be used to add logging or exception handling to any function.
</p>
<H3><a name="Typemaps_nn9"></a>10.1.8 The rest of this chapter</H3>
<H3><a name="Typemaps_nn9"></a>11.1.8 The rest of this chapter</H3>
<p>
@ -677,14 +677,14 @@ of "The C Programming Language" by Kernighan and Ritchie or
"The C++ Programming Language" by Stroustrup before going any further.
</p>
<H2><a name="Typemaps_nn10"></a>10.2 Typemap specifications</H2>
<H2><a name="Typemaps_nn10"></a>11.2 Typemap specifications</H2>
<p>
This section describes the behavior of the <tt>%typemap</tt> directive itself.
</p>
<H3><a name="Typemaps_defining"></a>10.2.1 Defining a typemap</H3>
<H3><a name="Typemaps_defining"></a>11.2.1 Defining a typemap</H3>
<p>
@ -797,7 +797,7 @@ Admittedly, it's not the most readable syntax at first glance. However, the pur
individual pieces will become clear.
</p>
<H3><a name="Typemaps_nn12"></a>10.2.2 Typemap scope</H3>
<H3><a name="Typemaps_nn12"></a>11.2.2 Typemap scope</H3>
<p>
@ -847,7 +847,7 @@ class Foo {
</pre>
</div>
<H3><a name="Typemaps_nn13"></a>10.2.3 Copying a typemap</H3>
<H3><a name="Typemaps_nn13"></a>11.2.3 Copying a typemap</H3>
<p>
@ -905,7 +905,7 @@ The patterns for <tt>%apply</tt> follow the same rules as for <tt>%typemap</tt>.
</pre>
</div>
<H3><a name="Typemaps_nn14"></a>10.2.4 Deleting a typemap</H3>
<H3><a name="Typemaps_nn14"></a>11.2.4 Deleting a typemap</H3>
<p>
@ -938,7 +938,7 @@ For example:
after the clear operation.
</p>
<H3><a name="Typemaps_nn15"></a>10.2.5 Placement of typemaps</H3>
<H3><a name="Typemaps_nn15"></a>11.2.5 Placement of typemaps</H3>
<p>
@ -1018,7 +1018,7 @@ It should be noted that for scoping to work, SWIG has to know that <tt>string</t
within a particular namespace. In this example, this is done using the forward class declaration <tt>class string</tt>.
</p>
<H2><a name="Typemaps_pattern_matching"></a>10.3 Pattern matching rules</H2>
<H2><a name="Typemaps_pattern_matching"></a>11.3 Pattern matching rules</H2>
<p>
@ -1026,7 +1026,7 @@ The section describes the pattern matching rules by which C/C++ datatypes are as
The matching rules can be observed in practice by using the debugging options also described.
</p>
<H3><a name="Typemaps_nn17"></a>10.3.1 Basic matching rules</H3>
<H3><a name="Typemaps_nn17"></a>11.3.1 Basic matching rules</H3>
<p>
@ -1125,7 +1125,7 @@ void F(int x[1000]); // int [ANY] rule (typemap 5)
stripped all qualifiers in one step.
</p>
<H3><a name="Typemaps_typedef_reductions"></a>10.3.2 Typedef reductions matching</H3>
<H3><a name="Typemaps_typedef_reductions"></a>11.3.2 Typedef reductions matching</H3>
<p>
@ -1300,7 +1300,7 @@ void go(Struct aStruct);
</pre>
</div>
<H3><a name="Typemaps_nn19"></a>10.3.3 Default typemap matching rules</H3>
<H3><a name="Typemaps_nn19"></a>11.3.3 Default typemap matching rules</H3>
<p>
@ -1438,7 +1438,7 @@ Finally the best way to view the typemap matching rules in action is via the <a
simpler scheme to match the current C++ class template partial specialization matching rules.
</p>
<H3><a name="Typemaps_multi_argument_typemaps_patterns"></a>10.3.4 Multi-arguments typemaps</H3>
<H3><a name="Typemaps_multi_argument_typemaps_patterns"></a>11.3.4 Multi-arguments typemaps</H3>
<p>
@ -1468,7 +1468,7 @@ but all subsequent arguments must match exactly.
</p>
<H3><a name="Typemaps_matching_template_comparison"></a>10.3.5 Matching rules compared to C++ templates</H3>
<H3><a name="Typemaps_matching_template_comparison"></a>11.3.5 Matching rules compared to C++ templates</H3>
<p>
@ -1627,7 +1627,7 @@ are similar to those for specialized template handling.
</p>
<H3><a name="Typemaps_debugging_search"></a>10.3.6 Debugging typemap pattern matching</H3>
<H3><a name="Typemaps_debugging_search"></a>11.3.6 Debugging typemap pattern matching</H3>
<p>
@ -1840,7 +1840,7 @@ Also the types may be displayed slightly differently - <tt>char const *</tt> and
</li>
</ul>
<H2><a name="Typemaps_nn21"></a>10.4 Code generation rules</H2>
<H2><a name="Typemaps_nn21"></a>11.4 Code generation rules</H2>
<p>
@ -1848,7 +1848,7 @@ This section describes rules by which typemap code is inserted into
the generated wrapper code.
</p>
<H3><a name="Typemaps_nn22"></a>10.4.1 Scope</H3>
<H3><a name="Typemaps_nn22"></a>11.4.1 Scope</H3>
<p>
@ -1926,7 +1926,7 @@ a block scope when it is emitted. This sometimes results in a less complicated
Note that only the third of the three typemaps have the typemap code passed through the SWIG preprocessor.
</p>
<H3><a name="Typemaps_nn23"></a>10.4.2 Declaring new local variables</H3>
<H3><a name="Typemaps_nn23"></a>11.4.2 Declaring new local variables</H3>
<p>
@ -2077,7 +2077,7 @@ each type must have its own local variable declaration.
</div>
<H3><a name="Typemaps_special_variables"></a>10.4.3 Special variables</H3>
<H3><a name="Typemaps_special_variables"></a>11.4.3 Special variables</H3>
<p>
@ -2329,7 +2329,7 @@ Another approach, which only works for arrays is to use the <tt>$1_basetype</tt>
</pre>
</div>
<H3><a name="Typemaps_special_variable_macros"></a>10.4.4 Special variable macros</H3>
<H3><a name="Typemaps_special_variable_macros"></a>11.4.4 Special variable macros</H3>
<p>
@ -2341,7 +2341,7 @@ it is done during the SWIG parsing/compilation stages.
The following special variable macros are available across all language modules.
</p>
<H4><a name="Typemaps_special_macro_descriptor"></a>10.4.4.1 $descriptor(type)</H4>
<H4><a name="Typemaps_special_macro_descriptor"></a>11.4.4.1 $descriptor(type)</H4>
<p>
@ -2352,7 +2352,7 @@ For example, <tt>$descriptor(std::vector&lt;int&gt; *)</tt> will expand into <tt
This macro is mostly used in the scripting target languages and is demonstrated later in the <a href="#Typemaps_runtime_type_checker_usage">Run-time type checker usage</a> section.
</p>
<H4><a name="Typemaps_special_macro_typemap"></a>10.4.4.2 $typemap(method, typepattern)</H4>
<H4><a name="Typemaps_special_macro_typemap"></a>11.4.4.2 $typemap(method, typepattern)</H4>
<p>
@ -2409,7 +2409,7 @@ The result is the following expansion
</pre>
</div>
<H2><a name="Typemaps_nn25"></a>10.5 Common typemap methods</H2>
<H2><a name="Typemaps_nn25"></a>11.5 Common typemap methods</H2>
<p>
@ -2417,7 +2417,7 @@ The set of typemaps recognized by a language module may vary. However,
the following typemap methods are nearly universal:
</p>
<H3><a name="Typemaps_nn26"></a>10.5.1 "in" typemap</H3>
<H3><a name="Typemaps_nn26"></a>11.5.1 "in" typemap</H3>
<p>
@ -2477,7 +2477,7 @@ Usually <tt>numinputs</tt> is not specified, whereupon the default value is 1, t
is the same as the old "ignore" typemap.
</p>
<H3><a name="Typemaps_nn27"></a>10.5.2 "typecheck" typemap</H3>
<H3><a name="Typemaps_nn27"></a>11.5.2 "typecheck" typemap</H3>
<p>
@ -2503,7 +2503,7 @@ If you define new "in" typemaps <em>and</em> your program uses overloaded method
"typecheck" typemaps. More details about this follow in the <a href="#Typemaps_overloading">Typemaps and overloading</a> section.
</p>
<H3><a name="Typemaps_nn28"></a>10.5.3 "out" typemap</H3>
<H3><a name="Typemaps_nn28"></a>11.5.3 "out" typemap</H3>
<p>
@ -2534,7 +2534,7 @@ $symname - Name of function/method being wrapped
The "out" typemap supports an optional attribute flag called "optimal". This is for code optimisation and is detailed in the <a href="#Typemaps_optimal">Optimal code generation when returning by value</a> section.
</p>
<H3><a name="Typemaps_nn29"></a>10.5.4 "arginit" typemap</H3>
<H3><a name="Typemaps_nn29"></a>11.5.4 "arginit" typemap</H3>
<p>
@ -2553,7 +2553,7 @@ For example:
</pre>
</div>
<H3><a name="Typemaps_nn30"></a>10.5.5 "default" typemap</H3>
<H3><a name="Typemaps_nn30"></a>11.5.5 "default" typemap</H3>
<p>
@ -2586,7 +2586,7 @@ See the <a href="SWIG.html#SWIG_default_args">Default/optional arguments</a> sec
for further information on default argument wrapping.
</p>
<H3><a name="Typemaps_nn31"></a>10.5.6 "check" typemap</H3>
<H3><a name="Typemaps_nn31"></a>11.5.6 "check" typemap</H3>
<p>
@ -2605,7 +2605,7 @@ converted. For example:
</pre>
</div>
<H3><a name="Typemaps_nn32"></a>10.5.7 "argout" typemap</H3>
<H3><a name="Typemaps_nn32"></a>11.5.7 "argout" typemap</H3>
<p>
@ -2651,7 +2651,7 @@ return values are often appended to return value of the function.
See the <tt>typemaps.i</tt> library file for examples.
</p>
<H3><a name="Typemaps_nn33"></a>10.5.8 "freearg" typemap</H3>
<H3><a name="Typemaps_nn33"></a>11.5.8 "freearg" typemap</H3>
<p>
@ -2684,7 +2684,7 @@ be used in other typemaps whenever a wrapper function needs to abort
prematurely.
</p>
<H3><a name="Typemaps_nn34"></a>10.5.9 "newfree" typemap</H3>
<H3><a name="Typemaps_nn34"></a>11.5.9 "newfree" typemap</H3>
<p>
@ -2713,7 +2713,7 @@ string *foo();
See <a href="Customization.html#Customization_ownership">Object ownership and %newobject</a> for further details.
</p>
<H3><a name="Typemaps_nn35"></a>10.5.10 "memberin" typemap</H3>
<H3><a name="Typemaps_nn35"></a>11.5.10 "memberin" typemap</H3>
<p>
@ -2735,7 +2735,7 @@ It is rarely necessary to write "memberin" typemaps---SWIG already provides
a default implementation for arrays, strings, and other objects.
</p>
<H3><a name="Typemaps_nn36"></a>10.5.11 "varin" typemap</H3>
<H3><a name="Typemaps_nn36"></a>11.5.11 "varin" typemap</H3>
<p>
@ -2743,7 +2743,7 @@ The "varin" typemap is used to convert objects in the target language to C for t
purposes of assigning to a C/C++ global variable. This is implementation specific.
</p>
<H3><a name="Typemaps_nn37"></a>10.5.12 "varout" typemap</H3>
<H3><a name="Typemaps_nn37"></a>11.5.12 "varout" typemap</H3>
<p>
@ -2751,7 +2751,7 @@ The "varout" typemap is used to convert a C/C++ object to an object in the targe
language when reading a C/C++ global variable. This is implementation specific.
</p>
<H3><a name="throws_typemap"></a>10.5.13 "throws" typemap</H3>
<H3><a name="throws_typemap"></a>11.5.13 "throws" typemap</H3>
<p>
@ -2797,7 +2797,7 @@ Note that if your methods do not have an exception specification yet they do thr
For a neat way to handle these, see the <a href="Customization.html#Customization_exception">Exception handling with %exception</a> section.
</p>
<H2><a name="Typemaps_nn39"></a>10.6 Some typemap examples</H2>
<H2><a name="Typemaps_nn39"></a>11.6 Some typemap examples</H2>
<p>
@ -2805,7 +2805,7 @@ This section contains a few examples. Consult language module documentation
for more examples.
</p>
<H3><a name="Typemaps_nn40"></a>10.6.1 Typemaps for arrays</H3>
<H3><a name="Typemaps_nn40"></a>11.6.1 Typemaps for arrays</H3>
<p>
@ -3064,7 +3064,7 @@ Now, you will find that member access is quite nice:
useless and has since been eliminated. To return structure members, simply use the "out" typemap.
</p>
<H3><a name="Typemaps_nn41"></a>10.6.2 Implementing constraints with typemaps</H3>
<H3><a name="Typemaps_nn41"></a>11.6.2 Implementing constraints with typemaps</H3>
<p>
@ -3112,7 +3112,7 @@ a NULL pointer. As a result, SWIG can often prevent a potential
segmentation faults or other run-time problems by raising an exception
rather than blindly passing values to the underlying C/C++ program.</p>
<H2><a name="Typemaps_nn43"></a>10.7 Typemaps for multiple target languages</H2>
<H2><a name="Typemaps_nn43"></a>11.7 Typemaps for multiple target languages</H2>
<p>
@ -3142,7 +3142,7 @@ The example above also shows a common approach of issuing a warning for an as ye
<tt>%typemap(ruby,in) int "$1 = NUM2INT($input);"</tt>.
</p>
<H2><a name="Typemaps_optimal"></a>10.8 Optimal code generation when returning by value</H2>
<H2><a name="Typemaps_optimal"></a>11.8 Optimal code generation when returning by value</H2>
<p>
@ -3331,7 +3331,7 @@ example.i:7: Warning 475: optimal attribute usage in the out typemap.
However, it doesn't always get it right, for example when <tt>$1</tt> is within some commented out code.
</p>
<H2><a name="Typemaps_multi_argument_typemaps"></a>10.9 Multi-argument typemaps</H2>
<H2><a name="Typemaps_multi_argument_typemaps"></a>11.9 Multi-argument typemaps</H2>
<p>
@ -3598,7 +3598,7 @@ 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_warnings"></a>10.10 Typemap warnings</H2>
<H2><a name="Typemaps_warnings"></a>11.10 Typemap warnings</H2>
<p>
@ -3607,7 +3607,7 @@ See the information in the <a href="Warnings.html#Warnings_nn5">issuing warnings
</p>
<H2><a name="Typemaps_fragments"></a>10.11 Typemap fragments</H2>
<H2><a name="Typemaps_fragments"></a>11.11 Typemap fragments</H2>
<p>
@ -3860,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.11.1 Fragment type specialization</H3>
<H3><a name="Typemaps_fragment_type_specialization"></a>11.11.1 Fragment type specialization</H3>
<p>
@ -3893,7 +3893,7 @@ struct A {
</pre>
</div>
<H3><a name="Typemaps_automatic_specialization"></a>10.11.2 Fragments and automatic typemap specialization</H3>
<H3><a name="Typemaps_automatic_specialization"></a>11.11.2 Fragments and automatic typemap specialization</H3>
<p>
@ -3939,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.12 The run-time type checker</H2>
<H2><a name="Typemaps_runtime_type_checker"></a>11.12 The run-time type checker</H2>
<p>
@ -3956,7 +3956,7 @@ Requirements for the type system:
<li>Store inheritance and type equivalence information and be able to correctly
re-create the type pointer.</li>
<li>Share type information between modules.</li>
<li>Modules can be loaded in any order, irregardless of actual type
<li>Modules can be loaded in any order, regardless of actual type
dependency.</li>
<li>Avoid the use of dynamically allocated memory, and library/system calls in general.</li>
<li>Provide a reasonably fast implementation, minimizing the lookup time for all
@ -3965,7 +3965,7 @@ language modules.</li>
<li>Modules can be unloaded from the type system.</li>
</ul>
<H3><a name="Typemaps_nn45"></a>10.12.1 Implementation</H3>
<H3><a name="Typemaps_nn45"></a>11.12.1 Implementation</H3>
<p>
@ -4151,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.12.2 Usage</H3>
<H3><a name="Typemaps_runtime_type_checker_usage"></a>11.12.2 Usage</H3>
<p>This section covers how to use these functions from typemaps. To learn how to
@ -4245,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.13 Typemaps and overloading</H2>
<H2><a name="Typemaps_overloading"></a>11.13 Typemaps and overloading</H2>
<p>
@ -4556,7 +4556,7 @@ Subsequent "in" typemaps would then perform more extensive type-checking.
</li>
</ul>
<H2><a name="Typemaps_nn48"></a>10.14 More about <tt>%apply</tt> and <tt>%clear</tt></H2>
<H2><a name="Typemaps_nn48"></a>11.14 More about <tt>%apply</tt> and <tt>%clear</tt></H2>
<p>
@ -4642,7 +4642,7 @@ example:
</div>
<H2><a name="Typemaps_nn47"></a>10.15 Passing data between typemaps</H2>
<H2><a name="Typemaps_nn47"></a>11.15 Passing data between typemaps</H2>
<p>
@ -4679,7 +4679,7 @@ sure that the typemaps sharing information have exactly the same types and names
</p>
<H2><a name="Typemaps_nn52"></a>10.16 C++ "this" pointer</H2>
<H2><a name="Typemaps_nn52"></a>11.16 C++ "this" pointer</H2>
<p>
@ -4739,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.17 Where to go for more information?</H2>
<H2><a name="Typemaps_nn51"></a>11.17 Where to go for more information?</H2>
<p>

20
Doc/Manual/Varargs.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Varargs"></a>13 Variable Length Arguments</H1>
<H1><a name="Varargs"></a>14 Variable Length Arguments</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -42,7 +42,7 @@ added in SWIG-1.3.12. Most other wrapper generation tools have
wisely chosen to avoid this issue.
</p>
<H2><a name="Varargs_nn2"></a>13.1 Introduction</H2>
<H2><a name="Varargs_nn2"></a>14.1 Introduction</H2>
<p>
@ -139,7 +139,7 @@ List make_list(const char *s, ...) {
</pre>
</div>
<H2><a name="Varargs_nn3"></a>13.2 The Problem</H2>
<H2><a name="Varargs_nn3"></a>14.2 The Problem</H2>
<p>
@ -232,7 +232,7 @@ can also support real varargs wrapping (with stack-frame manipulation) if you
are willing to get hands dirty. Keep reading.
</p>
<H2><a name="Varargs_nn4"></a>13.3 Default varargs support</H2>
<H2><a name="Varargs_nn4"></a>14.3 Default varargs support</H2>
<p>
@ -301,7 +301,7 @@ Read on for further solutions.
</p>
<H2><a name="Varargs_nn5"></a>13.4 Argument replacement using %varargs</H2>
<H2><a name="Varargs_nn5"></a>14.4 Argument replacement using %varargs</H2>
<p>
@ -412,7 +412,7 @@ mixed argument types such as <tt>printf()</tt>. Providing general purpose
wrappers to such functions presents special problems (covered shortly).
</p>
<H2><a name="Varargs_nn6"></a>13.5 Varargs and typemaps</H2>
<H2><a name="Varargs_nn6"></a>14.5 Varargs and typemaps</H2>
<p>
@ -589,7 +589,7 @@ really want to elevate your guru status and increase your job
security, continue to the next section.
</p>
<H2><a name="Varargs_nn7"></a>13.6 Varargs wrapping with libffi</H2>
<H2><a name="Varargs_nn7"></a>14.6 Varargs wrapping with libffi</H2>
<p>
@ -841,7 +841,7 @@ provide an argument number for the first extra argument. This can be used to in
values. Please consult the chapter on each language module for more details.
</p>
<H2><a name="Varargs_nn8"></a>13.7 Wrapping of va_list</H2>
<H2><a name="Varargs_nn8"></a>14.7 Wrapping of va_list</H2>
<p>
@ -895,7 +895,7 @@ int my_vprintf(const char *fmt, ...) {
</pre>
</div>
<H2><a name="Varargs_nn9"></a>13.8 C++ Issues</H2>
<H2><a name="Varargs_nn9"></a>14.8 C++ Issues</H2>
<p>
@ -964,7 +964,7 @@ design or to provide an alternative interface using a helper function than it is
fully general wrapper to a varargs C++ member function.
</p>
<H2><a name="Varargs_nn10"></a>13.9 Discussion</H2>
<H2><a name="Varargs_nn10"></a>14.9 Discussion</H2>
<p>

39
Doc/Manual/Warnings.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Warnings"></a>14 Warning Messages</H1>
<H1><a name="Warnings"></a>15 Warning Messages</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -35,7 +35,7 @@
<H2><a name="Warnings_nn2"></a>14.1 Introduction</H2>
<H2><a name="Warnings_nn2"></a>15.1 Introduction</H2>
<p>
@ -55,7 +55,7 @@ where the generated wrapper code will probably compile, but it may not
work like you expect.
</p>
<H2><a name="Warnings_suppression"></a>14.2 Warning message suppression</H2>
<H2><a name="Warnings_suppression"></a>15.2 Warning message suppression</H2>
<p>
@ -147,7 +147,7 @@ your interface. Ignore the warning messages at your own peril.
</p>
<H2><a name="Warnings_nn4"></a>14.3 Enabling extra warnings</H2>
<H2><a name="Warnings_nn4"></a>15.3 Enabling extra warnings</H2>
<p>
@ -220,7 +220,7 @@ that is, any warnings suppressed or added in <tt>%warnfilter</tt>, <tt>#pragma S
or the <tt>-w</tt> option.
</p>
<H2><a name="Warnings_nn5"></a>14.4 Issuing a warning message</H2>
<H2><a name="Warnings_nn5"></a>15.4 Issuing a warning message</H2>
<p>
@ -274,7 +274,7 @@ example.i:24: Warning 901: You are really going to regret this usage of blah * s
</pre>
</div>
<H2><a name="Warnings_symbolic_symbols"></a>14.5 Symbolic symbols</H2>
<H2><a name="Warnings_symbolic_symbols"></a>15.5 Symbolic symbols</H2>
<p>
@ -309,7 +309,7 @@ or
</pre>
</div>
<H2><a name="Warnings_nn6"></a>14.6 Commentary</H2>
<H2><a name="Warnings_nn6"></a>15.6 Commentary</H2>
<p>
@ -326,7 +326,7 @@ no obvious recovery. There is no mechanism for suppressing error
messages.
</p>
<H2><a name="Warnings_nn7"></a>14.7 Warnings as errors</H2>
<H2><a name="Warnings_nn7"></a>15.7 Warnings as errors</H2>
<p>
@ -335,7 +335,7 @@ option. This will cause SWIG to exit with a non successful exit code if a
warning is encountered.
</p>
<H2><a name="Warnings_nn8"></a>14.8 Message output format</H2>
<H2><a name="Warnings_nn8"></a>15.8 Message output format</H2>
<p>
@ -354,10 +354,10 @@ $ swig -python -Fmicrosoft example.i
example.i(4) : Syntax error in input.
</pre></div>
<H2><a name="Warnings_nn9"></a>14.9 Warning number reference</H2>
<H2><a name="Warnings_nn9"></a>15.9 Warning number reference</H2>
<H3><a name="Warnings_nn10"></a>14.9.1 Deprecated features (100-199)</H3>
<H3><a name="Warnings_nn10"></a>15.9.1 Deprecated features (100-199)</H3>
<ul>
@ -382,9 +382,10 @@ example.i(4) : Syntax error in input.
<li>119. Deprecated <tt>%typemap(ignore)</tt>.
<li>120. Deprecated command line option (-runtime, -noruntime).
<li>121. Deprecated <tt>%name</tt> directive.
<li>126. The 'nestedworkaround' feature is deprecated.
</ul>
<H3><a name="Warnings_nn11"></a>14.9.2 Preprocessor (200-299)</H3>
<H3><a name="Warnings_nn11"></a>15.9.2 Preprocessor (200-299)</H3>
<ul>
@ -396,7 +397,7 @@ example.i(4) : Syntax error in input.
<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>
<H3><a name="Warnings_nn12"></a>15.9.3 C/C++ Parser (300-399)</H3>
<ul>
@ -473,7 +474,7 @@ example.i(4) : Syntax error in input.
<li>395. operator delete[] ignored.
</ul>
<H3><a name="Warnings_nn13"></a>14.9.4 Types and typemaps (400-499) </H3>
<H3><a name="Warnings_nn13"></a>15.9.4 Types and typemaps (400-499) </H3>
<ul>
@ -498,11 +499,13 @@ example.i(4) : Syntax error in input.
<li>471. Unable to use return type <em>type</em> in director method
<li>474. Method <em>method</em> usage of the optimal attribute ignored in the out typemap as the following cannot be used to generate optimal code: <em>code</em>
<li>475. Multiple calls to <em>method</em> might be generated due to optimal attribute usage in the out typemap.
<li>476. Initialization using std::initializer_list.
<li>477. No directorthrows typemap defined for <em>type</em>
</ul>
<H3><a name="Warnings_nn14"></a>14.9.5 Code generation (500-599)</H3>
<H3><a name="Warnings_nn14"></a>15.9.5 Code generation (500-599)</H3>
<ul>
@ -531,7 +534,7 @@ example.i(4) : Syntax error in input.
<li>523. Use of an illegal destructor name '<em>name</em>' in %extend is deprecated, the destructor name should be '<em>name</em>'.
</ul>
<H3><a name="Warnings_nn15"></a>14.9.6 Language module specific (700-899) </H3>
<H3><a name="Warnings_nn15"></a>15.9.6 Language module specific (700-899) </H3>
<ul>
@ -582,14 +585,14 @@ example.i(4) : Syntax error in input.
<li>871. Unrecognized pragma <em>pragma</em>. (Php).
</ul>
<H3><a name="Warnings_nn16"></a>14.9.7 User defined (900-999)</H3>
<H3><a name="Warnings_nn16"></a>15.9.7 User defined (900-999)</H3>
<p>
These numbers can be used by your own application.
</p>
<H2><a name="Warnings_nn17"></a>14.10 History</H2>
<H2><a name="Warnings_nn17"></a>15.10 History</H2>
<p>

4
Doc/Manual/Windows.html
View file

@ -79,8 +79,8 @@ If you want to build your own swig.exe have a look at <a href="#Windows_swig_exe
Using Microsoft Visual C++ is the most common approach to compiling and linking SWIG's output.
The Examples directory has a few Visual C++ project files (.dsp files).
These were produced by Visual C++ 6.
Later versions of Visual Studio should also be able to open and convert these project files.
The C# examples come with .NET 2003 solution (.sln) and project files instead of Visual C++ 6 project files.
Newer versions of Visual Studio should be able to open and convert these project files.
Each C# example comes with a Visual Studio 2005 solution and associated project files instead of Visual C++ 6 project files.
The project files have been set up to execute SWIG in a custom build rule for the SWIG interface (.i) file.
Alternatively run the <a href="#Windows_examples_cygwin">examples using Cygwin</a>.

2
Doc/Manual/chapters
View file

@ -4,6 +4,7 @@ Windows.html
Scripting.html
SWIG.html
SWIGPlus.html
CPlusPlus11.html
Preprocessor.html
Library.html
Arguments.html
@ -22,6 +23,7 @@ D.html
Go.html
Guile.html
Java.html
Javascript.html
Lisp.html
Lua.html
Modula3.html

4
Doc/Manual/index.html
View file

@ -1,10 +1,10 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>SWIG-2.0 Documentation</title>
<title>SWIG-3.0 Documentation</title>
</head>
<body bgcolor="#ffffff">
<H1><a name="index"></a>SWIG-2.0 Documentation</h1>
<H1><a name="index"></a>SWIG-3.0 Documentation</h1>
The SWIG documentation is available in one of the following formats.
<ul>

825
Examples/Makefile.in
View file

File diff suppressed because it is too large Load diff

12
Examples/README
View file

@ -1,24 +1,18 @@
SWIG Examples
The "perl5", "python", "tcl", "guile", "java", "mzscheme", "ruby", and
"chicken" directories contain a number of simple examples that are
primarily used for testing.
The subdirectories of "Examples" named after SWIG's language backends
contain a number of simple examples that are primarily used for testing.
The file 'index.html' is the top of a hyperlinked document that
contains information about all of the examples along with various
notes related to each example.
The Examples directory is currently quite incomplete because it
is being reorganized. A more complete set of examples can be found
in the SWIG1.1p5 distribution (most of which should still work with
SWIG1.3).
Note: All of the examples rely upon the Makefile in this directory.
You may need to edit it to reflect the configuration of your machine
in case the configure script guesses incorrect settings.
*** Special note concering C++ ***
*** Special note concerning C++ ***
The configure script is currently unable to handle all of the possible
options for producing dynamically loadable C++ extensions. Here are

10
Examples/android/class/Makefile
View file

@ -3,9 +3,9 @@ SWIG = $(TOP)/../preinst-swig
TARGET = example
INTERFACE = example.i
INTERFACEDIR = jni/
PACKAGEDIR = src/org/swig
PACKAGEDIR = $(SRCDIR)src/org/swig
PACKAGENAME= org.swig.classexample
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/classexample
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/classexample
PROJECTNAME= SwigClass
TARGETID = 1
#INSTALLOPTIONS = -s # To install on SD Card
@ -13,14 +13,14 @@ TARGETID = 1
check: build
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' INTERFACEDIR='$(INTERFACEDIR)' \
PROJECTNAME='$(PROJECTNAME)' TARGETID='$(TARGETID)' android_cpp
install:
$(MAKE) -f $(TOP)/Makefile INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' PACKAGENAME='$(PACKAGENAME)' android_install
clean:
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' INTERFACEDIR='$(INTERFACEDIR)' android_clean

8
Examples/android/class/jni/example.cpp
View file

@ -11,18 +11,18 @@ void Shape::move(double dx, double dy) {
int Shape::nshapes = 0;
double Circle::area(void) {
double Circle::area() {
return M_PI*radius*radius;
}
double Circle::perimeter(void) {
double Circle::perimeter() {
return 2*M_PI*radius;
}
double Square::area(void) {
double Square::area() {
return width*width;
}
double Square::perimeter(void) {
double Square::perimeter() {
return 4*width;
}

20
Examples/android/class/jni/example.h
View file

@ -7,11 +7,11 @@ public:
}
virtual ~Shape() {
nshapes--;
};
double x, y;
}
double x, y;
void move(double dx, double dy);
virtual double area(void) = 0;
virtual double perimeter(void) = 0;
virtual double area() = 0;
virtual double perimeter() = 0;
static int nshapes;
};
@ -19,16 +19,16 @@ class Circle : public Shape {
private:
double radius;
public:
Circle(double r) : radius(r) { };
virtual double area(void);
virtual double perimeter(void);
Circle(double r) : radius(r) { }
virtual double area();
virtual double perimeter();
};
class Square : public Shape {
private:
double width;
public:
Square(double w) : width(w) { };
virtual double area(void);
virtual double perimeter(void);
Square(double w) : width(w) { }
virtual double area();
virtual double perimeter();
};

10
Examples/android/extend/Makefile
View file

@ -3,9 +3,9 @@ SWIG = $(TOP)/../preinst-swig
TARGET = example
INTERFACE = example.i
INTERFACEDIR = jni/
PACKAGEDIR = src/org/swig
PACKAGEDIR = $(SRCDIR)src/org/swig
PACKAGENAME= org.swig.extendexample
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/extendexample
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/extendexample
PROJECTNAME= SwigExtend
TARGETID = 1
#INSTALLOPTIONS = -s # To install on SD Card
@ -13,14 +13,14 @@ TARGETID = 1
check: build
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' INTERFACEDIR='$(INTERFACEDIR)' \
PROJECTNAME='$(PROJECTNAME)' TARGETID='$(TARGETID)' android_cpp
install:
$(MAKE) -f $(TOP)/Makefile INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' PACKAGENAME='$(PACKAGENAME)' android_install
clean:
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' INTERFACEDIR='$(INTERFACEDIR)' android_clean

8
Examples/android/simple/Makefile
View file

@ -3,7 +3,7 @@ SWIG = $(TOP)/../preinst-swig
TARGET = example
INTERFACE = example.i
INTERFACEDIR = jni/
PACKAGEDIR = src/org/swig
PACKAGEDIR = $(SRCDIR)src/org/swig
PACKAGENAME= org.swig.simple
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/simple
PROJECTNAME= SwigSimple
@ -13,14 +13,14 @@ TARGETID = 1
check: build
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' INTERFACEDIR='$(INTERFACEDIR)' \
PROJECTNAME='$(PROJECTNAME)' TARGETID='$(TARGETID)' android
install:
$(MAKE) -f $(TOP)/Makefile INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' PACKAGENAME='$(PACKAGENAME)' android_install
clean:
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' INTERFACEDIR='$(INTERFACEDIR)' android_clean

13
Examples/chicken/class/Makefile
View file

@ -1,12 +1,11 @@
TOP = ../..
SWIG = $(TOP)/../preinst-swig
INTERFACE = example.i
SRCS =
SRCS =
CXXSRCS = example.cxx
TARGET = class
INCLUDE =
SWIGOPT =
CFLAGS =
VARIANT =
# uncomment the following lines to build a static exe (only pick one of the CHICKEN_MAIN lines)
@ -15,24 +14,24 @@ VARIANT =
#VARIANT = _static
check: build
$(MAKE) -f $(TOP)/Makefile CHICKEN_SCRIPT='runme-lowlevel.scm' chicken_run
$(MAKE) -f $(TOP)/Makefile CHICKEN_SCRIPT='runme-tinyclos.scm' chicken_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CHICKEN_SCRIPT='runme-lowlevel.scm' chicken_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CHICKEN_SCRIPT='runme-tinyclos.scm' chicken_run
build: $(TARGET) $(TARGET)_proxy
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
$(TARGET)_proxy: $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT) -proxy' TARGET='$(TARGET)_proxy' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_clean
rm -f example.scm
rm -f $(TARGET)

10
Examples/chicken/class/example.cxx
View file

@ -1,4 +1,4 @@
/* File : example.c */
/* File : example.cxx */
#include "example.h"
#define M_PI 3.14159265358979323846
@ -11,18 +11,18 @@ void Shape::move(double dx, double dy) {
int Shape::nshapes = 0;
double Circle::area(void) {
double Circle::area() {
return M_PI*radius*radius;
}
double Circle::perimeter(void) {
double Circle::perimeter() {
return 2*M_PI*radius;
}
double Square::area(void) {
double Square::area() {
return width*width;
}
double Square::perimeter(void) {
double Square::perimeter() {
return 4*width;
}

25
Examples/chicken/class/example.h
View file

@ -7,11 +7,11 @@ public:
}
virtual ~Shape() {
nshapes--;
};
double x, y;
}
double x, y;
void move(double dx, double dy);
virtual double area(void) = 0;
virtual double perimeter(void) = 0;
virtual double area() = 0;
virtual double perimeter() = 0;
static int nshapes;
enum SomeEnum {
@ -26,21 +26,16 @@ class Circle : public Shape {
private:
double radius;
public:
Circle(double r) : radius(r) { };
virtual double area(void);
virtual double perimeter(void);
Circle(double r) : radius(r) { }
virtual double area();
virtual double perimeter();
};
class Square : public Shape {
private:
double width;
public:
Square(double w) : width(w) { };
virtual double area(void);
virtual double perimeter(void);
Square(double w) : width(w) { }
virtual double area();
virtual double perimeter();
};

1
Examples/chicken/class/example.i
View file

@ -7,4 +7,3 @@
/* Let's just grab the original header file here */
%include "example.h"

13
Examples/chicken/constants/Makefile
View file

@ -2,29 +2,28 @@ TOP = ../..
SWIG = $(TOP)/../preinst-swig
INTERFACE = example.i
SRCS =
CXXSRCS =
CXXSRCS =
TARGET = constants
INCLUDE =
SWIGOPT =
CFLAGS =
VARIANT =
SWIGOPT =
VARIANT =
# uncomment the following two lines to build a static exe
#CHICKEN_MAIN = runme.scm
#VARIANT = _static
check: build
$(MAKE) -f $(TOP)/Makefile chicken_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_run
build: $(TARGET)
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_clean
rm -f example.scm
rm -f $(TARGET)

13
Examples/chicken/multimap/Makefile
View file

@ -2,29 +2,28 @@ TOP = ../..
SWIG = $(TOP)/../preinst-swig
INTERFACE = example.i
SRCS = example.c
CXXSRCS =
CXXSRCS =
TARGET = multimap
INCLUDE =
SWIGOPT =
CFLAGS =
VARIANT =
SWIGOPT =
VARIANT =
# uncomment the following two lines to build a static exe
#CHICKEN_MAIN = runme.scm
#VARIANT = _static
check: build
$(MAKE) -f $(TOP)/Makefile chicken_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_run
build: $(TARGET)
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_clean
rm -f example.scm
rm -f $(TARGET)

11
Examples/chicken/overload/Makefile
View file

@ -1,30 +1,29 @@
TOP = ../..
SWIG = $(TOP)/../preinst-swig
INTERFACE = example.i
SRCS =
SRCS =
CXXSRCS = example.cxx
TARGET = overload
INCLUDE =
SWIGOPT = -proxy -unhideprimitive
CFLAGS =
VARIANT =
VARIANT =
# uncomment the following lines to build a static exe
#CHICKEN_MAIN = runme.scm
#VARIANT = _static
check: build
$(MAKE) -f $(TOP)/Makefile chicken_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_run
build: $(TARGET)
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_clean
rm -f example.scm
rm -f $(TARGET)

13
Examples/chicken/simple/Makefile
View file

@ -2,29 +2,28 @@ TOP = ../..
SWIG = $(TOP)/../preinst-swig
INTERFACE = example.i
SRCS = example.c
CXXSRCS =
CXXSRCS =
TARGET = simple
INCLUDE =
SWIGOPT =
CFLAGS =
VARIANT =
SWIGOPT =
VARIANT =
# uncomment the following two lines to build a static exe
#CHICKEN_MAIN = runme.scm
#VARIANT = _static
check: build
$(MAKE) -f $(TOP)/Makefile chicken_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_run
build: $(TARGET)
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' chicken_clean
rm -f example.scm example-generic.scm example-clos.scm
rm -f $(TARGET)

10
Examples/csharp/arrays/Makefile
View file

@ -5,15 +5,15 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -unsafe -out:runme.exe
CSHARPFLAGS= -nologo -debug+ -unsafe -out:runme.exe
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_run
build:
$(MAKE) -f $(TOP)/Makefile SRCS='$(SRCS)' SWIG='$(SWIG)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' SRCS='$(SRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_clean

90
Examples/csharp/arrays/example-cs.csproj Normal file
View file

@ -0,0 +1,90 @@
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectType>Local</ProjectType>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}</ProjectGuid>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ApplicationIcon>
</ApplicationIcon>
<AssemblyKeyContainerName>
</AssemblyKeyContainerName>
<AssemblyName>runme</AssemblyName>
<AssemblyOriginatorKeyFile>
</AssemblyOriginatorKeyFile>
<DefaultClientScript>JScript</DefaultClientScript>
<DefaultHTMLPageLayout>Grid</DefaultHTMLPageLayout>
<DefaultTargetSchema>IE50</DefaultTargetSchema>
<DelaySign>false</DelaySign>
<OutputType>Exe</OutputType>
<RootNamespace>runme</RootNamespace>
<RunPostBuildEvent>OnBuildSuccess</RunPostBuildEvent>
<StartupObject>
</StartupObject>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\x86\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
</PropertyGroup>
<ItemGroup>
<Compile Include="example.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="examplePINVOKE.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="runme.cs">
<SubType>Code</SubType>
</Compile>
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup>
<PreBuildEvent>
</PreBuildEvent>
<PostBuildEvent>copy runme.exe "$(SolutionDir)runme.exe"
echo Run the example from the root directory $(SolutionDir) and ensure example.dll is also in this directory</PostBuildEvent>
</PropertyGroup>
</Project>

415
Examples/csharp/arrays/example-vc.vcproj Normal file
View file

@ -0,0 +1,415 @@
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="8.00"
Name="example"
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
Keyword="Win32Proj"
>
<Platforms>
<Platform
Name="Win32"
/>
<Platform
Name="x64"
/>
</Platforms>
<ToolFiles>
</ToolFiles>
<Configurations>
<Configuration
Name="Debug|Win32"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="4"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Debug|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|Win32"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
</Configurations>
<References>
</References>
<Files>
<Filter
Name="Source Files"
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath="example.c"
>
</File>
<File
RelativePath="example_wrap.c"
>
</File>
</Filter>
<Filter
Name="Header Files"
Filter="h;hpp;hxx;hm;inl;inc;xsd"
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
>
<File
RelativePath="example.h"
>
</File>
</Filter>
<File
RelativePath=".\example.i"
>
<FileConfiguration
Name="Debug|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.c"
/>
</FileConfiguration>
<FileConfiguration
Name="Debug|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.c"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.c"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.c"
/>
</FileConfiguration>
</File>
</Files>
<Globals>
</Globals>
</VisualStudioProject>

38
Examples/csharp/arrays/example.sln Normal file
View file

@ -0,0 +1,38 @@
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
ProjectSection(ProjectDependencies) = postProject
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Debug|x64 = Debug|x64
Release|Win32 = Release|Win32
Release|x64 = Release|x64
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.ActiveCfg = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.Build.0 = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.ActiveCfg = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.Build.0 = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.ActiveCfg = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.Build.0 = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.ActiveCfg = Release|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.Build.0 = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.ActiveCfg = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.Build.0 = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.Build.0 = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.ActiveCfg = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.Build.0 = Release|x64
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal

10
Examples/csharp/callback/Makefile
View file

@ -5,15 +5,15 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -debug -nologo -out:runme.exe
CSHARPFLAGS= -nologo -debug+ -out:runme.exe
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_run
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_clean

187
Examples/csharp/callback/example-cs.csproj
View file

@ -1,99 +1,88 @@
<VisualStudioProject>
<CSHARP
ProjectType = "Local"
ProductVersion = "7.10.3077"
SchemaVersion = "2.0"
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
>
<Build>
<Settings
ApplicationIcon = ""
AssemblyKeyContainerName = ""
AssemblyName = "runme"
AssemblyOriginatorKeyFile = ""
DefaultClientScript = "JScript"
DefaultHTMLPageLayout = "Grid"
DefaultTargetSchema = "IE50"
DelaySign = "false"
OutputType = "Exe"
PreBuildEvent = ""
PostBuildEvent = ""
RootNamespace = "runme"
RunPostBuildEvent = "OnBuildSuccess"
StartupObject = ""
>
<Config
Name = "Debug"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "DEBUG;TRACE"
DocumentationFile = ""
DebugSymbols = "true"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "false"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
<Config
Name = "Release"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "TRACE"
DocumentationFile = ""
DebugSymbols = "false"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "true"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
</Settings>
<References/>
</Build>
<Files>
<Include>
<File
RelPath = "Callback.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "Caller.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "example.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "examplePINVOKE.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "runme.cs"
SubType = "Code"
BuildAction = "Compile"
/>
</Include>
</Files>
</CSHARP>
</VisualStudioProject>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectType>Local</ProjectType>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}</ProjectGuid>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ApplicationIcon>
</ApplicationIcon>
<AssemblyKeyContainerName>
</AssemblyKeyContainerName>
<AssemblyName>runme</AssemblyName>
<AssemblyOriginatorKeyFile>
</AssemblyOriginatorKeyFile>
<DefaultClientScript>JScript</DefaultClientScript>
<DefaultHTMLPageLayout>Grid</DefaultHTMLPageLayout>
<DefaultTargetSchema>IE50</DefaultTargetSchema>
<DelaySign>false</DelaySign>
<OutputType>Exe</OutputType>
<RootNamespace>runme</RootNamespace>
<RunPostBuildEvent>OnBuildSuccess</RunPostBuildEvent>
<StartupObject>
</StartupObject>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\x86\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<ItemGroup>
<Compile Include="Callback.cs" />
<Compile Include="Caller.cs" />
<Compile Include="example.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="examplePINVOKE.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="runme.cs">
<SubType>Code</SubType>
</Compile>
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup>
<PreBuildEvent>
</PreBuildEvent>
<PostBuildEvent>copy runme.exe "$(SolutionDir)runme.exe"
echo Run the example from the root directory $(SolutionDir) and ensure example.dll is also in this directory</PostBuildEvent>
</PropertyGroup>
</Project>

387
Examples/csharp/callback/example-vc.vcproj
View file

@ -1,110 +1,345 @@
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="7.10"
Version="8.00"
Name="example"
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
Keyword="Win32Proj">
Keyword="Win32Proj"
>
<Platforms>
<Platform
Name="Win32"/>
Name="Win32"
/>
<Platform
Name="x64"
/>
</Platforms>
<ToolFiles>
</ToolFiles>
<Configurations>
<Configuration
Name="Debug|Win32"
OutputDirectory="Debug"
IntermediateDirectory="Debug"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="TRUE"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="4"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="4"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="TRUE"
ProgramDatabaseFile="$(OutDir)/example.pdb"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Debug|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|Win32"
OutputDirectory="Release"
IntermediateDirectory="Release"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="3"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="TRUE"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
</Configurations>
<References>
@ -113,43 +348,69 @@
<Filter
Name="Source Files"
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath="example.cxx">
RelativePath="example.cxx"
>
</File>
<File
RelativePath="example_wrap.cxx">
RelativePath="example_wrap.cxx"
>
</File>
</Filter>
<Filter
Name="Header Files"
Filter="h;hpp;hxx;hm;inl;inc;xsd"
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
>
<File
RelativePath="example.h">
RelativePath="example.h"
>
</File>
<File
RelativePath="example_wrap.h"
>
</File>
</Filter>
<File
RelativePath=".\example.i">
RelativePath=".\example.i"
>
<FileConfiguration
Name="Debug|Win32">
Name="Debug|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;
@echo off"
Outputs="$(InputName)_wrap.cxx"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
Name="Debug|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;
@echo off"
Outputs="$(InputName)_wrap.cxx"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
</File>
</Files>

44
Examples/csharp/callback/example.sln
View file

@ -1,30 +1,38 @@
Microsoft Visual Studio Solution File, Format Version 8.00
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
ProjectSection(ProjectDependencies) = postProject
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
ProjectSection(ProjectDependencies) = postProject
EndProjectSection
EndProject
Global
GlobalSection(SolutionConfiguration) = preSolution
Debug = Debug
Release = Release
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Debug|x64 = Debug|x64
Release|Win32 = Release|Win32
Release|x64 = Release|x64
EndGlobalSection
GlobalSection(ProjectConfiguration) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.ActiveCfg = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.Build.0 = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.ActiveCfg = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.Build.0 = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.ActiveCfg = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.Build.0 = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.ActiveCfg = Release|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.Build.0 = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.ActiveCfg = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.Build.0 = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.Build.0 = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.ActiveCfg = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.Build.0 = Release|x64
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
EndGlobalSection
GlobalSection(ExtensibilityAddIns) = postSolution
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal

1
Examples/csharp/check.list
View file

@ -5,6 +5,7 @@ class
enum
extend
funcptr
nested
reference
simple
template

10
Examples/csharp/class/Makefile
View file

@ -5,15 +5,15 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
CSHARPFLAGS= -nologo -debug+ -out:runme.exe
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_run
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_clean

193
Examples/csharp/class/example-cs.csproj
View file

@ -1,104 +1,89 @@
<VisualStudioProject>
<CSHARP
ProjectType = "Local"
ProductVersion = "7.10.3077"
SchemaVersion = "2.0"
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
>
<Build>
<Settings
ApplicationIcon = ""
AssemblyKeyContainerName = ""
AssemblyName = "runme"
AssemblyOriginatorKeyFile = ""
DefaultClientScript = "JScript"
DefaultHTMLPageLayout = "Grid"
DefaultTargetSchema = "IE50"
DelaySign = "false"
OutputType = "Exe"
PreBuildEvent = ""
PostBuildEvent = ""
RootNamespace = "runme"
RunPostBuildEvent = "OnBuildSuccess"
StartupObject = ""
>
<Config
Name = "Debug"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "DEBUG;TRACE"
DocumentationFile = ""
DebugSymbols = "true"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "false"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
<Config
Name = "Release"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "TRACE"
DocumentationFile = ""
DebugSymbols = "false"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "true"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
</Settings>
<References/>
</Build>
<Files>
<Include>
<File
RelPath = "Circle.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "example.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "examplePINVOKE.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "runme.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "Shape.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "Square.cs"
SubType = "Code"
BuildAction = "Compile"
/>
</Include>
</Files>
</CSHARP>
</VisualStudioProject>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectType>Local</ProjectType>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}</ProjectGuid>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ApplicationIcon>
</ApplicationIcon>
<AssemblyKeyContainerName>
</AssemblyKeyContainerName>
<AssemblyName>runme</AssemblyName>
<AssemblyOriginatorKeyFile>
</AssemblyOriginatorKeyFile>
<DefaultClientScript>JScript</DefaultClientScript>
<DefaultHTMLPageLayout>Grid</DefaultHTMLPageLayout>
<DefaultTargetSchema>IE50</DefaultTargetSchema>
<DelaySign>false</DelaySign>
<OutputType>Exe</OutputType>
<RootNamespace>runme</RootNamespace>
<RunPostBuildEvent>OnBuildSuccess</RunPostBuildEvent>
<StartupObject>
</StartupObject>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\x86\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<ItemGroup>
<Compile Include="Circle.cs" />
<Compile Include="example.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="examplePINVOKE.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="runme.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="Shape.cs" />
<Compile Include="Square.cs" />
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup>
<PreBuildEvent>
</PreBuildEvent>
<PostBuildEvent>copy runme.exe "$(SolutionDir)runme.exe"
echo Run the example from the root directory $(SolutionDir) and ensure example.dll is also in this directory</PostBuildEvent>
</PropertyGroup>
</Project>

383
Examples/csharp/class/example-vc.vcproj
View file

@ -1,110 +1,345 @@
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="7.10"
Version="8.00"
Name="example"
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
Keyword="Win32Proj">
Keyword="Win32Proj"
>
<Platforms>
<Platform
Name="Win32"/>
Name="Win32"
/>
<Platform
Name="x64"
/>
</Platforms>
<ToolFiles>
</ToolFiles>
<Configurations>
<Configuration
Name="Debug|Win32"
OutputDirectory="Debug"
IntermediateDirectory="Debug"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="TRUE"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="4"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="4"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="TRUE"
ProgramDatabaseFile="$(OutDir)/example.pdb"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Debug|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|Win32"
OutputDirectory="Release"
IntermediateDirectory="Release"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="3"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="TRUE"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
</Configurations>
<References>
@ -113,43 +348,65 @@
<Filter
Name="Source Files"
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath="example.cxx">
RelativePath="example.cxx"
>
</File>
<File
RelativePath="example_wrap.cxx">
RelativePath="example_wrap.cxx"
>
</File>
</Filter>
<Filter
Name="Header Files"
Filter="h;hpp;hxx;hm;inl;inc;xsd"
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
>
<File
RelativePath="example.h">
RelativePath="example.h"
>
</File>
</Filter>
<File
RelativePath=".\example.i">
RelativePath=".\example.i"
>
<FileConfiguration
Name="Debug|Win32">
Name="Debug|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;
@echo off"
Outputs="$(InputName)_wrap.cxx"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
Name="Debug|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;
@echo off"
Outputs="$(InputName)_wrap.cxx"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
</File>
</Files>

10
Examples/csharp/class/example.cxx
View file

@ -1,4 +1,4 @@
/* File : example.c */
/* File : example.cxx */
#include "example.h"
#define M_PI 3.14159265358979323846
@ -11,18 +11,18 @@ void Shape::move(double dx, double dy) {
int Shape::nshapes = 0;
double Circle::area(void) {
double Circle::area() {
return M_PI*radius*radius;
}
double Circle::perimeter(void) {
double Circle::perimeter() {
return 2*M_PI*radius;
}
double Square::area(void) {
double Square::area() {
return width*width;
}
double Square::perimeter(void) {
double Square::perimeter() {
return 4*width;
}

25
Examples/csharp/class/example.h
View file

@ -7,11 +7,11 @@ public:
}
virtual ~Shape() {
nshapes--;
};
double x, y;
}
double x, y;
void move(double dx, double dy);
virtual double area(void) = 0;
virtual double perimeter(void) = 0;
virtual double area() = 0;
virtual double perimeter() = 0;
static int nshapes;
};
@ -19,21 +19,16 @@ class Circle : public Shape {
private:
double radius;
public:
Circle(double r) : radius(r) { };
virtual double area(void);
virtual double perimeter(void);
Circle(double r) : radius(r) { }
virtual double area();
virtual double perimeter();
};
class Square : public Shape {
private:
double width;
public:
Square(double w) : width(w) { };
virtual double area(void);
virtual double perimeter(void);
Square(double w) : width(w) { }
virtual double area();
virtual double perimeter();
};

1
Examples/csharp/class/example.i
View file

@ -7,4 +7,3 @@
/* Let's just grab the original header file here */
%include "example.h"

44
Examples/csharp/class/example.sln
View file

@ -1,30 +1,38 @@
Microsoft Visual Studio Solution File, Format Version 8.00
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
ProjectSection(ProjectDependencies) = postProject
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
ProjectSection(ProjectDependencies) = postProject
EndProjectSection
EndProject
Global
GlobalSection(SolutionConfiguration) = preSolution
Debug = Debug
Release = Release
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Debug|x64 = Debug|x64
Release|Win32 = Release|Win32
Release|x64 = Release|x64
EndGlobalSection
GlobalSection(ProjectConfiguration) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.ActiveCfg = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.Build.0 = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.ActiveCfg = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.Build.0 = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.ActiveCfg = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.Build.0 = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.ActiveCfg = Release|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.Build.0 = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.ActiveCfg = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.Build.0 = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.Build.0 = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.ActiveCfg = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.Build.0 = Release|x64
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
EndGlobalSection
GlobalSection(ExtensibilityAddIns) = postSolution
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal

10
Examples/csharp/enum/Makefile
View file

@ -5,15 +5,15 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
CSHARPFLAGS= -nologo -debug+ -out:runme.exe
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_run
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_clean

187
Examples/csharp/enum/example-cs.csproj
View file

@ -1,99 +1,88 @@
<VisualStudioProject>
<CSHARP
ProjectType = "Local"
ProductVersion = "7.10.3077"
SchemaVersion = "2.0"
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
>
<Build>
<Settings
ApplicationIcon = ""
AssemblyKeyContainerName = ""
AssemblyName = "runme"
AssemblyOriginatorKeyFile = ""
DefaultClientScript = "JScript"
DefaultHTMLPageLayout = "Grid"
DefaultTargetSchema = "IE50"
DelaySign = "false"
OutputType = "Exe"
PreBuildEvent = ""
PostBuildEvent = ""
RootNamespace = "runme"
RunPostBuildEvent = "OnBuildSuccess"
StartupObject = ""
>
<Config
Name = "Debug"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "DEBUG;TRACE"
DocumentationFile = ""
DebugSymbols = "true"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "false"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
<Config
Name = "Release"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "TRACE"
DocumentationFile = ""
DebugSymbols = "false"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "true"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
</Settings>
<References/>
</Build>
<Files>
<Include>
<File
RelPath = "color.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "example.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "examplePINVOKE.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "Foo.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "runme.cs"
SubType = "Code"
BuildAction = "Compile"
/>
</Include>
</Files>
</CSHARP>
</VisualStudioProject>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectType>Local</ProjectType>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}</ProjectGuid>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ApplicationIcon>
</ApplicationIcon>
<AssemblyKeyContainerName>
</AssemblyKeyContainerName>
<AssemblyName>runme</AssemblyName>
<AssemblyOriginatorKeyFile>
</AssemblyOriginatorKeyFile>
<DefaultClientScript>JScript</DefaultClientScript>
<DefaultHTMLPageLayout>Grid</DefaultHTMLPageLayout>
<DefaultTargetSchema>IE50</DefaultTargetSchema>
<DelaySign>false</DelaySign>
<OutputType>Exe</OutputType>
<RootNamespace>runme</RootNamespace>
<RunPostBuildEvent>OnBuildSuccess</RunPostBuildEvent>
<StartupObject>
</StartupObject>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\x86\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<ItemGroup>
<Compile Include="color.cs" />
<Compile Include="example.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="examplePINVOKE.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="Foo.cs" />
<Compile Include="runme.cs">
<SubType>Code</SubType>
</Compile>
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup>
<PreBuildEvent>
</PreBuildEvent>
<PostBuildEvent>copy runme.exe "$(SolutionDir)runme.exe"
echo Run the example from the root directory $(SolutionDir) and ensure example.dll is also in this directory</PostBuildEvent>
</PropertyGroup>
</Project>

383
Examples/csharp/enum/example-vc.vcproj
View file

@ -1,110 +1,345 @@
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="7.10"
Version="8.00"
Name="example"
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
Keyword="Win32Proj">
Keyword="Win32Proj"
>
<Platforms>
<Platform
Name="Win32"/>
Name="Win32"
/>
<Platform
Name="x64"
/>
</Platforms>
<ToolFiles>
</ToolFiles>
<Configurations>
<Configuration
Name="Debug|Win32"
OutputDirectory="Debug"
IntermediateDirectory="Debug"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="TRUE"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="4"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="4"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="TRUE"
ProgramDatabaseFile="$(OutDir)/example.pdb"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Debug|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|Win32"
OutputDirectory="Release"
IntermediateDirectory="Release"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="3"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="TRUE"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
</Configurations>
<References>
@ -113,43 +348,65 @@
<Filter
Name="Source Files"
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath="example.cxx">
RelativePath="example.cxx"
>
</File>
<File
RelativePath="example_wrap.cxx">
RelativePath="example_wrap.cxx"
>
</File>
</Filter>
<Filter
Name="Header Files"
Filter="h;hpp;hxx;hm;inl;inc;xsd"
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
>
<File
RelativePath="example.h">
RelativePath="example.h"
>
</File>
</Filter>
<File
RelativePath=".\example.i">
RelativePath=".\example.i"
>
<FileConfiguration
Name="Debug|Win32">
Name="Debug|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;
@echo off"
Outputs="$(InputName)_wrap.cxx"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
Name="Debug|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;
@echo off"
Outputs="$(InputName)_wrap.cxx"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
</File>
</Files>

44
Examples/csharp/enum/example.sln
View file

@ -1,30 +1,38 @@
Microsoft Visual Studio Solution File, Format Version 8.00
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
ProjectSection(ProjectDependencies) = postProject
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
ProjectSection(ProjectDependencies) = postProject
EndProjectSection
EndProject
Global
GlobalSection(SolutionConfiguration) = preSolution
Debug = Debug
Release = Release
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Debug|x64 = Debug|x64
Release|Win32 = Release|Win32
Release|x64 = Release|x64
EndGlobalSection
GlobalSection(ProjectConfiguration) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.ActiveCfg = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.Build.0 = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.ActiveCfg = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.Build.0 = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.ActiveCfg = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.Build.0 = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.ActiveCfg = Release|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.Build.0 = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.ActiveCfg = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.Build.0 = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.Build.0 = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.ActiveCfg = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.Build.0 = Release|x64
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
EndGlobalSection
GlobalSection(ExtensibilityAddIns) = postSolution
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal

10
Examples/csharp/extend/Makefile
View file

@ -5,15 +5,15 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
CSHARPFLAGS= -nologo -debug+ -out:runme.exe
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_run
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_clean

193
Examples/csharp/extend/example-cs.csproj
View file

@ -1,104 +1,89 @@
<VisualStudioProject>
<CSHARP
ProjectType = "Local"
ProductVersion = "7.10.3077"
SchemaVersion = "2.0"
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
>
<Build>
<Settings
ApplicationIcon = ""
AssemblyKeyContainerName = ""
AssemblyName = "runme"
AssemblyOriginatorKeyFile = ""
DefaultClientScript = "JScript"
DefaultHTMLPageLayout = "Grid"
DefaultTargetSchema = "IE50"
DelaySign = "false"
OutputType = "Exe"
PreBuildEvent = ""
PostBuildEvent = ""
RootNamespace = "runme"
RunPostBuildEvent = "OnBuildSuccess"
StartupObject = ""
>
<Config
Name = "Debug"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "DEBUG;TRACE"
DocumentationFile = ""
DebugSymbols = "true"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "false"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
<Config
Name = "Release"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "TRACE"
DocumentationFile = ""
DebugSymbols = "false"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "true"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
</Settings>
<References/>
</Build>
<Files>
<Include>
<File
RelPath = "Employee.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "EmployeeList.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "Manager.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "example.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "examplePINVOKE.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "runme.cs"
SubType = "Code"
BuildAction = "Compile"
/>
</Include>
</Files>
</CSHARP>
</VisualStudioProject>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectType>Local</ProjectType>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}</ProjectGuid>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ApplicationIcon>
</ApplicationIcon>
<AssemblyKeyContainerName>
</AssemblyKeyContainerName>
<AssemblyName>runme</AssemblyName>
<AssemblyOriginatorKeyFile>
</AssemblyOriginatorKeyFile>
<DefaultClientScript>JScript</DefaultClientScript>
<DefaultHTMLPageLayout>Grid</DefaultHTMLPageLayout>
<DefaultTargetSchema>IE50</DefaultTargetSchema>
<DelaySign>false</DelaySign>
<OutputType>Exe</OutputType>
<RootNamespace>runme</RootNamespace>
<RunPostBuildEvent>OnBuildSuccess</RunPostBuildEvent>
<StartupObject>
</StartupObject>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\x86\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<ItemGroup>
<Compile Include="Employee.cs" />
<Compile Include="EmployeeList.cs" />
<Compile Include="example.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="examplePINVOKE.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="Manager.cs" />
<Compile Include="runme.cs">
<SubType>Code</SubType>
</Compile>
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup>
<PreBuildEvent>
</PreBuildEvent>
<PostBuildEvent>copy runme.exe "$(SolutionDir)runme.exe"
echo Run the example from the root directory $(SolutionDir) and ensure example.dll is also in this directory</PostBuildEvent>
</PropertyGroup>
</Project>

387
Examples/csharp/extend/example-vc.vcproj
View file

@ -1,110 +1,345 @@
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="7.10"
Version="8.00"
Name="example"
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
Keyword="Win32Proj">
Keyword="Win32Proj"
>
<Platforms>
<Platform
Name="Win32"/>
Name="Win32"
/>
<Platform
Name="x64"
/>
</Platforms>
<ToolFiles>
</ToolFiles>
<Configurations>
<Configuration
Name="Debug|Win32"
OutputDirectory="Debug"
IntermediateDirectory="Debug"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="TRUE"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="4"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="4"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="TRUE"
ProgramDatabaseFile="$(OutDir)/example.pdb"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Debug|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|Win32"
OutputDirectory="Release"
IntermediateDirectory="Release"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="3"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="TRUE"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
</Configurations>
<References>
@ -113,43 +348,69 @@
<Filter
Name="Source Files"
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath="example.cxx">
RelativePath="example.cxx"
>
</File>
<File
RelativePath="example_wrap.cxx">
RelativePath="example_wrap.cxx"
>
</File>
</Filter>
<Filter
Name="Header Files"
Filter="h;hpp;hxx;hm;inl;inc;xsd"
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
>
<File
RelativePath="example.h">
RelativePath="example.h"
>
</File>
<File
RelativePath="example_wrap.h"
>
</File>
</Filter>
<File
RelativePath=".\example.i">
RelativePath=".\example.i"
>
<FileConfiguration
Name="Debug|Win32">
Name="Debug|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;
@echo off"
Outputs="$(InputName)_wrap.cxx"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
Name="Debug|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;
@echo off"
Outputs="$(InputName)_wrap.cxx"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
</File>
</Files>

2
Examples/csharp/extend/example.h
View file

@ -14,7 +14,7 @@ public:
virtual std::string getTitle() { return getPosition() + " " + getName(); }
virtual std::string getName() { return name; }
virtual std::string getPosition() const { return "Employee"; }
virtual ~Employee() { printf("~Employee() @ %p\n", this); }
virtual ~Employee() { printf("~Employee() @ %p\n", (void *)this); }
};

44
Examples/csharp/extend/example.sln
View file

@ -1,30 +1,38 @@
Microsoft Visual Studio Solution File, Format Version 8.00
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
ProjectSection(ProjectDependencies) = postProject
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
ProjectSection(ProjectDependencies) = postProject
EndProjectSection
EndProject
Global
GlobalSection(SolutionConfiguration) = preSolution
Debug = Debug
Release = Release
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Debug|x64 = Debug|x64
Release|Win32 = Release|Win32
Release|x64 = Release|x64
EndGlobalSection
GlobalSection(ProjectConfiguration) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.ActiveCfg = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.Build.0 = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.ActiveCfg = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.Build.0 = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.ActiveCfg = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.Build.0 = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.ActiveCfg = Release|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.Build.0 = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.ActiveCfg = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.Build.0 = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.Build.0 = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.ActiveCfg = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.Build.0 = Release|x64
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
EndGlobalSection
GlobalSection(ExtensibilityAddIns) = postSolution
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal

10
Examples/csharp/funcptr/Makefile
View file

@ -5,15 +5,15 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
CSHARPFLAGS= -nologo -debug+ -out:runme.exe
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_run
build:
$(MAKE) -f $(TOP)/Makefile SRCS='$(SRCS)' SWIG='$(SWIG)' \
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' SRCS='$(SRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_clean

181
Examples/csharp/funcptr/example-cs.csproj
View file

@ -1,94 +1,87 @@
<VisualStudioProject>
<CSHARP
ProjectType = "Local"
ProductVersion = "7.10.3077"
SchemaVersion = "2.0"
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
>
<Build>
<Settings
ApplicationIcon = ""
AssemblyKeyContainerName = ""
AssemblyName = "runme"
AssemblyOriginatorKeyFile = ""
DefaultClientScript = "JScript"
DefaultHTMLPageLayout = "Grid"
DefaultTargetSchema = "IE50"
DelaySign = "false"
OutputType = "Exe"
PreBuildEvent = ""
PostBuildEvent = ""
RootNamespace = "runme"
RunPostBuildEvent = "OnBuildSuccess"
StartupObject = ""
>
<Config
Name = "Debug"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "DEBUG;TRACE"
DocumentationFile = ""
DebugSymbols = "true"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "false"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
<Config
Name = "Release"
AllowUnsafeBlocks = "false"
BaseAddress = "285212672"
CheckForOverflowUnderflow = "false"
ConfigurationOverrideFile = ""
DefineConstants = "TRACE"
DocumentationFile = ""
DebugSymbols = "false"
FileAlignment = "4096"
IncrementalBuild = "false"
NoStdLib = "false"
NoWarn = ""
Optimize = "true"
OutputPath = ".\"
RegisterForComInterop = "false"
RemoveIntegerChecks = "false"
TreatWarningsAsErrors = "false"
WarningLevel = "4"
/>
</Settings>
<References/>
</Build>
<Files>
<Include>
<File
RelPath = "example.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "examplePINVOKE.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "runme.cs"
SubType = "Code"
BuildAction = "Compile"
/>
<File
RelPath = "SWIGTYPE_p_f_int_int__int.cs"
SubType = "Code"
BuildAction = "Compile"
/>
</Include>
</Files>
</CSHARP>
</VisualStudioProject>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectType>Local</ProjectType>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}</ProjectGuid>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ApplicationIcon>
</ApplicationIcon>
<AssemblyKeyContainerName>
</AssemblyKeyContainerName>
<AssemblyName>runme</AssemblyName>
<AssemblyOriginatorKeyFile>
</AssemblyOriginatorKeyFile>
<DefaultClientScript>JScript</DefaultClientScript>
<DefaultHTMLPageLayout>Grid</DefaultHTMLPageLayout>
<DefaultTargetSchema>IE50</DefaultTargetSchema>
<DelaySign>false</DelaySign>
<OutputType>Exe</OutputType>
<RootNamespace>runme</RootNamespace>
<RunPostBuildEvent>OnBuildSuccess</RunPostBuildEvent>
<StartupObject>
</StartupObject>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\x86\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<ItemGroup>
<Compile Include="example.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="examplePINVOKE.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="runme.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="SWIGTYPE_p_f_int_int__int.cs" />
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup>
<PreBuildEvent>
</PreBuildEvent>
<PostBuildEvent>copy runme.exe "$(SolutionDir)runme.exe"
echo Run the example from the root directory $(SolutionDir) and ensure example.dll is also in this directory</PostBuildEvent>
</PropertyGroup>
</Project>

385
Examples/csharp/funcptr/example-vc.vcproj
View file

@ -1,110 +1,345 @@
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="7.10"
Version="8.00"
Name="example"
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
Keyword="Win32Proj">
Keyword="Win32Proj"
>
<Platforms>
<Platform
Name="Win32"/>
Name="Win32"
/>
<Platform
Name="x64"
/>
</Platforms>
<ToolFiles>
</ToolFiles>
<Configurations>
<Configuration
Name="Debug|Win32"
OutputDirectory="Debug"
IntermediateDirectory="Debug"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="TRUE"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="4"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="4"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="TRUE"
ProgramDatabaseFile="$(OutDir)/example.pdb"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Debug|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|Win32"
OutputDirectory="Release"
IntermediateDirectory="Release"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
CharacterSet="2">
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="3"/>
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCCustomBuildTool"/>
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="example.dll"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="TRUE"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)/example.lib"
TargetMachine="1"/>
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCMIDLTool"/>
Name="VCALinkTool"
/>
<Tool
Name="VCPostBuildEventTool"/>
Name="VCManifestTool"
/>
<Tool
Name="VCPreBuildEventTool"/>
Name="VCXDCMakeTool"
/>
<Tool
Name="VCPreLinkEventTool"/>
Name="VCBscMakeTool"
/>
<Tool
Name="VCResourceCompilerTool"/>
Name="VCFxCopTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
Name="VCAppVerifierTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"/>
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCWebDeploymentTool"/>
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
</Configurations>
<References>
@ -113,45 +348,65 @@
<Filter
Name="Source Files"
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath=".\example.c">
RelativePath="example.c"
>
</File>
<File
RelativePath=".\example_wrap.c">
RelativePath="example_wrap.c"
>
</File>
</Filter>
<Filter
Name="Header Files"
Filter="h;hpp;hxx;hm;inl;inc;xsd"
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
>
<File
RelativePath=".\example.h">
RelativePath="example.h"
>
</File>
</Filter>
<File
RelativePath=".\example.i">
RelativePath=".\example.i"
>
<FileConfiguration
Name="Debug|Win32">
Name="Debug|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;
@echo off
"
Outputs="$(InputName)_wrap.c"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.c"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
Name="Debug|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;
@echo off
"
Outputs="$(InputName)_wrap.c"/>
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.c"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.c"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.c"
/>
</FileConfiguration>
</File>
</Files>

44
Examples/csharp/funcptr/example.sln
View file

@ -1,30 +1,38 @@
Microsoft Visual Studio Solution File, Format Version 8.00
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
ProjectSection(ProjectDependencies) = postProject
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
ProjectSection(ProjectDependencies) = postProject
EndProjectSection
EndProject
Global
GlobalSection(SolutionConfiguration) = preSolution
Debug = Debug
Release = Release
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Debug|x64 = Debug|x64
Release|Win32 = Release|Win32
Release|x64 = Release|x64
EndGlobalSection
GlobalSection(ProjectConfiguration) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.ActiveCfg = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.Build.0 = Debug|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.ActiveCfg = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|x64.Build.0 = Debug|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.ActiveCfg = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.Build.0 = Release|x86
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.ActiveCfg = Release|x64
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|x64.Build.0 = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.ActiveCfg = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.Build.0 = Debug|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.ActiveCfg = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|x64.Build.0 = Debug|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.ActiveCfg = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.Build.0 = Release|Win32
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.ActiveCfg = Release|x64
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|x64.Build.0 = Release|x64
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
EndGlobalSection
GlobalSection(ExtensibilityAddIns) = postSolution
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal

19
Examples/csharp/nested/Makefile Normal file
View file

@ -0,0 +1,19 @@
TOP = ../..
SWIG = $(TOP)/../preinst-swig
CXXSRCS = example.cxx
TARGET = example
INTERFACE = example.i
SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -debug+ -out:runme.exe
check: build
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_run
build:
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean:
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' csharp_clean

87
Examples/csharp/nested/example-cs.csproj Normal file
View file

@ -0,0 +1,87 @@
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectType>Local</ProjectType>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}</ProjectGuid>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ApplicationIcon>
</ApplicationIcon>
<AssemblyKeyContainerName>
</AssemblyKeyContainerName>
<AssemblyName>runme</AssemblyName>
<AssemblyOriginatorKeyFile>
</AssemblyOriginatorKeyFile>
<DefaultClientScript>JScript</DefaultClientScript>
<DefaultHTMLPageLayout>Grid</DefaultHTMLPageLayout>
<DefaultTargetSchema>IE50</DefaultTargetSchema>
<DelaySign>false</DelaySign>
<OutputType>Exe</OutputType>
<RootNamespace>runme</RootNamespace>
<RunPostBuildEvent>OnBuildSuccess</RunPostBuildEvent>
<StartupObject>
</StartupObject>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\x86\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<Optimize>true</Optimize>
<DebugType>
</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<ItemGroup>
<Compile Include="example.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="examplePINVOKE.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="runme.cs">
<SubType>Code</SubType>
</Compile>
<Compile Include="MotorCar.cs" />
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup>
<PreBuildEvent>
</PreBuildEvent>
<PostBuildEvent>copy runme.exe "$(SolutionDir)runme.exe"
echo Run the example from the root directory $(SolutionDir) and ensure example.dll is also in this directory</PostBuildEvent>
</PropertyGroup>
</Project>

415
Examples/csharp/nested/example-vc.vcproj Normal file
View file

@ -0,0 +1,415 @@
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="8.00"
Name="example"
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
Keyword="Win32Proj"
>
<Platforms>
<Platform
Name="Win32"
/>
<Platform
Name="x64"
/>
</Platforms>
<ToolFiles>
</ToolFiles>
<Configurations>
<Configuration
Name="Debug|Win32"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="4"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Debug|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="2"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|Win32"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="1"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
<Configuration
Name="Release|x64"
OutputDirectory="$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
CharacterSet="2"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
TargetEnvironment="3"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
RuntimeLibrary="0"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
Name="VCResourceCompilerTool"
/>
<Tool
Name="VCPreLinkEventTool"
/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\example.dll"
LinkIncremental="1"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)\example.pdb"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary="$(OutDir)\example.lib"
TargetMachine="17"
/>
<Tool
Name="VCALinkTool"
/>
<Tool
Name="VCManifestTool"
/>
<Tool
Name="VCXDCMakeTool"
/>
<Tool
Name="VCBscMakeTool"
/>
<Tool
Name="VCFxCopTool"
/>
<Tool
Name="VCAppVerifierTool"
/>
<Tool
Name="VCWebDeploymentTool"
/>
<Tool
Name="VCPostBuildEventTool"
Description="Copy unmanaged dll to root directory..."
CommandLine="echo on&#x0D;&#x0A;copy &quot;$(OutDir)\example.dll&quot; &quot;$(SolutionDir)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
/>
</Configuration>
</Configurations>
<References>
</References>
<Files>
<Filter
Name="Source Files"
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath="example.cxx"
>
</File>
<File
RelativePath="example_wrap.cxx"
>
</File>
</Filter>
<Filter
Name="Header Files"
Filter="h;hpp;hxx;hm;inl;inc;xsd"
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
>
<File
RelativePath="example.h"
>
</File>
</Filter>
<File
RelativePath=".\example.i"
>
<FileConfiguration
Name="Debug|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Debug|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|x64"
>
<Tool
Name="VCCustomBuildTool"
CommandLine="echo Invoking SWIG...&#x0D;&#x0A;echo on&#x0D;&#x0A;..\..\..\swig.exe -c++ -csharp &quot;$(InputPath)&quot;&#x0D;&#x0A;@echo off&#x0D;&#x0A;"
Outputs="$(InputName)_wrap.cxx"
/>
</FileConfiguration>
</File>
</Files>
<Globals>
</Globals>
</VisualStudioProject>

Some files were not shown because too many files have changed in this diff Show more