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

Merge branch 'master' into C

Browse source
This commit is contained in:
Vadim Zeitlin 2019-07-24 20:26:50 +02:00
commit 55741f9e31
1702 changed files with 57386 additions and 21599 deletions
Download patch file Download diff file Expand all files Collapse all files

23
.gitignore vendored
View file

@ -66,6 +66,7 @@ CCache/ccache_swig_config.h
CCache/config.h
CCache/config.log
CCache/config.status
CCache/config_win32.h
Examples/Makefile
Examples/d/example.mk
Examples/guile/Makefile
@ -85,6 +86,8 @@ swig.spec
# Build Artifacts
.dirstamp
CCache/ccache-swig
CCache/ccache-swig.1
CCache/web/ccache-swig-man.html
Lib/swigwarn.swg
Source/CParse/parser.c
Source/CParse/parser.h
@ -149,11 +152,24 @@ Examples/guile/*/my-guile
Examples/test-suite/java/*/
Examples/java/*/*.java
!Examples/java/*/runme.java
Examples/java/doxygen/javadocs
# Javascript
Examples/test-suite/javascript/*/
*.gyp
# OCaml
Examples/test-suite/ocaml/*.ml*
Examples/test-suite/ocaml/*.cm*
Examples/test-suite/ocaml/*_runme
!Examples/test-suite/ocaml/*runme.ml
Examples/ocaml/**/example.ml*
Examples/ocaml/**/runme
Examples/ocaml/**/runme_top
Examples/ocaml/**/*.cm*
Examples/ocaml/**/swig.ml*
Examples/ocaml/**/swigp4.ml
# Octave
swigexample*.oct
Examples/test-suite/octave/*.oct
@ -177,11 +193,16 @@ Examples/php/*/example.php
/__pycache__/
Examples/test-suite/python/*.py
!Examples/test-suite/python/*runme.py
Examples/python/*/example.py
Examples/python/**/bar.py
Examples/python/**/base.py
Examples/python/**/example.py
Examples/python/**/foo.py
Examples/python/**/robin.py
Examples/python/**/runme3.py
Examples/python/**/spam.py
Examples/python/import_packages/module_is_init/pkg1/__init__.py
Examples/python/import_packages/namespace_pkg/path4.zip
Examples/python/doxygen/example.html
# R
Examples/test-suite/r/*.R

385
.travis.yml
View file

@ -4,155 +4,404 @@ matrix:
- compiler: clang
os: linux
env: SWIGLANG=
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=
- os: linux
env: SWIGLANG= SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
sudo: required
dist: trusty
dist: xenial
- os: linux
env: SWIGLANG= SWIG_CC=gcc-6 SWIG_CXX=g++-6
env: SWIGLANG= GCC=4.4
sudo: required
dist: trusty
dist: xenial
- os: linux
env: SWIGLANG= GCC=4.6
sudo: required
dist: xenial
- os: linux
env: SWIGLANG= GCC=4.7
sudo: required
dist: xenial
- os: linux
env: SWIGLANG= GCC=4.8
sudo: required
dist: xenial
- os: linux
env: SWIGLANG= GCC=4.9
sudo: required
dist: xenial
- os: linux
env: SWIGLANG= GCC=6
sudo: required
dist: xenial
- os: linux
env: SWIGLANG= GCC=7
sudo: required
dist: xenial
- os: linux
env: SWIGLANG= GCC=8
sudo: required
dist: xenial
- os: linux
env: SWIGLANG= GCC=9
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=csharp
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=d
- compiler: gcc
os: linux
env: SWIGLANG=go
- compiler: gcc
os: linux
env: SWIGLANG=go VER=1.5
sudo: required
dist: trusty
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=go VER=1.3
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=go VER=1.8
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=go VER=1.12
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=guile
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=java
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=node
env: SWIGLANG=javascript ENGINE=node VER=0.10
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=node VER=4 CPP11=1
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=node VER=6 CPP11=1
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=node VER=8 CPP11=1
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=node VER=10 CPP11=1
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=jsc
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=v8
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=lua
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=lua VER=5.3
sudo: required
dist: trusty
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=octave SWIGJOBS=-j2 # 3.2
env: SWIGLANG=mzscheme
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=octave SWIGJOBS=-j2 VER=3.8
env: SWIGLANG=ocaml
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=octave SWIGJOBS=-j2 VER=4.0
env: SWIGLANG=octave SWIGJOBS=-j2
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=perl5
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=php
env: SWIGLANG=php VER=7.0
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python VER=2.4
env: SWIGLANG=php VER=7.1
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python VER=2.5
env: SWIGLANG=php VER=7.2
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python VER=2.6
env: SWIGLANG=php VER=7.3
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python # 2.7
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python PY3=3 # 3.2
env: SWIGLANG=python PY3=3 VER=3.2
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python PY3=3 VER=3.3
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python PY3=3 VER=3.4
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python PY3=3 VER=3.5
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin VER=2.6
env: SWIGLANG=python PY3=3 VER=3.6
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python PY3=3 VER=3.7
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3
env: SWIGLANG=python SWIG_FEATURES="-builtin -O"
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin GCC=6 CPP11=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin GCC=6 CPP11=1 PY3=3 VER=3.7
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.4
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5 SWIGOPTPY3=
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.7
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES="-builtin -O" PY3=3 VER=3.7
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.7 SWIGOPTPY3=
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-O
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-classic
env: SWIGLANG=python SWIG_FEATURES=-O PY3=3 VER=3.7
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=r
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ruby
env: SWIGLANG=ruby VER=1.9
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ruby VER=2.3.0
env: SWIGLANG=ruby VER=2.0
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ruby VER=2.1
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ruby VER=2.2
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ruby VER=2.3
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ruby VER=2.4
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ruby VER=2.5
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ruby VER=2.6
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=scilab
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=tcl
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=csharp SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
env: SWIGLANG=csharp CPP11=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=go VER=1.6 CPP11=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=java CPP11=1
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=octave SWIGJOBS=-j2 VER=4.4 CPP11=1
sudo: required
dist: trusty
- os: linux
env: SWIGLANG=java SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
env: SWIGLANG=python CPP11=1
sudo: required
dist: trusty
dist: xenial
- os: linux
env: SWIGLANG=python SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
env: SWIGLANG=r CPP11=1 # Note: making 'R CMD SHLIB' use a different compiler is non-trivial
sudo: required
dist: trusty
dist: xenial
- os: linux
env: SWIGLANG=csharp SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
env: SWIGLANG=ruby CPP11=1
sudo: required
dist: trusty
dist: xenial
- os: linux
env: SWIGLANG=java SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
env: SWIGLANG=tcl CPP11=1
sudo: required
dist: trusty
dist: xenial
- os: linux
env: SWIGLANG=python SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
env: SWIGLANG=csharp GCC=6 CPP14=1
sudo: required
dist: trusty
- os: osx
env: SWIGLANG= SWIG_CC=gcc-4.2 SWIG_CXX=g++-4.2
dist: xenial
- os: linux
env: SWIGLANG=go VER=1.6 GCC=6 CPP14=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=java GCC=6 CPP14=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=python GCC=6 CPP14=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=ruby GCC=6 CPP14=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=tcl GCC=6 CPP14=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=java GCC=7 CPP14=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=python GCC=7 CPP14=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=csharp GCC=8 CPP17=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=java GCC=8 CPP17=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=python GCC=8 CPP17=1 PY3=3 VER=3.7
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=csharp GCC=9 CPP17=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=java GCC=9 CPP17=1
sudo: required
dist: xenial
- os: linux
env: SWIGLANG=python GCC=9 CPP17=1 PY3=3 VER=3.7
sudo: required
dist: xenial
- compiler: gcc
os: osx
env: SWIGLANG=
- compiler: clang
os: osx
env: SWIGLANG=
@ -173,10 +422,10 @@ matrix:
env: SWIGLANG=lua
- compiler: clang
os: osx
env: SWIGLANG=perl5
env: SWIGLANG=octave SWIGJOBS=-j2
- compiler: clang
os: osx
env: SWIGLANG=php
env: SWIGLANG=perl5
- compiler: clang
os: osx
env: SWIGLANG=python
@ -189,35 +438,54 @@ matrix:
- compiler: clang
os: osx
env: SWIGLANG=tcl
- compiler: clang
os: osx
env: SWIGLANG=java CPP17=1
osx_image: xcode10.2
- compiler: clang
os: osx
env: SWIGLANG=python PY3=3 CPP17=1
osx_image: xcode10.2
allow_failures:
# Lots of failing tests currently
# seg fault in director_basic testcase
- compiler: gcc
os: linux
env: SWIGLANG=php VER=7.2
sudo: required
dist: xenial
# Sometimes hits the Travis 50 minute time limit
- compiler: clang
os: osx
env: SWIGLANG=octave SWIGJOBS=-j2
# Experimental languages
- compiler: gcc
os: linux
env: SWIGLANG=mzscheme
sudo: required
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ocaml
# Not quite working yet
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-O
sudo: required
dist: xenial
before_install:
- date -u
- uname -a
- if test "$TRAVIS_OS_NAME" = "linux"; then lscpu && cat /proc/cpuinfo | grep "model name" && cat /proc/meminfo | grep MemTotal; fi
- if test "$TRAVIS_OS_NAME" = "osx"; then sysctl -a | grep brand_string; fi
# Travis overrides CC environment with compiler predefined values
- if test -n "$SWIG_CC"; then export CC="$SWIG_CC"; fi
- if test -n "$SWIG_CXX"; then export CXX="$SWIG_CXX"; fi
# Travis overrides CC environment with compiler predefined values
- if test -n "$GCC"; then export CC="gcc-$GCC" && export CXX="g++-$GCC"; fi
install:
- if test "$TRAVIS_OS_NAME" = "linux"; then source Tools/travis-linux-install.sh; fi
- if test "$TRAVIS_OS_NAME" = "osx"; then source Tools/travis-osx-install.sh; fi
- if test -n "$CPP11"; then CONFIGOPTS+=(--enable-cpp11-testing --without-maximum-compile-warnings "CXXFLAGS=-std=c++11 -Wall -Wextra" "CFLAGS=-std=c11 -Wall -Wextra") && export CSTD=c11 && export CPPSTD=c++11; fi
- if test -n "$CPP14"; then CONFIGOPTS+=(--enable-cpp11-testing --without-maximum-compile-warnings "CXXFLAGS=-std=c++14 -Wall -Wextra" "CFLAGS=-std=c11 -Wall -Wextra") && export CSTD=c11 && export CPPSTD=c++14; fi
- ls -la $(which $CC)
- ls -la $(which $CXX)
- $CC --version
- $CXX --version
- ls -la $(which $CC) $(which $CXX) && $CC --version && $CXX --version
script:
- echo 'Configuring...' && echo -en 'travis_fold:start:script.1\\r'
- if test -n "$CPP11"; then CONFIGOPTS+=(--enable-cpp11-testing --without-maximum-compile-warnings "CXXFLAGS=-std=c++11 -Wall -Wextra" "CFLAGS=-std=c11 -Wall -Wextra") && export CSTD=c11 && export CPPSTD=c++11; fi
- if test -n "$CPP14"; then CONFIGOPTS+=(--enable-cpp11-testing --without-maximum-compile-warnings "CXXFLAGS=-std=c++14 -Wall -Wextra" "CFLAGS=-std=c11 -Wall -Wextra") && export CSTD=c11 && export CPPSTD=c++14; fi
- if test -n "$CPP17"; then CONFIGOPTS+=(--enable-cpp11-testing --without-maximum-compile-warnings "CXXFLAGS=-std=c++17 -Wall -Wextra" "CFLAGS=-std=c17 -Wall -Wextra") && export CSTD=c17 && export CPPSTD=c++17; fi
- if test -n "$SWIGLANG"; then CONFIGOPTS+=(--without-alllang --with-$WITHLANG); fi
- echo "${CONFIGOPTS[@]}"
- ./autogen.sh && mkdir -p build/build && cd build/build && ../../configure "${CONFIGOPTS[@]}"
@ -239,6 +507,3 @@ script:
- 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

20
ANNOUNCE
View file

@ -1,8 +1,8 @@
*** ANNOUNCE: SWIG 3.0.11 (in progress) ***
*** ANNOUNCE: SWIG 4.0.1 (in progress) ***
http://www.swig.org
We're pleased to announce SWIG-3.0.11, the latest SWIG release.
We're pleased to announce SWIG-4.0.1, the latest SWIG release.
What is SWIG?
=============
@ -10,13 +10,11 @@ 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, Javascript, Lua, Scheme (Guile, MzScheme, CHICKEN),
D, Ocaml, Pike, Modula-3, Octave, R, Scilab, 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.
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D,
Ocaml, Octave, R, Scilab. SWIG can also export its parse tree in
the form of XML. Major applications of SWIG include generation of
scripting language extension modules, rapid prototyping, testing,
and user interface development for large C/C++ systems.
Release Notes
=============
@ -27,11 +25,11 @@ Availability
============
The release is available for download on Sourceforge at
http://prdownloads.sourceforge.net/swig/swig-3.0.11.tar.gz
http://prdownloads.sourceforge.net/swig/swig-4.0.1.tar.gz
A Windows version is also available at
http://prdownloads.sourceforge.net/swig/swigwin-3.0.11.zip
http://prdownloads.sourceforge.net/swig/swigwin-4.0.1.zip
Please report problems with this release to the swig-devel mailing list,
details at http://www.swig.org/mail.html.

35
CCache/Makefile.in
View file

@ -8,6 +8,7 @@ bindir=@bindir@
mandir=@mandir@
INSTALLCMD=@INSTALL@
PACKAGE_NAME=@PACKAGE_NAME@
PROGRAM_NAME=@PROGRAM_NAME@
# Soft link test can be skipped on systems that don't support soft linking
NOSOFTLINKSTEST=
@ -17,13 +18,10 @@ SWIG=swig
SWIG_LIB=../$(srcdir)/../Lib
EXEEXT=@EXEEXT@
# Use standard autoconf approach to transform executable name using --program-prefix and --program-suffix
transform = @program_transform_name@
LIBS= @LIBS@
OBJS= ccache.o mdfour.o hash.o execute.o util.o args.o stats.o \
cleanup.o snprintf.o unify.o
HEADERS = ccache.h mdfour.h
HEADERS = ccache.h mdfour.h config.h config_win32.h
all: $(PACKAGE_NAME)$(EXEEXT)
@ -32,7 +30,7 @@ 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: $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/ccache-man.html
docs: $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/$(PACKAGE_NAME)-man.html
$(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
@ -40,40 +38,43 @@ $(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
$(srcdir)/$(PACKAGE_NAME).1: $(srcdir)/ccache.yo
-yodl2man -o $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/ccache.yo
$(srcdir)/web/ccache-man.html: $(srcdir)/ccache.yo
yodl2html -o $(srcdir)/web/ccache-man.html $(srcdir)/ccache.yo
$(srcdir)/web/$(PACKAGE_NAME)-man.html: $(srcdir)/ccache.yo
yodl2html -o $(srcdir)/web/$(PACKAGE_NAME)-man.html $(srcdir)/ccache.yo
install: $(PACKAGE_NAME)$(EXEEXT)
@echo "Installing $(PACKAGE_NAME)"
@echo "Installing $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)"
@echo "Installing $(DESTDIR)${bindir}/$(PROGRAM_NAME)$(EXEEXT)"
${INSTALLCMD} -d $(DESTDIR)${bindir}
${INSTALLCMD} -m 755 $(PACKAGE_NAME)$(EXEEXT) $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
${INSTALLCMD} -m 755 $(PACKAGE_NAME)$(EXEEXT) $(DESTDIR)${bindir}/$(PROGRAM_NAME)$(EXEEXT)
install-docs: $(srcdir)/$(PACKAGE_NAME).1
@echo "Installing $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1"
@echo "Installing $(DESTDIR)${mandir}/man1/$(PROGRAM_NAME).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/$(PROGRAM_NAME).1
uninstall: $(PACKAGE_NAME)$(EXEEXT)
rm -f $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
rm -f $(DESTDIR)${bindir}/$(PROGRAM_NAME)$(EXEEXT)
uninstall-docs: $(srcdir)/$(PACKAGE_NAME).1
rm -f $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
rm -f $(DESTDIR)${mandir}/man1/$(PROGRAM_NAME).1
clean:
clean: clean-docs
/bin/rm -f $(OBJS) *~ $(PACKAGE_NAME)$(EXEEXT)
clean-docs:
rm -f $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/$(PACKAGE_NAME)-man.html
test: test.sh
SWIG_LIB='$(SWIG_LIB)' PATH=../..:$$PATH SWIG='$(SWIG)' CC='$(CC)' NOSOFTLINKSTEST='$(NOSOFTLINKSTEST)' $(srcdir)/test.sh
SWIG_LIB='$(SWIG_LIB)' PATH=../..:$$PATH SWIG='$(SWIG)' CC='$(CC)' NOSOFTLINKSTEST='$(NOSOFTLINKSTEST)' CCACHE='../$(PACKAGE_NAME)' CCACHE_PROG=$(PROGRAM_NAME) $(srcdir)/test.sh
check: test
distclean: clean
/bin/rm -f Makefile config.h config.sub config.log build-stamp config.status ccache_swig_config.h
/bin/rm -f Makefile config.h config.sub config.log build-stamp config.status ccache_swig_config.h config_win32.h
/bin/rm -rf autom4te.cache
maintainer-clean: distclean
/bin/rm -f $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/ccache-man.html
/bin/rm -f $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/$(PACKAGE_NAME)-man.html
# FIXME: To fix this, test.sh needs to be able to take ccache from the

4
CCache/ccache.h
View file

@ -6,7 +6,7 @@
#include "config.h"
#else
#include <sys/locking.h>
#define PACKAGE_NAME "ccache-swig.exe"
#include "config_win32.h"
#endif
#include <stdio.h>
@ -51,7 +51,7 @@
#define STATUS_FATAL 4
#define STATUS_NOCACHE 5
#define MYNAME PACKAGE_NAME
#define MYNAME PROGRAM_NAME
#define LIMIT_MULTIPLE 0.8

3
CCache/config_win32.h.in Normal file
View file

@ -0,0 +1,3 @@
#if !defined(PROGRAM_NAME)
#define PROGRAM_NAME "@PROGRAM_NAME@.exe"
#endif

15
CCache/configure.ac
View file

@ -7,6 +7,7 @@ AC_CONFIG_SRCDIR([ccache.h])
AC_MSG_NOTICE([Configuring ccache])
AC_CONFIG_HEADER(config.h)
AC_CONFIG_FILES([config_win32.h])
dnl Checks for programs.
AC_PROG_CC
@ -14,6 +15,20 @@ AC_PROG_CPP
AC_PROG_INSTALL
AC_ARG_PROGRAM # for program_transform_name
AC_SUBST(PROGRAM_NAME)
if test "x$program_prefix" != "xNONE" -a "x$program_prefix" != "x"
then
PROGRAM_NAME="$program_prefix$PACKAGE_NAME"
else
PROGRAM_NAME="$PACKAGE_NAME"
fi
if test "x$program_suffix" != "xNONE" -a "x$program_suffix" != "x"
then
PROGRAM_NAME="$PROGRAM_NAME$program_suffix"
fi
AC_DEFINE_UNQUOTED(PROGRAM_NAME, "$PROGRAM_NAME", [Define my program name])
AC_DEFINE([_GNU_SOURCE], 1,
[Define _GNU_SOURCE so that we get all necessary prototypes])

3
CCache/snprintf.c
View file

@ -292,6 +292,7 @@ static size_t dopr(char *buffer, size_t maxlen, const char *format, va_list args
break;
case 'X':
flags |= DP_F_UP;
/* FALLTHROUGH */
case 'x':
flags |= DP_F_UNSIGNED;
if (cflags == DP_C_SHORT)
@ -314,6 +315,7 @@ static size_t dopr(char *buffer, size_t maxlen, const char *format, va_list args
break;
case 'E':
flags |= DP_F_UP;
/* FALLTHROUGH */
case 'e':
if (cflags == DP_C_LDOUBLE)
fvalue = va_arg (args, LDOUBLE);
@ -322,6 +324,7 @@ static size_t dopr(char *buffer, size_t maxlen, const char *format, va_list args
break;
case 'G':
flags |= DP_F_UP;
/* FALLTHROUGH */
case 'g':
if (cflags == DP_C_LDOUBLE)
fvalue = va_arg (args, LDOUBLE);

25
CCache/test.sh
View file

@ -20,7 +20,12 @@ fi
PATH="`echo $PATH | \
sed -e 's!:/usr\(/local\)*/lib\([0-9]\)*/ccache\(/\)*!!g'`"
CCACHE=../ccache-swig
if test -n "$CCACHE"; then
CCACHE="$CCACHE"
else
CCACHE=../ccache-swig
fi
TESTDIR=test.$$
test_failed() {
@ -406,6 +411,10 @@ swigtests() {
# main program
rm -rf $TESTDIR
mkdir $TESTDIR
if test -n "$CCACHE_PROG"; then
ln -s $CCACHE $TESTDIR/$CCACHE_PROG
CCACHE=./$CCACHE_PROG
fi
cd $TESTDIR || exit 1
unset CCACHE_DIR
@ -442,14 +451,16 @@ swigtests
if test -z "$NOSOFTLINKSTEST"; then
testsuite="link"
ln -s $CCACHE $COMPILER
CCACHE_COMPILE="./$COMPILER"
compilername=`basename $COMPILER`
ln -s $CCACHE ./$compilername
CCACHE_COMPILE="./$compilername"
basetests
rm "./$COMPILER"
ln -s $CCACHE $SWIG
CCACHE_COMPILE="./$SWIG"
rm "./$compilername"
compilername=`basename $SWIG`
ln -s $CCACHE ./$compilername
CCACHE_COMPILE="./$compilername"
swigtests
rm "./$SWIG"
rm "./$compilername"
else
echo "skipping testsuite link"
fi

1989
CHANGES
View file

File diff suppressed because it is too large Load diff

145
CHANGES.current
View file

@ -1,97 +1,72 @@
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.
Issue # numbers mentioned below can be found on Github. For more details, add
the issue number to the end of the URL: https://github.com/swig/swig/issues/
Version 3.0.11 (in progress)
============================
Version 4.0.1 (in progress)
===========================
2016-09-12: xypron
[C#] Patch #786 Keyword rename to be CLS compliant by adding an underscore
suffix instead of an underscore suffix to the C symbol name. Please use an explicit
%rename to rename the symbol with a _ prefix if you want the old symbol name.
2019-07-23: smithx
[C#] #1530 #1532 Fix marshalling of std::wstring to C#.
2019-07-18: gicmo
[Python] #1587 Python 3.8 support - remove use of deprecated PyObject_GC_UnTrack.
2019-07-18: cher-nov
[Python] #1573 Generated Python code uses consistent string quoting style - double
quotes.
2019-07-16: geefr
[C#] #616 #1576 Fix C# bool INPUT[], bool OUTPUT[], bool INOUT[] typemaps to marshall
as 1-byte.
2019-07-12: vadz
[C#, Java] #1568 #1583 Fix std::set<> typemaps for primitive types.
2019-07-12: vadz
#1566 #1584 Regression in 4.0.0 - fix missing value for first item of enums with
trailing comma.
2019-07-11: mcfarljm
#1548 #1578 Fix segfault in Doxygen parser parsing empty lines in some commands like
\code.
2019-07-09: IsaacPascual
[C#, Java] #1570 Fix name of generated C#/Java classes for %interface macros
in swiginterface.i when wrapping nested C++ classes.
2019-07-05: wsfulton
[Python] #1547 Whitespace fixes in Doxygen translated comments into pydoc comments
for Sphinx compatibility.
2019-06-28: wsfulton
[MzScheme, OCaml] #1559 $arg and $input were incorrectly substituted in the
argout typemap when two or more arguments were present.
2019-06-24: wsfulton
[Python, Ruby] #1538 Remove the UnknownExceptionHandler class in order to be
C++17 compliant as it uses std::unexpected_handler which was removed in C++17.
This class was intended for director exception handling but was never used by
SWIG and was never documented.
*** POTENTIAL INCOMPATIBILITY ***
2016-09-09: olly
[Python] Fix import handling for Python 2.6 to work in a frozen
application. Fixes #145, reported by Thomas Kluyver.
2019-06-06: bkotzz
[Java] #1552 Improve performance in Java std::vector constructor wrapper that takes
a native Java array as input.
2016-09-02: smarchetto
[Scilab] Pointers are mapped to mlist instead of tlist
(mlist better for scilab overloading)
2019-06-03: olly
[Python] Fix regression in implicit_conv handling of tuples,
introduced in SWIG 4.0.0. Fixes #1553, reported by Alexandre
Duret-Lutz.
2016-09-02: olly
[PHP] Fix "out" typemap for member function pointers and "in"
typemap for char INPUT[ANY].
2019-05-24: wsfulton
[Octave] Fix detection of Octave on MacOS.
2016-09-01: wsfulton
[Python] More efficient Python slicing.
Call reserve for container types that support it to avoid repeated
memory reallocations for new slices or slices that grow in size.
2019-05-24: opoplawski
[Octave] #1522 Adapt OCTAVE_LDFLAGS for Octave 5.1.
2016-09-01: wsfulton
[Python] #771 - Make builtin types hashable by default.
Default hash is the underlying C/C++ pointer. This matches up with testing for
equivalence (Py_EQ in SwigPyObject_richcompare) which compares the pointers.
2016-08-22: wsfulton
[Python] The following builtin slots can be customized like other slots via the
"python:<x>" and "python:slot" features where <x> is the appropriate slot name:
tp_allocs
tp_bases
tp_basicsize
tp_cache
tp_del
tp_dealloc
tp_flags
tp_frees
tp_getset
tp_is_gc
tp_maxalloc
tp_methods
tp_mro
tp_new
tp_next
tp_prev
tp_richcompare
tp_subclasses
tp_weaklist
was_sq_ass_slice
was_sq_slice
A few documentation improvements for slot customization.
2016-08-09: joequant
[R] Patch #765 Fix extern "C" header includes for C++ code.
2016-08-05: olly
[xml] Fix how the output filename is built to avoid problems when
it contains the embedded strings ".c", ".cpp" or ".cxx".
Fixes #540 reported by djack42.
2016-07-01: wsfulton
Fix corner case of wrapping std::vector of T pointers where a pointer to a pointer of T
also exists in the wrapped code. SF Bug 2359417 (967).
2016-06-26: wkalinin
[Java, C#] Patch #681 Fix seg fault when ignoring nested classes.
2016-06-25: mromberg
[Python] #711 Fix -castmode and conversion of signed and unsigned integer types.
See 2015-12-23 CHANGES entry for details of these improvements when they were
implemented for the default options (ie not using -castmode).
2016-06-25: ahnolds
Patch #730 - Fix %implicitconv for overloaded functions when using
-castmode or -fastdispatch options.
The result is that in all overload cases where there are multiple possibilities
with the same number of arguments, the dispatch function will first check for
exact (aka non implicit) matches, and then subsequently check for implicit
casting matches. This was already happening in the normal dispatch situation,
and in the -fastdispatch case two passes through the candidates were happening,
just with SWIG_POINTER_IMPLICIT_CONV always set. After this patch, it is not set
on the first pass, and then set on the second pass.
2016-06-25: liorgold
Patch #727 - Add support for C++11 type aliasing.
2019-05-22: ferdynator
[PHP] #1528 Don't add a closing '?>' PHP tag to generated files.
PSR-2 says it MUST be omitted for files containing only PHP.

6
COPYRIGHT
View file

@ -20,6 +20,7 @@ Active SWIG Developers:
Oliver Buchtala (oliver.buchtala@gmail.com) (Javascript)
Neha Narang (narangneha03@gmail.com) (Javascript)
Simon Marchetto (simon.marchetto@scilab-enterprises.com) (Scilab)
Zackery Spytz (zspytz@gmail.com) (OCaml, SWIG core)
Past SWIG developers and major contributors include:
Dave Beazley (dave-swig@dabeaz.com) (SWIG core, Python, Tcl, Perl)
@ -29,7 +30,7 @@ Past SWIG developers and major contributors include:
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)
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)
@ -63,7 +64,8 @@ Past SWIG developers and major contributors include:
John Lenz (Guile, MzScheme updates, Chicken module, runtime system)
Baozeng Ding <sploving1@163.com> (Scilab)
Ian Lance Taylor (Go)
Vadim Zeitlin (PCRE, Python)
Dmitry Kabak (userdima@gmail.com) (Doxygen)
Vadim Zeitlin (PCRE, Python, Doxygen)
Stefan Zager (szager@gmail.com) (Python)
Vincent Couvert (Scilab)
Sylvestre Ledru (Scilab)

788
Doc/Devel/cpp11.html
View file

@ -1,788 +0,0 @@
<!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>

341
Doc/Devel/plan-gsoc-2012.txt Normal file
View file

@ -0,0 +1,341 @@
Project Plan
============
SWIG Code Comments
Google Summer of Code 2012
This document describes goals for the Google Summer of Code 2012,
SWIG code documentation project.
Author: Marko Klopcic, Dmitry Kabak
Introduction
============
The goal of this project is _not_ to translate _any_ possible Doxygen
formatted comment to JavaDoc or PyDoc, but to make it possible to
translate a subset of comment types in C/C++ code to
JavaDoc and PyDoc. Covering all the Doxygen functionality would be to
complex for the limited time. However, the code must be flexible so
that implementing missing features would not require redesign of the
comment handling code in SWIG.
There will also be a possibility to add untranslated comments to Java
and Python code (## comments, see Doxygen manual), if the user will
prefer to use Doxygen on the generated code.
Note:
'-OK-' tick below means that the item is implemented, committed and
working.
Abbreviations:
JD - JavaDoc
PD - PyDoc
Functionality
=============
Types of comments
-----------------
Note:
See 'http://www.stack.nl/~dimitri/doxygen/docblocks.html' for
the detailed description of Doxygen syntax and terms used in this
section.
1. -OK- Only JavaDoc (/** */) and Qt (/*! */) styles of comment blocks
will be supported by SWIG translator.
2. -OK- The following doc after members will be supported:
int var; ///< Detailed description after the member
//!<
int var; //!< Brief description after the member
int var; ///< Brief description after the member
3. -OK- Only comments before or after declaration/definition will be
supported. Comments with structural commands will be ignored
(warning will be written). (What about writing them to
'package.info.java' for JD?)
Tags
----
This section contains all doxygen tags taken from
http://www.stack.nl/~dimitri/doxygen/commands.html. If a tag is
marked as 'ignored', then the tag is ignored, but the text is copied
to the destination documentation. 'Not implemented' means that the
tag with it's contents is stripped out of the output.
Doxygen tags:
All tags: -OK-
\a - translated to <i></i> in JD, surrounded with _ in PD
\addindex - ignored
\addtogroup - ignored
\anchor - ignored, not supported by JD and PD
\arg - equivalent to \li
\attention - ignored
\authors, \author - translated to @author in JD, 'Author:' in PD
\b - <b></b> in JD, surrounded with __ in PD
\brief - ignored
\bug - ignored
\c - translated to <code></code> in JD, ignored in PD
\callgraph - ignored, not supported by JD and PD
\callergraph - ignored, not supported by JD and PD
\category - ignored, used only in Objective C
\cite - translated to <i></i> in JD, single quotes in PD
\class - ignored (structural command)
\code - translated to {@code ...} in JD, ignored in PD
\cond - translated to 'Conditional comment: <condition>'. Later
SWIG may support definitions of conditions in config file.
\copybrief - ignored. Later SWIG may support this command by
performing copy
\copydetails - ignored. Later SWIG may support this command by
performing copy
\copydoc - ignored. Later SWIG may support this command by
performing copy
\copyright - replaced with text 'Copyright' in PD and PD
\date - ignored
\def - ignored (structural command)
\defgroup - not supported
\deprecated - translated to @deprecated in JD, 'Deprecated:' in PD
\details - ignored
\dir - not supported
\dontinclude - not supported
\dot - not supported. Later SWIG may call dot and produce the graph image
to include in JD and PD
\dotfile - see note for \dot
\e - equivalent \a
\else - see note for \cond
\elseif - see note for \cond
\em - equivalent to \a
\endcode - see note for \code
\endcond - translated to 'End of conditional comment: <condition>'. Later
SWIG may support definitions of conditions in config file.
\enddot - see note for \dot
\endhtmlonly - ignored
\endif - see note for \cond
\endinternal - ignored
\endlatexonly - ignored
\endlink - see note for \link
\endmanonly - ignored
\endmsc - see note for \msc
\endrtfonly - ignored
\endverbatim - see note for \verbatim
\endxmlonly - ignored
\enum - ignored (structural command)
\example - translated to 'Example:' in JD and PD
\exception - equivalent to throws, but translates to @exception in JD
\extends - not supported
\f$ - ignored. Later swig may call LATeX to produce bitmaps with formulas
to include in JD and PD
\f[ - see note for \f$
\f] - see note for \f$
\f{ - see note for \f$
\f} - see note for \f$
\file - ignored (structural command)
\fn - ignored (structural command)
\headerfile - not supported
\hideinitializer - not supported
\htmlinclude - not supported
\htmlonly - ignored
\if - see note for \cond
\ifnot - see note for \cond
\image - translated to <img/> in JD only when target=HTML, translated to
'Image: filename(Title)'
\implements - not supported
\include - not supported
\includelineno - not supported
\ingroup - not supported. Later swig may print group names as plain text
in comments like 'Code group: something' in both JD and PD
\internal - ignored
\invariant - ignored
\interface - ignored (structural command)
\latexonly - ignored
\li - trabslated to <li></li> in JD, ignored in PD
\line - not supported
\link - translated to {@link ...} in JD, ignored in PD
\mainpage - ignored
\manonly - ignored
\memberof - not supported
\msc - not supported. Later SWIG may call dot and produce the graph image
to include in JD and PD
\mscfile - see note for \msc
\n - prints the new line
\name - ignored
\namespace - included in package-info.java if nspace feature is enabled,
otherwise ignored, ignored in PD
\nosubgrouping - ignored
\note - translated to 'Note:' in both JD and PD
\overload - prints 'This is an overloaded member function, provided for
convenience. It differs from the above function only in what
argument(s) it accepts.' to the output in both JD and PD
\p - equivalent to \c
\package - is kept same in JD (it is already a JD tag), ignored in PD
\page - ignored
\par - translated to <p alt='title'></p> in JD, 'Title: ...' in PD
\paragraph - ignored
\param - translated to @param in JD, special formatting in PD
\post - ignored
\pre - ignored
\private - ignored
\privatesection - ignored
\property - ignored
\protected - ignored
\protectedsection - ignored
\protocol - ignored (Objective-C tag)
\public - ignored
\publicsection - ignored
\ref - ignored, not supported by JD and PD
\related - ignored
\relates - ignored
\relatedalso - ignored
\relatesalso - ignored
\remark - translated to 'Remarks:' in both JD and PD
\remarks - equivalent to remark
\result - translated to @return in JD, 'Return:' in PD
\return - equivalent to result
\returns - equivalent to result
\retval - ignored
\rtfonly - ignored
\sa - translated to @see in JD, 'See also:' in PD
\section - not supported
\see - equivalent to \sa
\short - equivalent to \brief
\showinitializer - not supported
\since - translated to @since in JD, 'Since:' in PD
\skip - not supported
\skipline - not supported
\snippet - not supported
\struct - ignored (structural command)
\subpage - not supported
\subsection - not supported
\subsubsection - not supported
\tableofcontents - not supported
\test - ignored
\throw - translated to @throws in JD, 'Throws:' in PD
\throws - equivalent to \throw
\todo - translated to 'TODO:' in both JD and PD
\tparam - similar to \arg
\typedef - ignored (structural command)
\union - ignored (structural command)
\until - not supported
\var - ignored (structural command)
\verbatim - translated to {@literal ...} in JD, ignored in PD
\verbinclude - ignored
\version - translated to @version in JD, 'Version:' in PD
\warning - translated to 'Warning:' in both JD and PD
\weakgroup - not supported
\xmlonly - ignored
\xrefitem - ignored
\$ - this and all the others below: these commands insert single char,
it is escaped as HTML char in JD, kept as-is in PD
\@
\\
\&
\~
\<
\>
\#
\%
\"
\.
\::
Optional functionality
======================
That section describes some complex cases where the current code
does not behave really well. Like a short to-do list of special cases.
-OK- When translating functions with default parameters in swig to
java, it creates overloaded functions with all the parameters
except the default ones. We need to copy the doxygen comment to
such functions and correct the list of @param tags.
-OK- In doxygen there is a special tags (and even a special option)
to create links to some code members from the current comment.
Sometimes it needs a type of parameters specified because of the
overloaded functions. And the same linking tags are supported in JD,
but it has a completely different typesystem, so we need to translate
the types of function parameters in comments also. For example:
{@link MyClass#doSomething(const std::string &)}
does not make sense in Java, so the type should be converted.
{@link MyClass#doSomething(String)}
Tests
=====
The following test cases will be implemented:
-OK- Class comments.
-OK- Struct comments.
-OK- Enum comments.
-OK- Function comments.
-OK- Var comments.
-OK- Class attributes, comment before and after declaration.
-OK- Class methods, comment of parameters in function
comment.
-OK- Class methods, comment of parameters
after parameter declaration.
-OK- Struct attributes, comment before and after declaration.
-OK- Struct methods, comment of parameters in function
comment.
-OK- Struct methods, comment of parameters
after parameter declaration.
-OK- Enum items JD and Qt style, comment before items
-OK- Enum items JD and Qt style, comment after items
-OK- Class comment, with all supported tags.
-OK- Class comment, with all doxygen tags, including
ignored ones.
The list of all tests, in form of shell commands to make it simple
to test project by copying the text below into terminal program.
make doxygen_parsing.cpptest -s
make doxygen_translate.cpptest -s
make doxygen_translate_all_tags.cpptest -s
make doxygen_basic_translate.cpptest -s
make doxygen_basic_notranslate.cpptest -s
make doxygen_translate_links.cpptest -s
make doxygen_tricky_constructs.cpptest -s
Refactoring
===========
All the code in directory _Doxygen_ should be refactored:
-OK- all methods should be class members
-OK- most static methods should be normal members
-OK- replace C arrays of strings and sequential searches with STL data
structures and algorithms.
-OK- use singletons instead of class instantiaion for each comment found.
Documentation
=============
SWIG documentation will contain:
-OK- command line options
-OK- list of implemented features (types and placements of comments)
-OK- list of unimplemented features (types and placements of comments)
-OK- list of tags and their translations (all Doxygen tags).
-OK- some amount of debugging and development information

4
Doc/Devel/runtime.txt
View file

@ -57,7 +57,7 @@ Alternatively, if the language supports modules, a module named
named "type_table" SWIG_TYPE_TABLE_NAME can be created inside it. The most
common approach is to store the mod pointer in some global variable in the
target language, but if the language provides an alternative place to store data
(like the chicken module), then that is good too.
then that is good too.
The way the code is set up, SetModule should only be called when GetModule
returns NULL, and if SetModule is called a second time, the behavior is
@ -105,7 +105,7 @@ Standard Functions
These functions are not required and their API is not formalized, but almost all
language modules implement them for consistency across languages. Throughout
this discussion, I will use LangType to represent the underlying language type
(C_word in chicken, Scheme_Object * in mzscheme, PyObject * in python, etc)
(Scheme_Object * in mzscheme, PyObject * in python, etc)

2
Doc/Devel/tree.html
View file

@ -236,7 +236,7 @@ The following functions can be used to help debug SWIG parse trees.
<blockquote>
Prints the tag-structure of the parse tree to standard output. <tt>node</tt> is the top-level parse tree node. <tt>prefix</tt> is
a string prefix thats added to the start of each line. Normally, you would specify the empty string or NIL for <tt>prefix</tt>.
a string prefix that's added to the start of each line. Normally, you would specify the empty string or NIL for <tt>prefix</tt>.
This function is called by the <tt>-debug-tags</tt> option to SWIG.
<pre>

314
Doc/Manual/Allegrocl.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Allegrocl">18 SWIG and Allegro Common Lisp</a></H1>
<H1><a name="Allegrocl">20 SWIG and Allegro Common Lisp</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -129,16 +129,16 @@ It is significant to note that, while this is a vendor-specific
module, we would like to acknowledge the current and ongoing
work by developers in the open source lisp community that are
working on similar interfaces to implementation-independent
foreign function interfaces (UFFI or CFFI, for example). Such
foreign function interfaces (CFFI, for example). Such
work can only benefit the lisp community, and we would not
be unhappy to see some enterprising folk use this work to add
to it.
</p>
<H2><a name="Allegrocl_nn2">18.1 Basics</a></H2>
<H2><a name="Allegrocl_nn2">20.1 Basics</a></H2>
<H3><a name="Allegrocl_nn3">18.1.1 Running SWIG</a></H3>
<H3><a name="Allegrocl_nn3">20.1.1 Running SWIG</a></H3>
<p>
@ -155,7 +155,7 @@ SWIG directives. SWIG can be furnished with a header file, but an
interface can also be generated without library headers by supplying a
simple text file--called the interface file, which is typically named
with a <tt>.i</tt> extension--containing any foreign declarations of
identifiers you wish to use. The most common approach is to use a an
identifiers you wish to use. The most common approach is to use an
interface file with directives to parse the needed headers. A straight
parse of library headers will result in usable code, but SWIG
directives provides much freedom in how a user might tailor the
@ -280,39 +280,39 @@ actual function.
<div class="code">example_wrap.i
<pre>
... lots of SWIG internals ...
... lots of SWIG internals ...
EXPORT int ACL___fact__SWIG_0 (char *larg1) {
int lresult = (int)0 ;
char *arg1 = (char *) 0 ;
int result;
arg1 = larg1;
try {
result = (int)fact(arg1);
lresult = result;
return lresult;
} catch (...) {
return (int)0;
}
int lresult = (int)0 ;
char *arg1 = (char *) 0 ;
int result;
arg1 = larg1;
try {
result = (int)fact(arg1);
lresult = result;
return lresult;
} catch (...) {
return (int)0;
}
}
EXPORT int ACL___fact__SWIG_1 (int larg1) {
int lresult = (int)0 ;
int arg1 ;
int result;
arg1 = larg1;
try {
result = (int)fact(arg1);
lresult = result;
return lresult;
} catch (...) {
return (int)0;
}
int lresult = (int)0 ;
int arg1 ;
int result;
arg1 = larg1;
try {
result = (int)fact(arg1);
lresult = result;
return lresult;
} catch (...) {
return (int)0;
}
}
</pre>
</div>
@ -324,7 +324,7 @@ what is generated when parsing C code:
<div class="targetlang">
<pre>
...
...
(swig-in-package ())
@ -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">18.1.2 Command Line Options</a></H3>
<H3><a name="Allegrocl_nn4">20.1.2 Command Line Options</a></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">18.1.3 Inserting user code into generated files</a></H3>
<H3><a name="Allegrocl_nn5">20.1.3 Inserting user code into generated files</a></H3>
<p>
@ -436,7 +436,7 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
</p>
<H2><a name="Allegrocl_nn6">18.2 Wrapping Overview</a></H2>
<H2><a name="Allegrocl_nn6">20.2 Wrapping Overview</a></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">18.2.1 Function Wrapping</a></H3>
<H3><a name="Allegrocl_nn7">20.2.1 Function Wrapping</a></H3>
<p>
@ -499,7 +499,7 @@ interested in generating an interface to C++.
</pre>
</div>
<H3><a name="Allegrocl_nn8">18.2.2 Foreign Wrappers</a></H3>
<H3><a name="Allegrocl_nn8">20.2.2 Foreign Wrappers</a></H3>
<p>
@ -512,7 +512,7 @@ interested in generating an interface to C++.
typemap.
</p>
<H3><a name="Allegrocl_nn9">18.2.3 FFI Wrappers</a></H3>
<H3><a name="Allegrocl_nn9">20.2.3 FFI Wrappers</a></H3>
<p>
@ -526,8 +526,8 @@ interested in generating an interface to C++.
<pre>
%module ffargs
%ffargs(strings_convert="nil",call_direct="t") foo;
%ffargs(strings_convert="nil",release_heap=":never",optimize_for_space="t") bar;
%ffargs(strings_convert="nil", call_direct="t") foo;
%ffargs(strings_convert="nil", release_heap=":never", optimize_for_space="t") bar;
int foo(float f1, float f2);
int foo(float f1, char c2);
@ -593,7 +593,7 @@ char *xxx();
ff:def-foreign-call's.
</p>
<H3><a name="Allegrocl_nn10">18.2.4 Non-overloaded Defuns</a></H3>
<H3><a name="Allegrocl_nn10">20.2.4 Non-overloaded Defuns</a></H3>
<p>
@ -606,11 +606,11 @@ char *xxx();
this function can be manipulated via the <tt>lout</tt> typemap.
</p>
<H3><a name="Allegrocl_nn11">18.2.5 Overloaded Defuns</a></H3>
<H3><a name="Allegrocl_nn11">20.2.5 Overloaded Defuns</a></H3>
<p>
In the case of overloaded functions, mulitple layers are
In the case of overloaded functions, multiple layers are
generated. First, all the overloads for a given name are separated
out into groups based on arity, and are wrapped in
defmethods. Each method calls a distinct wrapper function, but are
@ -622,7 +622,7 @@ char *xxx();
can be manipulated via the <tt>lout</tt> typemap.
</p>
<H3><a name="Allegrocl_nn12">18.2.6 What about constant and variable access?</a></H3>
<H3><a name="Allegrocl_nn12">20.2.6 What about constant and variable access?</a></H3>
<p>
@ -635,7 +635,7 @@ char *xxx();
into the foreign module.
</p>
<H3><a name="Allegrocl_nn13">18.2.7 Object Wrapping</a></H3>
<H3><a name="Allegrocl_nn13">20.2.7 Object Wrapping</a></H3>
<p>
@ -657,7 +657,7 @@ char *xxx();
foreign function interface.
</p>
<H2><a name="Allegrocl_nn14">18.3 Wrapping Details</a></H2>
<H2><a name="Allegrocl_nn14">20.3 Wrapping Details</a></H2>
<p>
@ -665,7 +665,7 @@ char *xxx();
translated into lisp.
</p>
<H3><a name="Allegrocl_nn15">18.3.1 Namespaces</a></H3>
<H3><a name="Allegrocl_nn15">20.3.1 Namespaces</a></H3>
<p>
@ -688,10 +688,10 @@ char *xxx();
%include "foo.h"
namespace car {
...
namespace tires {
int do_something(int n);
}
...
namespace tires {
int do_something(int n);
}
}
</pre>
</div>
@ -742,7 +742,7 @@ namespace car {
function such as <tt>(car '(1 2 3)</tt>.
</p>
<H3><a name="Allegrocl_nn16">18.3.2 Constants</a></H3>
<H3><a name="Allegrocl_nn16">20.3.2 Constants</a></H3>
@ -803,7 +803,7 @@ namespace car {
not use the <tt>-nocwrap</tt> command-line option.
</p>
<H3><a name="Allegrocl_nn17">18.3.3 Variables</a></H3>
<H3><a name="Allegrocl_nn17">20.3.3 Variables</a></H3>
<p>
@ -881,7 +881,7 @@ globalvar&gt; (globalvar.nnn::glob_float)
</pre>
</div>
<H3><a name="Allegrocl_nn18">18.3.4 Enumerations</a></H3>
<H3><a name="Allegrocl_nn18">20.3.4 Enumerations</a></H3>
<p>
@ -957,7 +957,7 @@ EXPORT const int ACL_ENUM___FOO3__SWIG_0 = FOO3;
</pre>
</div>
<H3><a name="Allegrocl_nn19">18.3.5 Arrays</a></H3>
<H3><a name="Allegrocl_nn19">20.3.5 Arrays</a></H3>
<p>
@ -1105,10 +1105,10 @@ namespace BAR {
</pre>
</div>
<H3><a name="Allegrocl_nn20">18.3.6 Classes and Structs and Unions (oh my!)</a></H3>
<H3><a name="Allegrocl_nn20">20.3.6 Classes and Structs and Unions (oh my!)</a></H3>
<H4><a name="Allegrocl_nn21">18.3.6.1 CLOS wrapping of</a></H4>
<H4><a name="Allegrocl_nn21">20.3.6.1 CLOS wrapping of</a></H4>
<p>
@ -1123,7 +1123,7 @@ namespace BAR {
integer values.
</p>
<H4><a name="Allegrocl_nn22">18.3.6.2 CLOS Inheritance</a></H4>
<H4><a name="Allegrocl_nn22">20.3.6.2 CLOS Inheritance</a></H4>
<p>
@ -1136,7 +1136,7 @@ namespace BAR {
parameter.
</p>
<H4><a name="Allegrocl_nn23">18.3.6.3 Member fields and functions</a></H4>
<H4><a name="Allegrocl_nn23">20.3.6.3 Member fields and functions</a></H4>
<p>
@ -1152,7 +1152,7 @@ namespace BAR {
the interface does nothing for <tt>friend</tt> directives,
</p>
<H4><a name="Allegrocl_nn24">18.3.6.4 Why not directly access C++ classes using foreign types?</a></H4>
<H4><a name="Allegrocl_nn24">20.3.6.4 Why not directly access C++ classes using foreign types?</a></H4>
<p>
@ -1170,11 +1170,11 @@ namespace BAR {
use the more robust wrapper functions.
</p>
<H3><a name="Allegrocl_nn25">18.3.7 Templates</a></H3>
<H3><a name="Allegrocl_nn25">20.3.7 Templates</a></H3>
<H4><a name="Allegrocl_nn26">18.3.7.1 Generating wrapper code for templates</a></H4>
<H4><a name="Allegrocl_nn26">20.3.7.1 Generating wrapper code for templates</a></H4>
<p>
@ -1187,7 +1187,7 @@ them. This is done via the
directive.
</p>
<H4><a name="Allegrocl_nn27">18.3.7.2 Implicit Template instantiation</a></H4>
<H4><a name="Allegrocl_nn27">20.3.7.2 Implicit Template instantiation</a></H4>
<p>
@ -1197,7 +1197,7 @@ to include these templated classes in the foreign-type and CLOS
class schema.
</p>
<H3><a name="Allegrocl_nn28">18.3.8 Typedef, Templates, and Synonym Types</a></H3>
<H3><a name="Allegrocl_nn28">20.3.8 Typedef, Templates, and Synonym Types</a></H3>
<p>
@ -1209,8 +1209,8 @@ class schema.
<div class="code">synonyms.h
<pre>
class A {
int x;
int y;
int x;
int y;
};
typedef A Foo;
@ -1239,7 +1239,7 @@ int zzz(A *inst = 0); /* return inst-&gt;x + inst-&gt;y */
We resolve this issue, by noting synonym relationships between
types while generating the interface. A Primary type is selected
(more on this below) from the candidate list of synonyms. For
all other synonyms, intead of generating a distinct CLOS class
all other synonyms, instead of generating a distinct CLOS class
definition, we generate a form that expands to:
</p>
<div class="targetlang">
@ -1277,7 +1277,7 @@ synonym&gt;
</pre>
</div>
<H4><a name="Allegrocl_nn29">18.3.8.1 Choosing a primary type</a></H4>
<H4><a name="Allegrocl_nn29">20.3.8.1 Choosing a primary type</a></H4>
<p>
@ -1298,7 +1298,7 @@ synonym&gt;
</li>
</ul>
<H3><a name="Allegrocl_nn30">18.3.9 Function overloading/Parameter defaulting</a></H3>
<H3><a name="Allegrocl_nn30">20.3.9 Function overloading/Parameter defaulting</a></H3>
<p>
@ -1336,70 +1336,70 @@ float xxx(A *inst, int x); /* return x + A-&gt;x + A-&gt;y */
<div class="code">overload_wrap.cxx
<pre>
EXPORT void ACL___delete_A__SWIG_0 (A *larg1) {
A *arg1 = (A *) 0 ;
arg1 = larg1;
try {
delete arg1;
} catch (...) {
}
A *arg1 = (A *) 0 ;
arg1 = larg1;
try {
delete arg1;
} catch (...) {
}
}
EXPORT float ACL___xxx__SWIG_0 (int larg1, int larg2) {
float lresult = (float)0 ;
int arg1 ;
int arg2 ;
float result;
arg1 = larg1;
arg2 = larg2;
try {
result = (float)xxx(arg1,arg2);
lresult = result;
return lresult;
} catch (...) {
return (float)0;
}
float lresult = (float)0 ;
int arg1 ;
int arg2 ;
float result;
arg1 = larg1;
arg2 = larg2;
try {
result = (float)xxx(arg1, arg2);
lresult = result;
return lresult;
} catch (...) {
return (float)0;
}
}
EXPORT float ACL___xxx__SWIG_1 (int larg1) {
float lresult = (float)0 ;
int arg1 ;
float result;
arg1 = larg1;
try {
result = (float)xxx(arg1);
lresult = result;
return lresult;
} catch (...) {
return (float)0;
}
float lresult = (float)0 ;
int arg1 ;
float result;
arg1 = larg1;
try {
result = (float)xxx(arg1);
lresult = result;
return lresult;
} catch (...) {
return (float)0;
}
}
EXPORT float ACL___xxx__SWIG_2 (A *larg1, int larg2) {
float lresult = (float)0 ;
A *arg1 = (A *) 0 ;
int arg2 ;
float result;
arg1 = larg1;
arg2 = larg2;
try {
result = (float)xxx(arg1,arg2);
lresult = result;
return lresult;
} catch (...) {
return (float)0;
}
float lresult = (float)0 ;
A *arg1 = (A *) 0 ;
int arg2 ;
float result;
arg1 = larg1;
arg2 = larg2;
try {
result = (float)xxx(arg1, arg2);
lresult = result;
return lresult;
} catch (...) {
return (float)0;
}
}
</pre>
</div>
@ -1461,7 +1461,7 @@ overload&gt;
</pre>
</div>
<H3><a name="Allegrocl_nn31">18.3.10 Operator wrapping and Operator overloading</a></H3>
<H3><a name="Allegrocl_nn31">20.3.10 Operator wrapping and Operator overloading</a></H3>
<p>
@ -1607,7 +1607,7 @@ opoverload&gt;
</pre>
</div>
<H3><a name="Allegrocl_nn32">18.3.11 Varargs</a></H3>
<H3><a name="Allegrocl_nn32">20.3.11 Varargs</a></H3>
<p>
@ -1628,7 +1628,7 @@ opoverload&gt;
with other ways such functions can be wrapped.
</p>
<H3><a name="Allegrocl_nn33">18.3.12 C++ Exceptions</a></H3>
<H3><a name="Allegrocl_nn33">20.3.12 C++ Exceptions</a></H3>
<p>
@ -1640,7 +1640,7 @@ opoverload&gt;
implemented.
</p>
<H3><a name="Allegrocl_nn34">18.3.13 Pass by value, pass by reference</a></H3>
<H3><a name="Allegrocl_nn34">20.3.13 Pass by value, pass by reference</a></H3>
<p>
@ -1652,7 +1652,7 @@ opoverload&gt;
newly defined types.
</p>
<H2><a name="Allegrocl_nn35">18.4 Typemaps</a></H2>
<H2><a name="Allegrocl_nn35">20.4 Typemaps</a></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">18.4.1 Code Generation in the C++ Wrapper</a></H3>
<H3><a name="Allegrocl_nn36">20.4.1 Code Generation in the C++ Wrapper</a></H3>
@ -1675,25 +1675,25 @@ opoverload&gt;
<pre>
return-val wrapper-name(parm0, parm1, ..., parmN)
{
return-val lresult; /* return value from wrapper */
&lt;local-declaration&gt;
... results; /* return value from function call */
return-val lresult; /* return value from wrapper */
&lt;local-declaration&gt;
... results; /* return value from function call */
&lt;binding locals to parameters&gt;
&lt;binding locals to parameters&gt;
try {
result = function-name(local0, local1, ..., localN);
try {
result = function-name(local0, local1, ..., localN);
&lt;convert and bind result to lresult&gt;
&lt;convert and bind result to lresult&gt;
return lresult;
catch (...) {
return (int)0;
}
return lresult;
catch (...) {
return (int)0;
}
</pre>
</div>
<H4><a name="Allegrocl_nn37">18.4.1.1 IN Typemap</a></H4>
<H4><a name="Allegrocl_nn37">20.4.1.1 IN Typemap</a></H4>
<p>
@ -1728,7 +1728,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn38">18.4.1.2 OUT Typemap</a></H4>
<H4><a name="Allegrocl_nn38">20.4.1.2 OUT Typemap</a></H4>
<p>
@ -1752,7 +1752,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn39">18.4.1.3 CTYPE Typemap</a></H4>
<H4><a name="Allegrocl_nn39">20.4.1.3 CTYPE Typemap</a></H4>
<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">18.4.2 Code generation in Lisp wrappers</a></H3>
<H3><a name="Allegrocl_nn40">20.4.2 Code generation in Lisp wrappers</a></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">18.4.2.1 LIN Typemap</a></H4>
<H4><a name="Allegrocl_nn41">20.4.2.1 LIN Typemap</a></H4>
<p>
@ -1846,7 +1846,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn42">18.4.2.2 LOUT Typemap</a></H4>
<H4><a name="Allegrocl_nn42">20.4.2.2 LOUT Typemap</a></H4>
<p>
@ -1889,7 +1889,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn43">18.4.2.3 FFITYPE Typemap</a></H4>
<H4><a name="Allegrocl_nn43">20.4.2.3 FFITYPE Typemap</a></H4>
@ -1939,7 +1939,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn44">18.4.2.4 LISPTYPE Typemap</a></H4>
<H4><a name="Allegrocl_nn44">20.4.2.4 LISPTYPE Typemap</a></H4>
<p>
@ -1959,7 +1959,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H4><a name="Allegrocl_nn45">18.4.2.5 LISPCLASS Typemap</a></H4>
<H4><a name="Allegrocl_nn45">20.4.2.5 LISPCLASS Typemap</a></H4>
<p>
@ -1983,7 +1983,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H3><a name="Allegrocl_nn46">18.4.3 Modifying SWIG behavior using typemaps</a></H3>
<H3><a name="Allegrocl_nn46">20.4.3 Modifying SWIG behavior using typemaps</a></H3>
<p>
@ -2017,10 +2017,10 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
</pre>
</div>
<H2><a name="Allegrocl_nn47">18.5 Identifier Converter functions</a></H2>
<H2><a name="Allegrocl_nn47">20.5 Identifier Converter functions</a></H2>
<H3><a name="Allegrocl_nn48">18.5.1 Creating symbols in the lisp environment</a></H3>
<H3><a name="Allegrocl_nn48">20.5.1 Creating symbols in the lisp environment</a></H3>
<p>
@ -2041,11 +2041,11 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
of arguments.
</p>
<H3><a name="Allegrocl_nn49">18.5.2 Existing identifier-converter functions</a></H3>
<H3><a name="Allegrocl_nn49">20.5.2 Existing identifier-converter functions</a></H3>
<p>Two basic identifier routines have been defined.
<H4><a name="Allegrocl_nn50">18.5.2.1 identifier-convert-null</a></H4>
<H4><a name="Allegrocl_nn50">20.5.2.1 identifier-convert-null</a></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">18.5.2.2 identifier-convert-lispify</a></H4>
<H4><a name="Allegrocl_nn51">20.5.2.2 identifier-convert-lispify</a></H4>
<p>
@ -2063,7 +2063,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
same symbol transformations.
</p>
<H4><a name="Allegrocl_nn52">18.5.2.3 Default identifier to symbol conversions</a></H4>
<H4><a name="Allegrocl_nn52">20.5.2.3 Default identifier to symbol conversions</a></H4>
<p>
@ -2072,7 +2072,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
default naming conventions.
</p>
<H3><a name="Allegrocl_nn53">18.5.3 Defining your own identifier-converter</a></H3>
<H3><a name="Allegrocl_nn53">20.5.3 Defining your own identifier-converter</a></H3>
<p>
@ -2128,7 +2128,7 @@ indicating the number of arguments passed to the routine indicated by
this identifier.
</p>
<H3><a name="Allegrocl_nn54">18.5.4 Instructing SWIG to use a particular identifier-converter</a></H3>
<H3><a name="Allegrocl_nn54">20.5.4 Instructing SWIG to use a particular identifier-converter</a></H3>
<p>

26
Doc/Manual/Android.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="Android">19 SWIG and Android</a></H1>
<H1><a name="Android">21 SWIG and Android</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -31,7 +31,7 @@ This chapter describes SWIG's support of Android.
<H2><a name="Android_overview">19.1 Overview</a></H2>
<H2><a name="Android_overview">21.1 Overview</a></H2>
<p>
@ -41,14 +41,14 @@ Everything in the <a href="Java.html#Java">Java chapter</a> applies to generatin
This chapter contains a few Android specific notes and examples.
</p>
<H2><a name="Android_examples">19.2 Android examples</a></H2>
<H2><a name="Android_examples">21.2 Android examples</a></H2>
<H3><a name="Android_examples_intro">19.2.1 Examples introduction</a></H3>
<H3><a name="Android_examples_intro">21.2.1 Examples introduction</a></H3>
<p>
The examples require the <a href="http://developer.android.com/sdk/index.html">Android SDK</a> and <a href="http://developer.android.com/tools/sdk/ndk/index.html">Android NDK</a> which can be installed as per instructions in the links.
The examples require the <a href="https://developer.android.com/sdk/">Android SDK</a> and <a href="https://developer.android.com/ndk/">Android NDK</a> which can be installed as per instructions in the links.
The Eclipse version is not required for these examples as just the command line tools are used (shown for Linux as the host, but Windows will be very similar, if not identical in most places).
Add the SDK tools and NDK tools to your path and create a directory somewhere for your Android projects (adjust PATH as necessary to where you installed the tools):
</p>
@ -77,7 +77,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">19.2.2 Simple C example</a></H3>
<H3><a name="Android_example_simple">21.2.2 Simple C example</a></H3>
<p>
@ -326,7 +326,7 @@ include $(BUILD_SHARED_LIBRARY)
</div>
<p>
See the <a href="http://developer.android.com/sdk/ndk/index.html">Android NDK documentation</a> for more on the NDK build system and getting started with the NDK.
See the <a href="https://developer.android.com/ndk/">Android NDK documentation</a> for more on the NDK build system and getting started with the NDK.
A simple invocation of ndk-build will compile the .c files and generate a shared object/system library. Output will be similar to:
</p>
@ -354,7 +354,7 @@ Modify the <tt>nativeCall</tt> method in <tt>src/org/swig/simple/SwigSimple.java
int x = 42;
int y = 105;
int g = example.gcd(x,y);
int g = example.gcd(x, y);
outputText.append("The greatest common divisor of " + x + " and " + y + " is " + g + "\n");
// Manipulate the Foo global variable
@ -399,7 +399,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">19.2.3 C++ class example</a></H3>
<H3><a name="Android_example_class">21.2.3 C++ class example</a></H3>
<p>
@ -409,7 +409,7 @@ All the steps required to compile and use a simple hierarchy of classes for shap
<p>
First create an Android project called <tt>SwigClass</tt> in a subdirectory called <tt>class</tt>.
The steps below create and build a the JNI C++ app.
The steps below create and build the JNI C++ app.
Adjust the <tt>--target</tt> id as mentioned earlier in the <a href="Android.html#Android_examples_intro">Examples introduction</a>.
</p>
@ -661,7 +661,7 @@ public class SwigClass extends Activity
// ----- Call some methods -----
outputText.append( "\nHere are some properties of the shapes:\n" );
Shape[] shapes = {c,s};
Shape[] shapes = {c, s};
for (int i=0; i&lt;shapes.length; i++)
{
outputText.append( " " + shapes[i].toString() + "\n" );
@ -747,7 +747,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">19.2.4 Other examples</a></H3>
<H3><a name="Android_examples_other">21.2.4 Other examples</a></H3>
<p>
@ -759,7 +759,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">19.3 C++ STL</a></H2>
<H2><a name="Android_stl">21.3 C++ STL</a></H2>
<p>

32
Doc/Manual/Arguments.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Arguments">10 Argument Handling</a></H1>
<H1><a name="Arguments">12 Argument Handling</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -32,7 +32,7 @@
<p>
In Chapter 3, SWIG's treatment of basic datatypes and pointers was
In Chapter 5, SWIG's treatment of basic datatypes and pointers was
described. In particular, primitive types such as <tt>int</tt> and
<tt>double</tt> are mapped to corresponding types in the target
language. For everything else, pointers are used to refer to
@ -43,7 +43,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">10.1 The typemaps.i library</a></H2>
<H2><a name="Arguments_nn2">12.1 The typemaps.i library</a></H2>
<p>
@ -51,7 +51,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">10.1.1 Introduction</a></H3>
<H3><a name="Arguments_nn3">12.1.1 Introduction</a></H3>
<p>
@ -100,7 +100,7 @@ like this (shown for Python):
</p>
<div class="targetlang"><pre>
&gt;&gt;&gt; a = add(3,4)
&gt;&gt;&gt; a = add(3, 4)
&gt;&gt;&gt; print a
7
&gt;&gt;&gt;
@ -148,7 +148,7 @@ For example, consider this code:
%include "typemaps.i"
%apply int *OUTPUT { int *width, int *height };
// Returns a pair (width,height)
// Returns a pair (width, height)
void getwinsize(int winid, int *width, int *height);
</pre>
</div>
@ -158,7 +158,7 @@ In this case, the function returns multiple values, allowing it to be used like
</p>
<div class="targetlang"><pre>
&gt;&gt;&gt; w,h = genwinsize(wid)
&gt;&gt;&gt; w, h = genwinsize(wid)
&gt;&gt;&gt; print w
400
&gt;&gt;&gt; print h
@ -195,7 +195,7 @@ else. To clear a typemap, the <tt>%clear</tt> directive should be used. For e
</pre>
</div>
<H3><a name="Arguments_nn4">10.1.2 Input parameters</a></H3>
<H3><a name="Arguments_nn4">12.1.2 Input parameters</a></H3>
<p>
@ -245,10 +245,10 @@ When the function is used in the scripting language interpreter, it will work li
</p>
<div class="targetlang"><pre>
result = add(3,4)
result = add(3, 4)
</pre></div>
<H3><a name="Arguments_nn5">10.1.3 Output parameters</a></H3>
<H3><a name="Arguments_nn5">12.1.3 Output parameters</a></H3>
<p>
@ -315,7 +315,7 @@ iresult, dresult = foo(3.5, 2)
</pre>
</div>
<H3><a name="Arguments_nn6">10.1.4 Input/Output parameters</a></H3>
<H3><a name="Arguments_nn6">12.1.4 Input/Output parameters</a></H3>
<p>
@ -380,7 +380,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">10.1.5 Using different names</a></H3>
<H3><a name="Arguments_nn7">12.1.5 Using different names</a></H3>
<p>
@ -414,7 +414,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">10.2 Applying constraints to input values</a></H2>
<H2><a name="Arguments_nn8">12.2 Applying constraints to input values</a></H2>
<p>
@ -424,7 +424,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">10.2.1 Simple constraint example</a></H3>
<H3><a name="Arguments_nn9">12.2.1 Simple constraint example</a></H3>
<p>
@ -450,7 +450,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">10.2.2 Constraint methods</a></H3>
<H3><a name="Arguments_nn10">12.2.2 Constraint methods</a></H3>
<p>
@ -466,7 +466,7 @@ NONNULL Non-NULL pointer (pointers only).
</pre></div>
<H3><a name="Arguments_nn11">10.2.3 Applying constraints to new datatypes</a></H3>
<H3><a name="Arguments_nn11">12.2.3 Applying constraints to new datatypes</a></H3>
<p>

40
Doc/Manual/CCache.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="CCache">17 Using SWIG with ccache - ccache-swig(1) manpage</a></H1>
<H1><a name="CCache">20 Using SWIG with ccache - ccache-swig(1) manpage</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -35,7 +35,7 @@
<p>
<H2><a name="CCache_nn2">17.1 NAME</a></H2>
<H2><a name="CCache_nn2">20.1 NAME</a></H2>
<p>
@ -43,7 +43,7 @@
ccache-swig - a fast compiler cache
<p>
<H2><a name="CCache_nn3">17.2 SYNOPSIS</a></H2>
<H2><a name="CCache_nn3">20.2 SYNOPSIS</a></H2>
<p>
@ -53,7 +53,7 @@ ccache-swig &lt;compiler&gt; [COMPILER OPTIONS]
<p>
&lt;compiler&gt; [COMPILER OPTIONS]
<p>
<H2><a name="CCache_nn4">17.3 DESCRIPTION</a></H2>
<H2><a name="CCache_nn4">20.3 DESCRIPTION</a></H2>
<p>
@ -62,7 +62,7 @@ by caching previous compiles and detecting when the same compile is
being done again. ccache-swig is ccache plus support for SWIG. ccache
and ccache-swig are used interchangeably in this document.
<p>
<H2><a name="CCache_nn5">17.4 OPTIONS SUMMARY</a></H2>
<H2><a name="CCache_nn5">20.4 OPTIONS SUMMARY</a></H2>
<p>
@ -82,7 +82,7 @@ Here is a summary of the options to ccache-swig.
</pre>
<p>
<H2><a name="CCache_nn6">17.5 OPTIONS</a></H2>
<H2><a name="CCache_nn6">20.5 OPTIONS</a></H2>
<p>
@ -124,7 +124,7 @@ rounded down to the nearest multiple of 16 kilobytes.
<p>
</dl>
<p>
<H2><a name="CCache_nn7">17.6 INSTALLATION</a></H2>
<H2><a name="CCache_nn7">20.6 INSTALLATION</a></H2>
<p>
@ -156,7 +156,7 @@ This will work as long as /usr/local/bin comes before the path to gcc
Note! Do not use a hard link, use a symbolic link. A hardlink will
cause "interesting" problems.
<p>
<H2><a name="CCache_nn8">17.7 EXTRA OPTIONS</a></H2>
<H2><a name="CCache_nn8">20.7 EXTRA OPTIONS</a></H2>
<p>
@ -176,7 +176,7 @@ file). By using --ccache-skip you can force an option to not be
treated as an input file name and instead be passed along to the
compiler as a command line option.
<p>
<H2><a name="CCache_nn9">17.8 ENVIRONMENT VARIABLES</a></H2>
<H2><a name="CCache_nn9">20.8 ENVIRONMENT VARIABLES</a></H2>
<p>
@ -315,7 +315,7 @@ the use of '#pragma SWIG'.
<p>
</dl>
<p>
<H2><a name="CCache_nn10">17.9 CACHE SIZE MANAGEMENT</a></H2>
<H2><a name="CCache_nn10">20.9 CACHE SIZE MANAGEMENT</a></H2>
<p>
@ -328,7 +328,7 @@ When these limits are reached ccache will reduce the cache to 20%
below the numbers you specified in order to avoid doing the cache
clean operation too often.
<p>
<H2><a name="CCache_nn11">17.10 CACHE COMPRESSION</a></H2>
<H2><a name="CCache_nn11">20.10 CACHE COMPRESSION</a></H2>
<p>
@ -339,7 +339,7 @@ performance slowdown, it significantly increases the number of files
that fit in the cache. You can turn off compression setting the
CCACHE_NOCOMPRESS environment variable.
<p>
<H2><a name="CCache_nn12">17.11 HOW IT WORKS</a></H2>
<H2><a name="CCache_nn12">20.11 HOW IT WORKS</a></H2>
<p>
@ -364,7 +364,7 @@ compiler output that you would get without the cache. If you ever
discover a case where ccache changes the output of your compiler then
please let me know.
<p>
<H2><a name="CCache_nn13">17.12 USING CCACHE WITH DISTCC</a></H2>
<H2><a name="CCache_nn13">20.12 USING CCACHE WITH DISTCC</a></H2>
<p>
@ -378,7 +378,7 @@ option. You just need to set the environment variable CCACHE_PREFIX to
'distcc' and ccache will prefix the command line used with the
compiler with the command 'distcc'.
<p>
<H2><a name="CCache_nn14">17.13 SHARING A CACHE</a></H2>
<H2><a name="CCache_nn14">20.13 SHARING A CACHE</a></H2>
<p>
@ -407,11 +407,11 @@ following conditions need to be met:
versions of ccache that do not support compression.
</ul>
<p>
<H2><a name="CCache_nn15">17.14 HISTORY</a></H2>
<H2><a name="CCache_nn15">20.14 HISTORY</a></H2>
<p>
ccache was inspired by the compilercache shell script script written
ccache was inspired by the compilercache shell script written
by Erik Thiele and I would like to thank him for an excellent piece of
work. See
<a href="http://www.erikyyy.de/compilercache/">http://www.erikyyy.de/compilercache/</a>
@ -423,7 +423,7 @@ I wrote ccache because I wanted to get a bit more speed out of a
compiler cache and I wanted to remove some of the limitations of the
shell-script version.
<p>
<H2><a name="CCache_nn16">17.15 DIFFERENCES FROM COMPILERCACHE</a></H2>
<H2><a name="CCache_nn16">20.15 DIFFERENCES FROM COMPILERCACHE</a></H2>
<p>
@ -441,7 +441,7 @@ are:
<li> ccache avoids a double call to cpp on a cache miss
</ul>
<p>
<H2><a name="CCache_nn17">17.16 CREDITS</a></H2>
<H2><a name="CCache_nn17">20.16 CREDITS</a></H2>
<p>
@ -453,12 +453,12 @@ Thanks to the following people for their contributions to ccache
<li> Paul Russell for many suggestions and the debian packaging
</ul>
<p>
<H2><a name="CCache_nn18">17.17 AUTHOR</a></H2>
<H2><a name="CCache_nn18">20.17 AUTHOR</a></H2>
<p>
ccache was written by Andrew Tridgell
<a href="http://samba.org/~tridge/">http://samba.org/~tridge/</a>.
<a href="https://www.samba.org/~tridge/">https://www.samba.org/~tridge/</a>.
ccache was adapted to create ccache-swig for use with SWIG by William Fulton.
<p>
If you wish to report a problem or make a suggestion then please email

188
Doc/Manual/CPlusPlus11.html
View file

@ -32,6 +32,7 @@
<li><a href="#CPlusPlus11_alias_templates">Type alias and alias templates</a>
<li><a href="#CPlusPlus11_unrestricted_unions">Unrestricted unions</a>
<li><a href="#CPlusPlus11_variadic_templates">Variadic templates</a>
<li><a href="#CPlusPlus11_new_char_literals">New character literals</a>
<li><a href="#CPlusPlus11_new_string_literals">New string literals</a>
<li><a href="#CPlusPlus11_user_defined_literals">User-defined literals</a>
<li><a href="#CPlusPlus11_thread_local_storage">Thread-local storage</a>
@ -42,6 +43,7 @@
<li><a href="#CPlusPlus11_noexcept">Exception specifications and noexcept</a>
<li><a href="#CPlusPlus11_alignment">Control and query object alignment</a>
<li><a href="#CPlusPlus11_attributes">Attributes</a>
<li><a href="#CPlusPlus11_ref_qualifiers">Methods with ref-qualifiers</a>
</ul>
<li><a href="#CPlusPlus11_standard_library_changes">Standard library changes</a>
<ul>
@ -203,7 +205,7 @@ public:
<p>And then call this constructor from your target language, for example, in Python, the following will call the constructor taking the <tt>std::vector</tt>:</p>
<div class="targetlang"><pre>
&gt;&gt;&gt; c = Container( [1,2,3,4] )
&gt;&gt;&gt; c = Container( [1, 2, 3, 4] )
</pre></div>
<p>
@ -392,7 +394,7 @@ auto SomeStruct::FuncName(int x, int y) -&gt; int {
<div class="targetlang"><pre>
&gt;&gt;&gt; a = SomeStruct()
&gt;&gt;&gt; a.FuncName(10,5)
&gt;&gt;&gt; a.FuncName(10, 5)
15
</pre></div>
@ -457,10 +459,10 @@ This kind of initialization is handled by SWIG.
<div class="code"><pre>
class SomeClass {
public:
SomeClass() {}
explicit SomeClass(int new_value) : value(new_value) {}
SomeClass() {}
explicit SomeClass(int new_value) : value(new_value) {}
int value = 5;
int value = 5;
};
</pre></div>
@ -622,20 +624,15 @@ which is equivalent to the old style typedef:
typedef void (*PFD)(double); // The old style
</pre></div>
<p>
SWIG supports type aliasing.
</p>
<p>
The following is an example of an alias template:
<div class="code"><pre>
template&lt; typename T1, typename T2, int &gt;
template&lt; typename T1, typename T2, int N &gt;
class SomeType {
public:
T1 a;
T2 b;
int c;
};
template&lt; typename T2 &gt;
@ -643,14 +640,19 @@ using TypedefName = SomeType&lt;char*, T2, 5&gt;;
</pre></div>
<p>
These are partially supported as SWIG will parse these and identify them, however, they are ignored as they are not added to the type system. A warning such as the following is issued:
SWIG supports both type aliasing and alias templates.
However, in order to use an alias template, two <tt>%template</tt> directives must be used:
</p>
<div class="shell">
<pre>
example.i:13: Warning 342: The 'using' keyword in template aliasing is not fully supported yet.
</pre>
</div>
<div class="code"><pre>
%template(SomeTypeBool) SomeType&lt;char*, bool, 5&gt;;
%template() TypedefName&lt;bool&gt;;
</pre></div>
<p>Firstly, the actual template is instantiated with a name to be used by the target language, as per any template being wrapped.
Secondly, the empty template instantiation, <tt>%template()</tt>, is required for the alias template.
This second requirement is necessary to add the appropriate instantiated template type into the type system as SWIG does not automatically instantiate templates.
See the <a href="SWIGPlus.html#SWIGPlus_nn30">Templates</a> section for more general information on wrapping templates.
<H3><a name="CPlusPlus11_unrestricted_unions">7.2.17 Unrestricted unions</a></H3>
@ -688,7 +690,7 @@ initializers) with some limitations. The following code is correctly parsed:</p>
<div class="code"><pre>
template &lt;typename... BaseClasses&gt; class ClassName : public BaseClasses... {
public:
ClassName (BaseClasses &amp;&amp;... baseClasses) : BaseClasses(baseClasses)... {}
ClassName (BaseClasses &amp;&amp;... baseClasses) : BaseClasses(baseClasses)... {}
}
</pre></div>
@ -713,7 +715,24 @@ const int SIZE = sizeof...(ClassName&lt;int, int&gt;);
In the above example <tt>SIZE</tt> is of course wrapped as a constant.
</p>
<H3><a name="CPlusPlus11_new_string_literals">7.2.19 New string literals</a></H3>
<H3><a name="CPlusPlus11_new_char_literals">7.2.19 New character literals</a></H3>
<p>
C++11 adds support for UCS-2 and UCS-4 character literals.
These character literals are preceded by either 'u' or 'U'.
</p>
<div class="code"><pre>
char16_t a = u'a';
char32_t b = U'b';
</pre></div>
<p>
<b>Compatibility note:</b> SWIG-4.0.0 was the first version to support these Universal Coded Character Set (UCS) character literals.
</p>
<H3><a name="CPlusPlus11_new_string_literals">7.2.20 New string literals</a></H3>
<p>SWIG supports wide string and Unicode string constants and raw string literals.</p>
@ -743,7 +762,7 @@ Note: There is a bug currently where SWIG's preprocessor incorrectly parses an o
inside raw string literals.
</p>
<H3><a name="CPlusPlus11_user_defined_literals">7.2.20 User-defined literals</a></H3>
<H3><a name="CPlusPlus11_user_defined_literals">7.2.21 User-defined literals</a></H3>
<p>
@ -810,7 +829,7 @@ OutputType var2 = 1234_suffix;
OutputType var3 = 3.1416_suffix;
</pre></div>
<H3><a name="CPlusPlus11_thread_local_storage">7.2.21 Thread-local storage</a></H3>
<H3><a name="CPlusPlus11_thread_local_storage">7.2.22 Thread-local storage</a></H3>
<p>SWIG correctly parses the <tt>thread_local</tt> keyword. For example, variables
@ -818,7 +837,7 @@ reachable by the current thread can be defined as:</p>
<div class="code"><pre>
struct A {
static thread_local int val;
static thread_local int val;
};
thread_local int global_val;
</pre></div>
@ -830,7 +849,7 @@ A variable will be thread local if accessed from different threads from the targ
same way that it will be thread local if accessed from C++ code.
</p>
<H3><a name="CPlusPlus11_defaulted_deleted">7.2.22 Explicitly defaulted functions and deleted functions</a></H3>
<H3><a name="CPlusPlus11_defaulted_deleted">7.2.23 Explicitly defaulted functions and deleted functions</a></H3>
<p>SWIG handles explicitly defaulted functions, that is, <tt>= default</tt> added to a function declaration. Deleted definitions, which are also called deleted functions, have <tt>= delete</tt> added to the function declaration.
@ -858,8 +877,8 @@ For example, the C++ compiler will not compile any code which attempts to use an
<div class="code"><pre>
struct NoInt {
void f(double i);
void f(int) = delete;
void f(double i);
void f(int) = delete;
};
</pre></div>
@ -868,16 +887,17 @@ This is a C++ compile time check and SWIG does not make any attempt to detect if
so in this case it is entirely possible to pass an int instead of a double to <tt>f</tt> from Java, Python etc.
</p>
<H3><a name="CPlusPlus11_type_long_long_int">7.2.23 Type long long int</a></H3>
<H3><a name="CPlusPlus11_type_long_long_int">7.2.24 Type long long int</a></H3>
<p>SWIG correctly parses and uses the new <tt>long long</tt> type already introduced in C99 some time ago.</p>
<H3><a name="CPlusPlus11_static_assertions">7.2.24 Static assertions</a></H3>
<H3><a name="CPlusPlus11_static_assertions">7.2.25 Static assertions</a></H3>
<p>
SWIG correctly parses the new <tt>static_assert</tt> declarations.
SWIG correctly parses the new <tt>static_assert</tt> declarations (though 3.0.12 and earlier
had a bug which meant this wasn't accepted at file scope).
This is a C++ compile time directive so there isn't anything useful that SWIG can do with it.
</p>
@ -888,7 +908,7 @@ struct Check {
};
</pre></div>
<H3><a name="CPlusPlus11_sizeof">7.2.25 Allow sizeof to work on members of classes without an explicit object</a></H3>
<H3><a name="CPlusPlus11_sizeof">7.2.26 Allow sizeof to work on members of classes without an explicit object</a></H3>
<p>
@ -909,7 +929,7 @@ const int SIZE = sizeof(A::member); // does not work with C++03. Okay with C++11
8
</pre></div>
<H3><a name="CPlusPlus11_noexcept">7.2.26 Exception specifications and noexcept</a></H3>
<H3><a name="CPlusPlus11_noexcept">7.2.27 Exception specifications and noexcept</a></H3>
<p>
@ -925,7 +945,7 @@ int noex2(int) noexcept(true);
int noex3(int, bool) noexcept(false);
</pre></div>
<H3><a name="CPlusPlus11_alignment">7.2.27 Control and query object alignment</a></H3>
<H3><a name="CPlusPlus11_alignment">7.2.28 Control and query object alignment</a></H3>
<p>
@ -957,7 +977,7 @@ Use the preprocessor to work around this for now:
</pre></div>
<H3><a name="CPlusPlus11_attributes">7.2.28 Attributes</a></H3>
<H3><a name="CPlusPlus11_attributes">7.2.29 Attributes</a></H3>
<p>
@ -970,6 +990,104 @@ int [[attr1]] i [[attr2, attr3]];
[[noreturn, nothrow]] void f [[noreturn]] ();
</pre></div>
<H3><a name="CPlusPlus11_ref_qualifiers">7.2.30 Methods with ref-qualifiers</a></H3>
<p>
C++11 non-static member functions can be declared with ref-qualifiers.
Member functions declared with a <tt>&amp;</tt> lvalue ref-qualifiers are wrapped like any other function without ref-qualifiers.
Member functions declared with a <tt>&amp;&amp;</tt> rvalue ref-qualifiers are ignored by default
as they are unlikely to be required from non-C++ languages where the concept of <i>rvalue-ness</i>
for the implied *this pointer does not apply.
The warning is hidden by default, but can be displayed as described in the section on <a href="Warnings.html#Warnings_nn4">Enabling extra warnings</a>.
</p>
<p>
Consider:
</p>
<div class="code"><pre>
struct RQ {
void m1(int x) &amp;;
void m2(int x) &amp;&amp;;
};
</pre></div>
<p>
The only wrapped method will be the lvalue ref-qualified method <tt>m1</tt>
and if SWIG is run with the <tt>-Wextra</tt> command-line option, the following warning will be issued indicating <tt>m2</tt> is not wrapped:
</p>
<div class="shell">
<pre>
example.i:7: Warning 405: Method with rvalue ref-qualifier m2(int) &amp;&amp; ignored.
</pre>
</div>
<p>
If you unignore the method as follows, wrappers for <tt>m2</tt> will be generated:
</p>
<div class="code"><pre>
%feature("ignore", "0") RQ::m2(int x) &amp;&amp;;
struct RQ {
void m1(int x) &amp;;
void m2(int x) &amp;&amp;;
};
</pre></div>
<p>
Inspection of the generated C++ code, will show that <tt>std::move</tt> is used on the instance
of the <tt>RQ *</tt> class:
</p>
<div class="code"><pre>
RQ *arg1 = (RQ *) 0 ;
int arg2 ;
arg1 = ...marshalled from target language...
arg2 = ...marshalled from target language...
std::move(*arg1).m2(arg2);
</pre></div>
<p>
This will compile but when run, the move effects may not be what you want.
As stated earlier, rvalue ref-qualifiers aren't really applicable outside the world of C++.
However, if you really know what you are doing, full control over the call to the method is
possible via the low-level "action" feature.
This feature completely replaces the call to the underlying function, that is, the last line in the snippet of code above.
</p>
<div class="code"><pre>
%feature("ignore", "0") RQ::m2(int x) &amp;&amp;;
%feature("action") RQ::m2(int x) &amp;&amp; %{
RQ().m2(arg2);
%}
struct RQ {
void m1(int x) &amp;;
void m2(int x) &amp;&amp;;
};
</pre></div>
<p>
resulting in:
</p>
<div class="code"><pre>
RQ *arg1 = (RQ *) 0 ;
int arg2 ;
arg1 = ...marshalled from target language...
arg2 = ...marshalled from target language...
RQ().m2(arg2);
</pre></div>
<p>
<b>Compatibility note:</b> SWIG-4.0.0 was the first version to support ref-qualifiers.
</p>
<H2><a name="CPlusPlus11_standard_library_changes">7.3 Standard library changes</a></H2>
@ -994,7 +1112,8 @@ Variadic template support requires further work to provide substantial tuple wra
<p>
The new hash tables in the STL are <tt>unordered_set</tt>, <tt>unordered_multiset</tt>, <tt>unordered_map</tt>, <tt>unordered_multimap</tt>.
These are not available in SWIG, but in principle should be easily implemented by adapting the current STL containers.
These are not available in all target languages.
Any missing support can in principle be easily implemented by adapting the current STL containers.
</p>
<H3><a name="CPlusPlus11_regular_expressions">7.3.4 Regular expressions</a></H3>
@ -1057,7 +1176,7 @@ It does not involve <tt>std::function</tt>.
<div class="targetlang"><pre>
t = Test()
b = t(1,2) # invoke C++ function object
b = t(1, 2) # invoke C++ function object
</pre></div>
<H3><a name="CPlusPlus11_type_traits_for_metaprogramming">7.3.9 Type traits for metaprogramming</a></H3>
@ -1175,5 +1294,6 @@ Phew, that is a lot of hard work to get a callback working.
You could just go with the more attractive option of just using <tt>double</tt> as the return type in the function declaration instead of <tt>result_of</tt>!
</p>
</body>
</html>

60
Doc/Manual/CPlusPlus14.html Normal file
View file

@ -0,0 +1,60 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>SWIG and C++14</title>
<link rel="stylesheet" type="text/css" href="style.css">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#ffffff">
<H1><a name="CPlusPlus14">8 SWIG and C++14</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="#CPlusPlus14_introduction">Introduction</a>
<li><a href="#CPlusPlus14_core_language_changes">Core language changes</a>
<ul>
<li><a href="#CPlusPlus14_binary_literals">Binary integer literals</a>
</ul>
<li><a href="#CPlusPlus14_standard_library_changes">Standard library changes</a>
</ul>
</div>
<!-- INDEX -->
<H2><a name="CPlusPlus14_introduction">8.1 Introduction</a></H2>
<p>This chapter gives you a brief overview about the SWIG
implementation of the C++14 standard.
There isn't much in C++14 that affects SWIG, however, work has only just begun on adding
C++14 support.
</p>
<p>
<b>Compatibility note:</b> SWIG-4.0.0 is the first version to support any C++14 features.
</p>
<H2><a name="CPlusPlus14_core_language_changes">8.2 Core language changes</a></H2>
<H3><a name="CPlusPlus14_binary_literals">8.2.1 Binary integer literals</a></H3>
<p>
C++14 added binary integer literals and SWIG supports these.
Example:
</p>
<div class="code">
<pre>
int b = 0b101011;
</pre>
</div>
<H2><a name="CPlusPlus14_standard_library_changes">8.3 Standard library changes</a></H2>
</body>
</html>

109
Doc/Manual/CPlusPlus17.html Normal file
View file

@ -0,0 +1,109 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>SWIG and C++17</title>
<link rel="stylesheet" type="text/css" href="style.css">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#ffffff">
<H1><a name="CPlusPlus17">9 SWIG and C++17</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="#CPlusPlus17_introduction">Introduction</a>
<li><a href="#CPlusPlus17_core_language_changes">Core language changes</a>
<ul>
<li><a href="#CPlusPlus17_nested_namespaces">Nested namespace definitions</a>
<li><a href="#CPlusPlus17_u8_char_literals">UTF-8 character literals</a>
<li><a href="#CPlusPlus17_hexadecimal_floating_literals">Hexadecimal floating literals</a>
</ul>
<li><a href="#CPlusPlus17_standard_library_changes">Standard library changes</a>
</ul>
</div>
<!-- INDEX -->
<H2><a name="CPlusPlus17_introduction">9.1 Introduction</a></H2>
<p>This chapter gives you a brief overview about the SWIG
implementation of the C++17 standard.
There isn't much in C++17 that affects SWIG, however, work has only just begun on adding
C++17 support.
</p>
<p>
<b>Compatibility note:</b> SWIG-4.0.0 is the first version to support any C++17 features.
</p>
<H2><a name="CPlusPlus17_core_language_changes">9.2 Core language changes</a></H2>
<H3><a name="CPlusPlus17_nested_namespaces">9.2.1 Nested namespace definitions</a></H3>
<p>
C++17 offers a more concise syntax for defining namespaces.
SWIG has support for nested namespace definitions such as:
</p>
<div class="code">
<pre>
namespace A::B::C {
...
}
</pre>
</div>
<p>
This is the equivalent to the C++98 namespace definitions:
</p>
<div class="code">
<pre>
namespace A {
namespace B {
namespace C {
...
}
}
}
</pre>
</div>
<H3><a name="CPlusPlus17_u8_char_literals">9.2.2 UTF-8 character literals</a></H3>
<p>
C++17 added UTF-8 (u8) character literals.
These are of type char.
Example:
</p>
<div class="code">
<pre>
char a = u8'a';
</pre>
</div>
<H3><a name="CPlusPlus17_hexadecimal_floating_literals">9.2.3 Hexadecimal floating literals</a></H3>
<p>
C++17 added hexadecimal floating literals.
For example:
</p>
<div class="code">
<pre>
double f = 0xF.68p2;
</pre>
</div>
<H2><a name="CPlusPlus17_standard_library_changes">9.3 Standard library changes</a></H2>
</body>
</html>

427
Doc/Manual/CSharp.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="CSharp">20 SWIG and C#</a></H1>
<H1><a name="CSharp">22 SWIG and C#</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -44,7 +44,8 @@
<li><a href="#CSharp_date_marshalling">Date marshalling using the csin typemap and associated attributes</a>
<li><a href="#CSharp_date_properties">A date example demonstrating marshalling of C# properties</a>
<li><a href="#CSharp_date_pre_post_directors">Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a>
<li><a href="#CSharp_partial_classes">Turning wrapped classes into partial classes</a>
<li><a href="#CSharp_partial_classes">Turning proxy classes into partial classes</a>
<li><a href="#CSharp_sealed_proxy_class">Turning proxy classes into sealed classes</a>
<li><a href="#CSharp_extending_proxy_class">Extending proxy classes with additional C# code</a>
<li><a href="#CSharp_enum_underlying_type">Underlying type for enums</a>
</ul>
@ -54,7 +55,7 @@
<H2><a name="CSharp_introduction">20.1 Introduction</a></H2>
<H2><a name="CSharp_introduction">22.1 Introduction</a></H2>
<p>
@ -63,18 +64,18 @@ The wrapper code implementation uses C# and the Platform Invoke (PInvoke) interf
The PInvoke interface has been chosen over Microsoft's Managed C++ interface as it is portable to both Microsoft Windows and non-Microsoft platforms.
PInvoke is part of the ECMA/ISO C# specification.
It is also better suited for robust production environments due to the Managed C++ flaw called the
<a href="http://msdn.microsoft.com/en-us/library/aa290048(VS.71).aspx">Mixed DLL Loading Problem</a>.
<a href="https://msdn.microsoft.com/en-us/ie/aa290048(v=vs.94)">Mixed DLL Loading Problem</a>.
SWIG C# works equally well on non-Microsoft operating systems such as Linux, Solaris and Apple Mac using
<a href="http://www.mono-project.com/Main_Page">Mono</a> and <a href="http://www.dotgnu.org/pnet.html">Portable.NET</a>.
<a href="https://www.mono-project.com/Main_Page/">Mono</a> and <a href="http://www.dotgnu.org/pnet.html">Portable.NET</a>.
</p>
<p>
To get the most out of this chapter an understanding of interop is required.
The <a href="http://msdn.microsoft.com">Microsoft Developer Network (MSDN)</a> has a good reference guide in a section titled "Interop Marshaling".
Monodoc, available from the Mono project, has a very useful section titled <a href="http://www.mono-project.com/docs/advanced/pinvoke/">Interop with native libraries</a>.
The <a href="https://msdn.microsoft.com">Microsoft Developer Network (MSDN)</a> has a good reference guide in a section titled "Interop Marshaling".
Monodoc, available from the Mono project, has a very useful section titled <a href="https://www.mono-project.com/docs/advanced/pinvoke/">Interop with native libraries</a>.
</p>
<H3><a name="CSharp_introduction_swig2_compatibility">20.1.1 SWIG 2 Compatibility</a></H3>
<H3><a name="CSharp_introduction_swig2_compatibility">22.1.1 SWIG 2 Compatibility</a></H3>
<p>
@ -82,7 +83,7 @@ In order to minimize name collisions between names generated based on input to S
</p>
<H3><a name="CSharp_commandline">20.1.2 Additional command line options</a></H3>
<H3><a name="CSharp_commandline">22.1.2 Additional command line options</a></H3>
<p>
@ -134,7 +135,7 @@ Note that the file extension (.cs) will not be automatically added and needs to
Due to possible compiler limits it is not advisable to use <tt>-outfile</tt> for large projects.
</p>
<H2><a name="CSharp_differences_java">20.2 Differences to the Java module</a></H2>
<H2><a name="CSharp_differences_java">22.2 Differences to the Java module</a></H2>
<p>
@ -231,8 +232,8 @@ javacode -&gt; cscode
javaimports -&gt; csimports
javabody -&gt; csbody
javafinalize -&gt; csfinalize
javadestruct -&gt; csdestruct
javadestruct_derived -&gt; csdestruct_derived
javadestruct -&gt; csdisposing and csdispose
javadestruct_derived -&gt; csdisposing_derived and csdispose_derived
javainterfacecode -&gt; csinterfacecode
</pre></div>
@ -544,14 +545,18 @@ unless the imclassname attribute is specified in the <a href="CSharp.html#CSharp
<p>
The directory <tt>Examples/csharp</tt> has a number of simple examples.
Visual Studio .NET 2003 solution and project files are available for compiling with the Microsoft .NET C# compiler on Windows.
If your SWIG installation went well on a Unix environment and your C# compiler was detected, you should be able to type <tt>make</tt> in each example directory,
then <tt>ilrun runme.exe</tt> (Portable.NET C# compiler) or <tt>mono runme.exe</tt> (Mono C# compiler) to run the examples.
Visual Studio .NET 2003 solution and project files are available for compiling with the Microsoft .NET C#
compiler on Windows. This also works with newer versions of Visual Studio if you allow
it to convert the solution to the latest version.
If your SWIG installation went well on a Unix environment and your C# compiler was detected, you should be able to type <tt>make</tt> in each example directory.
After SWIG has run and both the C# and C/C++ compilers have finished building,
the examples will be run, by either running <tt>runme.exe</tt> or by running
<tt>mono runme.exe</tt> (Mono C# compiler).
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.
Any one of the C# compilers (Mono or Microsoft) can be detected from within a Cygwin or Mingw environment if installed in your path.
<H2><a name="CSharp_void_pointers">20.3 Void pointers</a></H2>
<H2><a name="CSharp_void_pointers">22.3 Void pointers</a></H2>
<p>
@ -569,7 +574,7 @@ void * f(void *v);
</pre>
</div>
<H2><a name="CSharp_arrays">20.4 C# Arrays</a></H2>
<H2><a name="CSharp_arrays">22.4 C# Arrays</a></H2>
<p>
@ -581,7 +586,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">20.4.1 The SWIG C arrays library</a></H3>
<H3><a name="CSharp_arrays_swig_library">22.4.1 The SWIG C arrays library</a></H3>
<p>
@ -598,7 +603,7 @@ For the <tt>%array_functions</tt> example, the equivalent usage would be:
<pre>
SWIGTYPE_p_double a = example.new_doubleArray(10); // Create an array
for (int i=0; i&lt;10; i++)
example.doubleArray_setitem(a,i,2*i); // Set a value
example.doubleArray_setitem(a, i, 2*i); // Set a value
example.print_array(a); // Pass to C
example.delete_doubleArray(a); // Destroy array
</pre>
@ -618,7 +623,7 @@ example.print_array(c.cast()); // Pass to C
</div>
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling">20.4.2 Managed arrays using P/Invoke default array marshalling</a></H3>
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling">22.4.2 Managed arrays using P/Invoke default array marshalling</a></H3>
<p>
@ -638,7 +643,7 @@ passing a direct reference as described in the next section.
<p>
For more information on the subject, see the
<a href="http://msdn.microsoft.com/en-us/library/z6cfh6e6(VS.80).aspx">Default Marshaling for Arrays</a> article
<a href="https://docs.microsoft.com/en-us/dotnet/framework/interop/default-marshaling-for-arrays">Default Marshaling for Arrays</a> article
on MSDN.
</p>
@ -673,7 +678,7 @@ As a result, we get the following method in the module class:
<div class="code">
<pre>
public static void myArrayCopy(int[] sourceArray, int[] targetArray, int nitems) {
examplePINVOKE.myArrayCopy(sourceArray, targetArray, nitems);
examplePINVOKE.myArrayCopy(sourceArray, targetArray, nitems);
}
</pre>
</div>
@ -745,7 +750,7 @@ and intermediary class method
</div>
<H3><a name="CSharp_arrays_pinning">20.4.3 Managed arrays using pinning</a></H3>
<H3><a name="CSharp_arrays_pinning">22.4.3 Managed arrays using pinning</a></H3>
<p>
@ -758,7 +763,7 @@ another thread may produce enough garbage to trigger garbage collection.
</p>
<p>
For more information, see the <a href="http://msdn.microsoft.com/en-us/library/f58wzh21(VS.80).aspx">fixed statement</a> in the C# language reference.
For more information, see the <a href="https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/fixed-statement">fixed statement</a> in the C# language reference.
</p>
@ -840,7 +845,7 @@ public static extern void myArrayCopy(global::System.IntPtr jarg1, global::Syste
<H2><a name="CSharp_exceptions">20.5 C# Exceptions</a></H2>
<H2><a name="CSharp_exceptions">22.5 C# Exceptions</a></H2>
<p>
@ -937,7 +942,7 @@ set so should only be used when a C# exception is not created.
</p>
<H3><a name="CSharp_exception_example_check_typemap">20.5.1 C# exception example using "check" typemap</a></H3>
<H3><a name="CSharp_exception_example_check_typemap">22.5.1 C# exception example using "check" typemap</a></H3>
<p>
@ -993,9 +998,9 @@ When the following C# code is executed:
<div class="code">
<pre>
public class runme {
static void Main() {
example.positivesonly(-1);
}
static void Main() {
example.positivesonly(-1);
}
}
</pre>
</div>
@ -1021,18 +1026,18 @@ Now let's analyse the generated code to gain a fuller understanding of the typem
<div class="code">
<pre>
SWIGEXPORT void SWIGSTDCALL CSharp_positivesonly(int jarg1) {
int arg1 ;
arg1 = (int)jarg1;
if (arg1 &lt; 0) {
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException,
"only positive numbers accepted", "number");
return ;
}
positivesonly(arg1);
int arg1 ;
arg1 = (int)jarg1;
if (arg1 &lt; 0) {
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException,
"only positive numbers accepted", "number");
return ;
}
positivesonly(arg1);
}
</pre>
</div>
@ -1119,7 +1124,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">20.5.2 C# exception example using %exception</a></H3>
<H3><a name="CSharp_exception_example_percent_exception">22.5.2 C# exception example using %exception</a></H3>
<p>
@ -1155,18 +1160,17 @@ The generated unmanaged code this time catches the C++ exception and converts it
<div class="code">
<pre>
SWIGEXPORT void SWIGSTDCALL CSharp_negativesonly(int jarg1) {
int arg1 ;
arg1 = (int)jarg1;
try {
negativesonly(arg1);
} catch (std::out_of_range e) {
SWIG_CSharpSetPendingException(SWIG_CSharpApplicationException, e.what());
return ;
}
int arg1 ;
arg1 = (int)jarg1;
try {
negativesonly(arg1);
} catch (std::out_of_range e) {
SWIG_CSharpSetPendingException(SWIG_CSharpApplicationException, e.what());
return ;
}
}
</pre>
</div>
@ -1185,7 +1189,7 @@ The managed code generated does check for the pending exception as mentioned ear
</pre>
</div>
<H3><a name="CSharp_exception_example_exception_specifications">20.5.3 C# exception example using exception specifications</a></H3>
<H3><a name="CSharp_exception_example_exception_specifications">22.5.3 C# exception example using exception specifications</a></H3>
<p>
@ -1221,19 +1225,18 @@ SWIG generates a try catch block with the throws typemap code in the catch handl
<div class="code">
<pre>
SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
int arg1 ;
arg1 = (int)jarg1;
try {
evensonly(arg1);
int arg1 ;
arg1 = (int)jarg1;
try {
evensonly(arg1);
}
catch(std::out_of_range &amp;_e) {
{
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentException, (&amp;_e)-&gt;what(), NULL);
return ;
}
catch(std::out_of_range &amp;_e) {
{
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentException, (&amp;_e)-&gt;what(), NULL);
return ;
}
}
}
}
</pre>
</div>
@ -1242,7 +1245,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">20.5.4 Custom C# ApplicationException example</a></H3>
<H3><a name="CSharp_custom_application_exception">22.5.4 Custom C# ApplicationException example</a></H3>
<p>
@ -1376,7 +1379,7 @@ try {
</pre>
</div>
<H2><a name="CSharp_directors">20.6 C# Directors</a></H2>
<H2><a name="CSharp_directors">22.6 C# Directors</a></H2>
<p>
@ -1389,7 +1392,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">20.6.1 Directors example</a></H3>
<H3><a name="CSharp_directors_example">22.6.1 Directors example</a></H3>
<p>
@ -1510,7 +1513,7 @@ CSharpDerived - UIntMethod(123)
</pre>
</div>
<H3><a name="CSharp_directors_implementation">20.6.2 Directors implementation</a></H3>
<H3><a name="CSharp_directors_implementation">22.6.2 Directors implementation</a></H3>
<p>
@ -1572,9 +1575,9 @@ public class Base : global::System.IDisposable {
private void SwigDirectorConnect() {
if (SwigDerivedClassHasMethod("UIntMethod", swigMethodTypes0))
swigDelegate0 = new SwigDelegateBase_0(SwigDirectorUIntMethod);
swigDelegate0 = new SwigDelegateBase_0(SwigDirectorMethodUIntMethod);
if (SwigDerivedClassHasMethod("BaseBoolMethod", swigMethodTypes1))
swigDelegate1 = new SwigDelegateBase_1(SwigDirectorBaseBoolMethod);
swigDelegate1 = new SwigDelegateBase_1(SwigDirectorMethodBaseBoolMethod);
examplePINVOKE.Base_director_connect(swigCPtr, swigDelegate0, swigDelegate1);
}
@ -1584,16 +1587,16 @@ public class Base : global::System.IDisposable {
return hasDerivedMethod;
}
private uint SwigDirectorUIntMethod(uint x) {
private uint SwigDirectorMethodUIntMethod(uint x) {
return UIntMethod(x);
}
private void SwigDirectorBaseBoolMethod(global::System.IntPtr b, bool flag) {
private void SwigDirectorMethodBaseBoolMethod(global::System.IntPtr b, bool flag) {
BaseBoolMethod(new Base(b, false), flag);
}
internal delegate uint SwigDelegateBase_0(uint x);
internal delegate void SwigDelegateBase_1(global::System.IntPtr b, bool flag);
public delegate uint SwigDelegateBase_0(uint x);
public delegate void SwigDelegateBase_1(global::System.IntPtr b, bool flag);
private SwigDelegateBase_0 swigDelegate0;
private SwigDelegateBase_1 swigDelegate1;
@ -1617,9 +1620,9 @@ It uses a support method, <tt>SwigDerivedClassHasMethod()</tt>, which simply use
BaseBoolMethod, with the list of required parameter types, exists in a subclass.
If it does not exist, the delegate is not initialised as there is no need for unmanaged code to call back into managed C# code.
However, if there is an overridden method in any subclass, the delegate is required.
It is then initialised to the <tt>SwigDirectorBaseBoolMethod</tt> which in turn will call <tt>BaseBoolMethod</tt> if invoked.
It is then initialised to the <tt>SwigDirectorMethodBaseBoolMethod</tt> which in turn will call <tt>BaseBoolMethod</tt> if invoked.
The delegate is not initialised to the <tt>BaseBoolMethod</tt> directly as quite often types will need marshalling from the unmanaged type
to the managed type in which case an intermediary method (<tt>SwigDirectorBaseBoolMethod</tt>) is required for the marshalling.
to the managed type in which case an intermediary method (<tt>SwigDirectorMethodBaseBoolMethod</tt>) is required for the marshalling.
In this case, the C# <tt>Base</tt> class needs to be created from the unmanaged <tt>IntPtr</tt> type.
</p>
@ -1643,20 +1646,20 @@ SWIGEXPORT void SWIGSTDCALL CSharp_Base_director_connect(void *objarg,
class SwigDirector_Base : public Base, public Swig::Director {
public:
SwigDirector_Base();
virtual unsigned int UIntMethod(unsigned int x);
virtual ~SwigDirector_Base();
virtual void BaseBoolMethod(Base const &amp;b, bool flag);
SwigDirector_Base();
virtual unsigned int UIntMethod(unsigned int x);
virtual ~SwigDirector_Base();
virtual void BaseBoolMethod(Base const &amp;b, bool flag);
typedef unsigned int (SWIGSTDCALL* SWIG_Callback0_t)(unsigned int);
typedef void (SWIGSTDCALL* SWIG_Callback1_t)(void *, unsigned int);
void swig_connect_director(SWIG_Callback0_t callbackUIntMethod,
SWIG_Callback1_t callbackBaseBoolMethod);
typedef unsigned int (SWIGSTDCALL* SWIG_Callback0_t)(unsigned int);
typedef void (SWIGSTDCALL* SWIG_Callback1_t)(void *, unsigned int);
void swig_connect_director(SWIG_Callback0_t callbackUIntMethod,
SWIG_Callback1_t callbackBaseBoolMethod);
private:
SWIG_Callback0_t swig_callbackUIntMethod;
SWIG_Callback1_t swig_callbackBaseBoolMethod;
void swig_init_callbacks();
SWIG_Callback0_t swig_callbackUIntMethod;
SWIG_Callback1_t swig_callbackBaseBoolMethod;
void swig_init_callbacks();
};
void SwigDirector_Base::swig_connect_director(SWIG_Callback0_t callbackUIntMethod,
@ -1682,7 +1685,7 @@ void SwigDirector_Base::BaseBoolMethod(Base const &amp;b, bool flag) {
unsigned int jflag ;
if (!swig_callbackBaseBoolMethod) {
Base::BaseBoolMethod(b,flag);
Base::BaseBoolMethod(b, flag);
return;
} else {
jb = (Base *) &amp;b;
@ -1693,7 +1696,32 @@ void SwigDirector_Base::BaseBoolMethod(Base const &amp;b, bool flag) {
</pre>
</div>
<H3><a name="CSharp_director_caveats">20.6.3 Director caveats</a></H3>
<p>
The delegates from the above example are <tt>public</tt> by default:
</p>
<div class="code">
<pre>
public delegate uint SwigDelegateBase_0(uint x);
public delegate void SwigDelegateBase_1(global::System.IntPtr b, bool flag);
</pre>
</div>
<p>
These can be changed if desired via the <tt>csdirectordelegatemodifiers</tt>
<a href="Customization.html#Customization_features">%feature directive</a>.
For example, using <tt>%feature("csdirectordelegatemodifiers") "internal"</tt>
before SWIG parses the Base class will change all the delegates to <tt>internal</tt>:
</p>
<div class="code">
<pre>
internal delegate uint SwigDelegateBase_0(uint x);
internal delegate void SwigDelegateBase_1(global::System.IntPtr b, bool flag);
</pre>
</div>
<H3><a name="CSharp_director_caveats">22.6.3 Director caveats</a></H3>
<p>
@ -1741,11 +1769,11 @@ 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">20.7 Multiple modules</a></H2>
<H2><a name="CSharp_multiple_modules">22.7 Multiple modules</a></H2>
<p>
When using <a href="Modules.html#Modules">multiple modules</a> it is is possible to compile each SWIG generated wrapper
When using <a href="Modules.html#Modules">multiple modules</a> it is possible to compile each SWIG generated wrapper
into a different assembly.
However, by default the generated code may not compile if
generated classes in one assembly use generated classes in another assembly.
@ -1776,7 +1804,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">20.8 C# Typemap examples</a></H2>
<H2><a name="CSharp_typemap_examples">22.8 C# Typemap examples</a></H2>
This section includes a few examples of typemaps. For more examples, you
@ -1784,7 +1812,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">20.8.1 Memory management when returning references to member variables</a></H3>
<H3><a name="CSharp_memory_management_member_variables">22.8.1 Memory management when returning references to member variables</a></H3>
<p>
@ -1800,7 +1828,7 @@ Consider the following C++ code:
<pre>
struct Wheel {
int size;
Wheel(int sz) : size(sz) {}
Wheel(int sz = 0) : size(sz) {}
};
class Bike {
@ -1819,12 +1847,12 @@ and the following usage from C# after running the code through SWIG:
<div class="code">
<pre>
Wheel wheel = new Bike(10).getWheel();
Console.WriteLine("wheel size: " + wheel.size);
// Simulate a garbage collection
global::System.GC.Collect();
global::System.GC.WaitForPendingFinalizers();
global::System.Console.WriteLine("wheel size: " + wheel.size);
Wheel wheel = new Bike(10).getWheel();
Console.WriteLine("wheel size: " + wheel.size);
// Simulate a garbage collection
global::System.GC.Collect();
global::System.GC.WaitForPendingFinalizers();
global::System.Console.WriteLine("wheel size: " + wheel.size);
</pre>
</div>
@ -1908,7 +1936,7 @@ public class Bike : global::System.IDisposable {
Note the <tt>addReference</tt> call.
</p>
<H3><a name="CSharp_memory_management_objects">20.8.2 Memory management for objects passed to the C++ layer</a></H3>
<H3><a name="CSharp_memory_management_objects">22.8.2 Memory management for objects passed to the C++ layer</a></H3>
<p>
@ -1940,10 +1968,10 @@ and usage from C++
<div class="code">
<pre>
Container container;
Element element(20);
container.setElement(&amp;element);
cout &lt;&lt; "element.value: " &lt;&lt; container.getElement()-&gt;value &lt;&lt; endl;
Container container;
Element element(20);
container.setElement(&amp;element);
cout &lt;&lt; "element.value: " &lt;&lt; container.getElement()-&gt;value &lt;&lt; endl;
</pre>
</div>
@ -1953,27 +1981,27 @@ and more or less equivalent usage from C#
<div class="code">
<pre>
Container container = new Container();
Element element = new Element(20);
container.setElement(element);
Container container = new Container();
Element element = new Element(20);
container.setElement(element);
</pre>
</div>
<p>
The C++ code will always print out 20, but the value printed out may not be this in the C# equivalent code.
In order to understand why, consider a garbage collection occuring...
In order to understand why, consider a garbage collection occurring...
</p>
<div class="code">
<pre>
Container container = new Container();
Element element = new Element(20);
container.setElement(element);
Console.WriteLine("element.value: " + container.getElement().value);
// Simulate a garbage collection
global::System.GC.Collect();
global::System.GC.WaitForPendingFinalizers();
global::System.Console.WriteLine("element.value: " + container.getElement().value);
Container container = new Container();
Element element = new Element(20);
container.setElement(element);
Console.WriteLine("element.value: " + container.getElement().value);
// Simulate a garbage collection
global::System.GC.Collect();
global::System.GC.WaitForPendingFinalizers();
global::System.Console.WriteLine("element.value: " + container.getElement().value);
</pre>
</div>
@ -1992,42 +2020,55 @@ 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 global::System.Runtime.InteropServices.HandleRef getCPtrAndAddReference(Element element) {
elementReference = element;
return Element.getCPtr(element);
}
public void setElement(Element e) {
examplePINVOKE.Container_setElement(swigCPtr, getCPtrAndAddReference(e));
examplePINVOKE.Container_setElement(swigCPtr, Element.getCPtr(e));
elementReference = e;
}
}
</pre>
</div>
<p>
The following typemaps will generate the desired code.
The 'csin' typemap matches the input parameter type for the <tt>setElement</tt> method.
The 'cscode' typemap simply adds in the specified code into the C# proxy class.
The following typemaps can be used to generate this code:
</p>
<div class="code">
<pre>
%typemap(csin) Element *e "getCPtrAndAddReference($csinput)"
%typemap(cscode) Container %{
// 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 global::System.Runtime.InteropServices.HandleRef getCPtrAndAddReference(Element element) {
elementReference = element;
return Element.getCPtr(element);
}
%}
%typemap(csin,
post=" elementReference = $csinput;"
) Element *e "Element.getCPtr($csinput)"
</pre>
</div>
<p>
The 'cscode' typemap simply adds in the specified code into the C# proxy class.
The 'csin' typemap matches the input parameter type and name for the <tt>setElement</tt> method and
the 'post' typemap attribute allows adding code after the PInvoke call.
The 'post' code is generated into a finally block after the PInvoke call so the resulting code isn't quite
as mentioned earlier, <tt>setElement</tt> is actually:
</p>
<div class="code">
<pre>
public void setElement(Element e) {
try {
examplePINVOKE.Container_setElement(swigCPtr, Element.getCPtr(e));
} finally {
elementReference = e;
}
}
</pre>
</div>
<H3><a name="CSharp_date_marshalling">20.8.3 Date marshalling using the csin typemap and associated attributes</a></H3>
<H3><a name="CSharp_date_marshalling">22.8.3 Date marshalling using the csin typemap and associated attributes</a></H3>
<p>
@ -2100,7 +2141,7 @@ The <tt>CDate &amp;</tt> and <tt>const CDate &amp;</tt> C# code is generated fro
<p>
where '$csclassname' is translated into the proxy class name, <tt>CDate</tt> and '$csinput' is translated into the name of the parameter, eg <tt>dateIn</tt>.
From C#, the intention is then to call into a modifed API with something like:
From C#, the intention is then to call into a modified API with something like:
</p>
<div class="code">
@ -2134,7 +2175,7 @@ The typemaps to achieve this are shown below.
%typemap(csin,
pre=" CDate temp$csinput = new CDate();",
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
cshin="out $csinput"
) CDate &amp;
"$csclassname.getCPtr(temp$csinput)"
@ -2240,7 +2281,7 @@ will be possible with the following <tt>CDate *</tt> typemaps
%typemap(csin,
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);",
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
cshin="ref $csinput"
) CDate *
"$csclassname.getCPtr(temp$csinput)"
@ -2279,7 +2320,7 @@ The <tt>subtractYears</tt> method is nearly identical to the above <tt>addYears<
%typemap(csin,
pre=" using (CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day)) {",
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
terminator=" } // terminate temp$csinput using block",
cshin="ref $csinput"
) CDate *
@ -2313,7 +2354,7 @@ public class example {
</pre>
</div>
<H3><a name="CSharp_date_properties">20.8.4 A date example demonstrating marshalling of C# properties</a></H3>
<H3><a name="CSharp_date_properties">22.8.4 A date example demonstrating marshalling of C# properties</a></H3>
<p>
@ -2351,7 +2392,7 @@ The typemap type required is thus <tt>CDate *</tt>. Given that the previous sect
%typemap(csin,
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);",
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
" temp$csinput.getMonth(), temp$csinput.getDay(), 0, 0, 0);",
cshin="ref $csinput"
) CDate *
"$csclassname.getCPtr(temp$csinput)"
@ -2413,7 +2454,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">20.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a></H3>
<H3><a name="CSharp_date_pre_post_directors">22.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a></H3>
<p>
@ -2456,7 +2497,7 @@ The generated proxy class code will then contain the following wrapper for calli
<div class="code"><pre>
...
private void SwigDirectorsomeCallback(global::System.IntPtr date) {
private void SwigDirectorMethodsomeCallback(global::System.IntPtr date) {
System.DateTime tempdate = new System.DateTime();
try {
someCallback(out tempdate);
@ -2475,7 +2516,7 @@ Pay special attention to the memory management issues, using these attributes.
</p>
<H3><a name="CSharp_partial_classes">20.8.6 Turning wrapped classes into partial classes</a></H3>
<H3><a name="CSharp_partial_classes">22.8.6 Turning proxy classes into partial classes</a></H3>
<p>
@ -2575,7 +2616,97 @@ 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">20.8.7 Extending proxy classes with additional C# code</a></H3>
<H3><a name="CSharp_sealed_proxy_class">22.8.7 Turning proxy classes into sealed classes</a></H3>
<p>
The technique in the previous section can be used to make the proxy class a sealed class.
Consider a C++ class <tt>NotABaseClass</tt> that you don't want to be derived from in C#:
</p>
<div class="code">
<pre>
struct NotABaseClass {
NotABaseClass();
~NotABaseClass();
};
</pre>
</div>
<p>
The default C# proxy class method generated with Dispose method is:
</p>
<div class="code">
<pre>
public class NotABaseClass : global::System.IDisposable {
...
public virtual void Dispose() {
...
}
}
</pre>
</div>
<p>
The <tt>csclassmodifiers</tt> typemap can be used to modify the class modifiers and
the <tt>csmethodmodifiers</tt> feature can be used on the destructor to modify the proxy's <tt>Dispose</tt> method:
</p>
<div class="code">
<pre>
%typemap(csclassmodifiers) NotABaseClass "public sealed class"
%csmethodmodifiers NotABaseClass::~NotABaseClass "public /*virtual*/";
</pre>
</div>
<p>
The relevant generated code is thus:
</p>
<div class="code">
<pre>
public sealed class NotABaseClass : global::System.IDisposable {
...
public /*virtual*/ void Dispose() {
...
}
}
</pre>
</div>
<p>
Any attempt to derive from the <tt>NotABaseClass</tt> in C# will result in a C# compiler error, for example:
</p>
<div class="code">
<pre>
public class Derived : NotABaseClass {
};
</pre>
</div>
<div class="shell">
<pre>
runme.cs(6,14): error CS0509: `Derived': cannot derive from sealed type `NotABaseClass'
</pre>
</div>
<p>
Finally, if you get a warning about use of 'protected' in the generated base class:
</p>
<div class="shell">
<pre>
NotABaseClass.cs(14,18): warning CS0628: `NotABaseClass.swigCMemOwn': new protected member declared in sealed class
</pre>
</div>
<p>
Either suppress the warning or modify the generated code by copying and tweaking the default
'csbody' typemap code in csharp.swg by modifying swigCMemOwn to not be protected.
</p>
<H3><a name="CSharp_extending_proxy_class">22.8.8 Extending proxy classes with additional C# code</a></H3>
<p>
@ -2614,13 +2745,13 @@ public class ExtendMe : global::System.IDisposable {
</pre>
</div>
<H3><a name="CSharp_enum_underlying_type">20.8.8 Underlying type for enums</a></H3>
<H3><a name="CSharp_enum_underlying_type">22.8.9 Underlying type for enums</a></H3>
<P>
C# enums use int as the underlying type for each enum item.
If you wish to change the underlying type to something else, then use the <tt>csbase</tt> typemap.
For example when your C++ code uses a value larget than int, this is necessary as the C# compiler will not compile values which are too large to fit into an int.
For example when your C++ code uses a value larger than int, this is necessary as the C# compiler will not compile values which are too large to fit into an int.
Here is an example:
</p>

44
Doc/Manual/Chicken.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Chicken">21 SWIG and Chicken</a></H1>
<H1><a name="Chicken">23 SWIG and Chicken</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -72,7 +72,7 @@
</p>
<H2><a name="Chicken_nn2">21.1 Preliminaries</a></H2>
<H2><a name="Chicken_nn2">23.1 Preliminaries</a></H2>
<p>
@ -89,7 +89,7 @@
directory for the basic steps to run SWIG CHICKEN.
</p>
<H3><a name="Chicken_nn3">21.1.1 Running SWIG in C mode</a></H3>
<H3><a name="Chicken_nn3">23.1.1 Running SWIG in C mode</a></H3>
<p>
@ -122,7 +122,7 @@
object files and linked into your project.
</p>
<H3><a name="Chicken_nn4">21.1.2 Running SWIG in C++ mode</a></H3>
<H3><a name="Chicken_nn4">23.1.2 Running SWIG in C++ mode</a></H3>
<p>
@ -151,10 +151,10 @@
object files and linked into your project.
</p>
<H2><a name="Chicken_nn5">21.2 Code Generation</a></H2>
<H2><a name="Chicken_nn5">23.2 Code Generation</a></H2>
<H3><a name="Chicken_nn6">21.2.1 Naming Conventions</a></H3>
<H3><a name="Chicken_nn6">23.2.1 Naming Conventions</a></H3>
<p>
@ -170,7 +170,7 @@
<tt>%rename</tt> SWIG directive in the SWIG interface file.
</p>
<H3><a name="Chicken_nn7">21.2.2 Modules</a></H3>
<H3><a name="Chicken_nn7">23.2.2 Modules</a></H3>
<p>
@ -192,7 +192,7 @@
(uses <i>modulename</i>))</code> CHICKEN Scheme form.
</p>
<H3><a name="Chicken_nn8">21.2.3 Constants and Variables</a></H3>
<H3><a name="Chicken_nn8">23.2.3 Constants and Variables</a></H3>
<p>
@ -229,7 +229,7 @@
for info on how to apply the %feature.
</p>
<H3><a name="Chicken_nn9">21.2.4 Functions</a></H3>
<H3><a name="Chicken_nn9">23.2.4 Functions</a></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">21.2.5 Exceptions</a></H3>
<H3><a name="Chicken_nn10">23.2.5 Exceptions</a></H3>
<p>The SWIG chicken module has support for exceptions thrown from
@ -290,14 +290,14 @@
</pre></div>
<H2><a name="Chicken_nn11">21.3 TinyCLOS</a></H2>
<H2><a name="Chicken_nn11">23.3 TinyCLOS</a></H2>
<p>
The author of TinyCLOS, Gregor Kiczales, describes TinyCLOS as:
"Tiny CLOS is a Scheme implementation of a `kernelized' CLOS, with a
"Tiny CLOS is a Scheme implementation of a 'kernelized' CLOS, with a
metaobject protocol. The implementation is even simpler than
the simple CLOS found in `The Art of the Metaobject Protocol,'
the simple CLOS found in 'The Art of the Metaobject Protocol',
weighing in at around 850 lines of code, including (some)
comments and documentation."
</p>
@ -333,7 +333,7 @@
</p>
<H2><a name="Chicken_nn12">21.4 Linkage</a></H2>
<H2><a name="Chicken_nn12">23.4 Linkage</a></H2>
<p>
@ -354,7 +354,7 @@
</p>
<H3><a name="Chicken_nn13">21.4.1 Static binary or shared library linked at compile time</a></H3>
<H3><a name="Chicken_nn13">23.4.1 Static binary or shared library linked at compile time</a></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">21.4.2 Building chicken extension libraries</a></H3>
<H3><a name="Chicken_nn14">23.4.2 Building chicken extension libraries</a></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">21.4.3 Linking multiple SWIG modules with TinyCLOS</a></H3>
<H3><a name="Chicken_nn15">23.4.3 Linking multiple SWIG modules with TinyCLOS</a></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">21.5 Typemaps</a></H2>
<H2><a name="Chicken_nn16">23.5 Typemaps</a></H2>
<p>
@ -486,7 +486,7 @@ all the modules.</p>
<code>Lib/chicken/chicken.swg</code>.
</p>
<H2><a name="Chicken_nn17">21.6 Pointers</a></H2>
<H2><a name="Chicken_nn17">23.6 Pointers</a></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">21.6.1 Garbage collection</a></H3>
<H3><a name="Chicken_collection">23.6.1 Garbage collection</a></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">21.7 Unsupported features and known problems</a></H2>
<H2><a name="Chicken_nn18">23.7 Unsupported features and known problems</a></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">21.7.1 TinyCLOS problems with Chicken version &lt;= 1.92</a></H3>
<H3><a name="Chicken_nn19">23.7.1 TinyCLOS problems with Chicken version &lt;= 1.92</a></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

573
Doc/Manual/Contents.html
View file

@ -46,6 +46,11 @@
<ul>
<li><a href="Introduction.html#Introduction_nn2">What is SWIG?</a>
<li><a href="Introduction.html#Introduction_nn3">Why use SWIG?</a>
<li><a href="Introduction.html#Introduction_target_languages">Target languages</a>
<ul>
<li><a href="Introduction.html#Introduction_supported_status">Supported status</a>
<li><a href="Introduction.html#Introduction_experimental_status">Experimental status</a>
</ul>
<li><a href="Introduction.html#Introduction_nn4">A SWIG example</a>
<ul>
<li><a href="Introduction.html#Introduction_nn5">SWIG interface file</a>
@ -228,7 +233,6 @@
<li><a href="SWIGPlus.html#SWIGPlus_nn12">Static members</a>
<li><a href="SWIGPlus.html#SWIGPlus_member_data">Member data</a>
</ul>
<li><a href="SWIGPlus.html#SWIGPlus_default_args">Default arguments</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn15">Protection</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn16">Enums and constants</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn17">Friends</a>
@ -236,16 +240,27 @@
<li><a href="SWIGPlus.html#SWIGPlus_nn19">Pass and return by value</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn20">Inheritance</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn21">A brief discussion of multiple inheritance, pointers, and type checking</a>
<li><a href="SWIGPlus.html#SWIGPlus_overloaded_methods">Wrapping Overloaded Functions and Methods</a>
<li><a href="SWIGPlus.html#SWIGPlus_default_args">Default arguments</a>
<li><a href="SWIGPlus.html#SWIGPlus_overloaded_methods">Overloaded functions and methods</a>
<ul>
<li><a href="SWIGPlus.html#SWIGPlus_nn24">Dispatch function generation</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn25">Ambiguity in Overloading</a>
<li><a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn25">Ambiguity in overloading</a>
<li><a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn27">Comments on overloading</a>
</ul>
<li><a href="SWIGPlus.html#SWIGPlus_nn28">Wrapping overloaded operators</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn28">Overloaded operators</a>
<li><a href="SWIGPlus.html#SWIGPlus_class_extension">Class extension</a>
<li><a href="SWIGPlus.html#SWIGPlus_nn30">Templates</a>
<ul>
<li><a href="SWIGPlus.html#SWIGPlus_template_directive">The %template directive</a>
<li><a href="SWIGPlus.html#SWIGPlus_template_functions">Function templates</a>
<li><a href="SWIGPlus.html#SWIGPlus_template_classes">Default template arguments</a>
<li><a href="SWIGPlus.html#SWIGPlus_template_class_inheritance">Template base classes</a>
<li><a href="SWIGPlus.html#SWIGPlus_template_specialization">Template specialization</a>
<li><a href="SWIGPlus.html#SWIGPlus_template_member">Member templates</a>
<li><a href="SWIGPlus.html#SWIGPlus_template_scoping">Scoping and templates</a>
<li><a href="SWIGPlus.html#SWIGPlus_template_more">More on templates</a>
</ul>
<li><a href="SWIGPlus.html#SWIGPlus_namespaces">Namespaces</a>
<ul>
<li><a href="SWIGPlus.html#SWIGPlus_nspace">The nspace feature for namespaces</a>
@ -259,6 +274,11 @@
<li><a href="SWIGPlus.html#SWIGPlus_nn35">Using declarations and inheritance</a>
<li><a href="SWIGPlus.html#SWIGPlus_nested_classes">Nested classes</a>
<li><a href="SWIGPlus.html#SWIGPlus_const">A brief rant about const-correctness</a>
<li><a href="SWIGPlus.html#SWIGPlus_target_language_callbacks">Callbacks to the target language</a>
<ul>
<li><a href="SWIGPlus.html#SWIGPlus_director_classes_introduction">Introduction to director classes</a>
<li><a href="SWIGPlus.html#SWIGPlus_directors_for_function_pointers">Using directors and target language callbacks</a>
</ul>
<li><a href="SWIGPlus.html#SWIGPlus_nn42">Where to go for more information</a>
</ul>
</div>
@ -290,6 +310,7 @@
<li><a href="CPlusPlus11.html#CPlusPlus11_alias_templates">Type alias and 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_char_literals">New character literals</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>
@ -300,6 +321,7 @@
<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>
<li><a href="CPlusPlus11.html#CPlusPlus11_ref_qualifiers">Methods with ref-qualifiers</a>
</ul>
<li><a href="CPlusPlus11.html#CPlusPlus11_standard_library_changes">Standard library changes</a>
<ul>
@ -318,7 +340,39 @@
</div>
<!-- INDEX -->
<h3><a href="Preprocessor.html#Preprocessor">8 Preprocessing</a></h3>
<h3><a href="CPlusPlus14.html#CPlusPlus14">8 SWIG and C++14</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="CPlusPlus14.html#CPlusPlus14_introduction">Introduction</a>
<li><a href="CPlusPlus14.html#CPlusPlus14_core_language_changes">Core language changes</a>
<ul>
<li><a href="CPlusPlus14.html#CPlusPlus14_binary_literals">Binary integer literals</a>
</ul>
<li><a href="CPlusPlus14.html#CPlusPlus14_standard_library_changes">Standard library changes</a>
</ul>
</div>
<!-- INDEX -->
<h3><a href="CPlusPlus17.html#CPlusPlus17">9 SWIG and C++17</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="CPlusPlus17.html#CPlusPlus17_introduction">Introduction</a>
<li><a href="CPlusPlus17.html#CPlusPlus17_core_language_changes">Core language changes</a>
<ul>
<li><a href="CPlusPlus17.html#CPlusPlus17_nested_namespaces">Nested namespace definitions</a>
<li><a href="CPlusPlus17.html#CPlusPlus17_u8_char_literals">UTF-8 character literals</a>
<li><a href="CPlusPlus17.html#CPlusPlus17_hexadecimal_floating_literals">Hexadecimal floating literals</a>
</ul>
<li><a href="CPlusPlus17.html#CPlusPlus17_standard_library_changes">Standard library changes</a>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Preprocessor.html#Preprocessor">10 Preprocessing</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -341,32 +395,39 @@
</div>
<!-- INDEX -->
<h3><a href="Library.html#Library">9 SWIG library</a></h3>
<h3><a href="Library.html#Library">11 SWIG library</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Library.html#Library_nn2">The %include directive and library search path</a>
<li><a href="Library.html#Library_nn3">C Arrays and Pointers</a>
<li><a href="Library.html#Library_nn3">C arrays and pointers</a>
<ul>
<li><a href="Library.html#Library_nn4">cpointer.i</a>
<li><a href="Library.html#Library_carrays">carrays.i</a>
<li><a href="Library.html#Library_nn6">cmalloc.i</a>
<li><a href="Library.html#Library_nn7">cdata.i</a>
</ul>
<li><a href="Library.html#Library_nn8">C String Handling</a>
<li><a href="Library.html#Library_nn8">C string handling</a>
<ul>
<li><a href="Library.html#Library_nn9">Default string handling</a>
<li><a href="Library.html#Library_nn10">Passing binary data</a>
<li><a href="Library.html#Library_nn11">Using %newobject to release memory</a>
<li><a href="Library.html#Library_nn12">cstring.i</a>
</ul>
<li><a href="Library.html#Library_stl_cpp_library">STL/C++ Library</a>
<li><a href="Library.html#Library_stl_cpp_library">STL/C++ library</a>
<ul>
<li><a href="Library.html#Library_std_string">std::string</a>
<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>
<ul>
<li><a href="Library.html#Library_shared_ptr_basics">shared_ptr basics</a>
<li><a href="Library.html#Library_shared_ptr_inheritance">shared_ptr and inheritance</a>
<li><a href="Library.html#Library_shared_ptr_overloading">shared_ptr and method overloading</a>
<li><a href="Library.html#Library_shared_ptr_templates">shared_ptr and templates</a>
<li><a href="Library.html#Library_shared_ptr_directors">shared_ptr and directors</a>
</ul>
<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>
@ -377,7 +438,7 @@
</div>
<!-- INDEX -->
<h3><a href="Arguments.html#Arguments">10 Argument Handling</a></h3>
<h3><a href="Arguments.html#Arguments">12 Argument Handling</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -400,7 +461,7 @@
</div>
<!-- INDEX -->
<h3><a href="Typemaps.html#Typemaps">11 Typemaps</a></h3>
<h3><a href="Typemaps.html#Typemaps">13 Typemaps</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -457,10 +518,11 @@
<li><a href="Typemaps.html#Typemaps_nn32">"argout" typemap</a>
<li><a href="Typemaps.html#Typemaps_nn33">"freearg" typemap</a>
<li><a href="Typemaps.html#Typemaps_nn34">"newfree" typemap</a>
<li><a href="Typemaps.html#Typemaps_ret">"ret" typemap</a>
<li><a href="Typemaps.html#Typemaps_nn35">"memberin" typemap</a>
<li><a href="Typemaps.html#Typemaps_nn36">"varin" typemap</a>
<li><a href="Typemaps.html#Typemaps_nn37">"varout" typemap</a>
<li><a href="Typemaps.html#throws_typemap">"throws" typemap</a>
<li><a href="Typemaps.html#Typemaps_throws_typemap">"throws" typemap</a>
</ul>
<li><a href="Typemaps.html#Typemaps_nn39">Some typemap examples</a>
<ul>
@ -482,6 +544,9 @@
<li><a href="Typemaps.html#Typemaps_runtime_type_checker_usage">Usage</a>
</ul>
<li><a href="Typemaps.html#Typemaps_overloading">Typemaps and overloading</a>
<ul>
<li><a href="Typemaps.html#Typemaps_typecheck_pointer">SWIG_TYPECHECK_POINTER precedence level and the typecheck typemap</a>
</ul>
<li><a href="Typemaps.html#Typemaps_nn48">More about %apply and %clear</a>
<li><a href="Typemaps.html#Typemaps_nn47">Passing data between typemaps</a>
<li><a href="Typemaps.html#Typemaps_nn52">C++ "this" pointer</a>
@ -490,7 +555,7 @@
</div>
<!-- INDEX -->
<h3><a href="Customization.html#Customization">12 Customization Features</a></h3>
<h3><a href="Customization.html#Customization">14 Customization Features</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -518,7 +583,7 @@
</div>
<!-- INDEX -->
<h3><a href="Contract.html#Contract">13 Contracts</a></h3>
<h3><a href="Contract.html#Contract">15 Contracts</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -531,7 +596,7 @@
</div>
<!-- INDEX -->
<h3><a href="Varargs.html#Varargs">14 Variable Length Arguments</a></h3>
<h3><a href="Varargs.html#Varargs">16 Variable Length Arguments</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -549,7 +614,55 @@
</div>
<!-- INDEX -->
<h3><a href="Warnings.html#Warnings">15 Warning Messages</a></h3>
<h3><a href="Doxygen.html#Doxygen">17 SWIG and Doxygen Translation</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Doxygen.html#Doxygen_translation_overview">Doxygen translation overview</a>
<li><a href="Doxygen.html#Doxygen_file_preparation">Preparations</a>
<ul>
<li><a href="Doxygen.html#Doxygen_running_swig">Enabling Doxygen translation</a>
<li><a href="Doxygen.html#Doxygen_features">Doxygen-specific %feature directives</a>
<ul>
<li><a href="Doxygen.html#Doxygen_notranslate">doxygen:notranslate</a>
<li><a href="Doxygen.html#Doxygen_alias">doxygen:alias:&lt;command-name&gt;</a>
<li><a href="Doxygen.html#Doxygen_ignore">doxygen:ignore:&lt;command-name&gt;</a>
<li><a href="Doxygen.html#Doxygen_nolinktranslate">doxygen:nolinktranslate</a>
<li><a href="Doxygen.html#Doxygen_nostripparams">doxygen:nostripparams</a>
</ul>
<li><a href="Doxygen.html#Doxygen_additional_options">Additional command line options</a>
</ul>
<li><a href="Doxygen.html#Doxygen_to_javadoc">Doxygen to Javadoc</a>
<ul>
<li><a href="Doxygen.html#Doxygen_basic_example">Basic example</a>
<li><a href="Doxygen.html#Doxygen_javadoc_tags">Javadoc tags</a>
<li><a href="Doxygen.html#Doxygen_unsupported_tags">Unsupported tags</a>
<li><a href="Doxygen.html#Doxygen_further_details">Further details</a>
</ul>
<li><a href="Doxygen.html#Doxygen_to_pydoc">Doxygen to Pydoc</a>
<ul>
<li><a href="Doxygen.html#Doxygen_python_basic_example">Basic example</a>
<li><a href="Doxygen.html#Doxygen_pydoc_tags">Pydoc translator</a>
<li><a href="Doxygen.html#Doxygen_python_unsupported_tags">Unsupported tags</a>
<li><a href="Doxygen.html#Doxygen_python_further_details">Further details</a>
</ul>
<li><a href="Doxygen.html#Doxygen_troubleshooting">Troubleshooting</a>
<ul>
<li><a href="Doxygen.html#troubleshooting_ifndef">Problem with conditional compilation</a>
</ul>
<li><a href="Doxygen.html#Doxygen_developer_details">Developer information</a>
<ul>
<li><a href="Doxygen.html#Doxygen_translator_design">Doxygen translator design</a>
<li><a href="Doxygen.html#Doxygen_debugging_commands">Debugging the Doxygen parser and translator</a>
<li><a href="Doxygen.html#Doxygen_tests">Tests</a>
</ul>
<li><a href="Doxygen.html#Doxygen_language_extension">Extending to other languages</a>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Warnings.html#Warnings">18 Warning Messages</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -568,7 +681,8 @@
<li><a href="Warnings.html#Warnings_nn11">Preprocessor (200-299)</a>
<li><a href="Warnings.html#Warnings_nn12">C/C++ Parser (300-399)</a>
<li><a href="Warnings.html#Warnings_nn13">Types and typemaps (400-499) </a>
<li><a href="Warnings.html#Warnings_nn14">Code generation (500-599)</a>
<li><a href="Warnings.html#Warnings_nn14">Code generation (500-559)</a>
<li><a href="Warnings.html#Warnings_doxygen">Doxygen comments (560-599)</a>
<li><a href="Warnings.html#Warnings_nn15">Language module specific (700-899) </a>
<li><a href="Warnings.html#Warnings_nn16">User defined (900-999)</a>
</ul>
@ -577,7 +691,7 @@
</div>
<!-- INDEX -->
<h3><a href="Modules.html#Modules">16 Working with Modules</a></h3>
<h3><a href="Modules.html#Modules">19 Working with Modules</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -593,7 +707,7 @@
</div>
<!-- INDEX -->
<h3><a href="CCache.html#CCache">17 Using SWIG with ccache - ccache-swig(1) manpage</a></h3>
<h3><a href="CCache.html#CCache">20 Using SWIG with ccache - ccache-swig(1) manpage</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -619,91 +733,7 @@
</div>
<!-- INDEX -->
<h3><a href="Allegrocl.html#Allegrocl">18 SWIG and Allegro Common Lisp</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn2">Basics</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn3">Running SWIG</a>
<li><a href="Allegrocl.html#Allegrocl_nn4">Command Line Options</a>
<li><a href="Allegrocl.html#Allegrocl_nn5">Inserting user code into generated files</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn6">Wrapping Overview</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn7">Function Wrapping</a>
<li><a href="Allegrocl.html#Allegrocl_nn8">Foreign Wrappers</a>
<li><a href="Allegrocl.html#Allegrocl_nn9">FFI Wrappers</a>
<li><a href="Allegrocl.html#Allegrocl_nn10">Non-overloaded Defuns</a>
<li><a href="Allegrocl.html#Allegrocl_nn11">Overloaded Defuns</a>
<li><a href="Allegrocl.html#Allegrocl_nn12">What about constant and variable access?</a>
<li><a href="Allegrocl.html#Allegrocl_nn13">Object Wrapping</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn14">Wrapping Details</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn15">Namespaces</a>
<li><a href="Allegrocl.html#Allegrocl_nn16">Constants</a>
<li><a href="Allegrocl.html#Allegrocl_nn17">Variables</a>
<li><a href="Allegrocl.html#Allegrocl_nn18">Enumerations</a>
<li><a href="Allegrocl.html#Allegrocl_nn19">Arrays</a>
<li><a href="Allegrocl.html#Allegrocl_nn20">Classes and Structs and Unions (oh my!)</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn21">CLOS wrapping of</a>
<li><a href="Allegrocl.html#Allegrocl_nn22">CLOS Inheritance</a>
<li><a href="Allegrocl.html#Allegrocl_nn23">Member fields and functions</a>
<li><a href="Allegrocl.html#Allegrocl_nn24">Why not directly access C++ classes using foreign types?</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn25">Templates</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn26">Generating wrapper code for templates</a>
<li><a href="Allegrocl.html#Allegrocl_nn27">Implicit Template instantiation</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn28">Typedef, Templates, and Synonym Types</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn29">Choosing a primary type</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn30">Function overloading/Parameter defaulting</a>
<li><a href="Allegrocl.html#Allegrocl_nn31">Operator wrapping and Operator overloading</a>
<li><a href="Allegrocl.html#Allegrocl_nn32">Varargs</a>
<li><a href="Allegrocl.html#Allegrocl_nn33">C++ Exceptions</a>
<li><a href="Allegrocl.html#Allegrocl_nn34">Pass by value, pass by reference</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn35">Typemaps</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn36">Code Generation in the C++ Wrapper</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn37">IN Typemap</a>
<li><a href="Allegrocl.html#Allegrocl_nn38">OUT Typemap</a>
<li><a href="Allegrocl.html#Allegrocl_nn39">CTYPE Typemap</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn40">Code generation in Lisp wrappers</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn41">LIN Typemap</a>
<li><a href="Allegrocl.html#Allegrocl_nn42">LOUT Typemap</a>
<li><a href="Allegrocl.html#Allegrocl_nn43">FFITYPE Typemap</a>
<li><a href="Allegrocl.html#Allegrocl_nn44">LISPTYPE Typemap</a>
<li><a href="Allegrocl.html#Allegrocl_nn45">LISPCLASS Typemap</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn46">Modifying SWIG behavior using typemaps</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn47">Identifier Converter functions</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn48">Creating symbols in the lisp environment</a>
<li><a href="Allegrocl.html#Allegrocl_nn49">Existing identifier-converter functions</a>
<ul>
<li><a href="Allegrocl.html#Allegrocl_nn50">identifier-convert-null</a>
<li><a href="Allegrocl.html#Allegrocl_nn51">identifier-convert-lispify</a>
<li><a href="Allegrocl.html#Allegrocl_nn52">Default identifier to symbol conversions</a>
</ul>
<li><a href="Allegrocl.html#Allegrocl_nn53">Defining your own identifier-converter</a>
<li><a href="Allegrocl.html#Allegrocl_nn54">Instructing SWIG to use a particular identifier-converter</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Android.html#Android">19 SWIG and Android</a></h3>
<h3><a href="Android.html#Android">21 SWIG and Android</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -721,7 +751,7 @@
</div>
<!-- INDEX -->
<h3><a href="CSharp.html#CSharp">20 SWIG and C#</a></h3>
<h3><a href="CSharp.html#CSharp">22 SWIG and C#</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -760,7 +790,8 @@
<li><a href="CSharp.html#CSharp_date_marshalling">Date marshalling using the csin typemap and associated attributes</a>
<li><a href="CSharp.html#CSharp_date_properties">A date example demonstrating marshalling of C# properties</a>
<li><a href="CSharp.html#CSharp_date_pre_post_directors">Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a>
<li><a href="CSharp.html#CSharp_partial_classes">Turning wrapped classes into partial classes</a>
<li><a href="CSharp.html#CSharp_partial_classes">Turning proxy classes into partial classes</a>
<li><a href="CSharp.html#CSharp_sealed_proxy_class">Turning proxy classes into sealed classes</a>
<li><a href="CSharp.html#CSharp_extending_proxy_class">Extending proxy classes with additional C# code</a>
<li><a href="CSharp.html#CSharp_enum_underlying_type">Underlying type for enums</a>
</ul>
@ -768,45 +799,7 @@
</div>
<!-- INDEX -->
<h3><a href="Chicken.html#Chicken">21 SWIG and Chicken</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Chicken.html#Chicken_nn2">Preliminaries</a>
<ul>
<li><a href="Chicken.html#Chicken_nn3">Running SWIG in C mode</a>
<li><a href="Chicken.html#Chicken_nn4">Running SWIG in C++ mode</a>
</ul>
<li><a href="Chicken.html#Chicken_nn5">Code Generation</a>
<ul>
<li><a href="Chicken.html#Chicken_nn6">Naming Conventions</a>
<li><a href="Chicken.html#Chicken_nn7">Modules</a>
<li><a href="Chicken.html#Chicken_nn8">Constants and Variables</a>
<li><a href="Chicken.html#Chicken_nn9">Functions</a>
<li><a href="Chicken.html#Chicken_nn10">Exceptions</a>
</ul>
<li><a href="Chicken.html#Chicken_nn11">TinyCLOS</a>
<li><a href="Chicken.html#Chicken_nn12">Linkage</a>
<ul>
<li><a href="Chicken.html#Chicken_nn13">Static binary or shared library linked at compile time</a>
<li><a href="Chicken.html#Chicken_nn14">Building chicken extension libraries</a>
<li><a href="Chicken.html#Chicken_nn15">Linking multiple SWIG modules with TinyCLOS</a>
</ul>
<li><a href="Chicken.html#Chicken_nn16">Typemaps</a>
<li><a href="Chicken.html#Chicken_nn17">Pointers</a>
<ul>
<li><a href="Chicken.html#Chicken_collection">Garbage collection</a>
</ul>
<li><a href="Chicken.html#Chicken_nn18">Unsupported features and known problems</a>
<ul>
<li><a href="Chicken.html#Chicken_nn19">TinyCLOS problems with Chicken version &lt;= 1.92</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="D.html#D">22 SWIG and D</a></h3>
<h3><a href="D.html#D">23 SWIG and D</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -840,7 +833,7 @@
</div>
<!-- INDEX -->
<h3><a href="Go.html#Go">23 SWIG and Go</a></h3>
<h3><a href="Go.html#Go">24 SWIG and Go</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -884,7 +877,7 @@
</div>
<!-- INDEX -->
<h3><a href="Guile.html#Guile">24 SWIG and Guile</a></h3>
<h3><a href="Guile.html#Guile">25 SWIG and Guile</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -907,19 +900,20 @@
<li><a href="Guile.html#Guile_nn14">Smobs</a>
<li><a href="Guile.html#Guile_nn15">Garbage Collection</a>
</ul>
<li><a href="Guile.html#Guile_nn16">Exception Handling</a>
<li><a href="Guile.html#Guile_nn17">Procedure documentation</a>
<li><a href="Guile.html#Guile_nn18">Procedures with setters</a>
<li><a href="Guile.html#Guile_nn19">GOOPS Proxy Classes</a>
<li><a href="Guile.html#Guile_nn16">Native Guile pointers</a>
<li><a href="Guile.html#Guile_nn17">Exception Handling</a>
<li><a href="Guile.html#Guile_nn18">Procedure documentation</a>
<li><a href="Guile.html#Guile_nn19">Procedures with setters</a>
<li><a href="Guile.html#Guile_nn20">GOOPS Proxy Classes</a>
<ul>
<li><a href="Guile.html#Guile_nn20">Naming Issues</a>
<li><a href="Guile.html#Guile_nn21">Linking</a>
<li><a href="Guile.html#Guile_nn21">Naming Issues</a>
<li><a href="Guile.html#Guile_nn22">Linking</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Java.html#Java">25 SWIG and Java</a></h3>
<h3><a href="Java.html#Java">26 SWIG and Java</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1008,12 +1002,16 @@
<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_customizing_director_exceptions">Customizing director exceptions</a>
</ul>
</ul>
<li><a href="Java.html#Java_allprotected">Accessing protected members</a>
<li><a href="Java.html#Java_common_customization">Common customization features</a>
<ul>
<li><a href="Java.html#Java_helper_functions">C/C++ helper functions</a>
<li><a href="Java.html#Java_class_extension">Class extension with %extend</a>
<li><a href="Java.html#Java_proxycode">Class extension with %proxycode</a>
<li><a href="Java.html#Java_exception_handling">Exception handling with %exception and %javaexception</a>
<li><a href="Java.html#Java_method_access">Method access with %javamethodmodifiers</a>
</ul>
@ -1069,7 +1067,7 @@
</div>
<!-- INDEX -->
<h3><a href="Javascript.html#Javascript">26 SWIG and Javascript</a></h3>
<h3><a href="Javascript.html#Javascript">27 SWIG and Javascript</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1111,29 +1109,6 @@
</div>
<!-- INDEX -->
<h3><a href="Lisp.html#Lisp">27 SWIG and Common Lisp</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Lisp.html#Lisp_nn2">Allegro Common Lisp</a>
<li><a href="Lisp.html#Lisp_nn3">Common Foreign Function Interface(CFFI)</a>
<ul>
<li><a href="Lisp.html#Lisp_nn4">Additional Commandline Options </a>
<li><a href="Lisp.html#Lisp_nn5">Generating CFFI bindings</a>
<li><a href="Lisp.html#Lisp_nn6">Generating CFFI bindings for C++ code</a>
<li><a href="Lisp.html#Lisp_nn7">Inserting user code into generated files</a>
</ul>
<li><a href="Lisp.html#Lisp_nn8">CLISP</a>
<ul>
<li><a href="Lisp.html#Lisp_nn9">Additional Commandline Options </a>
<li><a href="Lisp.html#Lisp_nn10">Details on CLISP bindings</a>
</ul>
<li><a href="Lisp.html#Lisp_nn11">UFFI </a>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Lua.html#Lua">28 SWIG and Lua</a></h3>
<!-- INDEX -->
@ -1202,108 +1177,7 @@
</div>
<!-- INDEX -->
<h3><a href="Modula3.html#Modula3">29 SWIG and Modula-3</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Modula3.html#Modula3_modula3_overview">Overview</a>
<ul>
<li><a href="Modula3.html#Modula3_motivation">Motivation</a>
</ul>
<li><a href="Modula3.html#Modula3_conception">Conception</a>
<ul>
<li><a href="Modula3.html#Modula3_cinterface">Interfaces to C libraries</a>
<li><a href="Modula3.html#Modula3_cppinterface">Interfaces to C++ libraries</a>
</ul>
<li><a href="Modula3.html#Modula3_preliminaries">Preliminaries</a>
<ul>
<li><a href="Modula3.html#Modula3_compilers">Compilers</a>
<li><a href="Modula3.html#Modula3_commandline">Additional Commandline Options</a>
</ul>
<li><a href="Modula3.html#Modula3_typemaps">Modula-3 typemaps</a>
<ul>
<li><a href="Modula3.html#Modula3_inoutparam">Inputs and outputs</a>
<li><a href="Modula3.html#Modula3_ordinals">Subranges, Enumerations, Sets</a>
<li><a href="Modula3.html#Modula3_class">Objects</a>
<li><a href="Modula3.html#Modula3_imports">Imports</a>
<li><a href="Modula3.html#Modula3_exceptions">Exceptions</a>
<li><a href="Modula3.html#Modula3_typemap_example">Example</a>
</ul>
<li><a href="Modula3.html#Modula3_hints">More hints to the generator</a>
<ul>
<li><a href="Modula3.html#Modula3_features">Features</a>
<li><a href="Modula3.html#Modula3_pragmas">Pragmas</a>
</ul>
<li><a href="Modula3.html#Modula3_remarks">Remarks</a>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Mzscheme.html#Mzscheme">30 SWIG and MzScheme/Racket</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Mzscheme.html#MzScheme_nn2">Creating native structures</a>
<li><a href="Mzscheme.html#MzScheme_simple">Simple example</a>
<li><a href="Mzscheme.html#MzScheme_external_docs">External documentation</a>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Ocaml.html#Ocaml">31 SWIG and Ocaml</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Ocaml.html#Ocaml_nn2">Preliminaries</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn3">Running SWIG</a>
<li><a href="Ocaml.html#Ocaml_nn4">Compiling the code</a>
<li><a href="Ocaml.html#Ocaml_nn5">The camlp4 module</a>
<li><a href="Ocaml.html#Ocaml_nn6">Using your module</a>
<li><a href="Ocaml.html#Ocaml_nn7">Compilation problems and compiling with C++</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn8">The low-level Ocaml/C interface</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn9">The generated module</a>
<li><a href="Ocaml.html#Ocaml_nn10">Enums</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn11">Enum typing in Ocaml</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn12">Arrays</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn13">Simple types of bounded arrays</a>
<li><a href="Ocaml.html#Ocaml_nn14">Complex and unbounded arrays</a>
<li><a href="Ocaml.html#Ocaml_nn15">Using an object</a>
<li><a href="Ocaml.html#Ocaml_nn16">Example typemap for a function taking float * and int</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn17">C++ Classes</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn18">STL vector and string Example</a>
<li><a href="Ocaml.html#Ocaml_nn19">C++ Class Example</a>
<li><a href="Ocaml.html#Ocaml_nn20">Compiling the example</a>
<li><a href="Ocaml.html#Ocaml_nn21">Sample Session</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn22">Director Classes</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn23">Director Introduction</a>
<li><a href="Ocaml.html#Ocaml_nn24">Overriding Methods in Ocaml</a>
<li><a href="Ocaml.html#Ocaml_nn25">Director Usage Example</a>
<li><a href="Ocaml.html#Ocaml_nn26">Creating director objects</a>
<li><a href="Ocaml.html#Ocaml_nn27">Typemaps for directors, directorin, directorout, directorargout</a>
<li><a href="Ocaml.html#Ocaml_nn28">typemap</a>
<li><a href="Ocaml.html#Ocaml_nn29">directorout typemap</a>
<li><a href="Ocaml.html#Ocaml_nn30">directorargout typemap</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn31">Exceptions</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Octave.html#Octave">32 SWIG and Octave</a></h3>
<h3><a href="Octave.html#Octave">29 SWIG and Octave</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1343,7 +1217,7 @@
</div>
<!-- INDEX -->
<h3><a href="Perl5.html#Perl5">33 SWIG and Perl5</a></h3>
<h3><a href="Perl5.html#Perl5">30 SWIG and Perl5</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1419,7 +1293,7 @@
</div>
<!-- INDEX -->
<h3><a href="Php.html#Php">34 SWIG and PHP</a></h3>
<h3><a href="Php.html#Php">31 SWIG and PHP</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1460,31 +1334,7 @@
</div>
<!-- INDEX -->
<h3><a href="Pike.html#Pike">35 SWIG and Pike</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Pike.html#Pike_nn2">Preliminaries</a>
<ul>
<li><a href="Pike.html#Pike_nn3">Running SWIG</a>
<li><a href="Pike.html#Pike_nn4">Getting the right header files</a>
<li><a href="Pike.html#Pike_nn5">Using your module</a>
</ul>
<li><a href="Pike.html#Pike_nn6">Basic C/C++ Mapping</a>
<ul>
<li><a href="Pike.html#Pike_nn7">Modules</a>
<li><a href="Pike.html#Pike_nn8">Functions</a>
<li><a href="Pike.html#Pike_nn9">Global variables</a>
<li><a href="Pike.html#Pike_nn10">Constants and enumerated types</a>
<li><a href="Pike.html#Pike_nn11">Constructors and Destructors</a>
<li><a href="Pike.html#Pike_nn12">Static Members</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Python.html#Python">36 SWIG and Python</a></h3>
<h3><a href="Python.html#Python">32 SWIG and Python</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1499,7 +1349,8 @@
<li><a href="Python.html#Python_nn9">Using your module</a>
<li><a href="Python.html#Python_nn10">Compilation of C++ extensions</a>
<li><a href="Python.html#Python_nn11">Compiling for 64-bit platforms</a>
<li><a href="Python.html#Python_nn12">Building Python Extensions under Windows</a>
<li><a href="Python.html#Python_nn12">Building Python extensions under Windows</a>
<li><a href="Python.html#Python_commandline">Additional Python commandline options</a>
</ul>
<li><a href="Python.html#Python_nn13">A tour of basic C/C++ wrapping</a>
<ul>
@ -1532,7 +1383,6 @@
<li><a href="Python.html#Python_builtin_overloads">Operator overloads and slots -- use them!</a>
</ul>
<li><a href="Python.html#Python_nn30">Memory management</a>
<li><a href="Python.html#Python_nn31">Python 2.2 and classic classes</a>
</ul>
<li><a href="Python.html#Python_directors">Cross language polymorphism</a>
<ul>
@ -1550,6 +1400,10 @@
<li><a href="Python.html#Python_nn42">Adding additional Python code</a>
<li><a href="Python.html#Python_nn43">Class extension with %extend</a>
<li><a href="Python.html#Python_nn44">Exception handling with %exception</a>
<li><a href="Python.html#Python_optimization">Optimization options</a>
<ul>
<li><a href="Python.html#Python_fastproxy">-fastproxy</a>
</ul>
</ul>
<li><a href="Python.html#Python_nn45">Tips and techniques</a>
<ul>
@ -1574,6 +1428,7 @@
<li><a href="Python.html#Python_nn62">Mapping Python tuples into small arrays</a>
<li><a href="Python.html#Python_nn63">Mapping sequences to C arrays</a>
<li><a href="Python.html#Python_nn64">Pointer handling</a>
<li><a href="Python.html#Python_memory_management_member_variables">Memory management when returning references to member variables</a>
</ul>
<li><a href="Python.html#Python_nn65">Docstring Features</a>
<ul>
@ -1594,12 +1449,13 @@
<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>
<li><a href="Python.html#Python_implicit_namespace_packages">Implicit Namespace Packages</a>
<li><a href="Python.html#Python_package_search">Searching for the wrapper module</a>
<li><a href="Python.html#Python_implicit_namespace_packages">Implicit namespace packages</a>
<li><a href="Python.html#Python_package_search">Location of modules</a>
<ul>
<li><a href="Python.html#Python_package_search_both_package_modules">Both modules in the same package</a>
<li><a href="Python.html#Python_package_search_wrapper_split">Split modules</a>
<li><a href="Python.html#Python_package_search_both_global_modules">Both modules are global</a>
<li><a href="Python.html#Python_package_search_wrapper_split">Split modules custom configuration</a>
<li><a href="Python.html#Python_custom_module_import">More on customizing the module import code</a>
<li><a href="Python.html#Python_package_search_static">Statically linked C modules</a>
</ul>
</ul>
@ -1611,11 +1467,16 @@
<li><a href="Python.html#Python_nn77">Byte string output conversion</a>
<li><a href="Python.html#Python_2_unicode">Python 2 Unicode</a>
</ul>
<li><a href="Python.html#Python_multithreaded">Support for Multithreaded Applications</a>
<ul>
<li><a href="Python.html#Python_thread_UI">UI for Enabling Multithreading Support</a>
<li><a href="Python.html#Python_thread_performance">Multithread Performance</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="R.html#R">37 SWIG and R</a></h3>
<h3><a href="R.html#R">33 SWIG and R</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1631,7 +1492,7 @@
</div>
<!-- INDEX -->
<h3><a href="Ruby.html#Ruby">38 SWIG and Ruby</a></h3>
<h3><a href="Ruby.html#Ruby">34 SWIG and Ruby</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1769,7 +1630,7 @@
</div>
<!-- INDEX -->
<h3><a href="Scilab.html#Scilab">39 SWIG and Scilab</a></h3>
<h3><a href="Scilab.html#Scilab">35 SWIG and Scilab</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1800,7 +1661,7 @@
</ul>
<li><a href="Scilab.html#Scilab_wrapping_pointers">Pointers</a>
<ul>
<li><a href="Scilab.html#Scilab_wrapping_pointers_pointer_adresses">Utility functions</a>
<li><a href="Scilab.html#Scilab_wrapping_pointers_utility_functions">Utility functions</a>
<li><a href="Scilab.html#Scilab_wrapping_pointers_null_pointers">Null pointers:</a>
</ul>
<li><a href="Scilab.html#Scilab_wrapping_structs">Structures</a>
@ -1838,7 +1699,7 @@
</div>
<!-- INDEX -->
<h3><a href="Tcl.html#Tcl">40 SWIG and Tcl</a></h3>
<h3><a href="Tcl.html#Tcl">36 SWIG and Tcl</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1904,7 +1765,74 @@
</div>
<!-- INDEX -->
<h3><a href="Extending.html#Extending">41 Extending SWIG to support new languages</a></h3>
<h3><a href="Mzscheme.html#Mzscheme">37 SWIG and MzScheme/Racket</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Mzscheme.html#MzScheme_nn2">Creating native structures</a>
<li><a href="Mzscheme.html#MzScheme_simple">Simple example</a>
<li><a href="Mzscheme.html#MzScheme_external_docs">External documentation</a>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Ocaml.html#Ocaml">38 SWIG and OCaml</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Ocaml.html#Ocaml_nn2">Preliminaries</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn3">Running SWIG</a>
<li><a href="Ocaml.html#Ocaml_nn4">Compiling the code</a>
<li><a href="Ocaml.html#Ocaml_nn5">The camlp4 module</a>
<li><a href="Ocaml.html#Ocaml_nn6">Using your module</a>
<li><a href="Ocaml.html#Ocaml_nn7">Compilation problems and compiling with C++</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn8">The low-level Ocaml/C interface</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn9">The generated module</a>
<li><a href="Ocaml.html#Ocaml_nn10">Enums</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn11">Enum typing in Ocaml</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn12">Arrays</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn13">Simple types of bounded arrays</a>
<li><a href="Ocaml.html#Ocaml_nn14">Complex and unbounded arrays</a>
<li><a href="Ocaml.html#Ocaml_nn15">Using an object</a>
<li><a href="Ocaml.html#Ocaml_nn16">Example typemap for a function taking float * and int</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn17">C++ Classes</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn18">STL vector and string Example</a>
<li><a href="Ocaml.html#Ocaml_nn19">C++ Class Example</a>
<li><a href="Ocaml.html#Ocaml_nn20">Compiling the example</a>
<li><a href="Ocaml.html#Ocaml_nn21">Sample Session</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn22">Director Classes</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn23">Director Introduction</a>
<li><a href="Ocaml.html#Ocaml_nn24">Overriding Methods in Ocaml</a>
<li><a href="Ocaml.html#Ocaml_nn25">Director Usage Example</a>
<li><a href="Ocaml.html#Ocaml_nn26">Creating director objects</a>
<li><a href="Ocaml.html#Ocaml_nn27">Typemaps for directors, directorin, directorout, directorargout</a>
<li><a href="Ocaml.html#Ocaml_nn28">directorin typemap</a>
<li><a href="Ocaml.html#Ocaml_nn29">directorout typemap</a>
<li><a href="Ocaml.html#Ocaml_nn30">directorargout typemap</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn31">Exceptions</a>
</ul>
<li><a href="Ocaml.html#Ocaml_nn32">Documentation Features</a>
<ul>
<li><a href="Ocaml.html#Ocaml_nn33">Module docstring</a>
</ul>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Extending.html#Extending">39 Extending SWIG to support new languages</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1962,8 +1890,13 @@
<li><a href="Extending.html#Extending_running_test_suite">Running the test-suite</a>
</ul>
<li><a href="Extending.html#Extending_nn43">Documentation</a>
<li><a href="Extending.html#Extending_prerequisites">Prerequisites for adding a new language module to the SWIG distribution</a>
<li><a href="Extending.html#Extending_coding_style_guidelines">Coding style guidelines</a>
<li><a href="Extending.html#Extending_language_status">Target language status</a>
<ul>
<li><a href="Extending.html#Extending_supported_status">Supported status</a>
<li><a href="Extending.html#Extending_experimental_status">Experimental status</a>
</ul>
<li><a href="Extending.html#Extending_prerequisites">Prerequisites for adding a new language module to the SWIG distribution</a>
</ul>
<li><a href="Extending.html#Extending_debugging_options">Debugging Options</a>
<li><a href="Extending.html#Extending_nn46">Guide to parse tree nodes</a>

38
Doc/Manual/Contract.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Contract">13 Contracts</a></H1>
<H1><a name="Contract">15 Contracts</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -39,7 +39,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">13.1 The %contract directive</a></H2>
<H2><a name="Contract_nn2">15.1 The %contract directive</a></H2>
<p>
@ -51,9 +51,9 @@ is a simple example:
<pre>
%contract sqrt(double x) {
require:
x &gt;= 0;
x &gt;= 0;
ensure:
sqrt &gt;= 0;
sqrt &gt;= 0;
}
...
@ -95,7 +95,7 @@ RuntimeError: Contract violation: require: (arg1&gt;=0)
</pre>
</div>
<H2><a name="Contract_nn3">13.2 %contract and classes</a></H2>
<H2><a name="Contract_nn3">15.2 %contract and classes</a></H2>
<p>
@ -106,20 +106,20 @@ The <tt>%contract</tt> directive can also be applied to class methods and constr
<pre>
%contract Foo::bar(int x, int y) {
require:
x &gt; 0;
x &gt; 0;
ensure:
bar &gt; 0;
bar &gt; 0;
}
%contract Foo::Foo(int a) {
require:
a &gt; 0;
a &gt; 0;
}
class Foo {
public:
Foo(int);
int bar(int, int);
Foo(int);
int bar(int, int);
};
</pre>
</div>
@ -133,7 +133,7 @@ Thus, any contract that you specified for a base class will also be attached to
<pre>
class Spam : public Foo {
public:
int bar(int,int); // Gets contract defined for Foo::bar(int,int)
int bar(int, int); // Gets contract defined for Foo::bar(int, int)
};
</pre>
</div>
@ -146,22 +146,22 @@ In addition to this, separate contracts can be applied to both the base class an
<pre>
%contract Foo::bar(int x, int) {
require:
x &gt; 0;
x &gt; 0;
}
%contract Spam::bar(int, int y) {
require:
y &gt; 0;
y &gt; 0;
}
class Foo {
public:
int bar(int,int); // Gets Foo::bar contract.
int bar(int, int); // Gets Foo::bar contract.
};
class Spam : public Foo {
public:
int bar(int,int); // Gets Foo::bar and Spam::bar contract
int bar(int, int); // Gets Foo::bar and Spam::bar contract
};
</pre>
</div>
@ -174,7 +174,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">13.3 Constant aggregation and %aggregate_check</a></H2>
<H2><a name="Contract_nn4">15.3 Constant aggregation and %aggregate_check</a></H2>
<p>
@ -225,7 +225,7 @@ function can be used in contracts. For example:
%contract move(SomeObject *, int direction, in) {
require:
check_direction(direction);
check_direction(direction);
}
#define UP 1
@ -246,7 +246,7 @@ Alternatively, it can be used in typemaps and other directives. For example:
%aggregate_check(int, check_direction, UP, DOWN, RIGHT, LEFT);
%typemap(check) int direction {
if (!check_direction($1)) SWIG_exception(SWIG_ValueError, "Bad direction");
if (!check_direction($1)) SWIG_exception(SWIG_ValueError, "Bad direction");
}
#define UP 1
@ -263,7 +263,7 @@ Regrettably, there is no automatic way to perform similar checks with enums valu
release.
</p>
<H2><a name="Contract_nn5">13.4 Notes</a></H2>
<H2><a name="Contract_nn5">15.4 Notes</a></H2>
<p>

260
Doc/Manual/Customization.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Customization">12 Customization Features</a></H1>
<H1><a name="Customization">14 Customization Features</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -46,7 +46,7 @@ of exception handling is presented. Then, a more general-purpose
customization mechanism known as "features" is described.
</p>
<H2><a name="Customization_exception">12.1 Exception handling with %exception</a></H2>
<H2><a name="Customization_exception">14.1 Exception handling with %exception</a></H2>
<p>
@ -56,12 +56,12 @@ handler. For example, you can specify the following:
<div class="code"><pre>
%exception {
try {
$action
}
catch (RangeError) {
... handle error ...
}
try {
$action
}
catch (RangeError) {
... handle error ...
}
}
</pre></div>
@ -71,13 +71,13 @@ How the exception is handled depends on the target language, for example, Python
<div class="code"><pre>
%exception {
try {
$action
}
catch (RangeError) {
PyErr_SetString(PyExc_IndexError,"index out-of-bounds");
SWIG_fail;
}
try {
$action
}
catch (RangeError) {
PyErr_SetString(PyExc_IndexError, "index out-of-bounds");
SWIG_fail;
}
}
</pre></div>
@ -101,7 +101,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">12.1.1 Handling exceptions in C code</a></H3>
<H3><a name="Customization_nn3">14.1.1 Handling exceptions in C code</a></H3>
<p>
@ -116,7 +116,7 @@ static char error_message[256];
static int error_status = 0;
void throw_exception(char *msg) {
strncpy(error_message,msg,256);
strncpy(error_message, msg, 256);
error_status = 1;
}
@ -169,7 +169,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">12.1.2 Exception handling with longjmp()</a></H3>
<H3><a name="Customization_nn4">14.1.2 Exception handling with longjmp()</a></H3>
<p>
@ -193,7 +193,7 @@ extern int exception_status;
#define try if ((exception_status = setjmp(exception_buffer)) == 0)
#define catch(val) else if (exception_status == val)
#define throw(val) longjmp(exception_buffer,val)
#define throw(val) longjmp(exception_buffer, val)
#define finally else
/* Exception codes */
@ -245,7 +245,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">12.1.3 Handling C++ exceptions</a></H3>
<H3><a name="Customization_nn5">14.1.3 Handling C++ exceptions</a></H3>
<p>
@ -280,7 +280,7 @@ class OutOfMemory {};
</pre>
</div>
<H3><a name="Customization_allowexcept">12.1.4 Exception handlers for variables</a></H3>
<H3><a name="Customization_allowexcept">14.1.4 Exception handlers for variables</a></H3>
<p>
@ -305,7 +305,7 @@ The <tt>%allowexception</tt> feature works like any other feature and so can be
</pre>
</div>
<H3><a name="Customization_nn6">12.1.5 Defining different exception handlers</a></H3>
<H3><a name="Customization_nn6">14.1.5 Defining different exception handlers</a></H3>
<p>
@ -341,12 +341,12 @@ to specific declaration name. For example:
<div class="code">
<pre>
%exception allocate {
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
}
</pre>
</div>
@ -356,7 +356,7 @@ In this case, the exception handler is only attached to declarations
named "allocate". This would include both global and member
functions. The names supplied to <tt>%exception</tt> follow the same
rules as for <tt>%rename</tt> described in the section on
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a>.
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>.
For example, if you wanted to define
an exception handler for a specific class, you might write this:
</p>
@ -364,12 +364,12 @@ an exception handler for a specific class, you might write this:
<div class="code">
<pre>
%exception Object::allocate {
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
}
</pre>
</div>
@ -386,12 +386,12 @@ in the specified class as well as for identically named functions appearing in d
<div class="code">
<pre>
%exception Object::allocate(int) {
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
}
</pre>
</div>
@ -410,21 +410,21 @@ to attach exceptions to specific parts of a header file. For example:
// Define a few exception handlers for specific declarations
%exception Object::allocate(int) {
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
}
%exception Object::getitem {
try {
$action
}
catch (RangeError) {
croak("Index out of range");
}
try {
$action
}
catch (RangeError) {
croak("Index out of range");
}
}
...
// Read a raw header file
@ -442,7 +442,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">12.1.6 Special variables for %exception</a></H3>
<H3><a name="Customization_exception_special_variables">14.1.6 Special variables for %exception</a></H3>
<p>
@ -516,7 +516,7 @@ The special variables are often used in situations where method calls are logged
$action
}
catch (MemoryError) {
croak("Out of memory in $decl");
croak("Out of memory in $decl");
}
}
void log(const char *message);
@ -545,7 +545,7 @@ Below shows the expansions for the 1st of the overloaded <tt>something</tt> wrap
</pre></div>
<H3><a name="Customization_nn7">12.1.7 Using The SWIG exception library</a></H3>
<H3><a name="Customization_nn7">14.1.7 Using The SWIG exception library</a></H3>
<p>
@ -560,17 +560,17 @@ common scripting language exceptions in a portable manner. For example :</p>
%include exception.i
%exception {
try {
$action
} catch(RangeError) {
SWIG_exception(SWIG_ValueError, "Range Error");
} catch(DivisionByZero) {
SWIG_exception(SWIG_DivisionByZero, "Division by zero");
} catch(OutOfMemory) {
SWIG_exception(SWIG_MemoryError, "Out of memory");
} catch(...) {
SWIG_exception(SWIG_RuntimeError,"Unknown exception");
}
try {
$action
} catch(RangeError) {
SWIG_exception(SWIG_ValueError, "Range Error");
} catch(DivisionByZero) {
SWIG_exception(SWIG_DivisionByZero, "Division by zero");
} catch(OutOfMemory) {
SWIG_exception(SWIG_MemoryError, "Out of memory");
} catch(...) {
SWIG_exception(SWIG_RuntimeError, "Unknown exception");
}
}
</pre></div>
@ -600,7 +600,7 @@ SWIG_NullReferenceError
The <tt>SWIG_exception()</tt> function can also be used in typemaps.
</p>
<H2><a name="Customization_ownership">12.2 Object ownership and %newobject</a></H2>
<H2><a name="Customization_ownership">14.2 Object ownership and %newobject</a></H2>
<p>
@ -611,8 +611,8 @@ example, consider a function like this:
<div class="code">
<pre>
Foo *blah() {
Foo *f = new Foo();
return f;
Foo *f = new Foo();
return f;
}
</pre>
</div>
@ -645,7 +645,7 @@ you can attach it to class members and parameterized declarations as before. Fo
<div class="code">
<pre>
%newobject ::blah(); // Only applies to global blah
%newobject Object::blah(int,double); // Only blah(int,double) in Object
%newobject Object::blah(int, double); // Only blah(int, double) in Object
%newobject *::copy; // Copy method in all classes
...
</pre>
@ -757,7 +757,7 @@ char *strdup(const char *s);
The results might not be what you expect.
</p>
<H2><a name="Customization_features">12.3 Features and the %feature directive</a></H2>
<H2><a name="Customization_features">14.3 Features and the %feature directive</a></H2>
<p>
@ -771,15 +771,15 @@ using the <tt>%feature</tt> directive. For example:
<div class="code">
<pre>
%feature("except") Object::allocate {
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
try {
$action
}
catch (MemoryError) {
croak("Out of memory");
}
}
%feature("new","1") *::copy;
%feature("new", "1") *::copy;
</pre>
</div>
@ -791,12 +791,12 @@ involving <tt>%feature</tt>:
<div class="code">
<pre>
#define %exception %feature("except")
#define %newobject %feature("new","1")
#define %newobject %feature("new", "1")
</pre>
</div>
<p>
The name matching rules outlined in the <a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a>
The name matching rules outlined in the <a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>
section applies to all <tt>%feature</tt> directives.
In fact the <tt>%rename</tt> directive is just a special form of <tt>%feature</tt>.
The matching rules mean that features are very flexible and can be applied with
@ -811,10 +811,10 @@ are defined. For example:
<pre>
/* Define a global exception handler */
%feature("except") {
try {
$action
}
...
try {
$action
}
...
}
... bunch of declarations ...
@ -831,7 +831,7 @@ The following are all equivalent:
%feature("except") Object::method { $action };
%feature("except") Object::method %{ $action %};
%feature("except") Object::method " $action ";
%feature("except","$action") Object::method;
%feature("except", "$action") Object::method;
</pre>
</div>
@ -839,7 +839,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">12.3.1 Feature attributes</a></H3>
<H3><a name="Customization_feature_attributes">14.3.1 Feature attributes</a></H3>
<p>
@ -850,7 +850,7 @@ The following is the generic syntax for features:
<div class="code">
<pre>
%feature("name","value", attribute1="AttributeValue1") symbol;
%feature("name", "value", attribute1="AttributeValue1") symbol;
%feature("name", attribute1="AttributeValue1") symbol {value};
%feature("name", attribute1="AttributeValue1") symbol %{value%};
%feature("name", attribute1="AttributeValue1") symbol "value";
@ -867,11 +867,11 @@ In the following example, <tt>MyExceptionClass</tt> is the name of the Java clas
<div class="code">
<pre>
%feature("except", throws="MyExceptionClass") Object::method {
try {
$action
} catch (...) {
... code to throw a MyExceptionClass Java exception ...
}
try {
$action
} catch (...) {
... code to throw a MyExceptionClass Java exception ...
}
};
</pre>
</div>
@ -880,7 +880,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">12.3.2 Feature flags</a></H3>
<H3><a name="Customization_feature_flags">14.3.2 Feature flags</a></H3>
<p>
@ -914,13 +914,13 @@ int red; // mutable
%feature("immutable"); // global enable
int orange; // immutable
%feature("immutable","0"); // global disable
%feature("immutable", "0"); // global disable
int yellow; // mutable
%feature("immutable","1"); // another form of global enable
%feature("immutable", "1"); // another form of global enable
int green; // immutable
%feature("immutable",""); // clears the global feature
%feature("immutable", ""); // clears the global feature
int blue; // mutable
</pre>
</div>
@ -932,8 +932,8 @@ The above intersperses SWIG directives with C code. Of course you can target fea
<div class="code">
<pre>
%feature("immutable","1") orange;
%feature("immutable","1") green;
%feature("immutable", "1") orange;
%feature("immutable", "1") green;
int red; // mutable
int orange; // immutable
int yellow; // mutable
@ -949,10 +949,10 @@ The logic above can of course be inverted and rewritten as:
<div class="code">
<pre>
%feature("immutable","1");
%feature("immutable","0") red;
%feature("immutable","0") yellow;
%feature("immutable","0") blue;
%feature("immutable", "1");
%feature("immutable", "0") red;
%feature("immutable", "0") yellow;
%feature("immutable", "0") blue;
int red; // mutable
int orange; // immutable
int yellow; // mutable
@ -978,12 +978,12 @@ 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">12.3.3 Clearing features</a></H3>
<H3><a name="Customization_clearing_features">14.3.3 Clearing features</a></H3>
<p>
A feature stays in effect until it is explicitly cleared. A feature is cleared by
supplying a <tt>%feature</tt> directive with no value. For example <tt>%feature("name","")</tt>.
supplying a <tt>%feature</tt> directive with no value. For example <tt>%feature("name", "")</tt>.
A cleared feature means that any feature exactly matching any previously defined feature is no longer used in the name matching rules.
So if a feature is cleared, it might mean that another name matching rule will apply.
To clarify, let's consider the <tt>except</tt> feature again (<tt>%exception</tt>):
@ -993,27 +993,27 @@ To clarify, let's consider the <tt>except</tt> feature again (<tt>%exception</tt
<pre>
// Define global exception handler
%feature("except") {
try {
$action
} catch (...) {
croak("Unknown C++ exception");
}
try {
$action
} catch (...) {
croak("Unknown C++ exception");
}
}
// Define exception handler for all clone methods to log the method calls
%feature("except") *::clone() {
try {
logger.info("$action");
$action
} catch (...) {
croak("Unknown C++ exception");
}
try {
logger.info("$action");
$action
} catch (...) {
croak("Unknown C++ exception");
}
}
... initial set of class declarations with clone methods ...
// clear the previously defined feature
%feature("except","") *::clone();
%feature("except", "") *::clone();
... final set of class declarations with clone methods ...
</pre>
@ -1027,8 +1027,8 @@ However, these clone methods will still have an exception handler (without loggi
<p>
Note that clearing a feature is not always the same as disabling it.
Clearing the feature above with <tt>%feature("except","") *::clone()</tt> is not the same as specifying
<tt>%feature("except","0") *::clone()</tt>. The former will disable the feature for clone methods -
Clearing the feature above with <tt>%feature("except", "") *::clone()</tt> is not the same as specifying
<tt>%feature("except", "0") *::clone()</tt>. The former will disable the feature for clone methods -
the feature is still a better match than the global feature.
If on the other hand, no global exception handler had been defined at all,
then clearing the feature would be the same as disabling it as no other feature would have matched.
@ -1042,7 +1042,7 @@ For example the following attempt to clear the initial feature will not work:
<div class="code">
<pre>
%feature("except") clone() { logger.info("$action"); $action }
%feature("except","") *::clone();
%feature("except", "") *::clone();
</pre>
</div>
@ -1053,7 +1053,7 @@ but this will:
<div class="code">
<pre>
%feature("except") clone() { logger.info("$action"); $action }
%feature("except","") clone();
%feature("except", "") clone();
</pre>
</div>
@ -1066,12 +1066,12 @@ The three macros below show this for the "except" feature:
<div class="code">
<pre>
#define %exception %feature("except")
#define %noexception %feature("except","0")
#define %clearexception %feature("except","")
#define %noexception %feature("except", "0")
#define %clearexception %feature("except", "")
</pre>
</div>
<H3><a name="Customization_features_default_args">12.3.4 Features and default arguments</a></H3>
<H3><a name="Customization_features_default_args">14.3.4 Features and default arguments</a></H3>
<p>
@ -1146,7 +1146,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">12.3.5 Feature example</a></H3>
<H3><a name="Customization_features_example">14.3.5 Feature example</a></H3>
<p>
@ -1158,21 +1158,21 @@ in the Python module. You might use <tt>%feature</tt> to rewrite proxy/shadow cl
<div class="code">
<pre>
%module example
%rename(bar_id) bar(int,double);
%rename(bar_id) bar(int, double);
// Rewrite bar() to allow some nice overloading
%feature("shadow") Foo::bar(int) %{
def bar(*args):
if len(args) == 3:
return apply(examplec.Foo_bar_id,args)
return apply(examplec.Foo_bar,args)
return apply(examplec.Foo_bar_id, args)
return apply(examplec.Foo_bar, args)
%}
class Foo {
public:
int bar(int x);
int bar(int x, double y);
int bar(int x);
int bar(int x, double y);
}
</pre>
</div>

68
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">22 SWIG and D</a></H1>
<H1><a name="D">23 SWIG and D</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -41,7 +41,7 @@
<H2><a name="D_introduction">22.1 Introduction</a></H2>
<H2><a name="D_introduction">23.1 Introduction</a></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,10 +53,10 @@
<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#CSharp">C#</a> (and also on <a href="Java.html#Java">Java</a>, since the C# module was in turn forked from it).</p>
<H2><a name="D_command_line_invocation">22.2 Command line invocation</a></H2>
<H2><a name="D_command_line_invocation">23.2 Command line invocation</a></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>
<p>To activate the D module, pass the <tt>-d</tt> option to SWIG at the command line. The same standard command line options as with any other language module are available, plus the following D specific ones:</p>
<dl>
<dt><tt>-d2</tt></dt>
@ -66,8 +66,8 @@
<dt><a name="D_splitproxy"></a><tt>-splitproxy</tt></dt>
<dd>
<p>By default, SWIG generates two D modules: the <em>proxy</em> module, named like the source module (either specified via the <tt>%module</tt> directive or via the <tt>module</tt> command line switch), which contains all the proxy classes, functions, enums, etc., and the <em>intermediary</em> module (named like the proxy module, but suffixed with <tt>_im</tt>), which contains all the <tt>extern(C)</tt> function declarations and other private parts only used internally by the proxy module.</p>
<p>If the split proxy mode is enabled by passing this switch at the command line, all proxy classes and enums are emitted to their own D module instead. The main proxy module only contains free functions and constants in this case.</p>
<p>By default, SWIG generates two D modules: the <em>proxy</em> module, named like the source module (either specified via the <tt>%module</tt> directive or via the <tt>module</tt> command line option), which contains all the proxy classes, functions, enums, etc., and the <em>intermediary</em> module (named like the proxy module, but suffixed with <tt>_im</tt>), which contains all the <tt>extern(C)</tt> function declarations and other private parts only used internally by the proxy module.</p>
<p>If the split proxy mode is enabled by passing this option at the command line, all proxy classes and enums are emitted to their own D module instead. The main proxy module only contains free functions and constants in this case.</p>
</dd>
<dt><tt>-package &lt;pkg&gt;</tt></dt>
@ -77,16 +77,16 @@
<dt><tt>-wrapperlibrary &lt;wl&gt;</tt></dt>
<dd>
<p>The code SWIG generates to dynamically load the C/C++ wrapper layer looks for a library called <tt>$module_wrap</tt> by default. With this switch, you can override the name of the file the wrapper code loads at runtime (the <tt>lib</tt> prefix and the suffix for shared libraries are appended automatically, depending on the OS).</p>
<p>The code SWIG generates to dynamically load the C/C++ wrapper layer looks for a library called <tt>$module_wrap</tt> by default. With this option, you can override the name of the file the wrapper code loads at runtime (the <tt>lib</tt> prefix and the suffix for shared libraries are appended automatically, depending on the OS).</p>
<p>This might especially be useful if you want to invoke SWIG several times on separate modules, but compile the resulting code into a single shared library.</p>
</dd>
</dl>
<H2><a name="D_typemaps">22.3 Typemaps</a></H2>
<H2><a name="D_typemaps">23.3 Typemaps</a></H2>
<H3><a name="D_typemap_name_comparison">22.3.1 C# &lt;-&gt; D name comparison</a></H3>
<H3><a name="D_typemap_name_comparison">23.3.1 C# &lt;-&gt; D name comparison</a></H3>
<p>If you already know the SWIG C# module, you might find the following name comparison table useful:</p>
@ -107,12 +107,12 @@
csimports &lt;-&gt; dimports
csbody &lt;-&gt; dbody
csfinalize &lt;-&gt; ddestructor
csdestruct &lt;-&gt; ddispose
csdestruct_derived &lt;-&gt; ddispose_derived
csdisposing &lt;-&gt; ddispose
csdisposing_derived &lt;-&gt; ddispose_derived
</pre></div>
<H3><a name="D_ctype_imtype_dtype">22.3.2 ctype, imtype, dtype</a></H3>
<H3><a name="D_ctype_imtype_dtype">23.3.2 ctype, imtype, dtype</a></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">22.3.3 in, out, directorin, directorout</a></H3>
<H3><a name="D_in_out_directorin_direcetorout">23.3.3 in, out, directorin, directorout</a></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">22.3.4 din, dout, ddirectorin, ddirectorout</a></H3>
<H3><a name="D_din_dout_ddirectorin_ddirectorout">23.3.4 din, dout, ddirectorin, ddirectorout</a></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">22.3.5 typecheck typemaps</a></H3>
<H3><a name="D_typecheck_typemaps">23.3.5 typecheck typemaps</a></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">22.3.6 Code injection typemaps</a></H3>
<H3><a name="D_code_injection_typemaps">23.3.6 Code injection typemaps</a></H3>
<p>These typemaps are used for generating the skeleton of proxy classes for C++ types.</p>
@ -174,8 +174,11 @@
<p><a name="D_class_code_typemaps"></a><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>
<p>
Code can also be injected into the D proxy class using <tt>%proxycode</tt>.
</p>
<H3><a name="D_special_variables">22.3.7 Special variable macros</a></H3>
<H3><a name="D_special_variables">23.3.7 Special variable macros</a></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>
@ -229,8 +232,9 @@ void foo(SomeClass arg) {
%newobject bar();
SomeClass *bar();
%}</pre></div>
<p>The code generated for <tt>foo()</tt> and <tt>bar()</tt> looks like this:</p>
%}
</pre></div>
<p>The code generated for <tt>foo()</tt> and <tt>bar()</tt> looks like this:</p>
<div class="targetlang"><pre>
SomeClass foo() {
return new SomeClass(example_im.foo(), false);
@ -276,7 +280,7 @@ class SomeClass : AnInterface, AnotherInterface {
...
}
</pre></div>
<p>For this to work, <tt>AnInterface</tt> and <tt>AnotherInterface</tt> have to be in scope. If SWIG is not in split proxy mode, this is already the case, but it it is, they have to be added to the import list via the <tt>dimports</tt> typemap. Additionally, the import statement depends on the package SWIG is configured to emit the modules to.</p>
<p>For this to work, <tt>AnInterface</tt> and <tt>AnotherInterface</tt> have to be in scope. If SWIG is not in split proxy mode, this is already the case, but if it is, they have to be added to the import list via the <tt>dimports</tt> typemap. Additionally, the import statement depends on the package SWIG is configured to emit the modules to.</p>
<p>The <tt>$importtype</tt> macro helps you to elegantly solve this problem:</p>
<div class="code"><pre>
%typemap(dimports) RemoteMpe %{
@ -295,7 +299,7 @@ $importtype(AnotherInterface)
</dl>
<H2><a name="D_features">22.4 D and %feature</a></H2>
<H2><a name="D_features">23.4 D and %feature</a></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 +329,7 @@ struct A {
</dl>
<H2><a name="D_pragmas">22.5 Pragmas</a></H2>
<H2><a name="D_pragmas">23.5 Pragmas</a></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 +368,7 @@ struct A {
</dl>
<H2><a name="D_exceptions">22.6 D Exceptions</a></H2>
<H2><a name="D_exceptions">23.6 D Exceptions</a></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 +378,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">22.7 D Directors</a></H2>
<H2><a name="D_directors">23.7 D Directors</a></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 +387,16 @@ struct A {
</p>
<H2><a name="D_other_features">22.8 Other features</a></H2>
<H2><a name="D_other_features">23.8 Other features</a></H2>
<H3><a name="D_nspace">22.8.1 Extended namespace support (nspace)</a></H3>
<H3><a name="D_nspace">23.8.1 Extended namespace support (nspace)</a></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">22.8.2 Native pointer support</a></H3>
<H3><a name="D_native_pointer_support">23.8.2 Native pointer support</a></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 +408,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">22.8.3 Operator overloading</a></H3>
<H3><a name="D_operator_overloading">23.8.3 Operator overloading</a></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,22 +420,22 @@ 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">22.8.4 Running the test-suite</a></H3>
<H3><a name="D_test_suite">23.8.4 Running the test-suite</a></H3>
<p>As with any other language, the SWIG test-suite can be built for D using the <tt>*-d-test-suite</tt> targets of the top-level Makefile. By default, D1 is targeted, to build it with D2, use the optional <tt>D_VERSION</tt> variable, e.g. <tt>make check-d-test-suite D_VERSION=2</tt>.</p>
<p>Note: If you want to use GDC on Linux or another platform which requires you to link <tt>libdl</tt> for dynamically loading the shared library, you might have to add <tt>-ldl</tt> manually to the <tt>d_compile</tt> target in <tt>Examples/Makefile</tt>, because GDC does not currently honor the <tt>pragma(lib,...)</tt> statement.</p>
<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">22.9 D Typemap examples</a></H2>
<H2><a name="D_typemap_examples">23.9 D Typemap examples</a></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">22.10 Work in progress and planned features</a></H2>
<H2><a name="D_planned_features">23.10 Work in progress and planned features</a></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>

1838
Doc/Manual/Doxygen.html Normal file
View file

File diff suppressed because it is too large Load diff

668
Doc/Manual/Extending.html
View file

File diff suppressed because it is too large Load diff

142
Doc/Manual/Go.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="Go">23 SWIG and Go</a></H1>
<H1><a name="Go">24 SWIG and Go</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -57,7 +57,7 @@ the Go programming language
see <a href="http://golang.org/">golang.org</a>.
</p>
<H2><a name="Go_overview">23.1 Overview</a></H2>
<H2><a name="Go_overview">24.1 Overview</a></H2>
<p>
@ -86,7 +86,7 @@ type-safe as well. In case of type issues the build will fail and hence SWIG's
are not used.
</p>
<H2><a name="Go_examples">23.2 Examples</a></H2>
<H2><a name="Go_examples">24.2 Examples</a></H2>
<p>
@ -101,7 +101,7 @@ SWIG interface file extension for backwards compatibility with Go 1.
</p>
<H2><a name="Go_running_swig">23.3 Running SWIG with Go</a></H2>
<H2><a name="Go_running_swig">24.3 Running SWIG with Go</a></H2>
<p>
@ -125,16 +125,15 @@ Go distribution. To generate code for gccgo, you should also use the
</p>
<p>
When using the <tt>-cgo</tt> option, SWIG will generate files that can be used
directly by <tt>go build</tt>. Starting with the Go 1.5 distribution the
<tt>-cgo</tt> option has to be given. Put your SWIG interface file in a
directory under GOPATH/src, and give it a name that does <b>not</b> end in the
.swig or .swigcxx extension. Typically the SWIG interface file extension is .i
in this case.
By default SWIG will generate files that can be used directly
by <tt>go build</tt>. This requires Go 1.2 or later. Put your SWIG
interface file in a directory under GOPATH/src, and give it a name
that does <b>not</b> end in the .swig or .swigcxx extension.
Typically the SWIG interface file extension is .i in this case.
</p>
<div class="code"><pre>
% swig -go -cgo example.i
% swig -go example.i
% go install
</pre></div>
@ -144,15 +143,16 @@ usual.
</p>
<p>
To use SWIG without the <tt>-cgo</tt> option, more steps are required. Recall
that this only works with Go versions before 1.5. When using Go 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 Go compiler of
the Go distribution would look like this:
SWIG can be used without cgo, via the <tt>-no-cgo</tt> option, but
more steps are required. This only works with Go versions before 1.5.
When using Go 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 Go compiler of the Go
distribution would look like this:
</p>
<div class="code"><pre>
% swig -go example.i
% swig -go -no-cgo example.i
% gcc -c code.c # The C library being wrapped.
% gcc -c example_wrap.c
% go tool 6g example.go
@ -169,7 +169,7 @@ sequence for this approach would look like this:
</p>
<div class="code"><pre>
% swig -go -use-shlib example.i
% swig -go -no-cgo -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
@ -181,7 +181,7 @@ sequence for this approach would look like this:
</pre></div>
<H3><a name="Go_commandline">23.3.1 Go-specific Commandline Options</a></H3>
<H3><a name="Go_commandline">24.3.1 Go-specific Commandline Options</a></H3>
<p>
@ -200,10 +200,15 @@ swig -go -help
<tr>
<td>-cgo</td>
<td>Generate files to be used as input for the Go cgo tool. This
option is required for Go 1.5 and later, and works for Go 1.2 and
later. In the future this option will likely become the
default.</td>
<td>Generate files to be used as input for the Go cgo tool. This is
the default.</td>
</tr>
<tr>
<td>-no-cgo</td>
<td>Generate files that can be used directly, rather than via the Go
cgo tool. This option does not work with Go 1.5 or later. It is
required for versions of Go before 1.2.</td>
</tr>
<tr>
@ -261,18 +266,25 @@ swig -go -help
ignored.</td>
</tr>
<tr>
<td>-import-prefix &lt;prefix&gt;</td>
<td>A prefix to add when turning a %import prefix in the SWIG
interface file into an import statement in the Go file. For
example, with <code>-import-prefix mymodule</code>, a SWIG
interface file <code>%import mypackage</code> will become a Go
import statement <code>import "mymodule/mypackage"</code>.</td>
</table>
<H3><a name="Go_outputs">23.3.2 Generated Wrapper Files</a></H3>
<H3><a name="Go_outputs">24.3.2 Generated Wrapper Files</a></H3>
<p>There are two different approaches to generating wrapper files,
controlled by SWIG's <tt>-cgo</tt> option. The <tt>-cgo</tt> option
works with Go version 1.2 or later. It is required when using Go
version 1.5 or later.</p>
controlled by SWIG's <tt>-no-cgo</tt> option. The <tt>-no-cgo</tt>
option only works with version of Go before 1.5. It is required
when using versions of Go before 1.2.</p>
<p>With or without the <tt>-cgo</tt> option, SWIG will generate the
<p>With or without the <tt>-no-cgo</tt> option, SWIG will generate the
following files when generating wrapper code:</p>
<ul>
@ -296,8 +308,8 @@ or C++ compiler.
</li>
</ul>
<p>When neither the <tt>-cgo</tt> nor the <tt>-gccgo</tt> option is
used, SWIG will also generate an additional file:</p>
<p>When the <tt>-no-cgo</tt> option is used, and the <tt>-gccgo</tt>
option is not used, SWIG will also generate an additional file:</p>
<ul>
<li>
@ -308,7 +320,7 @@ combined with the compiled MODULE.go using go tool pack.
</ul>
<H2><a name="Go_basic_tour">23.4 A tour of basic C/C++ wrapping</a></H2>
<H2><a name="Go_basic_tour">24.4 A tour of basic C/C++ wrapping</a></H2>
<p>
@ -318,7 +330,7 @@ modifications have to occur. This section briefly covers the
essential aspects of this wrapping.
</p>
<H3><a name="Go_package">23.4.1 Go Package Name</a></H3>
<H3><a name="Go_package">24.4.1 Go Package Name</a></H3>
<p>
@ -328,7 +340,7 @@ directive. You may override this by using SWIG's <tt>-package</tt>
command line option.
</p>
<H3><a name="Go_names">23.4.2 Go Names</a></H3>
<H3><a name="Go_names">24.4.2 Go Names</a></H3>
<p>
@ -360,7 +372,7 @@ followed by that name, and the destructor will be
named <tt>Delete</tt> followed by that name.
</p>
<H3><a name="Go_constants">23.4.3 Go Constants</a></H3>
<H3><a name="Go_constants">24.4.3 Go Constants</a></H3>
<p>
@ -368,7 +380,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">23.4.4 Go Enumerations</a></H3>
<H3><a name="Go_enumerations">24.4.4 Go Enumerations</a></H3>
<p>
@ -378,7 +390,7 @@ usual). The values of the enumeration will become variables in Go;
code should avoid modifying those variables.
</p>
<H3><a name="Go_classes">23.4.5 Go Classes</a></H3>
<H3><a name="Go_classes">24.4.5 Go Classes</a></H3>
<p>
@ -456,7 +468,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_memory">23.4.5.1 Go Class Memory Management</a></H4>
<H4><a name="Go_class_memory">24.4.5.1 Go Class Memory Management</a></H4>
<p>
@ -471,7 +483,7 @@ The most Go idiomatic way to manage the memory for some C++ class is to call
<tt><a href="https://golang.org/doc/effective_go.html#defer">defer</a></tt> of
the <tt>DeleteClassName</tt> call. Using <tt>defer</tt> ensures that the memory
of the C++ object is freed as soon as the function containing the <tt>defer</tt>
statement returns. Furthemore <tt>defer</tt> works great for short-lived
statement returns. Furthermore <tt>defer</tt> works great for short-lived
objects and fits nicely C++'s RAII idiom. Example:
</p>
<div class="code">
@ -512,7 +524,7 @@ func main() {
<p>
Using <tt>defer</tt> has limitations though, especially when it comes to
long-lived C++ objects whichs lifetimes are hard to predict. For such C++
long-lived C++ objects whose lifetimes are hard to predict. For such C++
objects a common technique is to store the C++ object into a Go object, and to
use the Go function <tt>runtime.SetFinalizer</tt> to add a finalizer which frees
the C++ object when the Go object is freed. It is strongly recommended to read
@ -578,7 +590,7 @@ func (o *GoClassName) Close() {
</pre>
</div>
<H4><a name="Go_class_inheritance">23.4.5.2 Go Class Inheritance</a></H4>
<H4><a name="Go_class_inheritance">24.4.5.2 Go Class Inheritance</a></H4>
<p>
@ -590,16 +602,16 @@ Doing the reverse will require an explicit type assertion, which will
be checked dynamically.
</p>
<H3><a name="Go_templates">23.4.6 Go Templates</a></H3>
<H3><a name="Go_templates">24.4.6 Go Templates</a></H3>
<p>
In order to use C++ templates in Go, you must tell SWIG to create
wrappers for a particular template instantation. To do this, use
wrappers for a particular template instantiation. To do this, use
the <tt>%template</tt> directive.
<H3><a name="Go_director_classes">23.4.7 Go Director Classes</a></H3>
<H3><a name="Go_director_classes">24.4.7 Go Director Classes</a></H3>
<p>
@ -611,13 +623,13 @@ work is necessary.
</p>
<p>
This subchapter gives a step by step guide how to properly sublass a C++ class
This subchapter gives a step by step guide how to properly subclass a C++ class
with a Go type. In general it is strongly recommended to follow this guide
completely to avoid common pitfalls with directors in Go.
</p>
<H4><a name="Go_director_example_cpp_code">23.4.7.1 Example C++ code</a></H4>
<H4><a name="Go_director_example_cpp_code">24.4.7.1 Example C++ code</a></H4>
<p>
@ -639,12 +651,12 @@ public:
virtual ~FooBarAbstract() {};
std::string FooBar() {
return this->Foo() + ", " + this->Bar();
return this-&gt;Foo() + ", " + this-&gt;Bar();
};
protected:
virtual std::string Foo() {
return "Foo";
return "Foo";
};
virtual std::string Bar() = 0;
@ -689,7 +701,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
</p>
<H4><a name="Go_director_enable">23.4.7.2 Enable director feature</a></H4>
<H4><a name="Go_director_enable">24.4.7.2 Enable director feature</a></H4>
<p>
@ -724,7 +736,7 @@ documentation on directors.
</p>
<H4><a name="Go_director_ctor_dtor">23.4.7.3 Constructor and destructor</a></H4>
<H4><a name="Go_director_ctor_dtor">24.4.7.3 Constructor and destructor</a></H4>
<p>
@ -777,7 +789,7 @@ embedding</a>.
</p>
<H4><a name="Go_director_overriding">23.4.7.4 Override virtual methods</a></H4>
<H4><a name="Go_director_overriding">24.4.7.4 Override virtual methods</a></H4>
<p>
@ -785,10 +797,12 @@ In order to override virtual methods on a C++ class with Go methods the
<tt>NewDirectorClassName</tt> constructor functions receives a
<tt>DirectorInterface</tt> argument. The methods in the <tt>
DirectorInterface</tt> are a subset of the public and protected virtual methods
of the C++ class. If the <tt>DirectorInterface</tt> contains a method with a
of the C++ class.
Virtual methods that have a final specifier are unsurprisingly excluded.
If the <tt>DirectorInterface</tt> contains a method with a
matching signature to a virtual method of the C++ class then the virtual C++
method will be overwritten with the Go method. As Go doesn't support protected
methods all overriden protected virtual C++ methods will be public in Go.
methods all overridden protected virtual C++ methods will be public in Go.
</p>
<p>
@ -843,7 +857,7 @@ the Go methods.
</p>
<H4><a name="Go_director_base_methods">23.4.7.5 Call base methods</a></H4>
<H4><a name="Go_director_base_methods">24.4.7.5 Call base methods</a></H4>
<p>
@ -880,7 +894,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
</p>
<H4><a name="Go_director_subclass">23.4.7.6 Subclass via embedding</a></H4>
<H4><a name="Go_director_subclass">24.4.7.6 Subclass via embedding</a></H4>
<p>
@ -941,14 +955,14 @@ methods of the <tt>FooBarAbstract</tt> C++ class by means of embedding. The
public <tt>FooBarGo</tt> interface type includes the <tt>FooBarAbstract</tt>
interface and hence <tt>FooBarGo</tt> can be used as a drop in replacement for
<tt>FooBarAbstract</tt> while the reverse isn't possible and would raise a
compile time error. Furthemore the constructor and destructor functions <tt>
compile time error. Furthermore the constructor and destructor functions <tt>
NewFooBarGo</tt> and <tt>DeleteFooBarGo</tt> take care of all the director
specifics and to the user the class appears as any other SWIG wrapped C++
class.
</p>
<H4><a name="Go_director_finalizer">23.4.7.7 Memory management with runtime.SetFinalizer</a></H4>
<H4><a name="Go_director_finalizer">24.4.7.7 Memory management with runtime.SetFinalizer</a></H4>
<p>
@ -1013,7 +1027,7 @@ before using <tt>runtime.SetFinalizer</tt> to know all of its gotchas.
</p>
<H4><a name="Go_director_foobargo_class">23.4.7.8 Complete FooBarGo example class</a></H4>
<H4><a name="Go_director_foobargo_class">24.4.7.8 Complete FooBarGo example class</a></H4>
<p>
@ -1054,7 +1068,7 @@ type overwrittenMethodsOnFooBarAbstract struct {
fb FooBarAbstract
// If additional constructor arguments have been given they are typically
// stored here so that the overriden methods can use them.
// stored here so that the overridden methods can use them.
}
func (om *overwrittenMethodsOnFooBarAbstract) Foo() string {
@ -1081,7 +1095,7 @@ func NewFooBarGo() FooBarGo {
// The memory of the FooBarAbstract director object instance can be
// automatically freed once the FooBarGo instance is garbage collected by
// uncommenting the following line. Please make sure to understand the
// runtime.SetFinalizer specific gotchas before doing this. Furthemore
// runtime.SetFinalizer specific gotchas before doing this. Furthermore
// DeleteFooBarGo should be deleted if a finalizer is in use or the fooBarGo
// struct needs additional data to prevent double deletion.
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)
@ -1142,7 +1156,7 @@ SWIG/Examples/go/director/</a>.
</p>
<H3><a name="Go_primitive_type_mappings">23.4.8 Default Go primitive type mappings</a></H3>
<H3><a name="Go_primitive_type_mappings">24.4.8 Default Go primitive type mappings</a></H3>
<p>
@ -1249,7 +1263,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">23.4.9 Output arguments</a></H3>
<H3><a name="Go_output_arguments">24.4.9 Output arguments</a></H3>
<p>Because of limitations in the way output arguments are processed in swig,
@ -1289,7 +1303,7 @@ fraction := modulename.Modf(5.0, ptr)
</pre>
</div>
<p>Since this is ugly, you may want to wrap the swig-generated API with
some <a href="#Embedded_go_code">additional functions written in go</a> that
some <a href="#Go_adding_additional_code">additional functions written in go</a> that
hide the ugly details.</p>
<p>There are no <code>char&nbsp;*OUTPUT</code> typemaps. However you can
@ -1302,7 +1316,7 @@ void f(char *output);
</pre>
</div>
<H3><a name="Go_adding_additional_code">23.4.10 Adding additional go code</a></H3>
<H3><a name="Go_adding_additional_code">24.4.10 Adding additional go code</a></H3>
<p>Often the APIs generated by swig are not very natural in go, especially if
@ -1397,7 +1411,7 @@ func bar() {
</pre>
</div>
<H3><a name="Go_typemaps">23.4.11 Go typemaps</a></H3>
<H3><a name="Go_typemaps">24.4.11 Go typemaps</a></H3>
<p>

62
Doc/Manual/Guile.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Guile">24 SWIG and Guile</a></H1>
<H1><a name="Guile">25 SWIG and Guile</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -30,13 +30,14 @@
<li><a href="#Guile_nn14">Smobs</a>
<li><a href="#Guile_nn15">Garbage Collection</a>
</ul>
<li><a href="#Guile_nn16">Exception Handling</a>
<li><a href="#Guile_nn17">Procedure documentation</a>
<li><a href="#Guile_nn18">Procedures with setters</a>
<li><a href="#Guile_nn19">GOOPS Proxy Classes</a>
<li><a href="#Guile_nn16">Native Guile pointers</a>
<li><a href="#Guile_nn17">Exception Handling</a>
<li><a href="#Guile_nn18">Procedure documentation</a>
<li><a href="#Guile_nn19">Procedures with setters</a>
<li><a href="#Guile_nn20">GOOPS Proxy Classes</a>
<ul>
<li><a href="#Guile_nn20">Naming Issues</a>
<li><a href="#Guile_nn21">Linking</a>
<li><a href="#Guile_nn21">Naming Issues</a>
<li><a href="#Guile_nn22">Linking</a>
</ul>
</ul>
</div>
@ -47,7 +48,7 @@
<p>
This section details guile-specific support in SWIG.
<H2><a name="Guile_nn1">24.1 Supported Guile Versions</a></H2>
<H2><a name="Guile_nn1">25.1 Supported Guile Versions</a></H2>
<p>
@ -61,7 +62,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">24.2 Meaning of "Module"</a></H2>
<H2><a name="Guile_nn2">25.2 Meaning of "Module"</a></H2>
<p>
@ -69,7 +70,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">24.3 Old GH Guile API</a></H2>
<H2><a name="Guile_nn3">25.3 Old GH Guile API</a></H2>
<p>Guile 1.8 and older could be interfaced using two different api's, the SCM
@ -80,7 +81,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">24.4 Linkage</a></H2>
<H2><a name="Guile_nn4">25.4 Linkage</a></H2>
<p>
@ -88,7 +89,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">24.4.1 Simple Linkage</a></H3>
<H3><a name="Guile_nn5">25.4.1 Simple Linkage</a></H3>
<p>
@ -193,7 +194,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">24.4.2 Passive Linkage</a></H3>
<H3><a name="Guile_nn6">25.4.2 Passive Linkage</a></H3>
<p>Passive linkage is just like simple linkage, but it generates an
@ -203,7 +204,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">24.4.3 Native Guile Module Linkage</a></H3>
<H3><a name="Guile_nn7">25.4.3 Native Guile Module Linkage</a></H3>
<p>SWIG can also generate wrapper code that does all the Guile module
@ -244,7 +245,7 @@ Newer Guile versions have a shorthand procedure for this:
</div>
</ul>
<H3><a name="Guile_nn8">24.4.4 Old Auto-Loading Guile Module Linkage</a></H3>
<H3><a name="Guile_nn8">25.4.4 Old Auto-Loading Guile Module Linkage</a></H3>
<p>Guile used to support an autoloading facility for object-code
@ -270,7 +271,7 @@ option, SWIG generates an exported module initialization function with
an appropriate name.
<H3><a name="Guile_nn9">24.4.5 Hobbit4D Linkage</a></H3>
<H3><a name="Guile_nn9">25.4.5 Hobbit4D Linkage</a></H3>
<p>
@ -295,7 +296,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">24.5 Underscore Folding</a></H2>
<H2><a name="Guile_nn10">25.5 Underscore Folding</a></H2>
<p>
@ -307,7 +308,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">24.6 Typemaps</a></H2>
<H2><a name="Guile_nn11">25.6 Typemaps</a></H2>
<p>
@ -399,7 +400,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">24.7 Representation of pointers as smobs</a></H2>
<H2><a name="Guile_nn12">25.7 Representation of pointers as smobs</a></H2>
<p>
@ -420,7 +421,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">24.7.1 Smobs</a></H3>
<H3><a name="Guile_nn14">25.7.1 Smobs</a></H3>
<p>
@ -439,7 +440,7 @@ structure describing this type. If a generated GOOPS module has been loaded, sm
the corresponding GOOPS class.</p>
<H3><a name="Guile_nn15">24.7.2 Garbage Collection</a></H3>
<H3><a name="Guile_nn15">25.7.2 Garbage Collection</a></H3>
<p>Garbage collection is a feature of Guile since version 1.6. As SWIG now requires Guile &gt; 1.8,
@ -453,7 +454,14 @@ 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">24.8 Exception Handling</a></H2>
<H2><a name="Guile_nn16">25.8 Native Guile pointers</a></H2>
<p>
In addition to SWIG smob pointers, <a href="https://www.gnu.org/software/guile/manual/html_node/Foreign-Pointers.html">Guile's native pointer type</a> are accepted as arguments to wrapped SWIG functions. This can be useful for passing <a href="https://www.gnu.org/software/guile/manual/html_node/Void-Pointers-and-Byte-Access.html#">pointers to bytevector data</a> to wrapped functions.
</p>
<H2><a name="Guile_nn17">25.9 Exception Handling</a></H2>
<p>
@ -479,7 +487,7 @@ mapping:
The default when not specified here is to use "swig-error".
See Lib/exception.i for details.
<H2><a name="Guile_nn17">24.9 Procedure documentation</a></H2>
<H2><a name="Guile_nn18">25.10 Procedure documentation</a></H2>
<p>If invoked with the command-line option <code>-procdoc
@ -514,7 +522,7 @@ like this:
typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
details.
<H2><a name="Guile_nn18">24.10 Procedures with setters</a></H2>
<H2><a name="Guile_nn19">25.11 Procedures with setters</a></H2>
<p>For global variables, SWIG creates a single wrapper procedure
@ -542,7 +550,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">24.11 GOOPS Proxy Classes</a></H2>
<H2><a name="Guile_nn20">25.12 GOOPS Proxy Classes</a></H2>
<p>SWIG can also generate classes and generic functions for use with
@ -688,7 +696,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">24.11.1 Naming Issues</a></H3>
<H3><a name="Guile_nn21">25.12.1 Naming Issues</a></H3>
<p>As you can see in the example above, there are potential naming conflicts. The default exported
@ -725,7 +733,7 @@ guile-modules. For example,</p>
(use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:)))
</pre></div>
<H3><a name="Guile_nn21">24.11.2 Linking</a></H3>
<H3><a name="Guile_nn22">25.12.2 Linking</a></H3>
<p>The guile-modules generated above all need to be linked together. GOOPS support requires

121
Doc/Manual/Introduction.html
View file

@ -13,6 +13,11 @@
<ul>
<li><a href="#Introduction_nn2">What is SWIG?</a>
<li><a href="#Introduction_nn3">Why use SWIG?</a>
<li><a href="#Introduction_target_languages">Target languages</a>
<ul>
<li><a href="#Introduction_supported_status">Supported status</a>
<li><a href="#Introduction_experimental_status">Experimental status</a>
</ul>
<li><a href="#Introduction_nn4">A SWIG example</a>
<ul>
<li><a href="#Introduction_nn5">SWIG interface file</a>
@ -144,7 +149,79 @@ it provides a wide variety of customization features that let you change almost
every aspect of the language bindings. This is the main reason why SWIG has such a large
user manual ;-).
<H2><a name="Introduction_nn4">2.3 A SWIG example</a></H2>
<H2><a name="Introduction_target_languages">2.3 Target languages</a></H2>
<p>
SWIG in essence is a tool to generate code for making C/C++ code available to various other programming languages.
These higher level programming languages are the target languages for the SWIG code generator and C or C++ are the input languages.
A single target language must be specified when SWIG is run.
This results in generating code for C/C++ and the specified target language to interface with each other.
SWIG can be invoked multiple times, but with a different target language specified on each invocation.
This ability to interface C/C++ to many different target languages is one of SWIG's core strengths and features.
</p>
<p>
SWIG is very broadly composed of two components.
A core component creates a parse tree from the input ISO C/C++ and SWIG directives (extensions to the C/C++ standards).
The parse tree is then passed to a second component, one of the target language modules for generating code specific to a higher level language.
SWIG supports many different target languages.
These target languages are given a status of either Supported or Experimental.
This status is provided to indicate the level of maturity to expect when using a particular target language as not all target languages are fully developed.
</p>
<p>
The second part of the SWIG documentation contains a chapter for each target level language.
Each chapter will state the status (Supported or Experimental) for that language.
</p>
<H3><a name="Introduction_supported_status">2.3.1 Supported status</a></H3>
<p>
A target language is given the 'Supported' status when
</p>
<ul>
<li>It is in a mature, well functioning state.</li>
<li>It has its own comprehensive chapter in the documentation.</li>
<li>It passes all of the main SWIG test-suite and has a range of working examples.</li>
<li>It supports the vast majority of SWIG features.</li>
<li>It provides strong backwards compatibility between releases.</li>
</ul>
<p>
The above is a short summary and further details are outlined in the <a href="Extending.html#Extending_supported_status">Supported status</a> section in the Extending chapter.
The good news is that all the well-known and most popular languages have this status.
</p>
<H3><a name="Introduction_experimental_status">2.3.2 Experimental status</a></H3>
<p>
A target language is given the 'Experimental' status when
</p>
<ul>
<li>It is of sub-standard quality, failing to meet the above 'Supported' status.</li>
<li>It is somewhere between the mid to mature stage of development.</li>
<li>It does not guarantee any backwards compatibility between releases.</li>
<li>It is in need of help to finish development.</li>
</ul>
<p>
Anyone using an experimental target language is strongly urged to assist with development of the target language module if they wish to use it.
</p>
<p>
SWIG displays a warning when an experimental target language is used in order to set expectations and emphasize the experimental status of the target language.
The usual <a href="Warnings.html#Warnings_suppression">warning suppression</a> techniques can be used if required.
</p>
<p>
The above is a short summary and further details are outlined in the <a href="Extending.html#Extending_experimental_status">Experimental status</a> section in the Extending chapter.
</p>
<H2><a name="Introduction_nn4">2.4 A SWIG example</a></H2>
<p>
@ -155,7 +232,7 @@ following C code:
<div class="code"><pre>
/* File : example.c */
double My_variable = 3.0;
double My_variable = 3.0;
/* Compute factorial of n */
int fact(int n) {
@ -177,7 +254,7 @@ variable <tt>My_variable</tt> from Tcl. You start by making a SWIG
interface file as shown below (by convention, these files carry a .i
suffix) :
<H3><a name="Introduction_nn5">2.3.1 SWIG interface file</a></H3>
<H3><a name="Introduction_nn5">2.4.1 SWIG interface file</a></H3>
<div class="code"><pre>
@ -196,13 +273,13 @@ extern int my_mod(int n, int m);
</pre></div>
<p>
The interface file contains ANSI C function prototypes and variable
The interface file contains ISO C function prototypes and variable
declarations. The <tt>%module</tt> directive defines the name of the
module that will be created by SWIG. The <tt>%{ %}</tt> block
provides a location for inserting additional code, such as C header
files or additional C declarations, into the generated C wrapper code.
<H3><a name="Introduction_nn6">2.3.2 The swig command</a></H3>
<H3><a name="Introduction_nn6">2.4.2 The swig command</a></H3>
<p>
@ -235,7 +312,7 @@ and variables declared in the SWIG interface. A look at the file
<tt>example_wrap.c</tt> reveals a hideous mess. However, you
almost never need to worry about it.
<H3><a name="Introduction_nn7">2.3.3 Building a Perl5 module</a></H3>
<H3><a name="Introduction_nn7">2.4.3 Building a Perl5 module</a></H3>
<p>
@ -251,7 +328,7 @@ unix &gt; <b>ld -G example.o example_wrap.o -o example.so</b> # This is for Sola
unix &gt; <b>perl5.003
use example;
print example::fact(4), "\n";
print example::my_mod(23,7), "\n";
print example::my_mod(23, 7), "\n";
print $example::My_variable + 4.5, "\n";
&lt;ctrl-d&gt;</b>
24
@ -261,7 +338,7 @@ unix &gt;
</pre></div>
<H3><a name="Introduction_nn8">2.3.4 Building a Python module</a></H3>
<H3><a name="Introduction_nn8">2.4.4 Building a Python module</a></H3>
<p>
@ -279,13 +356,13 @@ Type "copyright", "credits" or "license" for more information.
&gt;&gt;&gt; <b>import example</b>
&gt;&gt;&gt; <b>example.fact(4)</b>
24
&gt;&gt;&gt; <b>example.my_mod(23,7)</b>
&gt;&gt;&gt; <b>example.my_mod(23, 7)</b>
2
&gt;&gt;&gt; <b>example.cvar.My_variable + 4.5</b>
7.5
</pre></div>
<H3><a name="Introduction_nn9">2.3.5 Shortcuts</a></H3>
<H3><a name="Introduction_nn9">2.4.5 Shortcuts</a></H3>
<p>
@ -303,7 +380,7 @@ unix &gt; <b>ld -G example.o example_wrap.o -o example.so</b>
unix &gt; <b>perl5.003
use example;
print example::fact(4), "\n";
print example::my_mod(23,7), "\n";
print example::my_mod(23, 7), "\n";
print $example::My_variable + 4.5, "\n";
&lt;ctrl-d&gt;</b>
24
@ -311,7 +388,7 @@ print $example::My_variable + 4.5, "\n";
7.5
</pre></div>
<H2><a name="Introduction_nn10">2.4 Supported C/C++ language features</a></H2>
<H2><a name="Introduction_nn10">2.5 Supported C/C++ language features</a></H2>
<p>
@ -323,7 +400,7 @@ major features include:
<ul>
<li>Full C99 preprocessing.
<li>All ANSI C and C++ datatypes.
<li>All ISO C and C++ datatypes.
<li>Functions, variables, and constants.
<li>Classes.
<li>Single and multiple inheritance.
@ -336,7 +413,9 @@ major features include:
</ul>
<p>
Most of C++11 is also supported. Details are in the <a href="CPlusPlus11.html#CPlusPlus11">C++11</a> section.
Most of C++11 is also supported. Details are in the <a href="CPlusPlus11.html#CPlusPlus11">C++11</a> chapter.
C++14 support is covered in the <a href="CPlusPlus14.html#CPlusPlus14">C++14</a> chapter.
C++17 support is covered in the <a href="CPlusPlus17.html#CPlusPlus17">C++17</a> chapter.
</p>
<p>
@ -350,7 +429,7 @@ wrapping simple C++ code. In fact, SWIG is able to handle C++ code that
stresses the very limits of many C++ compilers.
<H2><a name="Introduction_nn11">2.5 Non-intrusive interface building</a></H2>
<H2><a name="Introduction_nn11">2.6 Non-intrusive interface building</a></H2>
<p>
@ -362,7 +441,7 @@ interface and reuse the code in other applications. It is also
possible to support different types of interfaces depending on the application.
</p>
<H2><a name="Introduction_build_system">2.6 Incorporating SWIG into a build system</a></H2>
<H2><a name="Introduction_build_system">2.7 Incorporating SWIG into a build system</a></H2>
<p>
@ -385,13 +464,13 @@ for further information on this and other Autoconf macros.
</p>
<p>
There is growing support for SWIG in some build tools, for example <a href="http://cmake.org">CMake</a>
There is growing support for SWIG in some build tools, for example <a href="https://cmake.org">CMake</a>
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 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:
The following example is a CMake input file for creating a Python wrapper for the SWIG interface file, example.i:
</p>
<div class="code"><pre>
@ -420,7 +499,7 @@ which will invoke SWIG and compile the generated C++ files into _example.so (UNI
For other target languages on Windows a dll, instead of a .pyd file, is usually generated.
</p>
<H2><a name="Introduction_nn12">2.7 Hands off code generation</a></H2>
<H2><a name="Introduction_nn12">2.8 Hands off code generation</a></H2>
<p>
@ -433,7 +512,7 @@ it allows others to forget about the low-level implementation
details.
</p>
<H2><a name="Introduction_nn13">2.8 SWIG and freedom</a></H2>
<H2><a name="Introduction_nn13">2.9 SWIG and freedom</a></H2>
<p>
@ -452,7 +531,7 @@ to work with complicated and unusual C/C++ applications.
Ironically, the freedom that SWIG provides is countered by an
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
well-defined set of interface building techniques based on ISO C
programming. Because of this, you will find that SWIG interfaces can
be easily compiled by virtually every C/C++ compiler and that they can
be used on any platform. Again, this is an important part of staying out

1716
Doc/Manual/Java.html
View file

File diff suppressed because it is too large Load diff

110
Doc/Manual/Javascript.html
View file

@ -1,13 +1,13 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<link rel="stylesheet" type="text/css" href="./style.css">
<link rel="stylesheet" type="text/css" href="style.css">
<title></title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<H1><a name="Javascript">26 SWIG and Javascript</a></H1>
<H1><a name="Javascript">27 SWIG and Javascript</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -52,21 +52,21 @@
<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">26.1 Overview</a></H2>
<H2><a name="Javascript_overview">27.1 Overview</a></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>
Javascript has gone beyond being a browser-based scripting language and with <a href="https://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.
<p>SWIG Javascript currently supports <strong>JavascriptCore</strong>, the Javascript engine used by <code>Safari/Webkit</code>, and <a href="https://v8.dev/"><strong>v8</strong></a>, which is used by <code>Chromium</code> and <code>node.js</code>.</p>
<p><a href="https://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">26.2 Preliminaries</a></H2>
<H2><a name="Javascript_preliminaries">27.2 Preliminaries</a></H2>
<H3><a name="Javascript_running_swig">26.2.1 Running SWIG</a></H3>
<H3><a name="Javascript_running_swig">27.2.1 Running SWIG</a></H3>
<p>Suppose that you defined a SWIG module such as the following:</p>
@ -101,7 +101,7 @@ that era had a component &gt; 99. For example:</p>
<pre>
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
</div>
<p>If you're targetting V8 &gt;= 4.3.0, you would just run swig like so:</p>
<p>If you're targeting V8 &gt;= 4.3.0, you would just run swig like so:</p>
<div class="shell">
<pre>
$ swig -c++ -javascript -v8 example.i</pre>
@ -121,7 +121,7 @@ void example_initialize(v8::Handle&lt;v8::Object&gt; exports)</pre>
<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">26.2.2 Running Tests and Examples</a></H3>
<H3><a name="Javascript_running_tests_examples">27.2.2 Running Tests and Examples</a></H3>
<p>The configuration for tests and examples currently supports Linux and Mac only and not MinGW (Windows) yet.</p>
@ -153,7 +153,7 @@ $ make check-javascript-test-suite ENGINE=jsc</pre>
$ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
</div>
<H3><a name="Javascript_known_issues">26.2.3 Known Issues</a></H3>
<H3><a name="Javascript_known_issues">27.2.3 Known Issues</a></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>
@ -161,7 +161,7 @@ $ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
<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>C89 incompatibility: 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>
@ -170,12 +170,12 @@ $ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
<p>The primary development environment has been Linux (Ubuntu 12.04). Windows and Mac OS X 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">26.3 Integration</a></H2>
<H2><a name="Javascript_integration">27.3 Integration</a></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">26.3.1 Creating node.js Extensions</a></H3>
<H3><a name="Javascript_node_extensions">27.3.1 Creating node.js Extensions</a></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 Mac OS X 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/ubuntu/node.js/">PPA</a> available.</p>
@ -221,7 +221,7 @@ 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">26.3.1.1 Troubleshooting</a></H4>
<H4><a name="Javascript_troubleshooting">27.3.1.1 Troubleshooting</a></H4>
<ul>
@ -233,12 +233,12 @@ require("./build/Release/example")</pre>
$ sudo apt-get remove gyp</pre>
</div>
<H3><a name="Javascript_embedded_webkit">26.3.2 Embedded Webkit</a></H3>
<H3><a name="Javascript_embedded_webkit">27.3.2 Embedded Webkit</a></H3>
<p>Webkit is pre-installed on Mac OS X and available as a library for GTK.</p>
<H4><a name="Javascript_osx">26.3.2.1 Mac OS X</a></H4>
<H4><a name="Javascript_osx">27.3.2.1 Mac OS X</a></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>
@ -286,10 +286,10 @@ extern bool example_initialize(JSGlobalContextRef context, JSObjectRef* exports)
@end</pre>
</div>
<H4><a name="Javascript_gtk">26.3.2.2 GTK</a></H4>
<H4><a name="Javascript_gtk">27.3.2.2 GTK</a></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>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>
@ -300,38 +300,38 @@ extern bool example_initialize(JSGlobalContextRef context);
int main(int argc, char* argv[])
{
// Initialize GTK+
gtk_init(&amp;argc, &amp;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);
// 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);
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/");
// 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();
// Run the main GTK+ event loop
gtk_main();
return 0;
return 0;
}</pre>
</div>
<H3><a name="Javascript_applications_webkit">26.3.3 Creating Applications with node-webkit</a></H3>
<H3><a name="Javascript_applications_webkit">27.3.3 Creating Applications with node-webkit</a></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>
@ -415,19 +415,19 @@ open new windows, and many more things.
var example = require("example");
var x = 18;
var y = 24;
var z = example.gcd(x,y);
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_examples">26.4 Examples</a></H2>
<H2><a name="Javascript_examples">27.4 Examples</a></H2>
<p>Some basic examples are shown here in more detail.</p>
<H3><a name="Javascript_simple_example">26.4.1 Simple</a></H3>
<H3><a name="Javascript_simple_example">27.4.1 Simple</a></H3>
<p>The common example <code>simple</code> looks like this:</p>
@ -467,7 +467,7 @@ var example = require("./build/Release/example");
// calling the global method
var x = 42;
var y = 105;
var g = example.gcd(x,y);
var g = example.gcd(x, y);
// Accessing the global variable
var f = example.Foo;
@ -477,7 +477,7 @@ example.Foo = 3.1415926;</pre>
<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">26.4.2 Class</a></H3>
<H3><a name="Javascript_class_example">27.4.2 Class</a></H3>
<p>The common example <code>class</code> defines three classes, <code>Shape</code>, <code>Circle</code>, and <code>Square</code>:</p>
@ -604,15 +604,15 @@ 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.
<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/Inheritance_and_the_prototype_chain">Inheritance and the prototype chain</a>, for instance.
</p>
<H2><a name="Javascript_implementation">26.5 Implementation</a></H2>
<H2><a name="Javascript_implementation">27.5 Implementation</a></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">26.5.1 Source Code</a></H3>
<H3><a name="Javascript_source_code">27.5.1 Source Code</a></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>
@ -713,7 +713,7 @@ Template::Template(const String *code_) { ... }
...</pre>
</div>
<H3><a name="Javascript_code_templates">26.5.2 Code Templates</a></H3>
<H3><a name="Javascript_code_templates">27.5.2 Code Templates</a></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>
@ -742,7 +742,7 @@ t_register.replace("$jsparent", state.clazz(NAME_MANGLED))
.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>
<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")
@ -752,7 +752,7 @@ t_register.replace("$jsparent", state.clazz(NAME_MANGLED))
</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">26.5.3 Emitter</a></H3>
<H3><a name="Javascript_emitter">27.5.3 Emitter</a></H3>
<p>The Javascript module delegates code generation to a <code>JSEmitter</code> instance. The following extract shows the essential interface:</p>
@ -871,7 +871,7 @@ int JAVASCRIPT::classHandler(Node *n) {
</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">26.5.4 Emitter states</a></H3>
<H3><a name="Javascript_emitter_states">27.5.4 Emitter states</a></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>
@ -915,13 +915,13 @@ state.clazz(NAME, Getattr(n, "sym:name"));</pre>
<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">26.5.5 Handling Exceptions in JavascriptCore</a></H3>
<H3><a name="Javascript_jsc_exceptions">27.5.5 Handling Exceptions in JavascriptCore</a></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)
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;
@ -933,7 +933,7 @@ void script_exception_to_string(JSContextRef js_context,JSValueRef exception_val
exception_object = JSValueToObject(js_context, exception_value_ref, NULL);
/* source url */
strcpy(return_error_string,&quot;[&quot;);
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);

323
Doc/Manual/Library.html
View file

@ -7,31 +7,38 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Library">9 SWIG library</a></H1>
<H1><a name="Library">11 SWIG library</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="#Library_nn2">The %include directive and library search path</a>
<li><a href="#Library_nn3">C Arrays and Pointers</a>
<li><a href="#Library_nn3">C arrays and pointers</a>
<ul>
<li><a href="#Library_nn4">cpointer.i</a>
<li><a href="#Library_carrays">carrays.i</a>
<li><a href="#Library_nn6">cmalloc.i</a>
<li><a href="#Library_nn7">cdata.i</a>
</ul>
<li><a href="#Library_nn8">C String Handling</a>
<li><a href="#Library_nn8">C string handling</a>
<ul>
<li><a href="#Library_nn9">Default string handling</a>
<li><a href="#Library_nn10">Passing binary data</a>
<li><a href="#Library_nn11">Using %newobject to release memory</a>
<li><a href="#Library_nn12">cstring.i</a>
</ul>
<li><a href="#Library_stl_cpp_library">STL/C++ Library</a>
<li><a href="#Library_stl_cpp_library">STL/C++ library</a>
<ul>
<li><a href="#Library_std_string">std::string</a>
<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>
<ul>
<li><a href="#Library_shared_ptr_basics">shared_ptr basics</a>
<li><a href="#Library_shared_ptr_inheritance">shared_ptr and inheritance</a>
<li><a href="#Library_shared_ptr_overloading">shared_ptr and method overloading</a>
<li><a href="#Library_shared_ptr_templates">shared_ptr and templates</a>
<li><a href="#Library_shared_ptr_directors">shared_ptr and directors</a>
</ul>
<li><a href="#Library_std_auto_ptr">auto_ptr smart pointer</a>
</ul>
<li><a href="#Library_nn16">Utility Libraries</a>
@ -60,7 +67,7 @@ Alternative libraries provide similar functionality. Please read this chapter
carefully if you used the old libraries.
</p>
<H2><a name="Library_nn2">9.1 The %include directive and library search path</a></H2>
<H2><a name="Library_nn2">11.1 The %include directive and library search path</a></H2>
<p>
@ -92,7 +99,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">9.2 C Arrays and Pointers</a></H2>
<H2><a name="Library_nn3">11.2 C arrays and pointers</a></H2>
<p>
@ -104,7 +111,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">9.2.1 cpointer.i</a></H3>
<H3><a name="Library_nn4">11.2.1 cpointer.i</a></H3>
<p>
@ -115,7 +122,7 @@ this module is in generating pointers to primitive datatypes such as
</p>
<p>
<b><tt>%pointer_functions(type,name)</tt></b>
<b><tt>%pointer_functions(type, name)</tt></b>
</p>
<div class="indent">
@ -195,7 +202,7 @@ Now, in Python:
<pre>
&gt;&gt;&gt; import example
&gt;&gt;&gt; c = example.new_intp() # Create an "int" for storing result
&gt;&gt;&gt; example.add(3,4,c) # Call function
&gt;&gt;&gt; example.add(3, 4, c) # Call function
&gt;&gt;&gt; example.intp_value(c) # Dereference
7
&gt;&gt;&gt; example.delete_intp(c) # Delete
@ -205,7 +212,7 @@ Now, in Python:
</div>
<p>
<b><tt>%pointer_class(type,name)</tt></b>
<b><tt>%pointer_class(type, name)</tt></b>
</p>
<div class="indent">
@ -218,13 +225,13 @@ interface is as follows:
<div class="code">
<pre>
struct name {
name(); // Create pointer object
~name(); // Delete pointer object
void assign(type value); // Assign value
type value(); // Get value
type *cast(); // Cast the pointer to original type
static name *frompointer(type *); // Create class wrapper from existing
// pointer
name(); // Create pointer object
~name(); // Delete pointer object
void assign(type value); // Assign value
type value(); // Get value
type *cast(); // Cast the pointer to original type
static name *frompointer(type *); // Create class wrapper from existing
// pointer
};
</pre>
</div>
@ -275,7 +282,7 @@ Now, in Python (using proxy classes)
<pre>
&gt;&gt;&gt; import example
&gt;&gt;&gt; c = example.intp() # Create an "int" for storing result
&gt;&gt;&gt; example.add(3,4,c) # Call function
&gt;&gt;&gt; example.add(3, 4, c) # Call function
&gt;&gt;&gt; c.value() # Dereference
7
</pre>
@ -320,7 +327,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">9.2.2 carrays.i</a></H3>
<H3><a name="Library_carrays">11.2.2 carrays.i</a></H3>
<p>
@ -331,7 +338,7 @@ raw C array data.
</p>
<p>
<b><tt>%array_functions(type,name)</tt></b>
<b><tt>%array_functions(type, name)</tt></b>
</p>
<div class="indent">
@ -384,10 +391,10 @@ function like this:
<div class="code">
<pre>
void print_array(double x[10]) {
int i;
for (i = 0; i &lt; 10; i++) {
printf("[%d] = %g\n", i, x[i]);
}
int i;
for (i = 0; i &lt; 10; i++) {
printf("[%d] = %g\n", i, x[i]);
}
}
</pre>
</div>
@ -411,20 +418,20 @@ void print_array(double x[10]);
Now, in a scripting language, you might write this:
</p>
<div class="code">
<div class="targetlang">
<pre>
a = new_doubleArray(10) # Create an array
for i in range(0,10):
doubleArray_setitem(a,i,2*i) # Set a value
print_array(a) # Pass to C
delete_doubleArray(a) # Destroy array
a = new_doubleArray(10) # Create an array
for i in range(0, 10):
doubleArray_setitem(a, i, 2 * i) # Set a value
print_array(a) # Pass to C
delete_doubleArray(a) # Destroy array
</pre>
</div>
</div>
<p>
<b><tt>%array_class(type,name)</tt></b>
<b><tt>%array_class(type, name)</tt></b>
</p>
<div class="indent">
@ -436,13 +443,13 @@ interface is as follows:
<div class="code">
<pre>
struct name {
name(int nelements); // Create an array
~name(); // Delete array
type getitem(int index); // Return item
void setitem(int index, type value); // Set item
type *cast(); // Cast to original type
static name *frompointer(type *); // Create class wrapper from
// existing pointer
name(int nelements); // Create an array
~name(); // Delete array
type getitem(int index); // Return item
void setitem(int index, type value); // Set item
type *cast(); // Cast to original type
static name *frompointer(type *); // Create class wrapper from
// existing pointer
};
</pre>
</div>
@ -475,12 +482,12 @@ void print_array(double x[10]);
Allows you to do this:
</p>
<div class="code">
<div class="targetlang">
<pre>
import example
c = example.doubleArray(10) # Create double[10]
for i in range(0,10):
c[i] = 2*i # Assign values
for i in range(0, 10):
c[i] = 2 * i # Assign values
example.print_array(c) # Pass to C
</pre>
</div>
@ -496,9 +503,10 @@ you should consider using a special array object rather than a bare pointer.
<p>
<b>Note:</b> <tt>%array_functions()</tt> and <tt>%array_class()</tt> should not be
used with types of <tt>char</tt> or <tt>char *</tt>.
SWIG's default handling of these types is to handle them as character strings and the two macros do not do enough to change this.
</p>
<H3><a name="Library_nn6">9.2.3 cmalloc.i</a></H3>
<H3><a name="Library_nn6">11.2.3 cmalloc.i</a></H3>
<p>
@ -507,7 +515,7 @@ This module defines macros for wrapping the low-level C memory allocation functi
</p>
<p>
<b><tt>%malloc(type [,name=type])</tt></b>
<b><tt>%malloc(type [, name=type])</tt></b>
</p>
<div class="indent">
@ -530,7 +538,7 @@ is not a valid identifier (e.g., "<tt>int *</tt>", "<tt>double **</tt>", etc.).
</div>
<p>
<b><tt>%calloc(type [,name=type])</tt></b>
<b><tt>%calloc(type [, name=type])</tt></b>
</p>
<div class="indent">
@ -551,7 +559,7 @@ If <tt>type</tt> is <tt>void</tt>, then the size parameter <tt>sz</tt> is requir
</div>
<p>
<b><tt>%realloc(type [,name=type])</tt></b>
<b><tt>%realloc(type [, name=type])</tt></b>
</p>
<div class="indent">
@ -574,7 +582,7 @@ it holds 100 integers.
</div>
<p>
<b><tt>%free(type [,name=type])</tt></b>
<b><tt>%free(type [, name=type])</tt></b>
</p>
<div class="indent">
@ -590,7 +598,7 @@ void free_<em>name</em>(<em>type</em> *ptr);
</div>
<p>
<b><tt>%sizeof(type [,name=type])</tt></b>
<b><tt>%sizeof(type [, name=type])</tt></b>
</p>
<div class="indent">
@ -606,7 +614,7 @@ Creates the constant:
</div>
<p>
<b><tt>%allocators(type [,name=type])</tt></b>
<b><tt>%allocators(type [, name=type])</tt></b>
</p>
<div class="indent"><p>
@ -659,7 +667,7 @@ Now, in a script:
</pre>
</div>
<H3><a name="Library_nn7">9.2.4 cdata.i</a></H3>
<H3><a name="Library_nn7">11.2.4 cdata.i</a></H3>
<p>
@ -716,14 +724,14 @@ Python example:
<div class="targetlang">
<pre>
&gt;&gt;&gt; a = intArray(10)
&gt;&gt;&gt; for i in range(0,10):
&gt;&gt;&gt; for i in range(0, 10):
... a[i] = i
&gt;&gt;&gt; b = cdata(a,40)
&gt;&gt;&gt; b = cdata(a, 40)
&gt;&gt;&gt; b
'\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\x04
\x00\x00\x00\x05\x00\x00\x00\x06\x00\x00\x00\x07\x00\x00\x00\x08\x00\x00\x00\t'
&gt;&gt;&gt; c = intArray(10)
&gt;&gt;&gt; memmove(c,b)
&gt;&gt;&gt; memmove(c, b)
&gt;&gt;&gt; print c[4]
4
&gt;&gt;&gt;
@ -735,7 +743,7 @@ Since the size of data is not always known, the following macro is also defined:
</p>
<p>
<b><tt>%cdata(type [,name=type])</tt></b>
<b><tt>%cdata(type [, name=type])</tt></b>
</p>
<div class="indent">
@ -761,7 +769,7 @@ char *cdata_<em>name</em>(type* ptr, int nitems)
Clearly they are unsafe.
</p>
<H2><a name="Library_nn8">9.3 C String Handling</a></H2>
<H2><a name="Library_nn8">11.3 C string handling</a></H2>
<p>
@ -781,7 +789,7 @@ morality. The modules in this section provide basic functionality
for manipulating raw C strings.
</p>
<H3><a name="Library_nn9">9.3.1 Default string handling</a></H3>
<H3><a name="Library_nn9">11.3.1 Default string handling</a></H3>
<p>
@ -801,7 +809,7 @@ target language. In other words, if you were using a language like Tcl,
and you wrote this,
</p>
<div class="code">
<div class="targetlang">
<pre>
% foo Hello
</pre>
@ -822,7 +830,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">9.3.2 Passing binary data</a></H3>
<H3><a name="Library_nn10">11.3.2 Passing binary data</a></H3>
<p>
@ -852,10 +860,10 @@ size_t parity(char *str, size_t len, size_t initial);
Now, in the target language, you can use binary string data like this:
</p>
<div class="code">
<div class="targetlang">
<pre>
&gt;&gt;&gt; s = "H\x00\x15eg\x09\x20"
&gt;&gt;&gt; parity(s,0)
&gt;&gt;&gt; parity(s, 0)
</pre>
</div>
@ -864,7 +872,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">9.3.3 Using %newobject to release memory</a></H3>
<H3><a name="Library_nn11">11.3.3 Using %newobject to release memory</a></H3>
<p>
@ -874,9 +882,9 @@ If you have a function that allocates memory like this,
<div class="code">
<pre>
char *foo() {
char *result = (char *) malloc(...);
...
return result;
char *result = (char *) malloc(...);
...
return result;
}
</pre>
</div>
@ -905,7 +913,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">9.3.4 cstring.i</a></H3>
<H3><a name="Library_nn12">11.3.4 cstring.i</a></H3>
<p>
@ -919,16 +927,16 @@ implementation:
<div class="code">
<pre>
void get_path(char *s) {
// Potential buffer overflow---uh, oh.
sprintf(s,"%s/%s", base_directory, sub_directory);
// Potential buffer overflow---uh, oh.
sprintf(s, "%s/%s", base_directory, sub_directory);
}
...
// Somewhere else in the C program
{
char path[1024];
...
get_path(path);
...
char path[1024];
...
get_path(path);
...
}
</pre>
</div>
@ -1236,8 +1244,8 @@ returned in a parameter of type <tt>char **</tt>. For example:
<div class="code">
<pre>
void foo(char **s) {
*s = (char *) malloc(64);
sprintf(*s, "Hello world\n");
*s = (char *) malloc(64);
sprintf(*s, "Hello world\n");
}
</pre>
</div>
@ -1284,10 +1292,10 @@ returned in two parameters of type <tt>char **</tt> and <tt>int *</tt>. For exa
<div class="code">
<pre>
void foo(char **s, int *sz) {
*s = (char *) malloc(64);
*sz = 64;
// Write some binary data
...
*s = (char *) malloc(64);
*sz = 64;
// Write some binary data
...
}
</pre>
</div>
@ -1337,7 +1345,7 @@ You could wrap it with a function like this:
<div class="code">
<pre>
void my_get_data(char **result, int *len) {
*result = get_data(len);
*result = get_data(len);
}
</pre>
</div>
@ -1357,7 +1365,7 @@ to accomplish this in SWIG. This library provides support for a few common tech
</li>
<li>If used in C++, this library uses <tt>new</tt> and <tt>delete []</tt> for memory
allocation. If using ANSI C, the library uses <tt>malloc()</tt> and <tt>free()</tt>.
allocation. If using C, the library uses <tt>malloc()</tt> and <tt>free()</tt>.
</li>
<li>Rather than manipulating <tt>char *</tt> directly, you might consider using a special string
@ -1365,7 +1373,7 @@ structure or class instead.
</li>
</ul>
<H2><a name="Library_stl_cpp_library">9.4 STL/C++ Library</a></H2>
<H2><a name="Library_stl_cpp_library">11.4 STL/C++ library</a></H2>
<p>
@ -1385,16 +1393,24 @@ 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::array (C++11)</td> <td>array</td> <td>std_array.i</td> </tr>
<tr> <td>std::auto_ptr</td> <td>memory</td> <td>std_auto_ptr.i</td> </tr>
<tr> <td>std::complex</td> <td>complex</td> <td>std_complex.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>
<tr> <td>std::multimap (C++11)</td> <td>multimap</td> <td>std_multimap.i</td> </tr>
<tr> <td>std::multiset (C++11)</td> <td>multiset</td> <td>std_multiset.i</td> </tr>
<tr> <td>std::pair</td> <td>utility</td> <td>std_pair.i</td> </tr>
<tr> <td>std::set</td> <td>set</td> <td>std_set.i</td> </tr>
<tr> <td>std::string</td> <td>string</td> <td>std_string.i</td> </tr>
<tr> <td>std::unordered_map (C++11)</td> <td>unordered_map</td> <td>std_unordered_map.i</td> </tr>
<tr> <td>std::unordered_multimap (C++11)</td> <td>unordered_multimap</td> <td>std_unordered_multimap.i</td> </tr>
<tr> <td>std::unordered_multiset (C++11)</td> <td>unordered_multiset</td> <td>std_unordered_multiset.i</td> </tr>
<tr> <td>std::unordered_set (C++11)</td> <td>unordered_set</td> <td>std_unordered_set.i</td> </tr>
<tr> <td>std::vector</td> <td>vector</td> <td>std_vector.i</td> </tr>
<tr> <td>std::array</td> <td>array (C++11)</td> <td>std_array.i</td> </tr>
<tr> <td>std::shared_ptr</td> <td>shared_ptr (C++11)</td> <td>std_shared_ptr.i</td> </tr>
<tr> <td>std::wstring</td> <td>wstring</td> <td>std_wstring.i</td> </tr>
<tr> <td>std::shared_ptr (C++11)</td> <td>shared_ptr</td> <td>std_shared_ptr.i</td> </tr>
</table>
@ -1404,7 +1420,7 @@ Please look for the library files in the appropriate language library directory.
</p>
<H3><a name="Library_std_string">9.4.1 std::string</a></H3>
<H3><a name="Library_std_string">11.4.1 std::string</a></H3>
<p>
@ -1460,7 +1476,7 @@ In the target language:
<div class="targetlang">
<pre>
x = my_struct();
x.foo="Hello World"; # assign with string
x.foo = "Hello World"; # assign with string
print x.foo; # print as string
</pre>
</div>
@ -1488,7 +1504,7 @@ void foo(string s, const String &amp;t); // std_string typemaps still applie
</pre>
</div>
<H3><a name="Library_std_vector">9.4.2 std::vector</a></H3>
<H3><a name="Library_std_vector">11.4.2 std::vector</a></H3>
<p>
@ -1503,8 +1519,8 @@ instantiate different versions of <tt>vector</tt> for the types that you want to
%include "std_vector.i"
namespace std {
%template(vectori) vector&lt;int&gt;;
%template(vectord) vector&lt;double&gt;;
%template(vectori) vector&lt;int&gt;;
%template(vectord) vector&lt;double&gt;;
};
</pre>
</div>
@ -1554,19 +1570,19 @@ To illustrate the use of this library, consider the following functions:
#include &lt;numeric&gt;
double average(std::vector&lt;int&gt; v) {
return std::accumulate(v.begin(),v.end(),0.0)/v.size();
return std::accumulate(v.begin(), v.end(), 0.0)/v.size();
}
std::vector&lt;double&gt; half(const std::vector&lt;double&gt;&amp; v) {
std::vector&lt;double&gt; w(v);
for (unsigned int i=0; i&lt;w.size(); i++)
w[i] /= 2.0;
return w;
std::vector&lt;double&gt; w(v);
for (unsigned int i=0; i&lt;w.size(); i++)
w[i] /= 2.0;
return w;
}
void halve_in_place(std::vector&lt;double&gt;&amp; v) {
std::transform(v.begin(),v.end(),v.begin(),
std::bind2nd(std::divides&lt;double&gt;(),2.0));
for (std::vector&lt;double&gt;::iterator it = v.begin(); it != v.end(); ++it)
*it /= 2.0;
}
</pre>
</div>
@ -1585,8 +1601,8 @@ To wrap with SWIG, you might write the following:
%include "std_vector.i"
// Instantiate templates used by example
namespace std {
%template(IntVector) vector&lt;int&gt;;
%template(DoubleVector) vector&lt;double&gt;;
%template(IntVector) vector&lt;int&gt;;
%template(DoubleVector) vector&lt;double&gt;;
}
// Include the header file with above prototypes
@ -1602,20 +1618,20 @@ Now, to illustrate the behavior in the scripting interpreter, consider this Pyth
<pre>
&gt;&gt;&gt; from example import *
&gt;&gt;&gt; iv = IntVector(4) # Create an vector&lt;int&gt;
&gt;&gt;&gt; for i in range(0,4):
&gt;&gt;&gt; for i in range(0, 4):
... iv[i] = i
&gt;&gt;&gt; average(iv) # Call method
1.5
&gt;&gt;&gt; average([0,1,2,3]) # Call with list
&gt;&gt;&gt; average([0, 1, 2, 3]) # Call with list
1.5
&gt;&gt;&gt; half([1,2,3]) # Half a list
(0.5,1.0,1.5)
&gt;&gt;&gt; halve_in_place([1,2,3]) # Oops
&gt;&gt;&gt; half([1, 2, 3]) # Half a list
(0.5, 1.0, 1.5)
&gt;&gt;&gt; halve_in_place([1, 2, 3]) # Oops
Traceback (most recent call last):
File "&lt;stdin&gt;", line 1, in ?
TypeError: Type error. Expected _p_std__vectorTdouble_t
&gt;&gt;&gt; dv = DoubleVector(4)
&gt;&gt;&gt; for i in range(0,4):
&gt;&gt;&gt; for i in range(0, 4):
... dv[i] = i
&gt;&gt;&gt; halve_in_place(dv) # Ok
&gt;&gt;&gt; for i in dv:
@ -1629,7 +1645,7 @@ TypeError: Type error. Expected _p_std__vectorTdouble_t
Traceback (most recent call last):
File "&lt;stdin&gt;", line 1, in ?
File "example.py", line 81, in __setitem__
def __setitem__(*args): return apply(examplec.DoubleVector___setitem__,args)
def __setitem__(*args): return apply(examplec.DoubleVector___setitem__, args)
IndexError: vector index out of range
&gt;&gt;&gt;
</pre>
@ -1645,7 +1661,7 @@ make sure you include the appropriate <tt>using</tt> or typedef directives. For
%include "std_vector.i"
namespace std {
%template(IntVector) vector&lt;int&gt;;
%template(IntVector) vector&lt;int&gt;;
}
using namespace std;
@ -1667,7 +1683,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">9.4.3 STL exceptions</a></H3>
<H3><a name="Library_stl_exceptions">11.4.3 STL exceptions</a></H3>
<p>
@ -1717,7 +1733,10 @@ 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">9.4.4 shared_ptr smart pointer</a></H3>
<H3><a name="Library_std_shared_ptr">11.4.4 shared_ptr smart pointer</a></H3>
<H4><a name="Library_shared_ptr_basics">11.4.4.1 shared_ptr basics</a></H4>
<p>
@ -1813,8 +1832,11 @@ System.out.println(val1 + " " + val2);
</pre>
</div>
<H4><a name="Library_shared_ptr_inheritance">11.4.4.2 shared_ptr and inheritance</a></H4>
<p>
This shared_ptr library works quite differently to SWIG's normal, but somewhat limited,
The shared_ptr library works quite differently to SWIG's normal, but somewhat limited,
<a href="SWIGPlus.html#SWIGPlus_smart_pointers">smart pointer handling</a>.
The shared_ptr library does not generate extra wrappers, just for smart pointer handling, in addition to the proxy class.
The normal proxy class including inheritance relationships is generated as usual.
@ -1892,7 +1914,7 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
<div class="code">
<pre>
%include "boost_shared_ptr.i"
%include &lt;boost_shared_ptr.i&gt;
%shared_ptr(GrandParent);
%shared_ptr(Parent);
%shared_ptr(Child);
@ -1901,14 +1923,79 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
</pre>
</div>
<H4><a name="Library_shared_ptr_overloading">11.4.4.3 shared_ptr and method overloading</a></H4>
<p>
<b>Note:</b> There is somewhat limited support for <tt>%shared_ptr</tt> and the director feature
and the degress of success varies among the different target languages.
Please help to improve this support by providing patches with improvements.
A C++ compiler can disambiguate a method overloaded by a shared_ptr and one using the raw underlying type.
For example, either one of these methods can be called in C++:
</p>
<div class="code">
<pre>
int age(std::shared_ptr&lt;GrandParent&gt; num);
int age(GrandParent&amp; num);
</pre>
</div>
<p>
When wrapped by SWIG, disambiguation is not possible using the overloaded names as there is just one equivalent type (<tt>GrandParent</tt>) in the target language.
SWIG will choose to wrap just the first method by default.
<a href="SWIGPlus.html#SWIGPlus_nn25">Ambiguity in overloading</a> discusses ways to control which method(s) gets wrapped using <tt>%ignore</tt> or <tt>%rename</tt>.
For the interested reader, SWIG detects that they are equivalent types via the <a href=Typemaps.html#Typemaps_typecheck_pointer>typecheck typemaps</a> in the shared_ptr library.
</p>
<H4><a name="Library_shared_ptr_templates">11.4.4.4 shared_ptr and templates</a></H4>
<p>
The <tt>%shared_ptr</tt> macro should be used for all the required instantiations
of the template before each of the <tt>%template</tt> instantiations.
For example, consider <tt>number.h</tt> containing the following illustrative template:
</p>
<div class="code">
<pre>
#include &lt;memory&gt;
template&lt;int N&gt; struct Number {
int num;
Number() : num(N) {}
static std::shared_ptr&lt;Number&lt;N&gt;&gt; make() { return std::make_shared&lt;Number&lt;N&gt;&gt;(); }
};
</pre>
</div>
<p>
The SWIG code below shows the required ordering:
</p>
<div class="code">
<pre>
%include &lt;std_shared_ptr.i&gt;
%shared_ptr(Number&lt;10&gt;);
%shared_ptr(Number&lt;42&gt;);
%{
#include "number.h"
%}
%include "number.h"
%template(Number10) Number&lt;10&gt;;
%template(Number42) Number&lt;42&gt;;
</pre>
</div>
<H4><a name="Library_shared_ptr_directors">11.4.4.5 shared_ptr and directors</a></H4>
<p>
The languages that support shared_ptr also have support for using shared_ptr with directors.
</p>
<H3><a name="Library_std_auto_ptr">9.4.5 auto_ptr smart pointer</a></H3>
<H3><a name="Library_std_auto_ptr">11.4.5 auto_ptr smart pointer</a></H3>
<p>
@ -1957,10 +2044,10 @@ int value = k.getValue();
</pre>
</div>
<H2><a name="Library_nn16">9.5 Utility Libraries</a></H2>
<H2><a name="Library_nn16">11.5 Utility Libraries</a></H2>
<H3><a name="Library_nn17">9.5.1 exception.i</a></H3>
<H3><a name="Library_nn17">11.5.1 exception.i</a></H3>
<p>
@ -2011,11 +2098,11 @@ For example:
<pre>
%include "exception.i"
%exception std::vector::getitem {
try {
$action
} catch (std::out_of_range&amp; e) {
SWIG_exception(SWIG_IndexError,const_cast&lt;char*&gt;(e.what()));
}
try {
$action
} catch (std::out_of_range&amp; e) {
SWIG_exception(SWIG_IndexError, const_cast&lt;char*&gt;(e.what()));
}
}
</pre>
</div>

318
Doc/Manual/Lisp.html
View file

@ -7,11 +7,10 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Lisp">27 SWIG and Common Lisp</a></H1>
<H1><a name="Lisp">29 SWIG and Common Lisp</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="#Lisp_nn2">Allegro Common Lisp</a>
<li><a href="#Lisp_nn3">Common Foreign Function Interface(CFFI)</a>
<ul>
<li><a href="#Lisp_nn4">Additional Commandline Options </a>
@ -19,12 +18,9 @@
<li><a href="#Lisp_nn6">Generating CFFI bindings for C++ code</a>
<li><a href="#Lisp_nn7">Inserting user code into generated files</a>
</ul>
<li><a href="#Lisp_nn8">CLISP</a>
<ul>
<li><a href="#Lisp_nn9">Additional Commandline Options </a>
<li><a href="#Lisp_nn10">Details on CLISP bindings</a>
</ul>
<li><a href="#Lisp_nn11">UFFI </a>
</ul>
</div>
<!-- INDEX -->
@ -38,26 +34,17 @@
finance, and also common in computer science education.
There are more than 9 different implementations of common lisp which
are available, all have different foreign function
interfaces. SWIG currently supports only the Allegro Common
Lisp, Common Foreign Function Interface(CFFI), CLisp and UFFI
foreign function interfaces.
</p>
<H2><a name="Lisp_nn2">27.1 Allegro Common Lisp</a></H2>
<p>
Allegro Common Lisp support in SWIG has been updated to include
support for both C and C++. You can read about the interface
<a href="Allegrocl.html#Allegrocl">here</a>
interfaces. SWIG currently supports the
Common Foreign Function Interface(CFFI).
</p>
<H2><a name="Lisp_nn3">27.2 Common Foreign Function Interface(CFFI)</a></H2>
<H2><a name="Lisp_nn3">29.2 Common Foreign Function Interface(CFFI)</a></H2>
<p>
CFFI, the Common Foreign Function Interface, is a portable foreign
function interface for ANSI Common Lisp systems, similar in
spirit to UFFI. Unlike UFFI, CFFI requires only a small set of
function interface for ANSI Common Lisp systems.
CFFI requires only a small set of
low-level functionality from the Lisp implementation, such as
calling a foreign function by name, allocating foreign memory,
and dereferencing pointers.
@ -78,18 +65,9 @@ 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">27.2.1 Additional Commandline Options </a></H3>
<H3><a name="Lisp_nn4">29.2.1 Additional Commandline Options </a></H3>
<p>
The following table list the additional commandline options available for the CLISP module. They can also be seen by using:
</p>
<div class="code"><pre>
swig -cffi -help
</pre></div>
<br/>
<table summary="CFFI specific options">
<tr>
<th> CFFI specific options</th>
@ -119,12 +97,15 @@ swig -cffi -help
</table>
<H3><a name="Lisp_nn5">27.2.2 Generating CFFI bindings</a></H3>
<H3><a name="Lisp_nn5">29.2.2 Generating CFFI bindings</a></H3>
<p>
As we mentioned earlier the ideal way to use SWIG is to use interface
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:
</p>
<div class="code"><pre>
#define y 5
@ -134,29 +115,31 @@ typedef int days;
struct bar {
short p, q;
char a, b;
int *z[1000];
struct bar * n;
char a, b;
int *z[1000];
struct bar * n;
};
struct bar * my_struct;
struct foo {
int a;
struct foo * b[100];
int a;
struct foo * b[100];
};
int pointer_func(void (*ClosureFun)( void* _fun, void* _data, void* _evt ), int p);
int func123(div_t * p,int **q[100],int r[][1000][10]);
int func123(div_t * p, int **q[100], int r[][1000][10]);
void lispsort_double (int n, double * array);
enum color { RED, BLUE, GREEN};
</pre></div>
<p>
Corresponding to this we will write a simple interface file:
</p>
<div class="code"><pre>
%module test
@ -164,18 +147,20 @@ Corresponding to this we will write a simple interface file:
</pre></div>
<p>
The generated SWIG Code will be:
</p>
<div class="targetlang"><pre>
;;;SWIG wrapper code starts here
(cl:defmacro defanonenum (&amp;body enums)
"Converts anonymous enums to defconstants."
`(cl:progn ,@(cl:loop for value in enums
`(cl:progn , @(cl:loop for value in enums
for index = 0 then (cl:1+ index)
when (cl:listp value) do (cl:setf index (cl:second value)
value (cl:first value))
collect `(cl:defconstant ,value ,index))))
collect `(cl:defconstant , value , index))))
(cl:eval-when (:compile-toplevel :load-toplevel)
(cl:unless (cl:fboundp 'swig-lispify)
@ -281,7 +266,7 @@ Let's edit the interface file such that the C type "div_t*" is changed
%typemap(cin) div_t* ":my-pointer";
%feature("intern_function","1");
%feature("intern_function", "1");
%feature("export");
%feature("inline") lispsort_double;
@ -306,7 +291,7 @@ The <i>typemap(cin)</i> ensures that for all arguments which are input
The feature <i>intern_function</i> ensures that all C names are
interned using the <b>swig-lispify</b> function. The "1" given
to the feature is optional. The use of feature like
<i>%feature("intern_function","1");</i> globally enables
<i>%feature("intern_function", "1");</i> globally enables
interning for everything. If you want to target a single
function, or declaration then use the targeted version of
feature, <i>%feature("intern_function", "my-lispify")
@ -396,7 +381,7 @@ The feature <i>intern_function</i> ensures that all C names are
</pre></div>
<H3><a name="Lisp_nn6">27.2.3 Generating CFFI bindings for C++ code</a></H3>
<H3><a name="Lisp_nn6">29.2.3 Generating CFFI bindings for C++ code</a></H3>
<p>This feature to SWIG (for CFFI) is very new and still far from
@ -431,49 +416,48 @@ Also, while parsing the C++ file and generating C wrapper code SWIG
%include "target/header.h"
</pre></div>
<p>
Various features which were available for C headers can also be used
here. The target header which we are going to use here is:
</p>
<div class="code"><pre>
namespace OpenDemo {
class Test
{
{
public:
float x;
// constructors
Test (void) {x = 0;}
Test (float X) {x = X;}
float x;
// constructors
Test (void) {x = 0;}
Test (float X) {x = X;}
// vector addition
Test operator+ (const Test&amp; v) const {return Test (x+v.x);}
// vector addition
Test operator+ (const Test&amp; v) const {return Test (x+v.x);}
// length squared
float lengthSquared (void) const {return this-&gt;dot (*this);}
float lengthSquared (void) const {return this-&gt;dot (*this);}
static float distance (const Test&amp; a, const Test&amp; b){return(a-b).length();}
static float distance (const Test&amp; a, const Test&amp; b){return(a-b).length();}
inline Test parallelComponent (const Test&amp; unitBasis) const {
return unitBasis * projection;
}
inline Test parallelComponent (const Test&amp; unitBasis) const {
return unitBasis * projection;
}
Test setYtoZero (void) const {return Test (this-&gt;x);}
Test setYtoZero (void) const {return Test (this-&gt;x);}
static const Test zero;
};
static const Test zero;
};
inline Test operator* (float s, const Test&amp; v) {return v*s;}
inline Test operator* (float s, const Test&amp; v) {return v*s;}
inline std::ostream&amp; operator&lt;&lt; (std::ostream&amp; o, const Test&amp; v)
{
return o &lt;&lt; "(" &lt;&lt; v.x &lt;&lt; ")";
}
inline std::ostream&amp; operator&lt;&lt; (std::ostream&amp; o, const Test&amp; v)
{
return o &lt;&lt; "(" &lt;&lt; v.x &lt;&lt; ")";
}
inline Test RandomUnitVectorOnXZPlane (void)
{
return RandomVectorInUnitRadiusSphere().setYtoZero().normalize();
}
inline Test RandomUnitVectorOnXZPlane (void)
{
return RandomVectorInUnitRadiusSphere().setYtoZero().normalize();
}
}
</pre></div>
<p>The interface used is: </p>
@ -482,8 +466,10 @@ namespace OpenDemo {
%include "test.cpp"
</pre></div>
<p>
SWIG generates 3 files, the first one is a C wrap which we don't show,
the second is the plain CFFI wrapper which is as shown below:
</p>
<div class="targetlang"><pre>
(cffi:defcfun ("_wrap_Test_x_set" Test_x_set) :void
(self :pointer)
@ -532,11 +518,13 @@ SWIG generates 3 files, the first one is a C wrap which we don't show,
(cffi:defcfun ("_wrap_RandomUnitVectorOnXZPlane" RandomUnitVectorOnXZPlane) :pointer)
</pre></div>
<p>
The output is pretty good but it fails in disambiguating overloaded
functions such as the constructor, in this case. One way of
resolving this problem is to make the interface use the rename
directiv, but hopefully there are better solutions.
In addition SWIG also generates, a CLOS file
</p>
<div class="targetlang"><pre>
@ -572,7 +560,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">27.2.4 Inserting user code into generated files</a></H3>
<H3><a name="Lisp_nn7">29.2.4 Inserting user code into generated files</a></H3>
<p>
@ -612,195 +600,5 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
</p>
<H2><a name="Lisp_nn8">27.3 CLISP</a></H2>
<p>
<a href="http://clisp.cons.org">CLISP</a> is a feature-loaded
implementation of common lisp which is portable across most of the
operating system environments and hardware. CLISP includes an
interpreter, a compiler, a debugger, CLOS, MOP, a foreign
language interface, i18n, regular expressions, a socket
interface, and more. An X11 interface is available through CLX,
Garnet and CLUE/CLIO. Command line editing is provided by
readline. CLISP runs Maxima, ACL2 and many other Common Lisp
packages.
</p>
<p>
To run the clisp module of SWIG requires very little effort, you
just need to execute:
</p>
<div class="code"><pre>
swig -clisp -module <i>module-name</i> <i>file-name</i>
</pre></div>
<p>
Because of the high level nature of the CLISP FFI, the bindings
generated by SWIG may not be absolutely correct, and you may need
to modify them. The good thing is that you don't need to complex
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">27.3.1 Additional Commandline Options </a></H3>
<p>
The following table list the additional commandline options available for the CLISP module. They can also be seen by using:
</p>
<div class="code"><pre>
swig -clisp -help
</pre></div>
<br/>
<table summary="CLISP specific options">
<tr>
<th>CLISP specific options</th>
</tr>
<tr>
<td>-extern-all</td>
<td>If this option is given then clisp definitions for all the functions<br/>
and global variables will be created otherwise only definitions for<br/>
externed functions and variables are created.
</td>
</tr>
<tr>
<td>-generate-typedef</td>
<td>If this option is given then def-c-type will be used to generate<br/>
shortcuts according to the typedefs in the input.
</td>
</tr>
</table>
<H3><a name="Lisp_nn10">27.3.2 Details on CLISP bindings</a></H3>
<p>
As mentioned earlier the CLISP bindings generated by SWIG may need
some modifications. The clisp module creates a lisp file with
the same name as the module name. This
lisp file contains a 'defpackage' declaration, with the
package name same as the module name. This package uses the
'common-lisp' and 'ffi' packages. Also, package exports all
the functions, structures and variables for which an ffi
binding was generated.<br/>
After generating the defpackage statement, the clisp module also
sets the default language.
<div class="targetlang"><pre>
(defpackage :test
(:use :common-lisp :ffi)
(:export
:make-bar
:bar-x
:bar-y
:bar-a
:bar-b
:bar-z
:bar-n
:pointer_func
:func123
:make-cfunr
:lispsort_double
:test123))
(in-package :test)
(default-foreign-language :stdc)
</pre></div>
<p>
The ffi wrappers for functions and variables are generated as shown
below. When functions have arguments of type "double * array",
SWIG doesn't knows whether it is an 'out' argument or it is
an array which will be passed, so SWIG plays it safe by
declaring it as an '(array (ffi:c-ptr DOUBLE-FLOAT))'. For
arguments of type "int **z[100]" where SWIG has more
information, i.e., it knows that 'z' is an array of pointers to
pointers of integers, SWIG defines it to be '(z (ffi:c-ptr
(ffi:c-array (ffi:c-ptr (ffi:c-ptr ffi:int)) 100)))'
</p>
<div class="code"><pre>
extern "C" {
int pointer_func(void (*ClosureFun)( void* _fun, void* _data, void* _evt ), int y);
int func123(div_t * x,int **z[100],int y[][1000][10]);
void lispsort_double (int n, double * array);
void test123(float x , double y);
}
</pre></div>
<div class="targetlang"><pre>
(ffi:def-call-out pointer_func
(:name "pointer_func")
(:arguments (ClosureFun (ffi:c-function (:arguments (arg0 (ffi:c-pointer NIL))
(arg1 (ffi:c-pointer NIL))
(arg2 (ffi:c-pointer NIL)))
(:return-type NIL)))
(y ffi:int))
(:return-type ffi:int)
(:library +library-name+))
(ffi:def-call-out func123
(:name "func123")
(:arguments (x (ffi:c-pointer div_t))
(z (ffi:c-ptr (ffi:c-array (ffi:c-ptr (ffi:c-ptr ffi:int)) 100)))
(y (ffi:c-ptr (ffi:c-ptr (ffi:c-array ffi:int (1000 10))))))
(:return-type ffi:int)
(:library +library-name+))
(ffi:def-call-out lispsort_double
(:name "lispsort_double")
(:arguments (n ffi:int)
(array (ffi:c-ptr DOUBLE-FLOAT)))
(:return-type NIL)
(:library +library-name+))
(ffi:def-call-out test123
(:name "test")
(:arguments (x SINGLE-FLOAT)
(y DOUBLE-FLOAT))
(:return-type NIL)
(:library +library-name+))
</pre></div>
<p>
The module also handles strutcures and #define constants as shown
below. SWIG automatically adds the constructors and accessors
created for the struct to the list of symbols exported by the
package.
</p>
<div class="code"><pre>
struct bar {
short x, y;
char a, b;
int *z[1000];
struct bar * n;
};
#define max 1000
</pre></div>
<div class="targetlang"><pre>
(ffi:def-c-struct bar
(x :type ffi:short)
(y :type ffi:short)
(a :type character)
(b :type character)
(z :type (ffi:c-array (ffi:c-ptr ffi:int) 1000))
(n :type (ffi:c-pointer bar)))
(defconstant max 1000)
</pre></div>
<H2><a name="Lisp_nn11">27.4 UFFI </a></H2>
</body>
</html>

263
Doc/Manual/Lua.html
View file

@ -77,7 +77,7 @@
<p>
Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in clean C (that is, in the common subset of ANSI C and C++). It's also a <em>really</em> tiny language, less than 6000 lines of code, which compiles to &lt;100 kilobytes of binary code. It can be found at <a href="http://www.lua.org">http://www.lua.org</a>
Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in clean C (that is, in the common subset of ISO C and C++). It's also a <em>really</em> tiny language, less than 6000 lines of code, which compiles to &lt;100 kilobytes of binary code. It can be found at <a href="http://www.lua.org">http://www.lua.org</a>
</p>
<p>
eLua stands for Embedded Lua (can be thought of as a flavor of Lua) and offers the full implementation of the Lua programming language to the embedded world, extending it with specific features for efficient and portable software embedded development. eLua runs on smaller devices like microcontrollers and provides the full features of the regular Lua desktop version. More information on eLua can be found here: <a href="http://www.eluaproject.net">http://www.eluaproject.net</a>
@ -193,27 +193,27 @@ Normally Lua is embedded into another program and will be statically linked. An
extern int luaopen_example(lua_State* L); // declare the wrapped module
int main(int argc,char* argv[])
int main(int argc, char* argv[])
{
lua_State *L;
if (argc&lt;2)
{
printf("%s: &lt;filename.lua&gt;\n",argv[0]);
printf("%s: &lt;filename.lua&gt;\n", argv[0]);
return 0;
}
L=lua_open();
luaopen_base(L); // load basic libs (eg. print)
luaopen_example(L); // load the wrapped module
if (luaL_loadfile(L,argv[1])==0) // load and run the file
lua_pcall(L,0,0,0);
if (luaL_loadfile(L, argv[1])==0) // load and run the file
lua_pcall(L, 0, 0, 0);
else
printf("unable to load %s\n",argv[1]);
printf("unable to load %s\n", argv[1]);
lua_close(L);
return 0;
}
</pre></div>
<p>
A much improved set of code can be found in the Lua distribution <tt>src/lua/lua.c</tt>. Include your module, just add the external declaration &amp; add a <tt>#define LUA_EXTRALIBS {"example",luaopen_example}</tt>, at the relevant place.
A much improved set of code can be found in the Lua distribution <tt>src/lua/lua.c</tt>. Include your module, just add the external declaration &amp; add a <tt>#define LUA_EXTRALIBS {"example", luaopen_example}</tt>, at the relevant place.
</p>
<p>
The exact commands for compiling and linking vary from platform to platform. Here is a possible set of commands of doing this:
@ -272,8 +272,8 @@ require("example")
For those using Lua 5.0.x, you will also need an interpreter with the loadlib function (such as the default interpreter compiled with Lua). In order to dynamically load a module you must call the loadlib function with two parameters: the filename of the shared library, and the function exported by SWIG. Calling loadlib should return the function, which you then call to initialise the module
</p>
<div class="targetlang"><pre>
my_init=loadlib("example.so","luaopen_example") -- for Unix/Linux
--my_init=loadlib("example.dll","luaopen_example") -- for Windows
my_init=loadlib("example.so", "luaopen_example") -- for Unix/Linux
--my_init=loadlib("example.dll", "luaopen_example") -- for Windows
assert(my_init) -- make sure it's not nil
my_init() -- call the init fn of the lib
</pre></div>
@ -281,7 +281,7 @@ my_init() -- call the init fn of the lib
Or can be done in a single line of Lua code
</p>
<div class="targetlang"><pre>
assert(loadlib("example.so","luaopen_example"))()
assert(loadlib("example.so", "luaopen_example"))()
</pre></div>
@ -289,9 +289,9 @@ assert(loadlib("example.so","luaopen_example"))()
If the code didn't work, don't panic. The best thing to do is to copy the module and your interpreter into a single directory and then execute the interpreter and try to manually load the module (take care, all this code is case sensitive).
</p>
<div class="targetlang"><pre>
a,b,c=package.loadlib("example.so","luaopen_example") -- for Unix/Linux
--a,b,c=package.loadlib("example.dll","luaopen_example") -- for Windows
print(a,b,c)
a, b, c=package.loadlib("example.so", "luaopen_example") -- for Unix/Linux
--a, b, c=package.loadlib("example.dll", "luaopen_example") -- for Windows
print(a, b, c)
</pre></div>
<p>
Note: for Lua 5.0:<br>
@ -326,7 +326,7 @@ Assuming all goes well, you will be able to this:
</p>
<div class="targetlang"><pre>
$ ./my_lua
&gt; print(example.gcd(4,6))
&gt; print(example.gcd(4, 6))
2
&gt; print(example.Foo)
3
@ -373,7 +373,7 @@ 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
&gt; for k, v in pairs(example) do _G[k]=v end
&gt; print(fact(4))
24
&gt;
@ -411,7 +411,7 @@ SWIG will effectively generate two functions <tt>example.Foo_set()</tt> and <tt>
&gt; print(c)
3
&gt; c=5 -- this will not effect the original example.Foo
&gt; print(example.Foo,c)
&gt; print(example.Foo, c)
4 5
</pre></div>
<p>
@ -486,7 +486,7 @@ Because Lua doesn't really have the concept of constants, C/C++ constants are no
<div class="code"><pre>%module example
%constant int ICONST=42;
#define SCONST "Hello World"
enum Days{SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY};
enum Days{SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY};
</pre></div>
<p>
This is 'effectively' converted into the following Lua code:
@ -521,9 +521,9 @@ Enums are exported into a class table. For example, given some enums:
<div class="code"><pre>%module example
enum Days { SUNDAY = 0, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY };
struct Test {
enum { TEST1 = 10, TEST2 = 20 };
enum { TEST1 = 10, TEST2 = 20 };
#ifdef __cplusplus // There are no static members in C
static const int ICONST = 12;
static const int ICONST = 12;
#endif
};
</pre></div>
@ -584,8 +584,8 @@ int fclose(FILE *);
When wrapped, you will be able to use the functions in a natural way from Lua. For example:
</p>
<div class="targetlang"><pre>
&gt; f=example.fopen("junk","w")
&gt; example.fputs("Hello World",f)
&gt; f=example.fopen("junk", "w")
&gt; example.fputs("Hello World", f)
&gt; example.fclose(f)
</pre></div>
<p>
@ -601,7 +601,7 @@ FILE * -- it's a FILE*
Lua enforces the integrity of its userdata, so it is virtually impossible to corrupt the data. But as the user of the pointer, you are responsible for freeing it, or closing any resources associated with it (just as you would in a C program). This does not apply so strictly to classes &amp; structs (see below). One final note: if a function returns a NULL pointer, this is not encoded as a userdata, but as a Lua nil.
</p>
<div class="targetlang"><pre>
&gt; f=example.fopen("not there","r") -- this will return a NULL in C
&gt; f=example.fopen("not there", "r") -- this will return a NULL in C
&gt; print(f)
nil
</pre></div>
@ -613,7 +613,7 @@ nil
If you wrap a C structure, it is also mapped to a Lua userdata. By adding a metatable to the userdata, this provides a very natural interface. For example,
</p>
<div class="code"><pre>struct Point{
int x,y;
int x, y;
};
</pre></div>
<p>
@ -623,7 +623,7 @@ is used as follows:
&gt; p=example.new_Point()
&gt; p.x=3
&gt; p.y=5
&gt; print(p.x,p.y)
&gt; print(p.x, p.y)
3 5
&gt;
</pre></div>
@ -645,12 +645,12 @@ Like the pointer in the previous section, this is held as a userdata. However, a
<tt>const</tt> members of a structure are read-only. Data members can also be forced to be read-only using the immutable directive. As with other immutables, setting attempts will be cause an error. For example:
</p>
<div class="code"><pre>struct Foo {
...
%immutable;
int x; // Read-only members
char *name;
%mutable;
...
...
%immutable;
int x; // Read-only members
char *name;
%mutable;
...
};
</pre></div>
<p>
@ -661,11 +661,11 @@ When a member of a structure is itself a structure, it is handled as a pointer.
</p>
<div class="code"><pre>struct Foo {
int a;
int a;
};
struct Bar {
Foo f;
Foo f;
};
</pre></div>
<p>
@ -695,8 +695,8 @@ Because the pointer points inside the structure, you can modify the contents and
For eLua with the <tt>-eluac</tt> option, structure manipulation has to be performed with specific structure functions generated by SWIG. Let's say you have the following structure definition:
</p>
<div class="code"><pre>struct data {
int x, y;
double z;
int x, y;
double z;
};
&gt; --From eLua
@ -749,8 +749,8 @@ Class data members are accessed in the same manner as C structures. Static class
</p>
<div class="targetlang"><pre>class Spam {
public:
static void foo();
static int bar;
static void foo();
static int bar;
};
</pre></div>
<p>
@ -871,9 +871,9 @@ Similarly, if you have a class like this,
</p>
<div class="code"><pre>class Foo {
public:
Foo();
Foo(const Foo &amp;);
...
Foo();
Foo(const Foo &amp;);
...
};
</pre></div>
<p>
@ -953,8 +953,8 @@ public:
When wrapped, it works like you expect:
</p>
<div class="targetlang"><pre>
&gt; c = Complex(3,4)
&gt; d = Complex(7,8)
&gt; c = Complex(3, 4)
&gt; d = Complex(7, 8)
&gt; e = c + d
&gt; e:re()
10.0
@ -984,7 +984,7 @@ There are ways to make this operator appear as part of the class using the <tt>%
Also, be aware that certain operators don't map cleanly to Lua, and some Lua operators don't map cleanly to C++ operators. For instance, overloaded assignment operators don't map to Lua semantics and will be ignored, and C++ doesn't support Lua's concatenation operator (<tt>..</tt>).
</p>
<p>
In order to keep maximum compatibility within the different languages in SWIG, the Lua bindings uses the same set of operator names as python. Although internally it renames the functions to something else (on order to work with Lua).
In order to keep maximum compatibility within the different languages in SWIG, the Lua bindings uses the same set of operator names as Python. Although internally it renames the functions to something else (on order to work with Lua).
<p>
The current list of operators which can be overloaded (and the alternative function names) are:<ul>
<li><tt>__add__</tt> operator+
@ -1000,42 +1000,40 @@ The current list of operators which can be overloaded (and the alternative funct
<li><tt>__le__</tt> operator<tt>&lt;=</tt>
</ul>
<p>
Note: in Lua, only the equals, less than, and less than equals operators are defined. The other operators (!=,&gt;,&gt;=) are achieved by using a logical not applied to the results of other operators.
Note: in Lua, only the equals, less than, and less than equals operators are defined. The other operators (!=, &gt;, &gt;=) are achieved by using a logical not applied to the results of other operators.
</p>
<p>
The following operators cannot be overloaded (mainly because they are not supported in Lua)<ul>
<li>++ and --<li>+=,-=,*= etc<li>% operator (you have to use math.mod)<li>assignment operator<li>all bitwise/logical operations</ul>
<li>++ and --<li>+=, -=, *= etc<li>% operator (you have to use math.mod)<li>assignment operator<li>all bitwise/logical operations</ul>
<p>
SWIG also accepts the <tt>__str__()</tt> member function which converts an object to a string. This function should return a const char*, preferably to static memory. This will be used for the <tt>print()</tt> and <tt>tostring()</tt> functions in Lua. Assuming the complex class has a function
</p>
<div class="code"><pre>const char* __str__()
{
static char buffer[255];
sprintf(buffer,"Complex(%g,%g)",this-&gt;re(),this-&gt;im());
return buffer;
<div class="code"><pre>const char* __str__() {
static char buffer[255];
sprintf(buffer, "Complex(%g, %g)", this-&gt;re(), this-&gt;im());
return buffer;
}
</pre></div>
<p>
Then this will support the following code in Lua
</p>
<div class="targetlang"><pre>
&gt; c = Complex(3,4)
&gt; d = Complex(7,8)
&gt; c = Complex(3, 4)
&gt; d = Complex(7, 8)
&gt; e = c + d
&gt; print(e)
Complex(10,12)
Complex(10, 12)
&gt; s=tostring(e) -- s is the number in string form
&gt; print(s)
Complex(10,12)
Complex(10, 12)
</pre></div>
<p>
It is also possible to overload the operator<tt>[]</tt>, but currently this cannot be automatically performed. To overload the operator<tt>[]</tt> you need to provide two functions, <tt>__getitem__()</tt> and <tt>__setitem__()</tt>
</p>
<div class="code"><pre>class Complex
{
//....
double __getitem__(int i)const; // i is the index, returns the data
void __setitem__(int i,double d); // i is the index, d is the data
<div class="code"><pre>class Complex {
//....
double __getitem__(int i)const; // i is the index, returns the data
void __setitem__(int i, double d); // i is the index, d is the data
};
</pre></div>
<p>
@ -1090,27 +1088,28 @@ public:
Now we extend it with some new code
</p>
<div class="code"><pre>%extend Complex {
const char *__str__() {
static char tmp[1024];
sprintf(tmp,"Complex(%g,%g)", $self-&gt;re(),$self-&gt;im());
return tmp;
}
bool operator==(const Complex&amp; c)
{ return ($self-&gt;re()==c.re() &amp;&amp; $self-&gt;im()==c.im());}
const char *__str__() {
static char tmp[1024];
sprintf(tmp, "Complex(%g, %g)", $self-&gt;re(), $self-&gt;im());
return tmp;
}
bool operator==(const Complex&amp; c) {
return ($self-&gt;re()==c.re() &amp;&amp; $self-&gt;im()==c.im());
}
};
</pre></div>
<p>
Now, in Lua
</p>
<div class="targetlang"><pre>
&gt; c = Complex(3,4)
&gt; d = Complex(7,8)
&gt; c = Complex(3, 4)
&gt; d = Complex(7, 8)
&gt; e = c + d
&gt; print(e) -- print uses __str__ to get the string form to print
Complex(10,12)
&gt; print(e==Complex(10,12)) -- testing the == operator
Complex(10, 12)
&gt; print(e==Complex(10, 12)) -- testing the == operator
true
&gt; print(e!=Complex(12,12)) -- the != uses the == operator
&gt; print(e!=Complex(12, 12)) -- the != uses the == operator
true
</pre></div>
<p>
@ -1123,9 +1122,9 @@ Extend works with both C and C++ code, on classes and structs. It does not modif
<p> If you have a function that allocates memory like this,</p>
<div class="code">
<pre>char *foo() {
char *result = (char *) malloc(...);
...
return result;
char *result = (char *) malloc(...);
...
return result;
}
</pre>
</div>
@ -1154,23 +1153,23 @@ char *foo();
template&lt;class T1, class T2&gt;
struct pair {
typedef T1 first_type;
typedef T2 second_type;
T1 first;
T2 second;
pair();
pair(const T1&amp;, const T2&amp;);
typedef T1 first_type;
typedef T2 second_type;
T1 first;
T2 second;
pair();
pair(const T1&amp;, const T2&amp;);
~pair();
};
%template(pairii) pair&lt;int,int&gt;;
%template(pairii) pair&lt;int, int&gt;;
</pre></div>
<p>
In Lua:
</p>
<div class="targetlang"><pre>
&gt; p = example.pairii(3,4)
&gt; print(p.first,p.second)
&gt; p = example.pairii(3, 4)
&gt; print(p.first, p.second)
3 4
</pre></div>
<p>
@ -1183,9 +1182,9 @@ Obviously, there is more to template wrapping than shown in this example. More d
In certain C++ programs, it is common to use classes that have been wrapped by so-called "smart pointers." Generally, this involves the use of a template class that implements operator-&gt;() like this:
</p>
<div class="code"><pre>template&lt;class T&gt; class SmartPtr {
...
T *operator-&gt;();
...
...
T *operator-&gt;();
...
}
</pre></div>
<p>
@ -1193,8 +1192,8 @@ Then, if you have a class like this,
</p>
<div class="code"><pre>class Foo {
public:
int x;
int bar();
int x;
int bar();
};
</pre></div>
<p>
@ -1264,11 +1263,11 @@ Using xpcall will allow you to obtain additional debug information (such as a st
<div class="targetlang"><pre>
&gt; function a() b() end -- function a() calls function b()
&gt; function b() message() end -- function b() calls C++ function message(), which throws
&gt; ok,res=pcall(a) -- call the function
&gt; print(ok,res)
&gt; ok, res=pcall(a) -- call the function
&gt; print(ok, res)
false I died.
&gt; ok,res=xpcall(a,debug.traceback) -- call the function
&gt; print(ok,res)
&gt; ok, res=xpcall(a, debug.traceback) -- call the function
&gt; print(ok, res)
false I died.
stack traceback:
[C]: in function 'message'
@ -1321,7 +1320,7 @@ If you have your own class which you want output as a string you will need to ad
<div class="code"><pre>
%typemap(throws) my_except
%{
lua_pushstring(L,$1.what()); // assuming my_except::what() returns a const char* message
lua_pushstring(L, $1.what()); // assuming my_except::what() returns a const char* message
SWIG_fail; // trigger the error handler
%}
</pre></div>
@ -1336,26 +1335,26 @@ class Exc {
public:
Exc(int c, const char *m) {
code = c;
strncpy(msg,m,256);
strncpy(msg, m, 256);
}
int code;
char msg[256];
};
void throw_exc() throw(Exc) {
throw(Exc(42,"Hosed"));
throw(Exc(42, "Hosed"));
}
</pre></div>
<p>
Then the following code can be used (note: we use pcall to catch the error so we can process the exception).
</p>
<div class="targetlang"><pre>
&gt; ok,res=pcall(throw_exc)
&gt; ok, res=pcall(throw_exc)
&gt; print(ok)
false
&gt; print(res)
userdata: 0003D880
&gt; print(res.code,res.msg)
&gt; print(res.code, res.msg)
42 Hosed
&gt;
</pre></div>
@ -1536,8 +1535,8 @@ function
<div class="code"><pre>%module example
%typemap(in) int {
$1 = (int) lua_tonumber(L,$input);
printf("Received an integer : %d\n",$1);
$1 = (int) lua_tonumber(L, $input);
printf("Received an integer : %d\n", $1);
}
%inline %{
extern int fact(int n);
@ -1564,17 +1563,17 @@ Received an integer : 6
<p>However for more complex functions which use input/output parameters or arrays, you will need to make use of &lt;typemaps.i&gt;, which contains typemaps for these situations. For example, consider these functions:</p>
<div class="code"><pre>void add(int x, int y, int *result) {
*result = x + y;
*result = x + y;
}
int sub(int *x1, int *y1) {
return *x1-*y1;
return *x1-*y1;
}
void swap(int *sx, int *sy) {
int t=*sx;
*sx=*sy;
*sy=t;
int t=*sx;
*sx=*sy;
*sy=t;
}
</pre></div>
@ -1595,13 +1594,13 @@ void swap(int *sx, int *sy);
<p>When wrapped, it gives the following results:</p>
<div class="targetlang"><pre>&gt; require "example"
&gt; print(example.add(1,2))
&gt; print(example.add(1, 2))
3
&gt; print(demo.sub(1,2))
&gt; print(demo.sub(1, 2))
-1
&gt; a,b=1,2
&gt; c,d=demo.swap(a,b)
&gt; print(a,b,c,d)
&gt; a, b=1, 2
&gt; c, d=demo.swap(a, b)
&gt; print(a, b, c, d)
1 2 2 1
</pre></div>
@ -1632,13 +1631,13 @@ More details can be found in the <a href="Library.html#Library_carrays">carrays.
<div class="code"><pre>// using the C-array
%include &lt;carrays.i&gt;
// this declares a batch of function for manipulating C integer arrays
%array_functions(int,int)
%array_functions(int, int)
extern void sort_int(int* arr, int len); // the function to wrap
// using typemaps
%include &lt;typemaps.i&gt;
%apply (double *INOUT,int) {(double* arr,int len)};
%apply (double *INOUT, int) {(double* arr, int len)};
extern void sort_double(double* arr, int len); // the function to wrap
</pre></div>
@ -1650,16 +1649,16 @@ ARRAY_SIZE=10
-- passing a C array to the sort_int()
arr=example.new_int(ARRAY_SIZE) -- create the array
for i=0,ARRAY_SIZE-1 do -- index 0..9 (just like C)
example.int_setitem(arr,i,math.random(1000))
for i=0, ARRAY_SIZE-1 do -- index 0..9 (just like C)
example.int_setitem(arr, i, math.random(1000))
end
example.sort_int(arr,ARRAY_SIZE) -- call the function
example.sort_int(arr, ARRAY_SIZE) -- call the function
example.delete_int(arr) -- must delete the allocated memory
-- use a typemap to call with a Lua-table
-- one item of note: the typemap creates a copy, rather than edit-in-place
t={} -- a Lua table
for i=1,ARRAY_SIZE do -- index 1..10 (Lua style)
for i=1, ARRAY_SIZE do -- index 1..10 (Lua style)
t[i]=math.random(1000)/10
end
t=example.sort_double(t) -- replace t with the result
@ -1703,7 +1702,7 @@ int Create_Math(iMath** pptr); // its creator (assume it mallocs)
<p>The usage is as follows:</p>
<div class="targetlang"><pre>ok,ptr=Create_Math() -- ptr is an iMath* which is returned with the int (ok)
<div class="targetlang"><pre>ok, ptr=Create_Math() -- ptr is an iMath* which is returned with the int (ok)
ptr=nil -- the iMath* will be GC'ed as normal
</pre></div>
@ -1734,22 +1733,22 @@ ptr=nil -- the iMath* will be GC'ed as normal
<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>
<p><tt>int SWIG_ConvertPtr(lua_State* L,int index,void** ptr,swig_type_info *type,int flags);</tt></p>
<p><tt>int SWIG_ConvertPtr(lua_State* L, int index, void** ptr, swig_type_info *type, int flags);</tt></p>
<div class="indent">
This is the standard function used for converting a Lua userdata to a void*. It takes the value at the given index in the Lua state and converts it to a userdata. It will then provide the necessary type checks, confirming that the pointer is compatible with the type given in 'type'. Then finally setting '*ptr' to the pointer.
If flags is set to SWIG_POINTER_DISOWN, this is will clear any ownership flag set on the object.<br>
The returns a value which can be checked with the macro SWIG_IsOK()
This returns a value which can be checked with the macro SWIG_IsOK()
</div>
<p><tt>void SWIG_NewPointerObj(lua_State* L,void* ptr,swig_type_info *type,int own);</tt></p>
<p><tt>void SWIG_NewPointerObj(lua_State* L, void* ptr, swig_type_info *type, int own);</tt></p>
<div class="indent">
This is the opposite of SWIG_ConvertPtr, as it pushes a new userdata which wrappers the pointer 'ptr' of type 'type'.
The parameter 'own' specifies if the object is owned be Lua and if it is 1 then Lua will GC the object when the userdata is disposed of.
</div>
<p><tt>void* SWIG_MustGetPtr(lua_State* L,int index,swig_type_info *type,int flags,int argnum,const char* func_name);</tt></p>
<p><tt>void* SWIG_MustGetPtr(lua_State* L, int index, swig_type_info *type, int flags, int argnum, const char* func_name);</tt></p>
<div class="indent">
This function is a version of SWIG_ConvertPtr(), except that it will either work, or it will trigger a lua_error() with a text error message. This function is rarely used, and may be deprecated in the future.
@ -1761,11 +1760,11 @@ This function is a version of SWIG_ConvertPtr(), except that it will either work
This macro, when called within the context of a SWIG wrapped function, will jump to the error handler code. This will call any cleanup code (freeing any temp variables) and then triggers a lua_error.<br>
A common use for this code is:<br><pre>
if (!SWIG_IsOK(SWIG_ConvertPtr( .....)){
lua_pushstring(L,"something bad happened");
lua_pushstring(L, "something bad happened");
SWIG_fail;
}</pre></div>
<p><tt>SWIG_fail_arg(char* func_name,int argnum,char* type)</tt></p>
<p><tt>SWIG_fail_arg(char* func_name, int argnum, char* type)</tt></p>
<div class="indent">
This macro, when called within the context of a SWIG wrapped function, will display the error message and jump to the error handler code. The error message is of the form
@ -1773,7 +1772,7 @@ This macro, when called within the context of a SWIG wrapped function, will disp
"Error in <i>func_name</i> (arg <i>argnum</i>), expected '<i>type</i>' got '<i>whatever the type was</i>'"
</pre></div>
<p><tt>SWIG_fail_ptr(const char* fn_name,int argnum,swig_type_info* type);</tt></p>
<p><tt>SWIG_fail_ptr(const char* fn_name, int argnum, swig_type_info* type);</tt></p>
<div class="indent">
Similar to SWIG_fail_arg, except that it will display the swig_type_info information instead.</div>
@ -1877,24 +1876,24 @@ At initialisation time, it will then add to the interpreter a table called 'exam
&gt; print(example)
table: 003F8F90
&gt; m=getmetatable(example)
&gt; table.foreach(m,print)
&gt; table.foreach(m, print)
.set table: 003F9088
.get table: 003F9038
__index function: 003F8FE0
__newindex function: 003F8FF8
&gt; g=m['.get']
&gt; table.foreach(g,print)
&gt; table.foreach(g, print)
Foo function: 003FAFD8
&gt;
</pre></div>
<p>
The .get and .set tables are lookups connecting the variable name 'Foo' to the accessor/mutator functions (Foo_set,Foo_get)
The .get and .set tables are lookups connecting the variable name 'Foo' to the accessor/mutator functions (Foo_set, Foo_get)
</p>
<p>
The Lua equivalent of the code for the <tt>__index</tt> and <tt>__newindex</tt> looks a bit like this
</p>
<div class="targetlang"><pre>
function __index(mod,name)
function __index(mod, name)
local g=getmetatable(mod)['.get'] -- gets the table
if not g then return nil end
local f=g[name] -- looks for the function
@ -1903,13 +1902,13 @@ function __index(mod,name)
return nil
end
function __newindex(mod,name,value)
function __newindex(mod, name, value)
local s=getmetatable(mod)['.set'] -- gets the table
if not s then return end
local f=s[name] -- looks for the function
-- calls it to set the value
if type(f)=="function" then f(value)
else rawset(mod,name,value) end
else rawset(mod, name, value) end
end
</pre></div>
<p>
@ -1932,10 +1931,10 @@ Given a class
class Point
{
public:
int x,y;
int x, y;
Point(){x=y=0;}
~Point(){}
virtual void Print(){printf("Point @%p (%d,%d)\n",this,x,y);}
virtual void Print(){printf("Point @%p (%d, %d)\n", this, x, y);}
};
</pre></div>
<p>
@ -1949,7 +1948,7 @@ Some of the internals can be seen by looking at the metatable of a class:
&gt; print(p)
userdata: 003FDB28
&gt; m=getmetatable(p)
&gt; table.foreach(m,print)
&gt; table.foreach(m, print)
.type Point
__gc function: 003FB6C8
__newindex function: 003FB6B0
@ -1965,7 +1964,7 @@ The '.type' attribute is the name of the class. The '.get' and '.set' tables wor
The Lua equivalent of the code for enabling functions looks a little like this
</p>
<div class="targetlang"><pre>
function __index(obj,name)
function __index(obj, name)
local m=getmetatable(obj) -- gets the metatable
if not m then return nil end
local g=m['.get'] -- gets the attribute table

14
Doc/Manual/Makefile
View file

@ -1,10 +1,12 @@
# Makefile for generating the SWIG documentation
#
# Note that the htmldoc package needs to be installed, but requires patching (using the
# margin-left.patch file from this directory) in order to correctly generate the pdf docs.
# Note that the htmldoc package needs to be installed. wkhtmltopdf patched with qt is also required
# and can be installed from http://wkhtmltopdf.org/downloads.html.
#
# The .html files are first processed and updated with chapter numbering and anchor names
# are added to the HTML headings using the python scripts. The htmldoc program is then
# used to generate the PDF document and single page HTML version of the documentation.
# used to generate the single page HTML version of the documentation.
# wkhtmltopdf is used to generate the pdf document from the single page html file.
# HTML TIDY (package also known as tidy) is also required and is used as an aid to HTML
# validation.
#
@ -87,3 +89,9 @@ linkchecker2:
cp *.png linkchecker-tmp
(cd linkchecker-tmp && linkchecker --config=../linkchecker.config -F text --no-warnings SWIGDocumentation.html)
# Simple check for relative links (there shouldn't be any), they don't translate properly creating the .pdf doc
# with wkhtmltopdf. For example, href="SWIG.html" needs to be href="SWIG.html#SWIG"
linkchecker3:
@echo "The following list should just contain SWIGDocumentation.html and SWIGDocumentation.pdf,"
@echo "as all links should have an anchor (with a #) or be a full url beginning http."
grep 'href="' *.html | sed -e 's/.*href="\(.*\)">.*$$/\1/' | grep -v "#" | grep -v "^http" | grep -v "^style.css"

46
Doc/Manual/Modula3.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="Modula3">29 SWIG and Modula-3</a></H1>
<H1><a name="Modula3">31 SWIG and Modula-3</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -55,7 +55,7 @@ especially
<a href="Typemaps.html#Typemaps">typemaps</a>.
</p>
<H2><a name="Modula3_modula3_overview">29.1 Overview</a></H2>
<H2><a name="Modula3_modula3_overview">31.1 Overview</a></H2>
<p>
@ -85,7 +85,7 @@ FFTW
</li>
</ol>
<H3><a name="Modula3_motivation">29.1.1 Motivation</a></H3>
<H3><a name="Modula3_motivation">31.1.1 Motivation</a></H3>
<p>
@ -132,10 +132,10 @@ 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">29.2 Conception</a></H2>
<H2><a name="Modula3_conception">31.2 Conception</a></H2>
<H3><a name="Modula3_cinterface">29.2.1 Interfaces to C libraries</a></H3>
<H3><a name="Modula3_cinterface">31.2.1 Interfaces to C libraries</a></H3>
<p>
@ -284,7 +284,7 @@ and the principal type must be renamed (<tt>%typemap</tt>).
</p>
<H3><a name="Modula3_cppinterface">29.2.2 Interfaces to C++ libraries</a></H3>
<H3><a name="Modula3_cppinterface">31.2.2 Interfaces to C++ libraries</a></H3>
<p>
@ -385,10 +385,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">29.3 Preliminaries</a></H2>
<H2><a name="Modula3_preliminaries">31.3 Preliminaries</a></H2>
<H3><a name="Modula3_compilers">29.3.1 Compilers</a></H3>
<H3><a name="Modula3_compilers">31.3.1 Compilers</a></H3>
<p>
@ -401,7 +401,7 @@ For testing examples I use Critical Mass cm3.
</p>
<H3><a name="Modula3_commandline">29.3.2 Additional Commandline Options</a></H3>
<H3><a name="Modula3_commandline">31.3.2 Additional Commandline Options</a></H3>
<p>
@ -478,10 +478,10 @@ Instead generate templates for some basic typemaps.
</tr>
</table>
<H2><a name="Modula3_typemaps">29.4 Modula-3 typemaps</a></H2>
<H2><a name="Modula3_typemaps">31.4 Modula-3 typemaps</a></H2>
<H3><a name="Modula3_inoutparam">29.4.1 Inputs and outputs</a></H3>
<H3><a name="Modula3_inoutparam">31.4.1 Inputs and outputs</a></H3>
<p>
@ -684,7 +684,7 @@ consist of the following parts:
</tr>
<tr>
<td>m3wrapfreearg</td>
<td><tt>M3toC.FreeSharedS(str,arg1);</tt></td>
<td><tt>M3toC.FreeSharedS(str, arg1);</tt></td>
<td>
Free resources that were temporarily used in the wrapper.
Since this step should never be skipped,
@ -695,7 +695,7 @@ consist of the following parts:
</table>
<H3><a name="Modula3_ordinals">29.4.2 Subranges, Enumerations, Sets</a></H3>
<H3><a name="Modula3_ordinals">31.4.2 Subranges, Enumerations, Sets</a></H3>
<p>
@ -747,7 +747,7 @@ that I'd like to automate.
</p>
<H3><a name="Modula3_class">29.4.3 Objects</a></H3>
<H3><a name="Modula3_class">31.4.3 Objects</a></H3>
<p>
@ -760,7 +760,7 @@ is not really useful, yet.
</p>
<H3><a name="Modula3_imports">29.4.4 Imports</a></H3>
<H3><a name="Modula3_imports">31.4.4 Imports</a></H3>
<p>
@ -793,7 +793,7 @@ IMPORT M3toC;
</pre></div>
<H3><a name="Modula3_exceptions">29.4.5 Exceptions</a></H3>
<H3><a name="Modula3_exceptions">31.4.5 Exceptions</a></H3>
<p>
@ -817,7 +817,7 @@ you should declare
<tt>%typemap("m3wrapinconv:throws") blah * %{OSError.E%}</tt>.
</p>
<H3><a name="Modula3_typemap_example">29.4.6 Example</a></H3>
<H3><a name="Modula3_typemap_example">31.4.6 Example</a></H3>
<p>
@ -858,16 +858,16 @@ where almost everything is generated by a typemap:
RAISE E("invalid checksum");
END;
FINALLY
M3toC.FreeSharedS(str,arg1); <I>(* m3wrapfreearg *)</I>
M3toC.FreeSharedS(str, arg1); <I>(* m3wrapfreearg *)</I>
END;
END Name;
</pre></div>
<H2><a name="Modula3_hints">29.5 More hints to the generator</a></H2>
<H2><a name="Modula3_hints">31.5 More hints to the generator</a></H2>
<H3><a name="Modula3_features">29.5.1 Features</a></H3>
<H3><a name="Modula3_features">31.5.1 Features</a></H3>
<table border summary="Modula-3 features">
@ -891,7 +891,7 @@ where almost everything is generated by a typemap:
<tr>
<td>constnumeric</td>
<td><tt>%constnumeric(12) twelve;</tt> or
<tt>%feature("constnumeric","12") twelve;</tt></td>
<tt>%feature("constnumeric", "12") twelve;</tt></td>
<td>This feature can be used to tell Modula-3's back-end of SWIG
the value of an identifier.
This is necessary in the cases
@ -904,7 +904,7 @@ where almost everything is generated by a typemap:
</tr>
</table>
<H3><a name="Modula3_pragmas">29.5.2 Pragmas</a></H3>
<H3><a name="Modula3_pragmas">31.5.2 Pragmas</a></H3>
<table border summary="Modula-3 pragmas">
@ -927,7 +927,7 @@ where almost everything is generated by a typemap:
</tr>
</table>
<H2><a name="Modula3_remarks">29.6 Remarks</a></H2>
<H2><a name="Modula3_remarks">31.6 Remarks</a></H2>
<ul>

18
Doc/Manual/Modules.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Modules">16 Working with Modules</a></H1>
<H1><a name="Modules">19 Working with Modules</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -24,7 +24,7 @@
<H2><a name="Modules_introduction">16.1 Modules Introduction</a></H2>
<H2><a name="Modules_introduction">19.1 Modules Introduction</a></H2>
<p>
@ -44,7 +44,7 @@ The general form of this directive is:
</p>
<div class="code"><pre>
<tt>%module(option1="value1",option2="value2",...) modulename</tt>
<tt>%module(option1="value1", option2="value2", ...) modulename</tt>
</pre></div>
<p>
@ -78,7 +78,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">16.2 Basics</a></H2>
<H2><a name="Modules_nn1">19.2 Basics</a></H2>
<p>
@ -177,7 +177,7 @@ in parallel from multiple threads as SWIG provides no locking - for more on that
issue, read on.
</p>
<H2><a name="Modules_nn2">16.3 The SWIG runtime code</a></H2>
<H2><a name="Modules_nn2">19.3 The SWIG runtime code</a></H2>
<p>
@ -243,7 +243,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">16.4 External access to the runtime</a></H2>
<H2><a name="Modules_external_run_time">19.4 External access to the runtime</a></H2>
<p>As described in <a href="Typemaps.html#Typemaps_runtime_type_checker">The run-time type checker</a>,
@ -282,7 +282,7 @@ SWIG_TYPE_TABLE to be the same as the module whose types you are trying to
access.
</p>
<H2><a name="Modules_nn4">16.5 A word of caution about static libraries</a></H2>
<H2><a name="Modules_nn4">19.5 A word of caution about static libraries</a></H2>
<p>
@ -293,7 +293,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">16.6 References</a></H2>
<H2><a name="Modules_nn5">19.6 References</a></H2>
<p>
@ -301,7 +301,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">16.7 Reducing the wrapper file size</a></H2>
<H2><a name="Modules_nn6">19.7 Reducing the wrapper file size</a></H2>
<p>

20
Doc/Manual/Mzscheme.html
View file

@ -8,7 +8,7 @@
<body bgcolor="#ffffff">
<H1><a name="Mzscheme">30 SWIG and MzScheme/Racket</a></H1>
<H1><a name="Mzscheme">37 SWIG and MzScheme/Racket</a></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">30.1 Creating native structures</a></H2>
<H2><a name="MzScheme_nn2">37.1 Creating native structures</a></H2>
<p>
@ -34,14 +34,14 @@ Example interface file:
<div class="code">
<pre>
/* define a macro for the struct creation */
%define handle_ptr(TYPE,NAME)
%define handle_ptr(TYPE, NAME)
%typemap(argout) TYPE *NAME{
Scheme_Object *o = SWIG_NewStructFromPtr($1, $*1_mangle);
SWIG_APPEND_VALUE(o);
Scheme_Object *o = SWIG_NewStructFromPtr($1, $*1_mangle);
SWIG_APPEND_VALUE(o);
}
%typemap(in,numinputs=0) TYPE *NAME (TYPE temp) {
$1 = &amp;temp;
%typemap(in, numinputs=0) TYPE *NAME (TYPE temp) {
$1 = &amp;temp;
}
%enddef
@ -65,7 +65,7 @@ Then in scheme, you can use regular struct access procedures like
</pre>
</div>
<H2><a name="MzScheme_simple">30.2 Simple example</a></H2>
<H2><a name="MzScheme_simple">37.2 Simple example</a></H2>
<p>
@ -166,11 +166,11 @@ 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">30.3 External documentation</a></H2>
<H2><a name="MzScheme_external_docs">37.3 External documentation</a></H2>
<p>
See the <a href="http://docs.racket-lang.org/inside/index.html">C API</a> for more description of using the mechanism for adding extensions. The main documentation is <a href="http://docs.racket-lang.org/">here</a>.
See the <a href="https://docs.racket-lang.org/inside/index.html">C API</a> for more description of using the mechanism for adding extensions. The main documentation is <a href="https://docs.racket-lang.org/">here</a>.
</p>
<p>

228
Doc/Manual/Ocaml.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Ocaml">31 SWIG and Ocaml</a></H1>
<H1><a name="Ocaml">38 SWIG and OCaml</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -47,12 +47,16 @@
<li><a href="#Ocaml_nn25">Director Usage Example</a>
<li><a href="#Ocaml_nn26">Creating director objects</a>
<li><a href="#Ocaml_nn27">Typemaps for directors, directorin, directorout, directorargout</a>
<li><a href="#Ocaml_nn28">typemap</a>
<li><a href="#Ocaml_nn28">directorin typemap</a>
<li><a href="#Ocaml_nn29">directorout typemap</a>
<li><a href="#Ocaml_nn30">directorargout typemap</a>
</ul>
<li><a href="#Ocaml_nn31">Exceptions</a>
</ul>
<li><a href="#Ocaml_nn32">Documentation Features</a>
<ul>
<li><a href="#Ocaml_nn33">Module docstring</a>
</ul>
</ul>
</div>
<!-- INDEX -->
@ -84,13 +88,13 @@ If you're not familiar with the Objective Caml language, you can visit
<a href="http://ocaml.org/">The Ocaml Website</a>.
</p>
<H2><a name="Ocaml_nn2">31.1 Preliminaries</a></H2>
<H2><a name="Ocaml_nn2">38.1 Preliminaries</a></H2>
<p>
SWIG 3.0 works with Ocaml 3.08.3 and above. Given the choice,
SWIG is compatible with OCaml 3.12.0 and above. Given the choice,
you should use the latest stable release. The SWIG Ocaml module has
been tested on Linux (x86,PPC,Sparc) and Cygwin on Windows. The
been tested on Linux (x86, PPC, Sparc) and Cygwin on Windows. The
best way to determine whether your system will work is to compile the
examples and test-suite which come with SWIG. You can do this by running
<tt>make check</tt> from the SWIG root directory after installing SWIG.
@ -102,7 +106,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">31.1.1 Running SWIG</a></H3>
<H3><a name="Ocaml_nn3">38.1.1 Running SWIG</a></H3>
<p>
@ -125,7 +129,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">31.1.2 Compiling the code</a></H3>
<H3><a name="Ocaml_nn4">38.1.2 Compiling the code</a></H3>
<p>
@ -142,7 +146,7 @@ Use <tt>ocamlc</tt> or <tt>ocamlopt</tt> to compile your SWIG interface like:
<div class="code">
<pre>
% swig -ocaml -co swig.mli ; swig -ocaml co swig.ml
% swig -ocaml -co swig.mli ; swig -ocaml -co swig.ml
% ocamlc -c swig.mli ; ocamlc -c swig.ml
% ocamlc -c -ccopt "-I/usr/include/foo" example_wrap.c
% ocamlc -c example.mli
@ -162,7 +166,7 @@ in C++ mode, you must:</p>
</pre>
</div>
<H3><a name="Ocaml_nn5">31.1.3 The camlp4 module</a></H3>
<H3><a name="Ocaml_nn5">38.1.3 The camlp4 module</a></H3>
<p>
@ -238,7 +242,7 @@ let b = C_string (getenv "PATH")
</td></tr>
</table>
<H3><a name="Ocaml_nn6">31.1.4 Using your module</a></H3>
<H3><a name="Ocaml_nn6">38.1.4 Using your module</a></H3>
<p>
@ -252,7 +256,7 @@ option to build your functions into the primitive list. This
option is not needed when you build native code.
</p>
<H3><a name="Ocaml_nn7">31.1.5 Compilation problems and compiling with C++</a></H3>
<H3><a name="Ocaml_nn7">38.1.5 Compilation problems and compiling with C++</a></H3>
<p>
@ -263,7 +267,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">31.2 The low-level Ocaml/C interface</a></H2>
<H2><a name="Ocaml_nn8">38.2 The low-level Ocaml/C interface</a></H2>
<p>
@ -327,7 +331,7 @@ A few functions exist which generate and return these:
Because of this style, a typemap can return any kind of value it
wants from a function. This enables out typemaps and inout typemaps
to work well. The one thing to remember about outputting values
is that you must append them to the return list with swig_result = caml_list_append(swig_result,v).
is that you must append them to the return list with swig_result = caml_list_append(swig_result, v).
</p>
<p>
@ -336,7 +340,7 @@ appended. Upon return to caml space, the fnhelper function
beautifies the result. A list containing a single item degrades to
only that item (i.e. [ C_int 3 ] -&gt; C_int 3), and a list
containing more than one item is wrapped in C_list (i.e. [ C_char
'a' ; C_char 'b' -&gt; C_list [ C_char 'a' ; C_char b
'a' ; C_char 'b' ] -&gt; C_list [ C_char 'a' ; C_char 'b'
]). This is in order to make return values easier to handle
when functions have only one return value, such as constructors,
and operators. In addition, string, pointer, and object
@ -363,7 +367,7 @@ value items pass through directly, but you must make your own type
signature for a function that uses value in this way.
</p>
<H3><a name="Ocaml_nn9">31.2.1 The generated module</a></H3>
<H3><a name="Ocaml_nn9">38.2.1 The generated module</a></H3>
<p>
@ -397,7 +401,7 @@ it describes the output SWIG will generate for class definitions.
</td></tr>
</table>
<H3><a name="Ocaml_nn10">31.2.2 Enums</a></H3>
<H3><a name="Ocaml_nn10">38.2.2 Enums</a></H3>
<p>
@ -460,7 +464,7 @@ val x : Enum_test.c_obj = C_enum `a
</pre>
</div>
<H4><a name="Ocaml_nn11">31.2.2.1 Enum typing in Ocaml</a></H4>
<H4><a name="Ocaml_nn11">38.2.2.1 Enum typing in Ocaml</a></H4>
<p>
@ -473,10 +477,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">31.2.3 Arrays</a></H3>
<H3><a name="Ocaml_nn12">38.2.3 Arrays</a></H3>
<H4><a name="Ocaml_nn13">31.2.3.1 Simple types of bounded arrays</a></H4>
<H4><a name="Ocaml_nn13">38.2.3.1 Simple types of bounded arrays</a></H4>
<p>
@ -497,7 +501,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">31.2.3.2 Complex and unbounded arrays</a></H4>
<H4><a name="Ocaml_nn14">38.2.3.2 Complex and unbounded arrays</a></H4>
<p>
@ -505,12 +509,12 @@ Unfortunately, unbounded arrays and pointers can't be handled in a
completely general way by SWIG, because the end-condition of such an
array can't be predicted. In some cases, it will be by consent
(e.g. an array of four or more chars), sometimes by explicit length
(char *buffer, int len), and sometimes by sentinel value (0,-1,etc.).
(char *buffer, int len), and sometimes by sentinel value (0, -1, etc.).
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">31.2.3.3 Using an object</a></H4>
<H4><a name="Ocaml_nn15">38.2.3.3 Using an object</a></H4>
<p>
@ -524,7 +528,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">31.2.3.4 Example typemap for a function taking float * and int</a></H4>
<H4><a name="Ocaml_nn16">38.2.3.4 Example typemap for a function taking float * and int</a></H4>
<p>
@ -560,7 +564,7 @@ void printfloats( float *tab, int len ) {
$2 = caml_array_len($input);
$1 = ($*1_type *)malloc( $2 * sizeof( float ) );
for( i = 0; i &lt; $2; i++ ) {
$1[i] = caml_double_val(caml_array_nth($input,i));
$1[i] = caml_double_val(caml_array_nth($input, i));
}
}
@ -575,7 +579,7 @@ void printfloats( float *tab, int len );
</pre></td></tr></table>
<H3><a name="Ocaml_nn17">31.2.4 C++ Classes</a></H3>
<H3><a name="Ocaml_nn17">38.2.4 C++ Classes</a></H3>
<p>
@ -618,7 +622,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the
returned value for the same object.
</p>
<H4><a name="Ocaml_nn18">31.2.4.1 STL vector and string Example</a></H4>
<H4><a name="Ocaml_nn18">38.2.4.1 STL vector and string Example</a></H4>
<p>
@ -660,7 +664,7 @@ module.
</p>
<div class="code"><pre>
bash-2.05a$ ./example_top
bash-2.05a$ ./runme_top
Objective Caml version 3.06
Camlp4 Parsing version 3.06
@ -684,7 +688,7 @@ C_list
- : Example.c_obj = C_void
# x '[1] ;;
- : Example.c_obj = C_string "bar"
# x -&gt; set (1,"spam") ;;
# x -&gt; set (1, "spam") ;;
- : Example.c_obj = C_void
# x '[1] ;;
- : Example.c_obj = C_string "spam"
@ -698,7 +702,7 @@ baz
#
</pre></div>
<H4><a name="Ocaml_nn19">31.2.4.2 C++ Class Example</a></H4>
<H4><a name="Ocaml_nn19">38.2.4.2 C++ Class Example</a></H4>
<p>
@ -728,7 +732,7 @@ public:
};
</pre></td></tr></table>
<H4><a name="Ocaml_nn20">31.2.4.3 Compiling the example</a></H4>
<H4><a name="Ocaml_nn20">38.2.4.3 Compiling the example</a></H4>
<div class="code"><pre>
@ -746,7 +750,7 @@ bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
-L$QTPATH/lib -cclib -lqt
</pre></div>
<H4><a name="Ocaml_nn21">31.2.4.4 Sample Session</a></H4>
<H4><a name="Ocaml_nn21">38.2.4.4 Sample Session</a></H4>
<div class="code"><pre>
@ -757,11 +761,11 @@ bash-2.05a$ ./qt_top
# open Swig ;;
# open Qt ;;
# let a = new_QApplication '(0,0) ;;
# let a = new_QApplication '(0, 0) ;;
val a : Qt.c_obj = C_obj &lt;fun&gt;
# let hello = new_QPushButton '("hi",0) ;;
# let hello = new_QPushButton '("hi", 0) ;;
val hello : Qt.c_obj = C_obj &lt;fun&gt;
# hello -&gt; resize (100,30) ;;
# hello -&gt; resize (100, 30) ;;
- : Qt.c_obj = C_void
# hello -&gt; show () ;;
- : Qt.c_obj = C_void
@ -773,10 +777,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">31.2.5 Director Classes</a></H3>
<H3><a name="Ocaml_nn22">38.2.5 Director Classes</a></H3>
<H4><a name="Ocaml_nn23">31.2.5.1 Director Introduction</a></H4>
<H4><a name="Ocaml_nn23">38.2.5.1 Director Introduction</a></H4>
<p>
@ -803,7 +807,7 @@ class foo {
};
</pre></div>
<H4><a name="Ocaml_nn24">31.2.5.2 Overriding Methods in Ocaml</a></H4>
<H4><a name="Ocaml_nn24">38.2.5.2 Overriding Methods in Ocaml</a></H4>
<p>
@ -831,11 +835,11 @@ 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">31.2.5.3 Director Usage Example</a></H4>
<H4><a name="Ocaml_nn25">38.2.5.3 Director Usage Example</a></H4>
<table border="1" bgcolor="#dddddd" summary="Director usage example">
<tr><th><center>example_prog.ml</center>
<tr><th><center>runme.ml</center>
</th></tr>
<tr><td><pre>
open Swig
@ -854,13 +858,15 @@ let triangle_class pts ob meth args =
| _ -&gt; raise (Failure "cover needs two double arguments."))
| _ -&gt; (invoke ob) meth args ;;
...
let triangle =
new_derived_object
new_shape
(triangle_class ((0.0,0.0),(0.5,1.0),(1.0,0.0)))
(triangle_class ((0.0, 0.0), (0.5, 1.0), (1.0, 0.6)))
'() ;;
let _ = _draw_shape_coverage '(triangle, C_int 60, C_int 20) ;;
let _ = _draw_shape_coverage '(triangle, 60, 20) ;;
</pre></td></tr>
</table>
@ -890,7 +896,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the
program in C++.
</p>
<H4><a name="Ocaml_nn26">31.2.5.4 Creating director objects</a></H4>
<H4><a name="Ocaml_nn26">38.2.5.4 Creating director objects</a></H4>
<p>
@ -901,7 +907,7 @@ The definition of the actual object triangle can be described this way:
let triangle =
new_derived_object
new_shape
(triangle_class ((0.0,0.0),(0.5,1.0),(1.0,0.0)))
(triangle_class ((0.0, 0.0), (0.5, 1.0), (1.0, 0.0)))
'()
</pre></div>
@ -931,7 +937,7 @@ object from causing a core dump, as long as the object is destroyed
properly.
</p>
<H4><a name="Ocaml_nn27">31.2.5.5 Typemaps for directors, directorin, directorout, directorargout</a></H4>
<H4><a name="Ocaml_nn27">38.2.5.5 Typemaps for directors, directorin, directorout, directorargout</a></H4>
<p>
@ -942,7 +948,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">31.2.5.6 typemap</a></H4>
<H4><a name="Ocaml_nn28">38.2.5.6 directorin typemap</a></H4>
<p>
@ -953,7 +959,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">31.2.5.7 directorout typemap</a></H4>
<H4><a name="Ocaml_nn29">38.2.5.7 directorout typemap</a></H4>
<p>
@ -964,7 +970,7 @@ for the same type, except when there are special requirements for object
ownership, etc.
</p>
<H4><a name="Ocaml_nn30">31.2.5.8 directorargout typemap</a></H4>
<H4><a name="Ocaml_nn30">38.2.5.8 directorargout typemap</a></H4>
<p>
@ -981,14 +987,134 @@ 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">31.2.6 Exceptions</a></H3>
<H3><a name="Ocaml_nn31">38.2.6 Exceptions</a></H3>
<p>
Catching exceptions is now supported using SWIG's %exception feature. A simple
but not too useful example is provided by the throw_exception testcase in
Examples/test-suite. You can provide your own exceptions, too.
If an error occurs in a C or C++ function, you may want to convert that error into an OCaml
exception. To do this, you can use the <tt>%exception</tt> directive. The <tt>%exception</tt>
directive simply lets you rewrite part of the generated wrapper code to include an error check.
It is detailed in full in the <a href="Customization.html#Customization_exception">Exception handling with %exception</a> section.
</p>
<p>
In C, a function often indicates an error by returning a status code (e.g. a negative number
or a NULL pointer). Here is a simple example of how you might handle that:
</p>
<div class="code">
<pre>
%exception malloc {
$action
if (result == NULL) {
caml_failwith("Not enough memory");
}
}
void *malloc(size_t nbytes);
</pre>
</div>
<p>
In OCaml:
</p>
<div class="code">
<pre>
# let a = _malloc (C_int 20000000000);;
Exception: Failure "Not enough memory".
#
</pre>
</div>
<p>
If a library provides some kind of general error handling framework, you can also use
that. For example:
</p>
<div class="code">
<pre>
%exception {
$action
if (err_occurred()) {
caml_failwith(err_message());
}
}
</pre>
</div>
<p>
If no declaration name is given to <tt>%exception</tt>, it is applied to all wrapper functions.
<tt>$action</tt> is a SWIG special variable and is replaced by the C/C++ function call being wrapped.
</p>
<p>
C++ exceptions are also easy to handle. We can catch a C++ exception and rethrow it as
an OCaml exception like this:
</p>
<div class="code">
<pre>
%exception getitem {
try {
$action
} catch (std::out_of_range &amp;e) {
caml_failwith(e.what());
}
}
class FooClass {
public:
int getitem(int index); // Exception handling added
...
};
</pre>
</div>
<p>
The language-independent <tt>exception.i</tt> library file can also be used
to raise exceptions. See the <a href="Library.html#Library">SWIG Library</a> chapter.
</p>
<H2><a name="Ocaml_nn32">38.3 Documentation Features</a></H2>
<p>
The features described in this section can be used to generate documentation
comments (colloquially referred to as "docstrings") that can be read by
<a href="https://caml.inria.fr/pub/docs/manual-ocaml/ocamldoc.html">OCamldoc</a>.
</p>
<H3><a name="Ocaml_nn33">38.3.1 Module docstring</a></H3>
<p>
The first documentation comment of an <tt>mli</tt> file is the comment
associated with the entire module. SWIG supports this by setting an
option of the <tt>%module</tt> directive. For example:
</p>
<div class="code">
<pre>
%module(docstring="This is the example module's docstring") example
</pre>
</div>
<p>
When you have more than just a line or so, you can retain the
readability of the <tt>%module</tt> directive by using a macro. For
example:
</p>
<div class="code">
<pre>
%define DOCSTRING
"The `XmlResource` class allows program resources defining menus,
controls on a panel, etc. to be loaded from an XML file."
%enddef
%module(docstring=DOCSTRING) xrc
</pre>
</div>
</body>
</html>

147
Doc/Manual/Octave.html
View file

@ -9,7 +9,7 @@
<body bgcolor="#ffffff">
<H1><a name="Octave">32 SWIG and Octave</a></H1>
<H1><a name="Octave">29 SWIG and Octave</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -56,20 +56,27 @@ More information can be found at <a href="http://www.gnu.org/software/octave/">O
</p>
<p>
This chapter is intended to give an introduction to using the module. You should also read the SWIG documentation that is not specific to Octave.
This chapter is intended to give an introduction to using the module. You should also read the SWIG documentation that is not specific to Octave.
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">32.1 Preliminaries</a></H2>
<H2><a name="Octave_nn2">29.1 Preliminaries</a></H2>
<p>
As of SWIG 3.0.7, the Octave module is regularly tested with Octave versions 3.2.4, 3.8.1, and 4.0.0.
Use of older Octave versions is not recommended, as these versions are no longer tested with SWIG.
SWIG is regularly tested against the following versions of Octave: 3.8, 4.0, 4.2.
</p>
<p>
Every effort is made to maintain backward compatibility with older versions of Octave.
This cannot be guaranteed however, as in recent times new Octave releases have required nontrivial updates to SWIG, which may break backward compatibility for older Octave versions against which SWIG is not regularly tested.
</p>
<p>
The SWIG runtime exports the function <tt>swig_octave_prereq()</tt> for checking the version of Octave.
</p>
<H2><a name="Octave_nn3">32.2 Running SWIG</a></H2>
<H2><a name="Octave_nn3">29.2 Running SWIG</a></H2>
<p>
@ -101,7 +108,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">32.2.1 Command-line options</a></H3>
<H3><a name="Octave_nn4">29.2.1 Command-line options</a></H3>
<p>
@ -124,7 +131,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">32.2.2 Compiling a dynamic module</a></H3>
<H3><a name="Octave_nn5">29.2.2 Compiling a dynamic module</a></H3>
<p>
@ -151,7 +158,7 @@ $ mkoctfile example_wrap.cpp example.c
<div class="targetlang"><pre>octave:1&gt; swigexample</pre></div>
<H3><a name="Octave_nn6">32.2.3 Using your module</a></H3>
<H3><a name="Octave_nn6">29.2.3 Using your module</a></H3>
<p>
@ -161,7 +168,7 @@ Assuming all goes well, you will be able to do this:
<div class="targetlang"><pre>$ octave -q
octave:1&gt; swigexample
octave:2&gt; swigexample.gcd(4,6)
octave:2&gt; swigexample.gcd(4, 6)
ans = 2
octave:3&gt; swigexample.cvar.Foo
ans = 3
@ -169,10 +176,10 @@ octave:4&gt; swigexample.cvar.Foo=4;
octave:5&gt; swigexample.cvar.Foo
ans = 4 </pre></div>
<H2><a name="Octave_nn7">32.3 A tour of basic C/C++ wrapping</a></H2>
<H2><a name="Octave_nn7">29.3 A tour of basic C/C++ wrapping</a></H2>
<H3><a name="Octave_nn8">32.3.1 Modules</a></H3>
<H3><a name="Octave_nn8">29.3.1 Modules</a></H3>
<p>
@ -189,7 +196,7 @@ To load an Octave module, simply type its name:
<div class="targetlang"><pre>
octave:1&gt; swigexample;
octave:2&gt; gcd(4,6)
octave:2&gt; gcd(4, 6)
ans = 2
octave:3&gt; cvar.Foo
ans = 3
@ -204,20 +211,20 @@ If the module is also used in the base context, however, it must first be loaded
</p>
<div class="targetlang"><pre>
octave:1&gt; function l = my_lcm(a,b)
octave:1&gt; function l = my_lcm(a, b)
&gt; swigexample
&gt; l = abs(a*b)/swigexample.gcd(a,b);
&gt; l = abs(a*b)/swigexample.gcd(a, b);
&gt; endfunction
octave:2&gt; my_lcm(4,6)
octave:2&gt; my_lcm(4, 6)
ans = 12
octave:3&gt; swigexample.gcd(4,6)
octave:3&gt; swigexample.gcd(4, 6)
error: can't perform indexing operations for &lt;unknown type&gt; type
octave:3&gt; swigexample;
octave:4&gt; swigexample.gcd(4,6)
octave:4&gt; swigexample.gcd(4, 6)
ans = 2
</pre></div>
<H3><a name="Octave_nn9">32.3.2 Functions</a></H3>
<H3><a name="Octave_nn9">29.3.2 Functions</a></H3>
<p>
@ -234,7 +241,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">32.3.3 Global variables</a></H3>
<H3><a name="Octave_nn10">29.3.3 Global variables</a></H3>
<p>
@ -287,7 +294,7 @@ octave:2&gt; swigexample.PI=3.142;
octave:3&gt; swigexample.PI
ans = 3.1420 </pre></div>
<H3><a name="Octave_nn11">32.3.4 Constants and enums</a></H3>
<H3><a name="Octave_nn11">29.3.4 Constants and enums</a></H3>
<p>
@ -297,7 +304,7 @@ ans = 3.1420 </pre></div>
<div class="code"><pre>%module swigexample
%constant int ICONST=42;
#define SCONST "Hello World"
enum Days{SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY};
enum Days{SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY};
</pre></div>
<p>
@ -309,12 +316,12 @@ swigexample.SCONST="Hello World"
swigexample.SUNDAY=0
.... </pre></div>
<H3><a name="Octave_nn12">32.3.5 Pointers</a></H3>
<H3><a name="Octave_nn12">29.3.5 Pointers</a></H3>
<p>
C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the &lt;file.h&gt; interface:
C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the &lt;file.h&gt; interface:
C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the &lt;file.h&gt; interface:
</p>
<div class="code"><pre>%module swigexample
@ -329,8 +336,8 @@ When wrapped, you will be able to use the functions in a natural way from Octave
<div class="targetlang"><pre>
octave:1&gt; swigexample;
octave:2&gt; f=swigexample.fopen("w","junk");
octave:3&gt; swigexample.fputs("Hello world",f);
octave:2&gt; f=swigexample.fopen("w", "junk");
octave:3&gt; swigexample.fputs("Hello world", f);
octave:4&gt; swigexample.fclose(f);
</pre></div>
@ -339,7 +346,7 @@ octave:4&gt; swigexample.fclose(f);
</p>
<div class="targetlang"><pre>octave:1&gt; swigexample;
octave:2&gt; f=swigexample.fopen("junk","w");
octave:2&gt; f=swigexample.fopen("junk", "w");
octave:3&gt; f
f =
@ -352,11 +359,11 @@ f =
</p>
<div class="targetlang"><pre>octave:1&gt; swigexample;
octave:2&gt; f=swigexample.fopen("not there","r");
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">32.3.6 Structures and C++ classes</a></H3>
<H3><a name="Octave_nn13">29.3.6 Structures and C++ classes</a></H3>
<p>
@ -365,7 +372,7 @@ For each wrapped structure and class, a <tt>swig_ref</tt> will be exposed that h
</p>
<div class="code"><pre>struct Point{
int x,y;
int x, y;
};
</pre></div>
@ -395,12 +402,12 @@ Methods also work as expected. For example, code wrapped in the following way
<div class="code"><pre>class Point{
public:
int x,y;
Point(int _x,int _y) : x(_x),y(_y) {}
int x, y;
Point(int _x, int _y) : x(_x), y(_y) {}
double distance(const Point&amp; rhs) {
return sqrt(pow(x-rhs.x,2)+pow(y-rhs.y,2));
return sqrt(pow(x-rhs.x, 2)+pow(y-rhs.y, 2));
}
void set(int _x,int _y) {
void set(int _x, int _y) {
x=_x; y=_y;
}
};
@ -410,8 +417,8 @@ can be used from Octave like this
</p>
<div class="targetlang">
<pre>octave:1&gt; swigexample;
octave:2&gt; p1=swigexample.Point(3,5);
octave:3&gt; p2=swigexample.Point(1,2);
octave:2&gt; p1=swigexample.Point(3, 5);
octave:3&gt; p2=swigexample.Point(1, 2);
octave:4&gt; p1.distance(p2)
ans = 3.6056
</pre></div>
@ -433,7 +440,7 @@ This differs from the usual pass-by-value (copy-on-write) semantics that Octave
<div class="targetlang">
<pre>
octave:7> a=struct('x',4)
octave:7> a=struct('x', 4)
a =
{
x = 4
@ -464,7 +471,7 @@ However, when dealing with wrapped objects, one gets the behavior
<div class="targetlang">
<pre>
octave:2> a=Point(3,5)
octave:2> a=Point(3, 5)
a =
{
@ -478,7 +485,7 @@ b =
Point, ptr = 0x9afbbb0
}
octave:4> b.set(2,1);
octave:4> b.set(2, 1);
octave:5> b.x, b.y
ans = 2
ans = 1
@ -491,7 +498,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">32.3.7 C++ inheritance</a></H3>
<H3><a name="Octave_nn15">29.3.7 C++ inheritance</a></H3>
<p>
@ -500,7 +507,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">32.3.8 C++ overloaded functions</a></H3>
<H3><a name="Octave_nn17">29.3.8 C++ overloaded functions</a></H3>
<p>
@ -510,7 +517,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">32.3.9 C++ operators</a></H3>
<H3><a name="Octave_nn18">29.3.9 C++ operators</a></H3>
<p>
@ -614,14 +621,14 @@ 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">32.3.10 Class extension with %extend</a></H3>
<H3><a name="Octave_nn19">29.3.10 Class extension with %extend</a></H3>
<p>
The %extend directive works the same as in other modules.
</p>
<p>
You can use it to define special behavior, like for example defining Octave operators not mapped to C++ operators, or defining certain Octave mechanisms such as how an object prints. For example, the <tt>octave_value::{is_string,string_value,print}</tt> functions are routed to a special method <tt>__str__</tt> that can be defined inside an %extend.
You can use it to define special behavior, like for example defining Octave operators not mapped to C++ operators, or defining certain Octave mechanisms such as how an object prints. For example, the <tt>octave_value::{is_string, string_value, print}</tt> functions are routed to a special method <tt>__str__</tt> that can be defined inside an %extend.
</p>
<div class="code"><pre>
%extend A {
@ -639,7 +646,7 @@ Then in Octave one gets,
octave:1&gt; a=A(4);
octave:2&gt; a
a = 4
octave:3&gt; printf("%s\n",a);
octave:3&gt; printf("%s\n", a);
4
octave:4&gt; a.__str__()
4
@ -653,7 +660,7 @@ Similarly, Octave can use the <tt>__float__</tt> method to convert an object to
Octave 3.8.0 and later versions will also map unary functions X() to the corresponding <tt>__X__</tt> method, where X includes: abs(), acos(), acosh(), angle(), arg(), asin(), asinh(), atan(), atanh(), cbrt(), ceil(), conj(), cos(), cosh(), dawson(), erf(), erfc(), erfcinv(), erfcx(), erfi(), erfinv(), exp(), expm1(), finite(), fix(), floor(), gamma(), imag(), isalnum(), isalpha(), isascii(), iscntrl(), isdigit(), isgraph(), isinf(), islower(), isna(), isnan(), isprint(), ispunct(), isspace(), isupper(), isxdigit(), lgamma(), log(), log10(), log1p(), log2(), real(), round(), roundb(), signbit(), signum(), sin(), sinh(), sqrt(), tan(), tanh(), toascii(), tolower(), toupper()
</p>
<H3><a name="Octave_nn20">32.3.11 C++ templates</a></H3>
<H3><a name="Octave_nn20">29.3.11 C++ templates</a></H3>
<p>
@ -663,10 +670,10 @@ For example, function templates can be instantiated as follows:
<div class="code"><pre>%module swigexample
%inline {
template&lt;class __scalar&gt;
__scalar mul(__scalar a,__scalar b) {
return a*b;
}
template&lt;class __scalar&gt;
__scalar mul(__scalar a, __scalar b) {
return a*b;
}
}
%include &lt;std_complex.i&gt;
%template(mul) mul&lt;std::complex&lt;double&gt; &gt;
@ -677,11 +684,11 @@ and then used from Octave
</p>
<div class="targetlang"><pre>
octave:1> mul(4,3)
octave:1> mul(4, 3)
ans = 12
octave:2> mul(4.2,3.6)
octave:2> mul(4.2, 3.6)
ans = 15.120
octave:3> mul(3+4i,10+2i)
octave:3> mul(3+4i, 10+2i)
ans = 22 + 46i
</pre></div>
@ -722,18 +729,18 @@ octave:2> a=sum_complex(2+3i);
octave:3> a.add(2)
ans =
(4,3)
(4, 3)
octave:4> a.add(3+i)
ans =
(7,4)
(7, 4)
</pre></div>
<H3><a name="Octave_nn21">32.3.12 C++ Smart Pointers</a></H3>
<H3><a name="Octave_nn21">29.3.12 C++ Smart Pointers</a></H3>
<H4><a name="Octave_smart_pointers_shared_ptr">32.3.12.1 The shared_ptr Smart Pointer</a></H4>
<H4><a name="Octave_smart_pointers_shared_ptr">29.3.12.1 The shared_ptr Smart Pointer</a></H4>
<p>
@ -744,14 +751,14 @@ in the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a
</p>
<H4><a name="Octave_smart_pointers_generic">32.3.12.2 Generic Smart Pointers</a></H4>
<H4><a name="Octave_smart_pointers_generic">29.3.12.2 Generic Smart Pointers</a></H4>
<p>
C++ smart pointers are fully supported as in other modules.
</p>
<H3><a name="Octave_nn22">32.3.13 Directors (calling Octave from C++ code)</a></H3>
<H3><a name="Octave_nn22">29.3.13 Directors (calling Octave from C++ code)</a></H3>
<p>
@ -766,7 +773,7 @@ For example,
<div class="targetlang"><pre>
octave:1&gt; a=subclass();
octave:2&gt; a.my_var = 4;
octave:3&gt; a.my_method = @(self) printf("my_var = ",self.my_var);
octave:3&gt; a.my_method = @(self) printf("my_var = ", self.my_var);
octave:4&gt; a.my_method();
my_var = 4
</pre></div>
@ -790,7 +797,7 @@ void call_your_method(A&amp; a) {
Then from Octave you can say:
</p>
<div class="targetlang"><pre>
octave:1&gt; B=@() subclass(A(),@my_method);
octave:1&gt; B=@() subclass(A(), @my_method);
octave:2&gt; function my_method(self)
octave:3&gt; printf("octave-side routine called\n");
octave:4&gt; end
@ -801,7 +808,7 @@ octave-side routine called
or more concisely,
</p>
<div class="targetlang"><pre>
octave:1&gt; B=@() subclass(A(),'my_method',@(self) printf("octave-side routine called\n"));
octave:1&gt; B=@() subclass(A(), 'my_method', @(self) printf("octave-side routine called\n"));
octave:2&gt; call_your_method(B());
octave-side routine called
</pre></div>
@ -809,10 +816,10 @@ octave-side routine called
Note that you have to enable directors via the %feature directive (see other modules for this).
</p>
<p>
<tt>subclass()</tt> will accept any number of C++ bases or other <tt>subclass()</tt>'ed objects, <tt>(string,octave_value)</tt> pairs, and <tt>function_handles</tt>. In the first case, these are taken as base classes; in the second case, as named members (either variables or functions, depending on whether the given value is a function handle); in the third case, as member functions whose name is taken from the given function handle. E.g.,
<tt>subclass()</tt> will accept any number of C++ bases or other <tt>subclass()</tt>'ed objects, <tt>(string, octave_value)</tt> pairs, and <tt>function_handles</tt>. In the first case, these are taken as base classes; in the second case, as named members (either variables or functions, depending on whether the given value is a function handle); in the third case, as member functions whose name is taken from the given function handle. E.g.,
</p>
<div class="targetlang"><pre>
octave:1&gt; B=@(some_var=2) subclass(A(),'some_var',some_var,@some_func,'another_func',
octave:1&gt; B=@(some_var=2) subclass(A(), 'some_var', some_var, @some_func, 'another_func',
@(self) do_stuff())
</pre></div>
<p>
@ -822,7 +829,7 @@ You can also assign non-C++ member variables and functions after construct time.
There is limited support for explicitly referencing C++ bases. So, in the example above, we could have
</p>
<div class="targetlang"><pre>
octave:1&gt; B=@() subclass(A(),@my_method);
octave:1&gt; B=@() subclass(A(), @my_method);
octave:2&gt; function my_method(self)
octave:3&gt; self.A.my_method();
octave:4&gt; printf("octave-side routine called\n");
@ -832,14 +839,14 @@ c-side routine called
octave-side routine called
</pre></div>
<H3><a name="Octave_nn23">32.3.14 Threads</a></H3>
<H3><a name="Octave_nn23">29.3.14 Threads</a></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">32.3.15 Memory management</a></H3>
<H3><a name="Octave_nn24">29.3.15 Memory management</a></H3>
<p>
@ -873,21 +880,21 @@ 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">32.3.16 STL support</a></H3>
<H3><a name="Octave_nn25">29.3.16 STL support</a></H3>
<p>
Various STL library files are provided for wrapping STL containers.
</p>
<H3><a name="Octave_nn26">32.3.17 Matrix typemaps</a></H3>
<H3><a name="Octave_nn26">29.3.17 Matrix typemaps</a></H3>
<p>
Octave provides a rich set of classes for dealing with matrices. Currently there are no built-in typemaps to deal with those. However, these are relatively straight forward for users to add themselves (see the docs on typemaps). Without much work (a single typemap decl-- say, 5 lines of code in the interface file), it would be possible to have a function
</p>
<div class="code"><pre>
double my_det(const double* mat,int m,int n);
double my_det(const double* mat, int m, int n);
</pre></div>
<p>
that is accessed from Octave as,

406
Doc/Manual/Perl5.html
View file

File diff suppressed because it is too large Load diff

203
Doc/Manual/Php.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Php">34 SWIG and PHP</a></H1>
<H1><a name="Php">31 SWIG and PHP</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -50,27 +50,17 @@
<p>
SWIG supports generating wrappers for PHP5. Support for PHP4 was removed
in SWIG 1.3.37. The PHP developers are no longer making new PHP4 releases,
and won't even be patching critical security issues after 2008-08-08, so it
doesn't make much sense for SWIG to continue to support PHP4 now. If you
really need to continue to use PHP4, just stick with SWIG 1.3.36.
In this chapter, we discuss SWIG's support of PHP. SWIG currently supports
generating wrappers for PHP7. Support for PHP5 was removed in SWIG 4.0.0
and support for PHP4 was removed in SWIG 1.3.37.
</p>
<p>
Currently any PHP5 release should work, but we don't regularly test with
PHP &lt; 5.3.
Currently any PHP7 release should work.
</p>
<p>
In this chapter, we discuss SWIG's support of PHP. The PHP module
was extensively rewritten in release 1.3.26, and support for generating
OO wrappers for PHP5 was added in 1.3.30. The PHP module now supports most
of the features available in some of the other languages.
</p>
<p>
In order to use this module, you will need to have a copy of the PHP5
In order to use this module, you will need to have a copy of the PHP
include files to compile the SWIG generated files. If you installed
PHP from a binary package, you may need to install a "php-dev" or "php-devel"
package for these to be installed. You can find out where these files are
@ -80,16 +70,17 @@ your extension into php directly, you will need the complete PHP source tree
available.
</p>
<H2><a name="Php_nn1">34.1 Generating PHP Extensions</a></H2>
<H2><a name="Php_nn1">31.1 Generating PHP Extensions</a></H2>
<p>
To build a PHP extension, run swig using the <tt>-php</tt> option as
follows:
To build a PHP extension, run swig using the <tt>-php7</tt> option as follows
(<tt>-php</tt> is also supported and currently is an alias for <tt>-php7</tt>
but prior to SWIG 4.0.0 it was an alias for <tt>-php5</tt>):
</p>
<div class="code"><pre>
swig -php example.i
swig -php7 example.i
</pre></div>
<p>
@ -102,13 +93,16 @@ The third file,
<tt>example.php</tt> can be included by PHP scripts. It attempts to
dynamically load the extension and contains extra php code specified
in the interface file. If wrapping C++ code with PHP classes, it will
also contain PHP5 class wrappers.
also contain PHP class wrappers.
</p>
<p>
SWIG can generate PHP extensions from C++ libraries as well when
given the <tt>-c++</tt> option. The support for C++ is discussed in
more detail in <a href="#Php_nn2_6">section 27.2.6</a>.
more detail in <a href="#Php_nn2_6">section 27.2.6</a>. The generated
C++ wrapper will be called example_wrap.cxx. You can specify a
different extension for the C++ wrapper using <tt>-cppext</tt> -
e.g. if you want example_wrap.cc use <tt>-cppext cc</tt>.
</p>
<p>
@ -125,7 +119,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">34.1.1 Building a loadable extension</a></H3>
<H3><a name="Php_nn1_1">31.1.1 Building a loadable extension</a></H3>
<p>
@ -140,7 +134,7 @@ least work for Linux though):
gcc -shared example_wrap.o example.o -o example.so
</pre></div>
<H3><a name="Php_nn1_3">34.1.2 Using PHP Extensions</a></H3>
<H3><a name="Php_nn1_3">31.1.2 Using PHP Extensions</a></H3>
<p>
@ -159,8 +153,8 @@ If the module is in PHP's default extension directory, you can omit the path.
<p>
For some SAPIs (for example, the CLI SAPI) you can instead use the
<a href="http://php.net/manual/en/function.dl.php">dl() function</a> to load
an extension at run time, by adding a like like this to the start of each
<a href="https://www.php.net/manual/en/function.dl.php">dl() function</a> to load
an extension at run time, by adding a line like this to the start of each
PHP script which uses your extension:
</p>
@ -169,8 +163,8 @@ PHP script which uses your extension:
</pre></div>
<p>
But note that this doesn't work when running PHP through a webserver in PHP5.3
and later - you'll need to use <tt>extension</tt> in <tt>php.ini</tt> as
But note that <tt>dl()</tt> isn't supported when running PHP through a
webserver - you'll need to use <tt>extension</tt> in <tt>php.ini</tt> as
described above.
</p>
@ -188,7 +182,7 @@ This PHP module also defines the PHP classes for the wrapped API, so you'll
almost certainly want to include it anyway.
</p>
<H2><a name="Php_nn2">34.2 Basic PHP interface</a></H2>
<H2><a name="Php_nn2">31.2 Basic PHP interface</a></H2>
<p>
@ -196,10 +190,11 @@ It is important to understand that PHP uses a single global namespace
into which all symbols from extension modules are loaded. It is quite
possible for names of symbols in one extension module to clash with
other symbols unless care is taken to <tt>%rename</tt> them. At present
SWIG doesn't have support for the namespace feature added in PHP 5.3.
SWIG doesn't have support for generating wrappers which make use of PHP's
namespace feature.
</p>
<H3><a name="Php_nn2_1">34.2.1 Constants</a></H3>
<H3><a name="Php_nn2_1">31.2.1 Constants</a></H3>
<p>
@ -236,10 +231,12 @@ echo "E = " . E . "\n";
<p>
There's one peculiarity of how constants work in PHP which it is useful
to note (this is not specific to SWIG though) - if you try to use an undeclared
constant, PHP will emit a notice and then expand the constant to a string
version of the constant's name. Unfortunately it is easy to miss the notice
if you're using PHP in a webserver, as it will probably end up in error.log or
similar.
constant, PHP will emit a warning (or a notice in PHP 7.1 and earlier) and then
expand the constant to a string version of the constant's name. Unfortunately
it is easy to miss the warning message if you're using PHP in a webserver as
it will probably end up in error.log or similar. Apparently this will throw
an Error in a future version of PHP, but until then it's something to be
aware of.
</p>
<p>
@ -276,7 +273,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">34.2.2 Global Variables</a></H3>
<H3><a name="Php_nn2_2">31.2.2 Global Variables</a></H3>
<p>
@ -291,7 +288,7 @@ the use of automatically generated accessor functions.
%inline %{
double seki = 2;
void print_seki() {
zend_printf("seki is now %f\n",seki);
zend_printf("seki is now %f\n", seki);
}
%}
</pre></div>
@ -325,7 +322,7 @@ undefined.
At this time SWIG does not support custom accessor methods.
</p>
<H3><a name="Php_nn2_3">34.2.3 Functions</a></H3>
<H3><a name="Php_nn2_3">31.2.3 Functions</a></H3>
<p>
@ -378,7 +375,7 @@ print $s; # The value of $s was not changed.
-->
<H3><a name="Php_nn2_4">34.2.4 Overloading</a></H3>
<H3><a name="Php_nn2_4">31.2.4 Overloading</a></H3>
<p>
@ -386,8 +383,7 @@ Although PHP does not support overloading functions natively, swig
will generate dispatch functions which will use <tt>%typecheck</tt>
typemaps to allow overloading. This dispatch function's operation and
precedence is described in <a
href="SWIGPlus.html#SWIGPlus_overloaded_methods">Wrapping
Overloaded Functions and Methods</a>.
href="SWIGPlus.html#SWIGPlus_overloaded_methods">Overloaded functions and methods</a>.
</p>
<!-- This isn't correct for 1.3.30 and needs rewriting to reflect reality
@ -434,7 +430,7 @@ taking the integer argument.
</p>
-->
<H3><a name="Php_nn2_5">34.2.5 Pointers and References</a></H3>
<H3><a name="Php_nn2_5">31.2.5 Pointers and References</a></H3>
<p>
@ -459,7 +455,7 @@ One can include <b>cpointer.i</b> to generate PHP wrappers to <tt>int
<div class="code"><pre>
%module example
%include "cpointer.i"
%pointer_functions(int,intp)
%pointer_functions(int, intp)
void add( int *in1, int *in2, int *result);
</pre></div>
@ -509,7 +505,7 @@ include("example.php");
$in1 = 3;
$in2 = 5;
$result= add($in1,$in2); # Note using variables for the input is unnecessary.
$result= add($in1, $in2); # Note using variables for the input is unnecessary.
echo "The sum $in1 + $in2 = $result\n";
?&gt;
@ -522,13 +518,6 @@ this, one needs to include <b>phppointers.i</b> which defines the
named typemap REF.
</p>
<p>
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
@ -555,7 +544,7 @@ include("example.php");
$in1 = 3;
$in2 = 5;
$result = 0;
add($in1,$in2,$result);
add($in1, $in2, $result);
echo "The sum $in1 + $in2 = $result\n";
?&gt;
@ -579,7 +568,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">34.2.6 Structures and C++ classes</a></H3>
<H3><a name="Php_nn2_6">31.2.6 Structures and C++ classes</a></H3>
<p>
@ -599,7 +588,7 @@ This interface file
class Vector {
public:
double x,y,z;
double x, y, z;
Vector();
~Vector();
double magnitude();
@ -611,7 +600,7 @@ struct Complex {
</pre></div>
<p>
Would be used in the following way from PHP5:
Would be used in the following way from PHP:
</p>
<div class="code"><pre>
@ -623,7 +612,7 @@ Would be used in the following way from PHP5:
$v-&gt;y = 4;
$v-&gt;z = 5;
echo "Magnitude of ($v-&gt;x,$v-&gt;y,$v-&gt;z) = " . $v-&gt;magnitude() . "\n";
echo "Magnitude of ($v-&gt;x, $v-&gt;y, $v-&gt;z) = " . $v-&gt;magnitude() . "\n";
$v = NULL; # destructor called.
@ -640,33 +629,33 @@ 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">34.2.6.1 Using -noproxy</a></H4>
<H4><a name="Php_nn2_6_1">31.2.6.1 Using -noproxy</a></H4>
<p>
The <tt>-noproxy</tt> option flattens the object structure and
generates collections of named functions (these are the functions
which the PHP5 class wrappers call). The above example results
which the PHP class wrappers call). The above example results
in the following PHP functions:
</p>
<div class="code"><pre>
new_Vector();
Vector_x_set($obj,$d);
Vector_x_set($obj, $d);
Vector_x_get($obj);
Vector_y_set($obj,$d);
Vector_y_set($obj, $d);
Vector_y_get($obj);
Vector_z_set($obj,$d);
Vector_z_set($obj, $d);
Vector_z_get($obj);
Vector_magnitude($obj);
new_Complex();
Complex_re_set($obj,$d);
Complex_re_set($obj, $d);
Complex_re_get($obj);
Complex_im_set($obj,$d);
Complex_im_set($obj, $d);
Complex_im_get($obj);
</pre></div>
<H4><a name="Php_nn2_6_2">34.2.6.2 Constructors and Destructors</a></H4>
<H4><a name="Php_nn2_6_2">31.2.6.2 Constructors and Destructors</a></H4>
<p>
@ -707,7 +696,7 @@ the programmer can either reassign the variable or call
<tt>unset($v)</tt>
</p>
<H4><a name="Php_nn2_6_3">34.2.6.3 Static Member Variables</a></H4>
<H4><a name="Php_nn2_6_3">31.2.6.3 Static Member Variables</a></H4>
<p>
@ -750,7 +739,7 @@ Ko::threats(10);
echo "There have now been " . Ko::threats() . " threats\n";
</pre></div>
<H4><a name="Php_nn2_6_4">34.2.6.4 Static Member Functions</a></H4>
<H4><a name="Php_nn2_6_4">31.2.6.4 Static Member Functions</a></H4>
<p>
@ -772,7 +761,7 @@ Ko::threats();
</pre></div>
<H4><a name="Php_nn2_6_5">34.2.6.5 Specifying Implemented Interfaces</a></H4>
<H4><a name="Php_nn2_6_5">31.2.6.5 Specifying Implemented Interfaces</a></H4>
<p>
@ -790,7 +779,7 @@ so:
If there are multiple interfaces, just list them separated by commas.
</p>
<H3><a name="Php_nn2_7">34.2.7 PHP Pragmas, Startup and Shutdown code</a></H3>
<H3><a name="Php_nn2_7">31.2.7 PHP Pragmas, Startup and Shutdown code</a></H3>
<p>
@ -816,6 +805,15 @@ Results in the following in "example.php"
echo "example.php execution\n";
</pre></div>
<p>
The <b>version</b> pragma can be used to add version to generated PHP extension module. The version is inserted in the zend_module_entry block.
</p>
<div class="code"><pre>
%module example
%pragma(php) version="1.5"
</pre></div>
<p>
The <b>include</b> pragma is a short cut to add include statements to
the example.php file.
@ -878,7 +876,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">34.3 Cross language polymorphism</a></H2>
<H2><a name="Php_nn3">31.3 Cross language polymorphism</a></H2>
<p>
@ -913,7 +911,7 @@ wrapper functions takes care of all the cross-language method routing
transparently.
</p>
<H3><a name="Php_nn3_1">34.3.1 Enabling directors</a></H3>
<H3><a name="Php_nn3_1">31.3.1 Enabling directors</a></H3>
<p>
@ -940,7 +938,7 @@ globally, to specific classes, and to specific methods, like this:
// generate directors for all classes that have virtual methods
%feature("director");
// generate directors for all virtual methods in class Foo
// generate directors for the virtual methods in class Foo
%feature("director") Foo;
</pre>
</div>
@ -958,7 +956,7 @@ directors for specific classes or methods. So for example,
</div>
<p>
will generate directors for all virtual methods of class Foo except
will generate directors for the virtual methods of class Foo except
bar().
</p>
@ -973,14 +971,14 @@ the methods one() and two() (but not three()):
%feature("director") Foo;
class Foo {
public:
Foo(int foo);
virtual void one();
virtual void two();
Foo(int foo);
virtual void one();
virtual void two();
};
class Bar: public Foo {
public:
virtual void three();
virtual void three();
};
</pre>
</div>
@ -995,14 +993,14 @@ require("mymodule.php");
class MyFoo extends Foo {
function one() {
print "one from php\n";
print "one from php\n";
}
}
</pre>
</div>
<H3><a name="Php_nn3_2">34.3.2 Director classes</a></H3>
<H3><a name="Php_nn3_2">31.3.2 Director classes</a></H3>
@ -1023,7 +1021,8 @@ 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
Virtual methods that have a final specifier are unsurprisingly excluded.
Thus the virtual method calls, whether they originate in C++ or in
PHP 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
@ -1082,7 +1081,7 @@ so there is no need for the extra overhead involved with routing the
calls through PHP.
</p>
<H3><a name="Php_nn3_3">34.3.3 Ownership and object destruction</a></H3>
<H3><a name="Php_nn3_3">31.3.3 Ownership and object destruction</a></H3>
<p>
@ -1112,12 +1111,12 @@ Here is an example:
<pre>
class Foo {
public:
...
...
};
class FooContainer {
public:
void addFoo(Foo *);
...
void addFoo(Foo *);
...
};
</pre>
</div>
@ -1138,25 +1137,33 @@ 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">34.3.4 Exception unrolling</a></H3>
<H3><a name="Php_nn3_4">31.3.4 Exception unrolling</a></H3>
<p>
With directors routing method calls to PHP, 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 PHP. 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:
to C++, the handling of exceptions is an important concern. By default, an
exception thrown in PHP code called from C++ causes the PHP interpreter
to flag that an exception is thrown, then return passes to C++ as if
the PHP function had returned <code>Null</code>. Assuming the directorout
typemaps handle this (those SWIG defines by default should) then once
control returns to PHP code again, the PHP exception will actually propagate.
</p>
<p>
Sometimes this control flow is problematic, and you want to skip any
handling in the C++ code. To achieve this, it is necessary
to temporarily translate the PHP exception into a C++ exception. This can be
achieved using the %feature("director:except") directive. The following code
should suffice in most cases:
</p>
<div class="code">
<pre>
%feature("director:except") {
if ($error == FAILURE) {
throw Swig::DirectorMethodException();
}
if ($error == FAILURE) {
throw Swig::DirectorMethodException();
}
}
</pre>
</div>
@ -1183,8 +1190,8 @@ suitable exception handler:
<div class="code">
<pre>
%exception {
try { $action }
catch (Swig::DirectorException &amp;e) { SWIG_fail; }
try { $action }
catch (Swig::DirectorException &amp;e) { SWIG_fail; }
}
</pre>
</div>
@ -1197,7 +1204,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">34.3.5 Overhead and code bloat</a></H3>
<H3><a name="Php_nn3_5">31.3.5 Overhead and code bloat</a></H3>
<p>
@ -1230,7 +1237,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">34.3.6 Typemaps</a></H3>
<H3><a name="Php_nn3_6">31.3.6 Typemaps</a></H3>
<p>
@ -1244,7 +1251,7 @@ need to be supported.
</p>
<H3><a name="Php_nn3_7">34.3.7 Miscellaneous</a></H3>
<H3><a name="Php_nn3_7">31.3.7 Miscellaneous</a></H3>
<p> Director typemaps for STL classes are mostly in place, and hence you

28
Doc/Manual/Pike.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Pike">35 SWIG and Pike</a></H1>
<H1><a name="Pike">37 SWIG and Pike</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -47,10 +47,10 @@ least, make sure you read the "<a href="SWIG.html#SWIG">SWIG Basics</a>"
chapter.<br>
</p>
<H2><a name="Pike_nn2">35.1 Preliminaries</a></H2>
<H2><a name="Pike_nn2">37.1 Preliminaries</a></H2>
<H3><a name="Pike_nn3">35.1.1 Running SWIG</a></H3>
<H3><a name="Pike_nn3">37.1.1 Running SWIG</a></H3>
<p>
@ -95,7 +95,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">35.1.2 Getting the right header files</a></H3>
<H3><a name="Pike_nn4">37.1.2 Getting the right header files</a></H3>
<p>
@ -115,7 +115,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">35.1.3 Using your module</a></H3>
<H3><a name="Pike_nn5">37.1.3 Using your module</a></H3>
<p>
@ -130,10 +130,10 @@ Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
(1) Result: 24
</pre></div>
<H2><a name="Pike_nn6">35.2 Basic C/C++ Mapping</a></H2>
<H2><a name="Pike_nn6">37.2 Basic C/C++ Mapping</a></H2>
<H3><a name="Pike_nn7">35.2.1 Modules</a></H3>
<H3><a name="Pike_nn7">37.2.1 Modules</a></H3>
<p>
@ -144,7 +144,7 @@ concerned), SWIG's <tt>%module</tt> directive doesn't really have any
significance.
</p>
<H3><a name="Pike_nn8">35.2.2 Functions</a></H3>
<H3><a name="Pike_nn8">37.2.2 Functions</a></H3>
<p>
@ -169,7 +169,7 @@ exactly as you'd expect it to:
(1) Result: 24
</pre></div>
<H3><a name="Pike_nn9">35.2.3 Global variables</a></H3>
<H3><a name="Pike_nn9">37.2.3 Global variables</a></H3>
<p>
@ -198,7 +198,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">35.2.4 Constants and enumerated types</a></H3>
<H3><a name="Pike_nn10">37.2.4 Constants and enumerated types</a></H3>
<p>
@ -206,7 +206,7 @@ Enumerated types in C/C++ declarations are wrapped as Pike constants,
not as Pike enums.
</p>
<H3><a name="Pike_nn11">35.2.5 Constructors and Destructors</a></H3>
<H3><a name="Pike_nn11">37.2.5 Constructors and Destructors</a></H3>
<p>
@ -214,7 +214,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">35.2.6 Static Members</a></H3>
<H3><a name="Pike_nn12">37.2.6 Static Members</a></H3>
<p>
@ -230,8 +230,8 @@ For example, given this C++ class declaration:
class Shape
{
public:
static void print();
static int nshapes;
static void print();
static int nshapes;
};
</pre></div>

7
Doc/Manual/Preface.html
View file

@ -69,6 +69,9 @@ over a period of 10 years starting from the year 2000. The final version in the
series was 1.3.40, but in truth the 1.3.x series had been stable for many years.
An official stable version was released along with the decision to make SWIG
license changes and this gave rise to version 2.0.0 in 2010.
Version 3.0.0 was released in 2014 focusing on adding C++11 support and C++ nested classes.
Version 4.0.0 was released in 2019 to add in Doxygen support.
Some target languages were disabled as part of a clean up and others were given a new status of either 'Supported' or 'Experimental'.
</p>
<H2><a name="Preface_license">1.3 SWIG License</a></H2>
@ -364,7 +367,7 @@ a number of packages to be installed. Full instructions at
<p>
SWIG is known to work on various flavors of OS X. Follow the Unix installation
instructions above. However, as of this writing, there is still great deal of
inconsistency with how shared libaries are handled by various scripting languages
inconsistency with how shared libraries are handled by various scripting languages
on OS X.
</p>
@ -435,7 +438,7 @@ don't intend to use these features in your own programs.
</p>
<p>
Note: The test-suite currently contains over 500 tests. If you
Note: The test-suite currently contains over 600 tests. If you
have many different target languages installed and a slow machine, it
might take more than an hour to run the test-suite.
</p>

90
Doc/Manual/Preprocessor.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Preprocessor">8 Preprocessing</a></H1>
<H1><a name="Preprocessor">10 Preprocessing</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -38,7 +38,7 @@ However, a number of modifications and enhancements have been made. This
chapter describes some of these modifications.
</p>
<H2><a name="Preprocessor_nn2">8.1 File inclusion</a></H2>
<H2><a name="Preprocessor_nn2">10.1 File inclusion</a></H2>
<p>
@ -64,7 +64,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">8.2 File imports</a></H2>
<H2><a name="Preprocessor_nn3">10.2 File imports</a></H2>
<p>
@ -93,7 +93,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">8.3 Conditional Compilation</a></H2>
<H2><a name="Preprocessor_condition_compilation">10.3 Conditional Compilation</a></H2>
<p>
@ -109,10 +109,6 @@ SWIGIMPORTED Defined when SWIG is importing a file with <tt>%
SWIG_VERSION Hexadecimal (binary-coded decimal) number containing SWIG version,
such as 0x010311 (corresponding to SWIG-1.3.11).
SWIGALLEGROCL Defined when using Allegro CL
SWIGCFFI Defined when using CFFI
SWIGCHICKEN Defined when using CHICKEN
SWIGCLISP Defined when using CLISP
SWIGCSHARP Defined when using C#
SWIGGUILE Defined when using Guile
SWIGJAVA Defined when using Java
@ -120,18 +116,16 @@ 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
SWIGOCAML Defined when using Ocaml
SWIGOCAML Defined when using OCaml
SWIGOCTAVE Defined when using Octave
SWIGPERL Defined when using Perl
SWIGPHP Defined when using PHP
SWIGPIKE Defined when using Pike
SWIGPHP Defined when using PHP (any version)
SWIGPHP7 Defined when using PHP7
SWIGPYTHON Defined when using Python
SWIGR Defined when using R
SWIGRUBY Defined when using Ruby
SWIGSCILAB Defined when using Scilab
SWIGSEXP Defined when using S-expressions
SWIGTCL Defined when using Tcl
SWIGXML Defined when using XML
</pre></div>
@ -144,7 +138,7 @@ In addition, SWIG defines the following set of standard C/C++ macros:
<pre>
__LINE__ Current line number
__FILE__ Current file name
__STDC__ Defined to indicate ANSI C
__STDC__ Defined to indicate ISO C
__cplusplus Defined when -c++ option used
</pre>
</div>
@ -157,7 +151,7 @@ SWIG (except for the symbol `<tt>SWIG</tt>' which is only defined
within the SWIG compiler).
</p>
<H2><a name="Preprocessor_nn5">8.4 Macro Expansion</a></H2>
<H2><a name="Preprocessor_nn5">10.4 Macro Expansion</a></H2>
<p>
@ -186,9 +180,9 @@ More complex macros can be defined in the standard way. For example:
<pre>
#define EXTERN extern
#ifdef __STDC__
#define _ANSI(args) (args)
#define ISOC_(args) (args)
#else
#define _ANSI(args) ()
#define ISOC_(args) ()
#endif
</pre>
</div>
@ -212,7 +206,7 @@ like <tt>#x</tt>. This is a non-standard SWIG extension.
</li>
</ul>
<H2><a name="Preprocessor_nn6">8.5 SWIG Macros</a></H2>
<H2><a name="Preprocessor_nn6">10.5 SWIG Macros</a></H2>
<p>
@ -222,19 +216,19 @@ For example:
<div class="code">
<pre>
%define ARRAYHELPER(type,name)
%define ARRAYHELPER(type, name)
%inline %{
type *new_ ## name (int nitems) {
return (type *) malloc(sizeof(type)*nitems);
return (type *) malloc(sizeof(type)*nitems);
}
void delete_ ## name(type *t) {
free(t);
free(t);
}
type name ## _get(type *t, int index) {
return t[index];
return t[index];
}
void name ## _set(type *t, int index, type val) {
t[index] = val;
t[index] = val;
}
%}
%enddef
@ -258,7 +252,7 @@ many of SWIG's advanced features and libraries are built using this mechanism (s
support).
</p>
<H2><a name="Preprocessor_nn7">8.6 C99 and GNU Extensions</a></H2>
<H2><a name="Preprocessor_nn7">10.6 C99 and GNU Extensions</a></H2>
<p>
@ -267,7 +261,7 @@ SWIG-1.3.12 and newer releases support variadic preprocessor macros. For exampl
<div class="code">
<pre>
#define DEBUGF(fmt,...) fprintf(stderr,fmt,__VA_ARGS__)
#define DEBUGF(fmt, ...) fprintf(stderr, fmt, __VA_ARGS__)
</pre>
</div>
@ -279,12 +273,12 @@ macros defined using <tt>%define</tt>.
<p>
SWIG allows a variable number of arguments to be empty. However, this often results
in an extra comma (,) and syntax error in the resulting expansion. For example:
in an extra comma (, ) and syntax error in the resulting expansion. For example:
</p>
<div class="code">
<pre>
DEBUGF("hello"); --&gt; fprintf(stderr,"hello",);
DEBUGF("hello"); --&gt; fprintf(stderr, "hello", );
</pre>
</div>
@ -294,7 +288,7 @@ To get rid of the extra comma, use <tt>##</tt> like this:
<div class="code">
<pre>
#define DEBUGF(fmt,...) fprintf(stderr,fmt, ##__VA_ARGS__)
#define DEBUGF(fmt, ...) fprintf(stderr, fmt, ##__VA_ARGS__)
</pre>
</div>
@ -304,7 +298,7 @@ SWIG also supports GNU-style variadic macros. For example:
<div class="code">
<pre>
#define DEBUGF(fmt, args...) fprintf(stdout,fmt,args)
#define DEBUGF(fmt, args...) fprintf(stdout, fmt, args)
</pre>
</div>
@ -314,14 +308,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">8.7 Preprocessing and delimiters</a></H2>
<H2><a name="Preprocessor_delimiters">10.7 Preprocessing and delimiters</a></H2>
<p>
The preprocessor handles { }, " " and %{ %} delimiters differently.
</p>
<H3><a name="Preprocessor_nn8">8.7.1 Preprocessing and %{ ... %} &amp; " ... " delimiters</a></H3>
<H3><a name="Preprocessor_nn8">10.7.1 Preprocessing and %{ ... %} &amp; " ... " delimiters</a></H3>
<p>
@ -334,7 +328,7 @@ if you write code like this,
%{
#ifdef NEED_BLAH
int blah() {
...
...
}
#endif
%}
@ -346,7 +340,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">8.7.2 Preprocessing and { ... } delimiters</a></H3>
<H3><a name="Preprocessor_nn9">10.7.2 Preprocessing and { ... } delimiters</a></H3>
<p>
@ -358,11 +352,11 @@ file. For example:
<div class="code">
<pre>
%extend Foo {
void bar() {
#ifdef DEBUG
printf("I'm in bar\n");
#endif
}
void bar() {
#ifdef DEBUG
printf("I'm in bar\n");
#endif
}
}
</pre>
</div>
@ -375,11 +369,11 @@ to actually go into the wrapper file, prefix the preprocessor directives with <t
<div class="code">
<pre>
%extend Foo {
void bar() {
%#ifdef DEBUG
printf("I'm in bar\n");
%#endif
}
void bar() {
%#ifdef DEBUG
printf("I'm in bar\n");
%#endif
}
}
</pre>
</div>
@ -388,7 +382,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">8.8 Preprocessor and Typemaps</a></H2>
<H2><a name="Preprocessor_typemap_delimiters">10.8 Preprocessor and Typemaps</a></H2>
<p>
@ -423,7 +417,7 @@ whereas
<div class="code">
<pre>
#define SWIG_macro(CAST) (CAST)$input
%typemap(in,noblock=1) Int {$1= SWIG_macro(int);}
%typemap(in, noblock=1) Int {$1= SWIG_macro(int);}
</pre>
</div>
@ -459,17 +453,17 @@ would generate
</div>
<H2><a name="Preprocessor_nn10">8.9 Viewing preprocessor output</a></H2>
<H2><a name="Preprocessor_nn10">10.9 Viewing preprocessor output</a></H2>
<p>
Like many compilers, SWIG supports a <tt>-E</tt> command line option to display the output from the preprocessor.
When the <tt>-E</tt> switch is used, SWIG will not generate any wrappers.
When the <tt>-E</tt> option is used, SWIG will not generate any wrappers.
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">8.10 The #error and #warning directives</a></H2>
<H2><a name="Preprocessor_warning_error">10.10 The #error and #warning directives</a></H2>
<p>

1985
Doc/Manual/Python.html
View file

File diff suppressed because it is too large Load diff

66
Doc/Manual/R.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="R">37 SWIG and R</a></H1>
<H1><a name="R">33 SWIG and R</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -34,7 +34,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">37.1 Bugs</a></H2>
<H2><a name="R_nn2">33.1 Bugs</a></H2>
<p>
@ -46,7 +46,7 @@ Currently the following features are not implemented or broken:
<li>C Array wrappings
</ul>
<H2><a name="R_nn3">37.2 Using R and SWIG</a></H2>
<H2><a name="R_nn3">33.2 Using R and SWIG</a></H2>
<p>
@ -129,7 +129,7 @@ These two files can be loaded in any order
<li>If you do not set the output file name appropriately, you might see errors like
<div class="shell">
<pre>
> fact(4)
&gt; fact(4)
Error in .Call("R_swig_fact", s_arg1, as.logical(.copy), PACKAGE = "example") :
"R_swig_fact" not available for .Call() for package "example"
</pre>
@ -137,7 +137,7 @@ Error in .Call("R_swig_fact", s_arg1, as.logical(.copy), PACKAGE = "example") :
<li>Make sure the architecture of the shared library(x64 for instance), matches the architecture of the R program you want to load your shared library into
</ul>
<H2><a name="R_nn4">37.3 Precompiling large R files</a></H2>
<H2><a name="R_nn4">33.3 Precompiling large R files</a></H2>
In cases where the R file is large, one make save a lot of loading
@ -146,7 +146,7 @@ file makeRData.R which contains the following
<pre>
source('BigFile.R')
save(list=ls(all=TRUE),file="BigFile.RData", compress=TRUE)
save(list=ls(all=TRUE), file="BigFile.RData", compress=TRUE)
q(save="no")
</pre>
@ -155,7 +155,7 @@ will save a large amount of loading time.
<H2><a name="R_nn5">37.4 General policy</a></H2>
<H2><a name="R_nn5">33.4 General policy</a></H2>
<p>
@ -164,7 +164,7 @@ wrapping over the underlying functions and rely on the R type system
to provide R syntax.
</p>
<H2><a name="R_language_conventions">37.5 Language conventions</a></H2>
<H2><a name="R_language_conventions">33.5 Language conventions</a></H2>
<p>
@ -173,7 +173,7 @@ and [ are overloaded to allow for R syntax (one based indices and
slices)
</p>
<H2><a name="R_nn6">37.6 C++ classes</a></H2>
<H2><a name="R_nn6">33.6 C++ classes</a></H2>
<p>
@ -185,13 +185,53 @@ 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">37.7 Enumerations</a></H2>
<H2><a name="R_nn7">33.7 Enumerations</a></H2>
<p>
enumerations are characters which are then converted back and forth to
ints before calling the C routines. All of the enumeration code is
done in R.
R doesn't have a native enumeration type. Enumerations are represented
as character strings in R, with calls to R functions that convert back
and forth between integers.
The details of enumeration names and contents are stored in hidden R
environments, which are named according the the enumeration name - for
example, an enumeration colour:
<div class="code"><pre>
enum colour { red=-1, blue, green = 10 };
</pre></div>
will be initialized by the following call in R:
<div class="code"><pre>
defineEnumeration("_colour",
.values=c("red" = .Call('R_swig_colour_red_get',FALSE, PACKAGE='enum_thorough'),
"blue" = .Call('R_swig_colour_blue_get',FALSE, PACKAGE='enum_thorough'),
"green" = .Call('R_swig_colour_green_get',FALSE, PACKAGE='enum_thorough')))
</pre></div>
<p>
which will create an environment named <tt>.__E___colour</tt>. The enumeration
values are initialised via calls to C/C++ code, allowing complex
values for enumerations to be used. Calls to the C/C++ code require
the compiled library to be loaded, so a <tt>delayedAssign</tt> is employed
within <tt>defineEnumeration</tt> in order to allow the code to be easily used in R
packages.
The user typically does not need to access the enumeration lookup
functions or know the name of the enumeration type used by
R. Attributes containing the type information are attached by swig to
functions requiring enumeration arguments or returning enumeration
values, and those attributes are used to identify and access the
appropriate environments and thus translate between characters
and integers.
The relevant functions, for debugging purposes, are <tt>enumToInteger</tt> and
<tt>enumFromInteger</tt>.
Anonymous enumerations are ignored by the binding generation process,
leaving no way of accessing the value of anonymous enumerations from R
code.
</p>
</body>

305
Doc/Manual/Ruby.html
View file

File diff suppressed because it is too large Load diff

493
Doc/Manual/SWIG.html
View file

@ -88,7 +88,7 @@
<p>
This chapter describes the basic operation of SWIG, the structure of its
input files, and how it handles standard ANSI C declarations. C++ support is
input files, and how it handles standard ISO C declarations. C++ support is
described in the next chapter. However, C++ programmers should still read this
chapter to understand the basics.
Specific details about each target language are described in later
@ -103,70 +103,156 @@ To run SWIG, use the <tt>swig</tt> command with options and a filename like this
</p>
<div class="shell"><pre>
swig [ <em>options</em> ] filename
swig [ options ] filename
</pre></div>
<p>
where <tt>filename</tt> is a SWIG interface file or a C/C++ header file.
Below is a subset of <em>options</em> that can be used.
Full help can be seen by running <tt>swig -help</tt>.
Below is the common set of options that can be used.
Additional options are also defined for each target language. A full list
can be obtained by typing <tt>swig -help</tt> or <tt>swig
<em>-&lt;lang&gt;</em> -help</tt> for language <em>&lt;lang&gt;</em> specific options.
can be obtained by running <tt>swig
<em>-&lt;lang&gt;</em> -help</tt> for language <em>&lt;lang&gt;</em> specific options,
for example, <tt>swig -ruby -help</tt> for Ruby.
</p>
<div class="shell"><pre>
-allegrocl Generate ALLEGROCL wrappers
-chicken Generate CHICKEN wrappers
-clisp Generate CLISP wrappers
-cffi Generate CFFI wrappers
-csharp Generate C# wrappers
-d Generate D wrappers
-go Generate Go wrappers
-guile Generate Guile wrappers
-java Generate Java wrappers
-javascript Generate Javascript wrappers
-lua Generate Lua wrappers
-modula3 Generate Modula 3 wrappers
-mzscheme Generate Mzscheme wrappers
-ocaml Generate Ocaml wrappers
-octave Generate Octave wrappers
-perl Generate Perl wrappers
-php Generate PHP wrappers
-pike Generate Pike wrappers
-python Generate Python wrappers
-r Generate R (aka GNU S) wrappers
-ruby Generate Ruby wrappers
-scilab Generate Scilab wrappers
-sexp Generate Lisp S-Expressions wrappers
-tcl Generate Tcl wrappers
-uffi Generate Common Lisp / UFFI wrappers
-xml Generate XML wrappers
Supported Target Language Options
-csharp - Generate C# wrappers
-d - Generate D wrappers
-go - Generate Go wrappers
-guile - Generate Guile wrappers
-java - Generate Java wrappers
-javascript - Generate Javascript wrappers
-lua - Generate Lua wrappers
-octave - Generate Octave wrappers
-perl5 - Generate Perl 5 wrappers
-php7 - Generate PHP 7 wrappers
-python - Generate Python wrappers
-r - Generate R (aka GNU S) wrappers
-ruby - Generate Ruby wrappers
-scilab - Generate Scilab wrappers
-tcl8 - Generate Tcl 8 wrappers
-xml - Generate XML wrappers
-c++ Enable C++ parsing
-cppext <em>ext</em> Change file extension of C++ generated files to <em>ext</em>
(default is cxx, except for PHP which uses cpp)
-D<em>symbol</em> Define a preprocessor symbol
-Fstandard Display error/warning messages in commonly used format
-Fmicrosoft Display error/warning messages in Microsoft format
-help Display all options
-I<em>dir</em> Add a directory to the file include path
-l<em>file</em> Include a SWIG library file.
-module <em>name</em> Set the name of the SWIG module
-o <em>outfile</em> Set name of C/C++ output file to &lt;outfile&gt;
-oh <em>headfile</em> Set name of C++ output header file for directors to &lt;headfile&gt;
-outcurrentdir Set default output dir to current dir instead of input file's path
-outdir <em>dir</em> Set language specific files output directory
-pcreversion Display PCRE version information
-swiglib Show location of SWIG library
-version Show SWIG version number
Experimental Target Language Options
-mzscheme - Generate MzScheme/Racket wrappers
-ocaml - Generate OCaml wrappers
General Options
-addextern - Add extra extern declarations
-c++ - Enable C++ processing
-co &lt;file&gt; - Check &lt;file&gt; out of the SWIG library
-copyctor - Automatically generate copy constructors wherever possible
-cpperraswarn - Treat the preprocessor #error statement as #warning (default)
-cppext &lt;ext&gt; - Change file extension of generated C++ files to &lt;ext&gt;
(default is cxx)
-copyright - Display copyright notices
-debug-classes - Display information about the classes found in the interface
-debug-module &lt;n&gt;- Display module parse tree at stages 1-4, &lt;n&gt; is a csv list of stages
-debug-symtabs - Display symbol tables information
-debug-symbols - Display target language symbols in the symbol tables
-debug-csymbols - Display C symbols in the symbol tables
-debug-lsymbols - Display target language layer symbols
-debug-tags - Display information about the tags found in the interface
-debug-template - Display information for debugging templates
-debug-top &lt;n&gt; - Display entire parse tree at stages 1-4, &lt;n&gt; is a csv list of stages
-debug-typedef - Display information about the types and typedefs in the interface
-debug-typemap - Display typemap debugging information
-debug-tmsearch - Display typemap search debugging information
-debug-tmused - Display typemaps used debugging information
-directors - Turn on director mode for all the classes, mainly for testing
-dirprot - Turn on wrapping of protected members for director classes (default)
-D&lt;symbol&gt; - Define a symbol &lt;symbol&gt; (for conditional compilation)
-E - Preprocess only, does not generate wrapper code
-external-runtime [file] - Export the SWIG runtime stack
-fakeversion &lt;v&gt;- Make SWIG fake the program version number to &lt;v&gt;
-fcompact - Compile in compact mode
-features &lt;list&gt;- Set global features, where &lt;list&gt; is a comma separated list of
features, eg -features directors,autodoc=1
If no explicit value is given to the feature, a default of 1 is used
-fastdispatch - Enable fast dispatch mode to produce faster overload dispatcher code
-Fmicrosoft - Display error/warning messages in Microsoft format
-Fstandard - Display error/warning messages in commonly used format
-fvirtual - Compile in virtual elimination mode
-help - Display help
-I- - Don't search the current directory
-I&lt;dir&gt; - Look for SWIG files in directory &lt;dir&gt;
-ignoremissing - Ignore missing include files
-importall - Follow all #include statements as imports
-includeall - Follow all #include statements
-l&lt;ifile&gt; - Include SWIG library file &lt;ifile&gt;
-macroerrors - Report errors inside macros
-makedefault - Create default constructors/destructors (the default)
-M - List all dependencies
-MD - Is equivalent to `-M -MF &lt;file&gt;', except `-E' is not implied
-MF &lt;file&gt; - Generate dependencies into &lt;file&gt; and continue generating wrappers
-MM - List dependencies, but omit files in SWIG library
-MMD - Like `-MD', but omit files in SWIG library
-module &lt;name&gt; - Set module name to &lt;name&gt;
-MP - Generate phony targets for all dependencies
-MT &lt;target&gt; - Set the target of the rule emitted by dependency generation
-nocontract - Turn off contract checking
-nocpperraswarn - Do not treat the preprocessor #error statement as #warning
-nodefault - Do not generate default constructors nor default destructors
-nodefaultctor - Do not generate implicit default constructors
-nodefaultdtor - Do not generate implicit default destructors
-nodirprot - Do not wrap director protected members
-noexcept - Do not wrap exception specifiers
-nofastdispatch - Disable fast dispatch mode (default)
-nopreprocess - Skip the preprocessor step
-notemplatereduce - Disable reduction of the typedefs in templates
-O - Enable the optimization options:
-fastdispatch -fvirtual
-o &lt;outfile&gt; - Set name of C/C++ output file to &lt;outfile&gt;
-oh &lt;headfile&gt; - Set name of C++ output header file for directors to &lt;headfile&gt;
-outcurrentdir - Set default output dir to current dir instead of input file's path
-outdir &lt;dir&gt; - Set language specific files output directory to &lt;dir&gt;
-pcreversion - Display PCRE version information
-small - Compile in virtual elimination and compact mode
-swiglib - Report location of SWIG library and exit
-templatereduce - Reduce all the typedefs in templates
-v - Run in verbose mode
-version - Display SWIG version number
-Wall - Remove all warning suppression, also implies -Wextra
-Wallkw - Enable keyword warnings for all the supported languages
-Werror - Treat warnings as errors
-Wextra - Adds the following additional warnings: 202,309,403,405,512,321,322
-w&lt;list&gt; - Suppress/add warning messages, eg -w401,+321 - see Warnings.html
-xmlout &lt;file&gt; - Write XML version of the parse tree to &lt;file&gt; after normal processing
</pre></div>
<p>
Arguments may also be passed in a command-line options file (also known as a
response file) which is useful if they exceed the system command line length
limit. To do this, put the arguments in a file, then provide the file name
prefixed with <tt>@</tt> like so:
</p>
<div class="shell"><pre>
swig @<em>file</em>
</pre></div>
<p>
The options read from the file are inserted in place of the file option. If the
file does not exist, or cannot be read, then the option will be treated
literally and not removed.
</p>
<p>
Options in the file are separated by whitespace. A whitespace character may be
included in an option by surrounding the entire option in either single or
double quotes. Any character (including a backslash) may be included by
prefixing the character to be included with a backslash. The file may itself
contain additional <tt>@file</tt> options; any such options will be processed
recursively.
</p>
<H3><a name="SWIG_nn3">5.1.1 Input format</a></H3>
<p>
As input, SWIG expects a file containing ANSI C/C++ declarations and
As input, SWIG expects a file containing ISO C/C++ declarations and
special SWIG directives. More often than not, this is a special SWIG
interface file which is usually denoted with a special <tt>.i</tt> or
<tt>.swg</tt> suffix. In certain cases, SWIG can be used directly on
@ -184,7 +270,7 @@ The most common format of a SWIG interface is as follows:
%{
#include "myheader.h"
%}
// Now list ANSI C/C++ declarations
// Now list ISO C/C++ declarations
int foo;
int bar(int x);
...
@ -388,7 +474,7 @@ For example
/* bar not wrapped unless foo has been defined and
the declaration of bar within foo has already been parsed */
int foo::bar(int) {
... whatever ...
... whatever ...
}
</pre>
</div>
@ -479,7 +565,7 @@ Or in Python:
<div class="targetlang"><pre>
&gt;&gt;&gt; example.sin(3)
5.2335956
&gt;&gt;&gt; example.strcmp('Dave','Mike')
&gt;&gt;&gt; example.strcmp('Dave', 'Mike')
-1
&gt;&gt;&gt; print example.cvar.Foo
42
@ -648,7 +734,7 @@ print cvar.foo # Print value of foo
# Perl
$foo = 3.5; # Set foo to 3.5
print $foo,"\n"; # Print value of foo
print $foo, "\n"; # Print value of foo
# Ruby
Module.foo = 3.5 # Set foo to 3.5
@ -749,7 +835,7 @@ form of type-checking however).</p>
<p>
For enumerations, it is critical that the original enum definition be
included somewhere in the interface file (either in a header file or
in the <tt>%{,%}</tt> block). SWIG only translates the enumeration
in the <tt>%{ %}</tt> block). SWIG only translates the enumeration
into code needed to add the constants to a scripting language. It
needs the original enumeration declaration in order to get the correct
enum values as assigned by the C compiler.
@ -1041,15 +1127,15 @@ expect :</p>
<div class="targetlang"><pre>
# Copy a file
def filecopy(source,target):
f1 = fopen(source,"r")
f2 = fopen(target,"w")
buffer = malloc(8192)
nbytes = fread(buffer,8192,1,f1)
while (nbytes &gt; 0):
fwrite(buffer,8192,1,f2)
nbytes = fread(buffer,8192,1,f1)
free(buffer)
def filecopy(source, target):
f1 = fopen(source, "r")
f2 = fopen(target, "w")
buffer = malloc(8192)
nbytes = fread(buffer, 8192, 1, f1)
while (nbytes &gt; 0):
fwrite(buffer, 8192, 1, f2)
nbytes = fread(buffer, 8192, 1, f1)
free(buffer)
</pre></div>
<p>
@ -1235,9 +1321,9 @@ creating a wrapper equivalent to the following:
<div class="code"><pre>
double wrap_dot_product(Vector *a, Vector *b) {
Vector x = *a;
Vector y = *b;
return dot_product(x,y);
Vector x = *a;
Vector y = *b;
return dot_product(x, y);
}
</pre></div>
@ -1265,12 +1351,12 @@ pointers. As a result, SWIG creates a wrapper like this:
<div class="code"><pre>
Vector *wrap_cross_product(Vector *v1, Vector *v2) {
Vector x = *v1;
Vector y = *v2;
Vector *result;
result = (Vector *) malloc(sizeof(Vector));
*(result) = cross(x,y);
return result;
Vector x = *v1;
Vector y = *v2;
Vector *result;
result = (Vector *) malloc(sizeof(Vector));
*(result) = cross(x, y);
return result;
}
</pre></div>
@ -1279,10 +1365,10 @@ or if SWIG was run with the <tt>-c++</tt> option:</p>
<div class="code"><pre>
Vector *wrap_cross(Vector *v1, Vector *v2) {
Vector x = *v1;
Vector y = *v2;
Vector *result = new Vector(cross(x,y)); // Uses default copy constructor
return result;
Vector x = *v1;
Vector y = *v2;
Vector *result = new Vector(cross(x, y)); // Uses default copy constructor
return result;
}
</pre></div>
@ -1357,16 +1443,16 @@ SWIG generates the following code:
<pre>
/* C mode */
void foo_set(char *value) {
if (foo) free(foo);
foo = (char *) malloc(strlen(value)+1);
strcpy(foo,value);
if (foo) free(foo);
foo = (char *) malloc(strlen(value)+1);
strcpy(foo, value);
}
/* C++ mode. When -c++ option is used */
void foo_set(char *value) {
if (foo) delete [] foo;
foo = new char[strlen(value)+1];
strcpy(foo,value);
if (foo) delete [] foo;
foo = new char[strlen(value)+1];
strcpy(foo, value);
}
</pre>
</div>
@ -1381,8 +1467,8 @@ exactly like you want. For example:
<pre>
%inline %{
void set_foo(char *value) {
strncpy(foo,value, 50);
}
strncpy(foo, value, 50);
}
%}
</pre>
</div>
@ -1538,10 +1624,10 @@ a few simple assist functions like this:
<pre>
%inline %{
void a_set(int i, int j, int val) {
a[i][j] = val;
a[i][j] = val;
}
int a_get(int i, int j) {
return a[i][j];
return a[i][j];
}
%}
</pre>
@ -1558,11 +1644,11 @@ some helper functions in your interface. For example:
%inline %{
/* Create any sort of [size] array */
int *int_array(int size) {
return (int *) malloc(size*sizeof(int));
return (int *) malloc(size*sizeof(int));
}
/* Create a two-dimension array [size][10] */
int (*int_array_10(int size))[10] {
return (int (*)[10]) malloc(size*10*sizeof(int));
return (int (*)[10]) malloc(size*10*sizeof(int));
}
%}
</pre>
@ -1587,10 +1673,10 @@ code:
<div class="code">
<pre>
char *pathname_get() {
return pathname;
return pathname;
}
void pathname_set(char *value) {
strncpy(pathname,value,256);
strncpy(pathname, value, 256);
}
</pre>
</div>
@ -1611,9 +1697,9 @@ directive as shown :</p>
int a; // Can read/write
%immutable;
int b,c,d; // Read only variables
int b, c, d; // Read only variables
%mutable;
double x,y; // read/write
double x, y; // read/write
</pre></div>
<p>
@ -1638,7 +1724,7 @@ The <tt>%mutable</tt> and <tt>%immutable</tt> directives are actually
<div class="code"><pre>
#define %immutable %feature("immutable")
#define %mutable %feature("immutable","")
#define %mutable %feature("immutable", "")
</pre></div>
<p>
@ -1647,7 +1733,7 @@ If you wanted to make all wrapped variables read-only, barring one or two, it mi
<div class="code"><pre>
%immutable; // Make all variables read-only
%feature("immutable","0") x; // except, make x read/write
%feature("immutable", "0") x; // except, make x read/write
...
double x;
double y;
@ -1735,6 +1821,16 @@ already defined in the target scripting language. However, if you are
careful about namespaces and your use of modules, you can usually
avoid these problems.</p>
<p>
When wrapping C code, simple use of identifiers/symbols with <tt>%rename</tt> usually suffices.
When wrapping C++ code, simple use of simple identifiers/symbols with <tt>%rename</tt> might be too
limiting when using C++ features such as function overloading, default arguments, namespaces, template specialization etc.
If you are using the <tt>%rename</tt> directive and C++, make sure you read the
<a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a> chapter and in particular the section on
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>
for method overloading and default arguments.
</p>
<p>
Closely related to <tt>%rename</tt> is the <tt>%ignore</tt> directive. <tt>%ignore</tt> instructs SWIG
to ignore declarations that match a given identifier. For example:
@ -2077,7 +2173,7 @@ except those consisting of capital letters only:
<p>
Finally, variants of <tt>%rename</tt> and <tt>%ignore</tt> directives can be used to help
wrap C++ overloaded functions and methods or C++ methods which use default arguments. This is described in the
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a> section in the C++ chapter.
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a> section in the C++ chapter.
</p>
@ -2146,7 +2242,7 @@ used in Tcl as follows :</p>
</pre></div>
<p>
Although the ANSI C standard does not allow default arguments, default
Although the ISO C standard does not allow default arguments, default
arguments specified in a SWIG interface work with both C and C++.
</p>
@ -2166,13 +2262,13 @@ in the C++ chapter for further details.
<p>
Occasionally, a C library may include functions that expect to receive
pointers to functions--possibly to serve as callbacks. SWIG
provides full support for function pointers provided that the callback
provides full support for function pointers when the callback
functions are defined in C and not in the target language. For example,
consider a function like this:
</p>
<div class="code"><pre>
int binary_op(int a, int b, int (*op)(int,int));
int binary_op(int a, int b, int (*op)(int, int));
</pre></div>
<p>
@ -2181,10 +2277,10 @@ may find the function to be impossible to use. For instance, in Python:
</p>
<div class="targetlang"><pre>
&gt;&gt;&gt; def add(x,y):
&gt;&gt;&gt; def add(x, y):
... return x+y
...
&gt;&gt;&gt; binary_op(3,4,add)
&gt;&gt;&gt; binary_op(3, 4, add)
Traceback (most recent call last):
File "&lt;stdin&gt;", line 1, in ?
TypeError: Type error. Expected _p_f_int_int__int
@ -2201,12 +2297,12 @@ One way to do this is to use the <tt>%constant</tt> directive like this:
<div class="code"><pre>
/* Function with a callback */
int binary_op(int a, int b, int (*op)(int,int));
int binary_op(int a, int b, int (*op)(int, int));
/* Some callback functions */
%constant int add(int,int);
%constant int sub(int,int);
%constant int mul(int,int);
%constant int add(int, int);
%constant int sub(int, int);
%constant int mul(int, int);
</pre></div>
<p>
@ -2216,9 +2312,9 @@ constants in the target scripting language. This allows you to use them as foll
<div class="targetlang">
<pre>
&gt;&gt;&gt; binary_op(3,4,add)
&gt;&gt;&gt; binary_op(3, 4, add)
7
&gt;&gt;&gt; binary_op(3,4,mul)
&gt;&gt;&gt; binary_op(3, 4, mul)
12
&gt;&gt;&gt;
</pre>
@ -2231,7 +2327,7 @@ as functions. For example:
<div class="targetlang">
<pre>
&gt;&gt;&gt; add(3,4)
&gt;&gt;&gt; add(3, 4)
Traceback (most recent call last):
File "&lt;stdin&gt;", line 1, in ?
TypeError: object is not callable: '_ff020efc_p_f_int_int__int'
@ -2247,13 +2343,13 @@ can use the <tt>%callback</tt> and <tt>%nocallback</tt> directives like this:
<div class="code">
<pre>
/* Function with a callback */
int binary_op(int a, int b, int (*op)(int,int));
int binary_op(int a, int b, int (*op)(int, int));
/* Some callback functions */
%callback("%s_cb");
int add(int,int);
int sub(int,int);
int mul(int,int);
int add(int, int);
int sub(int, int);
int mul(int, int);
%nocallback;
</pre></div>
@ -2266,13 +2362,13 @@ disabled using <tt>%nocallback</tt>. When you do this, the interface now works
<div class="targetlang">
<pre>
&gt;&gt;&gt; binary_op(3,4,add_cb)
&gt;&gt;&gt; binary_op(3, 4, add_cb)
7
&gt;&gt;&gt; binary_op(3,4,mul_cb)
&gt;&gt;&gt; binary_op(3, 4, mul_cb)
12
&gt;&gt;&gt; add(3,4)
&gt;&gt;&gt; add(3, 4)
7
&gt;&gt;&gt; mul(3,4)
&gt;&gt;&gt; mul(3, 4)
12
</pre>
</div>
@ -2293,9 +2389,9 @@ variation installs the callbacks as all upper case constants such as
<div class="code"><pre>
/* Some callback functions */
%callback("%(uppercase)s");
int add(int,int);
int sub(int,int);
int mul(int,int);
int add(int, int);
int sub(int, int);
int mul(int, int);
%nocallback;
</pre></div>
@ -2310,14 +2406,16 @@ And now, a final note about function pointer support. Although SWIG
does not normally allow callback functions to be written in the target language, this
can be accomplished with the use of typemaps and other advanced SWIG features.
See the <a href="Typemaps.html#Typemaps">Typemaps chapter</a> for more about typemaps
and individual target language chapters for more on callbacks and the 'director' feature.
and individual target language chapters for more on callbacks.
The 'director' feature can be used to make callbacks from C/C++ into the target language,
see <a href="SWIGPlus.html#SWIGPlus_target_language_callbacks">Callbacks to the target language</a>.
</p>
<H2><a name="SWIG_nn31">5.5 Structures and unions</a></H2>
<p>
This section describes the behavior of SWIG when processing ANSI C structures and union declarations. Extensions to
This section describes the behavior of SWIG when processing ISO C structures and union declarations. Extensions to
handle C++ are described in the next section.
</p>
@ -2331,7 +2429,7 @@ to an individual member. For example, the declaration :</p>
<div class="code"><pre>
struct Vector {
double x,y,z;
double x, y, z;
}
</pre></div>
@ -2367,10 +2465,10 @@ defined in the interface. For example:
<div class="code"><pre>
struct Vector *new_Vector() {
return (Vector *) calloc(1,sizeof(struct Vector));
return (Vector *) calloc(1, sizeof(struct Vector));
}
void delete_Vector(struct Vector *obj) {
free(obj);
free(obj);
}
</pre>
</div>
@ -2383,9 +2481,9 @@ language using code like this:
<div class="code">
<pre>
v = new_Vector()
Vector_x_set(v,2)
Vector_y_set(v,10)
Vector_z_set(v,-5)
Vector_x_set(v, 2)
Vector_y_set(v, 10)
Vector_z_set(v, -5)
...
delete_Vector(v)
</pre>
@ -2404,7 +2502,7 @@ programs :</p>
<div class="code"><pre>
typedef struct {
double x,y,z;
double x, y, z;
} Vector;
</pre></div>
@ -2429,7 +2527,7 @@ If two different names are used like this :</p>
<div class="code"><pre>
typedef struct vector_struct {
double x,y,z;
double x, y, z;
} Vector;
</pre></div>
@ -2473,7 +2571,7 @@ char *Foo_name_set(Foo *obj, char *c) {
if (obj-&gt;name)
free(obj-&gt;name);
obj-&gt;name = (char *) malloc(strlen(c)+1);
strcpy(obj-&gt;name,c);
strcpy(obj-&gt;name, c);
return obj-&gt;name;
}
</pre></div>
@ -2521,12 +2619,12 @@ Occasionally, a structure will contain data members that are themselves structur
<div class="code">
<pre>
typedef struct Foo {
int x;
int x;
} Foo;
typedef struct Bar {
int y;
Foo f; /* struct member */
int y;
Foo f; /* struct member */
} Bar;
</pre>
</div>
@ -2540,10 +2638,10 @@ The accessors to the member variable as a pointer are effectively wrapped as fol
<div class="code">
<pre>
Foo *Bar_f_get(Bar *b) {
return &amp;b-&gt;f;
return &amp;b-&gt;f;
}
void Bar_f_set(Bar *b, Foo *value) {
b-&gt;f = *value;
b-&gt;f = *value;
}
</pre>
</div>
@ -2570,7 +2668,7 @@ language interface) results in the following code:
<div class="code">
<pre>
Bar *b;
Foo_x_set(Bar_f_get(b),37);
Foo_x_set(Bar_f_get(b), 37);
</pre>
</div>
@ -2588,7 +2686,7 @@ is a structure or class. For instance, if you had a structure like this,
<div class="code">
<pre>
struct Foo {
WORD w;
WORD w;
};
</pre>
</div>
@ -2601,10 +2699,10 @@ like this:
<div class="code">
<pre>
WORD Foo_w_get(Foo *f) {
return f-&gt;w;
return f-&gt;w;
}
void Foo_w_set(FOO *f, WORD value) {
f-&gt;w = value;
f-&gt;w = value;
}
</pre>
</div>
@ -2726,7 +2824,7 @@ the following declaration :</p>
/* file : vector.h */
...
typedef struct Vector {
double x,y,z;
double x, y, z;
} Vector;
</pre></div>
@ -2759,7 +2857,7 @@ You can make a <tt>Vector</tt> look a lot like a class by writing a SWIG interfa
return sqrt($self-&gt;x*$self-&gt;x+$self-&gt;y*$self-&gt;y+$self-&gt;z*$self-&gt;z);
}
void print() {
printf("Vector [%g, %g, %g]\n", $self-&gt;x,$self-&gt;y,$self-&gt;z);
printf("Vector [%g, %g, %g]\n", $self-&gt;x, $self-&gt;y, $self-&gt;z);
}
};
@ -2779,7 +2877,7 @@ Now, when used with proxy classes in Python, you can do things like
this :</p>
<div class="targetlang"><pre>
&gt;&gt;&gt; v = Vector(3,4,0) # Create a new vector
&gt;&gt;&gt; v = Vector(3, 4, 0) # Create a new vector
&gt;&gt;&gt; print v.magnitude() # Print magnitude
5.0
&gt;&gt;&gt; v.print() # Print it out
@ -2799,7 +2897,7 @@ of the Vector structure. For example:</p>
%}
typedef struct Vector {
double x,y,z;
double x, y, z;
%extend {
Vector(double x, double y, double z) { ... }
~Vector() { ... }
@ -2841,12 +2939,12 @@ double Vector_magnitude(Vector *v) {
%}
typedef struct Vector {
double x,y,z;
double x, y, z;
%extend {
Vector(int,int,int); // This calls new_Vector()
~Vector(); // This calls delete_Vector()
double magnitude(); // This will call Vector_magnitude()
...
Vector(int, int, int); // This calls new_Vector()
~Vector(); // This calls delete_Vector()
double magnitude(); // This will call Vector_magnitude()
...
}
} Vector;
</pre>
@ -2895,7 +2993,7 @@ instead of a method. To do this, you might write some code like this:
<pre>
// Add a new attribute to Vector
%extend Vector {
const double magnitude;
const double magnitude;
}
// Now supply the implementation of the Vector_magnitude_get function
%{
@ -2958,7 +3056,7 @@ char *Person_name_get(Person *p) {
}
void Person_name_set(Person *p, char *val) {
strncpy(p-&gt;name,val,50);
strncpy(p-&gt;name, val, 50);
make_upper(p-&gt;name);
}
%}
@ -3083,7 +3181,7 @@ in terms of high-level accessor functions such as this,
<div class="code">
<pre>
double Vector_x_get(Vector *v) {
return v-&gt;x;
return v-&gt;x;
}
</pre>
</div>
@ -3100,15 +3198,15 @@ the following function is generated instead:
static int
_wrap_Vector_x_get(ClientData clientData, Tcl_Interp *interp,
int objc, Tcl_Obj *CONST objv[]) {
struct Vector *arg1 ;
double result ;
if (SWIG_GetArgs(interp, objc, objv,"p:Vector_x_get self ",&amp;arg0,
SWIGTYPE_p_Vector) == TCL_ERROR)
return TCL_ERROR;
result = (double ) (arg1-&gt;x);
Tcl_SetObjResult(interp,Tcl_NewDoubleObj((double) result));
return TCL_OK;
struct Vector *arg1 ;
double result ;
if (SWIG_GetArgs(interp, objc, objv, "p:Vector_x_get self ", &amp;arg0,
SWIGTYPE_p_Vector) == TCL_ERROR)
return TCL_ERROR;
result = (double ) (arg1-&gt;x);
Tcl_SetObjResult(interp, Tcl_NewDoubleObj((double) result));
return TCL_OK;
}
</pre>
</div>
@ -3139,9 +3237,9 @@ output of SWIG is structured first.</p>
<p>
When SWIG creates its output file, it is broken up into five sections
When SWIG creates its output C/C++ file, it is broken up into five sections
corresponding to runtime code, headers, wrapper functions, and module
initialization code (in that order).
initialization code (in that order).
</p>
<ul>
@ -3175,31 +3273,59 @@ the module upon loading.
<p>
Code is inserted into the appropriate code section by using one
of the code insertion directives listed below. The order of the sections in
the wrapper file is as shown:
The <tt>%insert</tt> directive enables inserting blocks of code into a given section of the generated code.
It can be used in one of two ways:
</p>
<div class="code">
<pre>
%insert("section") "filename"
%insert("section") %{ ... %}
</pre>
</div>
<p>
The first will dump the contents of the file in the given <tt>filename</tt> into the named <tt>section</tt>.
The second inserts the code between the braces into the named <tt>section</tt>.
For example, the following adds code into the runtime section:
</p>
<div class="code">
<pre>
%insert("runtime") %{
... code in runtime section ...
%}
</pre>
</div>
<p>
There are the 5 sections, however, some target languages add in additional sections and some of these result in code being generated into a target language file instead of the C/C++ wrapper file.
These are documented when available in the target language chapters.
Macros named after the code sections are available as additional directives and these macro directives are normally used instead of <tt>%insert</tt>.
For example, <tt>%runtime</tt> is used instead of <tt>%insert("runtime")</tt>.
The valid sections and order of the sections in the generated C/C++ wrapper file is as shown:
</p>
<div class="code">
<pre>
%begin %{
... code in begin section ...
... code in begin section ...
%}
%runtime %{
... code in runtime section ...
... code in runtime section ...
%}
%header %{
... code in header section ...
... code in header section ...
%}
%wrapper %{
... code in wrapper section ...
... code in wrapper section ...
%}
%init %{
... code in init section ...
... code in init section ...
%}
</pre>
</div>
@ -3264,11 +3390,27 @@ Vector *new_Vector() {
return (Vector *) malloc(sizeof(Vector));
}
%}
</pre></div>
<p>
The <tt>%inline</tt> directive inserts all of the code that follows
This is the same as writing:
</p>
<div class="code"><pre>
%{
/* Create a new vector */
Vector *new_Vector() {
return (Vector *) malloc(sizeof(Vector));
}
%}
/* Create a new vector */
Vector *new_Vector() {
return (Vector *) malloc(sizeof(Vector));
}
</pre></div>
<p>
In other words, the <tt>%inline</tt> directive inserts all of the code that follows
verbatim into the header portion of an interface file. The code is
then parsed by both the SWIG preprocessor and parser.
Thus, the above example creates a new command <tt>new_Vector</tt> using only one
@ -3276,6 +3418,11 @@ declaration. Since the code inside an <tt>%inline %{ ... %}</tt> block
is given to both the C compiler and SWIG, it is illegal to include any
SWIG directives inside a <tt>%{ ... %}</tt> block.</p>
<p>
<b>Note:</b> The usual SWIG C preprocessor rules apply to code in <tt>%apply</tt> blocks when SWIG parses this code. For example, as mentioned earlier, <a href="SWIG.html#SWIG_nn6">SWIG's C Preprocessor</a> does not follow <tt>#include</tt> directives by default.
</p>
<H3><a name="SWIG_nn44">5.6.4 Initialization blocks</a></H3>
@ -3322,7 +3469,7 @@ interface to your program.
SWIG's <tt>%include</tt> directive to process an entire C
source/header file.
<li>Make sure everything in the interface file uses ANSI C/C++ syntax.
<li>Make sure everything in the interface file uses ISO C/C++ syntax.
<li>Make sure all necessary `<tt>typedef</tt>' declarations and
type-information is available in the interface file.
@ -3441,7 +3588,7 @@ header files.
<p>
Sometimes, it is necessary to use certain header files in order for
the code generated by SWIG to compile properly. Make sure you
include certain header files by using a <tt>%{,%}</tt> block like this:
include certain header files by using a <tt>%{ %}</tt> block like this:
</p>
<div class="code"><pre>

1689
Doc/Manual/SWIGPlus.html
View file

File diff suppressed because it is too large Load diff

200
Doc/Manual/Scilab.html
View file

@ -9,7 +9,7 @@
<body bgcolor="#ffffff">
<H1><a name="Scilab">39 SWIG and Scilab</a></H1>
<H1><a name="Scilab">35 SWIG and Scilab</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -39,7 +39,7 @@
</ul>
<li><a href="#Scilab_wrapping_pointers">Pointers</a>
<ul>
<li><a href="#Scilab_wrapping_pointers_pointer_adresses">Utility functions</a>
<li><a href="#Scilab_wrapping_pointers_utility_functions">Utility functions</a>
<li><a href="#Scilab_wrapping_pointers_null_pointers">Null pointers:</a>
</ul>
<li><a href="#Scilab_wrapping_structs">Structures</a>
@ -88,11 +88,11 @@ This chapter explains how to use SWIG for Scilab. After this introduction, you s
</p>
<H2><a name="Scilab_preliminaries">39.1 Preliminaries</a></H2>
<H2><a name="Scilab_preliminaries">35.1 Preliminaries</a></H2>
<p>
SWIG for Scilab supports Linux. Other operating sytems haven't been tested.
SWIG for Scilab supports Linux. Other operating systems haven't been tested.
</p>
<p>
@ -105,7 +105,7 @@ SWIG for Scilab supports C language. C++ is partially supported. See <a href="#S
</p>
<H2><a name="Scilab_running_swig">39.2 Running SWIG</a></H2>
<H2><a name="Scilab_running_swig">35.2 Running SWIG</a></H2>
<p>
@ -121,15 +121,15 @@ In this example we bind from C a function and a global variable into Scilab. The
double Foo = 3.0;
int fact(int n) {
if (n &lt; 0) {
return 0;
}
else if (n == 0) {
return 1;
}
else {
return n * fact(n-1);
}
if (n &lt; 0) {
return 0;
}
else if (n == 0) {
return 1;
}
else {
return n * fact(n-1);
}
}
%}
</pre></div>
@ -139,7 +139,7 @@ Note: a code in an <tt>%inline</tt> section is both parsed and wrapped by SWIG,
</p>
<H3><a name="Scilab_running_swig_generating_module">39.2.1 Generating the module</a></H3>
<H3><a name="Scilab_running_swig_generating_module">35.2.1 Generating the module</a></H3>
<p>
@ -182,7 +182,7 @@ The <tt>swig</tt> executable has several other command line options you can use.
</p>
<H3><a name="Scilab_running_swig_building_module">39.2.2 Building the module</a></H3>
<H3><a name="Scilab_running_swig_building_module">35.2.2 Building the module</a></H3>
<p>
@ -202,7 +202,7 @@ $ gcc -shared example_wrap.o -o libexample.so
Note: we supposed in this example that the path to the Scilab include directory is <tt>/usr/local/include/scilab</tt> (which is the case in a Debian environment), this should be changed for another environment.
</p>
<H3><a name="Scilab_running_swig_loading_module">39.2.3 Loading the module</a></H3>
<H3><a name="Scilab_running_swig_loading_module">35.2.3 Loading the module</a></H3>
<p>
@ -226,7 +226,7 @@ Link done.
which means that Scilab has successfully loaded the shared library. The module functions and other symbols are now available in Scilab.
</p>
<H3><a name="Scilab_running_swig_using_module">39.2.4 Using the module</a></H3>
<H3><a name="Scilab_running_swig_using_module">35.2.4 Using the module</a></H3>
<p>
@ -260,7 +260,7 @@ ans =
Note: for conciseness, we assume in the subsequent Scilab code examples that the modules have been beforehand built and loaded in Scilab.
</p>
<H3><a name="Scilab_running_swig_options">39.2.5 Scilab command line options</a></H3>
<H3><a name="Scilab_running_swig_options">35.2.5 Scilab command line options</a></H3>
<p>
@ -304,6 +304,11 @@ The following table lists the Scilab specific command line options in addition t
<td>Generate the gateway XML with the given &lt;gateway_id&gt;</td>
</tr>
<tr>
<td><tt>-targetversion</tt></td>
<td>Generate for Scilab target (major) version</td>
</tr>
</table>
<p>
@ -315,10 +320,10 @@ $ swig -scilab -help
</pre></div>
<H2><a name="Scilab_wrapping">39.3 A basic tour of C/C++ wrapping</a></H2>
<H2><a name="Scilab_wrapping">35.3 A basic tour of C/C++ wrapping</a></H2>
<H3><a name="Scilab_wrapping_overview">39.3.1 Overview</a></H3>
<H3><a name="Scilab_wrapping_overview">35.3.1 Overview</a></H3>
<p>
@ -327,18 +332,22 @@ This means that functions, structs, classes, variables, etc... are interfaced th
There are a few exceptions, such as constants and enumerations, which can be wrapped directly as Scilab variables.
</p>
<H3><a name="Scilab_wrapping_identifiers">39.3.2 Identifiers</a></H3>
<H3><a name="Scilab_wrapping_identifiers">35.3.2 Identifiers</a></H3>
<p>
In Scilab 5.x, identifier names are composed of 24 characters maximum (this limitation should disappear from Scilab 6.0 onwards).
<br>Thus long function or variable names may be truncated and this can cause ambiguities.
In Scilab 5.x, identifier names are composed of 24 characters maximum (this limitation disappears from Scilab 6.0 onwards).
<br>By default, variable, member, and function names longer than 24 characters are truncated, and a warning is produced for each truncation.
</p>
<p>This happens especially when wrapping structs/classes, for which the wrapped function name is composed of the struct/class name and field names.
<p>This can cause ambiguities, especially when wrapping structs/classes, for which the wrapped function name is composed of the struct/class name and field names.
In these cases, the <a href="SWIG.html#SWIG_rename_ignore">%rename directive</a> can be used to choose a different Scilab name.
</p>
<H3><a name="Scilab_wrapping_functions">39.3.3 Functions</a></H3>
<p>
Note: truncations can be disabled by specifying the target version 6 of Scilab in the <tt>targetversion</tt> argument (i.e. <tt>-targetversion 6</tt>).
</p>
<H3><a name="Scilab_wrapping_functions">35.3.3 Functions</a></H3>
<p>
@ -369,7 +378,7 @@ ans =
24.
</pre></div>
<H4><a name="Scilab_nn13">39.3.3.1 Argument passing</a></H4>
<H4><a name="Scilab_nn13">35.3.3.1 Argument passing</a></H4>
<p>
@ -422,7 +431,7 @@ In Scilab, parameters are passed by value. The output (and inout) parameters are
7.
</pre></div>
<H4><a name="Scilab_nn14">39.3.3.2 Multiple output arguments</a></H4>
<H4><a name="Scilab_nn14">35.3.3.2 Multiple output arguments</a></H4>
<p>
@ -443,14 +452,15 @@ The example below shows this for a C function returning 2 values and a result:
int divide(int n, int d, int *OUTPUT, int *OUTPUT);
%{
int divide(int n, int d, int q*, int *r) {
if (d != 0) {
*q = n / d;
*r = n % d;
return 1;
}
else return 0;
}
int divide(int n, int d, int q*, int *r) {
if (d != 0) {
*q = n / d;
*r = n % d;
return 1;
} else {
return 0;
}
}
%}
</pre></div>
@ -470,7 +480,7 @@ int divide(int n, int d, int q*, int *r) {
</pre></div>
<H3><a name="Scilab_wrapping_global_variables">39.3.4 Global variables</a></H3>
<H3><a name="Scilab_wrapping_global_variables">35.3.4 Global variables</a></H3>
<p>
@ -539,10 +549,10 @@ It works the same:</p>
</pre></div>
<H3><a name="Scilab_wrapping_constants_and_enums">39.3.5 Constants and enumerations</a></H3>
<H3><a name="Scilab_wrapping_constants_and_enums">35.3.5 Constants and enumerations</a></H3>
<H4><a name="Scilab_wrapping_constants">39.3.5.1 Constants</a></H4>
<H4><a name="Scilab_wrapping_constants">35.3.5.1 Constants</a></H4>
<p>
@ -683,7 +693,7 @@ are mapped to Scilab variables, with the same name:
3.14
</pre></div>
<H4><a name="Scilab_wrapping_enums">39.3.5.2 Enumerations</a></H4>
<H4><a name="Scilab_wrapping_enums">35.3.5.2 Enumerations</a></H4>
<p>
@ -748,14 +758,14 @@ typedef enum { RED, BLUE, GREEN } color;
</pre></div>
<H3><a name="Scilab_wrapping_pointers">39.3.6 Pointers</a></H3>
<H3><a name="Scilab_wrapping_pointers">35.3.6 Pointers</a></H3>
<p>
Pointers are supported by SWIG. A pointer can be returned from a wrapped C/C++ function, stored in a Scilab variable, and used in input argument of another C/C++ function.
</p>
<p>
Also, thanks to the SWIG runtime which stores informations about types, pointer types are tracked between exchanges Scilab and the native code. Indeed pointer types are stored alongside the pointer adress.
Also, thanks to the SWIG runtime which stores information about types, pointer types are tracked between exchanges Scilab and the native code. Indeed pointer types are stored alongside the pointer address.
A pointer is mapped to a Scilab structure (<a href="https://help.scilab.org/docs/5.5.2/en_US/tlist.html">tlist</a>), which contains as fields the pointer address and the pointer type (in fact a pointer to the type information structure in the SWIG runtime).
<br>
Why a native pointer is not mapped to a Scilab pointer (type name: "pointer", type ID: 128) ? The big advantage of mapping to a <tt>tlist</tt> is that it exposes a new type for the pointer in Scilab, type which can be acessed in Scilab with the <a href="https://help.scilab.org/docs/5.5.2/en_US/typeof.html">typeof</a> function, and manipulated using the <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a> mechanism.
@ -810,7 +820,7 @@ Note: the type name <tt>_p_FILE</tt> which means "pointer to FILE".
The user of a pointer is responsible for freeing it or, like in the example, closing any resources associated with it (just as is required in a C program).
</p>
<H4><a name="Scilab_wrapping_pointers_pointer_adresses">39.3.6.1 Utility functions</a></H4>
<H4><a name="Scilab_wrapping_pointers_utility_functions">35.3.6.1 Utility functions</a></H4>
<p>
@ -851,7 +861,7 @@ ans =
</pre></div>
<H4><a name="Scilab_wrapping_pointers_null_pointers">39.3.6.2 Null pointers:</a></H4>
<H4><a name="Scilab_wrapping_pointers_null_pointers">35.3.6.2 Null pointers:</a></H4>
<p>
@ -867,7 +877,7 @@ Using the previous <tt>SWIG_this()</tt> and <tt>SWIG_ptr()</tt>, it is possible
</pre></div>
<H3><a name="Scilab_wrapping_structs">39.3.7 Structures</a></H3>
<H3><a name="Scilab_wrapping_structs">35.3.7 Structures</a></H3>
<p>
@ -886,8 +896,8 @@ Let's see it on an example of a struct with two members:
%inline %{
typedef struct {
int x;
int arr[4];
int x;
int arr[4];
} Foo;
%}
@ -963,7 +973,7 @@ ans =
</pre></div>
<p>
Note: the pointer to the struct works as described in <a href="Scilab_wrapping_pointers">Pointers</a>. For example, the type of the struct pointer can be get with <tt>typeof</tt>, as following:
Note: the pointer to the struct works as described in <a href="#Scilab_wrapping_pointers">Pointers</a>. For example, the type of the struct pointer can be get with <tt>typeof</tt>, as following:
</p>
<div class="targetlang"><pre>
@ -976,7 +986,7 @@ Note: the pointer to the struct works as described in <a href="Scilab_wrapping_p
--&gt; delete_Bar(b);
</pre></div>
<H3><a name="Scilab_wrapping_cpp_classes">39.3.8 C++ classes</a></H3>
<H3><a name="Scilab_wrapping_cpp_classes">35.3.8 C++ classes</a></H3>
<p>
@ -1027,7 +1037,7 @@ ans =
</pre></div>
<p>
Note: like structs, class pointers are mapped as described in <a href="Scilab_wrapping_pointers">Pointers</a>. Let's give an example which shows that each class pointer type is a new type in Scilab that can be used for example (through <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a>) to implement a custom print for the <tt>Point</tt> class:
Note: like structs, class pointers are mapped as described in <a href="#Scilab_wrapping_pointers">Pointers</a>. Let's give an example which shows that each class pointer type is a new type in Scilab that can be used for example (through <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a>) to implement a custom print for the <tt>Point</tt> class:
</p>
<div class="targetlang"><pre>
@ -1044,7 +1054,7 @@ Note: like structs, class pointers are mapped as described in <a href="Scilab_wr
--&gt; delete_Point(p);
</pre></div>
<H3><a name="Scilab_wrapping_cpp_inheritance">39.3.9 C++ inheritance</a></H3>
<H3><a name="Scilab_wrapping_cpp_inheritance">35.3.9 C++ inheritance</a></H3>
<p>
@ -1119,25 +1129,25 @@ But we can use either use the <tt>get_perimeter()</tt> function of the parent cl
18.84
</pre></div>
<H3><a name="Scilab_wrapping_cpp_overloading">39.3.10 C++ overloading</a></H3>
<H3><a name="Scilab_wrapping_cpp_overloading">35.3.10 C++ overloading</a></H3>
<p>
As explained in <a href="SWIGPlus.html#SWIGPlus_overloaded_methods">6.15</a> SWIG provides support for overloaded functions and constructors.
As explained in <a href="SWIGPlus.html#SWIGPlus_overloaded_methods">Overloaded functions and methods</a> SWIG provides support for overloaded functions and constructors.
</p>
<p>As SWIG knows pointer types, the overloading works also with pointer types, here is is an example with a function <tt>magnify</tt> overloaded for the previous classes <tt>Shape</tt> and <tt>Circle</tt>:
<p>As SWIG knows pointer types, the overloading works also with pointer types, here is an example with a function <tt>magnify</tt> overloaded for the previous classes <tt>Shape</tt> and <tt>Circle</tt>:
</p>
<div class="code"><pre>
%module example
void magnify(Square *square, double factor) {
square-&gt;size *= factor;
square-&gt;size *= factor;
};
void magnify(Circle *circle, double factor) {
square-&gt;radius *= factor;
square-&gt;radius *= factor;
};
</pre></div>
@ -1159,7 +1169,7 @@ void magnify(Circle *circle, double factor) {
</pre></div>
<H3><a name="Scilab_wrapping_pointers_references_values_arrays">39.3.11 Pointers, references, values, and arrays</a></H3>
<H3><a name="Scilab_wrapping_pointers_references_values_arrays">35.3.11 Pointers, references, values, and arrays</a></H3>
<p>
@ -1217,7 +1227,7 @@ All these functions will return a pointer to an instance of <tt>Foo</tt>.
As the function <tt>spam7</tt> returns a value, new instance of <tt>Foo</tt> has to be allocated, and a pointer on this instance is returned.
</p>
<H3><a name="Scilab_wrapping_cpp_templates">39.3.12 C++ templates</a></H3>
<H3><a name="Scilab_wrapping_cpp_templates">35.3.12 C++ templates</a></H3>
<p>
@ -1242,7 +1252,7 @@ struct triplet {
}
};
%template(IntTriplet) triplet&lt;int,int,int&gt;;
%template(IntTriplet) triplet&lt;int, int, int&gt;;
</pre></div>
<p>
@ -1276,7 +1286,7 @@ Then in Scilab:
More details on template support can be found in the <a href="SWIGPlus.html#SWIGPlus_nn30">templates</a> documentation.
</p>
<H3><a name="Scilab_wrapping_cpp_operators">39.3.13 C++ operators</a></H3>
<H3><a name="Scilab_wrapping_cpp_operators">35.3.13 C++ operators</a></H3>
<p>
@ -1320,7 +1330,7 @@ private:
<div class="targetlang"><pre>
--&gt; c1 = new_Complex(3, 7);
--&gt; c2 = Complex_plus(c, new_Complex(1,1));
--&gt; c2 = Complex_plus(c, new_Complex(1, 1));
--&gt; Complex_toDouble(c2)
ans =
@ -1329,7 +1339,7 @@ private:
</pre></div>
<H3><a name="Scilab_wrapping_cpp_namespaces">39.3.14 C++ namespaces</a></H3>
<H3><a name="Scilab_wrapping_cpp_namespaces">35.3.14 C++ namespaces</a></H3>
<p>
@ -1354,7 +1364,7 @@ namespace foo {
}
struct Vector {
double x,y,z;
double x, y, z;
};
};
@ -1407,7 +1417,7 @@ Note: the <a href="SWIGPlus.html#SWIGPlus_nspace">nspace</a> feature is not supp
</p>
<H3><a name="Scilab_wrapping_cpp_exceptions">39.3.15 C++ exceptions</a></H3>
<H3><a name="Scilab_wrapping_cpp_exceptions">35.3.15 C++ exceptions</a></H3>
<p>
@ -1431,7 +1441,7 @@ void throw_exception() throw(char const *) {
<div class="targetlang"><pre>
--&gt;throw_exception()
!--error 999
SWIG/Scilab: Exception (char const *) occured: Bye world !
SWIG/Scilab: Exception (char const *) occurred: Bye world !
</pre></div>
<p>
@ -1448,7 +1458,7 @@ It can be used with the <tt>lasterror()</tt> function as following:
--&gt; lasterror()
ans =
SWIG/Scilab: Exception (char const *) occured: Bye world !
SWIG/Scilab: Exception (char const *) occurred: Bye world !
</pre></div>
<p>
@ -1478,7 +1488,7 @@ void throw_stl_invalid_arg(int i) throw(std::invalid_argument) {
<div class="targetlang"><pre>
--&gt; throw_int();
!--error 999
SWIG/Scilab: Exception (int) occured: 12
SWIG/Scilab: Exception (int) occurred: 12
--&gt;throw_stl_invalid_arg(-1);
!--error 999
@ -1490,17 +1500,17 @@ More complex or custom exception types require specific exception typemaps to be
See the <a href="SWIGPlus.html#SWIGPlus">SWIG C++ documentation</a> for more details.
</p>
<H3><a name="Scilab_wrapping_cpp_stl">39.3.16 C++ STL</a></H3>
<H3><a name="Scilab_wrapping_cpp_stl">35.3.16 C++ STL</a></H3>
<p>
The Standard Template Library (STL) is partially supported. See <a href="#Scilab_typemaps_stl">STL</a> for more details.
</p>
<H2><a name="Scilab_typemaps">39.4 Type mappings and libraries</a></H2>
<H2><a name="Scilab_typemaps">35.4 Type mappings and libraries</a></H2>
<H3><a name="Scilab_typemaps_primitive_types">39.4.1 Default primitive type mappings</a></H3>
<H3><a name="Scilab_typemaps_primitive_types">35.4.1 Default primitive type mappings</a></H3>
<p>
@ -1551,7 +1561,7 @@ The default behaviour is for SWIG to generate code that will give a runtime erro
<H3><a name="Scilab_typemaps_arrays">39.4.2 Arrays</a></H3>
<H3><a name="Scilab_typemaps_arrays">35.4.2 Arrays</a></H3>
<p>
@ -1606,15 +1616,15 @@ void printArray(int values[], int len) {
[ 0 1 2 3 ]
</pre></div>
<H3><a name="Scilab_typemaps_pointer-to-pointers">39.4.3 Pointer-to-pointers</a></H3>
<H3><a name="Scilab_typemaps_pointer-to-pointers">35.4.3 Pointer-to-pointers</a></H3>
<p>
There are no specific typemaps for pointer-to-pointers, they are are mapped as pointers in Scilab.
There are no specific typemaps for pointer-to-pointers, they are mapped as pointers in Scilab.
</p>
<p>
Pointer-to-pointers are sometimes used to implement matrices in C. The following is a an example of this:
Pointer-to-pointers are sometimes used to implement matrices in C. The following is an example of this:
</p>
@ -1635,17 +1645,17 @@ double **create_matrix() {
return M;
}
// Gets the item M(i,j) value
// Gets the item M(i, j) value
double get_matrix(double **M, int i, int j) {
return M[i][j];
}
// Sets the item M(i,j) value to be val
// Sets the item M(i, j) value to be val
void set_matrix(double **M, int i, int j, double val) {
M[i][j] = val;
}
// Prints a matrix (2,2) to console
// Prints a matrix (2, 2) to console
void print_matrix(double **M, int nbRows, int nbCols) {
int i, j;
for (i = 0; i &lt; 2; i++) {
@ -1679,7 +1689,7 @@ void print_matrix(double **M, int nbRows, int nbCols) {
</pre></div>
<H3><a name="Scilab_typemaps_matrices">39.4.4 Matrices</a></H3>
<H3><a name="Scilab_typemaps_matrices">35.4.4 Matrices</a></H3>
<p>
@ -1768,11 +1778,11 @@ void absolute(int *matrix, int matrixNbRow, int matrixNbCol,
The remarks made earlier for arrays also apply here:
</p>
<ul>
<li>The values of matrices in Scilab are column-major orderered,</li>
<li>The values of matrices in Scilab are column-major orderered, </li>
<li>There is no control while converting <tt>double</tt> values to integers, <tt>double</tt> values are truncated without any checking or warning.</li>
</ul>
<H3><a name="Scilab_typemaps_stl">39.4.5 STL</a></H3>
<H3><a name="Scilab_typemaps_stl">35.4.5 STL</a></H3>
<p>
@ -1972,7 +1982,7 @@ ans =
--&gt; delete_PersonPtrSet(p);
</pre></div>
<H2><a name="Scilab_module_initialization">39.5 Module initialization</a></H2>
<H2><a name="Scilab_module_initialization">35.5 Module initialization</a></H2>
<p>
@ -1996,7 +2006,7 @@ For example, to initialize the module <tt>example</tt>:
--&gt; example_Init();
</pre></div>
<H2><a name="Scilab_building_modes">39.6 Building modes</a></H2>
<H2><a name="Scilab_building_modes">35.6 Building modes</a></H2>
<p>
@ -2011,7 +2021,7 @@ To produce a dynamic module, when generating the wrapper, there are two possibil
<li>the <tt>builder</tt> mode. In this mode, Scilab is responsible of building.
</ul>
<H3><a name="Scilab_building_modes_nobuilder_mode">39.6.1 No-builder mode</a></H3>
<H3><a name="Scilab_building_modes_nobuilder_mode">35.6.1 No-builder mode</a></H3>
<p>
@ -2024,7 +2034,7 @@ This mode is the best option to use when you have to integrate the module build
</p>
<H3><a name="Scilab_building_modes_builder_mode">39.6.2 Builder mode</a></H3>
<H3><a name="Scilab_building_modes_builder_mode">35.6.2 Builder mode</a></H3>
<p>
@ -2052,7 +2062,7 @@ In this mode, the following SWIG options may be used to setup the build:
Let's give an example how to build a module <tt>example</tt>, composed of two sources, and using a library dependency:
</p>
<ul>
<li>the sources are <tt>baa1.c</tt> and <tt>baa2.c</tt> (and are stored in in the current directory)</li>
<li>the sources are <tt>baa1.c</tt> and <tt>baa2.c</tt> (and are stored in the current directory)</li>
<li>the library is <tt>libfoo</tt> in <tt>/opt/foo</tt> (headers stored in <tt>/opt/foo/include</tt>, and shared library in <tt>/opt/foo/lib</tt>)</li>
</ul>
@ -2061,17 +2071,17 @@ The command is:
</p>
<div class="shell"><pre>
$ swig -scilab -builder -buildercflags -I/opt/foo/include -builderldflags "-L/opt/foo/lib -lfoo" -buildersources baa1.cxx,baa2.cxx example.i
$ swig -scilab -builder -buildercflags -I/opt/foo/include -builderldflags "-L/opt/foo/lib -lfoo" -buildersources baa1.cxx, baa2.cxx example.i
</pre></div>
<H2><a name="Scilab_generated_scripts">39.7 Generated scripts</a></H2>
<H2><a name="Scilab_generated_scripts">35.7 Generated scripts</a></H2>
<p>
In this part we give some details about the generated Scilab scripts.
</p>
<H3><a name="Scilab_generated_scripts_builder_script">39.7.1 Builder script</a></H3>
<H3><a name="Scilab_generated_scripts_builder_script">35.7.1 Builder script</a></H3>
<p>
@ -2081,12 +2091,12 @@ In this part we give some details about the generated Scilab scripts.
ilib_name = "examplelib";
files = ["example_wrap.c"];
libs = [];
table = ["fact","_wrap_fact";"Foo_set","_wrap_Foo_set";"Foo_get","_wrap_Foo_get";];
ilib_build(ilib_name,table,files,libs);
table = ["fact", "_wrap_fact";"Foo_set", "_wrap_Foo_set";"Foo_get", "_wrap_Foo_get";];
ilib_build(ilib_name, table, files, libs);
</pre></div>
<p>
<tt>ilib_build(lib_name,table,files,libs)</tt> is used to create shared libraries, and to generate a loader file used to dynamically load the shared library into Scilab.
<tt>ilib_build(lib_name, table, files, libs)</tt> is used to create shared libraries, and to generate a loader file used to dynamically load the shared library into Scilab.
</p>
<ul>
@ -2096,7 +2106,7 @@ ilib_build(ilib_name,table,files,libs);
<li><tt><b>table</b></tt>: two column string matrix containing a table of pairs of 'scilab function name', 'C function name'.</li>
</ul>
<H3><a name="Scilab_generated_scripts_loader_script">39.7.2 Loader script</a></H3>
<H3><a name="Scilab_generated_scripts_loader_script">35.7.2 Loader script</a></H3>
<p>
@ -2117,7 +2127,7 @@ list_functions = [ 'fact';
'Foo_set';
'Foo_get';
];
addinter(libexamplelib_path+'/libexamplelib.so','libexamplelib',list_functions);
addinter(libexamplelib_path+'/libexamplelib.so', 'libexamplelib', list_functions);
// remove temp. variables on stack
clear libexamplelib_path;
clear list_functions;
@ -2126,7 +2136,7 @@ clear get_file_path;
</pre></div>
<p>
<tt>addinter(files,spname,fcts)</tt> performs dynamic linking of a compiled C interface function.
<tt>addinter(files, spname, fcts)</tt> performs dynamic linking of a compiled C interface function.
</p>
<ul>
<li><tt><b>files</b></tt>: a character string or a vector of character strings defining the object files (containing the C interface functions) to link with.</li>
@ -2135,7 +2145,7 @@ clear get_file_path;
</ul>
<H2><a name="Scilab_other_resources">39.8 Other resources</a></H2>
<H2><a name="Scilab_other_resources">35.8 Other resources</a></H2>
<ul>

6
Doc/Manual/Scripting.html
View file

@ -135,7 +135,7 @@ int wrap_fact(ClientData clientData, Tcl_Interp *interp, int argc, char *argv[])
}
arg0 = atoi(argv[1]);
result = fact(arg0);
sprintf(interp-&gt;result,"%d", result);
sprintf(interp-&gt;result, "%d", result);
return TCL_OK;
}
@ -247,7 +247,7 @@ representation of a structure. For example,
struct Vector {
Vector();
~Vector();
double x,y,z;
double x, y, z;
};
</pre></div>
@ -302,7 +302,7 @@ class Vector {
public:
Vector();
~Vector();
double x,y,z;
double x, y, z;
};
</pre></div>

25
Doc/Manual/Sections.html
View file

@ -1,14 +1,14 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>SWIG-3.0 Documentation</title>
<title>SWIG-4.0 Documentation</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#ffffff">
<H1><a name="Sections">SWIG-3.0 Documentation</a></H1>
<H1><a name="Sections">SWIG-4.0 Documentation</a></H1>
<p>
Last update : SWIG-3.0.11 (in progress)
Last update : SWIG-4.0.1 (in progress)
</p>
<H2><a name="Sections_Sections">Sections</a></H2>
@ -22,6 +22,8 @@ Last update : SWIG-3.0.11 (in progress)
<li><a href="SWIG.html#SWIG">SWIG Basics</a> (Read this!)</li>
<li><a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a></li>
<li><a href="CPlusPlus11.html#CPlusPlus11">SWIG and C++11</a></li>
<li><a href="CPlusPlus14.html#CPlusPlus14">SWIG and C++14</a></li>
<li><a href="CPlusPlus17.html#CPlusPlus17">SWIG and C++17</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>
@ -29,32 +31,26 @@ Last update : SWIG-3.0.11 (in progress)
<li><a href="Customization.html#Customization">Customization features</a></li>
<li><a href="Contract.html#Contract">Contracts</a></li>
<li><a href="Varargs.html#Varargs">Variable length arguments</a></li>
<li><a href="Doxygen.html#Doxygen">Doxygen documentation comments</a></li>
<li><a href="Warnings.html#Warnings">Warning messages</a></li>
<li><a href="Modules.html#Modules">Working with Modules</a></li>
<li><a href="CCache.html#CCache">Using SWIG with ccache</a></li>
</ul>
<H3><a name="Sections_language_modules">Language Module Documentation</a></H3>
<H3><a name="Sections_language_modules">Supported Language Modules Documentation</a></H3>
<ul>
<li><a href="Allegrocl.html#Allegrocl">Allegro Common Lisp support</a></li>
<li><a href="Android.html#Android">Android support</a></li>
<li><a href="CSharp.html#CSharp">C# support</a></li>
<li><a href="Chicken.html#Chicken">Chicken support</a></li>
<li><a href="D.html#D">D support</a></li>
<li><a href="Go.html#Go">Go support</a></li>
<li><a href="Guile.html#Guile">Guile support</a></li>
<li><a href="Java.html#Java">Java support</a></li>
<li><a href="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>
<li><a href="Mzscheme.html#Mzscheme">MzScheme/Racket support</a></li>
<li><a href="Ocaml.html#Ocaml">Ocaml support</a></li>
<li><a href="Octave.html#Octave">Octave support</a></li>
<li><a href="Perl5.html#Perl5">Perl5 support</a></li>
<li><a href="Php.html#Php">PHP support</a></li>
<li><a href="Pike.html#Pike">Pike support</a></li>
<li><a href="Python.html#Python">Python support</a></li>
<li><a href="R.html#R">R support</a></li>
<li><a href="Ruby.html#Ruby">Ruby support</a></li>
@ -62,6 +58,13 @@ Last update : SWIG-3.0.11 (in progress)
<li><a href="Tcl.html#Tcl">Tcl support</a></li>
</ul>
<H3><a name="Sections_experimental_language_modules">Experimental Language Modules Documentation</a></H3>
<ul>
<li><a href="Mzscheme.html#Mzscheme">MzScheme/Racket support</a></li>
<li><a href="Ocaml.html#Ocaml">OCaml support</a></li>
</ul>
<H3><a name="Sections_developers_docs">Developer Documentation</a></H3>
<ul>

336
Doc/Manual/Tcl.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Tcl">40 SWIG and Tcl</a></H1>
<H1><a name="Tcl">36 SWIG and Tcl</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -84,11 +84,11 @@ 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">40.1 Preliminaries</a></H2>
<H2><a name="Tcl_nn2">36.1 Preliminaries</a></H2>
<p>
To build a Tcl module, run SWIG using the <tt>-tcl</tt> option :
To build a Tcl module, run SWIG using the <tt>-tcl</tt> or <tt>-tcl8</tt> option :
</p>
<div class="code"><pre>
@ -110,7 +110,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">40.1.1 Getting the right header files</a></H3>
<H3><a name="Tcl_nn3">36.1.1 Getting the right header files</a></H3>
<p>
@ -128,7 +128,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">40.1.2 Compiling a dynamic module</a></H3>
<H3><a name="Tcl_nn4">36.1.2 Compiling a dynamic module</a></H3>
<p>
@ -151,7 +151,7 @@ SWIG tries to guess the right options when it is installed. Therefore,
you may want to start with one of the examples in the <tt>SWIG/Examples/tcl</tt>
directory. If that doesn't work, you will need to read the man-pages for
your compiler and linker to get the right set of options. You might also
check the <a href="http://www.dabeaz.com/cgi-bin/wiki.pl">SWIG Wiki</a> for
check the <a href="https://github.com/swig/swig/wiki">SWIG Wiki</a> for
additional information.
</p>
@ -164,7 +164,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">40.1.3 Static linking</a></H3>
<H3><a name="Tcl_nn5">36.1.3 Static linking</a></H3>
<p>
@ -230,7 +230,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">40.1.4 Using your module</a></H3>
<H3><a name="Tcl_nn6">36.1.4 Using your module</a></H3>
<p>
@ -358,7 +358,7 @@ to the default system configuration (this requires root access and you will need
the man pages).
</p>
<H3><a name="Tcl_nn7">40.1.5 Compilation of C++ extensions</a></H3>
<H3><a name="Tcl_nn7">36.1.5 Compilation of C++ extensions</a></H3>
<p>
@ -441,7 +441,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">40.1.6 Compiling for 64-bit platforms</a></H3>
<H3><a name="Tcl_nn8">36.1.6 Compiling for 64-bit platforms</a></H3>
<p>
@ -468,7 +468,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">40.1.7 Setting a package prefix</a></H3>
<H3><a name="Tcl_nn9">36.1.7 Setting a package prefix</a></H3>
<p>
@ -487,7 +487,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">40.1.8 Using namespaces</a></H3>
<H3><a name="Tcl_nn10">36.1.8 Using namespaces</a></H3>
<p>
@ -509,7 +509,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">40.2 Building Tcl/Tk Extensions under Windows 95/NT</a></H2>
<H2><a name="Tcl_nn11">36.2 Building Tcl/Tk Extensions under Windows 95/NT</a></H2>
<p>
@ -520,7 +520,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">40.2.1 Running SWIG from Developer Studio</a></H3>
<H3><a name="Tcl_nn12">36.2.1 Running SWIG from Developer Studio</a></H3>
<p>
@ -578,7 +578,7 @@ MSDOS &gt; tclsh80
%
</pre></div>
<H3><a name="Tcl_nn13">40.2.2 Using NMAKE</a></H3>
<H3><a name="Tcl_nn13">36.2.2 Using NMAKE</a></H3>
<p>
@ -641,7 +641,7 @@ to get you started. With a little practice, you'll be making lots of
Tcl extensions.
</p>
<H2><a name="Tcl_nn14">40.3 A tour of basic C/C++ wrapping</a></H2>
<H2><a name="Tcl_nn14">36.3 A tour of basic C/C++ wrapping</a></H2>
<p>
@ -652,7 +652,7 @@ classes. This section briefly covers the essential aspects of this
wrapping.
</p>
<H3><a name="Tcl_nn15">40.3.1 Modules</a></H3>
<H3><a name="Tcl_nn15">36.3.1 Modules</a></H3>
<p>
@ -686,7 +686,7 @@ To fix this, supply an extra argument to <tt>load</tt> like this:
</pre>
</div>
<H3><a name="Tcl_nn16">40.3.2 Functions</a></H3>
<H3><a name="Tcl_nn16">36.3.2 Functions</a></H3>
<p>
@ -711,7 +711,7 @@ like you think it does:
%
</pre></div>
<H3><a name="Tcl_nn17">40.3.3 Global variables</a></H3>
<H3><a name="Tcl_nn17">36.3.3 Global variables</a></H3>
<p>
@ -791,7 +791,7 @@ extern char *path; // Read-only (due to %immutable)
</pre>
</div>
<H3><a name="Tcl_nn18">40.3.4 Constants and enums</a></H3>
<H3><a name="Tcl_nn18">36.3.4 Constants and enums</a></H3>
<p>
@ -837,8 +837,8 @@ access constants in procedure bodies. For example:
<div class="code">
<pre>
proc blah {} {
global FOO
bar $FOO
global FOO
bar $FOO
}
</pre>
</div>
@ -865,7 +865,7 @@ its actual value or a symbolic identifier name. For example:
<div class="code">
<pre>
proc blah {} {
bar FOO
bar FOO
}
</pre>
</div>
@ -875,7 +875,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">40.3.5 Pointers</a></H3>
<H3><a name="Tcl_nn19">36.3.5 Pointers</a></H3>
<p>
@ -949,16 +949,16 @@ example:
%inline %{
/* C-style cast */
Bar *FooToBar(Foo *f) {
return (Bar *) f;
return (Bar *) f;
}
/* C++-style cast */
Foo *BarToFoo(Bar *b) {
return dynamic_cast&lt;Foo*&gt;(b);
return dynamic_cast&lt;Foo*&gt;(b);
}
Foo *IncrFoo(Foo *f, int i) {
return f+i;
return f+i;
}
%}
</pre>
@ -971,7 +971,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">40.3.6 Structures</a></H3>
<H3><a name="Tcl_nn20">36.3.6 Structures</a></H3>
<p>
@ -981,7 +981,7 @@ This provides a very natural interface. For example,
<div class="code"><pre>
struct Vector {
double x,y,z;
double x, y, z;
};
</pre></div>
@ -1028,12 +1028,12 @@ can also be forced to be read-only using the <tt>%immutable</tt> directive. For
<div class="code">
<pre>
struct Foo {
...
%immutable;
int x; /* Read-only members */
char *name;
%mutable;
...
...
%immutable;
int x; /* Read-only members */
char *name;
%mutable;
...
};
</pre>
</div>
@ -1054,7 +1054,7 @@ example, consider this:
<div class="code">
<pre>
struct Bar {
int x[16];
int x[16];
};
</pre>
</div>
@ -1100,11 +1100,11 @@ pointer. For example, suppose you have two structures like this:
<div class="code">
<pre>
struct Foo {
int a;
int a;
};
struct Bar {
Foo f;
Foo f;
};
</pre>
</div>
@ -1253,7 +1253,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">40.3.7 C++ classes</a></H3>
<H3><a name="Tcl_nn21">36.3.7 C++ classes</a></H3>
<p>
@ -1302,9 +1302,8 @@ To illustrate, suppose you have a class like this:
<pre>
class Spam {
public:
static void foo();
static int bar;
static void foo();
static int bar;
};
</pre>
</div>
@ -1320,7 +1319,7 @@ In Tcl, the static member is accessed as follows:
</pre>
</div>
<H3><a name="Tcl_nn22">40.3.8 C++ inheritance</a></H3>
<H3><a name="Tcl_nn22">36.3.8 C++ inheritance</a></H3>
<p>
@ -1369,7 +1368,7 @@ For instance:
It is safe to use multiple inheritance with SWIG.
</p>
<H3><a name="Tcl_nn23">40.3.9 Pointers, references, values, and arrays</a></H3>
<H3><a name="Tcl_nn23">36.3.9 Pointers, references, values, and arrays</a></H3>
<p>
@ -1423,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">40.3.10 C++ overloaded functions</a></H3>
<H3><a name="Tcl_nn24">36.3.10 C++ overloaded functions</a></H3>
<p>
@ -1457,9 +1456,9 @@ Similarly, if you have a class like this,
<pre>
class Foo {
public:
Foo();
Foo(const Foo &amp;);
...
Foo();
Foo(const Foo &amp;);
...
};
</pre>
</div>
@ -1546,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">40.3.11 C++ operators</a></H3>
<H3><a name="Tcl_nn25">36.3.11 C++ operators</a></H3>
<p>
@ -1648,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">40.3.12 C++ namespaces</a></H3>
<H3><a name="Tcl_nn26">36.3.12 C++ namespaces</a></H3>
<p>
@ -1662,10 +1661,10 @@ submodules or packages. For example, if you have a file like this,
%module example
namespace foo {
int fact(int n);
struct Vector {
double x,y,z;
};
int fact(int n);
struct Vector {
double x, y, z;
};
};
</pre>
</div>
@ -1694,11 +1693,11 @@ For example:
%rename(Bar_spam) Bar::spam;
namespace Foo {
int spam();
int spam();
}
namespace Bar {
int spam();
int spam();
}
</pre>
</div>
@ -1712,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">40.3.13 C++ templates</a></H3>
<H3><a name="Tcl_nn27">36.3.13 C++ templates</a></H3>
<p>
@ -1731,16 +1730,16 @@ For example:
template&lt;class T1, class T2&gt;
struct pair {
typedef T1 first_type;
typedef T2 second_type;
T1 first;
T2 second;
pair();
pair(const T1&amp;, const T2&amp;);
typedef T1 first_type;
typedef T2 second_type;
T1 first;
T2 second;
pair();
pair(const T1&amp;, const T2&amp;);
~pair();
};
%template(pairii) pair&lt;int,int&gt;;
%template(pairii) pair&lt;int, int&gt;;
</pre>
</div>
@ -1764,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">40.3.14 C++ Smart Pointers</a></H3>
<H3><a name="Tcl_nn28">36.3.14 C++ Smart Pointers</a></H3>
<p>
@ -1776,9 +1775,9 @@ that implements <tt>operator-&gt;()</tt> like this:
<div class="code">
<pre>
template&lt;class T&gt; class SmartPtr {
...
T *operator-&gt;();
...
...
T *operator-&gt;();
...
}
</pre>
</div>
@ -1791,8 +1790,8 @@ Then, if you have a class like this,
<pre>
class Foo {
public:
int x;
int bar();
int x;
int bar();
};
</pre>
</div>
@ -1848,7 +1847,7 @@ simply use the <tt>__deref__()</tt> method. For example:
</pre>
</div>
<H2><a name="Tcl_nn29">40.4 Further details on the Tcl class interface</a></H2>
<H2><a name="Tcl_nn29">36.4 Further details on the Tcl class interface</a></H2>
<p>
@ -1861,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">40.4.1 Proxy classes</a></H3>
<H3><a name="Tcl_nn30">36.4.1 Proxy classes</a></H3>
<p>
@ -1874,9 +1873,9 @@ have a class like this
<pre>
class Foo {
public:
int x;
int spam(int);
...
int x;
int spam(int);
...
</pre>
</div>
@ -1887,19 +1886,19 @@ then SWIG transforms it into a set of low-level procedural wrappers. For example
<div class="code">
<pre>
Foo *new_Foo() {
return new Foo();
return new Foo();
}
void delete_Foo(Foo *f) {
delete f;
delete f;
}
int Foo_x_get(Foo *f) {
return f-&gt;x;
return f-&gt;x;
}
void Foo_x_set(Foo *f, int value) {
f-&gt;x = value;
f-&gt;x = value;
}
int Foo_spam(Foo *f, int arg1) {
return f-&gt;spam(arg1);
return f-&gt;spam(arg1);
}
</pre>
</div>
@ -1926,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">40.4.2 Memory management</a></H3>
<H3><a name="Tcl_nn31">36.4.2 Memory management</a></H3>
<p>
@ -1946,8 +1945,8 @@ ownership of the result. For example:
<pre>
class Foo {
public:
Foo();
Foo bar();
Foo();
Foo bar();
};
</pre>
</div>
@ -1976,9 +1975,9 @@ they came from. Therefore, the ownership is set to zero. For example:
<pre>
class Foo {
public:
...
Foo *spam();
...
...
Foo *spam();
...
};
</pre>
</div>
@ -2012,8 +2011,8 @@ or global variable. For example, consider this interface:
%module example
struct Foo {
int value;
Foo *next;
int value;
Foo *next;
};
Foo *head = 0;
@ -2065,10 +2064,10 @@ change the ownership of an object. For instance, consider code like this:
<div class="code">
<pre>
class Node {
Object *value;
Object *value;
public:
void set_value(Object *v) { value = v; }
...
void set_value(Object *v) { value = v; }
...
};
</pre>
</div>
@ -2114,7 +2113,7 @@ typemaps--an advanced topic discussed later.
</p>
<H2><a name="Tcl_nn32">40.5 Input and output parameters</a></H2>
<H2><a name="Tcl_nn32">36.5 Input and output parameters</a></H2>
<p>
@ -2125,7 +2124,7 @@ example:
<div class="code">
<pre>
void add(int x, int y, int *result) {
*result = x + y;
*result = x + y;
}
</pre>
</div>
@ -2137,7 +2136,7 @@ or perhaps
<div class="code">
<pre>
int sub(int *x, int *y) {
return *x+*y;
return *x+*y;
}
</pre>
</div>
@ -2198,7 +2197,7 @@ If a function mutates one of its parameters like this,
<div class="code">
<pre>
void negate(int *x) {
*x = -(*x);
*x = -(*x);
}
</pre>
</div>
@ -2302,7 +2301,7 @@ set c [lindex $dim 1]
</pre>
</div>
<H2><a name="Tcl_nn33">40.6 Exception handling </a></H2>
<H2><a name="Tcl_nn33">36.6 Exception handling </a></H2>
<p>
@ -2328,7 +2327,7 @@ class DoubleArray {
}
// Destroy an array
~DoubleArray() {
delete ptr;
delete ptr;
}
// Return the length of the array
int length() {
@ -2436,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">40.7 Typemaps</a></H2>
<H2><a name="Tcl_nn34">36.7 Typemaps</a></H2>
<p>
@ -2453,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">40.7.1 What is a typemap?</a></H3>
<H3><a name="Tcl_nn35">36.7.1 What is a typemap?</a></H3>
<p>
@ -2466,9 +2465,9 @@ you might define a typemap like this:
%module example
%typemap(in) int {
if (Tcl_GetIntFromObj(interp,$input,&amp;$1) == TCL_ERROR)
return TCL_ERROR;
printf("Received an integer : %d\n",$1);
if (Tcl_GetIntFromObj(interp, $input, &amp;$1) == TCL_ERROR)
return TCL_ERROR;
printf("Received an integer : %d\n", $1);
}
%inline %{
extern int fact(int n);
@ -2505,9 +2504,9 @@ You can refine this by supplying an optional parameter name. For example:
%module example
%typemap(in) int n {
if (Tcl_GetIntFromObj(interp,$input,&amp;$1) == TCL_ERROR)
if (Tcl_GetIntFromObj(interp, $input, &amp;$1) == TCL_ERROR)
return TCL_ERROR;
printf("n = %d\n",$1);
printf("n = %d\n", $1);
}
%inline %{
extern int fact(int n);
@ -2529,9 +2528,9 @@ the typemap system follows <tt>typedef</tt> declarations. For example:
<div class="code">
<pre>
%typemap(in) int n {
if (Tcl_GetIntFromObj(interp,$input,&amp;$1) == TCL_ERROR)
if (Tcl_GetIntFromObj(interp, $input, &amp;$1) == TCL_ERROR)
return TCL_ERROR;
printf("n = %d\n",$1);
printf("n = %d\n", $1);
}
%inline %{
typedef int Integer;
@ -2553,7 +2552,7 @@ Typemaps can also be defined for groups of consecutive arguments. For example:
<div class="code">
<pre>
%typemap(in) (char *str, int len) {
$1 = Tcl_GetStringFromObj($input,&amp;$2);
$1 = Tcl_GetStringFromObj($input, &amp;$2);
};
int count(char c, char *str, int len);
@ -2573,7 +2572,7 @@ parameter is omitted):
</pre>
</div>
<H3><a name="Tcl_nn36">40.7.2 Tcl typemaps</a></H3>
<H3><a name="Tcl_nn36">36.7.2 Tcl typemaps</a></H3>
<p>
@ -2586,7 +2585,7 @@ like this:
<div class="code">
<pre>
%typemap(out) int {
Tcl_SetObjResult(interp,Tcl_NewIntObj($1));
Tcl_SetObjResult(interp, Tcl_NewIntObj($1));
}
</pre>
</div>
@ -2711,7 +2710,7 @@ Initialize an argument to a value before any conversions occur.
Examples of these methods will appear shortly.
</p>
<H3><a name="Tcl_nn37">40.7.3 Typemap variables</a></H3>
<H3><a name="Tcl_nn37">36.7.3 Typemap variables</a></H3>
<p>
@ -2782,7 +2781,7 @@ properly assigned.
The Tcl name of the wrapper function being created.
</div>
<H3><a name="Tcl_nn38">40.7.4 Converting a Tcl list to a char ** </a></H3>
<H3><a name="Tcl_nn38">36.7.4 Converting a Tcl list to a char ** </a></H3>
<p>
@ -2797,36 +2796,36 @@ used as a <tt>char **</tt> object.
// This tells SWIG to treat char ** as a special case
%typemap(in) char ** {
Tcl_Obj **listobjv;
int nitems;
int i;
if (Tcl_ListObjGetElements(interp, $input, &amp;nitems, &amp;listobjv) == TCL_ERROR) {
return TCL_ERROR;
}
$1 = (char **) malloc((nitems+1)*sizeof(char *));
for (i = 0; i &lt; nitems; i++) {
$1[i] = Tcl_GetStringFromObj(listobjv[i],0);
}
$1[i] = 0;
Tcl_Obj **listobjv;
int nitems;
int i;
if (Tcl_ListObjGetElements(interp, $input, &amp;nitems, &amp;listobjv) == TCL_ERROR) {
return TCL_ERROR;
}
$1 = (char **) malloc((nitems+1)*sizeof(char *));
for (i = 0; i &lt; nitems; i++) {
$1[i] = Tcl_GetStringFromObj(listobjv[i], 0);
}
$1[i] = 0;
}
// This gives SWIG some cleanup code that will get called after the function call
%typemap(freearg) char ** {
if ($1) {
free($1);
}
if ($1) {
free($1);
}
}
// Now a test functions
%inline %{
int print_args(char **argv) {
int print_args(char **argv) {
int i = 0;
while (argv[i]) {
printf("argv[%d] = %s\n", i,argv[i]);
i++;
printf("argv[%d] = %s\n", i, argv[i]);
i++;
}
return i;
}
}
%}
%include "tclsh.i"
@ -2844,7 +2843,7 @@ argv[2] = Larry
3
</pre></div>
<H3><a name="Tcl_nn39">40.7.5 Returning values in arguments</a></H3>
<H3><a name="Tcl_nn39">36.7.5 Returning values in arguments</a></H3>
<p>
@ -2855,21 +2854,21 @@ function argument. For example :
<div class="code"><pre>
// A typemap defining how to return an argument by appending it to the result
%typemap(argout) double *outvalue {
Tcl_Obj *o = Tcl_NewDoubleObj($1);
Tcl_ListObjAppendElement(interp,$result,o);
Tcl_Obj *o = Tcl_NewDoubleObj($1);
Tcl_ListObjAppendElement(interp, $result, o);
}
// A typemap telling SWIG to ignore an argument for input
// However, we still need to pass a pointer to the C function
%typemap(in,numinputs=0) double *outvalue (double temp) {
$1 = &amp;temp;
%typemap(in, numinputs=0) double *outvalue (double temp) {
$1 = &amp;temp;
}
// Now a function returning two values
int mypow(double a, double b, double *outvalue) {
if ((a &lt; 0) || (b &lt; 0)) return -1;
*outvalue = pow(a,b);
return 0;
if ((a &lt; 0) || (b &lt; 0)) return -1;
*outvalue = pow(a, b);
return 0;
};
</pre></div>
@ -2886,7 +2885,7 @@ result, a Tcl function using these typemaps will work like this :
%
</pre></div>
<H3><a name="Tcl_nn40">40.7.6 Useful functions</a></H3>
<H3><a name="Tcl_nn40">36.7.6 Useful functions</a></H3>
<p>
@ -2962,7 +2961,7 @@ int Tcl_IsShared(Tcl_Obj *obj);
</pre>
</div>
<H3><a name="Tcl_nn41">40.7.7 Standard typemaps</a></H3>
<H3><a name="Tcl_nn41">36.7.7 Standard typemaps</a></H3>
<p>
@ -2992,7 +2991,7 @@ work)
<div class="code">
<pre>
%typemap(out) int, short, long {
Tcl_SetIntObj($result,(int) $1);
Tcl_SetIntObj($result, (int) $1);
}
</pre>
</div>
@ -3004,10 +3003,10 @@ work)
<div class="code">
<pre>
%typemap(in) float, double {
double temp;
if (Tcl_GetDoubleFromObj(interp, $input, &amp;temp) == TCL_ERROR)
return TCL_ERROR;
$1 = ($1_ltype) temp;
double temp;
if (Tcl_GetDoubleFromObj(interp, $input, &amp;temp) == TCL_ERROR)
return TCL_ERROR;
$1 = ($1_ltype) temp;
}
</pre>
</div>
@ -3017,7 +3016,7 @@ work)
<div class="code">
<pre>
%typemap(out) float, double {
Tcl_SetDoubleObj($result, $1);
Tcl_SetDoubleObj($result, $1);
}
</pre>
</div>
@ -3029,9 +3028,8 @@ work)
<div class="code">
<pre>
%typemap(in) char * {
int len;
$1 = Tcl_GetStringFromObj(interp, &amp;len);
}
int len;
$1 = Tcl_GetStringFromObj(interp, &amp;len);
}
</pre>
</div>
@ -3040,14 +3038,14 @@ work)
<div class="code">
<pre>
%typemap(out,noblock=1,fragment="SWIG_FromCharPtr") char *, const char * {
Tcl_SetObjResult(interp,SWIG_FromCharPtr((const char *)$1));
%typemap(out, noblock=1, fragment="SWIG_FromCharPtr") char *, const char * {
Tcl_SetObjResult(interp, SWIG_FromCharPtr((const char *)$1));
}
</pre>
</div>
<H3><a name="Tcl_nn42">40.7.8 Pointer handling</a></H3>
<H3><a name="Tcl_nn42">36.7.8 Pointer handling</a></H3>
<p>
@ -3090,7 +3088,9 @@ is usually accessed as follows:
<div class="indent">
<pre>
Foo *f;
if (SWIG_ConvertPtr($input, (void **) &amp;f, SWIGTYPE_p_Foo, 0) == -1) return NULL;
if (!SWIG_IsOK(SWIG_ConvertPtr($input, (void **) &amp;f, SWIGTYPE_p_Foo, 0))) {
SWIG_exception_fail(SWIG_TypeError, "in method '$symname', expecting type Foo");
}
Tcl_Obj *;
obj = SWIG_NewPointerObj(f, SWIGTYPE_p_Foo, 0);
@ -3105,7 +3105,9 @@ variable <tt>$1_descriptor</tt>. For example:
<div class="indent">
<pre>
%typemap(in) Foo * {
if ((SWIG_ConvertPtr($input,(void **) &amp;$1, $1_descriptor,0)) == -1) return NULL;
if (!SWIG_IsOK(SWIG_ConvertPtr($input, (void **) &amp;$1, $1_descriptor, 0))) {
SWIG_exception_fail(SWIG_TypeError, "in method '$symname', expecting type Foo");
}
}
</pre>
</div>
@ -3118,12 +3120,14 @@ For example:
<div class="indent">
<pre>
%typemap(in) Foo * {
if ((SWIG_ConvertPtr($input,(void **) &amp;$1, $descriptor(Foo *), 0)) == -1) return NULL;
if (!SWIG_IsOK(SWIG_ConvertPtr($input, (void **) &amp;$1, $descriptor(Foo *), 0))) {
SWIG_exception_fail(SWIG_TypeError, "in method '$symname', expecting type Foo");
}
}
</pre>
</div>
<H2><a name="Tcl_nn43">40.8 Turning a SWIG module into a Tcl Package.</a></H2>
<H2><a name="Tcl_nn43">36.8 Turning a SWIG module into a Tcl Package.</a></H2>
<p>
@ -3195,7 +3199,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">40.9 Building new kinds of Tcl interfaces (in Tcl)</a></H2>
<H2><a name="Tcl_nn44">36.9 Building new kinds of Tcl interfaces (in Tcl)</a></H2>
<p>
@ -3211,28 +3215,28 @@ helper functions to access arrays :
%inline %{
double *new_double(int size) {
return (double *) malloc(size*sizeof(double));
return (double *) malloc(size*sizeof(double));
}
void delete_double(double *a) {
free(a);
free(a);
}
double get_double(double *a, int index) {
return a[index];
return a[index];
}
void set_double(double *a, int index, double val) {
a[index] = val;
a[index] = val;
}
int *new_int(int size) {
return (int *) malloc(size*sizeof(int));
return (int *) malloc(size*sizeof(int));
}
void delete_int(int *a) {
free(a);
free(a);
}
int get_int(int *a, int index) {
return a[index];
return a[index];
}
int set_int(int *a, int index, int val) {
a[index] = val;
a[index] = val;
}
%}
@ -3294,7 +3298,7 @@ danger of blowing something up (although it is easily accomplished
with an out of bounds array access).
</p>
<H3><a name="Tcl_nn45">40.9.1 Proxy classes</a></H3>
<H3><a name="Tcl_nn45">36.9.1 Proxy classes</a></H3>
<p>
@ -3415,7 +3419,7 @@ short, but clever Tcl script can be combined with SWIG to do many
interesting things.
</p>
<H2><a name="Tcl_nn46">40.10 Tcl/Tk Stubs</a></H2>
<H2><a name="Tcl_nn46">36.10 Tcl/Tk Stubs</a></H2>
<p>

1197
Doc/Manual/Typemaps.html
View file

File diff suppressed because it is too large Load diff

149
Doc/Manual/Varargs.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Varargs">14 Variable Length Arguments</a></H1>
<H1><a name="Varargs">16 Variable Length Arguments</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -43,7 +43,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">14.1 Introduction</a></H2>
<H2><a name="Varargs_nn2">16.1 Introduction</a></H2>
<p>
@ -95,7 +95,7 @@ int execlp(const char *path, const char *arg1, ...);
...
/* Example */
execlp("ls","ls","-l",NULL);
execlp("ls", "ls", "-l", NULL);
</pre>
</div>
@ -126,21 +126,21 @@ example:
<div class="code">
<pre>
List make_list(const char *s, ...) {
va_list ap;
List x;
...
va_start(ap, s);
while (s) {
x.append(s);
s = va_arg(ap, const char *);
}
va_end(ap);
return x;
va_list ap;
List x;
...
va_start(ap, s);
while (s) {
x.append(s);
s = va_arg(ap, const char *);
}
va_end(ap);
return x;
}
</pre>
</div>
<H2><a name="Varargs_nn3">14.2 The Problem</a></H2>
<H2><a name="Varargs_nn3">16.2 The Problem</a></H2>
<p>
@ -188,12 +188,12 @@ In contrast, suppose you attempted to make some kind of wrapper around
<div class="code">
<pre>
int wrap_printf(const char *fmt, ...) {
va_list ap;
va_start(ap,fmt);
...
printf(fmt,ap);
...
va_end(ap);
va_list ap;
va_start(ap, fmt);
...
printf(fmt, ap);
...
va_end(ap);
};
</pre>
</div>
@ -233,7 +233,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">14.3 Default varargs support</a></H2>
<H2><a name="Varargs_nn4">16.3 Default varargs support</a></H2>
<p>
@ -302,7 +302,7 @@ Read on for further solutions.
</p>
<H2><a name="Varargs_nn5">14.4 Argument replacement using %varargs</a></H2>
<H2><a name="Varargs_nn5">16.4 Argument replacement using %varargs</a></H2>
<p>
@ -413,7 +413,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">14.5 Varargs and typemaps</a></H2>
<H2><a name="Varargs_nn6">16.5 Varargs and typemaps</a></H2>
<p>
@ -423,8 +423,8 @@ Variable length arguments may be used in typemap specifications. For example:
<div class="code">
<pre>
%typemap(in) (...) {
// Get variable length arguments (somehow)
...
// Get variable length arguments (somehow)
...
}
%typemap(in) (const char *fmt, ...) {
@ -471,15 +471,15 @@ like this:
<div class="code">
<pre>
wrap_printf() {
char *arg1;
void *arg2;
int result;
char *arg1;
void *arg2;
int result;
arg1 = "%s";
arg2 = (void *) PyString_AsString(arg2obj);
...
result = printf(arg1,arg2);
...
arg1 = "%s";
arg2 = (void *) PyString_AsString(arg2obj);
...
result = printf(arg1, arg2);
...
}
</pre>
</div>
@ -517,7 +517,7 @@ like this:
argc = PyTuple_Size(varargs);
if (argc &gt; 10) {
PyErr_SetString(PyExc_ValueError, "Too many arguments");
return NULL;
SWIG_fail;
}
for (i = 0; i &lt; argc; i++) {
PyObject *pyobj = PyTuple_GetItem(varargs, i);
@ -525,16 +525,19 @@ like this:
%#if PY_VERSION_HEX&gt;=0x03000000
PyObject *pystr;
if (!PyUnicode_Check(pyobj)) {
PyErr_SetString(PyExc_ValueError, "Expected a string");
return NULL;
PyErr_SetString(PyExc_ValueError, "Expected a string");
SWIG_fail;
}
pystr = PyUnicode_AsUTF8String(pyobj);
if (!pystr) {
SWIG_fail;
}
str = strdup(PyBytes_AsString(pystr));
Py_XDECREF(pystr);
Py_DECREF(pystr);
%#else
if (!PyString_Check(pyobj)) {
PyErr_SetString(PyExc_ValueError, "Expected a string");
return NULL;
PyErr_SetString(PyExc_ValueError, "Expected a string");
SWIG_fail;
}
str = PyString_AsString(pyobj);
%#endif
@ -590,7 +593,7 @@ really want to elevate your guru status and increase your job
security, continue to the next section.
</p>
<H2><a name="Varargs_nn7">14.6 Varargs wrapping with libffi</a></H2>
<H2><a name="Varargs_nn7">16.6 Varargs wrapping with libffi</a></H2>
<p>
@ -626,23 +629,23 @@ example. For example:
of strings */
%typemap(in) (...) {
char **argv;
int argc;
int i;
char **argv;
int argc;
int i;
argc = PyTuple_Size(varargs);
argv = (char **) malloc(sizeof(char *)*(argc+1));
for (i = 0; i &lt; argc; i++) {
PyObject *o = PyTuple_GetItem(varargs,i);
if (!PyString_Check(o)) {
PyErr_SetString(PyExc_ValueError,"Expected a string");
free(argv);
return NULL;
}
argv[i] = PyString_AsString(o);
}
argv[i] = NULL;
$1 = (void *) argv;
argc = PyTuple_Size(varargs);
argv = (char **) malloc(sizeof(char *)*(argc+1));
for (i = 0; i &lt; argc; i++) {
PyObject *o = PyTuple_GetItem(varargs, i);
if (!PyString_Check(o)) {
free(argv);
PyErr_SetString(PyExc_ValueError, "Expected a string");
SWIG_fail;
}
argv[i] = PyString_AsString(o);
}
argv[i] = NULL;
$1 = (void *) argv;
}
/* Rewrite the function call, using libffi */
@ -676,11 +679,11 @@ example. For example:
&amp;ffi_type_uint, types) == FFI_OK) {
ffi_call(&amp;cif, (void (*)()) execlp, &amp;result, values);
} else {
PyErr_SetString(PyExc_RuntimeError, "Whoa!!!!!");
free(types);
free(values);
free(arg3);
return NULL;
PyErr_SetString(PyExc_RuntimeError, "Whoa!!!!!");
SWIG_fail;
}
free(types);
free(values);
@ -733,7 +736,7 @@ As a more extreme example of libffi, here is some code that attempts to wrap <tt
argc = PyTuple_Size(varargs);
argv = (vtype *) malloc(argc*sizeof(vtype));
for (i = 0; i &lt; argc; i++) {
PyObject *o = PyTuple_GetItem(varargs,i);
PyObject *o = PyTuple_GetItem(varargs, i);
if (PyInt_Check(o)) {
argv[i].type = VT_INT;
argv[i].val.ivalue = PyInt_AsLong(o);
@ -744,8 +747,8 @@ As a more extreme example of libffi, here is some code that attempts to wrap <tt
argv[i].type = VT_POINTER;
argv[i].val.pvalue = (void *) PyString_AsString(o);
} else {
PyErr_SetString(PyExc_ValueError,"Unsupported argument type");
free(argv);
PyErr_SetString(PyExc_ValueError, "Unsupported argument type");
return NULL;
}
}
@ -793,11 +796,11 @@ As a more extreme example of libffi, here is some code that attempts to wrap <tt
&amp;ffi_type_uint, types) == FFI_OK) {
ffi_call(&amp;cif, (void (*)()) printf, &amp;result, values);
} else {
PyErr_SetString(PyExc_RuntimeError, "Whoa!!!!!");
free(types);
free(values);
free(args);
return NULL;
PyErr_SetString(PyExc_RuntimeError, "Whoa!!!!!");
SWIG_fail;
}
free(types);
free(values);
@ -842,7 +845,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">14.7 Wrapping of va_list</a></H2>
<H2><a name="Varargs_nn8">16.7 Wrapping of va_list</a></H2>
<p>
@ -896,7 +899,7 @@ int my_vprintf(const char *fmt, ...) {
</pre>
</div>
<H2><a name="Varargs_nn9">14.8 C++ Issues</a></H2>
<H2><a name="Varargs_nn9">16.8 C++ Issues</a></H2>
<p>
@ -912,12 +915,12 @@ and it fully supports classes much like the <tt>%rename</tt> directive. For exa
class Foo {
public:
virtual void bar(char *arg, ...); // gets varargs above
virtual void bar(char *arg, ...); // gets varargs above
};
class Spam: public Foo {
public:
virtual void bar(char *arg, ...); // gets varargs above
virtual void bar(char *arg, ...); // gets varargs above
};
</pre>
</div>
@ -952,9 +955,9 @@ are placed in <tt>arg2</tt>, <tt>arg3</tt>, and so forth. For example:
<div class="code">
<pre>
%feature("action") Foo::bar {
...
result = arg1-&gt;bar(arg2, arg3, etc.);
...
...
result = arg1-&gt;bar(arg2, arg3, etc.);
...
}
</pre>
</div>
@ -965,7 +968,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">14.9 Discussion</a></H2>
<H2><a name="Varargs_nn10">16.9 Discussion</a></H2>
<p>
@ -987,10 +990,10 @@ you might structure your interface like this:
<div class="code">
<pre>
%typemap(const char *fmt, ...) {
...
...
}
%feature("action") traceprintf {
...
...
}
/* Include some header file with traceprintf in it */
@ -1011,7 +1014,7 @@ to control this:
<pre>
#ifdef USE_LIBFFI
%feature("action") printf {
...
...
}
#endif
#ifdef USE_OTHERFFI

68
Doc/Manual/Warnings.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Warnings">15 Warning Messages</a></H1>
<H1><a name="Warnings">18 Warning Messages</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -25,7 +25,8 @@
<li><a href="#Warnings_nn11">Preprocessor (200-299)</a>
<li><a href="#Warnings_nn12">C/C++ Parser (300-399)</a>
<li><a href="#Warnings_nn13">Types and typemaps (400-499) </a>
<li><a href="#Warnings_nn14">Code generation (500-599)</a>
<li><a href="#Warnings_nn14">Code generation (500-559)</a>
<li><a href="#Warnings_doxygen">Doxygen comments (560-599)</a>
<li><a href="#Warnings_nn15">Language module specific (700-899) </a>
<li><a href="#Warnings_nn16">User defined (900-999)</a>
</ul>
@ -36,7 +37,7 @@
<H2><a name="Warnings_nn2">15.1 Introduction</a></H2>
<H2><a name="Warnings_nn2">18.1 Introduction</a></H2>
<p>
@ -56,7 +57,7 @@ where the generated wrapper code will probably compile, but it may not
work like you expect.
</p>
<H2><a name="Warnings_suppression">15.2 Warning message suppression</a></H2>
<H2><a name="Warnings_suppression">18.2 Warning message suppression</a></H2>
<p>
@ -112,16 +113,16 @@ suppress a warning for a method in a class hierarchy, you could do this:
%warnfilter(501) Object::foo;
class Object {
public:
int foo(int);
int foo(double); // Silently ignored
...
int foo(int);
int foo(double); // Silently ignored
...
};
class Derived : public Object {
public:
int foo(int);
int foo(double); // Silently ignored
...
int foo(int);
int foo(double); // Silently ignored
...
};
</pre>
</div>
@ -136,7 +137,7 @@ Warnings can be suppressed for an entire class by supplying a class name. For e
class Object {
public:
... // All 501 warnings ignored in class
... // All 501 warnings ignored in class
};
</pre>
</div>
@ -148,7 +149,7 @@ your interface. Ignore the warning messages at your own peril.
</p>
<H2><a name="Warnings_nn4">15.3 Enabling extra warnings</a></H2>
<H2><a name="Warnings_nn4">18.3 Enabling extra warnings</a></H2>
<p>
@ -221,7 +222,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">15.4 Issuing a warning message</a></H2>
<H2><a name="Warnings_nn5">18.4 Issuing a warning message</a></H2>
<p>
@ -259,7 +260,7 @@ Warning messages can be associated with typemaps using the
<div class="code">
<pre>
%typemap(in, warning="901:You are really going to regret this usage of $1_type $1_name") blah * {
...
...
}
</pre>
</div>
@ -275,7 +276,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">15.5 Symbolic symbols</a></H2>
<H2><a name="Warnings_symbolic_symbols">18.5 Symbolic symbols</a></H2>
<p>
@ -310,7 +311,7 @@ or
</pre>
</div>
<H2><a name="Warnings_nn6">15.6 Commentary</a></H2>
<H2><a name="Warnings_nn6">18.6 Commentary</a></H2>
<p>
@ -327,7 +328,7 @@ no obvious recovery. There is no mechanism for suppressing error
messages.
</p>
<H2><a name="Warnings_nn7">15.7 Warnings as errors</a></H2>
<H2><a name="Warnings_nn7">18.7 Warnings as errors</a></H2>
<p>
@ -336,7 +337,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">15.8 Message output format</a></H2>
<H2><a name="Warnings_nn8">18.8 Message output format</a></H2>
<p>
@ -355,10 +356,10 @@ $ swig -python -Fmicrosoft example.i
example.i(4) : Syntax error in input(1).
</pre></div>
<H2><a name="Warnings_nn9">15.9 Warning number reference</a></H2>
<H2><a name="Warnings_nn9">18.9 Warning number reference</a></H2>
<H3><a name="Warnings_nn10">15.9.1 Deprecated features (100-199)</a></H3>
<H3><a name="Warnings_nn10">18.9.1 Deprecated features (100-199)</a></H3>
<ul>
@ -386,7 +387,7 @@ example.i(4) : Syntax error in input(1).
<li>126. The 'nestedworkaround' feature is deprecated.
</ul>
<H3><a name="Warnings_nn11">15.9.2 Preprocessor (200-299)</a></H3>
<H3><a name="Warnings_nn11">18.9.2 Preprocessor (200-299)</a></H3>
<ul>
@ -398,7 +399,7 @@ example.i(4) : Syntax error in input(1).
<li>206. Unexpected tokens after #<em>directive</em> directive.
</ul>
<H3><a name="Warnings_nn12">15.9.3 C/C++ Parser (300-399)</a></H3>
<H3><a name="Warnings_nn12">18.9.3 C/C++ Parser (300-399)</a></H3>
<ul>
@ -475,7 +476,7 @@ example.i(4) : Syntax error in input(1).
<li>395. operator delete[] ignored.
</ul>
<H3><a name="Warnings_nn13">15.9.4 Types and typemaps (400-499) </a></H3>
<H3><a name="Warnings_nn13">18.9.4 Types and typemaps (400-499) </a></H3>
<ul>
@ -506,7 +507,7 @@ example.i(4) : Syntax error in input(1).
<H3><a name="Warnings_nn14">15.9.5 Code generation (500-599)</a></H3>
<H3><a name="Warnings_nn14">18.9.5 Code generation (500-559)</a></H3>
<ul>
@ -533,9 +534,22 @@ example.i(4) : Syntax error in input(1).
<li>521. Illegal destructor name <em>name</em>. Ignored.
<li>522. Use of an illegal constructor name '<em>name</em>' in %extend is deprecated, the constructor name should be '<em>name</em>'.
<li>523. Use of an illegal destructor name '<em>name</em>' in %extend is deprecated, the destructor name should be '<em>name</em>'.
<li>524. Experimental target language. Target language <em>language</em> specified by <em>lang</em> is an experimental language. Please read about SWIG experimental languages, <em>htmllink</em>.
<li>525. Destructor <em>declaration</em> is final, <em>name</em> cannot be a director class.
</ul>
<H3><a name="Warnings_nn15">15.9.6 Language module specific (700-899) </a></H3>
<H3><a name="Warnings_doxygen">18.9.6 Doxygen comments (560-599)</a></H3>
<ul>
<li>560: Unknown Doxygen command: <em>command</em>.</li>
<li>561: Unexpected end of Doxygen comment encountered.</li>
<li>562: Expected Doxygen command: <em>command</em></li>
<li>563: Doxygen HTML error for tag <em>tag</em>: <em>error text</em>.</li>
<li>564: Error parsing Doxygen command <em>command</em>: <em>error text</em>. Command ignored."</li>
</ul>
<H3><a name="Warnings_nn15">18.9.7 Language module specific (700-899) </a></H3>
<ul>
@ -586,14 +600,14 @@ example.i(4) : Syntax error in input(1).
<li>871. Unrecognized pragma <em>pragma</em>. (Php).
</ul>
<H3><a name="Warnings_nn16">15.9.7 User defined (900-999)</a></H3>
<H3><a name="Warnings_nn16">18.9.8 User defined (900-999)</a></H3>
<p>
These numbers can be used by your own application.
</p>
<H2><a name="Warnings_nn17">15.10 History</a></H2>
<H2><a name="Warnings_nn17">18.10 History</a></H2>
<p>

8
Doc/Manual/Windows.html
View file

@ -68,7 +68,7 @@ SWIG does not come with the usual Windows type installation program, however it
<p>
The swigwin distribution contains the SWIG Windows executable, swig.exe, which will run on 32 bit versions of Windows, ie Windows 95 and later.
The swigwin distribution contains the SWIG Windows 32-bit executable, swig.exe, which will run on both 32-bit and 64-bit versions of Windows.
If you want to build your own swig.exe have a look at <a href="#Windows_swig_exe">Building swig.exe on Windows</a>.
</p>
@ -149,7 +149,7 @@ PERL5_LIB: D:\nsPerl5.004_04\lib\CORE\perl.lib<br>
<p>
<b><tt>PYTHON_INCLUDE</tt></b> : Set this to the directory that contains Python.h<br>
<b><tt>PYTHON_LIB</tt></b> : Set this to the python library including path for linking<p>
<b><tt>PYTHON_LIB</tt></b> : Set this to the Python library including path for linking<p>
Example using Python 2.1.1:<br>
<tt>
PYTHON_INCLUDE: D:\python21\include<br>
@ -211,7 +211,7 @@ If you do not have access to Visual C++ you will have to set up project files /
<p>
SWIG can also be compiled and run using <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> which provides a Unix like front end to Windows and comes free with gcc, an ANSI C/C++ compiler. However, this is not a recommended approach as the prebuilt executable is supplied.
SWIG can also be compiled and run using <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> which provides a Unix like front end to Windows and comes free with gcc, an ISO C/C++ compiler. However, this is not a recommended approach as the prebuilt executable is supplied.
</p>
<H3><a name="Windows_swig_exe">3.3.1 Building swig.exe on Windows</a></H3>
@ -249,7 +249,7 @@ Execute the steps in the order shown and don't use spaces in path names. In fact
<ol>
<li>
Download the following packages from the <a href="http://www.mingw.org/download.shtml">MinGW download page</a>
or <a href="http://sourceforge.net/projects/mingw/files/">MinGW SourceForge download page</a>.
or <a href="https://sourceforge.net/projects/mingw/files/">MinGW SourceForge download page</a>.
Note that at the time of writing, the majority of these are in the Current
release list and some are in the Snapshot or Previous release list.
<ul>

12
Doc/Manual/chapters
View file

@ -5,6 +5,8 @@ Scripting.html
SWIG.html
SWIGPlus.html
CPlusPlus11.html
CPlusPlus14.html
CPlusPlus17.html
Preprocessor.html
Library.html
Arguments.html
@ -12,31 +14,27 @@ Typemaps.html
Customization.html
Contract.html
Varargs.html
Doxygen.html
Warnings.html
Modules.html
CCache.html
Allegrocl.html
Android.html
C.html
CSharp.html
Chicken.html
D.html
Go.html
Guile.html
Java.html
Javascript.html
Lisp.html
Lua.html
Modula3.html
Mzscheme.html
Ocaml.html
Octave.html
Perl5.html
Php.html
Pike.html
Python.html
R.html
Ruby.html
Scilab.html
Tcl.html
Mzscheme.html
Ocaml.html
Extending.html

4
Doc/Manual/index.html
View file

@ -1,11 +1,11 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>SWIG-3.0 Documentation</title>
<title>SWIG-4.0 Documentation</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#ffffff">
<H1><a name="index">SWIG-3.0 Documentation</a></H1>
<H1><a name="index">SWIG-4.0 Documentation</a></H1>
The SWIG documentation is available in one of the following formats.
<ul>

4
Doc/Manual/makechap.py
View file

@ -44,6 +44,8 @@ def getheadingname(m):
def getheadingtext(m, s):
prevheadingtext_newstyle = m.group(2)
prevheadingtext_oldstyle = m.group(3)
if prevheadingtext_oldstyle is None or prevheadingtext_newstyle is None:
raise RuntimeError("Ill-formed heading in line:\n%s" % s)
if len(prevheadingtext_oldstyle) == 0 and len(prevheadingtext_newstyle) == 0:
raise RuntimeError("No heading text in line:\n%s" % s)
if len(prevheadingtext_oldstyle) > 0 and len(prevheadingtext_newstyle) > 0:
@ -72,7 +74,7 @@ name = ""
# Regexs for <h1>,... <h5> sections
h1 = re.compile(r".*?<H1>(<a.*?>\s*[\d\s]*(.*?)</a>)*[\d\s]*(.*?)</H1>", re.IGNORECASE)
h1 = re.compile(r".*?<H1>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H1>", re.IGNORECASE)
h2 = re.compile(r".*?<H2>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H2>", re.IGNORECASE)
h3 = re.compile(r".*?<H3>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H3>", re.IGNORECASE)
h4 = re.compile(r".*?<H4>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H4>", re.IGNORECASE)

530
Examples/Makefile.in
View file

@ -282,7 +282,7 @@ perl5_static_cpp: $(SRCDIR_SRCS)
# -----------------------------------------------------------------
perl5_run:
$(RUNTOOL) $(PERL) $(PERL5_SCRIPT) $(RUNPIPE)
$(RUNTOOL) $(PERL) -I. $(PERL5_SCRIPT) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
@ -334,8 +334,8 @@ else
SWIGOPTPY3 = -py3
endif
PEP8 = @PEP8@
PEP8_FLAGS = --ignore=E402,E501,E30,W291,W391
PYCODESTYLE = @PYCODESTYLE@
PYCODESTYLE_FLAGS = --ignore=E252,E30,E402,E501,E731,W291,W391
# ----------------------------------------------------------------
# Build a C dynamically loadable module
@ -386,11 +386,11 @@ else
PYSCRIPT = $(RUNME)3.py
endif
PY2TO3 = 2to3 `2to3 -l | grep -v -E "Available|import$$" | awk '{print "-f "$$0}'`
PY2TO3 = @PY2TO3@ `@PY2TO3@ -l | grep -v -E "Available|import$$" | awk '{print "-f "$$0}'`
python_run: $(PYSCRIPT)
ifneq (,$(PEP8))
$(COMPILETOOL) $(PEP8) $(PEP8_FLAGS) $(PYSCRIPT)
ifneq (,$(PYCODESTYLE))
$(COMPILETOOL) $(PYCODESTYLE) $(PYCODESTYLE_FLAGS) $(PYSCRIPT)
endif
env PYTHONPATH=$$PWD $(RUNTOOL) $(PYTHON) $(PYSCRIPT) $(RUNPIPE)
@ -463,7 +463,7 @@ octave_cpp: $(SRCDIR_SRCS)
# -----------------------------------------------------------------
octave_run:
OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE) $(OCTAVE_SCRIPT) $(RUNPIPE)
env OCTAVE_PATH= OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE) $(OCTAVE_SCRIPT) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
@ -671,7 +671,7 @@ javascript_build: $(SRCDIR_SRCS)
javascript_build_cpp: $(SRCDIR_SRCS)
ifeq (node,$(JSENGINE))
sed -e 's|$$srcdir|./$(SRCDIR)|g' $(SRCDIR)binding.gyp.in > binding.gyp
$(NODEGYP) --loglevel=silent configure build 1>>/dev/null
MAKEFLAGS= $(NODEGYP) --loglevel=silent configure build 1>>/dev/null
else
$(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES) $(JSINCLUDES)
$(CXXSHARED) $(CXXFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(JSDYNAMICLINKING) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
@ -805,45 +805,6 @@ android_clean:
rm -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
rm -rf obj
##################################################################
##### MODULA3 ######
##################################################################
MODULA3_INCLUDE= @MODULA3INC@
# ----------------------------------------------------------------
# Build a modula3 dynamically loadable module (C)
# ----------------------------------------------------------------
modula3: $(SRCDIR_SRCS)
$(SWIG) -modula3 $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
modula3_cpp: $(SRCDIR_SRCS)
$(SWIG) -modula3 -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
# -----------------------------------------------------------------
# Run modula3 example
# -----------------------------------------------------------------
modula3_run:
$(RUNTOOL) false $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
# -----------------------------------------------------------------
modula3_version:
echo "Unknown modula3 version"
# -----------------------------------------------------------------
# Cleaning the modula3 examples
# -----------------------------------------------------------------
modula3_clean:
rm -f *_wrap* *.i3 *.m3
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *@SO@
##################################################################
##### MZSCHEME ######
##################################################################
@ -852,7 +813,7 @@ MZSCHEME = mzscheme
MZC = @MZC@
MZDYNOBJ = @MZDYNOBJ@
MZSCHEME_SO = @MZSCHEME_SO@
MZSCHEME_SCRIPT = $(RUNME).scm
MZSCHEME_SCRIPT = $(SRCDIR)$(RUNME).scm
# ----------------------------------------------------------------
# Build a C/C++ dynamically loadable module
@ -860,12 +821,12 @@ MZSCHEME_SCRIPT = $(RUNME).scm
mzscheme: $(SRCDIR_SRCS)
$(SWIG) -mzscheme $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(COMPILETOOL) $(MZC) `echo $(INCLUDES) | sed 's/-I/++ccf -I/g'` --cc $(ISRCS) $(SRCDIR_SRCS)
$(COMPILETOOL) $(MZC) `echo " $(CPPFLAGS) $(INCLUDES) $(CFLAGS)" | sed 's/ -/ ++ccf -/g'` --cc $(ISRCS) $(SRCDIR_SRCS)
$(COMPILETOOL) $(MZC) --ld $(TARGET)$(MZSCHEME_SO) $(OBJS) $(IOBJS)
mzscheme_cpp: $(SRCDIR_SRCS)
$(SWIG) -mzscheme -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(COMPILETOOL) $(MZC) `echo $(INCLUDES) | sed 's/-I/++ccf -I/g'` --cc $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
env CFLAGS= $(COMPILETOOL) $(MZC) `echo " $(CPPFLAGS) $(INCLUDES) $(CXXFLAGS)" | sed 's/ -/ ++ccf -/g'` --cc $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o $(LIBPREFIX)$(TARGET)$(MZSCHEME_SO) $(OBJS) $(IOBJS) $(MZDYNOBJ) $(CPP_DLLIBS)
# -----------------------------------------------------------------
@ -896,135 +857,88 @@ mzscheme_clean:
##### Ocaml #####
##################################################################
OCC=@OCAMLC@
OCAMLDLGEN=@OCAMLDLGEN@
OCAMLFIND=@OCAMLFIND@
OCAMLMKTOP=@OCAMLMKTOP@ $(SWIGWHERE)
OCC=$(COMPILETOOL) @OCAMLC@
OCC_WITH_PP=env TMPDIR=./localtmp $(OCC)
# TMPDIR above is a workaround for some ocamlc versions, such as 4.05.0, which always create a temp file of the same name breaking parallel make (seemingly only when -pp is used)
OCAMLDLGEN=$(COMPILETOOL) @OCAMLDLGEN@
OCAMLFIND=$(COMPILETOOL) @OCAMLFIND@
OCAMLMKTOP=$(COMPILETOOL) @OCAMLMKTOP@
NOLINK ?= false
OCAMLPP= -pp "camlp4o ./swigp4.cmo"
OCAMLP4WHERE=`$(COMPILETOOL) @CAMLP4@ -where`
OCAMLCORE=\
rm -rf swig.mli swig.ml swigp4.ml && \
$(SWIG) -ocaml -co swig.mli 2>/dev/null && \
$(SWIG) -ocaml -co swig.ml 2>/dev/null && \
$(SWIG) -ocaml -co swigp4.ml 2>/dev/null && \
$(OCC) -c swig.mli && \
$(OCC) -c swig.ml && \
$(OCC) -I $(OCAMLP4WHERE) -pp "camlp4o pa_extend.cmo q_MLast.cmo" \
-c swigp4.ml
ocaml_core:
mkdir -p ./localtmp
$(SWIG) -ocaml -co swig.mli 2>/dev/null
$(SWIG) -ocaml -co swig.ml 2>/dev/null
$(SWIG) -ocaml -co swigp4.ml 2>/dev/null
$(OCC) -c swig.mli
$(OCC) -c swig.ml
$(OCC_WITH_PP) -I $(OCAMLP4WHERE) -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
ocaml_static: $(SRCDIR_SRCS)
$(OCAMLCORE)
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
$(OCC) $(OCAMLPP) -c $(PROGFILE)
$(NOLINK) || $(OCC) -g -ccopt -g -cclib -g -custom -o $(TARGET) \
swig.cmo \
$(INTERFACE:%.i=%.cmo) \
$(PROGFILE:%.ml=%.cmo) \
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) -cclib "$(LIBS)"
$(OCC) -w -U -g -c $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
$(NOLINK) || $(OCC) -g -ccopt -g -cclib -g -custom -o $(RUNME) swig.cmo $(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo) $(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) -cclib "$(LIBS)"
ocaml_dynamic: $(SRCDIR_SRCS)
$(OCAMLCORE)
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) $(CCSHARED) -o $(INTERFACE:%.i=%@SO@) \
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) $(LIBS)
$(OCAMLDLGEN) $(INTERFACE:%.i=%.ml) $(INTERFACE:%.i=%@SO@) > \
$(INTERFACE:%.i=%_dynamic.ml)
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) $(CCSHARED) -o $(INTERFACE:%.i=%@SO@) $(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) $(LIBS)
$(OCAMLDLGEN) $(INTERFACE:%.i=%.ml) $(INTERFACE:%.i=%@SO@) > $(INTERFACE:%.i=%_dynamic.ml)
mv $(INTERFACE:%.i=%_dynamic.ml) $(INTERFACE:%.i=%.ml)
rm $(INTERFACE:%.i=%.mli)
$(OCAMLFIND) $(OCC) -g -c -package dl $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
$(OCC) $(OCAMLPP) -c $(PROGFILE)
$(NOLINK) || $(OCAMLFIND) \
$(OCC) -g -ccopt -g -cclib -g -custom -o $(TARGET) \
swig.cmo \
-package dl -linkpkg \
$(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo)
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
$(NOLINK) || $(OCAMLFIND) $(OCC) -g -ccopt -g -cclib -g -custom -o $(RUNME) swig.cmo -package dl -linkpkg $(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo)
ocaml_static_toplevel: $(SRCDIR_SRCS)
$(OCAMLCORE)
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
$(OCC) $(OCAMLPP) -c $(PROGFILE)
$(NOLINK) || $(OCAMLMKTOP) \
swig.cmo \
-I $(OCAMLP4WHERE) camlp4o.cma swigp4.cmo \
-g -ccopt -g -cclib -g -custom -o $(TARGET)_top \
$(INTERFACE:%.i=%.cmo) \
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) -cclib "$(LIBS)"
$(OCC) -w -U -g -c $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
$(NOLINK) || $(OCAMLMKTOP) swig.cmo -I $(OCAMLP4WHERE) dynlink.cma camlp4o.cma swigp4.cmo -cclib "$(LIBS)" -g -ccopt -g -cclib -g -custom -o $(RUNME)_top $(INTERFACE:%.i=%.cmo) $(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS)
ocaml_static_cpp: $(SRCDIR_SRCS)
$(OCAMLCORE)
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
$(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
$(OCC) -cc '$(CXX) $(CPPFLAGS)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" $(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
$(OCC) $(OCAMLPP) -c $(PROGFILE)
$(NOLINK) || $(OCC) -g -ccopt -g -cclib -g -custom -o $(TARGET) \
swig.cmo \
$(INTERFACE:%.i=%.cmo) \
$(PROGFILE:%.ml=%.cmo) \
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) \
-cclib "$(LIBS)" -cc '$(CXX) -Wno-write-strings'
$(OCC) -w -U -g -c $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
$(NOLINK) || $(OCC) -g -ccopt -g -cclib -g -custom -o $(RUNME) swig.cmo $(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo) $(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) -cclib "$(LIBS)" -cc '$(CXX)'
ocaml_static_cpp_toplevel: $(SRCDIR_SRCS)
$(OCAMLCORE)
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
$(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
$(OCC) -cc '$(CXX) $(CPPFLAGS)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" $(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
$(OCC) $(OCAMLPP) -c $(PROGFILE)
$(NOLINK) || $(OCAMLMKTOP) \
swig.cmo \
-I $(OCAMLP4WHERE) dynlink.cma camlp4o.cma swigp4.cmo \
-g -ccopt -g -cclib -g -custom -o $(TARGET)_top \
$(INTERFACE:%.i=%.cmo) \
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) \
-cclib "$(LIBS)" -cc '$(CXX) -Wno-write-strings'
$(OCC) -w -U -g -c $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
$(NOLINK) || $(OCAMLMKTOP) -cc '$(CXX) $(CPPFLAGS)' swig.cmo -I $(OCAMLP4WHERE) dynlink.cma camlp4o.cma swigp4.cmo -cclib "$(LIBS)" -g -ccopt -g -cclib -g -custom -o $(RUNME)_top $(INTERFACE:%.i=%.cmo) $(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS)
ocaml_dynamic_cpp: $(SRCDIR_SRCS)
$(OCAMLCORE)
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
$(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) -ccopt -fPIC
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o $(INTERFACE:%.i=%@SO@) \
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) \
$(CPP_DLLIBS) $(LIBS)
$(OCAMLDLGEN) $(INTERFACE:%.i=%.ml) $(INTERFACE:%.i=%@SO@) > \
$(INTERFACE:%.i=%_dynamic.ml)
$(OCC) -cc '$(CXX) $(CPPFLAGS)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" $(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) -ccopt -fPIC
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o $(INTERFACE:%.i=%@SO@) $(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) $(CPP_DLLIBS) $(LIBS)
$(OCAMLDLGEN) $(INTERFACE:%.i=%.ml) $(INTERFACE:%.i=%@SO@) > $(INTERFACE:%.i=%_dynamic.ml)
mv $(INTERFACE:%.i=%_dynamic.ml) $(INTERFACE:%.i=%.ml)
rm $(INTERFACE:%.i=%.mli)
$(OCAMLFIND) $(OCC) -g -c -package dl $(INTERFACE:%.i=%.ml)
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
$(OCC) $(OCAMLPP) -c $(PROGFILE)
$(NOLINK) || $(OCAMLFIND) \
swig.cmo \
$(OCC) -cclib -export-dynamic -g -ccopt -g -cclib -g -custom \
-o $(TARGET) \
-package dl -linkpkg \
$(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo) -cc '$(CXX) -Wno-write-strings'
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
$(NOLINK) || $(OCAMLFIND) swig.cmo $(OCC) -cclib -export-dynamic -g -ccopt -g -cclib -g -custom -o $(RUNME) -package dl -linkpkg $(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo) -cc '$(CXX)'
# -----------------------------------------------------------------
# Run ocaml example
# -----------------------------------------------------------------
ocaml_run:
$(RUNTOOL) ./$(TARGET) $(RUNPIPE)
$(RUNTOOL) ./$(RUNME) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
@ -1038,9 +952,10 @@ ocaml_version:
# -----------------------------------------------------------------
ocaml_clean:
rm -f *_wrap* *~ .~* *.cmo *.cmi $(MLFILE) $(MLFILE)i swig.mli swig.cmi swig.ml swig.cmo swigp4.ml swigp4.cmo
rm -f *_wrap* *~ .~* *.cmo *.cmi *.mli $(TARGET).ml $(RUNME) $(RUNME)_top swig.ml swigp4.ml
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *@SO@
rm -rf ./localtmp
##################################################################
##### RUBY ######
@ -1116,7 +1031,7 @@ ruby_clean:
rm -f *.@OBJEXT@ *$(RUBY_SO)
##################################################################
##### PHP ######
##### PHP7 ######
##################################################################
PHP = @PHP@
@ -1129,7 +1044,7 @@ PHP_SCRIPT = $(SRCDIR)$(RUNME).php
# -------------------------------------------------------------------
php: $(SRCDIR_SRCS)
$(SWIG) -php $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(SWIG) -php7 $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(CC) -c $(CCSHARED) $(CPPFLAGS) $(CFLAGS) $(SRCDIR_SRCS) $(ISRCS) $(INCLUDES) $(PHP_INCLUDE)
$(LDSHARED) $(CFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(PHP_SO)
@ -1138,7 +1053,7 @@ php: $(SRCDIR_SRCS)
# --------------------------------------------------------------------
php_cpp: $(SRCDIR_SRCS)
$(SWIG) -php -cppext cxx -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(SWIG) -php7 -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(ICXXSRCS) $(INCLUDES) $(PHP_INCLUDE)
$(CXXSHARED) $(CXXFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(PHP_SO)
@ -1147,7 +1062,7 @@ php_cpp: $(SRCDIR_SRCS)
# -----------------------------------------------------------------
php_run:
$(RUNTOOL) $(PHP) -n -q -d extension_dir=. -d safe_mode=Off $(PHP_SCRIPT) $(RUNPIPE)
$(RUNTOOL) $(PHP) -n -q -d extension_dir=. -d safe_mode=Off -d display_errors=stderr $(PHP_SCRIPT) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
@ -1165,194 +1080,6 @@ php_clean:
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *$(PHP_SO)
##################################################################
##### Pike ######
##################################################################
# Make sure these locate your Pike installation
PIKE = pike
PIKE_CFLAGS = @PIKECCDLFLAGS@ -DHAVE_CONFIG_H
PIKE_INCLUDE = @PIKEINCLUDE@
PIKE_LIB = @PIKELIB@
PIKE_DLNK = @PIKEDYNAMICLINKING@
PIKE_LIBOPTS = @PIKELINK@ @LIBS@ $(SYSLIBS)
PIKE_SCRIPT = $(RUNME).pike
# ----------------------------------------------------------------
# Build a C dynamically loadable module
# ----------------------------------------------------------------
pike: $(SRCDIR_SRCS)
$(SWIG) -pike $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(CC) -c $(CCSHARED) $(CPPFLAGS) $(CFLAGS) $(PIKE_CFLAGS) $(ISRCS) $(SRCDIR_SRCS) $(INCLUDES) $(PIKE_INCLUDE)
$(LDSHARED) $(CFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(PIKE_DLNK) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
# -----------------------------------------------------------------
# Build a C++ dynamically loadable module
# -----------------------------------------------------------------
pike_cpp: $(SRCDIR_SRCS)
$(SWIG) -c++ -pike $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(PIKE_CFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES) $(PIKE_INCLUDE)
$(CXXSHARED) $(CXXFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(PIKE_DLNK) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
# -----------------------------------------------------------------
# Build statically linked Pike interpreter
#
# These should only be used in conjunction with the %include embed.i
# library file
# -----------------------------------------------------------------
pike_static: $(SRCDIR_SRCS)
$(SWIG) -pike -lembed.i $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(PIKE_CFLAGS) @LINKFORSHARED@ $(ISRCS) $(SRCDIR_SRCS) $(INCLUDES) \
$(PIKE_INCLUDE) $(LIBS) -L$(PIKE_LIB) $(PIKE_LIBOPTS) -o $(TARGET)
pike_cpp_static: $(SRCDIR_SRCS)
$(SWIG) -c++ -pike -lembed.i $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) $(PIKE_CFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES) \
$(PIKE_INCLUDE) $(LIBS) -L$(PIKE_LIB) $(PIKE_LIBOPTS) -o $(TARGET)
# -----------------------------------------------------------------
# Run pike example
# -----------------------------------------------------------------
pike_run:
$(RUNTOOL) $(PIKE) $(PIKE_SCRIPT) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
# -----------------------------------------------------------------
pike_version:
$(PIKE) -v 2>&1 | head -n 1
# -----------------------------------------------------------------
# Cleaning the Pike examples
# -----------------------------------------------------------------
pike_clean:
rm -f *_wrap* *~ .~* mypike@EXEEXT@
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *@SO@
##################################################################
##### Chicken ######
##################################################################
CHICKEN = @CHICKEN@
CHICKEN_CSC = @CHICKEN_CSC@
CHICKEN_CSI = @CHICKEN_CSI@
CHICKEN_LIBOPTS = @CHICKENLIB@ $(SYSLIBS)
CHICKEN_SHAREDLIBOPTS = @CHICKENSHAREDLIB@ $(SYSLIBS)
CHICKEN_CFLAGS = @CHICKENOPTS@
CHICKENOPTS = -quiet
CHICKEN_MAIN =
CHICKEN_SCRIPT = $(RUNME).scm
# SWIG produces $(ISRCS) (the C wrapper file)
# and $(CHICKEN_GENERATED_SCHEME) (the Scheme wrapper file):
CHICKEN_GENERATED_SCHEME = $(INTERFACE:.i=.scm)
CHICKEN_COMPILED_SCHEME = $(INTERFACE:.i=_chicken.c)
CHICKEN_COMPILED_OBJECT = $(CHICKEN_COMPILED_SCHEME:.c=.@OBJEXT@)
# flags for the main chicken sources (only used when compiling statically)
CHICKEN_COMPILED_MAIN = $(CHICKEN_MAIN:.scm=_chicken.c)
CHICKEN_COMPILED_MAIN_OBJECT = $(CHICKEN_COMPILED_MAIN:.c=.@OBJEXT@)
# -----------------------------------------------------------------
# Build a CHICKEN dynamically loadable module
# -----------------------------------------------------------------
# This is the old way to build chicken, but it does not work correctly with exceptions
chicken_direct: $(SRCDIR_SRCS)
$(SWIG) -chicken $(SWIGOPT) $(INCLUDE) $(INTERFACEPATH)
$(CHICKEN) $(CHICKEN_GENERATED_SCHEME) $(CHICKENOPTS) \
-dynamic -feature chicken-compile-shared \
-output-file $(CHICKEN_COMPILED_SCHEME)
$(CC) -c $(CCSHARED) $(CPPFLAGS) $(CFLAGS) $(CHICKEN_CFLAGS) \
$(INCLUDES) $(CHICKEN_INCLUDE) $(ISRCS) $(SRCDIR_SRCS) $(CHICKEN_COMPILED_SCHEME)
$(LDSHARED) $(CFLAGS) $(LDFLAGS) $(CHICKEN_COMPILED_OBJECT) $(OBJS) $(IOBJS) \
$(LIBS) $(CHICKEN_SHAREDLIBOPTS) -o $(LIBPREFIX)$(TARGET)$(SO)
chicken_direct_cpp: $(SRCDIR_CXXSRCS) $(CHICKSRCS)
$(SWIG) -c++ -chicken $(SWIGOPT) $(INCLUDE) $(INTERFACEPATH)
$(CHICKEN) $(CHICKEN_GENERATED_SCHEME) $(CHICKENOPTS) \
-dynamic -feature chicken-compile-shared \
-output-file $(CHICKEN_COMPILED_SCHEME)
$(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(CHICKEN_CFLAGS) \
$(INCLUDES) $(CHICKEN_INCLUDE) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(CHICKEN_COMPILED_SCHEME)
$(CXXSHARED) $(CXXFLAGS) $(LDFLAGS) $(CHICKEN_COMPILED_OBJECT) $(OBJS) $(IOBJS) \
$(LIBS) $(CPP_DLLIBS) $(CHICKEN_SHAREDLIBOPTS) -o $(LIBPREFIX)$(TARGET)$(SO)
# -----------------------------------------------------------------
# Build statically linked CHICKEN interpreter
# -----------------------------------------------------------------
# The following two targets are also used by the test suite
chicken_static: $(SRCDIR_SRCS) $(CHICKSRCS)
$(SWIG) -chicken $(SWIGOPT) $(INCLUDE) $(INTERFACEPATH)
$(CHICKEN) $(CHICKEN_GENERATED_SCHEME) $(CHICKENOPTS) \
-output-file $(CHICKEN_COMPILED_SCHEME)
$(CHICKEN) $(CHICKEN_MAIN) $(CHICKENOPTS) \
-output-file $(CHICKEN_MAIN:.scm=_chicken.c)
$(CC) -c $(CCSHARED) $(CPPFLAGS) $(CFLAGS) $(CHICKEN_CFLAGS) \
$(INCLUDES) $(CHICKEN_INCLUDE) $(ISRCS) $(SRCDIR_SRCS) \
$(CHICKEN_COMPILED_SCHEME) $(CHICKEN_COMPILED_MAIN)
$(CC) $(CFLAGS) $(LDFLAGS) $(CHICKEN_COMPILED_OBJECT) $(CHICKEN_COMPILED_MAIN_OBJECT) \
$(OBJS) $(IOBJS) $(LIBS) $(CHICKEN_SHAREDLIBOPTS) -o $(TARGET)
chicken_static_cpp: $(SRCDIR_CXXSRCS) $(CHICKSRCS)
$(SWIG) -c++ -chicken $(SWIGOPT) $(INCLUDE) $(INTERFACEPATH)
$(CHICKEN) $(CHICKEN_GENERATED_SCHEME) $(CHICKENOPTS) \
-output-file $(CHICKEN_COMPILED_SCHEME)
$(CHICKEN) $(CHICKEN_MAIN) $(CHICKENOPTS) \
-output-file $(CHICKEN_MAIN:.scm=_chicken.c)
$(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(CHICKEN_CFLAGS) \
$(INCLUDES) $(CHICKEN_INCLUDE) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) \
$(CHICKEN_COMPILED_SCHEME) $(CHICKEN_COMPILED_MAIN)
$(CXX) $(CXXFLAGS) $(LDFLAGS) $(CHICKEN_COMPILED_OBJECT) $(CHICKEN_COMPILED_MAIN_OBJECT) \
$(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) $(CHICKEN_SHAREDLIBOPTS) -o $(TARGET)
# ----------------------------------------------------------------
# Build a shared library using csc
# ----------------------------------------------------------------
chicken:
$(SWIG) -chicken $(SWIGOPT) $(INCLUDE) $(INTERFACEPATH)
$(COMPILETOOL) $(CHICKEN_CSC) -s `echo $(INCLUDES) | sed 's/-I/-C -I/g'` $(CHICKEN_GENERATED_SCHEME) $(SRCDIR_SRCS) $(ISRCS) -o $(TARGET)$(SO)
chicken_cpp:
$(SWIG) -c++ -chicken $(SWIGOPT) $(INCLUDE) $(INTERFACEPATH)
$(COMPILETOOL) $(CHICKEN_CSC) -s `echo $(INCLUDES) | sed 's/-I/-C -I/g'` $(CHICKEN_GENERATED_SCHEME) $(SRCDIR_SRCS) $(ICXXSRCS) $(SRCDIR_CXXSRCS) -o $(TARGET)$(SO)
chicken_externalhdr:
$(SWIG) -chicken -external-runtime $(TARGET)
# -----------------------------------------------------------------
# Run CHICKEN example
# -----------------------------------------------------------------
chicken_run:
env LD_LIBRARY_PATH=$$PWD $(RUNTOOL) $(CHICKEN_CSI) $(CHICKEN_SCRIPT) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
# -----------------------------------------------------------------
chicken_version:
$(CHICKEN) -version | grep -i version
# -----------------------------------------------------------------
# Cleaning the CHICKEN examples
# -----------------------------------------------------------------
chicken_clean:
rm -f *_wrap* *~ .~* *_chicken*
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *@SO@
##################################################################
##### CSHARP ######
##################################################################
@ -1367,7 +1094,7 @@ CSHARPCFLAGS = @CSHARPCFLAGS@
CSHARPFLAGS =
CSHARPOPTIONS =
CSHARPSO = @CSHARPSO@
CSHARP_RUNME = $(CSHARPCILINTERPRETER) $(CSHARPCILINTERPRETER_FLAGS) ./$(RUNME).exe
CSHARP_RUNME = ./$(RUNME).exe
# ----------------------------------------------------------------
# Build a CSharp dynamically loadable module (C)
@ -1405,7 +1132,7 @@ csharp_compile: $(SRCDIR_SRCS)
# -----------------------------------------------------------------
csharp_run:
env LD_LIBRARY_PATH=$$PWD $(RUNTOOL) $(CSHARP_RUNME) $(RUNPIPE)
env LD_LIBRARY_PATH=$$PWD $(RUNTOOL) $(CSHARPCILINTERPRETER) $(CSHARPCILINTERPRETER_FLAGS) $(CSHARP_RUNME) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
@ -1547,42 +1274,6 @@ allegrocl_clean:
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *@SO@
##################################################################
##### CLISP ######
##################################################################
CLISP = @CLISPBIN@
CLISP_SCRIPT=$(RUNME).lisp
clisp: $(SRCDIR_SRCS)
$(SWIG) -clisp $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
clisp_cpp: $(SRCDIR_SRCS)
$(SWIG) -c++ -clisp $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
# -----------------------------------------------------------------
# Run CLISP example
# -----------------------------------------------------------------
clisp_run:
$(RUNTOOL) $(CLISP) -batch -s $(CLISP_SCRIPT) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
# -----------------------------------------------------------------
clisp_version:
$(CLISP) --version | head -n 1
# -----------------------------------------------------------------
# Cleaning the CLISP examples
# -----------------------------------------------------------------
clisp_clean:
rm -f *_wrap* *~ .~*
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *@SO@
##################################################################
##### CFFI ######
##################################################################
@ -1623,46 +1314,6 @@ cffi_clean:
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *@SO@
##################################################################
##### UFFI ######
##################################################################
UFFI = @UFFIBIN@
UFFI_SCRIPT=$(RUNME).lisp
uffi: $(SRCDIR_SRCS)
$(SWIG) -uffi $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
# $(CC) -c $(CCSHARED) $(CPPFLAGS) $(CFLAGS) $(ISRCS) $(INCLUDES) $(SRCDIR_SRCS)
# $(LDSHARED) $(CFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
uffi_cpp: $(SRCDIR_SRCS)
$(SWIG) -c++ -uffi $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
# $(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES)
# $(CXXSHARED) $(CXXFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(SO)
# -----------------------------------------------------------------
# Run UFFI example
# -----------------------------------------------------------------
uffi_run:
$(RUNTOOL) $(UFFI) -batch -s $(UFFI_SCRIPT) $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
# -----------------------------------------------------------------
uffi_version:
$(UFFI) --version
# -----------------------------------------------------------------
# Cleaning the UFFI examples
# -----------------------------------------------------------------
uffi_clean:
rm -f *_wrap* *~ .~*
rm -f core @EXTRA_CLEAN@
rm -f *.@OBJEXT@ *@SO@
##################################################################
##### R ######
##################################################################
@ -1687,7 +1338,7 @@ r: $(SRCDIR_SRCS)
ifneq ($(SRCDIR_SRCS),)
$(CC) -g -c $(CPPFLAGS) $(CFLAGS) $(R_CFLAGS) $(SRCDIR_SRCS) $(INCLUDES)
endif
+( PKG_CPPFLAGS="$(CPPFLAGS) $(INCLUDES)" $(COMPILETOOL) $(R) CMD SHLIB -o $(LIBPREFIX)$(TARGET)$(SO) $(ISRCS) $(OBJS) > /dev/null )
+( PKG_CPPFLAGS="$(CPPFLAGS) $(INCLUDES)" PKG_CFLAGS="$(CFLAGS)" $(COMPILETOOL) $(R) CMD SHLIB -o $(LIBPREFIX)$(TARGET)$(SO) $(ISRCS) $(OBJS) > /dev/null )
# ----------------------------------------------------------------
# Build a R dynamically loadable module (C++)
@ -1697,7 +1348,7 @@ r_cpp: $(SRCDIR_CXXSRCS)
ifneq ($(SRCDIR_CXXSRCS),)
$(CXX) -g -c $(CPPFLAGS) $(CXXFLAGS) $(R_CFLAGS) $(SRCDIR_CXXSRCS) $(INCLUDES)
endif
+( PKG_CPPFLAGS="$(CPPFLAGS) $(INCLUDES)" $(COMPILETOOL) $(R) CMD SHLIB -o $(LIBPREFIX)$(TARGET)$(SO) $(RCXXSRCS) $(OBJS) > /dev/null )
+( PKG_CPPFLAGS="$(CPPFLAGS) $(INCLUDES)" PKG_CXXFLAGS="$(CXXFLAGS)" $(COMPILETOOL) $(R) CMD SHLIB -o $(LIBPREFIX)$(TARGET)$(SO) $(RCXXSRCS) $(OBJS) > /dev/null )
# -----------------------------------------------------------------
# Run R example
@ -1864,7 +1515,8 @@ GOPACK = `if $(GO1) ; then echo go tool pack; else echo gopack; fi`
GOPACKAGE = $(notdir $(INTERFACE:.i=.a))
GOPATHDIR = gopath/src/$(INTERFACE:.i=)
GOPATHPARENTDIR = gopath/$(GOMOD)/src
GOPATHDIR = $(GOPATHPARENTDIR)/$(INTERFACE:.i=)
GOOBJEXT = `if $(GO15); then echo o; else echo $(GOC:c=); fi`
GOGCOBJS = $(GOSRCS:.go=.$(GOOBJEXT))
@ -1874,8 +1526,18 @@ GOGCCOBJS = $(GOSRCS:.go=.@OBJEXT@)
# Build a Go module (C)
# ----------------------------------------------------------------
$(GOPATHPARENTDIR)/go.mod:
@mkdir gopath 2>/dev/null || true
@mkdir gopath/$(GOMOD) 2>/dev/null || true
@mkdir gopath/$(GOMOD)/src 2>/dev/null || true
@mkdir $(GOPATHDIR) 2>/dev/null || true
echo "module swigtests" > $(GOPATHDIR)/go.mod
echo "" >> $(GOPATHDIR)/go.mod
echo "go 1.12" >> $(GOPATHDIR)/go.mod
mv -f $(GOPATHDIR)/go.mod $(GOPATHPARENTDIR)/go.mod
go_nocgo: $(SRCDIR_SRCS)
$(SWIG) -go $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(SWIG) -go -no-cgo $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
if $(GO12) || $(GO13) || $(GO15) || $(GOGCC); then \
$(CC) -g -c $(CPPFLAGS) $(CFLAGS) $(SRCDIR_SRCS) $(ISRCS) $(INCLUDES); \
else \
@ -1910,11 +1572,12 @@ go_nocgo: $(SRCDIR_SRCS)
fi; \
fi
go: $(SRCDIR_SRCS)
$(SWIG) -go -cgo $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
go: $(SRCDIR_SRCS) $(GOPATHPARENTDIR)/go.mod
$(SWIG) -go -import-prefix swigtests $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
@mkdir gopath 2>/dev/null || true
@mkdir gopath/src 2>/dev/null || true
@mkdir gopath/src/$(INTERFACE:.i=) 2>/dev/null || true
@mkdir gopath/$(GOMOD) 2>/dev/null || true
@mkdir gopath/$(GOMOD)/src 2>/dev/null || true
@mkdir $(GOPATHDIR) 2>/dev/null || true
rm -f $(GOPATHDIR)/*
cp $(ISRCS) $(GOPATHDIR)/
if test -f $(IWRAP:.i=.h); then \
@ -1924,7 +1587,7 @@ go: $(SRCDIR_SRCS)
cp $(SRCDIR_SRCS) $(GOPATHDIR)/; \
fi
cp $(GOSRCS) $(GOPATHDIR)/
GOPATH=`pwd`/gopath; \
GOPATH=`pwd`/gopath/$(GOMOD); \
export GOPATH; \
CGO_CPPFLAGS="$(CPPFLAGS) $(INCLUDES) -I `cd $(SRCDIR) && pwd` -I `pwd`"; \
export CGO_CPPFLAGS; \
@ -1933,17 +1596,16 @@ go: $(SRCDIR_SRCS)
CGO_LDFLAGS="$(LDFLAGS) -lm"; \
export CGO_LDFLAGS; \
(cd $(GOPATHDIR)/ && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o $(GOPACKAGE))
cp $(GOPATHDIR)/$(GOPACKAGE) $(dir $(INTERFACE))/$(GOPACKAGE)
if $(GOGCC); then \
cp $(dir $(INTERFACE))/$(GOPACKAGE) $(dir $(INTERFACE))/$(GOPACKAGE:.a=.gox); \
cp $(GOPATHDIR)/$(GOPACKAGE) $(GOPATHDIR)/$(GOPACKAGE:.a=.gox); \
fi
if test -f $(SRCDIR)$(RUNME).go; then \
if $(GOGCC) ; then \
$(COMPILETOOL) $(GCCGO) -c -g $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GCCGO) -o $(RUNME) $(RUNME).@OBJEXT@ $(dir $(INTERFACE))/$(GOPACKAGE); \
$(COMPILETOOL) $(GCCGO) -c -g -I $(GOPATHDIR) $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GCCGO) -o $(RUNME) $(RUNME).@OBJEXT@ $(GOPATHDIR)/$(GOPACKAGE); \
elif $(GO12) || $(GO13) || $(GO15); then \
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -o $(RUNME).$(GOOBJEXT) $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GOTOOL) $(GOLD) -linkmode external -extld "$(CC)" -extldflags "$(CFLAGS) $(LDFLAGS)" -o $(RUNME) $(RUNME).$(GOOBJEXT); \
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -I $(GOPATHDIR) -o $(RUNME).$(GOOBJEXT) $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GOTOOL) $(GOLD) -L $(GOPATHDIR) -linkmode external -extld "$(CC)" -extldflags "$(CFLAGS) $(LDFLAGS)" -o $(RUNME) $(RUNME).$(GOOBJEXT); \
else \
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GOTOOL) $(GOLD) -r $${GOROOT:-`go env GOROOT`}/pkg/$${GOOS:-`go env GOOS`}_$${GOARCH:-`go env GOARCH`}:. -o $(RUNME) $(RUNME).$(GOOBJEXT); \
@ -1955,7 +1617,7 @@ go: $(SRCDIR_SRCS)
# ----------------------------------------------------------------
go_cpp_nocgo: $(SRCDIR_SRCS)
$(SWIG) -go -c++ $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(SWIG) -go -c++ -no-cgo $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
if $(GO12) || $(GO13) || $(GO15) || $(GOGCC); then \
if test -n "$(SRCDIR_CXXSRCS)$(SRCDIR_SRCS)"; then \
$(CXX) -g -c $(CPPFLAGS) $(CXXFLAGS) $(SRCDIR_CXXSRCS) $(SRCDIR_SRCS) $(INCLUDES); \
@ -2002,11 +1664,12 @@ go_cpp_nocgo: $(SRCDIR_SRCS)
fi; \
fi
go_cpp: $(SRCDIR_SRCS)
$(SWIG) -go -c++ -cgo $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
go_cpp: $(SRCDIR_SRCS) $(GOPATHPARENTDIR)/go.mod
$(SWIG) -go -c++ -import-prefix swigtests $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
@mkdir gopath 2>/dev/null || true
@mkdir gopath/src 2>/dev/null || true
@mkdir gopath/src/$(INTERFACE:.i=) 2>/dev/null || true
@mkdir gopath/$(GOMOD) 2>/dev/null || true
@mkdir gopath/$(GOMOD)/src 2>/dev/null || true
@mkdir $(GOPATHDIR) 2>/dev/null || true
rm -f $(GOPATHDIR)/*
cp $(ICXXSRCS) $(GOPATHDIR)/
if test -f $(IWRAP:.i=.h); then \
@ -2019,7 +1682,7 @@ go_cpp: $(SRCDIR_SRCS)
cp $(SRCDIR_SRCS) $(GOPATHDIR)/; \
fi
cp $(GOSRCS) $(GOPATHDIR)/
GOPATH=`pwd`/gopath; \
GOPATH=`pwd`/gopath/$(GOMOD); \
export GOPATH; \
CGO_CPPFLAGS="$(CPPFLAGS) $(INCLUDES) -I `cd $(SRCDIR) && pwd` -I `pwd`"; \
export CGO_CPPFLAGS; \
@ -2030,17 +1693,16 @@ go_cpp: $(SRCDIR_SRCS)
CGO_LDFLAGS="$(LDFLAGS) -lm"; \
export CGO_LDFLAGS; \
(cd $(GOPATHDIR) && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o $(GOPACKAGE))
cp $(GOPATHDIR)/$(GOPACKAGE) $(dir $(INTERFACE))/$(GOPACKAGE)
if $(GOGCC); then \
cp $(dir $(INTERFACE))/$(GOPACKAGE) $(dir $(INTERFACE))/$(GOPACKAGE:.a=.gox); \
cp $(GOPATHDIR)/$(GOPACKAGE) $(GOPATHDIR)/$(GOPACKAGE:.a=.gox); \
fi
if test -f $(SRCDIR)$(RUNME).go; then \
if $(GOGCC) ; then \
$(COMPILETOOL) $(GCCGO) -g -c $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GCCGO) -o $(RUNME) $(RUNME).@OBJEXT@ $(dir $(INTERFACE))/$(GOPACKAGE) -lstdc++; \
$(COMPILETOOL) $(GCCGO) -g -c -I $(GOPATHDIR) $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GCCGO) -o $(RUNME) $(RUNME).@OBJEXT@ $(GOPATHDIR)/$(GOPACKAGE) -lstdc++; \
elif $(GO12) || $(GO13) || $(GO15); then \
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -o $(RUNME).$(GOOBJEXT) $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GOTOOL) $(GOLD) -linkmode external -extld "$(CXX)" -extldflags "$(CXXFLAGS) $(LDFLAGS)" -o $(RUNME) $(RUNME).$(GOOBJEXT); \
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -I $(GOPATHDIR) -o $(RUNME).$(GOOBJEXT) $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GOTOOL) $(GOLD) -L $(GOPATHDIR) -linkmode external -extld "$(CXX)" -extldflags "$(CXXFLAGS) $(LDFLAGS)" -o $(RUNME) $(RUNME).$(GOOBJEXT); \
else \
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) $(SRCDIR)$(RUNME).go; \
$(COMPILETOOL) $(GOTOOL) $(GOLD) -r $${GOROOT:-`go env GOROOT`}/pkg/$${GOOS:-`go env GOOS`}_$${GOARCH:-`go env GOARCH`}:. -o $(RUNME) $(RUNME).$(GOOBJEXT); \

2
Examples/go/callback/gocallback.go
View file

@ -36,6 +36,6 @@ func DeleteGoCallback(p GoCallback) {
p.deleteCallback()
}
func (p *goCallback) Run() {
func (p *overwrittenMethodsOnCallback) Run() {
fmt.Println("GoCallback.Run")
}

3
Examples/go/callback/runme.go
View file

@ -1,8 +1,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/class/runme.go
View file

@ -3,8 +3,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/constants/runme.go
View file

@ -1,8 +1,9 @@
package main
import (
"./example"
"fmt"
"example"
)
func main() {

4
Examples/go/director/director.go
View file

@ -32,7 +32,7 @@ type overwrittenMethodsOnFooBarAbstract struct {
fb FooBarAbstract
// If additional constructor arguments have been given they are typically
// stored here so that the overriden methods can use them.
// stored here so that the overridden methods can use them.
}
func (om *overwrittenMethodsOnFooBarAbstract) Foo() string {
@ -59,7 +59,7 @@ func NewFooBarGo() FooBarGo {
// The memory of the FooBarAbstract director object instance can be
// automatically freed once the FooBarGo instance is garbage collected by
// uncommenting the following line. Please make sure to understand the
// runtime.SetFinalizer specific gotchas before doing this. Furthemore
// runtime.SetFinalizer specific gotchas before doing this. Furthermore
// DeleteFooBarGo should be deleted if a finalizer is in use or the fooBarGo
// struct needs additional data to prevent double deletion.
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)

3
Examples/go/director/runme.go
View file

@ -1,9 +1,10 @@
package main
import (
"./example"
"fmt"
"os"
"example"
)
func Compare(name string, got string, exp string) error {

3
Examples/go/enum/runme.go
View file

@ -1,8 +1,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/extend/runme.go
View file

@ -3,8 +3,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/funcptr/runme.go
View file

@ -1,8 +1,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/multimap/runme.go
View file

@ -1,8 +1,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/pointer/runme.go
View file

@ -1,8 +1,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/reference/runme.go
View file

@ -3,8 +3,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/simple/runme.go
View file

@ -1,8 +1,9 @@
package main
import (
"./example"
"fmt"
"example"
)
func main() {

3
Examples/go/template/runme.go
View file

@ -3,8 +3,9 @@
package main
import (
. "./example"
"fmt"
. "example"
)
func main() {

3
Examples/go/variables/runme.go
View file

@ -3,8 +3,9 @@
package main
import (
"./example"
"fmt"
"example"
)
func main() {

5
Examples/guile/matrix/runme.scm
View file

@ -1,6 +1,3 @@
#!./matrix \
-e do-test -s
!#
;;; Authors: David Beazley <beazley@cs.uchicago.edu>, 1999
;;; Martin Froehlich <MartinFroehlich@ACM.org>, 2000
;;;
@ -15,7 +12,7 @@
;;; Explanation: The three lines at the beginning of this script are
;;; telling the kernel to load the enhanced guile interpreter named
;;; "matrix"; to execute the function "do-test" (-e option) after loading
;;; this script (-s option). There are a lot more options wich allow for
;;; this script (-s option). There are a lot more options which allow for
;;; even finer tuning. SEE ALSO: Section "Guile Scripts" in the "Guile
;;; reference manual -- Part I: Preliminaries".
;;;

4
Examples/guile/multivalue/example.i
View file

@ -15,14 +15,14 @@ back to this behavior, use: */
void divide_l(int a, int b, int *OUTPUT, int *OUTPUT);
/* Multiple values as vectors. By issueing: */
/* Multiple values as vectors. By issuing: */
%values_as_vector;
/* vectors instead of lists will be used. */
void divide_v(int a, int b, int *OUTPUT, int *OUTPUT);
/* Multiple values for multiple-value continuations.
(This is the most elegant way.) By issueing: */
(This is the most elegant way.) By issuing: */
%multiple_values;
/* multiple values are passed to the multiple-value
continuation, as created by `call-with-values' or the

27
Examples/guile/simple/example.c
View file

@ -1,21 +1,18 @@
/* Simple example from documentation */
/* File : example.c */
#include <time.h>
/* A global variable */
double Foo = 3.0;
double My_variable = 3.0;
int fact(int n) {
if (n <= 1) return 1;
else return n*fact(n-1);
/* Compute the greatest common divisor of positive integers */
int gcd(int x, int y) {
int g;
g = y;
while (x > 0) {
g = x;
x = y % x;
y = g;
}
return g;
}
int mod(int n, int m) {
return (n % m);
}
char *get_time() {
long ltime;
time(&ltime);
return ctime(&ltime);
}

6
Examples/guile/simple/example.i
View file

@ -5,10 +5,8 @@
%}
%inline %{
extern double My_variable;
extern int fact(int);
extern int mod(int n, int m);
extern char *get_time();
extern int gcd(int x, int y);
extern double Foo;
%}
%include guile/guilemain.i

28
Examples/guile/simple/runme.scm
View file

@ -3,24 +3,20 @@
(for-each display args)
(newline))
(mdisplay-newline (get-time) "My variable = " (My-variable))
; Call our gcd() function
(do ((i 0 (1+ i)))
((= 14 i))
(mdisplay-newline i " factorial is " (fact i)))
(define x 42)
(define y 105)
(define g (gcd x y))
(mdisplay-newline "The gcd of " x " and " y " is " g)
(define (mods i imax j jmax)
(if (< i imax)
(if (< j jmax)
(begin
(My-variable (+ (My-variable) (mod i j)))
(mods i imax (+ j 1) jmax))
(mods (+ i 1) imax 1 jmax))))
; Manipulate the Foo global variable
(mods 1 150 1 150)
; Output its current value
(mdisplay-newline "Foo = " (Foo))
(mdisplay-newline "My-variable = " (My-variable))
(exit (and (= 1932053504 (fact 13))
(= 745470.0 (My-variable))))
; Change its value
(Foo 3.1415926)
; See if the change took effect
(mdisplay-newline "Foo = " (Foo))

5
Examples/guile/std_vector/example.h
View file

@ -17,9 +17,8 @@ std::vector<double> half(const std::vector<double>& v) {
}
void halve_in_place(std::vector<double>& v) {
// would you believe this is the same as the above?
std::transform(v.begin(),v.end(),v.begin(),
std::bind2nd(std::divides<double>(),2.0));
for (std::vector<double>::iterator it = v.begin(); it != v.end(); ++it)
*it /= 2.0;
}

1
Examples/java/check.list
View file

@ -2,6 +2,7 @@
callback
class
constants
doxygen
enum
extend
funcptr

21
Examples/java/doxygen/Makefile Normal file
View file

@ -0,0 +1,21 @@
TOP = ../..
SWIGEXE = $(TOP)/../swig
SWIG_LIB_DIR = $(TOP)/../$(TOP_BUILDDIR_TO_TOP_SRCDIR)Lib
CXXSRCS = example.cxx
TARGET = example
INTERFACE = example.i
SWIGOPT = -doxygen
JAVASRCS = *.java
check: build
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' java_run
build:
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' \
SWIG_LIB_DIR='$(SWIG_LIB_DIR)' SWIGEXE='$(SWIGEXE)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' java_cpp
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' JAVASRCS='$(JAVASRCS)' JAVAFLAGS='$(JAVAFLAGS)' java_compile
clean:
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' java_clean
rm -rf javadocs

48
Examples/java/doxygen/example.cxx Normal file
View file

@ -0,0 +1,48 @@
/* File : example.cxx */
#include "example.h"
#define M_PI 3.14159265358979323846
/* Move the shape to a new location */
void Shape::move(double dx, double dy) {
x += dx;
y += dy;
}
int Shape::nshapes = 0;
Circle::Circle(double r) : radius(r) {
NumCircles++;
}
double Circle::area() {
return M_PI*radius*radius;
}
double Circle::perimeter() {
return 2*M_PI*radius;
}
Square::Square(double w) : width(w) {
NumSquares++;
}
double Square::area() {
return width*width;
}
double Square::perimeter() {
return 4*width;
}
int NumSquares = 0;
int NumCircles = 0;
Square MakeSquare(double r) {
return Square(r);
}
Circle MakeCircle(double w) {
return Circle(w);
}

162
Examples/java/doxygen/example.dsp Normal file
View file

@ -0,0 +1,162 @@
# Microsoft Developer Studio Project File - Name="example" - Package Owner=<4>
# Microsoft Developer Studio Generated Build File, Format Version 6.00
# ** DO NOT EDIT **
# TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102
CFG=example - Win32 Release
!MESSAGE This is not a valid makefile. To build this project using NMAKE,
!MESSAGE use the Export Makefile command and run
!MESSAGE
!MESSAGE NMAKE /f "example.mak".
!MESSAGE
!MESSAGE You can specify a configuration when running NMAKE
!MESSAGE by defining the macro CFG on the command line. For example:
!MESSAGE
!MESSAGE NMAKE /f "example.mak" CFG="example - Win32 Release"
!MESSAGE
!MESSAGE Possible choices for configuration are:
!MESSAGE
!MESSAGE "example - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library")
!MESSAGE "example - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library")
!MESSAGE
# Begin Project
# PROP AllowPerConfigDependencies 0
# PROP Scc_ProjName ""
# PROP Scc_LocalPath ""
CPP=cl.exe
MTL=midl.exe
RSC=rc.exe
!IF "$(CFG)" == "example - Win32 Debug"
# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 1
# PROP BASE Output_Dir "Debug"
# PROP BASE Intermediate_Dir "Debug"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 1
# PROP Output_Dir "Debug"
# PROP Intermediate_Dir "Debug"
# PROP Ignore_Export_Lib 0
# PROP Target_Dir ""
# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "EXAMPLE_EXPORTS" /YX /FD /GZ /c
# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I "$(JAVA_INCLUDE)" /I "$(JAVA_INCLUDE)\win32" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "EXAMPLE_EXPORTS" /YX /FD /GZ /c
# ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32
# ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32
# ADD BASE RSC /l 0x809 /d "_DEBUG"
# ADD RSC /l 0x809 /d "_DEBUG"
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /dll /debug /machine:I386 /pdbtype:sept
# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /dll /debug /machine:I386 /out:"example.dll" /pdbtype:sept
# Begin Special Build Tool
SOURCE="$(InputPath)"
PostBuild_Desc=Java compile post-build step
PostBuild_Cmds=echo on "%JAVA_BIN%\javac" *.java
# End Special Build Tool
!ELSEIF "$(CFG)" == "example - Win32 Release"
# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 0
# PROP BASE Output_Dir "Release"
# PROP BASE Intermediate_Dir "Release"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 0
# PROP Output_Dir "Release"
# PROP Intermediate_Dir "Release"
# PROP Ignore_Export_Lib 0
# PROP Target_Dir ""
# ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "EXAMPLE_EXPORTS" /YX /FD /c
# ADD CPP /nologo /MT /W3 /GX /O2 /I "$(JAVA_INCLUDE)" /I "$(JAVA_INCLUDE)\win32" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "EXAMPLE_EXPORTS" /YX /FD /c
# ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32
# ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32
# ADD BASE RSC /l 0x809 /d "NDEBUG"
# ADD RSC /l 0x809 /d "NDEBUG"
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /dll /machine:I386
# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /dll /machine:I386 /out:"example.dll"
# Begin Special Build Tool
SOURCE="$(InputPath)"
PostBuild_Desc=Java compile post-build step
PostBuild_Cmds=echo on "%JAVA_BIN%\javac" *.java
# End Special Build Tool
!ENDIF
# Begin Target
# Name "example - Win32 Debug"
# Name "example - Win32 Release"
# Begin Group "Source Files"
# PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat"
# Begin Source File
SOURCE=.\example.cxx
# End Source File
# Begin Source File
SOURCE=.\example_wrap.cxx
# End Source File
# End Group
# Begin Group "Header Files"
# PROP Default_Filter "h;hpp;hxx;hm;inl"
# Begin Source File
SOURCE=.\example.h
# End Source File
# End Group
# Begin Group "Resource Files"
# PROP Default_Filter "ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe"
# End Group
# Begin Source File
SOURCE=.\example.i
!IF "$(CFG)" == "example - Win32 Debug"
# Begin Custom Build
InputPath=.\example.i
InputName=example
"$(InputName)_wrap.cxx" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
echo In order to function correctly, please ensure the following environment variables are correctly set:
echo JAVA_INCLUDE: %JAVA_INCLUDE%
echo JAVA_BIN: %JAVA_BIN%
echo on
..\..\..\swig.exe -c++ -java "$(InputPath)"
# End Custom Build
!ELSEIF "$(CFG)" == "example - Win32 Release"
# Begin Custom Build
InputPath=.\example.i
InputName=example
"$(InputName)_wrap.cxx" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
echo In order to function correctly, please ensure the following environment variables are correctly set:
echo JAVA_INCLUDE: %JAVA_INCLUDE%
echo JAVA_BIN: %JAVA_BIN%
echo on
..\..\..\swig.exe -c++ -java "$(InputPath)"
# End Custom Build
!ENDIF
# End Source File
# End Target
# End Project

107
Examples/java/doxygen/example.h Normal file
View file

@ -0,0 +1,107 @@
/*! \file example.h
This file provides a simple set of Shape classes. */
/*! Base class for all shapes.
\author Bob
*/
class Shape {
public:
/*! Default constructor for creating a Shape */
Shape() {
nshapes++;
}
/*! Destructor for destroying a Shape */
virtual ~Shape() {
nshapes--;
}
double x; /*!< x co-ordinate */
double y; /*!< y co-ordinate */
void move(double dx, double dy); /*!< Move a shape to a new co-ordinate
\param dx x co-ordinate
\param dy y co-ordinate */
virtual double area() = 0; /*!< \return the area */
virtual double perimeter() = 0; /*!< \return the perimeter */
static int nshapes; /*!< Number of shapes currently in existence */
};
/*! A class for representing a circle.
\author Jack
*/
class Circle : public Shape {
private:
double radius;
public:
/*! Construct a circle
* \param r radius of the circle */
Circle(double r);
/*! Calculate the area of the circle
* \return calculated area */
virtual double area();
/*! Calculate the perimeter of the circle
* \return calculated perimeter of the circle */
virtual double perimeter();
};
/// A class for representing a square.
class Square : public Shape {
private:
double width;
public:
/** Construct a square
* \param w width of the square */
Square(double w);
/** Calculate the area of the square
* \return calculated area */
virtual double area();
/** Calculate the perimeter of the square
* \return calculated perimeter of the square */
virtual double perimeter();
};
/// A class for representing a rectangle, templated on the type for the rectangle dimensions
template<typename T>
class Rectangle : public Shape {
private:
T height;
T width;
public:
/** Construct a rectangle
* \param h height of the rectangle
* \param w width of the rectangle */
Rectangle(T h, T w) : height(h), width(w) {}
/** Calculate the area of the rectangle
* \return calculated area */
virtual double area() { return width*height; }
/** Calculate the perimeter of the rectangle
* \return calculated perimeter of the rectangle */
virtual double perimeter() { return 2*height + 2*width; }
};
/*! Factory function for creating a square
* \param r width of the square
* \return a fully constructed square */
Square MakeSquare(double r);
/*! Factory function for creating a circle
* \param w radius of the circle
* \return a fully constructed circle */
Circle MakeCircle(double w);
/*! Factory function for creating a rectangle
* \param h height of the rectangle
* \param w width of the rectangle
* \return a fully constructed rectangle */
template<typename T>
Rectangle<T> MakeRectangle(T h, T w) {
return Rectangle<T>(h, w);
}
/*! Total number of circles ever created */
extern int NumCircles;
/// Total number of squares ever created
extern int NumSquares;

17
Examples/java/doxygen/example.i Normal file
View file

@ -0,0 +1,17 @@
%module example
%{
#include "example.h"
%}
%immutable NumSquares;
%immutable NumCircles;
%include "example.h"
/*! - this instantiation uses type int */
%template(RectangleInt) Rectangle<int>;
/*! - this instantiation uses type int */
%template(MakeRectangleInt) MakeRectangle<int>;

63
Examples/java/doxygen/runme.java Normal file
View file

@ -0,0 +1,63 @@
// This example shows simple usage of the wrapped Shape classes.
// The main purpose of this example is to show the doxygen comments translation to JavaDoc comments.
// Users should look at the generated .java files and if javadoc is installed and working on your system,
// the generated Java docs can be viewed in a browser by opening the javadocs/index.html file.
import java.io.*;
public class runme {
static {
try {
System.loadLibrary("example");
} catch (UnsatisfiedLinkError e) {
System.err.println("Native code library failed to load. See the chapter on Dynamic Linking Problems in the SWIG Java documentation for help.\n" + e);
System.exit(1);
}
}
public static void main(String argv[]) throws InterruptedException, IOException
{
System.out.println("Creating some objects:");
Circle c = example.MakeCircle(10);
System.out.println(" Created circle " + c);
Square s = example.MakeSquare(10);
System.out.println(" Created square " + s);
RectangleInt r = example.MakeRectangleInt(10, 20);
System.out.println(" Created rectangle " + r);
System.out.println("\nHere are some properties of the shapes:");
Shape[] shapes = {c, s, r};
for (int i=0; i<shapes.length; i++) {
System.out.println(" " + shapes[i].toString());
System.out.println(" area = " + shapes[i].area());
System.out.println(" perimeter = " + shapes[i].perimeter());
}
String command = "javadoc -quiet -public -d javadocs example.java Shape.java Circle.java Square.java RectangleInt.java";
System.out.println("\nRunning: " + command);
Process p = Runtime.getRuntime().exec(command);
int exitCode = p.waitFor();
System.out.println("javadoc exited with code " + exitCode);
BufferedReader stdout = new BufferedReader(new InputStreamReader(p.getInputStream()));
BufferedReader stderr = new BufferedReader(new InputStreamReader(p.getErrorStream()));
String line = null;
System.out.println("stdout from javadoc:\n");
while ((line = stdout.readLine()) != null) {
System.out.println(line);
}
System.out.println("\nstderr from javadoc:\n");
while ((line = stderr.readLine()) != null) {
System.out.println(line);
}
if (exitCode != 0) {
System.out.println("No java docs were generated!\n");
} else {
System.out.println("javadoc ran successfully, open javadocs/index.html in your browser to view the generated java docs.");
}
}
}

2
Examples/java/variables/runme.java
View file

@ -76,7 +76,7 @@ public class runme {
System.out.println( " Trying to set 'status'" );
try {
Method m = example.class.getDeclaredMethod("setStatus", new Class[] {Integer.class});
m.invoke(example.class, new Object[] {new Integer(0)} );
m.invoke(example.class, new Object[] {Integer.valueOf(0)} );
System.out.println( "Hey, what's going on?!?! This shouldn't work" );
}
catch (NoSuchMethodException e) {

2
Examples/javascript/enum/runme.js
View file

@ -30,5 +30,5 @@ f.enum_test(example.Foo.LUDICROUS);
// enum value BLUE of enum color is accessed as property of cconst
console.log("example.BLUE= " + example.BLUE);
// enum value LUDICROUS of enum Foo::speed is accessed as as property of cconst
// enum value LUDICROUS of enum Foo::speed is accessed as property of cconst
console.log("example.speed.LUDICROUS= " + example.Foo.LUDICROUS);

18
Examples/javascript/exception/example.h
View file

@ -16,30 +16,26 @@ public:
char msg[256];
};
#if defined(_MSC_VER)
#pragma warning(disable: 4290) // C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
#endif
class Test {
public:
int simple() throw(int) {
int simple() {
throw(37);
return 1;
}
int message() throw(const char *) {
int message() {
throw("I died.");
return 1;
}
int hosed() throw(Exc) {
int hosed() {
throw(Exc(42,"Hosed"));
return 1;
}
int unknown() throw(A*) {
int unknown() {
static A a;
throw &a;
return 1;
}
int multi(int x) throw(int, const char *, Exc) {
int multi(int x) {
if (x == 1) throw(37);
if (x == 2) throw("Bleah!");
if (x == 3) throw(Exc(42,"No-go-diggy-die"));
@ -47,7 +43,3 @@ public:
}
};
#if defined(_MSC_VER)
#pragma warning(default: 4290) // C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
#endif

6
Examples/javascript/exception/example.i
View file

@ -7,6 +7,12 @@
%include "std_string.i"
%catches(int) Test::simple();
%catches(const char *) Test::message();
%catches(Exc) Test::hosed();
%catches(A*) Test::unknown();
%catches(int, const char *, Exc) Test::multi(int x);
/* Let's just grab the original header file here */
%include "example.h"

10
Examples/javascript/exception/runme.js
View file

@ -10,7 +10,7 @@ try{
if(error == -1) {
console.log("t.unknown() didn't throw");
} else {
console.log("successfully catched throw in Test::unknown().");
console.log("successfully caught throw in Test::unknown().");
}
}
@ -22,7 +22,7 @@ catch(error){
if(error == -1) {
console.log("t.simple() did not throw");
} else {
console.log("successfully catched throw in Test::simple().");
console.log("successfully caught throw in Test::simple().");
}
}
@ -33,7 +33,7 @@ try{
if(error == -1) {
console.log("t.message() did not throw");
} else {
console.log("successfully catched throw in Test::message().");
console.log("successfully caught throw in Test::message().");
}
}
@ -45,7 +45,7 @@ catch(error){
if(error == -1) {
console.log("t.hosed() did not throw");
} else {
console.log("successfully catched throw in Test::hosed().");
console.log("successfully caught throw in Test::hosed().");
}
}
@ -58,7 +58,7 @@ for (var i=1; i<4; i++) {
if(error == -1) {
console.log("t.multi(" + i + ") did not throw");
} else {
console.log("successfully catched throw in Test::multi().");
console.log("successfully caught throw in Test::multi().");
}
}
}

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