Merge branch 'master' into C
This commit is contained in:
Vadim Zeitlin
commit
55741f9e31
1702 changed files with 57386 additions and 21599 deletions
23
.gitignore
vendored
23
.gitignore
vendored
|
|
@ -66,6 +66,7 @@ CCache/ccache_swig_config.h
|
||||||
CCache/config.h
|
CCache/config.h
|
||||||
CCache/config.log
|
CCache/config.log
|
||||||
CCache/config.status
|
CCache/config.status
|
||||||
|
CCache/config_win32.h
|
||||||
Examples/Makefile
|
Examples/Makefile
|
||||||
Examples/d/example.mk
|
Examples/d/example.mk
|
||||||
Examples/guile/Makefile
|
Examples/guile/Makefile
|
||||||
|
|
@ -85,6 +86,8 @@ swig.spec
|
||||||
# Build Artifacts
|
# Build Artifacts
|
||||||
.dirstamp
|
.dirstamp
|
||||||
CCache/ccache-swig
|
CCache/ccache-swig
|
||||||
|
CCache/ccache-swig.1
|
||||||
|
CCache/web/ccache-swig-man.html
|
||||||
Lib/swigwarn.swg
|
Lib/swigwarn.swg
|
||||||
Source/CParse/parser.c
|
Source/CParse/parser.c
|
||||||
Source/CParse/parser.h
|
Source/CParse/parser.h
|
||||||
|
|
@ -149,11 +152,24 @@ Examples/guile/*/my-guile
|
||||||
Examples/test-suite/java/*/
|
Examples/test-suite/java/*/
|
||||||
Examples/java/*/*.java
|
Examples/java/*/*.java
|
||||||
!Examples/java/*/runme.java
|
!Examples/java/*/runme.java
|
||||||
|
Examples/java/doxygen/javadocs
|
||||||
|
|
||||||
# Javascript
|
# Javascript
|
||||||
Examples/test-suite/javascript/*/
|
Examples/test-suite/javascript/*/
|
||||||
*.gyp
|
*.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
|
# Octave
|
||||||
swigexample*.oct
|
swigexample*.oct
|
||||||
Examples/test-suite/octave/*.oct
|
Examples/test-suite/octave/*.oct
|
||||||
|
|
@ -177,11 +193,16 @@ Examples/php/*/example.php
|
||||||
/__pycache__/
|
/__pycache__/
|
||||||
Examples/test-suite/python/*.py
|
Examples/test-suite/python/*.py
|
||||||
!Examples/test-suite/python/*runme.py
|
!Examples/test-suite/python/*runme.py
|
||||||
Examples/python/*/example.py
|
|
||||||
Examples/python/**/bar.py
|
Examples/python/**/bar.py
|
||||||
Examples/python/**/base.py
|
Examples/python/**/base.py
|
||||||
|
Examples/python/**/example.py
|
||||||
Examples/python/**/foo.py
|
Examples/python/**/foo.py
|
||||||
|
Examples/python/**/robin.py
|
||||||
|
Examples/python/**/runme3.py
|
||||||
Examples/python/**/spam.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
|
# R
|
||||||
Examples/test-suite/r/*.R
|
Examples/test-suite/r/*.R
|
||||||
|
|
|
||||||
385
.travis.yml
385
.travis.yml
|
|
@ -4,155 +4,404 @@ matrix:
|
||||||
- compiler: clang
|
- compiler: clang
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=
|
env: SWIGLANG=
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=
|
env: SWIGLANG=
|
||||||
- os: linux
|
|
||||||
env: SWIGLANG= SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
|
|
||||||
sudo: required
|
sudo: required
|
||||||
dist: trusty
|
dist: xenial
|
||||||
- os: linux
|
- os: linux
|
||||||
env: SWIGLANG= SWIG_CC=gcc-6 SWIG_CXX=g++-6
|
env: SWIGLANG= GCC=4.4
|
||||||
sudo: required
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=csharp
|
env: SWIGLANG=csharp
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=d
|
env: SWIGLANG=d
|
||||||
- compiler: gcc
|
|
||||||
os: linux
|
|
||||||
env: SWIGLANG=go
|
|
||||||
- compiler: gcc
|
|
||||||
os: linux
|
|
||||||
env: SWIGLANG=go VER=1.5
|
|
||||||
sudo: required
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=guile
|
env: SWIGLANG=guile
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=java
|
env: SWIGLANG=java
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=javascript ENGINE=jsc
|
env: SWIGLANG=javascript ENGINE=jsc
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=javascript ENGINE=v8
|
env: SWIGLANG=javascript ENGINE=v8
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=lua
|
env: SWIGLANG=lua
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=lua VER=5.3
|
env: SWIGLANG=lua VER=5.3
|
||||||
sudo: required
|
sudo: required
|
||||||
dist: trusty
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=octave SWIGJOBS=-j2 # 3.2
|
env: SWIGLANG=mzscheme
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=octave SWIGJOBS=-j2 VER=3.8
|
env: SWIGLANG=ocaml
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=octave SWIGJOBS=-j2 VER=4.0
|
env: SWIGLANG=octave SWIGJOBS=-j2
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=perl5
|
env: SWIGLANG=perl5
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=php
|
env: SWIGLANG=php VER=7.0
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python VER=2.4
|
env: SWIGLANG=php VER=7.1
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python VER=2.5
|
env: SWIGLANG=php VER=7.2
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python VER=2.6
|
env: SWIGLANG=php VER=7.3
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python # 2.7
|
env: SWIGLANG=python # 2.7
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python PY3=3 # 3.2
|
env: SWIGLANG=python PY3=3 VER=3.2
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python PY3=3 VER=3.3
|
env: SWIGLANG=python PY3=3 VER=3.3
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python PY3=3 VER=3.4
|
env: SWIGLANG=python PY3=3 VER=3.4
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python PY3=3 VER=3.5
|
env: SWIGLANG=python PY3=3 VER=3.5
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python SWIG_FEATURES=-builtin
|
env: SWIGLANG=python SWIG_FEATURES=-builtin
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5
|
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=python SWIG_FEATURES=-O
|
env: SWIGLANG=python SWIG_FEATURES=-O
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=r
|
env: SWIGLANG=r
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=ruby
|
env: SWIGLANG=ruby VER=1.9
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=scilab
|
env: SWIGLANG=scilab
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- compiler: gcc
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=tcl
|
env: SWIGLANG=tcl
|
||||||
|
sudo: required
|
||||||
|
dist: xenial
|
||||||
- os: linux
|
- 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
|
sudo: required
|
||||||
dist: trusty
|
dist: trusty
|
||||||
- os: linux
|
- os: linux
|
||||||
env: SWIGLANG=java SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
|
env: SWIGLANG=python CPP11=1
|
||||||
sudo: required
|
sudo: required
|
||||||
dist: trusty
|
dist: xenial
|
||||||
- os: linux
|
- 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
|
sudo: required
|
||||||
dist: trusty
|
dist: xenial
|
||||||
- os: linux
|
- os: linux
|
||||||
env: SWIGLANG=csharp SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
|
env: SWIGLANG=ruby CPP11=1
|
||||||
sudo: required
|
sudo: required
|
||||||
dist: trusty
|
dist: xenial
|
||||||
- os: linux
|
- os: linux
|
||||||
env: SWIGLANG=java SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
|
env: SWIGLANG=tcl CPP11=1
|
||||||
sudo: required
|
sudo: required
|
||||||
dist: trusty
|
dist: xenial
|
||||||
- os: linux
|
- os: linux
|
||||||
env: SWIGLANG=python SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
|
env: SWIGLANG=csharp GCC=6 CPP14=1
|
||||||
sudo: required
|
sudo: required
|
||||||
dist: trusty
|
dist: xenial
|
||||||
- os: osx
|
- os: linux
|
||||||
env: SWIGLANG= SWIG_CC=gcc-4.2 SWIG_CXX=g++-4.2
|
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
|
- compiler: clang
|
||||||
os: osx
|
os: osx
|
||||||
env: SWIGLANG=
|
env: SWIGLANG=
|
||||||
|
|
@ -173,10 +422,10 @@ matrix:
|
||||||
env: SWIGLANG=lua
|
env: SWIGLANG=lua
|
||||||
- compiler: clang
|
- compiler: clang
|
||||||
os: osx
|
os: osx
|
||||||
env: SWIGLANG=perl5
|
env: SWIGLANG=octave SWIGJOBS=-j2
|
||||||
- compiler: clang
|
- compiler: clang
|
||||||
os: osx
|
os: osx
|
||||||
env: SWIGLANG=php
|
env: SWIGLANG=perl5
|
||||||
- compiler: clang
|
- compiler: clang
|
||||||
os: osx
|
os: osx
|
||||||
env: SWIGLANG=python
|
env: SWIGLANG=python
|
||||||
|
|
@ -189,35 +438,54 @@ matrix:
|
||||||
- compiler: clang
|
- compiler: clang
|
||||||
os: osx
|
os: osx
|
||||||
env: SWIGLANG=tcl
|
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:
|
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
|
- compiler: gcc
|
||||||
os: linux
|
os: linux
|
||||||
env: SWIGLANG=ocaml
|
env: SWIGLANG=ocaml
|
||||||
# Not quite working yet
|
sudo: required
|
||||||
- compiler: gcc
|
dist: xenial
|
||||||
os: linux
|
|
||||||
env: SWIGLANG=python SWIG_FEATURES=-O
|
|
||||||
before_install:
|
before_install:
|
||||||
- date -u
|
- date -u
|
||||||
- uname -a
|
- 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" = "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
|
- if test "$TRAVIS_OS_NAME" = "osx"; then sysctl -a | grep brand_string; fi
|
||||||
# Travis overrides CC environment with compiler predefined values
|
# Travis overrides CC environment with compiler predefined values
|
||||||
- if test -n "$SWIG_CC"; then export CC="$SWIG_CC"; fi
|
- if test -n "$GCC"; then export CC="gcc-$GCC" && export CXX="g++-$GCC"; fi
|
||||||
- if test -n "$SWIG_CXX"; then export CXX="$SWIG_CXX"; fi
|
|
||||||
install:
|
install:
|
||||||
- if test "$TRAVIS_OS_NAME" = "linux"; then source Tools/travis-linux-install.sh; fi
|
- 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 "$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
|
- ls -la $(which $CC) $(which $CXX) && $CC --version && $CXX --version
|
||||||
- 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
|
|
||||||
script:
|
script:
|
||||||
- echo 'Configuring...' && echo -en 'travis_fold:start:script.1\\r'
|
- 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
|
- if test -n "$SWIGLANG"; then CONFIGOPTS+=(--without-alllang --with-$WITHLANG); fi
|
||||||
- echo "${CONFIGOPTS[@]}"
|
- echo "${CONFIGOPTS[@]}"
|
||||||
- ./autogen.sh && mkdir -p build/build && cd build/build && ../../configure "${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'
|
- echo 'Cleaning...' && echo -en 'travis_fold:start:script.3\\r'
|
||||||
- make check-maintainer-clean && ../../configure $CONFIGOPTS
|
- make check-maintainer-clean && ../../configure $CONFIGOPTS
|
||||||
- echo -en 'travis_fold:end:script.3\\r'
|
- echo -en 'travis_fold:end:script.3\\r'
|
||||||
branches:
|
|
||||||
only:
|
|
||||||
- master
|
|
||||||
|
|
|
||||||
20
ANNOUNCE
20
ANNOUNCE
|
|
@ -1,8 +1,8 @@
|
||||||
*** ANNOUNCE: SWIG 3.0.11 (in progress) ***
|
*** ANNOUNCE: SWIG 4.0.1 (in progress) ***
|
||||||
|
|
||||||
http://www.swig.org
|
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?
|
What is SWIG?
|
||||||
=============
|
=============
|
||||||
|
|
@ -10,13 +10,11 @@ What is SWIG?
|
||||||
SWIG is a software development tool that reads C/C++ header files and
|
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
|
generates the wrapper code needed to make C and C++ code accessible
|
||||||
from other programming languages including Perl, Python, Tcl, Ruby,
|
from other programming languages including Perl, Python, Tcl, Ruby,
|
||||||
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme, CHICKEN),
|
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D,
|
||||||
D, Ocaml, Pike, Modula-3, Octave, R, Scilab, Common Lisp (CLISP,
|
Ocaml, Octave, R, Scilab. SWIG can also export its parse tree in
|
||||||
Allegro CL, CFFI, UFFI). SWIG can also export its parse tree in
|
the form of XML. Major applications of SWIG include generation of
|
||||||
the form of XML and Lisp s-expressions. Major applications of SWIG
|
scripting language extension modules, rapid prototyping, testing,
|
||||||
include generation of scripting language extension modules, rapid
|
and user interface development for large C/C++ systems.
|
||||||
prototyping, testing, and user interface development for large
|
|
||||||
C/C++ systems.
|
|
||||||
|
|
||||||
Release Notes
|
Release Notes
|
||||||
=============
|
=============
|
||||||
|
|
@ -27,11 +25,11 @@ Availability
|
||||||
============
|
============
|
||||||
The release is available for download on Sourceforge at
|
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
|
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,
|
Please report problems with this release to the swig-devel mailing list,
|
||||||
details at http://www.swig.org/mail.html.
|
details at http://www.swig.org/mail.html.
|
||||||
|
|
|
||||||
|
|
@ -8,6 +8,7 @@ bindir=@bindir@
|
||||||
mandir=@mandir@
|
mandir=@mandir@
|
||||||
INSTALLCMD=@INSTALL@
|
INSTALLCMD=@INSTALL@
|
||||||
PACKAGE_NAME=@PACKAGE_NAME@
|
PACKAGE_NAME=@PACKAGE_NAME@
|
||||||
|
PROGRAM_NAME=@PROGRAM_NAME@
|
||||||
# Soft link test can be skipped on systems that don't support soft linking
|
# Soft link test can be skipped on systems that don't support soft linking
|
||||||
NOSOFTLINKSTEST=
|
NOSOFTLINKSTEST=
|
||||||
|
|
||||||
|
|
@ -17,13 +18,10 @@ SWIG=swig
|
||||||
SWIG_LIB=../$(srcdir)/../Lib
|
SWIG_LIB=../$(srcdir)/../Lib
|
||||||
EXEEXT=@EXEEXT@
|
EXEEXT=@EXEEXT@
|
||||||
|
|
||||||
# Use standard autoconf approach to transform executable name using --program-prefix and --program-suffix
|
|
||||||
transform = @program_transform_name@
|
|
||||||
|
|
||||||
LIBS= @LIBS@
|
LIBS= @LIBS@
|
||||||
OBJS= ccache.o mdfour.o hash.o execute.o util.o args.o stats.o \
|
OBJS= ccache.o mdfour.o hash.o execute.o util.o args.o stats.o \
|
||||||
cleanup.o snprintf.o unify.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)
|
all: $(PACKAGE_NAME)$(EXEEXT)
|
||||||
|
|
||||||
|
|
@ -32,7 +30,7 @@ Makefile: $(srcdir)/Makefile.in ./config.status
|
||||||
$(SHELL) ./config.status
|
$(SHELL) ./config.status
|
||||||
|
|
||||||
# Note that HTML documentation is actually generated and used from the main SWIG documentation Makefile
|
# 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)
|
$(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
|
||||||
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
|
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
|
||||||
|
|
@ -40,40 +38,43 @@ $(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
|
||||||
$(srcdir)/$(PACKAGE_NAME).1: $(srcdir)/ccache.yo
|
$(srcdir)/$(PACKAGE_NAME).1: $(srcdir)/ccache.yo
|
||||||
-yodl2man -o $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/ccache.yo
|
-yodl2man -o $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/ccache.yo
|
||||||
|
|
||||||
$(srcdir)/web/ccache-man.html: $(srcdir)/ccache.yo
|
$(srcdir)/web/$(PACKAGE_NAME)-man.html: $(srcdir)/ccache.yo
|
||||||
yodl2html -o $(srcdir)/web/ccache-man.html $(srcdir)/ccache.yo
|
yodl2html -o $(srcdir)/web/$(PACKAGE_NAME)-man.html $(srcdir)/ccache.yo
|
||||||
|
|
||||||
install: $(PACKAGE_NAME)$(EXEEXT)
|
install: $(PACKAGE_NAME)$(EXEEXT)
|
||||||
@echo "Installing $(PACKAGE_NAME)"
|
@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} -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
|
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} -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)
|
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
|
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)
|
/bin/rm -f $(OBJS) *~ $(PACKAGE_NAME)$(EXEEXT)
|
||||||
|
|
||||||
|
clean-docs:
|
||||||
|
rm -f $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/$(PACKAGE_NAME)-man.html
|
||||||
|
|
||||||
test: test.sh
|
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
|
check: test
|
||||||
|
|
||||||
distclean: clean
|
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
|
/bin/rm -rf autom4te.cache
|
||||||
|
|
||||||
maintainer-clean: distclean
|
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
|
# FIXME: To fix this, test.sh needs to be able to take ccache from the
|
||||||
|
|
|
||||||
|
|
@ -6,7 +6,7 @@
|
||||||
#include "config.h"
|
#include "config.h"
|
||||||
#else
|
#else
|
||||||
#include <sys/locking.h>
|
#include <sys/locking.h>
|
||||||
#define PACKAGE_NAME "ccache-swig.exe"
|
#include "config_win32.h"
|
||||||
#endif
|
#endif
|
||||||
|
|
||||||
#include <stdio.h>
|
#include <stdio.h>
|
||||||
|
|
@ -51,7 +51,7 @@
|
||||||
#define STATUS_FATAL 4
|
#define STATUS_FATAL 4
|
||||||
#define STATUS_NOCACHE 5
|
#define STATUS_NOCACHE 5
|
||||||
|
|
||||||
#define MYNAME PACKAGE_NAME
|
#define MYNAME PROGRAM_NAME
|
||||||
|
|
||||||
#define LIMIT_MULTIPLE 0.8
|
#define LIMIT_MULTIPLE 0.8
|
||||||
|
|
||||||
|
|
|
||||||
3
CCache/config_win32.h.in
Normal file
3
CCache/config_win32.h.in
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
#if !defined(PROGRAM_NAME)
|
||||||
|
#define PROGRAM_NAME "@PROGRAM_NAME@.exe"
|
||||||
|
#endif
|
||||||
|
|
@ -7,6 +7,7 @@ AC_CONFIG_SRCDIR([ccache.h])
|
||||||
AC_MSG_NOTICE([Configuring ccache])
|
AC_MSG_NOTICE([Configuring ccache])
|
||||||
|
|
||||||
AC_CONFIG_HEADER(config.h)
|
AC_CONFIG_HEADER(config.h)
|
||||||
|
AC_CONFIG_FILES([config_win32.h])
|
||||||
|
|
||||||
dnl Checks for programs.
|
dnl Checks for programs.
|
||||||
AC_PROG_CC
|
AC_PROG_CC
|
||||||
|
|
@ -14,6 +15,20 @@ AC_PROG_CPP
|
||||||
AC_PROG_INSTALL
|
AC_PROG_INSTALL
|
||||||
AC_ARG_PROGRAM # for program_transform_name
|
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,
|
AC_DEFINE([_GNU_SOURCE], 1,
|
||||||
[Define _GNU_SOURCE so that we get all necessary prototypes])
|
[Define _GNU_SOURCE so that we get all necessary prototypes])
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -292,6 +292,7 @@ static size_t dopr(char *buffer, size_t maxlen, const char *format, va_list args
|
||||||
break;
|
break;
|
||||||
case 'X':
|
case 'X':
|
||||||
flags |= DP_F_UP;
|
flags |= DP_F_UP;
|
||||||
|
/* FALLTHROUGH */
|
||||||
case 'x':
|
case 'x':
|
||||||
flags |= DP_F_UNSIGNED;
|
flags |= DP_F_UNSIGNED;
|
||||||
if (cflags == DP_C_SHORT)
|
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;
|
break;
|
||||||
case 'E':
|
case 'E':
|
||||||
flags |= DP_F_UP;
|
flags |= DP_F_UP;
|
||||||
|
/* FALLTHROUGH */
|
||||||
case 'e':
|
case 'e':
|
||||||
if (cflags == DP_C_LDOUBLE)
|
if (cflags == DP_C_LDOUBLE)
|
||||||
fvalue = va_arg (args, 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;
|
break;
|
||||||
case 'G':
|
case 'G':
|
||||||
flags |= DP_F_UP;
|
flags |= DP_F_UP;
|
||||||
|
/* FALLTHROUGH */
|
||||||
case 'g':
|
case 'g':
|
||||||
if (cflags == DP_C_LDOUBLE)
|
if (cflags == DP_C_LDOUBLE)
|
||||||
fvalue = va_arg (args, LDOUBLE);
|
fvalue = va_arg (args, LDOUBLE);
|
||||||
|
|
|
||||||
|
|
@ -20,7 +20,12 @@ fi
|
||||||
PATH="`echo $PATH | \
|
PATH="`echo $PATH | \
|
||||||
sed -e 's!:/usr\(/local\)*/lib\([0-9]\)*/ccache\(/\)*!!g'`"
|
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.$$
|
TESTDIR=test.$$
|
||||||
|
|
||||||
test_failed() {
|
test_failed() {
|
||||||
|
|
@ -406,6 +411,10 @@ swigtests() {
|
||||||
# main program
|
# main program
|
||||||
rm -rf $TESTDIR
|
rm -rf $TESTDIR
|
||||||
mkdir $TESTDIR
|
mkdir $TESTDIR
|
||||||
|
if test -n "$CCACHE_PROG"; then
|
||||||
|
ln -s $CCACHE $TESTDIR/$CCACHE_PROG
|
||||||
|
CCACHE=./$CCACHE_PROG
|
||||||
|
fi
|
||||||
cd $TESTDIR || exit 1
|
cd $TESTDIR || exit 1
|
||||||
|
|
||||||
unset CCACHE_DIR
|
unset CCACHE_DIR
|
||||||
|
|
@ -442,14 +451,16 @@ swigtests
|
||||||
|
|
||||||
if test -z "$NOSOFTLINKSTEST"; then
|
if test -z "$NOSOFTLINKSTEST"; then
|
||||||
testsuite="link"
|
testsuite="link"
|
||||||
ln -s $CCACHE $COMPILER
|
compilername=`basename $COMPILER`
|
||||||
CCACHE_COMPILE="./$COMPILER"
|
ln -s $CCACHE ./$compilername
|
||||||
|
CCACHE_COMPILE="./$compilername"
|
||||||
basetests
|
basetests
|
||||||
rm "./$COMPILER"
|
rm "./$compilername"
|
||||||
ln -s $CCACHE $SWIG
|
compilername=`basename $SWIG`
|
||||||
CCACHE_COMPILE="./$SWIG"
|
ln -s $CCACHE ./$compilername
|
||||||
|
CCACHE_COMPILE="./$compilername"
|
||||||
swigtests
|
swigtests
|
||||||
rm "./$SWIG"
|
rm "./$compilername"
|
||||||
else
|
else
|
||||||
echo "skipping testsuite link"
|
echo "skipping testsuite link"
|
||||||
fi
|
fi
|
||||||
|
|
|
||||||
145
CHANGES.current
145
CHANGES.current
|
|
@ -1,97 +1,72 @@
|
||||||
Below are the changes for the current release.
|
Below are the changes for the current release.
|
||||||
See the CHANGES file for changes in older releases.
|
See the CHANGES file for changes in older releases.
|
||||||
See the RELEASENOTES file for a summary of changes in each release.
|
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
|
2019-07-23: smithx
|
||||||
[C#] Patch #786 Keyword rename to be CLS compliant by adding an underscore
|
[C#] #1530 #1532 Fix marshalling of std::wstring to C#.
|
||||||
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-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 ***
|
*** POTENTIAL INCOMPATIBILITY ***
|
||||||
|
|
||||||
2016-09-09: olly
|
2019-06-06: bkotzz
|
||||||
[Python] Fix import handling for Python 2.6 to work in a frozen
|
[Java] #1552 Improve performance in Java std::vector constructor wrapper that takes
|
||||||
application. Fixes #145, reported by Thomas Kluyver.
|
a native Java array as input.
|
||||||
|
|
||||||
2016-09-02: smarchetto
|
2019-06-03: olly
|
||||||
[Scilab] Pointers are mapped to mlist instead of tlist
|
[Python] Fix regression in implicit_conv handling of tuples,
|
||||||
(mlist better for scilab overloading)
|
introduced in SWIG 4.0.0. Fixes #1553, reported by Alexandre
|
||||||
|
Duret-Lutz.
|
||||||
|
|
||||||
2016-09-02: olly
|
2019-05-24: wsfulton
|
||||||
[PHP] Fix "out" typemap for member function pointers and "in"
|
[Octave] Fix detection of Octave on MacOS.
|
||||||
typemap for char INPUT[ANY].
|
|
||||||
|
|
||||||
2016-09-01: wsfulton
|
2019-05-24: opoplawski
|
||||||
[Python] More efficient Python slicing.
|
[Octave] #1522 Adapt OCTAVE_LDFLAGS for Octave 5.1.
|
||||||
Call reserve for container types that support it to avoid repeated
|
|
||||||
memory reallocations for new slices or slices that grow in size.
|
|
||||||
|
|
||||||
2016-09-01: wsfulton
|
2019-05-22: ferdynator
|
||||||
[Python] #771 - Make builtin types hashable by default.
|
[PHP] #1528 Don't add a closing '?>' PHP tag to generated files.
|
||||||
Default hash is the underlying C/C++ pointer. This matches up with testing for
|
PSR-2 says it MUST be omitted for files containing only PHP.
|
||||||
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.
|
|
||||||
|
|
|
||||||
|
|
@ -20,6 +20,7 @@ Active SWIG Developers:
|
||||||
Oliver Buchtala (oliver.buchtala@gmail.com) (Javascript)
|
Oliver Buchtala (oliver.buchtala@gmail.com) (Javascript)
|
||||||
Neha Narang (narangneha03@gmail.com) (Javascript)
|
Neha Narang (narangneha03@gmail.com) (Javascript)
|
||||||
Simon Marchetto (simon.marchetto@scilab-enterprises.com) (Scilab)
|
Simon Marchetto (simon.marchetto@scilab-enterprises.com) (Scilab)
|
||||||
|
Zackery Spytz (zspytz@gmail.com) (OCaml, SWIG core)
|
||||||
|
|
||||||
Past SWIG developers and major contributors include:
|
Past SWIG developers and major contributors include:
|
||||||
Dave Beazley (dave-swig@dabeaz.com) (SWIG core, Python, Tcl, Perl)
|
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)
|
Mikel Bancroft (mikel@franz.com) (Allegro CL)
|
||||||
Surendra Singhi (efuzzyone@netscape.net) (CLISP, CFFI)
|
Surendra Singhi (efuzzyone@netscape.net) (CLISP, CFFI)
|
||||||
Marcelo Matus (mmatus@acms.arizona.edu) (SWIG core, Python, UTL[python,perl,tcl,ruby])
|
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)
|
Lyle Johnson (lyle@users.sourceforge.net) (Ruby)
|
||||||
Charlie Savage (cfis@interserv.com) (Ruby)
|
Charlie Savage (cfis@interserv.com) (Ruby)
|
||||||
Thien-Thi Nguyen (ttn@glug.org) (build/test/misc)
|
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)
|
John Lenz (Guile, MzScheme updates, Chicken module, runtime system)
|
||||||
Baozeng Ding <sploving1@163.com> (Scilab)
|
Baozeng Ding <sploving1@163.com> (Scilab)
|
||||||
Ian Lance Taylor (Go)
|
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)
|
Stefan Zager (szager@gmail.com) (Python)
|
||||||
Vincent Couvert (Scilab)
|
Vincent Couvert (Scilab)
|
||||||
Sylvestre Ledru (Scilab)
|
Sylvestre Ledru (Scilab)
|
||||||
|
|
|
||||||
|
|
@ -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 <class T> swap(T& a, T& 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 <class T> swap(T& a, T& 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&& as an argument) and
|
|
||||||
operator=(ClassType&&):</P>
|
|
||||||
<PRE>class MyClass {
|
|
||||||
MyClass(MyClass&& p) : ptr(p.ptr) {p.ptr = 0;}
|
|
||||||
MyClass& operator=(MyClass&& 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&& to Swig parser. Added testcase
|
|
||||||
cpp11_rvalue_reference.i. Operator && is treated the same as
|
|
||||||
operator &. 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 "return expr",
|
|
||||||
where expr is a constant expression.
|
|
||||||
</P>
|
|
||||||
<P>A keyword "constexpr" 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 "final"
|
|
||||||
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<MyClass>;'. 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<T>. New symbols {} are introduced for the
|
|
||||||
initializer lists.
|
|
||||||
</P>
|
|
||||||
<P>One can now use:
|
|
||||||
</P>
|
|
||||||
<PRE> class A {
|
|
||||||
public:
|
|
||||||
A( std::initializer_list<int> );
|
|
||||||
};
|
|
||||||
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 {"SomeName", 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) -> 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 '->' 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<int> someList;
|
|
||||||
int total = 0;
|
|
||||||
std::for_each( someList.begin(), someList.end(), [&total](int x) {total += x} );
|
|
||||||
std::cout << total;</PRE><P>
|
|
||||||
Parameters inside the [] are the visible parameters of the lambda
|
|
||||||
functions. These can be & (references), = (copies), variable name
|
|
||||||
(variable copy), &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->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< typename LHS, typename RHS>
|
|
||||||
decltype(lhs+rhs) AddingFunc(const LHS &lhs, const RHS &rhs) {return lhs + rhs;} //Not legal C++11</PRE><P>
|
|
||||||
The solution C++11 offers is the combination of the 'auto' keyword
|
|
||||||
before and '-> rettype' after the function declaration:</P>
|
|
||||||
<PRE>template< typename LHS, typename RHS>
|
|
||||||
auto AddingFunc(const LHS &lhs, const RHS &rhs) -> 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) -> int;
|
|
||||||
};
|
|
||||||
|
|
||||||
auto SomeStruct::FuncName(int x, int y) -> int {
|
|
||||||
return x + y;
|
|
||||||
}</PRE><P>
|
|
||||||
Done: Added support for the 'auto' return type. Added support for the
|
|
||||||
'-> 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 "concepts". 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&id=LessThanComparable">?</A>
|
|
||||||
instead of "class" or "typename"):
|
|
||||||
</P>
|
|
||||||
<PRE> template<LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=LessThanComparable">?</A> T>
|
|
||||||
const T& min(const T &x, const T &y) {
|
|
||||||
return y < x ? y : x;
|
|
||||||
}</PRE><P>
|
|
||||||
Extended syntax (requires conditions are separated with &&,
|
|
||||||
|| or !):
|
|
||||||
</P>
|
|
||||||
<PRE> template< typename T> requires LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=LessThanComparable">?</A><T>
|
|
||||||
const T& min(const T &x, const T &y) {
|
|
||||||
return y < 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&id=LessThanComparable">?</A>< typename T > {
|
|
||||||
bool operator<(T,T);
|
|
||||||
requires GreaterThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=GreaterThanComparable">?</A><T>;
|
|
||||||
typename value_type;
|
|
||||||
typename reference;
|
|
||||||
};</PRE><P>
|
|
||||||
Concept maps allow usage of a specific type:
|
|
||||||
</P>
|
|
||||||
<PRE> template< typename T>
|
|
||||||
concept_map InputIterator<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=InputIterator">?</A><T*> {
|
|
||||||
typedef T value_type ;
|
|
||||||
typedef T& 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< typename X> {
|
|
||||||
typename value_type;
|
|
||||||
void push(X&, const value_type&);
|
|
||||||
void pop(X&);
|
|
||||||
value_type top(const X&);
|
|
||||||
bool empty(const X&);
|
|
||||||
};
|
|
||||||
template< typename T>
|
|
||||||
concept_map Stack<std::vector<T> > {
|
|
||||||
typedef T value_type;
|
|
||||||
void push(std::vector<T>& v, const T& x) { v.push_back(x); }
|
|
||||||
void pop(std::vector<T>& v) { v.pop_back(); }
|
|
||||||
T top(const std::vector<T>& v) { return v.back(); }
|
|
||||||
bool empty(const std::vector<T>& 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< typename Op, typename T> : CopyConstructible<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=CopyConstructible">?</A><T> {
|
|
||||||
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 <cstddef>.
|
|
||||||
</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 "int".
|
|
||||||
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
|
|
||||||
"Approach 1". 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 "explicit" 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< typename first, typename second, int third>
|
|
||||||
class SomeType;
|
|
||||||
|
|
||||||
template< typename second>
|
|
||||||
typedef SomeType<OtherType, second, 5> 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< typename first, typename second, int third>
|
|
||||||
class SomeType;
|
|
||||||
|
|
||||||
template< typename second>
|
|
||||||
using TypedefName = SomeType<OtherType, second, 5>;</PRE><P>
|
|
||||||
Here we created a new wrapper TypedefName taking one template
|
|
||||||
argument <second> which creates a type SomeType<OtherType,
|
|
||||||
second, 5>. 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<int> 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<typename... Values> class tuple;</PRE><P>
|
|
||||||
This can be used for example:</P>
|
|
||||||
<PRE STYLE="margin-bottom: 0.5cm">class tuple<int, std::vector<int>, std::map<std::string, std::vector<int>>> 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 == '%' && *(++s) != '%')
|
|
||||||
throw std::runtime_error("invalid format string: missing arguments");
|
|
||||||
std::cout << *s++;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
template<typename T, typename... Args>
|
|
||||||
void printf(const char* s, T value, Args... args) { // recursive action – split previous args to value + args
|
|
||||||
while (*s) {
|
|
||||||
if (*s == '%' && *(++s) != '%') {
|
|
||||||
std::cout << value;
|
|
||||||
printf(*s ? ++s : s, args...); // call even when *s == 0 to detect extra arguments
|
|
||||||
return;
|
|
||||||
}
|
|
||||||
std::cout << *s++;
|
|
||||||
}
|
|
||||||
throw std::logic_error("extra arguments provided to printf");
|
|
||||||
}</PRE><P>
|
|
||||||
The tricky part is that variadic templates can unpack actually
|
|
||||||
anywhere – including the class inheritance :(</P>
|
|
||||||
<PRE>template <typename... BaseClasses> class ClassName : public BaseClasses... {
|
|
||||||
public:
|
|
||||||
|
|
||||||
ClassName (BaseClasses&&... 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<typename ...Args> struct SomeStruct {
|
|
||||||
static const int size = sizeof...(Args);
|
|
||||||
}
|
|
||||||
// SomeStruct<Type1, Type2>::size is 2 and SomeStruct<>::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"DELIMITER[, ]DELIMITER" 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 = "hello"_mySuffix;
|
|
||||||
</P>
|
|
||||||
<P>The syntax is similar to other operator overloading functions:
|
|
||||||
</P>
|
|
||||||
<PRE STYLE="margin-bottom: 0.5cm"> OutputType operator "" _mySuffix(const char * string_values);</PRE><P>
|
|
||||||
The null terminated const char* is the string between the "".
|
|
||||||
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 "" _mySuffix(const char * string_values, size_t num_chars);
|
|
||||||
OutputType operator "" _mySuffix(const wchar_t * string_values, size_t num_chars);
|
|
||||||
OutputType operator "" _mySuffix(const char16_t * string_values, size_t num_chars);
|
|
||||||
OutputType operator "" _mySuffix(const char32_t * string_values, size_t num_chars);
|
|
||||||
OutputType operator "" _mySuffix(int value); /* cooked version - ie. atoi() of string */</PRE><P>
|
|
||||||
Another possibility is to use variadic templates:
|
|
||||||
</P>
|
|
||||||
<PRE> template<char...> OutputType operator "" _mySuffix();
|
|
||||||
OutputType someVariable = "1234"_mySuffix;</PRE><P>
|
|
||||||
This instantiates the literal processing function as
|
|
||||||
operator""_Suffix<'1', '2', '3', '4'>. 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 "thread_local" which marks
|
|
||||||
the following variable dynamically located depending on the current
|
|
||||||
thread when using the address-of (&) operator.
|
|
||||||
</P>
|
|
||||||
<P>Syntax:
|
|
||||||
</P>
|
|
||||||
<PRE> struct A {
|
|
||||||
thread_local int val;
|
|
||||||
};</PRE><P>
|
|
||||||
Done: Add "thread_local" 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 "default" and "delete" are introduced.
|
|
||||||
The syntax is similar to declaration of pure virtual function:
|
|
||||||
</P>
|
|
||||||
<PRE> struct NonCopyable {
|
|
||||||
NonCopyable & operator=(const NonCopyable&) = delete; /* Removes operator= */
|
|
||||||
NonCopyable(const NonCopyable&) = 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<class T> void f(T) = delete; /* Only accept int */
|
|
||||||
};</PRE><P>
|
|
||||||
Ignored: Swig already parses the keywords "= delete" and "=
|
|
||||||
default". 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 <typename T>
|
|
||||||
struct Check {
|
|
||||||
static_assert(sizeof(int) <= sizeof(T), "not big enough");
|
|
||||||
};</PRE><P>
|
|
||||||
Done: Added syntax support for "static_assert()". 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 <class ...Types> class tuple;</PRE><P>
|
|
||||||
Constructor is automatically generated filling the tuple elements.
|
|
||||||
get<X> function is introduced to get the Xth element in the
|
|
||||||
tuple.</P>
|
|
||||||
<PRE>typedef tuple< int, double, long &, const char * > test_tuple ;
|
|
||||||
long lengthy = 12 ;
|
|
||||||
test_tuple proof( 18, 6.5, lengthy, "Ciao!" ) ;
|
|
||||||
lengthy = get<0>(proof) ; // Assign to 'lengthy' the value 18.
|
|
||||||
get<3>(proof) = " Beautiful!" ; // 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< int , double, string > tuple_1 t1 ;
|
|
||||||
typedef tuple< char, short , const char * > tuple_2 t2( 'X', 2, "Hola!" ) ;
|
|
||||||
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<> class.</P>
|
|
||||||
<H2>Hash tables [TODO]</H2>
|
|
||||||
<P>C++11 introduces the "unordered" 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 "unordered" 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 <utility>) 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<int ( int, int )> 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 <type_traits> 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< int B, int N >
|
|
||||||
struct Pow {
|
|
||||||
// recursive call and recombination.
|
|
||||||
enum{ value = B*Pow< B, N-1 >::value };
|
|
||||||
};
|
|
||||||
template< int B > struct Pow< B, 0 > // <EM>N == 0</EM> condition of termination.
|
|
||||||
{
|
|
||||||
enum{ value = 1 };
|
|
||||||
};
|
|
||||||
int quartic_of_three = Pow< 3, 4 >::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< bool B > struct algorithm {
|
|
||||||
template< class T1, class T2 > int do_it( T1 &, T2 & ) { /*...*/ }
|
|
||||||
};
|
|
||||||
// Second way of operating.
|
|
||||||
template<> struct algorithm<true> {
|
|
||||||
template< class T1, class T2 > int do_it( T1, T2 ) { /*...*/ }
|
|
||||||
};
|
|
||||||
// Instantiating 'elaborate' will automatically instantiate the correct way to operate.
|
|
||||||
template< class T1, class T2 > 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< is_integral<T1>::value && is_floating_point<T2>::value >::do_it( A, B );
|
|
||||||
}</PRE><P>
|
|
||||||
Swig correctly parses the syntax for template<bool>,
|
|
||||||
template<class T> and template<>.
|
|
||||||
</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< class Obj >
|
|
||||||
class calculus_ver2 {
|
|
||||||
public:
|
|
||||||
template< class Arg >
|
|
||||||
typename std::result_of<Obj(Arg)>::type operator()( Arg& 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
341
Doc/Devel/plan-gsoc-2012.txt
Normal 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
|
||||||
|
|
||||||
|
|
@ -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
|
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
|
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
|
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
|
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
|
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
|
These functions are not required and their API is not formalized, but almost all
|
||||||
language modules implement them for consistency across languages. Throughout
|
language modules implement them for consistency across languages. Throughout
|
||||||
this discussion, I will use LangType to represent the underlying language type
|
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)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -236,7 +236,7 @@ The following functions can be used to help debug SWIG parse trees.
|
||||||
|
|
||||||
<blockquote>
|
<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
|
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.
|
This function is called by the <tt>-debug-tags</tt> option to SWIG.
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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
|
module, we would like to acknowledge the current and ongoing
|
||||||
work by developers in the open source lisp community that are
|
work by developers in the open source lisp community that are
|
||||||
working on similar interfaces to implementation-independent
|
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
|
work can only benefit the lisp community, and we would not
|
||||||
be unhappy to see some enterprising folk use this work to add
|
be unhappy to see some enterprising folk use this work to add
|
||||||
to it.
|
to it.
|
||||||
</p>
|
</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>
|
<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
|
interface can also be generated without library headers by supplying a
|
||||||
simple text file--called the interface file, which is typically named
|
simple text file--called the interface file, which is typically named
|
||||||
with a <tt>.i</tt> extension--containing any foreign declarations of
|
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
|
interface file with directives to parse the needed headers. A straight
|
||||||
parse of library headers will result in usable code, but SWIG
|
parse of library headers will result in usable code, but SWIG
|
||||||
directives provides much freedom in how a user might tailor the
|
directives provides much freedom in how a user might tailor the
|
||||||
|
|
@ -280,39 +280,39 @@ actual function.
|
||||||
|
|
||||||
<div class="code">example_wrap.i
|
<div class="code">example_wrap.i
|
||||||
<pre>
|
<pre>
|
||||||
... lots of SWIG internals ...
|
... lots of SWIG internals ...
|
||||||
|
|
||||||
EXPORT int ACL___fact__SWIG_0 (char *larg1) {
|
EXPORT int ACL___fact__SWIG_0 (char *larg1) {
|
||||||
int lresult = (int)0 ;
|
int lresult = (int)0 ;
|
||||||
char *arg1 = (char *) 0 ;
|
char *arg1 = (char *) 0 ;
|
||||||
int result;
|
int result;
|
||||||
|
|
||||||
arg1 = larg1;
|
arg1 = larg1;
|
||||||
try {
|
try {
|
||||||
result = (int)fact(arg1);
|
result = (int)fact(arg1);
|
||||||
|
|
||||||
lresult = result;
|
lresult = result;
|
||||||
return lresult;
|
return lresult;
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
return (int)0;
|
return (int)0;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
EXPORT int ACL___fact__SWIG_1 (int larg1) {
|
EXPORT int ACL___fact__SWIG_1 (int larg1) {
|
||||||
int lresult = (int)0 ;
|
int lresult = (int)0 ;
|
||||||
int arg1 ;
|
int arg1 ;
|
||||||
int result;
|
int result;
|
||||||
|
|
||||||
arg1 = larg1;
|
arg1 = larg1;
|
||||||
try {
|
try {
|
||||||
result = (int)fact(arg1);
|
result = (int)fact(arg1);
|
||||||
|
|
||||||
lresult = result;
|
lresult = result;
|
||||||
return lresult;
|
return lresult;
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
return (int)0;
|
return (int)0;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -324,7 +324,7 @@ what is generated when parsing C code:
|
||||||
|
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
...
|
...
|
||||||
|
|
||||||
(swig-in-package ())
|
(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.
|
the C++ wrapper will be what you then load into Allegro CL.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -396,7 +396,7 @@ See <a href="#Allegrocl_nn47">Section 17.5 Identifier converter
|
||||||
functions</a> for more details.
|
functions</a> for more details.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -436,7 +436,7 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
||||||
<H2><a name="Allegrocl_nn6">18.2 Wrapping Overview</a></H2>
|
<H2><a name="Allegrocl_nn6">20.2 Wrapping Overview</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -446,7 +446,7 @@ New users to SWIG are encouraged to read
|
||||||
interested in generating an interface to C++.
|
interested in generating an interface to C++.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -499,7 +499,7 @@ interested in generating an interface to C++.
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -512,7 +512,7 @@ interested in generating an interface to C++.
|
||||||
typemap.
|
typemap.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -526,8 +526,8 @@ interested in generating an interface to C++.
|
||||||
<pre>
|
<pre>
|
||||||
%module ffargs
|
%module ffargs
|
||||||
|
|
||||||
%ffargs(strings_convert="nil",call_direct="t") foo;
|
%ffargs(strings_convert="nil", call_direct="t") foo;
|
||||||
%ffargs(strings_convert="nil",release_heap=":never",optimize_for_space="t") bar;
|
%ffargs(strings_convert="nil", release_heap=":never", optimize_for_space="t") bar;
|
||||||
|
|
||||||
int foo(float f1, float f2);
|
int foo(float f1, float f2);
|
||||||
int foo(float f1, char c2);
|
int foo(float f1, char c2);
|
||||||
|
|
@ -593,7 +593,7 @@ char *xxx();
|
||||||
ff:def-foreign-call's.
|
ff:def-foreign-call's.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -606,11 +606,11 @@ char *xxx();
|
||||||
this function can be manipulated via the <tt>lout</tt> typemap.
|
this function can be manipulated via the <tt>lout</tt> typemap.
|
||||||
</p>
|
</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>
|
<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
|
generated. First, all the overloads for a given name are separated
|
||||||
out into groups based on arity, and are wrapped in
|
out into groups based on arity, and are wrapped in
|
||||||
defmethods. Each method calls a distinct wrapper function, but are
|
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.
|
can be manipulated via the <tt>lout</tt> typemap.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -635,7 +635,7 @@ char *xxx();
|
||||||
into the foreign module.
|
into the foreign module.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -657,7 +657,7 @@ char *xxx();
|
||||||
foreign function interface.
|
foreign function interface.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Allegrocl_nn14">18.3 Wrapping Details</a></H2>
|
<H2><a name="Allegrocl_nn14">20.3 Wrapping Details</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -665,7 +665,7 @@ char *xxx();
|
||||||
translated into lisp.
|
translated into lisp.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Allegrocl_nn15">18.3.1 Namespaces</a></H3>
|
<H3><a name="Allegrocl_nn15">20.3.1 Namespaces</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -688,10 +688,10 @@ char *xxx();
|
||||||
%include "foo.h"
|
%include "foo.h"
|
||||||
|
|
||||||
namespace car {
|
namespace car {
|
||||||
...
|
...
|
||||||
namespace tires {
|
namespace tires {
|
||||||
int do_something(int n);
|
int do_something(int n);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -742,7 +742,7 @@ namespace car {
|
||||||
function such as <tt>(car '(1 2 3)</tt>.
|
function such as <tt>(car '(1 2 3)</tt>.
|
||||||
</p>
|
</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.
|
not use the <tt>-nocwrap</tt> command-line option.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Allegrocl_nn17">18.3.3 Variables</a></H3>
|
<H3><a name="Allegrocl_nn17">20.3.3 Variables</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -881,7 +881,7 @@ globalvar> (globalvar.nnn::glob_float)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H3><a name="Allegrocl_nn18">18.3.4 Enumerations</a></H3>
|
<H3><a name="Allegrocl_nn18">20.3.4 Enumerations</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -957,7 +957,7 @@ EXPORT const int ACL_ENUM___FOO3__SWIG_0 = FOO3;
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H3><a name="Allegrocl_nn19">18.3.5 Arrays</a></H3>
|
<H3><a name="Allegrocl_nn19">20.3.5 Arrays</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1105,10 +1105,10 @@ namespace BAR {
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1123,7 +1123,7 @@ namespace BAR {
|
||||||
integer values.
|
integer values.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1136,7 +1136,7 @@ namespace BAR {
|
||||||
parameter.
|
parameter.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1152,7 +1152,7 @@ namespace BAR {
|
||||||
the interface does nothing for <tt>friend</tt> directives,
|
the interface does nothing for <tt>friend</tt> directives,
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1170,11 +1170,11 @@ namespace BAR {
|
||||||
use the more robust wrapper functions.
|
use the more robust wrapper functions.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1187,7 +1187,7 @@ them. This is done via the
|
||||||
directive.
|
directive.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1197,7 +1197,7 @@ to include these templated classes in the foreign-type and CLOS
|
||||||
class schema.
|
class schema.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1209,8 +1209,8 @@ class schema.
|
||||||
<div class="code">synonyms.h
|
<div class="code">synonyms.h
|
||||||
<pre>
|
<pre>
|
||||||
class A {
|
class A {
|
||||||
int x;
|
int x;
|
||||||
int y;
|
int y;
|
||||||
};
|
};
|
||||||
|
|
||||||
typedef A Foo;
|
typedef A Foo;
|
||||||
|
|
@ -1239,7 +1239,7 @@ int zzz(A *inst = 0); /* return inst->x + inst->y */
|
||||||
We resolve this issue, by noting synonym relationships between
|
We resolve this issue, by noting synonym relationships between
|
||||||
types while generating the interface. A Primary type is selected
|
types while generating the interface. A Primary type is selected
|
||||||
(more on this below) from the candidate list of synonyms. For
|
(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:
|
definition, we generate a form that expands to:
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
|
|
@ -1277,7 +1277,7 @@ synonym>
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1298,7 +1298,7 @@ synonym>
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</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>
|
<p>
|
||||||
|
|
@ -1336,70 +1336,70 @@ float xxx(A *inst, int x); /* return x + A->x + A->y */
|
||||||
<div class="code">overload_wrap.cxx
|
<div class="code">overload_wrap.cxx
|
||||||
<pre>
|
<pre>
|
||||||
EXPORT void ACL___delete_A__SWIG_0 (A *larg1) {
|
EXPORT void ACL___delete_A__SWIG_0 (A *larg1) {
|
||||||
A *arg1 = (A *) 0 ;
|
A *arg1 = (A *) 0 ;
|
||||||
|
|
||||||
arg1 = larg1;
|
arg1 = larg1;
|
||||||
try {
|
try {
|
||||||
delete arg1;
|
delete arg1;
|
||||||
|
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
EXPORT float ACL___xxx__SWIG_0 (int larg1, int larg2) {
|
EXPORT float ACL___xxx__SWIG_0 (int larg1, int larg2) {
|
||||||
float lresult = (float)0 ;
|
float lresult = (float)0 ;
|
||||||
int arg1 ;
|
int arg1 ;
|
||||||
int arg2 ;
|
int arg2 ;
|
||||||
float result;
|
float result;
|
||||||
|
|
||||||
arg1 = larg1;
|
arg1 = larg1;
|
||||||
arg2 = larg2;
|
arg2 = larg2;
|
||||||
try {
|
try {
|
||||||
result = (float)xxx(arg1,arg2);
|
result = (float)xxx(arg1, arg2);
|
||||||
|
|
||||||
lresult = result;
|
lresult = result;
|
||||||
return lresult;
|
return lresult;
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
return (float)0;
|
return (float)0;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
EXPORT float ACL___xxx__SWIG_1 (int larg1) {
|
EXPORT float ACL___xxx__SWIG_1 (int larg1) {
|
||||||
float lresult = (float)0 ;
|
float lresult = (float)0 ;
|
||||||
int arg1 ;
|
int arg1 ;
|
||||||
float result;
|
float result;
|
||||||
|
|
||||||
arg1 = larg1;
|
arg1 = larg1;
|
||||||
try {
|
try {
|
||||||
result = (float)xxx(arg1);
|
result = (float)xxx(arg1);
|
||||||
|
|
||||||
lresult = result;
|
lresult = result;
|
||||||
return lresult;
|
return lresult;
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
return (float)0;
|
return (float)0;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
EXPORT float ACL___xxx__SWIG_2 (A *larg1, int larg2) {
|
EXPORT float ACL___xxx__SWIG_2 (A *larg1, int larg2) {
|
||||||
float lresult = (float)0 ;
|
float lresult = (float)0 ;
|
||||||
A *arg1 = (A *) 0 ;
|
A *arg1 = (A *) 0 ;
|
||||||
int arg2 ;
|
int arg2 ;
|
||||||
float result;
|
float result;
|
||||||
|
|
||||||
arg1 = larg1;
|
arg1 = larg1;
|
||||||
arg2 = larg2;
|
arg2 = larg2;
|
||||||
try {
|
try {
|
||||||
result = (float)xxx(arg1,arg2);
|
result = (float)xxx(arg1, arg2);
|
||||||
|
|
||||||
lresult = result;
|
lresult = result;
|
||||||
return lresult;
|
return lresult;
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
return (float)0;
|
return (float)0;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1461,7 +1461,7 @@ overload>
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1607,7 +1607,7 @@ opoverload>
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H3><a name="Allegrocl_nn32">18.3.11 Varargs</a></H3>
|
<H3><a name="Allegrocl_nn32">20.3.11 Varargs</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1628,7 +1628,7 @@ opoverload>
|
||||||
with other ways such functions can be wrapped.
|
with other ways such functions can be wrapped.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1640,7 +1640,7 @@ opoverload>
|
||||||
implemented.
|
implemented.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1652,7 +1652,7 @@ opoverload>
|
||||||
newly defined types.
|
newly defined types.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Allegrocl_nn35">18.4 Typemaps</a></H2>
|
<H2><a name="Allegrocl_nn35">20.4 Typemaps</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1663,7 +1663,7 @@ opoverload>
|
||||||
on <a href="Typemaps.html#Typemaps">Typemaps</a> for more information.
|
on <a href="Typemaps.html#Typemaps">Typemaps</a> for more information.
|
||||||
</p>
|
</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>
|
||||||
<pre>
|
<pre>
|
||||||
return-val wrapper-name(parm0, parm1, ..., parmN)
|
return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
{
|
{
|
||||||
return-val lresult; /* return value from wrapper */
|
return-val lresult; /* return value from wrapper */
|
||||||
<local-declaration>
|
<local-declaration>
|
||||||
... results; /* return value from function call */
|
... results; /* return value from function call */
|
||||||
|
|
||||||
<binding locals to parameters>
|
<binding locals to parameters>
|
||||||
|
|
||||||
try {
|
try {
|
||||||
result = function-name(local0, local1, ..., localN);
|
result = function-name(local0, local1, ..., localN);
|
||||||
|
|
||||||
<convert and bind result to lresult>
|
<convert and bind result to lresult>
|
||||||
|
|
||||||
return lresult;
|
return lresult;
|
||||||
catch (...) {
|
catch (...) {
|
||||||
return (int)0;
|
return (int)0;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1728,7 +1728,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1752,7 +1752,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1784,7 +1784,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
these <a href="Typemaps.html#Typemaps_nn25">common typemaps</a> here.
|
these <a href="Typemaps.html#Typemaps_nn25">common typemaps</a> here.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1803,7 +1803,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
<a href="#Allegrocl_nn15">16.3.1 Namespaces</a> for details.
|
<a href="#Allegrocl_nn15">16.3.1 Namespaces</a> for details.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1846,7 +1846,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1889,7 +1889,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1959,7 +1959,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1983,7 +1983,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -2017,10 +2017,10 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -2041,11 +2041,11 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
of arguments.
|
of arguments.
|
||||||
</p>
|
</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.
|
<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>
|
<p>
|
||||||
|
|
@ -2054,7 +2054,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
strings, from which a symbol will be created.
|
strings, from which a symbol will be created.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -2063,7 +2063,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
same symbol transformations.
|
same symbol transformations.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -2072,7 +2072,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
||||||
default naming conventions.
|
default naming conventions.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -2128,7 +2128,7 @@ indicating the number of arguments passed to the routine indicated by
|
||||||
this identifier.
|
this identifier.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -6,7 +6,7 @@
|
||||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||||
</head>
|
</head>
|
||||||
<body bgcolor="#FFFFFF">
|
<body bgcolor="#FFFFFF">
|
||||||
<H1><a name="Android">19 SWIG and Android</a></H1>
|
<H1><a name="Android">21 SWIG and Android</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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>
|
<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.
|
This chapter contains a few Android specific notes and examples.
|
||||||
</p>
|
</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>
|
<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).
|
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):
|
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>
|
</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.
|
The following examples are shipped with SWIG under the Examples/android directory and include a Makefile to build and install each example.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -326,7 +326,7 @@ include $(BUILD_SHARED_LIBRARY)
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<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:
|
A simple invocation of ndk-build will compile the .c files and generate a shared object/system library. Output will be similar to:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -354,7 +354,7 @@ Modify the <tt>nativeCall</tt> method in <tt>src/org/swig/simple/SwigSimple.java
|
||||||
|
|
||||||
int x = 42;
|
int x = 42;
|
||||||
int y = 105;
|
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");
|
outputText.append("The greatest common divisor of " + x + " and " + y + " is " + g + "\n");
|
||||||
|
|
||||||
// Manipulate the Foo global variable
|
// 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>
|
<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>
|
<p>
|
||||||
|
|
@ -409,7 +409,7 @@ All the steps required to compile and use a simple hierarchy of classes for shap
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
First create an Android project called <tt>SwigClass</tt> in a subdirectory called <tt>class</tt>.
|
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>.
|
Adjust the <tt>--target</tt> id as mentioned earlier in the <a href="Android.html#Android_examples_intro">Examples introduction</a>.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -661,7 +661,7 @@ public class SwigClass extends Activity
|
||||||
// ----- Call some methods -----
|
// ----- Call some methods -----
|
||||||
|
|
||||||
outputText.append( "\nHere are some properties of the shapes:\n" );
|
outputText.append( "\nHere are some properties of the shapes:\n" );
|
||||||
Shape[] shapes = {c,s};
|
Shape[] shapes = {c, s};
|
||||||
for (int i=0; i<shapes.length; i++)
|
for (int i=0; i<shapes.length; i++)
|
||||||
{
|
{
|
||||||
outputText.append( " " + shapes[i].toString() + "\n" );
|
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>
|
<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>
|
<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.
|
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>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Android_stl">19.3 C++ STL</a></H2>
|
<H2><a name="Android_stl">21.3 C++ STL</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Arguments">10 Argument Handling</a></H1>
|
<H1><a name="Arguments">12 Argument Handling</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -32,7 +32,7 @@
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
described. In particular, primitive types such as <tt>int</tt> and
|
||||||
<tt>double</tt> are mapped to corresponding types in the target
|
<tt>double</tt> are mapped to corresponding types in the target
|
||||||
language. For everything else, pointers are used to refer to
|
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.
|
describes some of the techniques for doing this.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -51,7 +51,7 @@ This section describes the <tt>typemaps.i</tt> library file--commonly used to
|
||||||
change certain properties of argument conversion.
|
change certain properties of argument conversion.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Arguments_nn3">10.1.1 Introduction</a></H3>
|
<H3><a name="Arguments_nn3">12.1.1 Introduction</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -100,7 +100,7 @@ like this (shown for Python):
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> a = add(3,4)
|
>>> a = add(3, 4)
|
||||||
>>> print a
|
>>> print a
|
||||||
7
|
7
|
||||||
>>>
|
>>>
|
||||||
|
|
@ -148,7 +148,7 @@ For example, consider this code:
|
||||||
%include "typemaps.i"
|
%include "typemaps.i"
|
||||||
%apply int *OUTPUT { int *width, int *height };
|
%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);
|
void getwinsize(int winid, int *width, int *height);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -158,7 +158,7 @@ In this case, the function returns multiple values, allowing it to be used like
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> w,h = genwinsize(wid)
|
>>> w, h = genwinsize(wid)
|
||||||
>>> print w
|
>>> print w
|
||||||
400
|
400
|
||||||
>>> print h
|
>>> print h
|
||||||
|
|
@ -195,7 +195,7 @@ else. To clear a typemap, the <tt>%clear</tt> directive should be used. For e
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -245,10 +245,10 @@ When the function is used in the scripting language interpreter, it will work li
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
result = add(3,4)
|
result = add(3, 4)
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -315,7 +315,7 @@ iresult, dresult = foo(3.5, 2)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -380,7 +380,7 @@ rather than directly overwriting the value of the original input object.
|
||||||
SWIG. Backwards compatibility is preserved, but deprecated.
|
SWIG. Backwards compatibility is preserved, but deprecated.
|
||||||
</p>
|
</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>
|
<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.
|
file or a matching <tt>%clear</tt> declaration.
|
||||||
</p>
|
</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>
|
<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.
|
can be accomplished including the <tt>constraints.i</tt> library file.
|
||||||
</p>
|
</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>
|
<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
|
exception will be raised. As a result, it is possible to catch bad
|
||||||
values, prevent mysterious program crashes and so on.</p>
|
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>
|
<p>
|
||||||
|
|
@ -466,7 +466,7 @@ NONNULL Non-NULL pointer (pointers only).
|
||||||
|
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -35,7 +35,7 @@
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn2">17.1 NAME</a></H2>
|
<H2><a name="CCache_nn2">20.1 NAME</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -43,7 +43,7 @@
|
||||||
ccache-swig - a fast compiler cache
|
ccache-swig - a fast compiler cache
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn3">17.2 SYNOPSIS</a></H2>
|
<H2><a name="CCache_nn3">20.2 SYNOPSIS</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -53,7 +53,7 @@ ccache-swig <compiler> [COMPILER OPTIONS]
|
||||||
<p>
|
<p>
|
||||||
<compiler> [COMPILER OPTIONS]
|
<compiler> [COMPILER OPTIONS]
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn4">17.3 DESCRIPTION</a></H2>
|
<H2><a name="CCache_nn4">20.3 DESCRIPTION</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
being done again. ccache-swig is ccache plus support for SWIG. ccache
|
||||||
and ccache-swig are used interchangeably in this document.
|
and ccache-swig are used interchangeably in this document.
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn5">17.4 OPTIONS SUMMARY</a></H2>
|
<H2><a name="CCache_nn5">20.4 OPTIONS SUMMARY</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -82,7 +82,7 @@ Here is a summary of the options to ccache-swig.
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn6">17.5 OPTIONS</a></H2>
|
<H2><a name="CCache_nn6">20.5 OPTIONS</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -124,7 +124,7 @@ rounded down to the nearest multiple of 16 kilobytes.
|
||||||
<p>
|
<p>
|
||||||
</dl>
|
</dl>
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn7">17.6 INSTALLATION</a></H2>
|
<H2><a name="CCache_nn7">20.6 INSTALLATION</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
Note! Do not use a hard link, use a symbolic link. A hardlink will
|
||||||
cause "interesting" problems.
|
cause "interesting" problems.
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn8">17.7 EXTRA OPTIONS</a></H2>
|
<H2><a name="CCache_nn8">20.7 EXTRA OPTIONS</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
treated as an input file name and instead be passed along to the
|
||||||
compiler as a command line option.
|
compiler as a command line option.
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn9">17.8 ENVIRONMENT VARIABLES</a></H2>
|
<H2><a name="CCache_nn9">20.8 ENVIRONMENT VARIABLES</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -315,7 +315,7 @@ the use of '#pragma SWIG'.
|
||||||
<p>
|
<p>
|
||||||
</dl>
|
</dl>
|
||||||
<p>
|
<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>
|
<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
|
below the numbers you specified in order to avoid doing the cache
|
||||||
clean operation too often.
|
clean operation too often.
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn11">17.10 CACHE COMPRESSION</a></H2>
|
<H2><a name="CCache_nn11">20.10 CACHE COMPRESSION</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
that fit in the cache. You can turn off compression setting the
|
||||||
CCACHE_NOCOMPRESS environment variable.
|
CCACHE_NOCOMPRESS environment variable.
|
||||||
<p>
|
<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>
|
<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
|
discover a case where ccache changes the output of your compiler then
|
||||||
please let me know.
|
please let me know.
|
||||||
<p>
|
<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>
|
<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
|
'distcc' and ccache will prefix the command line used with the
|
||||||
compiler with the command 'distcc'.
|
compiler with the command 'distcc'.
|
||||||
<p>
|
<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>
|
<p>
|
||||||
|
|
@ -407,11 +407,11 @@ following conditions need to be met:
|
||||||
versions of ccache that do not support compression.
|
versions of ccache that do not support compression.
|
||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn15">17.14 HISTORY</a></H2>
|
<H2><a name="CCache_nn15">20.14 HISTORY</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
by Erik Thiele and I would like to thank him for an excellent piece of
|
||||||
work. See
|
work. See
|
||||||
<a href="http://www.erikyyy.de/compilercache/">http://www.erikyyy.de/compilercache/</a>
|
<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
|
compiler cache and I wanted to remove some of the limitations of the
|
||||||
shell-script version.
|
shell-script version.
|
||||||
<p>
|
<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>
|
<p>
|
||||||
|
|
@ -441,7 +441,7 @@ are:
|
||||||
<li> ccache avoids a double call to cpp on a cache miss
|
<li> ccache avoids a double call to cpp on a cache miss
|
||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn17">17.16 CREDITS</a></H2>
|
<H2><a name="CCache_nn17">20.16 CREDITS</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
<li> Paul Russell for many suggestions and the debian packaging
|
||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
<H2><a name="CCache_nn18">17.17 AUTHOR</a></H2>
|
<H2><a name="CCache_nn18">20.17 AUTHOR</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
ccache was written by Andrew Tridgell
|
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.
|
ccache was adapted to create ccache-swig for use with SWIG by William Fulton.
|
||||||
<p>
|
<p>
|
||||||
If you wish to report a problem or make a suggestion then please email
|
If you wish to report a problem or make a suggestion then please email
|
||||||
|
|
|
||||||
|
|
@ -32,6 +32,7 @@
|
||||||
<li><a href="#CPlusPlus11_alias_templates">Type alias and alias templates</a>
|
<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_unrestricted_unions">Unrestricted unions</a>
|
||||||
<li><a href="#CPlusPlus11_variadic_templates">Variadic templates</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_new_string_literals">New string literals</a>
|
||||||
<li><a href="#CPlusPlus11_user_defined_literals">User-defined literals</a>
|
<li><a href="#CPlusPlus11_user_defined_literals">User-defined literals</a>
|
||||||
<li><a href="#CPlusPlus11_thread_local_storage">Thread-local storage</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_noexcept">Exception specifications and noexcept</a>
|
||||||
<li><a href="#CPlusPlus11_alignment">Control and query object alignment</a>
|
<li><a href="#CPlusPlus11_alignment">Control and query object alignment</a>
|
||||||
<li><a href="#CPlusPlus11_attributes">Attributes</a>
|
<li><a href="#CPlusPlus11_attributes">Attributes</a>
|
||||||
|
<li><a href="#CPlusPlus11_ref_qualifiers">Methods with ref-qualifiers</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#CPlusPlus11_standard_library_changes">Standard library changes</a>
|
<li><a href="#CPlusPlus11_standard_library_changes">Standard library changes</a>
|
||||||
<ul>
|
<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>
|
<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>
|
<div class="targetlang"><pre>
|
||||||
>>> c = Container( [1,2,3,4] )
|
>>> c = Container( [1, 2, 3, 4] )
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -392,7 +394,7 @@ auto SomeStruct::FuncName(int x, int y) -> int {
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> a = SomeStruct()
|
>>> a = SomeStruct()
|
||||||
>>> a.FuncName(10,5)
|
>>> a.FuncName(10, 5)
|
||||||
15
|
15
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -457,10 +459,10 @@ This kind of initialization is handled by SWIG.
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
class SomeClass {
|
class SomeClass {
|
||||||
public:
|
public:
|
||||||
SomeClass() {}
|
SomeClass() {}
|
||||||
explicit SomeClass(int new_value) : value(new_value) {}
|
explicit SomeClass(int new_value) : value(new_value) {}
|
||||||
|
|
||||||
int value = 5;
|
int value = 5;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -622,20 +624,15 @@ which is equivalent to the old style typedef:
|
||||||
typedef void (*PFD)(double); // The old style
|
typedef void (*PFD)(double); // The old style
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
|
||||||
SWIG supports type aliasing.
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The following is an example of an alias template:
|
The following is an example of an alias template:
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
template< typename T1, typename T2, int >
|
template< typename T1, typename T2, int N >
|
||||||
class SomeType {
|
class SomeType {
|
||||||
public:
|
public:
|
||||||
T1 a;
|
T1 a;
|
||||||
T2 b;
|
T2 b;
|
||||||
int c;
|
|
||||||
};
|
};
|
||||||
|
|
||||||
template< typename T2 >
|
template< typename T2 >
|
||||||
|
|
@ -643,14 +640,19 @@ using TypedefName = SomeType<char*, T2, 5>;
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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>
|
</p>
|
||||||
|
|
||||||
<div class="shell">
|
<div class="code"><pre>
|
||||||
<pre>
|
%template(SomeTypeBool) SomeType<char*, bool, 5>;
|
||||||
example.i:13: Warning 342: The 'using' keyword in template aliasing is not fully supported yet.
|
%template() TypedefName<bool>;
|
||||||
</pre>
|
</pre></div>
|
||||||
</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>
|
<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>
|
<div class="code"><pre>
|
||||||
template <typename... BaseClasses> class ClassName : public BaseClasses... {
|
template <typename... BaseClasses> class ClassName : public BaseClasses... {
|
||||||
public:
|
public:
|
||||||
ClassName (BaseClasses &&... baseClasses) : BaseClasses(baseClasses)... {}
|
ClassName (BaseClasses &&... baseClasses) : BaseClasses(baseClasses)... {}
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -713,7 +715,24 @@ const int SIZE = sizeof...(ClassName<int, int>);
|
||||||
In the above example <tt>SIZE</tt> is of course wrapped as a constant.
|
In the above example <tt>SIZE</tt> is of course wrapped as a constant.
|
||||||
</p>
|
</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>
|
<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.
|
inside raw string literals.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -810,7 +829,7 @@ OutputType var2 = 1234_suffix;
|
||||||
OutputType var3 = 3.1416_suffix;
|
OutputType var3 = 3.1416_suffix;
|
||||||
</pre></div>
|
</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
|
<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>
|
<div class="code"><pre>
|
||||||
struct A {
|
struct A {
|
||||||
static thread_local int val;
|
static thread_local int val;
|
||||||
};
|
};
|
||||||
thread_local int global_val;
|
thread_local int global_val;
|
||||||
</pre></div>
|
</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.
|
same way that it will be thread local if accessed from C++ code.
|
||||||
</p>
|
</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.
|
<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>
|
<div class="code"><pre>
|
||||||
struct NoInt {
|
struct NoInt {
|
||||||
void f(double i);
|
void f(double i);
|
||||||
void f(int) = delete;
|
void f(int) = delete;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</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.
|
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>
|
</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>
|
<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>
|
<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.
|
This is a C++ compile time directive so there isn't anything useful that SWIG can do with it.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -888,7 +908,7 @@ struct Check {
|
||||||
};
|
};
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -909,7 +929,7 @@ const int SIZE = sizeof(A::member); // does not work with C++03. Okay with C++11
|
||||||
8
|
8
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -925,7 +945,7 @@ int noex2(int) noexcept(true);
|
||||||
int noex3(int, bool) noexcept(false);
|
int noex3(int, bool) noexcept(false);
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -957,7 +977,7 @@ Use the preprocessor to work around this for now:
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -970,6 +990,104 @@ int [[attr1]] i [[attr2, attr3]];
|
||||||
[[noreturn, nothrow]] void f [[noreturn]] ();
|
[[noreturn, nothrow]] void f [[noreturn]] ();
|
||||||
</pre></div>
|
</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>&</tt> lvalue ref-qualifiers are wrapped like any other function without ref-qualifiers.
|
||||||
|
Member functions declared with a <tt>&&</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) &;
|
||||||
|
void m2(int x) &&;
|
||||||
|
};
|
||||||
|
</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) && 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) &&;
|
||||||
|
struct RQ {
|
||||||
|
void m1(int x) &;
|
||||||
|
void m2(int x) &&;
|
||||||
|
};
|
||||||
|
</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) &&;
|
||||||
|
%feature("action") RQ::m2(int x) && %{
|
||||||
|
RQ().m2(arg2);
|
||||||
|
%}
|
||||||
|
struct RQ {
|
||||||
|
void m1(int x) &;
|
||||||
|
void m2(int x) &&;
|
||||||
|
};
|
||||||
|
</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>
|
<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>
|
<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>.
|
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>
|
</p>
|
||||||
|
|
||||||
<H3><a name="CPlusPlus11_regular_expressions">7.3.4 Regular expressions</a></H3>
|
<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>
|
<div class="targetlang"><pre>
|
||||||
t = Test()
|
t = Test()
|
||||||
b = t(1,2) # invoke C++ function object
|
b = t(1, 2) # invoke C++ function object
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<H3><a name="CPlusPlus11_type_traits_for_metaprogramming">7.3.9 Type traits for metaprogramming</a></H3>
|
<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>!
|
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>
|
</p>
|
||||||
|
|
||||||
|
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
|
|
|
||||||
60
Doc/Manual/CPlusPlus14.html
Normal file
60
Doc/Manual/CPlusPlus14.html
Normal 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
109
Doc/Manual/CPlusPlus17.html
Normal 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>
|
||||||
|
|
@ -6,7 +6,7 @@
|
||||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||||
</head>
|
</head>
|
||||||
<body bgcolor="#FFFFFF">
|
<body bgcolor="#FFFFFF">
|
||||||
<H1><a name="CSharp">20 SWIG and C#</a></H1>
|
<H1><a name="CSharp">22 SWIG and C#</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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_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_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_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_extending_proxy_class">Extending proxy classes with additional C# code</a>
|
||||||
<li><a href="#CSharp_enum_underlying_type">Underlying type for enums</a>
|
<li><a href="#CSharp_enum_underlying_type">Underlying type for enums</a>
|
||||||
</ul>
|
</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>
|
<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.
|
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.
|
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
|
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
|
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>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
To get the most out of this chapter an understanding of interop is required.
|
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".
|
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="http://www.mono-project.com/docs/advanced/pinvoke/">Interop with native libraries</a>.
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -82,7 +83,7 @@ In order to minimize name collisions between names generated based on input to S
|
||||||
</p>
|
</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>
|
<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.
|
Due to possible compiler limits it is not advisable to use <tt>-outfile</tt> for large projects.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -231,8 +232,8 @@ javacode -> cscode
|
||||||
javaimports -> csimports
|
javaimports -> csimports
|
||||||
javabody -> csbody
|
javabody -> csbody
|
||||||
javafinalize -> csfinalize
|
javafinalize -> csfinalize
|
||||||
javadestruct -> csdestruct
|
javadestruct -> csdisposing and csdispose
|
||||||
javadestruct_derived -> csdestruct_derived
|
javadestruct_derived -> csdisposing_derived and csdispose_derived
|
||||||
javainterfacecode -> csinterfacecode
|
javainterfacecode -> csinterfacecode
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -544,14 +545,18 @@ unless the imclassname attribute is specified in the <a href="CSharp.html#CSharp
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The directory <tt>Examples/csharp</tt> has a number of simple examples.
|
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.
|
Visual Studio .NET 2003 solution and project files are available for compiling with the Microsoft .NET C#
|
||||||
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,
|
compiler on Windows. This also works with newer versions of Visual Studio if you allow
|
||||||
then <tt>ilrun runme.exe</tt> (Portable.NET C# compiler) or <tt>mono runme.exe</tt> (Mono C# compiler) to run the examples.
|
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
|
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.
|
<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>
|
<p>
|
||||||
|
|
@ -569,7 +574,7 @@ void * f(void *v);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H2><a name="CSharp_arrays">20.4 C# Arrays</a></H2>
|
<H2><a name="CSharp_arrays">22.4 C# Arrays</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -581,7 +586,7 @@ with one of the following three approaches; namely the SWIG C arrays library, P/
|
||||||
pinned arrays.
|
pinned arrays.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -598,7 +603,7 @@ For the <tt>%array_functions</tt> example, the equivalent usage would be:
|
||||||
<pre>
|
<pre>
|
||||||
SWIGTYPE_p_double a = example.new_doubleArray(10); // Create an array
|
SWIGTYPE_p_double a = example.new_doubleArray(10); // Create an array
|
||||||
for (int i=0; i<10; i++)
|
for (int i=0; i<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.print_array(a); // Pass to C
|
||||||
example.delete_doubleArray(a); // Destroy array
|
example.delete_doubleArray(a); // Destroy array
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -618,7 +623,7 @@ example.print_array(c.cast()); // Pass to C
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -638,7 +643,7 @@ passing a direct reference as described in the next section.
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
For more information on the subject, see the
|
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.
|
on MSDN.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -673,7 +678,7 @@ As a result, we get the following method in the module class:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
public static void myArrayCopy(int[] sourceArray, int[] targetArray, int nitems) {
|
public static void myArrayCopy(int[] sourceArray, int[] targetArray, int nitems) {
|
||||||
examplePINVOKE.myArrayCopy(sourceArray, targetArray, nitems);
|
examplePINVOKE.myArrayCopy(sourceArray, targetArray, nitems);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -745,7 +750,7 @@ and intermediary class method
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -758,7 +763,7 @@ another thread may produce enough garbage to trigger garbage collection.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<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>
|
</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>
|
<p>
|
||||||
|
|
@ -937,7 +942,7 @@ set so should only be used when a C# exception is not created.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -993,9 +998,9 @@ When the following C# code is executed:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
public class runme {
|
public class runme {
|
||||||
static void Main() {
|
static void Main() {
|
||||||
example.positivesonly(-1);
|
example.positivesonly(-1);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1021,18 +1026,18 @@ Now let's analyse the generated code to gain a fuller understanding of the typem
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
SWIGEXPORT void SWIGSTDCALL CSharp_positivesonly(int jarg1) {
|
SWIGEXPORT void SWIGSTDCALL CSharp_positivesonly(int jarg1) {
|
||||||
int arg1 ;
|
int arg1 ;
|
||||||
|
|
||||||
arg1 = (int)jarg1;
|
arg1 = (int)jarg1;
|
||||||
|
|
||||||
if (arg1 < 0) {
|
if (arg1 < 0) {
|
||||||
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException,
|
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException,
|
||||||
"only positive numbers accepted", "number");
|
"only positive numbers accepted", "number");
|
||||||
return ;
|
return ;
|
||||||
}
|
}
|
||||||
|
|
||||||
positivesonly(arg1);
|
positivesonly(arg1);
|
||||||
|
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>.
|
Actually it will issue this warning for any function beginning with <tt>SWIG_CSharpSetPendingException</tt>.
|
||||||
</P>
|
</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>
|
<p>
|
||||||
|
|
@ -1155,18 +1160,17 @@ The generated unmanaged code this time catches the C++ exception and converts it
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
SWIGEXPORT void SWIGSTDCALL CSharp_negativesonly(int jarg1) {
|
SWIGEXPORT void SWIGSTDCALL CSharp_negativesonly(int jarg1) {
|
||||||
int arg1 ;
|
int arg1 ;
|
||||||
|
|
||||||
arg1 = (int)jarg1;
|
arg1 = (int)jarg1;
|
||||||
|
|
||||||
try {
|
try {
|
||||||
negativesonly(arg1);
|
negativesonly(arg1);
|
||||||
|
|
||||||
} catch (std::out_of_range e) {
|
} catch (std::out_of_range e) {
|
||||||
SWIG_CSharpSetPendingException(SWIG_CSharpApplicationException, e.what());
|
SWIG_CSharpSetPendingException(SWIG_CSharpApplicationException, e.what());
|
||||||
return ;
|
return ;
|
||||||
}
|
}
|
||||||
|
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1185,7 +1189,7 @@ The managed code generated does check for the pending exception as mentioned ear
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1221,19 +1225,18 @@ SWIG generates a try catch block with the throws typemap code in the catch handl
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
|
SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
|
||||||
int arg1 ;
|
int arg1 ;
|
||||||
|
|
||||||
arg1 = (int)jarg1;
|
arg1 = (int)jarg1;
|
||||||
try {
|
try {
|
||||||
evensonly(arg1);
|
evensonly(arg1);
|
||||||
|
}
|
||||||
|
catch(std::out_of_range &_e) {
|
||||||
|
{
|
||||||
|
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentException, (&_e)->what(), NULL);
|
||||||
|
return ;
|
||||||
}
|
}
|
||||||
catch(std::out_of_range &_e) {
|
}
|
||||||
{
|
|
||||||
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentException, (&_e)->what(), NULL);
|
|
||||||
return ;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
Multiple catch handlers are generated should there be more than one exception specifications declared.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1376,7 +1379,7 @@ try {
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H2><a name="CSharp_directors">20.6 C# Directors</a></H2>
|
<H2><a name="CSharp_directors">22.6 C# Directors</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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.
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -1510,7 +1513,7 @@ CSharpDerived - UIntMethod(123)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1572,9 +1575,9 @@ public class Base : global::System.IDisposable {
|
||||||
|
|
||||||
private void SwigDirectorConnect() {
|
private void SwigDirectorConnect() {
|
||||||
if (SwigDerivedClassHasMethod("UIntMethod", swigMethodTypes0))
|
if (SwigDerivedClassHasMethod("UIntMethod", swigMethodTypes0))
|
||||||
swigDelegate0 = new SwigDelegateBase_0(SwigDirectorUIntMethod);
|
swigDelegate0 = new SwigDelegateBase_0(SwigDirectorMethodUIntMethod);
|
||||||
if (SwigDerivedClassHasMethod("BaseBoolMethod", swigMethodTypes1))
|
if (SwigDerivedClassHasMethod("BaseBoolMethod", swigMethodTypes1))
|
||||||
swigDelegate1 = new SwigDelegateBase_1(SwigDirectorBaseBoolMethod);
|
swigDelegate1 = new SwigDelegateBase_1(SwigDirectorMethodBaseBoolMethod);
|
||||||
examplePINVOKE.Base_director_connect(swigCPtr, swigDelegate0, swigDelegate1);
|
examplePINVOKE.Base_director_connect(swigCPtr, swigDelegate0, swigDelegate1);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -1584,16 +1587,16 @@ public class Base : global::System.IDisposable {
|
||||||
return hasDerivedMethod;
|
return hasDerivedMethod;
|
||||||
}
|
}
|
||||||
|
|
||||||
private uint SwigDirectorUIntMethod(uint x) {
|
private uint SwigDirectorMethodUIntMethod(uint x) {
|
||||||
return UIntMethod(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);
|
BaseBoolMethod(new Base(b, false), flag);
|
||||||
}
|
}
|
||||||
|
|
||||||
internal delegate uint SwigDelegateBase_0(uint x);
|
public delegate uint SwigDelegateBase_0(uint x);
|
||||||
internal delegate void SwigDelegateBase_1(global::System.IntPtr b, bool flag);
|
public delegate void SwigDelegateBase_1(global::System.IntPtr b, bool flag);
|
||||||
|
|
||||||
private SwigDelegateBase_0 swigDelegate0;
|
private SwigDelegateBase_0 swigDelegate0;
|
||||||
private SwigDelegateBase_1 swigDelegate1;
|
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.
|
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.
|
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.
|
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
|
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.
|
In this case, the C# <tt>Base</tt> class needs to be created from the unmanaged <tt>IntPtr</tt> type.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -1643,20 +1646,20 @@ SWIGEXPORT void SWIGSTDCALL CSharp_Base_director_connect(void *objarg,
|
||||||
|
|
||||||
class SwigDirector_Base : public Base, public Swig::Director {
|
class SwigDirector_Base : public Base, public Swig::Director {
|
||||||
public:
|
public:
|
||||||
SwigDirector_Base();
|
SwigDirector_Base();
|
||||||
virtual unsigned int UIntMethod(unsigned int x);
|
virtual unsigned int UIntMethod(unsigned int x);
|
||||||
virtual ~SwigDirector_Base();
|
virtual ~SwigDirector_Base();
|
||||||
virtual void BaseBoolMethod(Base const &b, bool flag);
|
virtual void BaseBoolMethod(Base const &b, bool flag);
|
||||||
|
|
||||||
typedef unsigned int (SWIGSTDCALL* SWIG_Callback0_t)(unsigned int);
|
typedef unsigned int (SWIGSTDCALL* SWIG_Callback0_t)(unsigned int);
|
||||||
typedef void (SWIGSTDCALL* SWIG_Callback1_t)(void *, unsigned int);
|
typedef void (SWIGSTDCALL* SWIG_Callback1_t)(void *, unsigned int);
|
||||||
void swig_connect_director(SWIG_Callback0_t callbackUIntMethod,
|
void swig_connect_director(SWIG_Callback0_t callbackUIntMethod,
|
||||||
SWIG_Callback1_t callbackBaseBoolMethod);
|
SWIG_Callback1_t callbackBaseBoolMethod);
|
||||||
|
|
||||||
private:
|
private:
|
||||||
SWIG_Callback0_t swig_callbackUIntMethod;
|
SWIG_Callback0_t swig_callbackUIntMethod;
|
||||||
SWIG_Callback1_t swig_callbackBaseBoolMethod;
|
SWIG_Callback1_t swig_callbackBaseBoolMethod;
|
||||||
void swig_init_callbacks();
|
void swig_init_callbacks();
|
||||||
};
|
};
|
||||||
|
|
||||||
void SwigDirector_Base::swig_connect_director(SWIG_Callback0_t callbackUIntMethod,
|
void SwigDirector_Base::swig_connect_director(SWIG_Callback0_t callbackUIntMethod,
|
||||||
|
|
@ -1682,7 +1685,7 @@ void SwigDirector_Base::BaseBoolMethod(Base const &b, bool flag) {
|
||||||
unsigned int jflag ;
|
unsigned int jflag ;
|
||||||
|
|
||||||
if (!swig_callbackBaseBoolMethod) {
|
if (!swig_callbackBaseBoolMethod) {
|
||||||
Base::BaseBoolMethod(b,flag);
|
Base::BaseBoolMethod(b, flag);
|
||||||
return;
|
return;
|
||||||
} else {
|
} else {
|
||||||
jb = (Base *) &b;
|
jb = (Base *) &b;
|
||||||
|
|
@ -1693,7 +1696,32 @@ void SwigDirector_Base::BaseBoolMethod(Base const &b, bool flag) {
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<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.
|
should pass the call on to <tt>CSharpDefaults.DefaultMethod(int)</tt>using the C++ default value, as shown above.
|
||||||
</p>
|
</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>
|
<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.
|
into a different assembly.
|
||||||
However, by default the generated code may not compile if
|
However, by default the generated code may not compile if
|
||||||
generated classes in one assembly use generated classes in another assembly.
|
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.
|
if you don't want users to easily stumble upon these so called 'internal workings' of the wrappers.
|
||||||
</p>
|
</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
|
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.
|
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>
|
<p>
|
||||||
|
|
@ -1800,7 +1828,7 @@ Consider the following C++ code:
|
||||||
<pre>
|
<pre>
|
||||||
struct Wheel {
|
struct Wheel {
|
||||||
int size;
|
int size;
|
||||||
Wheel(int sz) : size(sz) {}
|
Wheel(int sz = 0) : size(sz) {}
|
||||||
};
|
};
|
||||||
|
|
||||||
class Bike {
|
class Bike {
|
||||||
|
|
@ -1819,12 +1847,12 @@ and the following usage from C# after running the code through SWIG:
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
Wheel wheel = new Bike(10).getWheel();
|
Wheel wheel = new Bike(10).getWheel();
|
||||||
Console.WriteLine("wheel size: " + wheel.size);
|
Console.WriteLine("wheel size: " + wheel.size);
|
||||||
// Simulate a garbage collection
|
// Simulate a garbage collection
|
||||||
global::System.GC.Collect();
|
global::System.GC.Collect();
|
||||||
global::System.GC.WaitForPendingFinalizers();
|
global::System.GC.WaitForPendingFinalizers();
|
||||||
global::System.Console.WriteLine("wheel size: " + wheel.size);
|
global::System.Console.WriteLine("wheel size: " + wheel.size);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -1908,7 +1936,7 @@ public class Bike : global::System.IDisposable {
|
||||||
Note the <tt>addReference</tt> call.
|
Note the <tt>addReference</tt> call.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1940,10 +1968,10 @@ and usage from C++
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
Container container;
|
Container container;
|
||||||
Element element(20);
|
Element element(20);
|
||||||
container.setElement(&element);
|
container.setElement(&element);
|
||||||
cout << "element.value: " << container.getElement()->value << endl;
|
cout << "element.value: " << container.getElement()->value << endl;
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -1953,27 +1981,27 @@ and more or less equivalent usage from C#
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
Container container = new Container();
|
Container container = new Container();
|
||||||
Element element = new Element(20);
|
Element element = new Element(20);
|
||||||
container.setElement(element);
|
container.setElement(element);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The C++ code will always print out 20, but the value printed out may not be this in the C# equivalent code.
|
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>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
Container container = new Container();
|
Container container = new Container();
|
||||||
Element element = new Element(20);
|
Element element = new Element(20);
|
||||||
container.setElement(element);
|
container.setElement(element);
|
||||||
Console.WriteLine("element.value: " + container.getElement().value);
|
Console.WriteLine("element.value: " + container.getElement().value);
|
||||||
// Simulate a garbage collection
|
// Simulate a garbage collection
|
||||||
global::System.GC.Collect();
|
global::System.GC.Collect();
|
||||||
global::System.GC.WaitForPendingFinalizers();
|
global::System.GC.WaitForPendingFinalizers();
|
||||||
global::System.Console.WriteLine("element.value: " + container.getElement().value);
|
global::System.Console.WriteLine("element.value: " + container.getElement().value);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -1992,42 +2020,55 @@ public class Container : global::System.IDisposable {
|
||||||
// Ensure that the GC doesn't collect any Element set from C#
|
// Ensure that the GC doesn't collect any Element set from C#
|
||||||
// as the underlying C++ class stores a shallow copy
|
// as the underlying C++ class stores a shallow copy
|
||||||
private Element elementReference;
|
private Element elementReference;
|
||||||
private global::System.Runtime.InteropServices.HandleRef getCPtrAndAddReference(Element element) {
|
|
||||||
elementReference = element;
|
|
||||||
return Element.getCPtr(element);
|
|
||||||
}
|
|
||||||
|
|
||||||
public void setElement(Element e) {
|
public void setElement(Element e) {
|
||||||
examplePINVOKE.Container_setElement(swigCPtr, getCPtrAndAddReference(e));
|
examplePINVOKE.Container_setElement(swigCPtr, Element.getCPtr(e));
|
||||||
|
elementReference = e;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The following typemaps will generate the desired code.
|
The following typemaps can be used to generate this 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.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(csin) Element *e "getCPtrAndAddReference($csinput)"
|
|
||||||
|
|
||||||
%typemap(cscode) Container %{
|
%typemap(cscode) Container %{
|
||||||
// Ensure that the GC doesn't collect any Element set from C#
|
// Ensure that the GC doesn't collect any Element set from C#
|
||||||
// as the underlying C++ class stores a shallow copy
|
// as the underlying C++ class stores a shallow copy
|
||||||
private Element elementReference;
|
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>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -2100,7 +2141,7 @@ The <tt>CDate &</tt> and <tt>const CDate &</tt> C# code is generated fro
|
||||||
|
|
||||||
<p>
|
<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>.
|
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>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
|
|
@ -2134,7 +2175,7 @@ The typemaps to achieve this are shown below.
|
||||||
%typemap(csin,
|
%typemap(csin,
|
||||||
pre=" CDate temp$csinput = new CDate();",
|
pre=" CDate temp$csinput = new CDate();",
|
||||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
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"
|
cshin="out $csinput"
|
||||||
) CDate &
|
) CDate &
|
||||||
"$csclassname.getCPtr(temp$csinput)"
|
"$csclassname.getCPtr(temp$csinput)"
|
||||||
|
|
@ -2240,7 +2281,7 @@ will be possible with the following <tt>CDate *</tt> typemaps
|
||||||
%typemap(csin,
|
%typemap(csin,
|
||||||
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);",
|
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);",
|
||||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
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"
|
cshin="ref $csinput"
|
||||||
) CDate *
|
) CDate *
|
||||||
"$csclassname.getCPtr(temp$csinput)"
|
"$csclassname.getCPtr(temp$csinput)"
|
||||||
|
|
@ -2279,7 +2320,7 @@ The <tt>subtractYears</tt> method is nearly identical to the above <tt>addYears<
|
||||||
%typemap(csin,
|
%typemap(csin,
|
||||||
pre=" using (CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day)) {",
|
pre=" using (CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day)) {",
|
||||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
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",
|
terminator=" } // terminate temp$csinput using block",
|
||||||
cshin="ref $csinput"
|
cshin="ref $csinput"
|
||||||
) CDate *
|
) CDate *
|
||||||
|
|
@ -2313,7 +2354,7 @@ public class example {
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -2351,7 +2392,7 @@ The typemap type required is thus <tt>CDate *</tt>. Given that the previous sect
|
||||||
%typemap(csin,
|
%typemap(csin,
|
||||||
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);",
|
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);",
|
||||||
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
|
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"
|
cshin="ref $csinput"
|
||||||
) CDate *
|
) CDate *
|
||||||
"$csclassname.getCPtr(temp$csinput)"
|
"$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.
|
<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>
|
</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>
|
<p>
|
||||||
|
|
@ -2456,7 +2497,7 @@ The generated proxy class code will then contain the following wrapper for calli
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
...
|
...
|
||||||
private void SwigDirectorsomeCallback(global::System.IntPtr date) {
|
private void SwigDirectorMethodsomeCallback(global::System.IntPtr date) {
|
||||||
System.DateTime tempdate = new System.DateTime();
|
System.DateTime tempdate = new System.DateTime();
|
||||||
try {
|
try {
|
||||||
someCallback(out tempdate);
|
someCallback(out tempdate);
|
||||||
|
|
@ -2475,7 +2516,7 @@ Pay special attention to the memory management issues, using these attributes.
|
||||||
</p>
|
</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>
|
<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.
|
The following example is an alternative approach to adding managed code to the generated proxy class.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -2614,13 +2745,13 @@ public class ExtendMe : global::System.IDisposable {
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<P>
|
||||||
C# enums use int as the underlying type for each enum item.
|
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.
|
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:
|
Here is an example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
|
|
||||||
<H1><a name="Chicken">21 SWIG and Chicken</a></H1>
|
<H1><a name="Chicken">23 SWIG and Chicken</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -72,7 +72,7 @@
|
||||||
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Chicken_nn2">21.1 Preliminaries</a></H2>
|
<H2><a name="Chicken_nn2">23.1 Preliminaries</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -89,7 +89,7 @@
|
||||||
directory for the basic steps to run SWIG CHICKEN.
|
directory for the basic steps to run SWIG CHICKEN.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -122,7 +122,7 @@
|
||||||
object files and linked into your project.
|
object files and linked into your project.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -151,10 +151,10 @@
|
||||||
object files and linked into your project.
|
object files and linked into your project.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -170,7 +170,7 @@
|
||||||
<tt>%rename</tt> SWIG directive in the SWIG interface file.
|
<tt>%rename</tt> SWIG directive in the SWIG interface file.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Chicken_nn7">21.2.2 Modules</a></H3>
|
<H3><a name="Chicken_nn7">23.2.2 Modules</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -192,7 +192,7 @@
|
||||||
(uses <i>modulename</i>))</code> CHICKEN Scheme form.
|
(uses <i>modulename</i>))</code> CHICKEN Scheme form.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -229,7 +229,7 @@
|
||||||
for info on how to apply the %feature.
|
for info on how to apply the %feature.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Chicken_nn9">21.2.4 Functions</a></H3>
|
<H3><a name="Chicken_nn9">23.2.4 Functions</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -248,7 +248,7 @@
|
||||||
parameters). The return values can then be accessed with <code>(call-with-values)</code>.
|
parameters). The return values can then be accessed with <code>(call-with-values)</code>.
|
||||||
</p>
|
</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
|
<p>The SWIG chicken module has support for exceptions thrown from
|
||||||
|
|
@ -290,14 +290,14 @@
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
||||||
<H2><a name="Chicken_nn11">21.3 TinyCLOS</a></H2>
|
<H2><a name="Chicken_nn11">23.3 TinyCLOS</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The author of TinyCLOS, Gregor Kiczales, describes TinyCLOS as:
|
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
|
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)
|
weighing in at around 850 lines of code, including (some)
|
||||||
comments and documentation."
|
comments and documentation."
|
||||||
</p>
|
</p>
|
||||||
|
|
@ -333,7 +333,7 @@
|
||||||
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Chicken_nn12">21.4 Linkage</a></H2>
|
<H2><a name="Chicken_nn12">23.4 Linkage</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -354,7 +354,7 @@
|
||||||
</p>
|
</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>
|
<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>.
|
be run with <tt>csi</tt>.
|
||||||
</p>
|
</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
|
<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
|
<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>
|
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>
|
<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>
|
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>
|
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>
|
<p>
|
||||||
|
|
@ -486,7 +486,7 @@ all the modules.</p>
|
||||||
<code>Lib/chicken/chicken.swg</code>.
|
<code>Lib/chicken/chicken.swg</code>.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Chicken_nn17">21.6 Pointers</a></H2>
|
<H2><a name="Chicken_nn17">23.6 Pointers</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -519,7 +519,7 @@ all the modules.</p>
|
||||||
type. flags is either zero or SWIG_POINTER_DISOWN (see below).
|
type. flags is either zero or SWIG_POINTER_DISOWN (see below).
|
||||||
</p>
|
</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
|
<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.
|
must be called manually.
|
||||||
</p>
|
</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>
|
<ul>
|
||||||
|
|
@ -560,7 +560,7 @@ all the modules.</p>
|
||||||
<a href="SWIGPlus.html#SWIGPlus_default_args">%feature(compactdefaultargs)</a>.</li>
|
<a href="SWIGPlus.html#SWIGPlus_default_args">%feature(compactdefaultargs)</a>.</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
<H3><a name="Chicken_nn19">21.7.1 TinyCLOS problems with Chicken version <= 1.92</a></H3>
|
<H3><a name="Chicken_nn19">23.7.1 TinyCLOS problems with Chicken version <= 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
|
<p>In Chicken versions equal to or below 1.92, TinyCLOS has a limitation such that generic methods do not properly work on methods
|
||||||
|
|
|
||||||
|
|
@ -46,6 +46,11 @@
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="Introduction.html#Introduction_nn2">What is SWIG?</a>
|
<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_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>
|
<li><a href="Introduction.html#Introduction_nn4">A SWIG example</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="Introduction.html#Introduction_nn5">SWIG interface file</a>
|
<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_nn12">Static members</a>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_member_data">Member data</a>
|
<li><a href="SWIGPlus.html#SWIGPlus_member_data">Member data</a>
|
||||||
</ul>
|
</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_nn15">Protection</a>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_nn16">Enums and constants</a>
|
<li><a href="SWIGPlus.html#SWIGPlus_nn16">Enums and constants</a>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_nn17">Friends</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_nn19">Pass and return by value</a>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_nn20">Inheritance</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_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>
|
<ul>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_nn24">Dispatch function generation</a>
|
<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_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_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_nn27">Comments on overloading</a>
|
<li><a href="SWIGPlus.html#SWIGPlus_nn27">Comments on overloading</a>
|
||||||
</ul>
|
</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_class_extension">Class extension</a>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_nn30">Templates</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>
|
<li><a href="SWIGPlus.html#SWIGPlus_namespaces">Namespaces</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_nspace">The nspace feature for namespaces</a>
|
<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_nn35">Using declarations and inheritance</a>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus_nested_classes">Nested classes</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_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>
|
<li><a href="SWIGPlus.html#SWIGPlus_nn42">Where to go for more information</a>
|
||||||
</ul>
|
</ul>
|
||||||
</div>
|
</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_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_unrestricted_unions">Unrestricted unions</a>
|
||||||
<li><a href="CPlusPlus11.html#CPlusPlus11_variadic_templates">Variadic templates</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_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_user_defined_literals">User-defined literals</a>
|
||||||
<li><a href="CPlusPlus11.html#CPlusPlus11_thread_local_storage">Thread-local storage</a>
|
<li><a href="CPlusPlus11.html#CPlusPlus11_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_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_alignment">Control and query object alignment</a>
|
||||||
<li><a href="CPlusPlus11.html#CPlusPlus11_attributes">Attributes</a>
|
<li><a href="CPlusPlus11.html#CPlusPlus11_attributes">Attributes</a>
|
||||||
|
<li><a href="CPlusPlus11.html#CPlusPlus11_ref_qualifiers">Methods with ref-qualifiers</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="CPlusPlus11.html#CPlusPlus11_standard_library_changes">Standard library changes</a>
|
<li><a href="CPlusPlus11.html#CPlusPlus11_standard_library_changes">Standard library changes</a>
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -318,7 +340,39 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -341,32 +395,39 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Library.html#Library">9 SWIG library</a></h3>
|
<h3><a href="Library.html#Library">11 SWIG library</a></h3>
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="Library.html#Library_nn2">The %include directive and library search path</a>
|
<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>
|
<ul>
|
||||||
<li><a href="Library.html#Library_nn4">cpointer.i</a>
|
<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_carrays">carrays.i</a>
|
||||||
<li><a href="Library.html#Library_nn6">cmalloc.i</a>
|
<li><a href="Library.html#Library_nn6">cmalloc.i</a>
|
||||||
<li><a href="Library.html#Library_nn7">cdata.i</a>
|
<li><a href="Library.html#Library_nn7">cdata.i</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="Library.html#Library_nn8">C String Handling</a>
|
<li><a href="Library.html#Library_nn8">C string handling</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="Library.html#Library_nn9">Default string handling</a>
|
<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_nn10">Passing binary data</a>
|
||||||
<li><a href="Library.html#Library_nn11">Using %newobject to release memory</a>
|
<li><a href="Library.html#Library_nn11">Using %newobject to release memory</a>
|
||||||
<li><a href="Library.html#Library_nn12">cstring.i</a>
|
<li><a href="Library.html#Library_nn12">cstring.i</a>
|
||||||
</ul>
|
</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>
|
<ul>
|
||||||
<li><a href="Library.html#Library_std_string">std::string</a>
|
<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_std_vector">std::vector</a>
|
||||||
<li><a href="Library.html#Library_stl_exceptions">STL exceptions</a>
|
<li><a href="Library.html#Library_stl_exceptions">STL exceptions</a>
|
||||||
<li><a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a>
|
<li><a href="Library.html#Library_std_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>
|
<li><a href="Library.html#Library_std_auto_ptr">auto_ptr smart pointer</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="Library.html#Library_nn16">Utility Libraries</a>
|
<li><a href="Library.html#Library_nn16">Utility Libraries</a>
|
||||||
|
|
@ -377,7 +438,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Arguments.html#Arguments">10 Argument Handling</a></h3>
|
<h3><a href="Arguments.html#Arguments">12 Argument Handling</a></h3>
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -400,7 +461,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Typemaps.html#Typemaps">11 Typemaps</a></h3>
|
<h3><a href="Typemaps.html#Typemaps">13 Typemaps</a></h3>
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -457,10 +518,11 @@
|
||||||
<li><a href="Typemaps.html#Typemaps_nn32">"argout" typemap</a>
|
<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_nn33">"freearg" typemap</a>
|
||||||
<li><a href="Typemaps.html#Typemaps_nn34">"newfree" 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_nn35">"memberin" typemap</a>
|
||||||
<li><a href="Typemaps.html#Typemaps_nn36">"varin" 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#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>
|
</ul>
|
||||||
<li><a href="Typemaps.html#Typemaps_nn39">Some typemap examples</a>
|
<li><a href="Typemaps.html#Typemaps_nn39">Some typemap examples</a>
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -482,6 +544,9 @@
|
||||||
<li><a href="Typemaps.html#Typemaps_runtime_type_checker_usage">Usage</a>
|
<li><a href="Typemaps.html#Typemaps_runtime_type_checker_usage">Usage</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="Typemaps.html#Typemaps_overloading">Typemaps and overloading</a>
|
<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_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_nn47">Passing data between typemaps</a>
|
||||||
<li><a href="Typemaps.html#Typemaps_nn52">C++ "this" pointer</a>
|
<li><a href="Typemaps.html#Typemaps_nn52">C++ "this" pointer</a>
|
||||||
|
|
@ -490,7 +555,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Customization.html#Customization">12 Customization Features</a></h3>
|
<h3><a href="Customization.html#Customization">14 Customization Features</a></h3>
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -518,7 +583,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Contract.html#Contract">13 Contracts</a></h3>
|
<h3><a href="Contract.html#Contract">15 Contracts</a></h3>
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -531,7 +596,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -549,7 +614,55 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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:<command-name></a>
|
||||||
|
<li><a href="Doxygen.html#Doxygen_ignore">doxygen:ignore:<command-name></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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -568,7 +681,8 @@
|
||||||
<li><a href="Warnings.html#Warnings_nn11">Preprocessor (200-299)</a>
|
<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_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_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_nn15">Language module specific (700-899) </a>
|
||||||
<li><a href="Warnings.html#Warnings_nn16">User defined (900-999)</a>
|
<li><a href="Warnings.html#Warnings_nn16">User defined (900-999)</a>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
@ -577,7 +691,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -593,7 +707,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -619,91 +733,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Allegrocl.html#Allegrocl">18 SWIG and Allegro Common Lisp</a></h3>
|
<h3><a href="Android.html#Android">21 SWIG and Android</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>
|
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -721,7 +751,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<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_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_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_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_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>
|
<li><a href="CSharp.html#CSharp_enum_underlying_type">Underlying type for enums</a>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
@ -768,45 +799,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Chicken.html#Chicken">21 SWIG and Chicken</a></h3>
|
<h3><a href="D.html#D">23 SWIG and D</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 <= 1.92</a>
|
|
||||||
</ul>
|
|
||||||
</ul>
|
|
||||||
</div>
|
|
||||||
<!-- INDEX -->
|
|
||||||
|
|
||||||
<h3><a href="D.html#D">22 SWIG and D</a></h3>
|
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -840,7 +833,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -884,7 +877,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -907,19 +900,20 @@
|
||||||
<li><a href="Guile.html#Guile_nn14">Smobs</a>
|
<li><a href="Guile.html#Guile_nn14">Smobs</a>
|
||||||
<li><a href="Guile.html#Guile_nn15">Garbage Collection</a>
|
<li><a href="Guile.html#Guile_nn15">Garbage Collection</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="Guile.html#Guile_nn16">Exception Handling</a>
|
<li><a href="Guile.html#Guile_nn16">Native Guile pointers</a>
|
||||||
<li><a href="Guile.html#Guile_nn17">Procedure documentation</a>
|
<li><a href="Guile.html#Guile_nn17">Exception Handling</a>
|
||||||
<li><a href="Guile.html#Guile_nn18">Procedures with setters</a>
|
<li><a href="Guile.html#Guile_nn18">Procedure documentation</a>
|
||||||
<li><a href="Guile.html#Guile_nn19">GOOPS Proxy Classes</a>
|
<li><a href="Guile.html#Guile_nn19">Procedures with setters</a>
|
||||||
|
<li><a href="Guile.html#Guile_nn20">GOOPS Proxy Classes</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="Guile.html#Guile_nn20">Naming Issues</a>
|
<li><a href="Guile.html#Guile_nn21">Naming Issues</a>
|
||||||
<li><a href="Guile.html#Guile_nn21">Linking</a>
|
<li><a href="Guile.html#Guile_nn22">Linking</a>
|
||||||
</ul>
|
</ul>
|
||||||
</ul>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<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_threading">Director threading issues</a>
|
||||||
<li><a href="Java.html#Java_directors_performance">Director performance tuning</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>
|
<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>
|
</ul>
|
||||||
<li><a href="Java.html#Java_allprotected">Accessing protected members</a>
|
<li><a href="Java.html#Java_allprotected">Accessing protected members</a>
|
||||||
<li><a href="Java.html#Java_common_customization">Common customization features</a>
|
<li><a href="Java.html#Java_common_customization">Common customization features</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="Java.html#Java_helper_functions">C/C++ helper functions</a>
|
<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_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_exception_handling">Exception handling with %exception and %javaexception</a>
|
||||||
<li><a href="Java.html#Java_method_access">Method access with %javamethodmodifiers</a>
|
<li><a href="Java.html#Java_method_access">Method access with %javamethodmodifiers</a>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
@ -1069,7 +1067,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1111,29 +1109,6 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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>
|
<h3><a href="Lua.html#Lua">28 SWIG and Lua</a></h3>
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
@ -1202,108 +1177,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Modula3.html#Modula3">29 SWIG and Modula-3</a></h3>
|
<h3><a href="Octave.html#Octave">29 SWIG and Octave</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>
|
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1343,7 +1217,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1419,7 +1293,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1460,31 +1334,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
||||||
<h3><a href="Pike.html#Pike">35 SWIG and Pike</a></h3>
|
<h3><a href="Python.html#Python">32 SWIG and Python</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>
|
|
||||||
|
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1499,7 +1349,8 @@
|
||||||
<li><a href="Python.html#Python_nn9">Using your module</a>
|
<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_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_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>
|
</ul>
|
||||||
<li><a href="Python.html#Python_nn13">A tour of basic C/C++ wrapping</a>
|
<li><a href="Python.html#Python_nn13">A tour of basic C/C++ wrapping</a>
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -1532,7 +1383,6 @@
|
||||||
<li><a href="Python.html#Python_builtin_overloads">Operator overloads and slots -- use them!</a>
|
<li><a href="Python.html#Python_builtin_overloads">Operator overloads and slots -- use them!</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="Python.html#Python_nn30">Memory management</a>
|
<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>
|
</ul>
|
||||||
<li><a href="Python.html#Python_directors">Cross language polymorphism</a>
|
<li><a href="Python.html#Python_directors">Cross language polymorphism</a>
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -1550,6 +1400,10 @@
|
||||||
<li><a href="Python.html#Python_nn42">Adding additional Python code</a>
|
<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_nn43">Class extension with %extend</a>
|
||||||
<li><a href="Python.html#Python_nn44">Exception handling with %exception</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>
|
</ul>
|
||||||
<li><a href="Python.html#Python_nn45">Tips and techniques</a>
|
<li><a href="Python.html#Python_nn45">Tips and techniques</a>
|
||||||
<ul>
|
<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_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_nn63">Mapping sequences to C arrays</a>
|
||||||
<li><a href="Python.html#Python_nn64">Pointer handling</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>
|
</ul>
|
||||||
<li><a href="Python.html#Python_nn65">Docstring Features</a>
|
<li><a href="Python.html#Python_nn65">Docstring Features</a>
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -1594,12 +1449,13 @@
|
||||||
<li><a href="Python.html#Python_absrelimports">Absolute and relative imports</a>
|
<li><a href="Python.html#Python_absrelimports">Absolute and relative imports</a>
|
||||||
<li><a href="Python.html#Python_absimport">Enforcing absolute import semantics</a>
|
<li><a href="Python.html#Python_absimport">Enforcing absolute import semantics</a>
|
||||||
<li><a href="Python.html#Python_importfrominit">Importing from __init__.py</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_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_package_search">Location of modules</a>
|
||||||
<ul>
|
<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_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_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>
|
<li><a href="Python.html#Python_package_search_static">Statically linked C modules</a>
|
||||||
</ul>
|
</ul>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
@ -1611,11 +1467,16 @@
|
||||||
<li><a href="Python.html#Python_nn77">Byte string output conversion</a>
|
<li><a href="Python.html#Python_nn77">Byte string output conversion</a>
|
||||||
<li><a href="Python.html#Python_2_unicode">Python 2 Unicode</a>
|
<li><a href="Python.html#Python_2_unicode">Python 2 Unicode</a>
|
||||||
</ul>
|
</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>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1631,7 +1492,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1769,7 +1630,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1800,7 +1661,7 @@
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="Scilab.html#Scilab_wrapping_pointers">Pointers</a>
|
<li><a href="Scilab.html#Scilab_wrapping_pointers">Pointers</a>
|
||||||
<ul>
|
<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>
|
<li><a href="Scilab.html#Scilab_wrapping_pointers_null_pointers">Null pointers:</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="Scilab.html#Scilab_wrapping_structs">Structures</a>
|
<li><a href="Scilab.html#Scilab_wrapping_structs">Structures</a>
|
||||||
|
|
@ -1838,7 +1699,7 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1904,7 +1765,74 @@
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -1962,8 +1890,13 @@
|
||||||
<li><a href="Extending.html#Extending_running_test_suite">Running the test-suite</a>
|
<li><a href="Extending.html#Extending_running_test_suite">Running the test-suite</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="Extending.html#Extending_nn43">Documentation</a>
|
<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_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>
|
</ul>
|
||||||
<li><a href="Extending.html#Extending_debugging_options">Debugging Options</a>
|
<li><a href="Extending.html#Extending_debugging_options">Debugging Options</a>
|
||||||
<li><a href="Extending.html#Extending_nn46">Guide to parse tree nodes</a>
|
<li><a href="Extending.html#Extending_nn46">Guide to parse tree nodes</a>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Contract">13 Contracts</a></H1>
|
<H1><a name="Contract">15 Contracts</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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.
|
generated rather than having the program continue to execute.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -51,9 +51,9 @@ is a simple example:
|
||||||
<pre>
|
<pre>
|
||||||
%contract sqrt(double x) {
|
%contract sqrt(double x) {
|
||||||
require:
|
require:
|
||||||
x >= 0;
|
x >= 0;
|
||||||
ensure:
|
ensure:
|
||||||
sqrt >= 0;
|
sqrt >= 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
...
|
...
|
||||||
|
|
@ -95,7 +95,7 @@ RuntimeError: Contract violation: require: (arg1>=0)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -106,20 +106,20 @@ The <tt>%contract</tt> directive can also be applied to class methods and constr
|
||||||
<pre>
|
<pre>
|
||||||
%contract Foo::bar(int x, int y) {
|
%contract Foo::bar(int x, int y) {
|
||||||
require:
|
require:
|
||||||
x > 0;
|
x > 0;
|
||||||
ensure:
|
ensure:
|
||||||
bar > 0;
|
bar > 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
%contract Foo::Foo(int a) {
|
%contract Foo::Foo(int a) {
|
||||||
require:
|
require:
|
||||||
a > 0;
|
a > 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
Foo(int);
|
Foo(int);
|
||||||
int bar(int, int);
|
int bar(int, int);
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -133,7 +133,7 @@ Thus, any contract that you specified for a base class will also be attached to
|
||||||
<pre>
|
<pre>
|
||||||
class Spam : public Foo {
|
class Spam : public Foo {
|
||||||
public:
|
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>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -146,22 +146,22 @@ In addition to this, separate contracts can be applied to both the base class an
|
||||||
<pre>
|
<pre>
|
||||||
%contract Foo::bar(int x, int) {
|
%contract Foo::bar(int x, int) {
|
||||||
require:
|
require:
|
||||||
x > 0;
|
x > 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
%contract Spam::bar(int, int y) {
|
%contract Spam::bar(int, int y) {
|
||||||
require:
|
require:
|
||||||
y > 0;
|
y > 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
int bar(int,int); // Gets Foo::bar contract.
|
int bar(int, int); // Gets Foo::bar contract.
|
||||||
};
|
};
|
||||||
|
|
||||||
class Spam : public Foo {
|
class Spam : public Foo {
|
||||||
public:
|
public:
|
||||||
int bar(int,int); // Gets Foo::bar and Spam::bar contract
|
int bar(int, int); // Gets Foo::bar and Spam::bar contract
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
this means that both the arguments to <tt>Spam::bar</tt> must be positive.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -225,7 +225,7 @@ function can be used in contracts. For example:
|
||||||
|
|
||||||
%contract move(SomeObject *, int direction, in) {
|
%contract move(SomeObject *, int direction, in) {
|
||||||
require:
|
require:
|
||||||
check_direction(direction);
|
check_direction(direction);
|
||||||
}
|
}
|
||||||
|
|
||||||
#define UP 1
|
#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);
|
%aggregate_check(int, check_direction, UP, DOWN, RIGHT, LEFT);
|
||||||
|
|
||||||
%typemap(check) int direction {
|
%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
|
#define UP 1
|
||||||
|
|
@ -263,7 +263,7 @@ Regrettably, there is no automatic way to perform similar checks with enums valu
|
||||||
release.
|
release.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Contract_nn5">13.4 Notes</a></H2>
|
<H2><a name="Contract_nn5">15.4 Notes</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Customization">12 Customization Features</a></H1>
|
<H1><a name="Customization">14 Customization Features</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -46,7 +46,7 @@ of exception handling is presented. Then, a more general-purpose
|
||||||
customization mechanism known as "features" is described.
|
customization mechanism known as "features" is described.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -56,12 +56,12 @@ handler. For example, you can specify the following:
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
%exception {
|
%exception {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (RangeError) {
|
catch (RangeError) {
|
||||||
... handle error ...
|
... handle error ...
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -71,13 +71,13 @@ How the exception is handled depends on the target language, for example, Python
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
%exception {
|
%exception {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (RangeError) {
|
catch (RangeError) {
|
||||||
PyErr_SetString(PyExc_IndexError,"index out-of-bounds");
|
PyErr_SetString(PyExc_IndexError, "index out-of-bounds");
|
||||||
SWIG_fail;
|
SWIG_fail;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre></div>
|
</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.
|
provides the same functionality, but is substantially more flexible.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -116,7 +116,7 @@ static char error_message[256];
|
||||||
static int error_status = 0;
|
static int error_status = 0;
|
||||||
|
|
||||||
void throw_exception(char *msg) {
|
void throw_exception(char *msg) {
|
||||||
strncpy(error_message,msg,256);
|
strncpy(error_message, msg, 256);
|
||||||
error_status = 1;
|
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.
|
and for Perl it is the <tt>croak</tt> method shown above.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -193,7 +193,7 @@ extern int exception_status;
|
||||||
|
|
||||||
#define try if ((exception_status = setjmp(exception_buffer)) == 0)
|
#define try if ((exception_status = setjmp(exception_buffer)) == 0)
|
||||||
#define catch(val) else if (exception_status == val)
|
#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
|
#define finally else
|
||||||
|
|
||||||
/* Exception codes */
|
/* 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.
|
modify it to handle nested <tt>try</tt> declarations.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -280,7 +280,7 @@ class OutOfMemory {};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -305,7 +305,7 @@ The <tt>%allowexception</tt> feature works like any other feature and so can be
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -341,12 +341,12 @@ to specific declaration name. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%exception allocate {
|
%exception allocate {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (MemoryError) {
|
catch (MemoryError) {
|
||||||
croak("Out of memory");
|
croak("Out of memory");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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
|
named "allocate". This would include both global and member
|
||||||
functions. The names supplied to <tt>%exception</tt> follow the same
|
functions. The names supplied to <tt>%exception</tt> follow the same
|
||||||
rules as for <tt>%rename</tt> described in the section on
|
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
|
For example, if you wanted to define
|
||||||
an exception handler for a specific class, you might write this:
|
an exception handler for a specific class, you might write this:
|
||||||
</p>
|
</p>
|
||||||
|
|
@ -364,12 +364,12 @@ an exception handler for a specific class, you might write this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%exception Object::allocate {
|
%exception Object::allocate {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (MemoryError) {
|
catch (MemoryError) {
|
||||||
croak("Out of memory");
|
croak("Out of memory");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -386,12 +386,12 @@ in the specified class as well as for identically named functions appearing in d
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%exception Object::allocate(int) {
|
%exception Object::allocate(int) {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (MemoryError) {
|
catch (MemoryError) {
|
||||||
croak("Out of memory");
|
croak("Out of memory");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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
|
// Define a few exception handlers for specific declarations
|
||||||
%exception Object::allocate(int) {
|
%exception Object::allocate(int) {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (MemoryError) {
|
catch (MemoryError) {
|
||||||
croak("Out of memory");
|
croak("Out of memory");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
%exception Object::getitem {
|
%exception Object::getitem {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (RangeError) {
|
catch (RangeError) {
|
||||||
croak("Index out of range");
|
croak("Index out of range");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
...
|
...
|
||||||
// Read a raw header file
|
// 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.
|
%exception directive is much better.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -516,7 +516,7 @@ The special variables are often used in situations where method calls are logged
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (MemoryError) {
|
catch (MemoryError) {
|
||||||
croak("Out of memory in $decl");
|
croak("Out of memory in $decl");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
void log(const char *message);
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -560,17 +560,17 @@ common scripting language exceptions in a portable manner. For example :</p>
|
||||||
%include exception.i
|
%include exception.i
|
||||||
|
|
||||||
%exception {
|
%exception {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
} catch(RangeError) {
|
} catch(RangeError) {
|
||||||
SWIG_exception(SWIG_ValueError, "Range Error");
|
SWIG_exception(SWIG_ValueError, "Range Error");
|
||||||
} catch(DivisionByZero) {
|
} catch(DivisionByZero) {
|
||||||
SWIG_exception(SWIG_DivisionByZero, "Division by zero");
|
SWIG_exception(SWIG_DivisionByZero, "Division by zero");
|
||||||
} catch(OutOfMemory) {
|
} catch(OutOfMemory) {
|
||||||
SWIG_exception(SWIG_MemoryError, "Out of memory");
|
SWIG_exception(SWIG_MemoryError, "Out of memory");
|
||||||
} catch(...) {
|
} catch(...) {
|
||||||
SWIG_exception(SWIG_RuntimeError,"Unknown exception");
|
SWIG_exception(SWIG_RuntimeError, "Unknown exception");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -600,7 +600,7 @@ SWIG_NullReferenceError
|
||||||
The <tt>SWIG_exception()</tt> function can also be used in typemaps.
|
The <tt>SWIG_exception()</tt> function can also be used in typemaps.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -611,8 +611,8 @@ example, consider a function like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
Foo *blah() {
|
Foo *blah() {
|
||||||
Foo *f = new Foo();
|
Foo *f = new Foo();
|
||||||
return f;
|
return f;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -645,7 +645,7 @@ you can attach it to class members and parameterized declarations as before. Fo
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%newobject ::blah(); // Only applies to global blah
|
%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
|
%newobject *::copy; // Copy method in all classes
|
||||||
...
|
...
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -757,7 +757,7 @@ char *strdup(const char *s);
|
||||||
The results might not be what you expect.
|
The results might not be what you expect.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -771,15 +771,15 @@ using the <tt>%feature</tt> directive. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%feature("except") Object::allocate {
|
%feature("except") Object::allocate {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
catch (MemoryError) {
|
catch (MemoryError) {
|
||||||
croak("Out of memory");
|
croak("Out of memory");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
%feature("new","1") *::copy;
|
%feature("new", "1") *::copy;
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -791,12 +791,12 @@ involving <tt>%feature</tt>:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
#define %exception %feature("except")
|
#define %exception %feature("except")
|
||||||
#define %newobject %feature("new","1")
|
#define %newobject %feature("new", "1")
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<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.
|
section applies to all <tt>%feature</tt> directives.
|
||||||
In fact the <tt>%rename</tt> directive is just a special form of <tt>%feature</tt>.
|
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
|
The matching rules mean that features are very flexible and can be applied with
|
||||||
|
|
@ -811,10 +811,10 @@ are defined. For example:
|
||||||
<pre>
|
<pre>
|
||||||
/* Define a global exception handler */
|
/* Define a global exception handler */
|
||||||
%feature("except") {
|
%feature("except") {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
}
|
}
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
|
|
||||||
... bunch of declarations ...
|
... 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") Object::method %{ $action %};
|
||||||
%feature("except") Object::method " $action ";
|
%feature("except") Object::method " $action ";
|
||||||
%feature("except","$action") Object::method;
|
%feature("except", "$action") Object::method;
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
The syntax in the first variation will generate the <tt>{ }</tt> delimiters used whereas the other variations will not.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -850,7 +850,7 @@ The following is the generic syntax for features:
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<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%};
|
%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">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%feature("except", throws="MyExceptionClass") Object::method {
|
%feature("except", throws="MyExceptionClass") Object::method {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
... code to throw a MyExceptionClass Java exception ...
|
... code to throw a MyExceptionClass Java exception ...
|
||||||
}
|
}
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
Further details can be obtained from the <a href="Java.html#Java_exception_handling">Java exception handling</a> section.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -914,13 +914,13 @@ int red; // mutable
|
||||||
%feature("immutable"); // global enable
|
%feature("immutable"); // global enable
|
||||||
int orange; // immutable
|
int orange; // immutable
|
||||||
|
|
||||||
%feature("immutable","0"); // global disable
|
%feature("immutable", "0"); // global disable
|
||||||
int yellow; // mutable
|
int yellow; // mutable
|
||||||
|
|
||||||
%feature("immutable","1"); // another form of global enable
|
%feature("immutable", "1"); // another form of global enable
|
||||||
int green; // immutable
|
int green; // immutable
|
||||||
|
|
||||||
%feature("immutable",""); // clears the global feature
|
%feature("immutable", ""); // clears the global feature
|
||||||
int blue; // mutable
|
int blue; // mutable
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -932,8 +932,8 @@ The above intersperses SWIG directives with C code. Of course you can target fea
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%feature("immutable","1") orange;
|
%feature("immutable", "1") orange;
|
||||||
%feature("immutable","1") green;
|
%feature("immutable", "1") green;
|
||||||
int red; // mutable
|
int red; // mutable
|
||||||
int orange; // immutable
|
int orange; // immutable
|
||||||
int yellow; // mutable
|
int yellow; // mutable
|
||||||
|
|
@ -949,10 +949,10 @@ The logic above can of course be inverted and rewritten as:
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%feature("immutable","1");
|
%feature("immutable", "1");
|
||||||
%feature("immutable","0") red;
|
%feature("immutable", "0") red;
|
||||||
%feature("immutable","0") yellow;
|
%feature("immutable", "0") yellow;
|
||||||
%feature("immutable","0") blue;
|
%feature("immutable", "0") blue;
|
||||||
int red; // mutable
|
int red; // mutable
|
||||||
int orange; // immutable
|
int orange; // immutable
|
||||||
int yellow; // mutable
|
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.
|
The concept of clearing features is discussed next.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
A feature stays in effect until it is explicitly cleared. A feature is cleared by
|
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.
|
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.
|
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>):
|
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>
|
<pre>
|
||||||
// Define global exception handler
|
// Define global exception handler
|
||||||
%feature("except") {
|
%feature("except") {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
croak("Unknown C++ exception");
|
croak("Unknown C++ exception");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
// Define exception handler for all clone methods to log the method calls
|
// Define exception handler for all clone methods to log the method calls
|
||||||
%feature("except") *::clone() {
|
%feature("except") *::clone() {
|
||||||
try {
|
try {
|
||||||
logger.info("$action");
|
logger.info("$action");
|
||||||
$action
|
$action
|
||||||
} catch (...) {
|
} catch (...) {
|
||||||
croak("Unknown C++ exception");
|
croak("Unknown C++ exception");
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
... initial set of class declarations with clone methods ...
|
... initial set of class declarations with clone methods ...
|
||||||
|
|
||||||
// clear the previously defined feature
|
// clear the previously defined feature
|
||||||
%feature("except","") *::clone();
|
%feature("except", "") *::clone();
|
||||||
|
|
||||||
... final set of class declarations with clone methods ...
|
... final set of class declarations with clone methods ...
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1027,8 +1027,8 @@ However, these clone methods will still have an exception handler (without loggi
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Note that clearing a feature is not always the same as disabling it.
|
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
|
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 -
|
<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.
|
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,
|
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.
|
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">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%feature("except") clone() { logger.info("$action"); $action }
|
%feature("except") clone() { logger.info("$action"); $action }
|
||||||
%feature("except","") *::clone();
|
%feature("except", "") *::clone();
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -1053,7 +1053,7 @@ but this will:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%feature("except") clone() { logger.info("$action"); $action }
|
%feature("except") clone() { logger.info("$action"); $action }
|
||||||
%feature("except","") clone();
|
%feature("except", "") clone();
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -1066,12 +1066,12 @@ The three macros below show this for the "except" feature:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
#define %exception %feature("except")
|
#define %exception %feature("except")
|
||||||
#define %noexception %feature("except","0")
|
#define %noexception %feature("except", "0")
|
||||||
#define %clearexception %feature("except","")
|
#define %clearexception %feature("except", "")
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<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.
|
in SWIG-1.3.23 when the approach to wrapping methods with default arguments was changed.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1158,21 +1158,21 @@ in the Python module. You might use <tt>%feature</tt> to rewrite proxy/shadow cl
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%module example
|
%module example
|
||||||
%rename(bar_id) bar(int,double);
|
%rename(bar_id) bar(int, double);
|
||||||
|
|
||||||
// Rewrite bar() to allow some nice overloading
|
// Rewrite bar() to allow some nice overloading
|
||||||
|
|
||||||
%feature("shadow") Foo::bar(int) %{
|
%feature("shadow") Foo::bar(int) %{
|
||||||
def bar(*args):
|
def bar(*args):
|
||||||
if len(args) == 3:
|
if len(args) == 3:
|
||||||
return apply(examplec.Foo_bar_id,args)
|
return apply(examplec.Foo_bar_id, args)
|
||||||
return apply(examplec.Foo_bar,args)
|
return apply(examplec.Foo_bar, args)
|
||||||
%}
|
%}
|
||||||
|
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
int bar(int x);
|
int bar(int x);
|
||||||
int bar(int x, double y);
|
int bar(int x, double y);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
|
||||||
|
|
@ -6,7 +6,7 @@
|
||||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||||
</head>
|
</head>
|
||||||
<body bgcolor="#FFFFFF">
|
<body bgcolor="#FFFFFF">
|
||||||
<H1><a name="D">22 SWIG and D</a></H1>
|
<H1><a name="D">23 SWIG and D</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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>
|
<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>
|
<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>
|
<dl>
|
||||||
<dt><tt>-d2</tt></dt>
|
<dt><tt>-d2</tt></dt>
|
||||||
|
|
@ -66,8 +66,8 @@
|
||||||
|
|
||||||
<dt><a name="D_splitproxy"></a><tt>-splitproxy</tt></dt>
|
<dt><a name="D_splitproxy"></a><tt>-splitproxy</tt></dt>
|
||||||
<dd>
|
<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>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 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>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>
|
</dd>
|
||||||
|
|
||||||
<dt><tt>-package <pkg></tt></dt>
|
<dt><tt>-package <pkg></tt></dt>
|
||||||
|
|
@ -77,16 +77,16 @@
|
||||||
|
|
||||||
<dt><tt>-wrapperlibrary <wl></tt></dt>
|
<dt><tt>-wrapperlibrary <wl></tt></dt>
|
||||||
<dd>
|
<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>
|
<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>
|
</dd>
|
||||||
</dl>
|
</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# <-> D name comparison</a></H3>
|
<H3><a name="D_typemap_name_comparison">23.3.1 C# <-> D name comparison</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>If you already know the SWIG C# module, you might find the following name comparison table useful:</p>
|
<p>If you already know the SWIG C# module, you might find the following name comparison table useful:</p>
|
||||||
|
|
@ -107,12 +107,12 @@
|
||||||
csimports <-> dimports
|
csimports <-> dimports
|
||||||
csbody <-> dbody
|
csbody <-> dbody
|
||||||
csfinalize <-> ddestructor
|
csfinalize <-> ddestructor
|
||||||
csdestruct <-> ddispose
|
csdisposing <-> ddispose
|
||||||
csdestruct_derived <-> ddispose_derived
|
csdisposing_derived <-> ddispose_derived
|
||||||
</pre></div>
|
</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>
|
<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>
|
<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>
|
<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>
|
<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>
|
<p>Typemaps for code generation in D proxy and type wrapper classes.</p>
|
||||||
|
|
@ -157,13 +157,13 @@
|
||||||
dtype DClass.method(dtype a)</pre></div>
|
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>
|
<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>
|
<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><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>
|
<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();
|
%newobject bar();
|
||||||
SomeClass *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>
|
<div class="targetlang"><pre>
|
||||||
SomeClass foo() {
|
SomeClass foo() {
|
||||||
return new SomeClass(example_im.foo(), false);
|
return new SomeClass(example_im.foo(), false);
|
||||||
|
|
@ -276,7 +280,7 @@ class SomeClass : AnInterface, AnotherInterface {
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
</pre></div>
|
</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>
|
<p>The <tt>$importtype</tt> macro helps you to elegantly solve this problem:</p>
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
%typemap(dimports) RemoteMpe %{
|
%typemap(dimports) RemoteMpe %{
|
||||||
|
|
@ -295,7 +299,7 @@ $importtype(AnotherInterface)
|
||||||
</dl>
|
</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>
|
<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>
|
</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>
|
<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>
|
</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>
|
<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>
|
<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>
|
<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>
|
</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>
|
<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>
|
<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>
|
<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>
|
<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>
|
<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>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>
|
<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>
|
<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
1838
Doc/Manual/Doxygen.html
Normal file
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -6,7 +6,7 @@
|
||||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||||
</head>
|
</head>
|
||||||
<body bgcolor="#FFFFFF">
|
<body bgcolor="#FFFFFF">
|
||||||
<H1><a name="Go">23 SWIG and Go</a></H1>
|
<H1><a name="Go">24 SWIG and Go</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -57,7 +57,7 @@ the Go programming language
|
||||||
see <a href="http://golang.org/">golang.org</a>.
|
see <a href="http://golang.org/">golang.org</a>.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Go_overview">23.1 Overview</a></H2>
|
<H2><a name="Go_overview">24.1 Overview</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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.
|
are not used.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Go_examples">23.2 Examples</a></H2>
|
<H2><a name="Go_examples">24.2 Examples</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -101,7 +101,7 @@ SWIG interface file extension for backwards compatibility with Go 1.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -125,16 +125,15 @@ Go distribution. To generate code for gccgo, you should also use the
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
When using the <tt>-cgo</tt> option, SWIG will generate files that can be used
|
By default SWIG will generate files that can be used directly
|
||||||
directly by <tt>go build</tt>. Starting with the Go 1.5 distribution the
|
by <tt>go build</tt>. This requires Go 1.2 or later. Put your SWIG
|
||||||
<tt>-cgo</tt> option has to be given. Put your SWIG interface file in a
|
interface file in a directory under GOPATH/src, and give it a name
|
||||||
directory under GOPATH/src, and give it a name that does <b>not</b> end in the
|
that does <b>not</b> end in the .swig or .swigcxx extension.
|
||||||
.swig or .swigcxx extension. Typically the SWIG interface file extension is .i
|
Typically the SWIG interface file extension is .i in this case.
|
||||||
in this case.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
% swig -go -cgo example.i
|
% swig -go example.i
|
||||||
% go install
|
% go install
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -144,15 +143,16 @@ usual.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
To use SWIG without the <tt>-cgo</tt> option, more steps are required. Recall
|
SWIG can be used without cgo, via the <tt>-no-cgo</tt> option, but
|
||||||
that this only works with Go versions before 1.5. When using Go version 1.2 or
|
more steps are required. This only works with Go versions before 1.5.
|
||||||
later, or when using gccgo, the code generated by SWIG can be linked directly
|
When using Go version 1.2 or later, or when using gccgo, the code
|
||||||
into the Go program. A typical command sequence when using the Go compiler of
|
generated by SWIG can be linked directly into the Go program. A
|
||||||
the Go distribution would look like this:
|
typical command sequence when using the Go compiler of the Go
|
||||||
|
distribution would look like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<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 code.c # The C library being wrapped.
|
||||||
% gcc -c example_wrap.c
|
% gcc -c example_wrap.c
|
||||||
% go tool 6g example.go
|
% go tool 6g example.go
|
||||||
|
|
@ -169,7 +169,7 @@ sequence for this approach would look like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<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.c
|
||||||
% gcc -c -fpic example_wrap.c
|
% gcc -c -fpic example_wrap.c
|
||||||
% gcc -shared example.o example_wrap.o -o example.so
|
% gcc -shared example.o example_wrap.o -o example.so
|
||||||
|
|
@ -181,7 +181,7 @@ sequence for this approach would look like this:
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -200,10 +200,15 @@ swig -go -help
|
||||||
|
|
||||||
<tr>
|
<tr>
|
||||||
<td>-cgo</td>
|
<td>-cgo</td>
|
||||||
<td>Generate files to be used as input for the Go cgo tool. This
|
<td>Generate files to be used as input for the Go cgo tool. This is
|
||||||
option is required for Go 1.5 and later, and works for Go 1.2 and
|
the default.</td>
|
||||||
later. In the future this option will likely become the
|
</tr>
|
||||||
default.</td>
|
|
||||||
|
<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>
|
||||||
|
|
||||||
<tr>
|
<tr>
|
||||||
|
|
@ -261,18 +266,25 @@ swig -go -help
|
||||||
ignored.</td>
|
ignored.</td>
|
||||||
</tr>
|
</tr>
|
||||||
|
|
||||||
|
<tr>
|
||||||
|
<td>-import-prefix <prefix></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>
|
</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,
|
<p>There are two different approaches to generating wrapper files,
|
||||||
controlled by SWIG's <tt>-cgo</tt> option. The <tt>-cgo</tt> option
|
controlled by SWIG's <tt>-no-cgo</tt> option. The <tt>-no-cgo</tt>
|
||||||
works with Go version 1.2 or later. It is required when using Go
|
option only works with version of Go before 1.5. It is required
|
||||||
version 1.5 or later.</p>
|
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>
|
following files when generating wrapper code:</p>
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -296,8 +308,8 @@ or C++ compiler.
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
<p>When neither the <tt>-cgo</tt> nor the <tt>-gccgo</tt> option is
|
<p>When the <tt>-no-cgo</tt> option is used, and the <tt>-gccgo</tt>
|
||||||
used, SWIG will also generate an additional file:</p>
|
option is not used, SWIG will also generate an additional file:</p>
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>
|
<li>
|
||||||
|
|
@ -308,7 +320,7 @@ combined with the compiled MODULE.go using go tool pack.
|
||||||
</ul>
|
</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>
|
<p>
|
||||||
|
|
@ -318,7 +330,7 @@ modifications have to occur. This section briefly covers the
|
||||||
essential aspects of this wrapping.
|
essential aspects of this wrapping.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -328,7 +340,7 @@ directive. You may override this by using SWIG's <tt>-package</tt>
|
||||||
command line option.
|
command line option.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -360,7 +372,7 @@ followed by that name, and the destructor will be
|
||||||
named <tt>Delete</tt> followed by that name.
|
named <tt>Delete</tt> followed by that name.
|
||||||
</p>
|
</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>
|
<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>
|
directive become Go constants, declared with a <tt>const</tt>
|
||||||
declaration.
|
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>
|
<p>
|
||||||
|
|
@ -378,7 +390,7 @@ usual). The values of the enumeration will become variables in Go;
|
||||||
code should avoid modifying those variables.
|
code should avoid modifying those variables.
|
||||||
</p>
|
</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>
|
<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.
|
for this by calling the Swigcptr() method.
|
||||||
</p>
|
</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>
|
<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
|
<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
|
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>
|
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:
|
objects and fits nicely C++'s RAII idiom. Example:
|
||||||
</p>
|
</p>
|
||||||
<div class="code">
|
<div class="code">
|
||||||
|
|
@ -512,7 +524,7 @@ func main() {
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Using <tt>defer</tt> has limitations though, especially when it comes to
|
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
|
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
|
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
|
the C++ object when the Go object is freed. It is strongly recommended to read
|
||||||
|
|
@ -578,7 +590,7 @@ func (o *GoClassName) Close() {
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -590,16 +602,16 @@ Doing the reverse will require an explicit type assertion, which will
|
||||||
be checked dynamically.
|
be checked dynamically.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
In order to use C++ templates in Go, you must tell SWIG to create
|
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.
|
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>
|
<p>
|
||||||
|
|
@ -611,13 +623,13 @@ work is necessary.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<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
|
with a Go type. In general it is strongly recommended to follow this guide
|
||||||
completely to avoid common pitfalls with directors in Go.
|
completely to avoid common pitfalls with directors in Go.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -639,12 +651,12 @@ public:
|
||||||
virtual ~FooBarAbstract() {};
|
virtual ~FooBarAbstract() {};
|
||||||
|
|
||||||
std::string FooBar() {
|
std::string FooBar() {
|
||||||
return this->Foo() + ", " + this->Bar();
|
return this->Foo() + ", " + this->Bar();
|
||||||
};
|
};
|
||||||
|
|
||||||
protected:
|
protected:
|
||||||
virtual std::string Foo() {
|
virtual std::string Foo() {
|
||||||
return "Foo";
|
return "Foo";
|
||||||
};
|
};
|
||||||
|
|
||||||
virtual std::string Bar() = 0;
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -724,7 +736,7 @@ documentation on directors.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -777,7 +789,7 @@ embedding</a>.
|
||||||
</p>
|
</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>
|
<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>NewDirectorClassName</tt> constructor functions receives a
|
||||||
<tt>DirectorInterface</tt> argument. The methods in the <tt>
|
<tt>DirectorInterface</tt> argument. The methods in the <tt>
|
||||||
DirectorInterface</tt> are a subset of the public and protected virtual methods
|
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++
|
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
|
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>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -843,7 +857,7 @@ the Go methods.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -880,7 +894,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
|
||||||
</p>
|
</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>
|
<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>
|
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
|
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
|
<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
|
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++
|
specifics and to the user the class appears as any other SWIG wrapped C++
|
||||||
class.
|
class.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1013,7 +1027,7 @@ before using <tt>runtime.SetFinalizer</tt> to know all of its gotchas.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1054,7 +1068,7 @@ type overwrittenMethodsOnFooBarAbstract struct {
|
||||||
fb FooBarAbstract
|
fb FooBarAbstract
|
||||||
|
|
||||||
// If additional constructor arguments have been given they are typically
|
// 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 {
|
func (om *overwrittenMethodsOnFooBarAbstract) Foo() string {
|
||||||
|
|
@ -1081,7 +1095,7 @@ func NewFooBarGo() FooBarGo {
|
||||||
// The memory of the FooBarAbstract director object instance can be
|
// The memory of the FooBarAbstract director object instance can be
|
||||||
// automatically freed once the FooBarGo instance is garbage collected by
|
// automatically freed once the FooBarGo instance is garbage collected by
|
||||||
// uncommenting the following line. Please make sure to understand the
|
// 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
|
// DeleteFooBarGo should be deleted if a finalizer is in use or the fooBarGo
|
||||||
// struct needs additional data to prevent double deletion.
|
// struct needs additional data to prevent double deletion.
|
||||||
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)
|
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)
|
||||||
|
|
@ -1142,7 +1156,7 @@ SWIG/Examples/go/director/</a>.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1249,7 +1263,7 @@ that typemap, or add new values, to control how C/C++ types are mapped
|
||||||
into Go types.
|
into Go types.
|
||||||
</p>
|
</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,
|
<p>Because of limitations in the way output arguments are processed in swig,
|
||||||
|
|
@ -1289,7 +1303,7 @@ fraction := modulename.Modf(5.0, ptr)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
<p>Since this is ugly, you may want to wrap the swig-generated API with
|
<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>
|
hide the ugly details.</p>
|
||||||
|
|
||||||
<p>There are no <code>char *OUTPUT</code> typemaps. However you can
|
<p>There are no <code>char *OUTPUT</code> typemaps. However you can
|
||||||
|
|
@ -1302,7 +1316,7 @@ void f(char *output);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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
|
<p>Often the APIs generated by swig are not very natural in go, especially if
|
||||||
|
|
@ -1397,7 +1411,7 @@ func bar() {
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
|
|
||||||
<H1><a name="Guile">24 SWIG and Guile</a></H1>
|
<H1><a name="Guile">25 SWIG and Guile</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -30,13 +30,14 @@
|
||||||
<li><a href="#Guile_nn14">Smobs</a>
|
<li><a href="#Guile_nn14">Smobs</a>
|
||||||
<li><a href="#Guile_nn15">Garbage Collection</a>
|
<li><a href="#Guile_nn15">Garbage Collection</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Guile_nn16">Exception Handling</a>
|
<li><a href="#Guile_nn16">Native Guile pointers</a>
|
||||||
<li><a href="#Guile_nn17">Procedure documentation</a>
|
<li><a href="#Guile_nn17">Exception Handling</a>
|
||||||
<li><a href="#Guile_nn18">Procedures with setters</a>
|
<li><a href="#Guile_nn18">Procedure documentation</a>
|
||||||
<li><a href="#Guile_nn19">GOOPS Proxy Classes</a>
|
<li><a href="#Guile_nn19">Procedures with setters</a>
|
||||||
|
<li><a href="#Guile_nn20">GOOPS Proxy Classes</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Guile_nn20">Naming Issues</a>
|
<li><a href="#Guile_nn21">Naming Issues</a>
|
||||||
<li><a href="#Guile_nn21">Linking</a>
|
<li><a href="#Guile_nn22">Linking</a>
|
||||||
</ul>
|
</ul>
|
||||||
</ul>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -47,7 +48,7 @@
|
||||||
<p>
|
<p>
|
||||||
This section details guile-specific support in SWIG.
|
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>
|
<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
|
so your mileage may vary. To be safe set environment variable
|
||||||
GUILE_AUTO_COMPILE to 0 when using swig generated guile code.
|
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>
|
<p>
|
||||||
|
|
@ -69,7 +70,7 @@ There are three different concepts of "module" involved, defined
|
||||||
separately for SWIG, Guile, and Libtool. To avoid horrible confusion,
|
separately for SWIG, Guile, and Libtool. To avoid horrible confusion,
|
||||||
we explicitly prefix the context, e.g., "guile-module".
|
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
|
<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
|
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.
|
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>
|
<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
|
which manifests in multiple shared-library usage conventions. A set of
|
||||||
policies implementing a usage convention is called a <b>linkage</b>.
|
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>
|
<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
|
<code>SWIG_init</code> via a preprocessor define to avoid symbol
|
||||||
clashes. For this case, however, passive linkage is available.
|
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
|
<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
|
<p>You should use passive linkage rather than simple linkage when you
|
||||||
are using multiple modules.
|
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
|
<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>
|
</div>
|
||||||
</ul>
|
</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
|
<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.
|
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>
|
<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.
|
experimental; the (hobbit4d link) conventions are not well understood.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Guile_nn10">24.5 Underscore Folding</a></H2>
|
<H2><a name="Guile_nn10">25.5 Underscore Folding</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -307,7 +308,7 @@ complained so far.
|
||||||
<code>%rename</code> to specify the Guile name of the wrapped
|
<code>%rename</code> to specify the Guile name of the wrapped
|
||||||
functions and variables (see CHANGES).
|
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>
|
<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>
|
<a href="Customization.html#Customization_features">Features and the %feature directive</a>
|
||||||
for info on how to apply the %feature.</p>
|
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>
|
<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
|
If the Scheme object passed was not a SWIG smob representing a compatible
|
||||||
pointer, a <code>wrong-type-arg</code> exception is raised.
|
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>
|
<p>
|
||||||
|
|
@ -439,7 +440,7 @@ structure describing this type. If a generated GOOPS module has been loaded, sm
|
||||||
the corresponding GOOPS class.</p>
|
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 > 1.8,
|
<p>Garbage collection is a feature of Guile since version 1.6. As SWIG now requires Guile > 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
|
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>
|
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>
|
<p>
|
||||||
|
|
@ -479,7 +487,7 @@ mapping:
|
||||||
The default when not specified here is to use "swig-error".
|
The default when not specified here is to use "swig-error".
|
||||||
See Lib/exception.i for details.
|
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
|
<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
|
typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
|
||||||
details.
|
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
|
<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
|
pointer)</code> and <code>(<var>struct-member</var>-set pointer
|
||||||
value)</code> are <em>not</em> generated.
|
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
|
<p>SWIG can also generate classes and generic functions for use with
|
||||||
|
|
@ -688,7 +696,7 @@ Notice that <Foo> is used before it is defined. The fix is to just put th
|
||||||
<code>%import "foo.h"</code> before the <code>%inline</code> block.
|
<code>%import "foo.h"</code> before the <code>%inline</code> block.
|
||||||
</p>
|
</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
|
<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:)))
|
(use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:)))
|
||||||
</pre></div>
|
</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
|
<p>The guile-modules generated above all need to be linked together. GOOPS support requires
|
||||||
|
|
|
||||||
|
|
@ -13,6 +13,11 @@
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Introduction_nn2">What is SWIG?</a>
|
<li><a href="#Introduction_nn2">What is SWIG?</a>
|
||||||
<li><a href="#Introduction_nn3">Why use 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>
|
<li><a href="#Introduction_nn4">A SWIG example</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Introduction_nn5">SWIG interface file</a>
|
<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
|
every aspect of the language bindings. This is the main reason why SWIG has such a large
|
||||||
user manual ;-).
|
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>
|
<p>
|
||||||
|
|
@ -155,7 +232,7 @@ following C code:
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
/* File : example.c */
|
/* File : example.c */
|
||||||
|
|
||||||
double My_variable = 3.0;
|
double My_variable = 3.0;
|
||||||
|
|
||||||
/* Compute factorial of n */
|
/* Compute factorial of n */
|
||||||
int fact(int 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
|
interface file as shown below (by convention, these files carry a .i
|
||||||
suffix) :
|
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>
|
<div class="code"><pre>
|
||||||
|
|
@ -196,13 +273,13 @@ extern int my_mod(int n, int m);
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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
|
declarations. The <tt>%module</tt> directive defines the name of the
|
||||||
module that will be created by SWIG. The <tt>%{ %}</tt> block
|
module that will be created by SWIG. The <tt>%{ %}</tt> block
|
||||||
provides a location for inserting additional code, such as C header
|
provides a location for inserting additional code, such as C header
|
||||||
files or additional C declarations, into the generated C wrapper code.
|
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>
|
<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
|
<tt>example_wrap.c</tt> reveals a hideous mess. However, you
|
||||||
almost never need to worry about it.
|
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>
|
<p>
|
||||||
|
|
@ -251,7 +328,7 @@ unix > <b>ld -G example.o example_wrap.o -o example.so</b> # This is for Sola
|
||||||
unix > <b>perl5.003
|
unix > <b>perl5.003
|
||||||
use example;
|
use example;
|
||||||
print example::fact(4), "\n";
|
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";
|
print $example::My_variable + 4.5, "\n";
|
||||||
<ctrl-d></b>
|
<ctrl-d></b>
|
||||||
24
|
24
|
||||||
|
|
@ -261,7 +338,7 @@ unix >
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -279,13 +356,13 @@ Type "copyright", "credits" or "license" for more information.
|
||||||
>>> <b>import example</b>
|
>>> <b>import example</b>
|
||||||
>>> <b>example.fact(4)</b>
|
>>> <b>example.fact(4)</b>
|
||||||
24
|
24
|
||||||
>>> <b>example.my_mod(23,7)</b>
|
>>> <b>example.my_mod(23, 7)</b>
|
||||||
2
|
2
|
||||||
>>> <b>example.cvar.My_variable + 4.5</b>
|
>>> <b>example.cvar.My_variable + 4.5</b>
|
||||||
7.5
|
7.5
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -303,7 +380,7 @@ unix > <b>ld -G example.o example_wrap.o -o example.so</b>
|
||||||
unix > <b>perl5.003
|
unix > <b>perl5.003
|
||||||
use example;
|
use example;
|
||||||
print example::fact(4), "\n";
|
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";
|
print $example::My_variable + 4.5, "\n";
|
||||||
<ctrl-d></b>
|
<ctrl-d></b>
|
||||||
24
|
24
|
||||||
|
|
@ -311,7 +388,7 @@ print $example::My_variable + 4.5, "\n";
|
||||||
7.5
|
7.5
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -323,7 +400,7 @@ major features include:
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>Full C99 preprocessing.
|
<li>Full C99 preprocessing.
|
||||||
<li>All ANSI C and C++ datatypes.
|
<li>All ISO C and C++ datatypes.
|
||||||
<li>Functions, variables, and constants.
|
<li>Functions, variables, and constants.
|
||||||
<li>Classes.
|
<li>Classes.
|
||||||
<li>Single and multiple inheritance.
|
<li>Single and multiple inheritance.
|
||||||
|
|
@ -336,7 +413,9 @@ major features include:
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
<p>
|
<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>
|
||||||
|
|
||||||
<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.
|
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>
|
<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.
|
possible to support different types of interfaces depending on the application.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -385,13 +464,13 @@ for further information on this and other Autoconf macros.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<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
|
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.
|
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.
|
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
|
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.
|
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>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<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.
|
For other target languages on Windows a dll, instead of a .pyd file, is usually generated.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -433,7 +512,7 @@ it allows others to forget about the low-level implementation
|
||||||
details.
|
details.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -452,7 +531,7 @@ to work with complicated and unusual C/C++ applications.
|
||||||
Ironically, the freedom that SWIG provides is countered by an
|
Ironically, the freedom that SWIG provides is countered by an
|
||||||
extremely conservative approach to code generation. At its core, SWIG
|
extremely conservative approach to code generation. At its core, SWIG
|
||||||
tries to distill even the most advanced C++ code down to a small
|
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
|
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 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
|
be used on any platform. Again, this is an important part of staying out
|
||||||
|
|
|
||||||
1716
Doc/Manual/Java.html
1716
Doc/Manual/Java.html
File diff suppressed because it is too large
Load diff
|
|
@ -1,13 +1,13 @@
|
||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||||
<html>
|
<html>
|
||||||
<head>
|
<head>
|
||||||
<link rel="stylesheet" type="text/css" href="./style.css">
|
<link rel="stylesheet" type="text/css" href="style.css">
|
||||||
<title></title>
|
<title></title>
|
||||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||||
</head>
|
</head>
|
||||||
<body>
|
<body>
|
||||||
|
|
||||||
<H1><a name="Javascript">26 SWIG and Javascript</a></H1>
|
<H1><a name="Javascript">27 SWIG and Javascript</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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>
|
<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.
|
<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>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>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="http://www.webkit.org/">WebKit</a> is a modern browser implementation available as open-source which can be embedded into an application.
|
<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.
|
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>
|
</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>
|
<p>Suppose that you defined a SWIG module such as the following:</p>
|
||||||
|
|
@ -101,7 +101,7 @@ that era had a component > 99. For example:</p>
|
||||||
<pre>
|
<pre>
|
||||||
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
|
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
|
||||||
</div>
|
</div>
|
||||||
<p>If you're targetting V8 >= 4.3.0, you would just run swig like so:</p>
|
<p>If you're targeting V8 >= 4.3.0, you would just run swig like so:</p>
|
||||||
<div class="shell">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
$ swig -c++ -javascript -v8 example.i</pre>
|
$ swig -c++ -javascript -v8 example.i</pre>
|
||||||
|
|
@ -121,7 +121,7 @@ void example_initialize(v8::Handle<v8::Object> 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++.
|
<b>Note</b>: be aware that <code>v8</code> has a C++ API, and thus, the generated modules must be compiled as C++.
|
||||||
</p>
|
</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>
|
<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>
|
$ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
|
||||||
</div>
|
</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>
|
<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>
|
<ul>
|
||||||
<li><p>Default optional arguments do not work for all targeted interpreters</p></li>
|
<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>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>long long</code> is not supported</p></li>
|
||||||
<li><p><code>%native</code> is not supported</p></li>
|
<li><p><code>%native</code> is not supported</p></li>
|
||||||
<li><p>Javascript callbacks are not supported</p></li>
|
<li><p>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>
|
<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>
|
<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>
|
<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>
|
</div>
|
||||||
<p>A more detailed explanation is given in the <a href="#Javascript_examples">Examples</a> section.</p>
|
<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>
|
<ul>
|
||||||
|
|
@ -233,12 +233,12 @@ require("./build/Release/example")</pre>
|
||||||
$ sudo apt-get remove gyp</pre>
|
$ sudo apt-get remove gyp</pre>
|
||||||
</div>
|
</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>
|
<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>
|
<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>
|
@end</pre>
|
||||||
</div>
|
</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>
|
<p>An integration of a native extension 'example' would look like this:</p>
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
|
|
@ -300,38 +300,38 @@ extern bool example_initialize(JSGlobalContextRef context);
|
||||||
|
|
||||||
int main(int argc, char* argv[])
|
int main(int argc, char* argv[])
|
||||||
{
|
{
|
||||||
// Initialize GTK+
|
// Initialize GTK+
|
||||||
gtk_init(&argc, &argv);
|
gtk_init(&argc, &argv);
|
||||||
|
|
||||||
...
|
...
|
||||||
|
|
||||||
// Create a browser instance
|
// Create a browser instance
|
||||||
WebKitWebView *webView = WEBKIT_WEB_VIEW(webkit_web_view_new());
|
WebKitWebView *webView = WEBKIT_WEB_VIEW(webkit_web_view_new());
|
||||||
WebFrame *webframe = webkit_web_view_get_main_frame(webView);
|
WebFrame *webframe = webkit_web_view_get_main_frame(webView);
|
||||||
JSGlobalContextRef context = webkit_web_frame_get_global_context(webFrame);
|
JSGlobalContextRef context = webkit_web_frame_get_global_context(webFrame);
|
||||||
JSObjectRef global = JSContextGetGlobalObject(context);
|
JSObjectRef global = JSContextGetGlobalObject(context);
|
||||||
|
|
||||||
JSObjectRef exampleModule;
|
JSObjectRef exampleModule;
|
||||||
example_initialize(context, &exampleModule);
|
example_initialize(context, &exampleModule);
|
||||||
JSStringRef jsName = JSStringCreateWithUTF8CString("example");
|
JSStringRef jsName = JSStringCreateWithUTF8CString("example");
|
||||||
JSObjectSetProperty(context, global, jsName, exampleModule, kJSPropertyAttributeReadOnly, NULL);
|
JSObjectSetProperty(context, global, jsName, exampleModule, kJSPropertyAttributeReadOnly, NULL);
|
||||||
JSStringRelease(jsName);
|
JSStringRelease(jsName);
|
||||||
|
|
||||||
...
|
...
|
||||||
|
|
||||||
// Load a web page into the browser instance
|
// Load a web page into the browser instance
|
||||||
webkit_web_view_load_uri(webView, "http://www.webkitgtk.org/");
|
webkit_web_view_load_uri(webView, "http://www.webkitgtk.org/");
|
||||||
|
|
||||||
...
|
...
|
||||||
|
|
||||||
// Run the main GTK+ event loop
|
// Run the main GTK+ event loop
|
||||||
gtk_main();
|
gtk_main();
|
||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}</pre>
|
}</pre>
|
||||||
</div>
|
</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>
|
<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 example = require("example");
|
||||||
var x = 18;
|
var x = 18;
|
||||||
var y = 24;
|
var y = 24;
|
||||||
var z = example.gcd(x,y);
|
var z = example.gcd(x, y);
|
||||||
document.querySelector('#x').innerHTML = x;
|
document.querySelector('#x').innerHTML = x;
|
||||||
document.querySelector('#y').innerHTML = y;
|
document.querySelector('#y').innerHTML = y;
|
||||||
document.querySelector('#z').innerHTML = z;
|
document.querySelector('#z').innerHTML = z;
|
||||||
};</pre>
|
};</pre>
|
||||||
</div>
|
</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>
|
<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>
|
<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
|
// calling the global method
|
||||||
var x = 42;
|
var x = 42;
|
||||||
var y = 105;
|
var y = 105;
|
||||||
var g = example.gcd(x,y);
|
var g = example.gcd(x, y);
|
||||||
|
|
||||||
// Accessing the global variable
|
// Accessing the global variable
|
||||||
var f = example.Foo;
|
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>
|
<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>
|
<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>
|
at emitKey (readline.js:1095:12)</pre>
|
||||||
</div>
|
</div>
|
||||||
<p>
|
<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>
|
</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>
|
<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>
|
<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>
|
...</pre>
|
||||||
</div>
|
</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>
|
<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().
|
.trim().
|
||||||
print(f_init_static_wrappers);</pre>
|
print(f_init_static_wrappers);</pre>
|
||||||
</div>
|
</div>
|
||||||
<p>A code template is registered with the <em>JSEmitter</em> via <code>fragment(name, "template")</code>, e.g.,</p>
|
<p>A code template is registered with the <em>JSEmitter</em> via <code>fragment(name, "template")</code>, e.g., </p>
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%fragment ("jsc_variable_declaration", "templates")
|
%fragment ("jsc_variable_declaration", "templates")
|
||||||
|
|
@ -752,7 +752,7 @@ t_register.replace("$jsparent", state.clazz(NAME_MANGLED))
|
||||||
</div>
|
</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>
|
<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>
|
<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>
|
</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>
|
<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>
|
<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>
|
<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>
|
<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">
|
<div class="code">
|
||||||
<pre>
|
<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;
|
JSObjectRef exception_object;
|
||||||
JSValueRef value_ref;
|
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);
|
exception_object = JSValueToObject(js_context, exception_value_ref, NULL);
|
||||||
|
|
||||||
/* source url */
|
/* source url */
|
||||||
strcpy(return_error_string,"[");
|
strcpy(return_error_string, "[");
|
||||||
jsstring_property_name = JSStringCreateWithUTF8CString("sourceURL");
|
jsstring_property_name = JSStringCreateWithUTF8CString("sourceURL");
|
||||||
value_ref = JSObjectGetProperty(js_context, exception_object, jsstring_property_name, &temporary_exception);
|
value_ref = JSObjectGetProperty(js_context, exception_object, jsstring_property_name, &temporary_exception);
|
||||||
JSStringRelease(jsstring_property_name);
|
JSStringRelease(jsstring_property_name);
|
||||||
|
|
|
||||||
|
|
@ -7,31 +7,38 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Library">9 SWIG library</a></H1>
|
<H1><a name="Library">11 SWIG library</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Library_nn2">The %include directive and library search path</a>
|
<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>
|
<ul>
|
||||||
<li><a href="#Library_nn4">cpointer.i</a>
|
<li><a href="#Library_nn4">cpointer.i</a>
|
||||||
<li><a href="#Library_carrays">carrays.i</a>
|
<li><a href="#Library_carrays">carrays.i</a>
|
||||||
<li><a href="#Library_nn6">cmalloc.i</a>
|
<li><a href="#Library_nn6">cmalloc.i</a>
|
||||||
<li><a href="#Library_nn7">cdata.i</a>
|
<li><a href="#Library_nn7">cdata.i</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Library_nn8">C String Handling</a>
|
<li><a href="#Library_nn8">C string handling</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Library_nn9">Default string handling</a>
|
<li><a href="#Library_nn9">Default string handling</a>
|
||||||
<li><a href="#Library_nn10">Passing binary data</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_nn11">Using %newobject to release memory</a>
|
||||||
<li><a href="#Library_nn12">cstring.i</a>
|
<li><a href="#Library_nn12">cstring.i</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Library_stl_cpp_library">STL/C++ Library</a>
|
<li><a href="#Library_stl_cpp_library">STL/C++ library</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Library_std_string">std::string</a>
|
<li><a href="#Library_std_string">std::string</a>
|
||||||
<li><a href="#Library_std_vector">std::vector</a>
|
<li><a href="#Library_std_vector">std::vector</a>
|
||||||
<li><a href="#Library_stl_exceptions">STL exceptions</a>
|
<li><a href="#Library_stl_exceptions">STL exceptions</a>
|
||||||
<li><a href="#Library_std_shared_ptr">shared_ptr smart pointer</a>
|
<li><a href="#Library_std_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>
|
<li><a href="#Library_std_auto_ptr">auto_ptr smart pointer</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Library_nn16">Utility Libraries</a>
|
<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.
|
carefully if you used the old libraries.
|
||||||
</p>
|
</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>
|
<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.
|
The directories that are searched are displayed when using <tt>-verbose</tt> commandline option.
|
||||||
</p>
|
</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>
|
<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.
|
memory, their use is potentially unsafe and you should exercise caution.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -115,7 +122,7 @@ this module is in generating pointers to primitive datatypes such as
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%pointer_functions(type,name)</tt></b>
|
<b><tt>%pointer_functions(type, name)</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
@ -195,7 +202,7 @@ Now, in Python:
|
||||||
<pre>
|
<pre>
|
||||||
>>> import example
|
>>> import example
|
||||||
>>> c = example.new_intp() # Create an "int" for storing result
|
>>> c = example.new_intp() # Create an "int" for storing result
|
||||||
>>> example.add(3,4,c) # Call function
|
>>> example.add(3, 4, c) # Call function
|
||||||
>>> example.intp_value(c) # Dereference
|
>>> example.intp_value(c) # Dereference
|
||||||
7
|
7
|
||||||
>>> example.delete_intp(c) # Delete
|
>>> example.delete_intp(c) # Delete
|
||||||
|
|
@ -205,7 +212,7 @@ Now, in Python:
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%pointer_class(type,name)</tt></b>
|
<b><tt>%pointer_class(type, name)</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
@ -218,13 +225,13 @@ interface is as follows:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
struct name {
|
struct name {
|
||||||
name(); // Create pointer object
|
name(); // Create pointer object
|
||||||
~name(); // Delete pointer object
|
~name(); // Delete pointer object
|
||||||
void assign(type value); // Assign value
|
void assign(type value); // Assign value
|
||||||
type value(); // Get value
|
type value(); // Get value
|
||||||
type *cast(); // Cast the pointer to original type
|
type *cast(); // Cast the pointer to original type
|
||||||
static name *frompointer(type *); // Create class wrapper from existing
|
static name *frompointer(type *); // Create class wrapper from existing
|
||||||
// pointer
|
// pointer
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -275,7 +282,7 @@ Now, in Python (using proxy classes)
|
||||||
<pre>
|
<pre>
|
||||||
>>> import example
|
>>> import example
|
||||||
>>> c = example.intp() # Create an "int" for storing result
|
>>> c = example.intp() # Create an "int" for storing result
|
||||||
>>> example.add(3,4,c) # Call function
|
>>> example.add(3, 4, c) # Call function
|
||||||
>>> c.value() # Dereference
|
>>> c.value() # Dereference
|
||||||
7
|
7
|
||||||
</pre>
|
</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.
|
<b>Note:</b> When working with simple pointers, typemaps can often be used to provide more seamless operation.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -331,7 +338,7 @@ raw C array data.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%array_functions(type,name)</tt></b>
|
<b><tt>%array_functions(type, name)</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
@ -384,10 +391,10 @@ function like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
void print_array(double x[10]) {
|
void print_array(double x[10]) {
|
||||||
int i;
|
int i;
|
||||||
for (i = 0; i < 10; i++) {
|
for (i = 0; i < 10; i++) {
|
||||||
printf("[%d] = %g\n", i, x[i]);
|
printf("[%d] = %g\n", i, x[i]);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -411,20 +418,20 @@ void print_array(double x[10]);
|
||||||
Now, in a scripting language, you might write this:
|
Now, in a scripting language, you might write this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
a = new_doubleArray(10) # Create an array
|
a = new_doubleArray(10) # Create an array
|
||||||
for i in range(0,10):
|
for i in range(0, 10):
|
||||||
doubleArray_setitem(a,i,2*i) # Set a value
|
doubleArray_setitem(a, i, 2 * i) # Set a value
|
||||||
print_array(a) # Pass to C
|
print_array(a) # Pass to C
|
||||||
delete_doubleArray(a) # Destroy array
|
delete_doubleArray(a) # Destroy array
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%array_class(type,name)</tt></b>
|
<b><tt>%array_class(type, name)</tt></b>
|
||||||
</p>
|
</p>
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
||||||
|
|
@ -436,13 +443,13 @@ interface is as follows:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
struct name {
|
struct name {
|
||||||
name(int nelements); // Create an array
|
name(int nelements); // Create an array
|
||||||
~name(); // Delete array
|
~name(); // Delete array
|
||||||
type getitem(int index); // Return item
|
type getitem(int index); // Return item
|
||||||
void setitem(int index, type value); // Set item
|
void setitem(int index, type value); // Set item
|
||||||
type *cast(); // Cast to original type
|
type *cast(); // Cast to original type
|
||||||
static name *frompointer(type *); // Create class wrapper from
|
static name *frompointer(type *); // Create class wrapper from
|
||||||
// existing pointer
|
// existing pointer
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -475,12 +482,12 @@ void print_array(double x[10]);
|
||||||
Allows you to do this:
|
Allows you to do this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
import example
|
import example
|
||||||
c = example.doubleArray(10) # Create double[10]
|
c = example.doubleArray(10) # Create double[10]
|
||||||
for i in range(0,10):
|
for i in range(0, 10):
|
||||||
c[i] = 2*i # Assign values
|
c[i] = 2 * i # Assign values
|
||||||
example.print_array(c) # Pass to C
|
example.print_array(c) # Pass to C
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -496,9 +503,10 @@ you should consider using a special array object rather than a bare pointer.
|
||||||
<p>
|
<p>
|
||||||
<b>Note:</b> <tt>%array_functions()</tt> and <tt>%array_class()</tt> should not be
|
<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>.
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -507,7 +515,7 @@ This module defines macros for wrapping the low-level C memory allocation functi
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%malloc(type [,name=type])</tt></b>
|
<b><tt>%malloc(type [, name=type])</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
@ -530,7 +538,7 @@ is not a valid identifier (e.g., "<tt>int *</tt>", "<tt>double **</tt>", etc.).
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%calloc(type [,name=type])</tt></b>
|
<b><tt>%calloc(type [, name=type])</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<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>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%realloc(type [,name=type])</tt></b>
|
<b><tt>%realloc(type [, name=type])</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
@ -574,7 +582,7 @@ it holds 100 integers.
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%free(type [,name=type])</tt></b>
|
<b><tt>%free(type [, name=type])</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
@ -590,7 +598,7 @@ void free_<em>name</em>(<em>type</em> *ptr);
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%sizeof(type [,name=type])</tt></b>
|
<b><tt>%sizeof(type [, name=type])</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
@ -606,7 +614,7 @@ Creates the constant:
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%allocators(type [,name=type])</tt></b>
|
<b><tt>%allocators(type [, name=type])</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent"><p>
|
<div class="indent"><p>
|
||||||
|
|
@ -659,7 +667,7 @@ Now, in a script:
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -716,14 +724,14 @@ Python example:
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> a = intArray(10)
|
>>> a = intArray(10)
|
||||||
>>> for i in range(0,10):
|
>>> for i in range(0, 10):
|
||||||
... a[i] = i
|
... a[i] = i
|
||||||
>>> b = cdata(a,40)
|
>>> b = cdata(a, 40)
|
||||||
>>> b
|
>>> b
|
||||||
'\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\x04
|
'\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'
|
\x00\x00\x00\x05\x00\x00\x00\x06\x00\x00\x00\x07\x00\x00\x00\x08\x00\x00\x00\t'
|
||||||
>>> c = intArray(10)
|
>>> c = intArray(10)
|
||||||
>>> memmove(c,b)
|
>>> memmove(c, b)
|
||||||
>>> print c[4]
|
>>> print c[4]
|
||||||
4
|
4
|
||||||
>>>
|
>>>
|
||||||
|
|
@ -735,7 +743,7 @@ Since the size of data is not always known, the following macro is also defined:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>%cdata(type [,name=type])</tt></b>
|
<b><tt>%cdata(type [, name=type])</tt></b>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
|
|
@ -761,7 +769,7 @@ char *cdata_<em>name</em>(type* ptr, int nitems)
|
||||||
Clearly they are unsafe.
|
Clearly they are unsafe.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -781,7 +789,7 @@ morality. The modules in this section provide basic functionality
|
||||||
for manipulating raw C strings.
|
for manipulating raw C strings.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -801,7 +809,7 @@ target language. In other words, if you were using a language like Tcl,
|
||||||
and you wrote this,
|
and you wrote this,
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
% foo Hello
|
% foo Hello
|
||||||
</pre>
|
</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.
|
not work well with binary data. Instead, strings are assumed to be NULL-terminated.
|
||||||
</p>
|
</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>
|
<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:
|
Now, in the target language, you can use binary string data like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> s = "H\x00\x15eg\x09\x20"
|
>>> s = "H\x00\x15eg\x09\x20"
|
||||||
>>> parity(s,0)
|
>>> parity(s, 0)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>.
|
The <tt>(char *STRING, int LENGTH)</tt> multi-argument typemap is also available in addition to <tt>(char *STRING, size_t LENGTH)</tt>.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -874,9 +882,9 @@ If you have a function that allocates memory like this,
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
char *foo() {
|
char *foo() {
|
||||||
char *result = (char *) malloc(...);
|
char *result = (char *) malloc(...);
|
||||||
...
|
...
|
||||||
return result;
|
return result;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
See <a href="Customization.html#Customization_ownership">Object ownership and %newobject</a> for more details.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -919,16 +927,16 @@ implementation:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
void get_path(char *s) {
|
void get_path(char *s) {
|
||||||
// Potential buffer overflow---uh, oh.
|
// Potential buffer overflow---uh, oh.
|
||||||
sprintf(s,"%s/%s", base_directory, sub_directory);
|
sprintf(s, "%s/%s", base_directory, sub_directory);
|
||||||
}
|
}
|
||||||
...
|
...
|
||||||
// Somewhere else in the C program
|
// Somewhere else in the C program
|
||||||
{
|
{
|
||||||
char path[1024];
|
char path[1024];
|
||||||
...
|
...
|
||||||
get_path(path);
|
get_path(path);
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1236,8 +1244,8 @@ returned in a parameter of type <tt>char **</tt>. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
void foo(char **s) {
|
void foo(char **s) {
|
||||||
*s = (char *) malloc(64);
|
*s = (char *) malloc(64);
|
||||||
sprintf(*s, "Hello world\n");
|
sprintf(*s, "Hello world\n");
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1284,10 +1292,10 @@ returned in two parameters of type <tt>char **</tt> and <tt>int *</tt>. For exa
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
void foo(char **s, int *sz) {
|
void foo(char **s, int *sz) {
|
||||||
*s = (char *) malloc(64);
|
*s = (char *) malloc(64);
|
||||||
*sz = 64;
|
*sz = 64;
|
||||||
// Write some binary data
|
// Write some binary data
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1337,7 +1345,7 @@ You could wrap it with a function like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
void my_get_data(char **result, int *len) {
|
void my_get_data(char **result, int *len) {
|
||||||
*result = get_data(len);
|
*result = get_data(len);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1357,7 +1365,7 @@ to accomplish this in SWIG. This library provides support for a few common tech
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
<li>If used in C++, this library uses <tt>new</tt> and <tt>delete []</tt> for memory
|
<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>
|
||||||
|
|
||||||
<li>Rather than manipulating <tt>char *</tt> directly, you might consider using a special string
|
<li>Rather than manipulating <tt>char *</tt> directly, you might consider using a special string
|
||||||
|
|
@ -1365,7 +1373,7 @@ structure or class instead.
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</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>
|
<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>
|
<td><b>SWIG Interface library file</b></td>
|
||||||
</tr>
|
</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::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::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::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::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::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::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::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::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::wstring</td> <td>wstring</td> <td>std_wstring.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::shared_ptr (C++11)</td> <td>shared_ptr</td> <td>std_shared_ptr.i</td> </tr>
|
||||||
|
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
|
|
@ -1404,7 +1420,7 @@ Please look for the library files in the appropriate language library directory.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1460,7 +1476,7 @@ In the target language:
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
x = my_struct();
|
x = my_struct();
|
||||||
x.foo="Hello World"; # assign with string
|
x.foo = "Hello World"; # assign with string
|
||||||
print x.foo; # print as string
|
print x.foo; # print as string
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1488,7 +1504,7 @@ void foo(string s, const String &t); // std_string typemaps still applie
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1503,8 +1519,8 @@ instantiate different versions of <tt>vector</tt> for the types that you want to
|
||||||
%include "std_vector.i"
|
%include "std_vector.i"
|
||||||
|
|
||||||
namespace std {
|
namespace std {
|
||||||
%template(vectori) vector<int>;
|
%template(vectori) vector<int>;
|
||||||
%template(vectord) vector<double>;
|
%template(vectord) vector<double>;
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1554,19 +1570,19 @@ To illustrate the use of this library, consider the following functions:
|
||||||
#include <numeric>
|
#include <numeric>
|
||||||
|
|
||||||
double average(std::vector<int> v) {
|
double average(std::vector<int> 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<double> half(const std::vector<double>& v) {
|
std::vector<double> half(const std::vector<double>& v) {
|
||||||
std::vector<double> w(v);
|
std::vector<double> w(v);
|
||||||
for (unsigned int i=0; i<w.size(); i++)
|
for (unsigned int i=0; i<w.size(); i++)
|
||||||
w[i] /= 2.0;
|
w[i] /= 2.0;
|
||||||
return w;
|
return w;
|
||||||
}
|
}
|
||||||
|
|
||||||
void halve_in_place(std::vector<double>& v) {
|
void halve_in_place(std::vector<double>& v) {
|
||||||
std::transform(v.begin(),v.end(),v.begin(),
|
for (std::vector<double>::iterator it = v.begin(); it != v.end(); ++it)
|
||||||
std::bind2nd(std::divides<double>(),2.0));
|
*it /= 2.0;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1585,8 +1601,8 @@ To wrap with SWIG, you might write the following:
|
||||||
%include "std_vector.i"
|
%include "std_vector.i"
|
||||||
// Instantiate templates used by example
|
// Instantiate templates used by example
|
||||||
namespace std {
|
namespace std {
|
||||||
%template(IntVector) vector<int>;
|
%template(IntVector) vector<int>;
|
||||||
%template(DoubleVector) vector<double>;
|
%template(DoubleVector) vector<double>;
|
||||||
}
|
}
|
||||||
|
|
||||||
// Include the header file with above prototypes
|
// Include the header file with above prototypes
|
||||||
|
|
@ -1602,20 +1618,20 @@ Now, to illustrate the behavior in the scripting interpreter, consider this Pyth
|
||||||
<pre>
|
<pre>
|
||||||
>>> from example import *
|
>>> from example import *
|
||||||
>>> iv = IntVector(4) # Create an vector<int>
|
>>> iv = IntVector(4) # Create an vector<int>
|
||||||
>>> for i in range(0,4):
|
>>> for i in range(0, 4):
|
||||||
... iv[i] = i
|
... iv[i] = i
|
||||||
>>> average(iv) # Call method
|
>>> average(iv) # Call method
|
||||||
1.5
|
1.5
|
||||||
>>> average([0,1,2,3]) # Call with list
|
>>> average([0, 1, 2, 3]) # Call with list
|
||||||
1.5
|
1.5
|
||||||
>>> half([1,2,3]) # Half a list
|
>>> half([1, 2, 3]) # Half a list
|
||||||
(0.5,1.0,1.5)
|
(0.5, 1.0, 1.5)
|
||||||
>>> halve_in_place([1,2,3]) # Oops
|
>>> halve_in_place([1, 2, 3]) # Oops
|
||||||
Traceback (most recent call last):
|
Traceback (most recent call last):
|
||||||
File "<stdin>", line 1, in ?
|
File "<stdin>", line 1, in ?
|
||||||
TypeError: Type error. Expected _p_std__vectorTdouble_t
|
TypeError: Type error. Expected _p_std__vectorTdouble_t
|
||||||
>>> dv = DoubleVector(4)
|
>>> dv = DoubleVector(4)
|
||||||
>>> for i in range(0,4):
|
>>> for i in range(0, 4):
|
||||||
... dv[i] = i
|
... dv[i] = i
|
||||||
>>> halve_in_place(dv) # Ok
|
>>> halve_in_place(dv) # Ok
|
||||||
>>> for i in dv:
|
>>> for i in dv:
|
||||||
|
|
@ -1629,7 +1645,7 @@ TypeError: Type error. Expected _p_std__vectorTdouble_t
|
||||||
Traceback (most recent call last):
|
Traceback (most recent call last):
|
||||||
File "<stdin>", line 1, in ?
|
File "<stdin>", line 1, in ?
|
||||||
File "example.py", line 81, in __setitem__
|
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
|
IndexError: vector index out of range
|
||||||
>>>
|
>>>
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1645,7 +1661,7 @@ make sure you include the appropriate <tt>using</tt> or typedef directives. For
|
||||||
%include "std_vector.i"
|
%include "std_vector.i"
|
||||||
|
|
||||||
namespace std {
|
namespace std {
|
||||||
%template(IntVector) vector<int>;
|
%template(IntVector) vector<int>;
|
||||||
}
|
}
|
||||||
|
|
||||||
using namespace std;
|
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.
|
details and the public API exposed to the interpreter vary.
|
||||||
</p>
|
</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>
|
<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.
|
Any thrown STL exceptions will then be gracefully handled instead of causing a crash.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1813,8 +1832,11 @@ System.out.println(val1 + " " + val2);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
<H4><a name="Library_shared_ptr_inheritance">11.4.4.2 shared_ptr and inheritance</a></H4>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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>.
|
<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 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.
|
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">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%include "boost_shared_ptr.i"
|
%include <boost_shared_ptr.i>
|
||||||
%shared_ptr(GrandParent);
|
%shared_ptr(GrandParent);
|
||||||
%shared_ptr(Parent);
|
%shared_ptr(Parent);
|
||||||
%shared_ptr(Child);
|
%shared_ptr(Child);
|
||||||
|
|
@ -1901,14 +1923,79 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
<H4><a name="Library_shared_ptr_overloading">11.4.4.3 shared_ptr and method overloading</a></H4>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b>Note:</b> There is somewhat limited support for <tt>%shared_ptr</tt> and the director feature
|
A C++ compiler can disambiguate a method overloaded by a shared_ptr and one using the raw underlying type.
|
||||||
and the degress of success varies among the different target languages.
|
For example, either one of these methods can be called in C++:
|
||||||
Please help to improve this support by providing patches with improvements.
|
</p>
|
||||||
|
|
||||||
|
<div class="code">
|
||||||
|
<pre>
|
||||||
|
int age(std::shared_ptr<GrandParent> num);
|
||||||
|
int age(GrandParent& 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 <memory>
|
||||||
|
|
||||||
|
template<int N> struct Number {
|
||||||
|
int num;
|
||||||
|
Number() : num(N) {}
|
||||||
|
static std::shared_ptr<Number<N>> make() { return std::make_shared<Number<N>>(); }
|
||||||
|
};
|
||||||
|
</pre>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
The SWIG code below shows the required ordering:
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<div class="code">
|
||||||
|
<pre>
|
||||||
|
%include <std_shared_ptr.i>
|
||||||
|
|
||||||
|
%shared_ptr(Number<10>);
|
||||||
|
%shared_ptr(Number<42>);
|
||||||
|
|
||||||
|
%{
|
||||||
|
#include "number.h"
|
||||||
|
%}
|
||||||
|
%include "number.h"
|
||||||
|
|
||||||
|
%template(Number10) Number<10>;
|
||||||
|
%template(Number42) Number<42>;
|
||||||
|
</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>
|
</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>
|
<p>
|
||||||
|
|
@ -1957,10 +2044,10 @@ int value = k.getValue();
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -2011,11 +2098,11 @@ For example:
|
||||||
<pre>
|
<pre>
|
||||||
%include "exception.i"
|
%include "exception.i"
|
||||||
%exception std::vector::getitem {
|
%exception std::vector::getitem {
|
||||||
try {
|
try {
|
||||||
$action
|
$action
|
||||||
} catch (std::out_of_range& e) {
|
} catch (std::out_of_range& e) {
|
||||||
SWIG_exception(SWIG_IndexError,const_cast<char*>(e.what()));
|
SWIG_exception(SWIG_IndexError, const_cast<char*>(e.what()));
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
|
||||||
|
|
@ -7,11 +7,10 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Lisp_nn2">Allegro Common Lisp</a>
|
|
||||||
<li><a href="#Lisp_nn3">Common Foreign Function Interface(CFFI)</a>
|
<li><a href="#Lisp_nn3">Common Foreign Function Interface(CFFI)</a>
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Lisp_nn4">Additional Commandline Options </a>
|
<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_nn6">Generating CFFI bindings for C++ code</a>
|
||||||
<li><a href="#Lisp_nn7">Inserting user code into generated files</a>
|
<li><a href="#Lisp_nn7">Inserting user code into generated files</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Lisp_nn8">CLISP</a>
|
|
||||||
<ul>
|
<ul>
|
||||||
<li><a href="#Lisp_nn9">Additional Commandline Options </a>
|
<li><a href="#Lisp_nn9">Additional Commandline Options </a>
|
||||||
<li><a href="#Lisp_nn10">Details on CLISP bindings</a>
|
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Lisp_nn11">UFFI </a>
|
|
||||||
</ul>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
|
|
@ -38,26 +34,17 @@
|
||||||
finance, and also common in computer science education.
|
finance, and also common in computer science education.
|
||||||
There are more than 9 different implementations of common lisp which
|
There are more than 9 different implementations of common lisp which
|
||||||
are available, all have different foreign function
|
are available, all have different foreign function
|
||||||
interfaces. SWIG currently supports only the Allegro Common
|
interfaces. SWIG currently supports the
|
||||||
Lisp, Common Foreign Function Interface(CFFI), CLisp and UFFI
|
Common Foreign Function Interface(CFFI).
|
||||||
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>
|
|
||||||
</p>
|
</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>
|
<p>
|
||||||
CFFI, the Common Foreign Function Interface, is a portable foreign
|
CFFI, the Common Foreign Function Interface, is a portable foreign
|
||||||
function interface for ANSI Common Lisp systems, similar in
|
function interface for ANSI Common Lisp systems.
|
||||||
spirit to UFFI. Unlike UFFI, CFFI requires only a small set of
|
CFFI requires only a small set of
|
||||||
low-level functionality from the Lisp implementation, such as
|
low-level functionality from the Lisp implementation, such as
|
||||||
calling a foreign function by name, allocating foreign memory,
|
calling a foreign function by name, allocating foreign memory,
|
||||||
and dereferencing pointers.
|
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.
|
files and the various things which you can do with them.
|
||||||
</p>
|
</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">
|
<table summary="CFFI specific options">
|
||||||
<tr>
|
<tr>
|
||||||
<th> CFFI specific options</th>
|
<th> CFFI specific options</th>
|
||||||
|
|
@ -119,12 +97,15 @@ swig -cffi -help
|
||||||
|
|
||||||
</table>
|
</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
|
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
|
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:
|
file named <i>test.h</i> with the following C code:
|
||||||
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
#define y 5
|
#define y 5
|
||||||
|
|
@ -134,29 +115,31 @@ typedef int days;
|
||||||
|
|
||||||
struct bar {
|
struct bar {
|
||||||
short p, q;
|
short p, q;
|
||||||
char a, b;
|
char a, b;
|
||||||
int *z[1000];
|
int *z[1000];
|
||||||
struct bar * n;
|
struct bar * n;
|
||||||
};
|
};
|
||||||
|
|
||||||
struct bar * my_struct;
|
struct bar * my_struct;
|
||||||
|
|
||||||
struct foo {
|
struct foo {
|
||||||
int a;
|
int a;
|
||||||
struct foo * b[100];
|
struct foo * b[100];
|
||||||
|
|
||||||
};
|
};
|
||||||
|
|
||||||
int pointer_func(void (*ClosureFun)( void* _fun, void* _data, void* _evt ), int p);
|
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);
|
void lispsort_double (int n, double * array);
|
||||||
|
|
||||||
enum color { RED, BLUE, GREEN};
|
enum color { RED, BLUE, GREEN};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
<p>
|
||||||
Corresponding to this we will write a simple interface file:
|
Corresponding to this we will write a simple interface file:
|
||||||
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
%module test
|
%module test
|
||||||
|
|
||||||
|
|
@ -164,18 +147,20 @@ Corresponding to this we will write a simple interface file:
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
<p>
|
||||||
The generated SWIG Code will be:
|
The generated SWIG Code will be:
|
||||||
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
;;;SWIG wrapper code starts here
|
;;;SWIG wrapper code starts here
|
||||||
|
|
||||||
(cl:defmacro defanonenum (&body enums)
|
(cl:defmacro defanonenum (&body enums)
|
||||||
"Converts anonymous enums to defconstants."
|
"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)
|
for index = 0 then (cl:1+ index)
|
||||||
when (cl:listp value) do (cl:setf index (cl:second value)
|
when (cl:listp value) do (cl:setf index (cl:second value)
|
||||||
value (cl:first value))
|
value (cl:first value))
|
||||||
collect `(cl:defconstant ,value ,index))))
|
collect `(cl:defconstant , value , index))))
|
||||||
|
|
||||||
(cl:eval-when (:compile-toplevel :load-toplevel)
|
(cl:eval-when (:compile-toplevel :load-toplevel)
|
||||||
(cl:unless (cl:fboundp 'swig-lispify)
|
(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";
|
%typemap(cin) div_t* ":my-pointer";
|
||||||
|
|
||||||
%feature("intern_function","1");
|
%feature("intern_function", "1");
|
||||||
%feature("export");
|
%feature("export");
|
||||||
|
|
||||||
%feature("inline") lispsort_double;
|
%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
|
The feature <i>intern_function</i> ensures that all C names are
|
||||||
interned using the <b>swig-lispify</b> function. The "1" given
|
interned using the <b>swig-lispify</b> function. The "1" given
|
||||||
to the feature is optional. The use of feature like
|
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
|
interning for everything. If you want to target a single
|
||||||
function, or declaration then use the targeted version of
|
function, or declaration then use the targeted version of
|
||||||
feature, <i>%feature("intern_function", "my-lispify")
|
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>
|
</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
|
<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"
|
%include "target/header.h"
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
<p>
|
||||||
Various features which were available for C headers can also be used
|
Various features which were available for C headers can also be used
|
||||||
here. The target header which we are going to use here is:
|
here. The target header which we are going to use here is:
|
||||||
|
</p>
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
namespace OpenDemo {
|
namespace OpenDemo {
|
||||||
class Test
|
class Test
|
||||||
{
|
{
|
||||||
public:
|
public:
|
||||||
float x;
|
float x;
|
||||||
// constructors
|
// constructors
|
||||||
Test (void) {x = 0;}
|
Test (void) {x = 0;}
|
||||||
Test (float X) {x = X;}
|
Test (float X) {x = X;}
|
||||||
|
|
||||||
// vector addition
|
// vector addition
|
||||||
Test operator+ (const Test& v) const {return Test (x+v.x);}
|
Test operator+ (const Test& v) const {return Test (x+v.x);}
|
||||||
|
|
||||||
// length squared
|
// length squared
|
||||||
float lengthSquared (void) const {return this->dot (*this);}
|
float lengthSquared (void) const {return this->dot (*this);}
|
||||||
|
|
||||||
static float distance (const Test& a, const Test& b){return(a-b).length();}
|
static float distance (const Test& a, const Test& b){return(a-b).length();}
|
||||||
|
|
||||||
inline Test parallelComponent (const Test& unitBasis) const {
|
inline Test parallelComponent (const Test& unitBasis) const {
|
||||||
return unitBasis * projection;
|
return unitBasis * projection;
|
||||||
}
|
}
|
||||||
|
|
||||||
Test setYtoZero (void) const {return Test (this->x);}
|
Test setYtoZero (void) const {return Test (this->x);}
|
||||||
|
|
||||||
static const Test zero;
|
static const Test zero;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
inline Test operator* (float s, const Test& v) {return v*s;}
|
||||||
|
|
||||||
inline Test operator* (float s, const Test& v) {return v*s;}
|
inline std::ostream& operator<< (std::ostream& o, const Test& v)
|
||||||
|
{
|
||||||
|
return o << "(" << v.x << ")";
|
||||||
|
}
|
||||||
|
|
||||||
|
inline Test RandomUnitVectorOnXZPlane (void)
|
||||||
inline std::ostream& operator<< (std::ostream& o, const Test& v)
|
{
|
||||||
{
|
return RandomVectorInUnitRadiusSphere().setYtoZero().normalize();
|
||||||
return o << "(" << v.x << ")";
|
}
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
inline Test RandomUnitVectorOnXZPlane (void)
|
|
||||||
{
|
|
||||||
return RandomVectorInUnitRadiusSphere().setYtoZero().normalize();
|
|
||||||
}
|
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>The interface used is: </p>
|
<p>The interface used is: </p>
|
||||||
|
|
@ -482,8 +466,10 @@ namespace OpenDemo {
|
||||||
%include "test.cpp"
|
%include "test.cpp"
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
<p>
|
||||||
SWIG generates 3 files, the first one is a C wrap which we don't show,
|
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:
|
the second is the plain CFFI wrapper which is as shown below:
|
||||||
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
(cffi:defcfun ("_wrap_Test_x_set" Test_x_set) :void
|
(cffi:defcfun ("_wrap_Test_x_set" Test_x_set) :void
|
||||||
(self :pointer)
|
(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)
|
(cffi:defcfun ("_wrap_RandomUnitVectorOnXZPlane" RandomUnitVectorOnXZPlane) :pointer)
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
<p>
|
||||||
The output is pretty good but it fails in disambiguating overloaded
|
The output is pretty good but it fails in disambiguating overloaded
|
||||||
functions such as the constructor, in this case. One way of
|
functions such as the constructor, in this case. One way of
|
||||||
resolving this problem is to make the interface use the rename
|
resolving this problem is to make the interface use the rename
|
||||||
directiv, but hopefully there are better solutions.
|
directiv, but hopefully there are better solutions.
|
||||||
In addition SWIG also generates, a CLOS file
|
In addition SWIG also generates, a CLOS file
|
||||||
|
</p>
|
||||||
|
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<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
|
module feel free to contact us on the SWIG mailing list, and
|
||||||
also please add a "[CFFI]" tag in the subject line.
|
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>
|
<p>
|
||||||
|
|
@ -612,195 +600,5 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
|
||||||
</p>
|
</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>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
|
|
|
||||||
|
|
@ -77,7 +77,7 @@
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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 <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 <100 kilobytes of binary code. It can be found at <a href="http://www.lua.org">http://www.lua.org</a>
|
||||||
</p>
|
</p>
|
||||||
<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>
|
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
|
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;
|
lua_State *L;
|
||||||
if (argc<2)
|
if (argc<2)
|
||||||
{
|
{
|
||||||
printf("%s: <filename.lua>\n",argv[0]);
|
printf("%s: <filename.lua>\n", argv[0]);
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
L=lua_open();
|
L=lua_open();
|
||||||
luaopen_base(L); // load basic libs (eg. print)
|
luaopen_base(L); // load basic libs (eg. print)
|
||||||
luaopen_example(L); // load the wrapped module
|
luaopen_example(L); // load the wrapped module
|
||||||
if (luaL_loadfile(L,argv[1])==0) // load and run the file
|
if (luaL_loadfile(L, argv[1])==0) // load and run the file
|
||||||
lua_pcall(L,0,0,0);
|
lua_pcall(L, 0, 0, 0);
|
||||||
else
|
else
|
||||||
printf("unable to load %s\n",argv[1]);
|
printf("unable to load %s\n", argv[1]);
|
||||||
lua_close(L);
|
lua_close(L);
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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 & 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 & add a <tt>#define LUA_EXTRALIBS {"example", luaopen_example}</tt>, at the relevant place.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
The exact commands for compiling and linking vary from platform to platform. Here is a possible set of commands of doing this:
|
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
|
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>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
my_init=loadlib("example.so","luaopen_example") -- for Unix/Linux
|
my_init=loadlib("example.so", "luaopen_example") -- for Unix/Linux
|
||||||
--my_init=loadlib("example.dll","luaopen_example") -- for Windows
|
--my_init=loadlib("example.dll", "luaopen_example") -- for Windows
|
||||||
assert(my_init) -- make sure it's not nil
|
assert(my_init) -- make sure it's not nil
|
||||||
my_init() -- call the init fn of the lib
|
my_init() -- call the init fn of the lib
|
||||||
</pre></div>
|
</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
|
Or can be done in a single line of Lua code
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
assert(loadlib("example.so","luaopen_example"))()
|
assert(loadlib("example.so", "luaopen_example"))()
|
||||||
</pre></div>
|
</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).
|
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>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
a,b,c=package.loadlib("example.so","luaopen_example") -- for Unix/Linux
|
a, b, c=package.loadlib("example.so", "luaopen_example") -- for Unix/Linux
|
||||||
--a,b,c=package.loadlib("example.dll","luaopen_example") -- for Windows
|
--a, b, c=package.loadlib("example.dll", "luaopen_example") -- for Windows
|
||||||
print(a,b,c)
|
print(a, b, c)
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
Note: for Lua 5.0:<br>
|
Note: for Lua 5.0:<br>
|
||||||
|
|
@ -326,7 +326,7 @@ Assuming all goes well, you will be able to this:
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
$ ./my_lua
|
$ ./my_lua
|
||||||
> print(example.gcd(4,6))
|
> print(example.gcd(4, 6))
|
||||||
2
|
2
|
||||||
> print(example.Foo)
|
> print(example.Foo)
|
||||||
3
|
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.
|
This option is considered deprecated and will be removed in the near future.
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> for k,v in pairs(example) do _G[k]=v end
|
> for k, v in pairs(example) do _G[k]=v end
|
||||||
> print(fact(4))
|
> print(fact(4))
|
||||||
24
|
24
|
||||||
>
|
>
|
||||||
|
|
@ -411,7 +411,7 @@ SWIG will effectively generate two functions <tt>example.Foo_set()</tt> and <tt>
|
||||||
> print(c)
|
> print(c)
|
||||||
3
|
3
|
||||||
> c=5 -- this will not effect the original example.Foo
|
> c=5 -- this will not effect the original example.Foo
|
||||||
> print(example.Foo,c)
|
> print(example.Foo, c)
|
||||||
4 5
|
4 5
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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
|
<div class="code"><pre>%module example
|
||||||
%constant int ICONST=42;
|
%constant int ICONST=42;
|
||||||
#define SCONST "Hello World"
|
#define SCONST "Hello World"
|
||||||
enum Days{SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY};
|
enum Days{SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
This is 'effectively' converted into the following Lua code:
|
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
|
<div class="code"><pre>%module example
|
||||||
enum Days { SUNDAY = 0, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY };
|
enum Days { SUNDAY = 0, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY };
|
||||||
struct Test {
|
struct Test {
|
||||||
enum { TEST1 = 10, TEST2 = 20 };
|
enum { TEST1 = 10, TEST2 = 20 };
|
||||||
#ifdef __cplusplus // There are no static members in C
|
#ifdef __cplusplus // There are no static members in C
|
||||||
static const int ICONST = 12;
|
static const int ICONST = 12;
|
||||||
#endif
|
#endif
|
||||||
};
|
};
|
||||||
</pre></div>
|
</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:
|
When wrapped, you will be able to use the functions in a natural way from Lua. For example:
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> f=example.fopen("junk","w")
|
> f=example.fopen("junk", "w")
|
||||||
> example.fputs("Hello World",f)
|
> example.fputs("Hello World", f)
|
||||||
> example.fclose(f)
|
> example.fclose(f)
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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 & 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.
|
Lua enforces the integrity of its userdata, so it is virtually impossible to corrupt the data. But as the user of the pointer, you are responsible for freeing it, or closing any resources associated with it (just as you would in a C program). This does not apply so strictly to classes & structs (see below). One final note: if a function returns a NULL pointer, this is not encoded as a userdata, but as a Lua nil.
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> f=example.fopen("not there","r") -- this will return a NULL in C
|
> f=example.fopen("not there", "r") -- this will return a NULL in C
|
||||||
> print(f)
|
> print(f)
|
||||||
nil
|
nil
|
||||||
</pre></div>
|
</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,
|
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>
|
</p>
|
||||||
<div class="code"><pre>struct Point{
|
<div class="code"><pre>struct Point{
|
||||||
int x,y;
|
int x, y;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -623,7 +623,7 @@ is used as follows:
|
||||||
> p=example.new_Point()
|
> p=example.new_Point()
|
||||||
> p.x=3
|
> p.x=3
|
||||||
> p.y=5
|
> p.y=5
|
||||||
> print(p.x,p.y)
|
> print(p.x, p.y)
|
||||||
3 5
|
3 5
|
||||||
>
|
>
|
||||||
</pre></div>
|
</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:
|
<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>
|
</p>
|
||||||
<div class="code"><pre>struct Foo {
|
<div class="code"><pre>struct Foo {
|
||||||
...
|
...
|
||||||
%immutable;
|
%immutable;
|
||||||
int x; // Read-only members
|
int x; // Read-only members
|
||||||
char *name;
|
char *name;
|
||||||
%mutable;
|
%mutable;
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -661,11 +661,11 @@ When a member of a structure is itself a structure, it is handled as a pointer.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>struct Foo {
|
<div class="code"><pre>struct Foo {
|
||||||
int a;
|
int a;
|
||||||
};
|
};
|
||||||
|
|
||||||
struct Bar {
|
struct Bar {
|
||||||
Foo f;
|
Foo f;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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:
|
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>
|
</p>
|
||||||
<div class="code"><pre>struct data {
|
<div class="code"><pre>struct data {
|
||||||
int x, y;
|
int x, y;
|
||||||
double z;
|
double z;
|
||||||
};
|
};
|
||||||
|
|
||||||
> --From eLua
|
> --From eLua
|
||||||
|
|
@ -749,8 +749,8 @@ Class data members are accessed in the same manner as C structures. Static class
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>class Spam {
|
<div class="targetlang"><pre>class Spam {
|
||||||
public:
|
public:
|
||||||
static void foo();
|
static void foo();
|
||||||
static int bar;
|
static int bar;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -871,9 +871,9 @@ Similarly, if you have a class like this,
|
||||||
</p>
|
</p>
|
||||||
<div class="code"><pre>class Foo {
|
<div class="code"><pre>class Foo {
|
||||||
public:
|
public:
|
||||||
Foo();
|
Foo();
|
||||||
Foo(const Foo &);
|
Foo(const Foo &);
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -953,8 +953,8 @@ public:
|
||||||
When wrapped, it works like you expect:
|
When wrapped, it works like you expect:
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> c = Complex(3,4)
|
> c = Complex(3, 4)
|
||||||
> d = Complex(7,8)
|
> d = Complex(7, 8)
|
||||||
> e = c + d
|
> e = c + d
|
||||||
> e:re()
|
> e:re()
|
||||||
10.0
|
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>).
|
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>
|
||||||
<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>
|
<p>
|
||||||
The current list of operators which can be overloaded (and the alternative function names) are:<ul>
|
The current list of operators which can be overloaded (and the alternative function names) are:<ul>
|
||||||
<li><tt>__add__</tt> operator+
|
<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><=</tt>
|
<li><tt>__le__</tt> operator<tt><=</tt>
|
||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
Note: in Lua, only the equals, less than, and less than equals operators are defined. The other operators (!=,>,>=) 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 (!=, >, >=) are achieved by using a logical not applied to the results of other operators.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
The following operators cannot be overloaded (mainly because they are not supported in Lua)<ul>
|
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>
|
<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
|
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>
|
</p>
|
||||||
<div class="code"><pre>const char* __str__()
|
<div class="code"><pre>const char* __str__() {
|
||||||
{
|
static char buffer[255];
|
||||||
static char buffer[255];
|
sprintf(buffer, "Complex(%g, %g)", this->re(), this->im());
|
||||||
sprintf(buffer,"Complex(%g,%g)",this->re(),this->im());
|
return buffer;
|
||||||
return buffer;
|
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
Then this will support the following code in Lua
|
Then this will support the following code in Lua
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> c = Complex(3,4)
|
> c = Complex(3, 4)
|
||||||
> d = Complex(7,8)
|
> d = Complex(7, 8)
|
||||||
> e = c + d
|
> e = c + d
|
||||||
> print(e)
|
> print(e)
|
||||||
Complex(10,12)
|
Complex(10, 12)
|
||||||
> s=tostring(e) -- s is the number in string form
|
> s=tostring(e) -- s is the number in string form
|
||||||
> print(s)
|
> print(s)
|
||||||
Complex(10,12)
|
Complex(10, 12)
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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>
|
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>
|
</p>
|
||||||
<div class="code"><pre>class Complex
|
<div class="code"><pre>class Complex {
|
||||||
{
|
//....
|
||||||
//....
|
double __getitem__(int i)const; // i is the index, returns the data
|
||||||
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
|
||||||
void __setitem__(int i,double d); // i is the index, d is the data
|
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1090,27 +1088,28 @@ public:
|
||||||
Now we extend it with some new code
|
Now we extend it with some new code
|
||||||
</p>
|
</p>
|
||||||
<div class="code"><pre>%extend Complex {
|
<div class="code"><pre>%extend Complex {
|
||||||
const char *__str__() {
|
const char *__str__() {
|
||||||
static char tmp[1024];
|
static char tmp[1024];
|
||||||
sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im());
|
sprintf(tmp, "Complex(%g, %g)", $self->re(), $self->im());
|
||||||
return tmp;
|
return tmp;
|
||||||
}
|
}
|
||||||
bool operator==(const Complex& c)
|
bool operator==(const Complex& c) {
|
||||||
{ return ($self->re()==c.re() && $self->im()==c.im());}
|
return ($self->re()==c.re() && $self->im()==c.im());
|
||||||
|
}
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
Now, in Lua
|
Now, in Lua
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> c = Complex(3,4)
|
> c = Complex(3, 4)
|
||||||
> d = Complex(7,8)
|
> d = Complex(7, 8)
|
||||||
> e = c + d
|
> e = c + d
|
||||||
> print(e) -- print uses __str__ to get the string form to print
|
> print(e) -- print uses __str__ to get the string form to print
|
||||||
Complex(10,12)
|
Complex(10, 12)
|
||||||
> print(e==Complex(10,12)) -- testing the == operator
|
> print(e==Complex(10, 12)) -- testing the == operator
|
||||||
true
|
true
|
||||||
> print(e!=Complex(12,12)) -- the != uses the == operator
|
> print(e!=Complex(12, 12)) -- the != uses the == operator
|
||||||
true
|
true
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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>
|
<p> If you have a function that allocates memory like this,</p>
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>char *foo() {
|
<pre>char *foo() {
|
||||||
char *result = (char *) malloc(...);
|
char *result = (char *) malloc(...);
|
||||||
...
|
...
|
||||||
return result;
|
return result;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1154,23 +1153,23 @@ char *foo();
|
||||||
|
|
||||||
template<class T1, class T2>
|
template<class T1, class T2>
|
||||||
struct pair {
|
struct pair {
|
||||||
typedef T1 first_type;
|
typedef T1 first_type;
|
||||||
typedef T2 second_type;
|
typedef T2 second_type;
|
||||||
T1 first;
|
T1 first;
|
||||||
T2 second;
|
T2 second;
|
||||||
pair();
|
pair();
|
||||||
pair(const T1&, const T2&);
|
pair(const T1&, const T2&);
|
||||||
~pair();
|
~pair();
|
||||||
};
|
};
|
||||||
|
|
||||||
%template(pairii) pair<int,int>;
|
%template(pairii) pair<int, int>;
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
In Lua:
|
In Lua:
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> p = example.pairii(3,4)
|
> p = example.pairii(3, 4)
|
||||||
> print(p.first,p.second)
|
> print(p.first, p.second)
|
||||||
3 4
|
3 4
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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->() like this:
|
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->() like this:
|
||||||
</p>
|
</p>
|
||||||
<div class="code"><pre>template<class T> class SmartPtr {
|
<div class="code"><pre>template<class T> class SmartPtr {
|
||||||
...
|
...
|
||||||
T *operator->();
|
T *operator->();
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1193,8 +1192,8 @@ Then, if you have a class like this,
|
||||||
</p>
|
</p>
|
||||||
<div class="code"><pre>class Foo {
|
<div class="code"><pre>class Foo {
|
||||||
public:
|
public:
|
||||||
int x;
|
int x;
|
||||||
int bar();
|
int bar();
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1264,11 +1263,11 @@ Using xpcall will allow you to obtain additional debug information (such as a st
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> function a() b() end -- function a() calls function b()
|
> function a() b() end -- function a() calls function b()
|
||||||
> function b() message() end -- function b() calls C++ function message(), which throws
|
> function b() message() end -- function b() calls C++ function message(), which throws
|
||||||
> ok,res=pcall(a) -- call the function
|
> ok, res=pcall(a) -- call the function
|
||||||
> print(ok,res)
|
> print(ok, res)
|
||||||
false I died.
|
false I died.
|
||||||
> ok,res=xpcall(a,debug.traceback) -- call the function
|
> ok, res=xpcall(a, debug.traceback) -- call the function
|
||||||
> print(ok,res)
|
> print(ok, res)
|
||||||
false I died.
|
false I died.
|
||||||
stack traceback:
|
stack traceback:
|
||||||
[C]: in function 'message'
|
[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>
|
<div class="code"><pre>
|
||||||
%typemap(throws) my_except
|
%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
|
SWIG_fail; // trigger the error handler
|
||||||
%}
|
%}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -1336,26 +1335,26 @@ class Exc {
|
||||||
public:
|
public:
|
||||||
Exc(int c, const char *m) {
|
Exc(int c, const char *m) {
|
||||||
code = c;
|
code = c;
|
||||||
strncpy(msg,m,256);
|
strncpy(msg, m, 256);
|
||||||
}
|
}
|
||||||
int code;
|
int code;
|
||||||
char msg[256];
|
char msg[256];
|
||||||
};
|
};
|
||||||
|
|
||||||
void throw_exc() throw(Exc) {
|
void throw_exc() throw(Exc) {
|
||||||
throw(Exc(42,"Hosed"));
|
throw(Exc(42, "Hosed"));
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
Then the following code can be used (note: we use pcall to catch the error so we can process the exception).
|
Then the following code can be used (note: we use pcall to catch the error so we can process the exception).
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
> ok,res=pcall(throw_exc)
|
> ok, res=pcall(throw_exc)
|
||||||
> print(ok)
|
> print(ok)
|
||||||
false
|
false
|
||||||
> print(res)
|
> print(res)
|
||||||
userdata: 0003D880
|
userdata: 0003D880
|
||||||
> print(res.code,res.msg)
|
> print(res.code, res.msg)
|
||||||
42 Hosed
|
42 Hosed
|
||||||
>
|
>
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -1536,8 +1535,8 @@ function
|
||||||
<div class="code"><pre>%module example
|
<div class="code"><pre>%module example
|
||||||
|
|
||||||
%typemap(in) int {
|
%typemap(in) int {
|
||||||
$1 = (int) lua_tonumber(L,$input);
|
$1 = (int) lua_tonumber(L, $input);
|
||||||
printf("Received an integer : %d\n",$1);
|
printf("Received an integer : %d\n", $1);
|
||||||
}
|
}
|
||||||
%inline %{
|
%inline %{
|
||||||
extern int fact(int n);
|
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 <typemaps.i>, which contains typemaps for these situations. For example, consider these functions:</p>
|
<p>However for more complex functions which use input/output parameters or arrays, you will need to make use of <typemaps.i>, which contains typemaps for these situations. For example, consider these functions:</p>
|
||||||
|
|
||||||
<div class="code"><pre>void add(int x, int y, int *result) {
|
<div class="code"><pre>void add(int x, int y, int *result) {
|
||||||
*result = x + y;
|
*result = x + y;
|
||||||
}
|
}
|
||||||
|
|
||||||
int sub(int *x1, int *y1) {
|
int sub(int *x1, int *y1) {
|
||||||
return *x1-*y1;
|
return *x1-*y1;
|
||||||
}
|
}
|
||||||
|
|
||||||
void swap(int *sx, int *sy) {
|
void swap(int *sx, int *sy) {
|
||||||
int t=*sx;
|
int t=*sx;
|
||||||
*sx=*sy;
|
*sx=*sy;
|
||||||
*sy=t;
|
*sy=t;
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -1595,13 +1594,13 @@ void swap(int *sx, int *sy);
|
||||||
<p>When wrapped, it gives the following results:</p>
|
<p>When wrapped, it gives the following results:</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>> require "example"
|
<div class="targetlang"><pre>> require "example"
|
||||||
> print(example.add(1,2))
|
> print(example.add(1, 2))
|
||||||
3
|
3
|
||||||
> print(demo.sub(1,2))
|
> print(demo.sub(1, 2))
|
||||||
-1
|
-1
|
||||||
> a,b=1,2
|
> a, b=1, 2
|
||||||
> c,d=demo.swap(a,b)
|
> c, d=demo.swap(a, b)
|
||||||
> print(a,b,c,d)
|
> print(a, b, c, d)
|
||||||
1 2 2 1
|
1 2 2 1
|
||||||
</pre></div>
|
</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
|
<div class="code"><pre>// using the C-array
|
||||||
%include <carrays.i>
|
%include <carrays.i>
|
||||||
// this declares a batch of function for manipulating C integer arrays
|
// 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
|
extern void sort_int(int* arr, int len); // the function to wrap
|
||||||
|
|
||||||
// using typemaps
|
// using typemaps
|
||||||
%include <typemaps.i>
|
%include <typemaps.i>
|
||||||
%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
|
extern void sort_double(double* arr, int len); // the function to wrap
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -1650,16 +1649,16 @@ ARRAY_SIZE=10
|
||||||
|
|
||||||
-- passing a C array to the sort_int()
|
-- passing a C array to the sort_int()
|
||||||
arr=example.new_int(ARRAY_SIZE) -- create the array
|
arr=example.new_int(ARRAY_SIZE) -- create the array
|
||||||
for i=0,ARRAY_SIZE-1 do -- index 0..9 (just like C)
|
for i=0, ARRAY_SIZE-1 do -- index 0..9 (just like C)
|
||||||
example.int_setitem(arr,i,math.random(1000))
|
example.int_setitem(arr, i, math.random(1000))
|
||||||
end
|
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
|
example.delete_int(arr) -- must delete the allocated memory
|
||||||
|
|
||||||
-- use a typemap to call with a Lua-table
|
-- use a typemap to call with a Lua-table
|
||||||
-- one item of note: the typemap creates a copy, rather than edit-in-place
|
-- one item of note: the typemap creates a copy, rather than edit-in-place
|
||||||
t={} -- a Lua table
|
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
|
t[i]=math.random(1000)/10
|
||||||
end
|
end
|
||||||
t=example.sort_double(t) -- replace t with the result
|
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>
|
<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
|
ptr=nil -- the iMath* will be GC'ed as normal
|
||||||
</pre></div>
|
</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>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">
|
<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.
|
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>
|
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>
|
</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">
|
<div class="indent">
|
||||||
This is the opposite of SWIG_ConvertPtr, as it pushes a new userdata which wrappers the pointer 'ptr' of type 'type'.
|
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.
|
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>
|
</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">
|
<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.
|
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>
|
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>
|
A common use for this code is:<br><pre>
|
||||||
if (!SWIG_IsOK(SWIG_ConvertPtr( .....)){
|
if (!SWIG_IsOK(SWIG_ConvertPtr( .....)){
|
||||||
lua_pushstring(L,"something bad happened");
|
lua_pushstring(L, "something bad happened");
|
||||||
SWIG_fail;
|
SWIG_fail;
|
||||||
}</pre></div>
|
}</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">
|
<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
|
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>'"
|
"Error in <i>func_name</i> (arg <i>argnum</i>), expected '<i>type</i>' got '<i>whatever the type was</i>'"
|
||||||
</pre></div>
|
</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">
|
<div class="indent">
|
||||||
Similar to SWIG_fail_arg, except that it will display the swig_type_info information instead.</div>
|
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
|
||||||
> print(example)
|
> print(example)
|
||||||
table: 003F8F90
|
table: 003F8F90
|
||||||
> m=getmetatable(example)
|
> m=getmetatable(example)
|
||||||
> table.foreach(m,print)
|
> table.foreach(m, print)
|
||||||
.set table: 003F9088
|
.set table: 003F9088
|
||||||
.get table: 003F9038
|
.get table: 003F9038
|
||||||
__index function: 003F8FE0
|
__index function: 003F8FE0
|
||||||
__newindex function: 003F8FF8
|
__newindex function: 003F8FF8
|
||||||
> g=m['.get']
|
> g=m['.get']
|
||||||
> table.foreach(g,print)
|
> table.foreach(g, print)
|
||||||
Foo function: 003FAFD8
|
Foo function: 003FAFD8
|
||||||
>
|
>
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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>
|
||||||
<p>
|
<p>
|
||||||
The Lua equivalent of the code for the <tt>__index</tt> and <tt>__newindex</tt> looks a bit like this
|
The Lua equivalent of the code for the <tt>__index</tt> and <tt>__newindex</tt> looks a bit like this
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
function __index(mod,name)
|
function __index(mod, name)
|
||||||
local g=getmetatable(mod)['.get'] -- gets the table
|
local g=getmetatable(mod)['.get'] -- gets the table
|
||||||
if not g then return nil end
|
if not g then return nil end
|
||||||
local f=g[name] -- looks for the function
|
local f=g[name] -- looks for the function
|
||||||
|
|
@ -1903,13 +1902,13 @@ function __index(mod,name)
|
||||||
return nil
|
return nil
|
||||||
end
|
end
|
||||||
|
|
||||||
function __newindex(mod,name,value)
|
function __newindex(mod, name, value)
|
||||||
local s=getmetatable(mod)['.set'] -- gets the table
|
local s=getmetatable(mod)['.set'] -- gets the table
|
||||||
if not s then return end
|
if not s then return end
|
||||||
local f=s[name] -- looks for the function
|
local f=s[name] -- looks for the function
|
||||||
-- calls it to set the value
|
-- calls it to set the value
|
||||||
if type(f)=="function" then f(value)
|
if type(f)=="function" then f(value)
|
||||||
else rawset(mod,name,value) end
|
else rawset(mod, name, value) end
|
||||||
end
|
end
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1932,10 +1931,10 @@ Given a class
|
||||||
class Point
|
class Point
|
||||||
{
|
{
|
||||||
public:
|
public:
|
||||||
int x,y;
|
int x, y;
|
||||||
Point(){x=y=0;}
|
Point(){x=y=0;}
|
||||||
~Point(){}
|
~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>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1949,7 +1948,7 @@ Some of the internals can be seen by looking at the metatable of a class:
|
||||||
> print(p)
|
> print(p)
|
||||||
userdata: 003FDB28
|
userdata: 003FDB28
|
||||||
> m=getmetatable(p)
|
> m=getmetatable(p)
|
||||||
> table.foreach(m,print)
|
> table.foreach(m, print)
|
||||||
.type Point
|
.type Point
|
||||||
__gc function: 003FB6C8
|
__gc function: 003FB6C8
|
||||||
__newindex function: 003FB6B0
|
__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
|
The Lua equivalent of the code for enabling functions looks a little like this
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
function __index(obj,name)
|
function __index(obj, name)
|
||||||
local m=getmetatable(obj) -- gets the metatable
|
local m=getmetatable(obj) -- gets the metatable
|
||||||
if not m then return nil end
|
if not m then return nil end
|
||||||
local g=m['.get'] -- gets the attribute table
|
local g=m['.get'] -- gets the attribute table
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,12 @@
|
||||||
# Makefile for generating the SWIG documentation
|
# Makefile for generating the SWIG documentation
|
||||||
#
|
#
|
||||||
# Note that the htmldoc package needs to be installed, but requires patching (using the
|
# Note that the htmldoc package needs to be installed. wkhtmltopdf patched with qt is also required
|
||||||
# margin-left.patch file from this directory) in order to correctly generate the pdf docs.
|
# and can be installed from http://wkhtmltopdf.org/downloads.html.
|
||||||
|
#
|
||||||
# The .html files are first processed and updated with chapter numbering and anchor names
|
# 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
|
# 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
|
# HTML TIDY (package also known as tidy) is also required and is used as an aid to HTML
|
||||||
# validation.
|
# validation.
|
||||||
#
|
#
|
||||||
|
|
@ -87,3 +89,9 @@ linkchecker2:
|
||||||
cp *.png linkchecker-tmp
|
cp *.png linkchecker-tmp
|
||||||
(cd linkchecker-tmp && linkchecker --config=../linkchecker.config -F text --no-warnings SWIGDocumentation.html)
|
(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"
|
||||||
|
|
|
||||||
|
|
@ -6,7 +6,7 @@
|
||||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||||
</head>
|
</head>
|
||||||
<body bgcolor="#FFFFFF">
|
<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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -55,7 +55,7 @@ especially
|
||||||
<a href="Typemaps.html#Typemaps">typemaps</a>.
|
<a href="Typemaps.html#Typemaps">typemaps</a>.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Modula3_modula3_overview">29.1 Overview</a></H2>
|
<H2><a name="Modula3_modula3_overview">31.1 Overview</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -85,7 +85,7 @@ FFTW
|
||||||
</li>
|
</li>
|
||||||
</ol>
|
</ol>
|
||||||
|
|
||||||
<H3><a name="Modula3_motivation">29.1.1 Motivation</a></H3>
|
<H3><a name="Modula3_motivation">31.1.1 Motivation</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -132,10 +132,10 @@ functions), but it doesn't allow you to easily integrate a Modula-3 module into
|
||||||
a C/C++ project.
|
a C/C++ project.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -284,7 +284,7 @@ and the principal type must be renamed (<tt>%typemap</tt>).
|
||||||
</p>
|
</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>
|
<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.
|
so I'm not sure if this is possible or sensible, yet.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -401,7 +401,7 @@ For testing examples I use Critical Mass cm3.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -478,10 +478,10 @@ Instead generate templates for some basic typemaps.
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</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>
|
<p>
|
||||||
|
|
@ -684,7 +684,7 @@ consist of the following parts:
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td>m3wrapfreearg</td>
|
<td>m3wrapfreearg</td>
|
||||||
<td><tt>M3toC.FreeSharedS(str,arg1);</tt></td>
|
<td><tt>M3toC.FreeSharedS(str, arg1);</tt></td>
|
||||||
<td>
|
<td>
|
||||||
Free resources that were temporarily used in the wrapper.
|
Free resources that were temporarily used in the wrapper.
|
||||||
Since this step should never be skipped,
|
Since this step should never be skipped,
|
||||||
|
|
@ -695,7 +695,7 @@ consist of the following parts:
|
||||||
</table>
|
</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>
|
<p>
|
||||||
|
|
@ -747,7 +747,7 @@ that I'd like to automate.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
||||||
<H3><a name="Modula3_class">29.4.3 Objects</a></H3>
|
<H3><a name="Modula3_class">31.4.3 Objects</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -760,7 +760,7 @@ is not really useful, yet.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
||||||
<H3><a name="Modula3_imports">29.4.4 Imports</a></H3>
|
<H3><a name="Modula3_imports">31.4.4 Imports</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -793,7 +793,7 @@ IMPORT M3toC;
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -817,7 +817,7 @@ you should declare
|
||||||
<tt>%typemap("m3wrapinconv:throws") blah * %{OSError.E%}</tt>.
|
<tt>%typemap("m3wrapinconv:throws") blah * %{OSError.E%}</tt>.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -858,16 +858,16 @@ where almost everything is generated by a typemap:
|
||||||
RAISE E("invalid checksum");
|
RAISE E("invalid checksum");
|
||||||
END;
|
END;
|
||||||
FINALLY
|
FINALLY
|
||||||
M3toC.FreeSharedS(str,arg1); <I>(* m3wrapfreearg *)</I>
|
M3toC.FreeSharedS(str, arg1); <I>(* m3wrapfreearg *)</I>
|
||||||
END;
|
END;
|
||||||
END Name;
|
END Name;
|
||||||
</pre></div>
|
</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">
|
<table border summary="Modula-3 features">
|
||||||
|
|
@ -891,7 +891,7 @@ where almost everything is generated by a typemap:
|
||||||
<tr>
|
<tr>
|
||||||
<td>constnumeric</td>
|
<td>constnumeric</td>
|
||||||
<td><tt>%constnumeric(12) twelve;</tt> or
|
<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
|
<td>This feature can be used to tell Modula-3's back-end of SWIG
|
||||||
the value of an identifier.
|
the value of an identifier.
|
||||||
This is necessary in the cases
|
This is necessary in the cases
|
||||||
|
|
@ -904,7 +904,7 @@ where almost everything is generated by a typemap:
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</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">
|
<table border summary="Modula-3 pragmas">
|
||||||
|
|
@ -927,7 +927,7 @@ where almost everything is generated by a typemap:
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
<H2><a name="Modula3_remarks">29.6 Remarks</a></H2>
|
<H2><a name="Modula3_remarks">31.6 Remarks</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Modules">16 Working with Modules</a></H1>
|
<H1><a name="Modules">19 Working with Modules</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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>
|
<p>
|
||||||
|
|
@ -44,7 +44,7 @@ The general form of this directive is:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
<tt>%module(option1="value1",option2="value2",...) modulename</tt>
|
<tt>%module(option1="value1", option2="value2", ...) modulename</tt>
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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.
|
Each module in the collection is created via separate invocations of SWIG.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Modules_nn1">16.2 Basics</a></H2>
|
<H2><a name="Modules_nn1">19.2 Basics</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -177,7 +177,7 @@ in parallel from multiple threads as SWIG provides no locking - for more on that
|
||||||
issue, read on.
|
issue, read on.
|
||||||
</p>
|
</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>
|
<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.
|
is empty. Only modules compiled with the same pair will share type information.
|
||||||
</p>
|
</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>,
|
<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.
|
access.
|
||||||
</p>
|
</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>
|
<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.
|
behavior. When working with dynamically loadable modules, you should try to work exclusively with shared libraries.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Modules_nn5">16.6 References</a></H2>
|
<H2><a name="Modules_nn5">19.6 References</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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.
|
an outside reference. John Levine's "Linkers and Loaders" is highly recommended.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<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 -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -24,7 +24,7 @@
|
||||||
<p>
|
<p>
|
||||||
This section contains information on SWIG's support of Racket, formally known as MzScheme.
|
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>
|
<p>
|
||||||
|
|
@ -34,14 +34,14 @@ Example interface file:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
/* define a macro for the struct creation */
|
/* define a macro for the struct creation */
|
||||||
%define handle_ptr(TYPE,NAME)
|
%define handle_ptr(TYPE, NAME)
|
||||||
%typemap(argout) TYPE *NAME{
|
%typemap(argout) TYPE *NAME{
|
||||||
Scheme_Object *o = SWIG_NewStructFromPtr($1, $*1_mangle);
|
Scheme_Object *o = SWIG_NewStructFromPtr($1, $*1_mangle);
|
||||||
SWIG_APPEND_VALUE(o);
|
SWIG_APPEND_VALUE(o);
|
||||||
}
|
}
|
||||||
|
|
||||||
%typemap(in,numinputs=0) TYPE *NAME (TYPE temp) {
|
%typemap(in, numinputs=0) TYPE *NAME (TYPE temp) {
|
||||||
$1 = &temp;
|
$1 = &temp;
|
||||||
}
|
}
|
||||||
%enddef
|
%enddef
|
||||||
|
|
||||||
|
|
@ -65,7 +65,7 @@ Then in scheme, you can use regular struct access procedures like
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H2><a name="MzScheme_simple">30.2 Simple example</a></H2>
|
<H2><a name="MzScheme_simple">37.2 Simple example</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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.
|
<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>
|
</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>
|
<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>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Ocaml">31 SWIG and Ocaml</a></H1>
|
<H1><a name="Ocaml">38 SWIG and OCaml</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -47,12 +47,16 @@
|
||||||
<li><a href="#Ocaml_nn25">Director Usage Example</a>
|
<li><a href="#Ocaml_nn25">Director Usage Example</a>
|
||||||
<li><a href="#Ocaml_nn26">Creating director objects</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_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_nn29">directorout typemap</a>
|
||||||
<li><a href="#Ocaml_nn30">directorargout typemap</a>
|
<li><a href="#Ocaml_nn30">directorargout typemap</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Ocaml_nn31">Exceptions</a>
|
<li><a href="#Ocaml_nn31">Exceptions</a>
|
||||||
</ul>
|
</ul>
|
||||||
|
<li><a href="#Ocaml_nn32">Documentation Features</a>
|
||||||
|
<ul>
|
||||||
|
<li><a href="#Ocaml_nn33">Module docstring</a>
|
||||||
|
</ul>
|
||||||
</ul>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
<!-- INDEX -->
|
<!-- 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>.
|
<a href="http://ocaml.org/">The Ocaml Website</a>.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Ocaml_nn2">31.1 Preliminaries</a></H2>
|
<H2><a name="Ocaml_nn2">38.1 Preliminaries</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
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
|
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
|
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.
|
<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.
|
will be loaded dynamically. This has only been tested on Linux so far.
|
||||||
</p>
|
</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>
|
<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
|
the resulting .ml and .mli files as well, and do the final link with -custom
|
||||||
(not needed for native link).</p>
|
(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>
|
<p>
|
||||||
|
|
@ -142,7 +146,7 @@ Use <tt>ocamlc</tt> or <tt>ocamlopt</tt> to compile your SWIG interface like:
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<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 swig.mli ; ocamlc -c swig.ml
|
||||||
% ocamlc -c -ccopt "-I/usr/include/foo" example_wrap.c
|
% ocamlc -c -ccopt "-I/usr/include/foo" example_wrap.c
|
||||||
% ocamlc -c example.mli
|
% ocamlc -c example.mli
|
||||||
|
|
@ -162,7 +166,7 @@ in C++ mode, you must:</p>
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -238,7 +242,7 @@ let b = C_string (getenv "PATH")
|
||||||
</td></tr>
|
</td></tr>
|
||||||
</table>
|
</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>
|
<p>
|
||||||
|
|
@ -252,7 +256,7 @@ option to build your functions into the primitive list. This
|
||||||
option is not needed when you build native code.
|
option is not needed when you build native code.
|
||||||
</p>
|
</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>
|
<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.
|
Most code meant to be compiled as C++ will not have problems.
|
||||||
</p>
|
</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>
|
<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
|
Because of this style, a typemap can return any kind of value it
|
||||||
wants from a function. This enables out typemaps and inout typemaps
|
wants from a function. This enables out typemaps and inout typemaps
|
||||||
to work well. The one thing to remember about outputting values
|
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>
|
||||||
|
|
||||||
<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
|
beautifies the result. A list containing a single item degrades to
|
||||||
only that item (i.e. [ C_int 3 ] -> C_int 3), and a list
|
only that item (i.e. [ C_int 3 ] -> C_int 3), and a list
|
||||||
containing more than one item is wrapped in C_list (i.e. [ C_char
|
containing more than one item is wrapped in C_list (i.e. [ C_char
|
||||||
'a' ; C_char 'b' -> C_list [ C_char 'a' ; C_char b
|
'a' ; C_char 'b' ] -> C_list [ C_char 'a' ; C_char 'b'
|
||||||
]). This is in order to make return values easier to handle
|
]). This is in order to make return values easier to handle
|
||||||
when functions have only one return value, such as constructors,
|
when functions have only one return value, such as constructors,
|
||||||
and operators. In addition, string, pointer, and object
|
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.
|
signature for a function that uses value in this way.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -397,7 +401,7 @@ it describes the output SWIG will generate for class definitions.
|
||||||
</td></tr>
|
</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
<H3><a name="Ocaml_nn10">31.2.2 Enums</a></H3>
|
<H3><a name="Ocaml_nn10">38.2.2 Enums</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -460,7 +464,7 @@ val x : Enum_test.c_obj = C_enum `a
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<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.
|
values using the swig_val function before sharing them with another module.
|
||||||
</p>
|
</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>
|
<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.
|
for arrays whose bounds are completely specified.
|
||||||
</p>
|
</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>
|
<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
|
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
|
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
|
(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,
|
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.
|
so you have to specify it for yourself in the form of a typemap.
|
||||||
</p>
|
</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>
|
<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.
|
such as using a required sentinel, etc.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -560,7 +564,7 @@ void printfloats( float *tab, int len ) {
|
||||||
$2 = caml_array_len($input);
|
$2 = caml_array_len($input);
|
||||||
$1 = ($*1_type *)malloc( $2 * sizeof( float ) );
|
$1 = ($*1_type *)malloc( $2 * sizeof( float ) );
|
||||||
for( i = 0; i < $2; i++ ) {
|
for( i = 0; i < $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>
|
</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>
|
<p>
|
||||||
|
|
@ -618,7 +622,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the
|
||||||
returned value for the same object.
|
returned value for the same object.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -660,7 +664,7 @@ module.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
bash-2.05a$ ./example_top
|
bash-2.05a$ ./runme_top
|
||||||
Objective Caml version 3.06
|
Objective Caml version 3.06
|
||||||
|
|
||||||
Camlp4 Parsing version 3.06
|
Camlp4 Parsing version 3.06
|
||||||
|
|
@ -684,7 +688,7 @@ C_list
|
||||||
- : Example.c_obj = C_void
|
- : Example.c_obj = C_void
|
||||||
# x '[1] ;;
|
# x '[1] ;;
|
||||||
- : Example.c_obj = C_string "bar"
|
- : Example.c_obj = C_string "bar"
|
||||||
# x -> set (1,"spam") ;;
|
# x -> set (1, "spam") ;;
|
||||||
- : Example.c_obj = C_void
|
- : Example.c_obj = C_void
|
||||||
# x '[1] ;;
|
# x '[1] ;;
|
||||||
- : Example.c_obj = C_string "spam"
|
- : Example.c_obj = C_string "spam"
|
||||||
|
|
@ -698,7 +702,7 @@ baz
|
||||||
#
|
#
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -728,7 +732,7 @@ public:
|
||||||
};
|
};
|
||||||
</pre></td></tr></table>
|
</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>
|
<div class="code"><pre>
|
||||||
|
|
@ -746,7 +750,7 @@ bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
|
||||||
-L$QTPATH/lib -cclib -lqt
|
-L$QTPATH/lib -cclib -lqt
|
||||||
</pre></div>
|
</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>
|
<div class="code"><pre>
|
||||||
|
|
@ -757,11 +761,11 @@ bash-2.05a$ ./qt_top
|
||||||
|
|
||||||
# open Swig ;;
|
# open Swig ;;
|
||||||
# open Qt ;;
|
# open Qt ;;
|
||||||
# let a = new_QApplication '(0,0) ;;
|
# let a = new_QApplication '(0, 0) ;;
|
||||||
val a : Qt.c_obj = C_obj <fun>
|
val a : Qt.c_obj = C_obj <fun>
|
||||||
# let hello = new_QPushButton '("hi",0) ;;
|
# let hello = new_QPushButton '("hi", 0) ;;
|
||||||
val hello : Qt.c_obj = C_obj <fun>
|
val hello : Qt.c_obj = C_obj <fun>
|
||||||
# hello -> resize (100,30) ;;
|
# hello -> resize (100, 30) ;;
|
||||||
- : Qt.c_obj = C_void
|
- : Qt.c_obj = C_void
|
||||||
# hello -> show () ;;
|
# hello -> show () ;;
|
||||||
- : Qt.c_obj = C_void
|
- : 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.
|
containing the string "hi" in a button.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -803,7 +807,7 @@ class foo {
|
||||||
};
|
};
|
||||||
</pre></div>
|
</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>
|
<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.
|
an overloaded class. This example is contained in Examples/ocaml/shapes.
|
||||||
</p>
|
</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">
|
<table border="1" bgcolor="#dddddd" summary="Director usage example">
|
||||||
<tr><th><center>example_prog.ml</center>
|
<tr><th><center>runme.ml</center>
|
||||||
</th></tr>
|
</th></tr>
|
||||||
<tr><td><pre>
|
<tr><td><pre>
|
||||||
open Swig
|
open Swig
|
||||||
|
|
@ -854,13 +858,15 @@ let triangle_class pts ob meth args =
|
||||||
| _ -> raise (Failure "cover needs two double arguments."))
|
| _ -> raise (Failure "cover needs two double arguments."))
|
||||||
| _ -> (invoke ob) meth args ;;
|
| _ -> (invoke ob) meth args ;;
|
||||||
|
|
||||||
|
...
|
||||||
|
|
||||||
let triangle =
|
let triangle =
|
||||||
new_derived_object
|
new_derived_object
|
||||||
new_shape
|
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>
|
</pre></td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
|
|
@ -890,7 +896,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the
|
||||||
program in C++.
|
program in C++.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -901,7 +907,7 @@ The definition of the actual object triangle can be described this way:
|
||||||
let triangle =
|
let triangle =
|
||||||
new_derived_object
|
new_derived_object
|
||||||
new_shape
|
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>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -931,7 +937,7 @@ object from causing a core dump, as long as the object is destroyed
|
||||||
properly.
|
properly.
|
||||||
</p>
|
</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>
|
<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.
|
and to receive arguments the same way you normally receive function returns.
|
||||||
</p>
|
</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>
|
<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.
|
can use the same body as a simple <tt>out</tt> typemap.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -964,7 +970,7 @@ for the same type, except when there are special requirements for object
|
||||||
ownership, etc.
|
ownership, etc.
|
||||||
</p>
|
</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>
|
<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.
|
values will read zero, and struct or object returns have undefined results.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Ocaml_nn31">31.2.6 Exceptions</a></H3>
|
<H3><a name="Ocaml_nn31">38.2.6 Exceptions</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Catching exceptions is now supported using SWIG's %exception feature. A simple
|
If an error occurs in a C or C++ function, you may want to convert that error into an OCaml
|
||||||
but not too useful example is provided by the throw_exception testcase in
|
exception. To do this, you can use the <tt>%exception</tt> directive. The <tt>%exception</tt>
|
||||||
Examples/test-suite. You can provide your own exceptions, too.
|
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>
|
||||||
|
|
||||||
|
<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 &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>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
|
|
|
||||||
|
|
@ -9,7 +9,7 @@
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
|
|
||||||
<H1><a name="Octave">32 SWIG and Octave</a></H1>
|
<H1><a name="Octave">29 SWIG and Octave</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -56,20 +56,27 @@ More information can be found at <a href="http://www.gnu.org/software/octave/">O
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<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).
|
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>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Octave_nn2">32.1 Preliminaries</a></H2>
|
<H2><a name="Octave_nn2">29.1 Preliminaries</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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.
|
SWIG is regularly tested against the following versions of Octave: 3.8, 4.0, 4.2.
|
||||||
Use of older Octave versions is not recommended, as these versions are no longer tested with SWIG.
|
</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.
|
The SWIG runtime exports the function <tt>swig_octave_prereq()</tt> for checking the version of Octave.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Octave_nn3">32.2 Running SWIG</a></H2>
|
<H2><a name="Octave_nn3">29.2 Running SWIG</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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.
|
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>
|
</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>
|
<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.
|
The <em>-opprefix</em> options sets the prefix of the names of global/friend <a href="#Octave_nn18">operator</a> functions.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -151,7 +158,7 @@ $ mkoctfile example_wrap.cpp example.c
|
||||||
|
|
||||||
<div class="targetlang"><pre>octave:1> swigexample</pre></div>
|
<div class="targetlang"><pre>octave:1> 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>
|
<p>
|
||||||
|
|
@ -161,7 +168,7 @@ Assuming all goes well, you will be able to do this:
|
||||||
|
|
||||||
<div class="targetlang"><pre>$ octave -q
|
<div class="targetlang"><pre>$ octave -q
|
||||||
octave:1> swigexample
|
octave:1> swigexample
|
||||||
octave:2> swigexample.gcd(4,6)
|
octave:2> swigexample.gcd(4, 6)
|
||||||
ans = 2
|
ans = 2
|
||||||
octave:3> swigexample.cvar.Foo
|
octave:3> swigexample.cvar.Foo
|
||||||
ans = 3
|
ans = 3
|
||||||
|
|
@ -169,10 +176,10 @@ octave:4> swigexample.cvar.Foo=4;
|
||||||
octave:5> swigexample.cvar.Foo
|
octave:5> swigexample.cvar.Foo
|
||||||
ans = 4 </pre></div>
|
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>
|
<p>
|
||||||
|
|
@ -189,7 +196,7 @@ To load an Octave module, simply type its name:
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
octave:1> swigexample;
|
octave:1> swigexample;
|
||||||
octave:2> gcd(4,6)
|
octave:2> gcd(4, 6)
|
||||||
ans = 2
|
ans = 2
|
||||||
octave:3> cvar.Foo
|
octave:3> cvar.Foo
|
||||||
ans = 3
|
ans = 3
|
||||||
|
|
@ -204,20 +211,20 @@ If the module is also used in the base context, however, it must first be loaded
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
octave:1> function l = my_lcm(a,b)
|
octave:1> function l = my_lcm(a, b)
|
||||||
> swigexample
|
> swigexample
|
||||||
> l = abs(a*b)/swigexample.gcd(a,b);
|
> l = abs(a*b)/swigexample.gcd(a, b);
|
||||||
> endfunction
|
> endfunction
|
||||||
octave:2> my_lcm(4,6)
|
octave:2> my_lcm(4, 6)
|
||||||
ans = 12
|
ans = 12
|
||||||
octave:3> swigexample.gcd(4,6)
|
octave:3> swigexample.gcd(4, 6)
|
||||||
error: can't perform indexing operations for <unknown type> type
|
error: can't perform indexing operations for <unknown type> type
|
||||||
octave:3> swigexample;
|
octave:3> swigexample;
|
||||||
octave:4> swigexample.gcd(4,6)
|
octave:4> swigexample.gcd(4, 6)
|
||||||
ans = 2
|
ans = 2
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -234,7 +241,7 @@ int fact(int n); </pre></div>
|
||||||
<div class="targetlang"><pre>octave:1> swigexample.fact(4)
|
<div class="targetlang"><pre>octave:1> swigexample.fact(4)
|
||||||
24 </pre></div>
|
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>
|
<p>
|
||||||
|
|
@ -287,7 +294,7 @@ octave:2> swigexample.PI=3.142;
|
||||||
octave:3> swigexample.PI
|
octave:3> swigexample.PI
|
||||||
ans = 3.1420 </pre></div>
|
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>
|
<p>
|
||||||
|
|
@ -297,7 +304,7 @@ ans = 3.1420 </pre></div>
|
||||||
<div class="code"><pre>%module swigexample
|
<div class="code"><pre>%module swigexample
|
||||||
%constant int ICONST=42;
|
%constant int ICONST=42;
|
||||||
#define SCONST "Hello World"
|
#define SCONST "Hello World"
|
||||||
enum Days{SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY};
|
enum Days{SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -309,12 +316,12 @@ swigexample.SCONST="Hello World"
|
||||||
swigexample.SUNDAY=0
|
swigexample.SUNDAY=0
|
||||||
.... </pre></div>
|
.... </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>
|
<p>
|
||||||
C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the <file.h> interface:
|
C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the <file.h> interface:
|
||||||
C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the <file.h> interface:
|
C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the <file.h> interface:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>%module swigexample
|
<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>
|
<div class="targetlang"><pre>
|
||||||
octave:1> swigexample;
|
octave:1> swigexample;
|
||||||
octave:2> f=swigexample.fopen("w","junk");
|
octave:2> f=swigexample.fopen("w", "junk");
|
||||||
octave:3> swigexample.fputs("Hello world",f);
|
octave:3> swigexample.fputs("Hello world", f);
|
||||||
octave:4> swigexample.fclose(f);
|
octave:4> swigexample.fclose(f);
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -339,7 +346,7 @@ octave:4> swigexample.fclose(f);
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>octave:1> swigexample;
|
<div class="targetlang"><pre>octave:1> swigexample;
|
||||||
octave:2> f=swigexample.fopen("junk","w");
|
octave:2> f=swigexample.fopen("junk", "w");
|
||||||
octave:3> f
|
octave:3> f
|
||||||
f =
|
f =
|
||||||
|
|
||||||
|
|
@ -352,11 +359,11 @@ f =
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>octave:1> swigexample;
|
<div class="targetlang"><pre>octave:1> swigexample;
|
||||||
octave:2> f=swigexample.fopen("not there","r");
|
octave:2> f=swigexample.fopen("not there", "r");
|
||||||
error: value on right hand side of assignment is undefined
|
error: value on right hand side of assignment is undefined
|
||||||
error: evaluating assignment expression near line 2, column 2 </pre></div>
|
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>
|
<p>
|
||||||
|
|
@ -365,7 +372,7 @@ For each wrapped structure and class, a <tt>swig_ref</tt> will be exposed that h
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>struct Point{
|
<div class="code"><pre>struct Point{
|
||||||
int x,y;
|
int x, y;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</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{
|
<div class="code"><pre>class Point{
|
||||||
public:
|
public:
|
||||||
int x,y;
|
int x, y;
|
||||||
Point(int _x,int _y) : x(_x),y(_y) {}
|
Point(int _x, int _y) : x(_x), y(_y) {}
|
||||||
double distance(const Point& rhs) {
|
double distance(const Point& 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;
|
x=_x; y=_y;
|
||||||
}
|
}
|
||||||
};
|
};
|
||||||
|
|
@ -410,8 +417,8 @@ can be used from Octave like this
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>octave:1> swigexample;
|
<pre>octave:1> swigexample;
|
||||||
octave:2> p1=swigexample.Point(3,5);
|
octave:2> p1=swigexample.Point(3, 5);
|
||||||
octave:3> p2=swigexample.Point(1,2);
|
octave:3> p2=swigexample.Point(1, 2);
|
||||||
octave:4> p1.distance(p2)
|
octave:4> p1.distance(p2)
|
||||||
ans = 3.6056
|
ans = 3.6056
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -433,7 +440,7 @@ This differs from the usual pass-by-value (copy-on-write) semantics that Octave
|
||||||
|
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
octave:7> a=struct('x',4)
|
octave:7> a=struct('x', 4)
|
||||||
a =
|
a =
|
||||||
{
|
{
|
||||||
x = 4
|
x = 4
|
||||||
|
|
@ -464,7 +471,7 @@ However, when dealing with wrapped objects, one gets the behavior
|
||||||
|
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
octave:2> a=Point(3,5)
|
octave:2> a=Point(3, 5)
|
||||||
a =
|
a =
|
||||||
|
|
||||||
{
|
{
|
||||||
|
|
@ -478,7 +485,7 @@ b =
|
||||||
Point, ptr = 0x9afbbb0
|
Point, ptr = 0x9afbbb0
|
||||||
}
|
}
|
||||||
|
|
||||||
octave:4> b.set(2,1);
|
octave:4> b.set(2, 1);
|
||||||
octave:5> b.x, b.y
|
octave:5> b.x, b.y
|
||||||
ans = 2
|
ans = 2
|
||||||
ans = 1
|
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.
|
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>
|
</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>
|
<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>.
|
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>
|
</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>
|
<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.
|
<tt>typecheck</tt> typemaps are used to analyze each argument, as well as assign precedence. See the chapter on typemaps for details.
|
||||||
</p>
|
</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>
|
<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.
|
Octave can also utilise friend (i.e. non-member) operators with a simple %rename: see the example in the Examples/octave/operator directory.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
The %extend directive works the same as in other modules.
|
The %extend directive works the same as in other modules.
|
||||||
</p>
|
</p>
|
||||||
<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>
|
</p>
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
%extend A {
|
%extend A {
|
||||||
|
|
@ -639,7 +646,7 @@ Then in Octave one gets,
|
||||||
octave:1> a=A(4);
|
octave:1> a=A(4);
|
||||||
octave:2> a
|
octave:2> a
|
||||||
a = 4
|
a = 4
|
||||||
octave:3> printf("%s\n",a);
|
octave:3> printf("%s\n", a);
|
||||||
4
|
4
|
||||||
octave:4> a.__str__()
|
octave:4> a.__str__()
|
||||||
4
|
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()
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -663,10 +670,10 @@ For example, function templates can be instantiated as follows:
|
||||||
|
|
||||||
<div class="code"><pre>%module swigexample
|
<div class="code"><pre>%module swigexample
|
||||||
%inline {
|
%inline {
|
||||||
template<class __scalar>
|
template<class __scalar>
|
||||||
__scalar mul(__scalar a,__scalar b) {
|
__scalar mul(__scalar a, __scalar b) {
|
||||||
return a*b;
|
return a*b;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
%include <std_complex.i>
|
%include <std_complex.i>
|
||||||
%template(mul) mul<std::complex<double> >
|
%template(mul) mul<std::complex<double> >
|
||||||
|
|
@ -677,11 +684,11 @@ and then used from Octave
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
octave:1> mul(4,3)
|
octave:1> mul(4, 3)
|
||||||
ans = 12
|
ans = 12
|
||||||
octave:2> mul(4.2,3.6)
|
octave:2> mul(4.2, 3.6)
|
||||||
ans = 15.120
|
ans = 15.120
|
||||||
octave:3> mul(3+4i,10+2i)
|
octave:3> mul(3+4i, 10+2i)
|
||||||
ans = 22 + 46i
|
ans = 22 + 46i
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -722,18 +729,18 @@ octave:2> a=sum_complex(2+3i);
|
||||||
octave:3> a.add(2)
|
octave:3> a.add(2)
|
||||||
ans =
|
ans =
|
||||||
|
|
||||||
(4,3)
|
(4, 3)
|
||||||
octave:4> a.add(3+i)
|
octave:4> a.add(3+i)
|
||||||
ans =
|
ans =
|
||||||
|
|
||||||
(7,4)
|
(7, 4)
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -744,14 +751,14 @@ in the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a
|
||||||
</p>
|
</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>
|
<p>
|
||||||
C++ smart pointers are fully supported as in other modules.
|
C++ smart pointers are fully supported as in other modules.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -766,7 +773,7 @@ For example,
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
octave:1> a=subclass();
|
octave:1> a=subclass();
|
||||||
octave:2> a.my_var = 4;
|
octave:2> a.my_var = 4;
|
||||||
octave:3> a.my_method = @(self) printf("my_var = ",self.my_var);
|
octave:3> a.my_method = @(self) printf("my_var = ", self.my_var);
|
||||||
octave:4> a.my_method();
|
octave:4> a.my_method();
|
||||||
my_var = 4
|
my_var = 4
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -790,7 +797,7 @@ void call_your_method(A& a) {
|
||||||
Then from Octave you can say:
|
Then from Octave you can say:
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
octave:1> B=@() subclass(A(),@my_method);
|
octave:1> B=@() subclass(A(), @my_method);
|
||||||
octave:2> function my_method(self)
|
octave:2> function my_method(self)
|
||||||
octave:3> printf("octave-side routine called\n");
|
octave:3> printf("octave-side routine called\n");
|
||||||
octave:4> end
|
octave:4> end
|
||||||
|
|
@ -801,7 +808,7 @@ octave-side routine called
|
||||||
or more concisely,
|
or more concisely,
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
octave:1> B=@() subclass(A(),'my_method',@(self) printf("octave-side routine called\n"));
|
octave:1> B=@() subclass(A(), 'my_method', @(self) printf("octave-side routine called\n"));
|
||||||
octave:2> call_your_method(B());
|
octave:2> call_your_method(B());
|
||||||
octave-side routine called
|
octave-side routine called
|
||||||
</pre></div>
|
</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).
|
Note that you have to enable directors via the %feature directive (see other modules for this).
|
||||||
</p>
|
</p>
|
||||||
<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>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
octave:1> B=@(some_var=2) subclass(A(),'some_var',some_var,@some_func,'another_func',
|
octave:1> B=@(some_var=2) subclass(A(), 'some_var', some_var, @some_func, 'another_func',
|
||||||
@(self) do_stuff())
|
@(self) do_stuff())
|
||||||
</pre></div>
|
</pre></div>
|
||||||
<p>
|
<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
|
There is limited support for explicitly referencing C++ bases. So, in the example above, we could have
|
||||||
</p>
|
</p>
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
octave:1> B=@() subclass(A(),@my_method);
|
octave:1> B=@() subclass(A(), @my_method);
|
||||||
octave:2> function my_method(self)
|
octave:2> function my_method(self)
|
||||||
octave:3> self.A.my_method();
|
octave:3> self.A.my_method();
|
||||||
octave:4> printf("octave-side routine called\n");
|
octave:4> printf("octave-side routine called\n");
|
||||||
|
|
@ -832,14 +839,14 @@ c-side routine called
|
||||||
octave-side routine called
|
octave-side routine called
|
||||||
</pre></div>
|
</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>
|
<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.
|
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>
|
</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>
|
<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).
|
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>
|
</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>
|
<p>
|
||||||
Various STL library files are provided for wrapping STL containers.
|
Various STL library files are provided for wrapping STL containers.
|
||||||
</p>
|
</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>
|
<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
|
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>
|
</p>
|
||||||
<div class="code"><pre>
|
<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>
|
</pre></div>
|
||||||
<p>
|
<p>
|
||||||
that is accessed from Octave as,
|
that is accessed from Octave as,
|
||||||
|
|
|
||||||
File diff suppressed because it is too large
Load diff
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Php">34 SWIG and PHP</a></H1>
|
<H1><a name="Php">31 SWIG and PHP</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -50,27 +50,17 @@
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
SWIG supports generating wrappers for PHP5. Support for PHP4 was removed
|
In this chapter, we discuss SWIG's support of PHP. SWIG currently supports
|
||||||
in SWIG 1.3.37. The PHP developers are no longer making new PHP4 releases,
|
generating wrappers for PHP7. Support for PHP5 was removed in SWIG 4.0.0
|
||||||
and won't even be patching critical security issues after 2008-08-08, so it
|
and support for PHP4 was removed in SWIG 1.3.37.
|
||||||
doesn't make much sense for SWIG to continue to support PHP4 now. If you
|
|
||||||
really need to continue to use PHP4, just stick with SWIG 1.3.36.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Currently any PHP5 release should work, but we don't regularly test with
|
Currently any PHP7 release should work.
|
||||||
PHP < 5.3.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
In this chapter, we discuss SWIG's support of PHP. The PHP module
|
In order to use this module, you will need to have a copy of the PHP
|
||||||
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
|
|
||||||
include files to compile the SWIG generated files. If you installed
|
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"
|
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
|
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.
|
available.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
To build a PHP extension, run swig using the <tt>-php</tt> option as
|
To build a PHP extension, run swig using the <tt>-php7</tt> option as follows
|
||||||
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>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
swig -php example.i
|
swig -php7 example.i
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -102,13 +93,16 @@ The third file,
|
||||||
<tt>example.php</tt> can be included by PHP scripts. It attempts to
|
<tt>example.php</tt> can be included by PHP scripts. It attempts to
|
||||||
dynamically load the extension and contains extra php code specified
|
dynamically load the extension and contains extra php code specified
|
||||||
in the interface file. If wrapping C++ code with PHP classes, it will
|
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>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
SWIG can generate PHP extensions from C++ libraries as well when
|
SWIG can generate PHP extensions from C++ libraries as well when
|
||||||
given the <tt>-c++</tt> option. The support for C++ is discussed in
|
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>
|
||||||
|
|
||||||
<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.
|
this approach, or provide explicit support for it.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -140,7 +134,7 @@ least work for Linux though):
|
||||||
gcc -shared example_wrap.o example.o -o example.so
|
gcc -shared example_wrap.o example.o -o example.so
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -159,8 +153,8 @@ If the module is in PHP's default extension directory, you can omit the path.
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
For some SAPIs (for example, the CLI SAPI) you can instead use the
|
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
|
<a href="https://www.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
|
an extension at run time, by adding a line like this to the start of each
|
||||||
PHP script which uses your extension:
|
PHP script which uses your extension:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -169,8 +163,8 @@ PHP script which uses your extension:
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
But note that this doesn't work when running PHP through a webserver in PHP5.3
|
But note that <tt>dl()</tt> isn't supported when running PHP through a
|
||||||
and later - you'll need to use <tt>extension</tt> in <tt>php.ini</tt> as
|
webserver - you'll need to use <tt>extension</tt> in <tt>php.ini</tt> as
|
||||||
described above.
|
described above.
|
||||||
</p>
|
</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.
|
almost certainly want to include it anyway.
|
||||||
</p>
|
</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>
|
<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
|
into which all symbols from extension modules are loaded. It is quite
|
||||||
possible for names of symbols in one extension module to clash with
|
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
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -236,10 +231,12 @@ echo "E = " . E . "\n";
|
||||||
<p>
|
<p>
|
||||||
There's one peculiarity of how constants work in PHP which it is useful
|
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
|
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
|
constant, PHP will emit a warning (or a notice in PHP 7.1 and earlier) and then
|
||||||
version of the constant's name. Unfortunately it is easy to miss the notice
|
expand the constant to a string version of the constant's name. Unfortunately
|
||||||
if you're using PHP in a webserver, as it will probably end up in error.log or
|
it is easy to miss the warning message if you're using PHP in a webserver as
|
||||||
similar.
|
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>
|
||||||
|
|
||||||
<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!
|
would be treated as false!
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -291,7 +288,7 @@ the use of automatically generated accessor functions.
|
||||||
%inline %{
|
%inline %{
|
||||||
double seki = 2;
|
double seki = 2;
|
||||||
void print_seki() {
|
void print_seki() {
|
||||||
zend_printf("seki is now %f\n",seki);
|
zend_printf("seki is now %f\n", seki);
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -325,7 +322,7 @@ undefined.
|
||||||
At this time SWIG does not support custom accessor methods.
|
At this time SWIG does not support custom accessor methods.
|
||||||
</p>
|
</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>
|
<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>
|
<p>
|
||||||
|
|
@ -386,8 +383,7 @@ Although PHP does not support overloading functions natively, swig
|
||||||
will generate dispatch functions which will use <tt>%typecheck</tt>
|
will generate dispatch functions which will use <tt>%typecheck</tt>
|
||||||
typemaps to allow overloading. This dispatch function's operation and
|
typemaps to allow overloading. This dispatch function's operation and
|
||||||
precedence is described in <a
|
precedence is described in <a
|
||||||
href="SWIGPlus.html#SWIGPlus_overloaded_methods">Wrapping
|
href="SWIGPlus.html#SWIGPlus_overloaded_methods">Overloaded functions and methods</a>.
|
||||||
Overloaded Functions and Methods</a>.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<!-- This isn't correct for 1.3.30 and needs rewriting to reflect reality
|
<!-- This isn't correct for 1.3.30 and needs rewriting to reflect reality
|
||||||
|
|
@ -434,7 +430,7 @@ taking the integer argument.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -459,7 +455,7 @@ One can include <b>cpointer.i</b> to generate PHP wrappers to <tt>int
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
%module example
|
%module example
|
||||||
%include "cpointer.i"
|
%include "cpointer.i"
|
||||||
%pointer_functions(int,intp)
|
%pointer_functions(int, intp)
|
||||||
|
|
||||||
void add( int *in1, int *in2, int *result);
|
void add( int *in1, int *in2, int *result);
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -509,7 +505,7 @@ include("example.php");
|
||||||
|
|
||||||
$in1 = 3;
|
$in1 = 3;
|
||||||
$in2 = 5;
|
$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";
|
echo "The sum $in1 + $in2 = $result\n";
|
||||||
?>
|
?>
|
||||||
|
|
@ -522,13 +518,6 @@ this, one needs to include <b>phppointers.i</b> which defines the
|
||||||
named typemap REF.
|
named typemap REF.
|
||||||
</p>
|
</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≥3.0 is
|
|
||||||
used to generate wrappers from your interface file.
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
In case you write your own typemaps, SWIG supports an attribute called
|
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
|
<tt>byref</tt>: if you set that, then SWIG will make sure that the generated
|
||||||
|
|
@ -555,7 +544,7 @@ include("example.php");
|
||||||
$in1 = 3;
|
$in1 = 3;
|
||||||
$in2 = 5;
|
$in2 = 5;
|
||||||
$result = 0;
|
$result = 0;
|
||||||
add($in1,$in2,$result);
|
add($in1, $in2, $result);
|
||||||
|
|
||||||
echo "The sum $in1 + $in2 = $result\n";
|
echo "The sum $in1 + $in2 = $result\n";
|
||||||
?>
|
?>
|
||||||
|
|
@ -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.
|
variable, or assigning <tt>NULL</tt> to a variable.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -599,7 +588,7 @@ This interface file
|
||||||
|
|
||||||
class Vector {
|
class Vector {
|
||||||
public:
|
public:
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
Vector();
|
Vector();
|
||||||
~Vector();
|
~Vector();
|
||||||
double magnitude();
|
double magnitude();
|
||||||
|
|
@ -611,7 +600,7 @@ struct Complex {
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Would be used in the following way from PHP5:
|
Would be used in the following way from PHP:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
|
|
@ -623,7 +612,7 @@ Would be used in the following way from PHP5:
|
||||||
$v->y = 4;
|
$v->y = 4;
|
||||||
$v->z = 5;
|
$v->z = 5;
|
||||||
|
|
||||||
echo "Magnitude of ($v->x,$v->y,$v->z) = " . $v->magnitude() . "\n";
|
echo "Magnitude of ($v->x, $v->y, $v->z) = " . $v->magnitude() . "\n";
|
||||||
|
|
||||||
$v = NULL; # destructor called.
|
$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>-></tt> operator.
|
Member variables and methods are accessed using the <tt>-></tt> operator.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
The <tt>-noproxy</tt> option flattens the object structure and
|
The <tt>-noproxy</tt> option flattens the object structure and
|
||||||
generates collections of named functions (these are the functions
|
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:
|
in the following PHP functions:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
new_Vector();
|
new_Vector();
|
||||||
Vector_x_set($obj,$d);
|
Vector_x_set($obj, $d);
|
||||||
Vector_x_get($obj);
|
Vector_x_get($obj);
|
||||||
Vector_y_set($obj,$d);
|
Vector_y_set($obj, $d);
|
||||||
Vector_y_get($obj);
|
Vector_y_get($obj);
|
||||||
Vector_z_set($obj,$d);
|
Vector_z_set($obj, $d);
|
||||||
Vector_z_get($obj);
|
Vector_z_get($obj);
|
||||||
Vector_magnitude($obj);
|
Vector_magnitude($obj);
|
||||||
new_Complex();
|
new_Complex();
|
||||||
Complex_re_set($obj,$d);
|
Complex_re_set($obj, $d);
|
||||||
Complex_re_get($obj);
|
Complex_re_get($obj);
|
||||||
Complex_im_set($obj,$d);
|
Complex_im_set($obj, $d);
|
||||||
Complex_im_get($obj);
|
Complex_im_get($obj);
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -707,7 +696,7 @@ the programmer can either reassign the variable or call
|
||||||
<tt>unset($v)</tt>
|
<tt>unset($v)</tt>
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -750,7 +739,7 @@ Ko::threats(10);
|
||||||
echo "There have now been " . Ko::threats() . " threats\n";
|
echo "There have now been " . Ko::threats() . " threats\n";
|
||||||
|
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -772,7 +761,7 @@ Ko::threats();
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -790,7 +779,7 @@ so:
|
||||||
If there are multiple interfaces, just list them separated by commas.
|
If there are multiple interfaces, just list them separated by commas.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -816,6 +805,15 @@ Results in the following in "example.php"
|
||||||
echo "example.php execution\n";
|
echo "example.php execution\n";
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
The <b>include</b> pragma is a short cut to add include statements to
|
The <b>include</b> pragma is a short cut to add include statements to
|
||||||
the example.php file.
|
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.
|
into the request init (PHP_RINIT_FUNCTION) and request shutdown (PHP_RSHUTDOWN_FUNCTION) code respectively.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -913,7 +911,7 @@ wrapper functions takes care of all the cross-language method routing
|
||||||
transparently.
|
transparently.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -940,7 +938,7 @@ globally, to specific classes, and to specific methods, like this:
|
||||||
// generate directors for all classes that have virtual methods
|
// generate directors for all classes that have virtual methods
|
||||||
%feature("director");
|
%feature("director");
|
||||||
|
|
||||||
// generate directors for all virtual methods in class Foo
|
// generate directors for the virtual methods in class Foo
|
||||||
%feature("director") Foo;
|
%feature("director") Foo;
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -958,7 +956,7 @@ directors for specific classes or methods. So for example,
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
will generate directors for all virtual methods of class Foo except
|
will generate directors for the virtual methods of class Foo except
|
||||||
bar().
|
bar().
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -973,14 +971,14 @@ the methods one() and two() (but not three()):
|
||||||
%feature("director") Foo;
|
%feature("director") Foo;
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
Foo(int foo);
|
Foo(int foo);
|
||||||
virtual void one();
|
virtual void one();
|
||||||
virtual void two();
|
virtual void two();
|
||||||
};
|
};
|
||||||
|
|
||||||
class Bar: public Foo {
|
class Bar: public Foo {
|
||||||
public:
|
public:
|
||||||
virtual void three();
|
virtual void three();
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -995,14 +993,14 @@ require("mymodule.php");
|
||||||
|
|
||||||
class MyFoo extends Foo {
|
class MyFoo extends Foo {
|
||||||
function one() {
|
function one() {
|
||||||
print "one from php\n";
|
print "one from php\n";
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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
|
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 extends all virtual methods in the inheritance chain of its base
|
||||||
class (see the preceding section for how to modify this behavior).
|
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
|
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
|
director class. The job of the director methods is to route these method
|
||||||
calls to the appropriate place in the inheritance chain. By "appropriate
|
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.
|
calls through PHP.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1112,12 +1111,12 @@ Here is an example:
|
||||||
<pre>
|
<pre>
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
class FooContainer {
|
class FooContainer {
|
||||||
public:
|
public:
|
||||||
void addFoo(Foo *);
|
void addFoo(Foo *);
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
deleting all the Foo pointers it contains at some point.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
With directors routing method calls to PHP, and proxies routing them
|
With directors routing method calls to PHP, and proxies routing them
|
||||||
to C++, the handling of exceptions is an important concern. By default, the
|
to C++, the handling of exceptions is an important concern. By default, an
|
||||||
directors ignore exceptions that occur during method calls that are
|
exception thrown in PHP code called from C++ causes the PHP interpreter
|
||||||
resolved in PHP. To handle such exceptions correctly, it is necessary
|
to flag that an exception is thrown, then return passes to C++ as if
|
||||||
to temporarily translate them into C++ exceptions. This can be done with
|
the PHP function had returned <code>Null</code>. Assuming the directorout
|
||||||
the %feature("director:except") directive. The following code should
|
typemaps handle this (those SWIG defines by default should) then once
|
||||||
suffice in most cases:
|
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>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%feature("director:except") {
|
%feature("director:except") {
|
||||||
if ($error == FAILURE) {
|
if ($error == FAILURE) {
|
||||||
throw Swig::DirectorMethodException();
|
throw Swig::DirectorMethodException();
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1183,8 +1190,8 @@ suitable exception handler:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%exception {
|
%exception {
|
||||||
try { $action }
|
try { $action }
|
||||||
catch (Swig::DirectorException &e) { SWIG_fail; }
|
catch (Swig::DirectorException &e) { SWIG_fail; }
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1197,7 +1204,7 @@ Swig::DirectorMethodException is thrown, PHP will register the exception
|
||||||
as soon as the C wrapper function returns.
|
as soon as the C wrapper function returns.
|
||||||
</p>
|
</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>
|
<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.
|
directive) for only those methods that are likely to be extended in PHP.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1244,7 +1251,7 @@ need to be supported.
|
||||||
</p>
|
</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
|
<p> Director typemaps for STL classes are mostly in place, and hence you
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Pike">35 SWIG and Pike</a></H1>
|
<H1><a name="Pike">37 SWIG and Pike</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -47,10 +47,10 @@ least, make sure you read the "<a href="SWIG.html#SWIG">SWIG Basics</a>"
|
||||||
chapter.<br>
|
chapter.<br>
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -95,7 +95,7 @@ can use the <tt>-o</tt> option:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>$ <b>swig -pike -o pseudonym.c example.i</b><br></pre>
|
<pre>$ <b>swig -pike -o pseudonym.c example.i</b><br></pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -115,7 +115,7 @@ You're looking for files with the names <tt>global.h</tt>, <tt>program.h</tt>
|
||||||
and so on.
|
and so on.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -130,10 +130,10 @@ Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
|
||||||
(1) Result: 24
|
(1) Result: 24
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -144,7 +144,7 @@ concerned), SWIG's <tt>%module</tt> directive doesn't really have any
|
||||||
significance.
|
significance.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Pike_nn8">35.2.2 Functions</a></H3>
|
<H3><a name="Pike_nn8">37.2.2 Functions</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -169,7 +169,7 @@ exactly as you'd expect it to:
|
||||||
(1) Result: 24
|
(1) Result: 24
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -198,7 +198,7 @@ will result in two functions, <tt>Foo_get()</tt> and <tt>Foo_set()</tt>:
|
||||||
(3) Result: 3.141590
|
(3) Result: 3.141590
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -206,7 +206,7 @@ Enumerated types in C/C++ declarations are wrapped as Pike constants,
|
||||||
not as Pike enums.
|
not as Pike enums.
|
||||||
</p>
|
</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>
|
<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.
|
wrapped as <tt>destroy()</tt> methods, for Pike classes.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -230,8 +230,8 @@ For example, given this C++ class declaration:
|
||||||
class Shape
|
class Shape
|
||||||
{
|
{
|
||||||
public:
|
public:
|
||||||
static void print();
|
static void print();
|
||||||
static int nshapes;
|
static int nshapes;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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.
|
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
|
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.
|
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>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Preface_license">1.3 SWIG License</a></H2>
|
<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>
|
<p>
|
||||||
SWIG is known to work on various flavors of OS X. Follow the Unix installation
|
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
|
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.
|
on OS X.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -435,7 +438,7 @@ don't intend to use these features in your own programs.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<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
|
have many different target languages installed and a slow machine, it
|
||||||
might take more than an hour to run the test-suite.
|
might take more than an hour to run the test-suite.
|
||||||
</p>
|
</p>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Preprocessor">8 Preprocessing</a></H1>
|
<H1><a name="Preprocessor">10 Preprocessing</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -38,7 +38,7 @@ However, a number of modifications and enhancements have been made. This
|
||||||
chapter describes some of these modifications.
|
chapter describes some of these modifications.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Preprocessor_nn2">8.1 File inclusion</a></H2>
|
<H2><a name="Preprocessor_nn2">10.1 File inclusion</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
is that you often don't want SWIG to try and wrap everything included
|
||||||
in standard header system headers and auxiliary files.
|
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>
|
<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
|
as imports. This might be useful if you want to extract type definitions from system
|
||||||
header files without generating any wrappers.
|
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>
|
<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,
|
SWIG_VERSION Hexadecimal (binary-coded decimal) number containing SWIG version,
|
||||||
such as 0x010311 (corresponding to SWIG-1.3.11).
|
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#
|
SWIGCSHARP Defined when using C#
|
||||||
SWIGGUILE Defined when using Guile
|
SWIGGUILE Defined when using Guile
|
||||||
SWIGJAVA Defined when using Java
|
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_JSC Defined when using Javascript for JavascriptCore
|
||||||
SWIG_JAVASCRIPT_V8 Defined when using Javascript for v8 or node.js
|
SWIG_JAVASCRIPT_V8 Defined when using Javascript for v8 or node.js
|
||||||
SWIGLUA Defined when using Lua
|
SWIGLUA Defined when using Lua
|
||||||
SWIGMODULA3 Defined when using Modula-3
|
|
||||||
SWIGMZSCHEME Defined when using Mzscheme
|
SWIGMZSCHEME Defined when using Mzscheme
|
||||||
SWIGOCAML Defined when using Ocaml
|
SWIGOCAML Defined when using OCaml
|
||||||
SWIGOCTAVE Defined when using Octave
|
SWIGOCTAVE Defined when using Octave
|
||||||
SWIGPERL Defined when using Perl
|
SWIGPERL Defined when using Perl
|
||||||
SWIGPHP Defined when using PHP
|
SWIGPHP Defined when using PHP (any version)
|
||||||
SWIGPIKE Defined when using Pike
|
SWIGPHP7 Defined when using PHP7
|
||||||
SWIGPYTHON Defined when using Python
|
SWIGPYTHON Defined when using Python
|
||||||
SWIGR Defined when using R
|
SWIGR Defined when using R
|
||||||
SWIGRUBY Defined when using Ruby
|
SWIGRUBY Defined when using Ruby
|
||||||
SWIGSCILAB Defined when using Scilab
|
SWIGSCILAB Defined when using Scilab
|
||||||
SWIGSEXP Defined when using S-expressions
|
|
||||||
SWIGTCL Defined when using Tcl
|
SWIGTCL Defined when using Tcl
|
||||||
SWIGXML Defined when using XML
|
SWIGXML Defined when using XML
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -144,7 +138,7 @@ In addition, SWIG defines the following set of standard C/C++ macros:
|
||||||
<pre>
|
<pre>
|
||||||
__LINE__ Current line number
|
__LINE__ Current line number
|
||||||
__FILE__ Current file name
|
__FILE__ Current file name
|
||||||
__STDC__ Defined to indicate ANSI C
|
__STDC__ Defined to indicate ISO C
|
||||||
__cplusplus Defined when -c++ option used
|
__cplusplus Defined when -c++ option used
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -157,7 +151,7 @@ SWIG (except for the symbol `<tt>SWIG</tt>' which is only defined
|
||||||
within the SWIG compiler).
|
within the SWIG compiler).
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Preprocessor_nn5">8.4 Macro Expansion</a></H2>
|
<H2><a name="Preprocessor_nn5">10.4 Macro Expansion</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -186,9 +180,9 @@ More complex macros can be defined in the standard way. For example:
|
||||||
<pre>
|
<pre>
|
||||||
#define EXTERN extern
|
#define EXTERN extern
|
||||||
#ifdef __STDC__
|
#ifdef __STDC__
|
||||||
#define _ANSI(args) (args)
|
#define ISOC_(args) (args)
|
||||||
#else
|
#else
|
||||||
#define _ANSI(args) ()
|
#define ISOC_(args) ()
|
||||||
#endif
|
#endif
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -212,7 +206,7 @@ like <tt>#x</tt>. This is a non-standard SWIG extension.
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
<H2><a name="Preprocessor_nn6">8.5 SWIG Macros</a></H2>
|
<H2><a name="Preprocessor_nn6">10.5 SWIG Macros</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -222,19 +216,19 @@ For example:
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%define ARRAYHELPER(type,name)
|
%define ARRAYHELPER(type, name)
|
||||||
%inline %{
|
%inline %{
|
||||||
type *new_ ## name (int nitems) {
|
type *new_ ## name (int nitems) {
|
||||||
return (type *) malloc(sizeof(type)*nitems);
|
return (type *) malloc(sizeof(type)*nitems);
|
||||||
}
|
}
|
||||||
void delete_ ## name(type *t) {
|
void delete_ ## name(type *t) {
|
||||||
free(t);
|
free(t);
|
||||||
}
|
}
|
||||||
type name ## _get(type *t, int index) {
|
type name ## _get(type *t, int index) {
|
||||||
return t[index];
|
return t[index];
|
||||||
}
|
}
|
||||||
void name ## _set(type *t, int index, type val) {
|
void name ## _set(type *t, int index, type val) {
|
||||||
t[index] = val;
|
t[index] = val;
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
%enddef
|
%enddef
|
||||||
|
|
@ -258,7 +252,7 @@ many of SWIG's advanced features and libraries are built using this mechanism (s
|
||||||
support).
|
support).
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -267,7 +261,7 @@ SWIG-1.3.12 and newer releases support variadic preprocessor macros. For exampl
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
#define DEBUGF(fmt,...) fprintf(stderr,fmt,__VA_ARGS__)
|
#define DEBUGF(fmt, ...) fprintf(stderr, fmt, __VA_ARGS__)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -279,12 +273,12 @@ macros defined using <tt>%define</tt>.
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
SWIG allows a variable number of arguments to be empty. However, this often results
|
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>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
DEBUGF("hello"); --> fprintf(stderr,"hello",);
|
DEBUGF("hello"); --> fprintf(stderr, "hello", );
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -294,7 +288,7 @@ To get rid of the extra comma, use <tt>##</tt> like this:
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
#define DEBUGF(fmt,...) fprintf(stderr,fmt, ##__VA_ARGS__)
|
#define DEBUGF(fmt, ...) fprintf(stderr, fmt, ##__VA_ARGS__)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -304,7 +298,7 @@ SWIG also supports GNU-style variadic macros. For example:
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
#define DEBUGF(fmt, args...) fprintf(stdout,fmt,args)
|
#define DEBUGF(fmt, args...) fprintf(stdout, fmt, args)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
SWIG directives and are provided to make SWIG more compatible with C99 code.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
The preprocessor handles { }, " " and %{ %} delimiters differently.
|
The preprocessor handles { }, " " and %{ %} delimiters differently.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Preprocessor_nn8">8.7.1 Preprocessing and %{ ... %} & " ... " delimiters</a></H3>
|
<H3><a name="Preprocessor_nn8">10.7.1 Preprocessing and %{ ... %} & " ... " delimiters</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -334,7 +328,7 @@ if you write code like this,
|
||||||
%{
|
%{
|
||||||
#ifdef NEED_BLAH
|
#ifdef NEED_BLAH
|
||||||
int blah() {
|
int blah() {
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
#endif
|
#endif
|
||||||
%}
|
%}
|
||||||
|
|
@ -346,7 +340,7 @@ the contents of the <tt>%{ ... %}</tt> block are copied without
|
||||||
modification to the output (including all preprocessor directives).
|
modification to the output (including all preprocessor directives).
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -358,11 +352,11 @@ file. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%extend Foo {
|
%extend Foo {
|
||||||
void bar() {
|
void bar() {
|
||||||
#ifdef DEBUG
|
#ifdef DEBUG
|
||||||
printf("I'm in bar\n");
|
printf("I'm in bar\n");
|
||||||
#endif
|
#endif
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -375,11 +369,11 @@ to actually go into the wrapper file, prefix the preprocessor directives with <t
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%extend Foo {
|
%extend Foo {
|
||||||
void bar() {
|
void bar() {
|
||||||
%#ifdef DEBUG
|
%#ifdef DEBUG
|
||||||
printf("I'm in bar\n");
|
printf("I'm in bar\n");
|
||||||
%#endif
|
%#endif
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
SWIG will strip the extra <tt>%</tt> and leave the preprocessor directive in the code.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -423,7 +417,7 @@ whereas
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
#define SWIG_macro(CAST) (CAST)$input
|
#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>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -459,17 +453,17 @@ would generate
|
||||||
</div>
|
</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>
|
<p>
|
||||||
Like many compilers, SWIG supports a <tt>-E</tt> command line option to display the output from the preprocessor.
|
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.
|
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.
|
This might be useful as an aid to debugging and viewing the results of macro expansions.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
|
||||||
File diff suppressed because it is too large
Load diff
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="R">37 SWIG and R</a></H1>
|
<H1><a name="R">33 SWIG and R</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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++.
|
with gcc. The R bindings also work on Microsoft Windows using Visual C++.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="R_nn2">37.1 Bugs</a></H2>
|
<H2><a name="R_nn2">33.1 Bugs</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -46,7 +46,7 @@ Currently the following features are not implemented or broken:
|
||||||
<li>C Array wrappings
|
<li>C Array wrappings
|
||||||
</ul>
|
</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>
|
<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
|
<li>If you do not set the output file name appropriately, you might see errors like
|
||||||
<div class="shell">
|
<div class="shell">
|
||||||
<pre>
|
<pre>
|
||||||
> fact(4)
|
> fact(4)
|
||||||
Error in .Call("R_swig_fact", s_arg1, as.logical(.copy), PACKAGE = "example") :
|
Error in .Call("R_swig_fact", s_arg1, as.logical(.copy), PACKAGE = "example") :
|
||||||
"R_swig_fact" not available for .Call() for package "example"
|
"R_swig_fact" not available for .Call() for package "example"
|
||||||
</pre>
|
</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
|
<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>
|
</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
|
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>
|
<pre>
|
||||||
source('BigFile.R')
|
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")
|
q(save="no")
|
||||||
</pre>
|
</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>
|
<p>
|
||||||
|
|
@ -164,7 +164,7 @@ wrapping over the underlying functions and rely on the R type system
|
||||||
to provide R syntax.
|
to provide R syntax.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -173,7 +173,7 @@ and [ are overloaded to allow for R syntax (one based indices and
|
||||||
slices)
|
slices)
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="R_nn6">37.6 C++ classes</a></H2>
|
<H2><a name="R_nn6">33.6 C++ classes</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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.
|
of the proxy class baggage you see in other languages.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="R_nn7">37.7 Enumerations</a></H2>
|
<H2><a name="R_nn7">33.7 Enumerations</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
enumerations are characters which are then converted back and forth to
|
R doesn't have a native enumeration type. Enumerations are represented
|
||||||
ints before calling the C routines. All of the enumeration code is
|
as character strings in R, with calls to R functions that convert back
|
||||||
done in R.
|
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>
|
</p>
|
||||||
|
|
||||||
</body>
|
</body>
|
||||||
|
|
|
||||||
File diff suppressed because it is too large
Load diff
|
|
@ -88,7 +88,7 @@
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This chapter describes the basic operation of SWIG, the structure of its
|
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
|
described in the next chapter. However, C++ programmers should still read this
|
||||||
chapter to understand the basics.
|
chapter to understand the basics.
|
||||||
Specific details about each target language are described in later
|
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>
|
</p>
|
||||||
|
|
||||||
<div class="shell"><pre>
|
<div class="shell"><pre>
|
||||||
swig [ <em>options</em> ] filename
|
swig [ options ] filename
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
where <tt>filename</tt> is a SWIG interface file or a C/C++ header file.
|
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
|
Additional options are also defined for each target language. A full list
|
||||||
can be obtained by typing <tt>swig -help</tt> or <tt>swig
|
can be obtained by running <tt>swig
|
||||||
<em>-<lang></em> -help</tt> for language <em><lang></em> specific options.
|
<em>-<lang></em> -help</tt> for language <em><lang></em> specific options,
|
||||||
|
for example, <tt>swig -ruby -help</tt> for Ruby.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="shell"><pre>
|
<div class="shell"><pre>
|
||||||
-allegrocl Generate ALLEGROCL wrappers
|
Supported Target Language Options
|
||||||
-chicken Generate CHICKEN wrappers
|
-csharp - Generate C# wrappers
|
||||||
-clisp Generate CLISP wrappers
|
-d - Generate D wrappers
|
||||||
-cffi Generate CFFI wrappers
|
-go - Generate Go wrappers
|
||||||
-csharp Generate C# wrappers
|
-guile - Generate Guile wrappers
|
||||||
-d Generate D wrappers
|
-java - Generate Java wrappers
|
||||||
-go Generate Go wrappers
|
-javascript - Generate Javascript wrappers
|
||||||
-guile Generate Guile wrappers
|
-lua - Generate Lua wrappers
|
||||||
-java Generate Java wrappers
|
-octave - Generate Octave wrappers
|
||||||
-javascript Generate Javascript wrappers
|
-perl5 - Generate Perl 5 wrappers
|
||||||
-lua Generate Lua wrappers
|
-php7 - Generate PHP 7 wrappers
|
||||||
-modula3 Generate Modula 3 wrappers
|
-python - Generate Python wrappers
|
||||||
-mzscheme Generate Mzscheme wrappers
|
-r - Generate R (aka GNU S) wrappers
|
||||||
-ocaml Generate Ocaml wrappers
|
-ruby - Generate Ruby wrappers
|
||||||
-octave Generate Octave wrappers
|
-scilab - Generate Scilab wrappers
|
||||||
-perl Generate Perl wrappers
|
-tcl8 - Generate Tcl 8 wrappers
|
||||||
-php Generate PHP wrappers
|
-xml - Generate XML 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
|
|
||||||
|
|
||||||
-c++ Enable C++ parsing
|
Experimental Target Language Options
|
||||||
-cppext <em>ext</em> Change file extension of C++ generated files to <em>ext</em>
|
-mzscheme - Generate MzScheme/Racket wrappers
|
||||||
(default is cxx, except for PHP which uses cpp)
|
-ocaml - Generate OCaml wrappers
|
||||||
-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 <outfile>
|
|
||||||
-oh <em>headfile</em> Set name of C++ output header file for directors to <headfile>
|
|
||||||
-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
|
|
||||||
|
|
||||||
|
General Options
|
||||||
|
-addextern - Add extra extern declarations
|
||||||
|
-c++ - Enable C++ processing
|
||||||
|
-co <file> - Check <file> out of the SWIG library
|
||||||
|
-copyctor - Automatically generate copy constructors wherever possible
|
||||||
|
-cpperraswarn - Treat the preprocessor #error statement as #warning (default)
|
||||||
|
-cppext <ext> - Change file extension of generated C++ files to <ext>
|
||||||
|
(default is cxx)
|
||||||
|
-copyright - Display copyright notices
|
||||||
|
-debug-classes - Display information about the classes found in the interface
|
||||||
|
-debug-module <n>- Display module parse tree at stages 1-4, <n> 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 <n> - Display entire parse tree at stages 1-4, <n> is a csv list of stages
|
||||||
|
-debug-typedef - Display information about the types and typedefs in the interface
|
||||||
|
-debug-typemap - Display 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<symbol> - Define a symbol <symbol> (for conditional compilation)
|
||||||
|
-E - Preprocess only, does not generate wrapper code
|
||||||
|
-external-runtime [file] - Export the SWIG runtime stack
|
||||||
|
-fakeversion <v>- Make SWIG fake the program version number to <v>
|
||||||
|
-fcompact - Compile in compact mode
|
||||||
|
-features <list>- Set global features, where <list> 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<dir> - Look for SWIG files in directory <dir>
|
||||||
|
-ignoremissing - Ignore missing include files
|
||||||
|
-importall - Follow all #include statements as imports
|
||||||
|
-includeall - Follow all #include statements
|
||||||
|
-l<ifile> - Include SWIG library file <ifile>
|
||||||
|
-macroerrors - Report errors inside macros
|
||||||
|
-makedefault - Create default constructors/destructors (the default)
|
||||||
|
-M - List all dependencies
|
||||||
|
-MD - Is equivalent to `-M -MF <file>', except `-E' is not implied
|
||||||
|
-MF <file> - Generate dependencies into <file> and continue generating wrappers
|
||||||
|
-MM - List dependencies, but omit files in SWIG library
|
||||||
|
-MMD - Like `-MD', but omit files in SWIG library
|
||||||
|
-module <name> - Set module name to <name>
|
||||||
|
-MP - Generate phony targets for all dependencies
|
||||||
|
-MT <target> - 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 <outfile> - Set name of C/C++ output file to <outfile>
|
||||||
|
-oh <headfile> - Set name of C++ output header file for directors to <headfile>
|
||||||
|
-outcurrentdir - Set default output dir to current dir instead of input file's path
|
||||||
|
-outdir <dir> - Set language specific files output directory to <dir>
|
||||||
|
-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<list> - Suppress/add warning messages, eg -w401,+321 - see Warnings.html
|
||||||
|
-xmlout <file> - Write XML version of the parse tree to <file> after normal processing
|
||||||
</pre></div>
|
</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>
|
<H3><a name="SWIG_nn3">5.1.1 Input format</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
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
|
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
|
<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"
|
#include "myheader.h"
|
||||||
%}
|
%}
|
||||||
// Now list ANSI C/C++ declarations
|
// Now list ISO C/C++ declarations
|
||||||
int foo;
|
int foo;
|
||||||
int bar(int x);
|
int bar(int x);
|
||||||
...
|
...
|
||||||
|
|
@ -388,7 +474,7 @@ For example
|
||||||
/* bar not wrapped unless foo has been defined and
|
/* bar not wrapped unless foo has been defined and
|
||||||
the declaration of bar within foo has already been parsed */
|
the declaration of bar within foo has already been parsed */
|
||||||
int foo::bar(int) {
|
int foo::bar(int) {
|
||||||
... whatever ...
|
... whatever ...
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -479,7 +565,7 @@ Or in Python:
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> example.sin(3)
|
>>> example.sin(3)
|
||||||
5.2335956
|
5.2335956
|
||||||
>>> example.strcmp('Dave','Mike')
|
>>> example.strcmp('Dave', 'Mike')
|
||||||
-1
|
-1
|
||||||
>>> print example.cvar.Foo
|
>>> print example.cvar.Foo
|
||||||
42
|
42
|
||||||
|
|
@ -648,7 +734,7 @@ print cvar.foo # Print value of foo
|
||||||
|
|
||||||
# Perl
|
# Perl
|
||||||
$foo = 3.5; # Set foo to 3.5
|
$foo = 3.5; # Set foo to 3.5
|
||||||
print $foo,"\n"; # Print value of foo
|
print $foo, "\n"; # Print value of foo
|
||||||
|
|
||||||
# Ruby
|
# Ruby
|
||||||
Module.foo = 3.5 # Set foo to 3.5
|
Module.foo = 3.5 # Set foo to 3.5
|
||||||
|
|
@ -749,7 +835,7 @@ form of type-checking however).</p>
|
||||||
<p>
|
<p>
|
||||||
For enumerations, it is critical that the original enum definition be
|
For enumerations, it is critical that the original enum definition be
|
||||||
included somewhere in the interface file (either in a header file or
|
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
|
into code needed to add the constants to a scripting language. It
|
||||||
needs the original enumeration declaration in order to get the correct
|
needs the original enumeration declaration in order to get the correct
|
||||||
enum values as assigned by the C compiler.
|
enum values as assigned by the C compiler.
|
||||||
|
|
@ -1041,15 +1127,15 @@ expect :</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
# Copy a file
|
# Copy a file
|
||||||
def filecopy(source,target):
|
def filecopy(source, target):
|
||||||
f1 = fopen(source,"r")
|
f1 = fopen(source, "r")
|
||||||
f2 = fopen(target,"w")
|
f2 = fopen(target, "w")
|
||||||
buffer = malloc(8192)
|
buffer = malloc(8192)
|
||||||
nbytes = fread(buffer,8192,1,f1)
|
nbytes = fread(buffer, 8192, 1, f1)
|
||||||
while (nbytes > 0):
|
while (nbytes > 0):
|
||||||
fwrite(buffer,8192,1,f2)
|
fwrite(buffer, 8192, 1, f2)
|
||||||
nbytes = fread(buffer,8192,1,f1)
|
nbytes = fread(buffer, 8192, 1, f1)
|
||||||
free(buffer)
|
free(buffer)
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1235,9 +1321,9 @@ creating a wrapper equivalent to the following:
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
double wrap_dot_product(Vector *a, Vector *b) {
|
double wrap_dot_product(Vector *a, Vector *b) {
|
||||||
Vector x = *a;
|
Vector x = *a;
|
||||||
Vector y = *b;
|
Vector y = *b;
|
||||||
return dot_product(x,y);
|
return dot_product(x, y);
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -1265,12 +1351,12 @@ pointers. As a result, SWIG creates a wrapper like this:
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
Vector *wrap_cross_product(Vector *v1, Vector *v2) {
|
Vector *wrap_cross_product(Vector *v1, Vector *v2) {
|
||||||
Vector x = *v1;
|
Vector x = *v1;
|
||||||
Vector y = *v2;
|
Vector y = *v2;
|
||||||
Vector *result;
|
Vector *result;
|
||||||
result = (Vector *) malloc(sizeof(Vector));
|
result = (Vector *) malloc(sizeof(Vector));
|
||||||
*(result) = cross(x,y);
|
*(result) = cross(x, y);
|
||||||
return result;
|
return result;
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -1279,10 +1365,10 @@ or if SWIG was run with the <tt>-c++</tt> option:</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
Vector *wrap_cross(Vector *v1, Vector *v2) {
|
Vector *wrap_cross(Vector *v1, Vector *v2) {
|
||||||
Vector x = *v1;
|
Vector x = *v1;
|
||||||
Vector y = *v2;
|
Vector y = *v2;
|
||||||
Vector *result = new Vector(cross(x,y)); // Uses default copy constructor
|
Vector *result = new Vector(cross(x, y)); // Uses default copy constructor
|
||||||
return result;
|
return result;
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -1357,16 +1443,16 @@ SWIG generates the following code:
|
||||||
<pre>
|
<pre>
|
||||||
/* C mode */
|
/* C mode */
|
||||||
void foo_set(char *value) {
|
void foo_set(char *value) {
|
||||||
if (foo) free(foo);
|
if (foo) free(foo);
|
||||||
foo = (char *) malloc(strlen(value)+1);
|
foo = (char *) malloc(strlen(value)+1);
|
||||||
strcpy(foo,value);
|
strcpy(foo, value);
|
||||||
}
|
}
|
||||||
|
|
||||||
/* C++ mode. When -c++ option is used */
|
/* C++ mode. When -c++ option is used */
|
||||||
void foo_set(char *value) {
|
void foo_set(char *value) {
|
||||||
if (foo) delete [] foo;
|
if (foo) delete [] foo;
|
||||||
foo = new char[strlen(value)+1];
|
foo = new char[strlen(value)+1];
|
||||||
strcpy(foo,value);
|
strcpy(foo, value);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1381,8 +1467,8 @@ exactly like you want. For example:
|
||||||
<pre>
|
<pre>
|
||||||
%inline %{
|
%inline %{
|
||||||
void set_foo(char *value) {
|
void set_foo(char *value) {
|
||||||
strncpy(foo,value, 50);
|
strncpy(foo, value, 50);
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1538,10 +1624,10 @@ a few simple assist functions like this:
|
||||||
<pre>
|
<pre>
|
||||||
%inline %{
|
%inline %{
|
||||||
void a_set(int i, int j, int val) {
|
void a_set(int i, int j, int val) {
|
||||||
a[i][j] = val;
|
a[i][j] = val;
|
||||||
}
|
}
|
||||||
int a_get(int i, int j) {
|
int a_get(int i, int j) {
|
||||||
return a[i][j];
|
return a[i][j];
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -1558,11 +1644,11 @@ some helper functions in your interface. For example:
|
||||||
%inline %{
|
%inline %{
|
||||||
/* Create any sort of [size] array */
|
/* Create any sort of [size] array */
|
||||||
int *int_array(int size) {
|
int *int_array(int size) {
|
||||||
return (int *) malloc(size*sizeof(int));
|
return (int *) malloc(size*sizeof(int));
|
||||||
}
|
}
|
||||||
/* Create a two-dimension array [size][10] */
|
/* Create a two-dimension array [size][10] */
|
||||||
int (*int_array_10(int 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>
|
</pre>
|
||||||
|
|
@ -1587,10 +1673,10 @@ code:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
char *pathname_get() {
|
char *pathname_get() {
|
||||||
return pathname;
|
return pathname;
|
||||||
}
|
}
|
||||||
void pathname_set(char *value) {
|
void pathname_set(char *value) {
|
||||||
strncpy(pathname,value,256);
|
strncpy(pathname, value, 256);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1611,9 +1697,9 @@ directive as shown :</p>
|
||||||
|
|
||||||
int a; // Can read/write
|
int a; // Can read/write
|
||||||
%immutable;
|
%immutable;
|
||||||
int b,c,d; // Read only variables
|
int b, c, d; // Read only variables
|
||||||
%mutable;
|
%mutable;
|
||||||
double x,y; // read/write
|
double x, y; // read/write
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1638,7 +1724,7 @@ The <tt>%mutable</tt> and <tt>%immutable</tt> directives are actually
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
#define %immutable %feature("immutable")
|
#define %immutable %feature("immutable")
|
||||||
#define %mutable %feature("immutable","")
|
#define %mutable %feature("immutable", "")
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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>
|
<div class="code"><pre>
|
||||||
%immutable; // Make all variables read-only
|
%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 x;
|
||||||
double y;
|
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
|
careful about namespaces and your use of modules, you can usually
|
||||||
avoid these problems.</p>
|
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>
|
<p>
|
||||||
Closely related to <tt>%rename</tt> is the <tt>%ignore</tt> directive. <tt>%ignore</tt> instructs SWIG
|
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:
|
to ignore declarations that match a given identifier. For example:
|
||||||
|
|
@ -2077,7 +2173,7 @@ except those consisting of capital letters only:
|
||||||
<p>
|
<p>
|
||||||
Finally, variants of <tt>%rename</tt> and <tt>%ignore</tt> directives can be used to help
|
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
|
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>
|
</p>
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -2146,7 +2242,7 @@ used in Tcl as follows :</p>
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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++.
|
arguments specified in a SWIG interface work with both C and C++.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -2166,13 +2262,13 @@ in the C++ chapter for further details.
|
||||||
<p>
|
<p>
|
||||||
Occasionally, a C library may include functions that expect to receive
|
Occasionally, a C library may include functions that expect to receive
|
||||||
pointers to functions--possibly to serve as callbacks. SWIG
|
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,
|
functions are defined in C and not in the target language. For example,
|
||||||
consider a function like this:
|
consider a function like this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<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>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -2181,10 +2277,10 @@ may find the function to be impossible to use. For instance, in Python:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> def add(x,y):
|
>>> def add(x, y):
|
||||||
... return x+y
|
... return x+y
|
||||||
...
|
...
|
||||||
>>> binary_op(3,4,add)
|
>>> binary_op(3, 4, add)
|
||||||
Traceback (most recent call last):
|
Traceback (most recent call last):
|
||||||
File "<stdin>", line 1, in ?
|
File "<stdin>", line 1, in ?
|
||||||
TypeError: Type error. Expected _p_f_int_int__int
|
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>
|
<div class="code"><pre>
|
||||||
/* Function with a callback */
|
/* 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 */
|
/* Some callback functions */
|
||||||
%constant int add(int,int);
|
%constant int add(int, int);
|
||||||
%constant int sub(int,int);
|
%constant int sub(int, int);
|
||||||
%constant int mul(int,int);
|
%constant int mul(int, int);
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -2216,9 +2312,9 @@ constants in the target scripting language. This allows you to use them as foll
|
||||||
|
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> binary_op(3,4,add)
|
>>> binary_op(3, 4, add)
|
||||||
7
|
7
|
||||||
>>> binary_op(3,4,mul)
|
>>> binary_op(3, 4, mul)
|
||||||
12
|
12
|
||||||
>>>
|
>>>
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2231,7 +2327,7 @@ as functions. For example:
|
||||||
|
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> add(3,4)
|
>>> add(3, 4)
|
||||||
Traceback (most recent call last):
|
Traceback (most recent call last):
|
||||||
File "<stdin>", line 1, in ?
|
File "<stdin>", line 1, in ?
|
||||||
TypeError: object is not callable: '_ff020efc_p_f_int_int__int'
|
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">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
/* Function with a callback */
|
/* 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 */
|
/* Some callback functions */
|
||||||
%callback("%s_cb");
|
%callback("%s_cb");
|
||||||
int add(int,int);
|
int add(int, int);
|
||||||
int sub(int,int);
|
int sub(int, int);
|
||||||
int mul(int,int);
|
int mul(int, int);
|
||||||
%nocallback;
|
%nocallback;
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -2266,13 +2362,13 @@ disabled using <tt>%nocallback</tt>. When you do this, the interface now works
|
||||||
|
|
||||||
<div class="targetlang">
|
<div class="targetlang">
|
||||||
<pre>
|
<pre>
|
||||||
>>> binary_op(3,4,add_cb)
|
>>> binary_op(3, 4, add_cb)
|
||||||
7
|
7
|
||||||
>>> binary_op(3,4,mul_cb)
|
>>> binary_op(3, 4, mul_cb)
|
||||||
12
|
12
|
||||||
>>> add(3,4)
|
>>> add(3, 4)
|
||||||
7
|
7
|
||||||
>>> mul(3,4)
|
>>> mul(3, 4)
|
||||||
12
|
12
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2293,9 +2389,9 @@ variation installs the callbacks as all upper case constants such as
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
/* Some callback functions */
|
/* Some callback functions */
|
||||||
%callback("%(uppercase)s");
|
%callback("%(uppercase)s");
|
||||||
int add(int,int);
|
int add(int, int);
|
||||||
int sub(int,int);
|
int sub(int, int);
|
||||||
int mul(int,int);
|
int mul(int, int);
|
||||||
%nocallback;
|
%nocallback;
|
||||||
</pre></div>
|
</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
|
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.
|
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
|
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>
|
</p>
|
||||||
|
|
||||||
<H2><a name="SWIG_nn31">5.5 Structures and unions</a></H2>
|
<H2><a name="SWIG_nn31">5.5 Structures and unions</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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.
|
handle C++ are described in the next section.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
@ -2331,7 +2429,7 @@ to an individual member. For example, the declaration :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
struct Vector {
|
struct Vector {
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
}
|
}
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -2367,10 +2465,10 @@ defined in the interface. For example:
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
struct Vector *new_Vector() {
|
struct Vector *new_Vector() {
|
||||||
return (Vector *) calloc(1,sizeof(struct Vector));
|
return (Vector *) calloc(1, sizeof(struct Vector));
|
||||||
}
|
}
|
||||||
void delete_Vector(struct Vector *obj) {
|
void delete_Vector(struct Vector *obj) {
|
||||||
free(obj);
|
free(obj);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2383,9 +2481,9 @@ language using code like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
v = new_Vector()
|
v = new_Vector()
|
||||||
Vector_x_set(v,2)
|
Vector_x_set(v, 2)
|
||||||
Vector_y_set(v,10)
|
Vector_y_set(v, 10)
|
||||||
Vector_z_set(v,-5)
|
Vector_z_set(v, -5)
|
||||||
...
|
...
|
||||||
delete_Vector(v)
|
delete_Vector(v)
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2404,7 +2502,7 @@ programs :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
typedef struct {
|
typedef struct {
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
} Vector;
|
} Vector;
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -2429,7 +2527,7 @@ If two different names are used like this :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
typedef struct vector_struct {
|
typedef struct vector_struct {
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
} Vector;
|
} Vector;
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -2473,7 +2571,7 @@ char *Foo_name_set(Foo *obj, char *c) {
|
||||||
if (obj->name)
|
if (obj->name)
|
||||||
free(obj->name);
|
free(obj->name);
|
||||||
obj->name = (char *) malloc(strlen(c)+1);
|
obj->name = (char *) malloc(strlen(c)+1);
|
||||||
strcpy(obj->name,c);
|
strcpy(obj->name, c);
|
||||||
return obj->name;
|
return obj->name;
|
||||||
}
|
}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -2521,12 +2619,12 @@ Occasionally, a structure will contain data members that are themselves structur
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
typedef struct Foo {
|
typedef struct Foo {
|
||||||
int x;
|
int x;
|
||||||
} Foo;
|
} Foo;
|
||||||
|
|
||||||
typedef struct Bar {
|
typedef struct Bar {
|
||||||
int y;
|
int y;
|
||||||
Foo f; /* struct member */
|
Foo f; /* struct member */
|
||||||
} Bar;
|
} Bar;
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2540,10 +2638,10 @@ The accessors to the member variable as a pointer are effectively wrapped as fol
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
Foo *Bar_f_get(Bar *b) {
|
Foo *Bar_f_get(Bar *b) {
|
||||||
return &b->f;
|
return &b->f;
|
||||||
}
|
}
|
||||||
void Bar_f_set(Bar *b, Foo *value) {
|
void Bar_f_set(Bar *b, Foo *value) {
|
||||||
b->f = *value;
|
b->f = *value;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2570,7 +2668,7 @@ language interface) results in the following code:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
Bar *b;
|
Bar *b;
|
||||||
Foo_x_set(Bar_f_get(b),37);
|
Foo_x_set(Bar_f_get(b), 37);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -2588,7 +2686,7 @@ is a structure or class. For instance, if you had a structure like this,
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
struct Foo {
|
struct Foo {
|
||||||
WORD w;
|
WORD w;
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2601,10 +2699,10 @@ like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
WORD Foo_w_get(Foo *f) {
|
WORD Foo_w_get(Foo *f) {
|
||||||
return f->w;
|
return f->w;
|
||||||
}
|
}
|
||||||
void Foo_w_set(FOO *f, WORD value) {
|
void Foo_w_set(FOO *f, WORD value) {
|
||||||
f->w = value;
|
f->w = value;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2726,7 +2824,7 @@ the following declaration :</p>
|
||||||
/* file : vector.h */
|
/* file : vector.h */
|
||||||
...
|
...
|
||||||
typedef struct Vector {
|
typedef struct Vector {
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
} Vector;
|
} Vector;
|
||||||
|
|
||||||
</pre></div>
|
</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->x*$self->x+$self->y*$self->y+$self->z*$self->z);
|
return sqrt($self->x*$self->x+$self->y*$self->y+$self->z*$self->z);
|
||||||
}
|
}
|
||||||
void print() {
|
void print() {
|
||||||
printf("Vector [%g, %g, %g]\n", $self->x,$self->y,$self->z);
|
printf("Vector [%g, %g, %g]\n", $self->x, $self->y, $self->z);
|
||||||
}
|
}
|
||||||
};
|
};
|
||||||
|
|
||||||
|
|
@ -2779,7 +2877,7 @@ Now, when used with proxy classes in Python, you can do things like
|
||||||
this :</p>
|
this :</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
>>> v = Vector(3,4,0) # Create a new vector
|
>>> v = Vector(3, 4, 0) # Create a new vector
|
||||||
>>> print v.magnitude() # Print magnitude
|
>>> print v.magnitude() # Print magnitude
|
||||||
5.0
|
5.0
|
||||||
>>> v.print() # Print it out
|
>>> v.print() # Print it out
|
||||||
|
|
@ -2799,7 +2897,7 @@ of the Vector structure. For example:</p>
|
||||||
%}
|
%}
|
||||||
|
|
||||||
typedef struct Vector {
|
typedef struct Vector {
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
%extend {
|
%extend {
|
||||||
Vector(double x, double y, double z) { ... }
|
Vector(double x, double y, double z) { ... }
|
||||||
~Vector() { ... }
|
~Vector() { ... }
|
||||||
|
|
@ -2841,12 +2939,12 @@ double Vector_magnitude(Vector *v) {
|
||||||
%}
|
%}
|
||||||
|
|
||||||
typedef struct Vector {
|
typedef struct Vector {
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
%extend {
|
%extend {
|
||||||
Vector(int,int,int); // This calls new_Vector()
|
Vector(int, int, int); // This calls new_Vector()
|
||||||
~Vector(); // This calls delete_Vector()
|
~Vector(); // This calls delete_Vector()
|
||||||
double magnitude(); // This will call Vector_magnitude()
|
double magnitude(); // This will call Vector_magnitude()
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
} Vector;
|
} Vector;
|
||||||
</pre>
|
</pre>
|
||||||
|
|
@ -2895,7 +2993,7 @@ instead of a method. To do this, you might write some code like this:
|
||||||
<pre>
|
<pre>
|
||||||
// Add a new attribute to Vector
|
// Add a new attribute to Vector
|
||||||
%extend Vector {
|
%extend Vector {
|
||||||
const double magnitude;
|
const double magnitude;
|
||||||
}
|
}
|
||||||
// Now supply the implementation of the Vector_magnitude_get function
|
// 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) {
|
void Person_name_set(Person *p, char *val) {
|
||||||
strncpy(p->name,val,50);
|
strncpy(p->name, val, 50);
|
||||||
make_upper(p->name);
|
make_upper(p->name);
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
|
|
@ -3083,7 +3181,7 @@ in terms of high-level accessor functions such as this,
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
double Vector_x_get(Vector *v) {
|
double Vector_x_get(Vector *v) {
|
||||||
return v->x;
|
return v->x;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -3100,15 +3198,15 @@ the following function is generated instead:
|
||||||
static int
|
static int
|
||||||
_wrap_Vector_x_get(ClientData clientData, Tcl_Interp *interp,
|
_wrap_Vector_x_get(ClientData clientData, Tcl_Interp *interp,
|
||||||
int objc, Tcl_Obj *CONST objv[]) {
|
int objc, Tcl_Obj *CONST objv[]) {
|
||||||
struct Vector *arg1 ;
|
struct Vector *arg1 ;
|
||||||
double result ;
|
double result ;
|
||||||
|
|
||||||
if (SWIG_GetArgs(interp, objc, objv,"p:Vector_x_get self ",&arg0,
|
if (SWIG_GetArgs(interp, objc, objv, "p:Vector_x_get self ", &arg0,
|
||||||
SWIGTYPE_p_Vector) == TCL_ERROR)
|
SWIGTYPE_p_Vector) == TCL_ERROR)
|
||||||
return TCL_ERROR;
|
return TCL_ERROR;
|
||||||
result = (double ) (arg1->x);
|
result = (double ) (arg1->x);
|
||||||
Tcl_SetObjResult(interp,Tcl_NewDoubleObj((double) result));
|
Tcl_SetObjResult(interp, Tcl_NewDoubleObj((double) result));
|
||||||
return TCL_OK;
|
return TCL_OK;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -3139,9 +3237,9 @@ output of SWIG is structured first.</p>
|
||||||
|
|
||||||
|
|
||||||
<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
|
corresponding to runtime code, headers, wrapper functions, and module
|
||||||
initialization code (in that order).
|
initialization code (in that order).
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -3175,31 +3273,59 @@ the module upon loading.
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Code is inserted into the appropriate code section by using one
|
The <tt>%insert</tt> directive enables inserting blocks of code into a given section of the generated code.
|
||||||
of the code insertion directives listed below. The order of the sections in
|
It can be used in one of two ways:
|
||||||
the wrapper file is as shown:
|
</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>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%begin %{
|
%begin %{
|
||||||
... code in begin section ...
|
... code in begin section ...
|
||||||
%}
|
%}
|
||||||
|
|
||||||
%runtime %{
|
%runtime %{
|
||||||
... code in runtime section ...
|
... code in runtime section ...
|
||||||
%}
|
%}
|
||||||
|
|
||||||
%header %{
|
%header %{
|
||||||
... code in header section ...
|
... code in header section ...
|
||||||
%}
|
%}
|
||||||
|
|
||||||
%wrapper %{
|
%wrapper %{
|
||||||
... code in wrapper section ...
|
... code in wrapper section ...
|
||||||
%}
|
%}
|
||||||
|
|
||||||
%init %{
|
%init %{
|
||||||
... code in init section ...
|
... code in init section ...
|
||||||
%}
|
%}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -3264,11 +3390,27 @@ Vector *new_Vector() {
|
||||||
return (Vector *) malloc(sizeof(Vector));
|
return (Vector *) malloc(sizeof(Vector));
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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
|
verbatim into the header portion of an interface file. The code is
|
||||||
then parsed by both the SWIG preprocessor and parser.
|
then parsed by both the SWIG preprocessor and parser.
|
||||||
Thus, the above example creates a new command <tt>new_Vector</tt> using only one
|
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
|
is given to both the C compiler and SWIG, it is illegal to include any
|
||||||
SWIG directives inside a <tt>%{ ... %}</tt> block.</p>
|
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>
|
<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
|
SWIG's <tt>%include</tt> directive to process an entire C
|
||||||
source/header file.
|
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
|
<li>Make sure all necessary `<tt>typedef</tt>' declarations and
|
||||||
type-information is available in the interface file.
|
type-information is available in the interface file.
|
||||||
|
|
@ -3441,7 +3588,7 @@ header files.
|
||||||
<p>
|
<p>
|
||||||
Sometimes, it is necessary to use certain header files in order for
|
Sometimes, it is necessary to use certain header files in order for
|
||||||
the code generated by SWIG to compile properly. Make sure you
|
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>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
|
|
|
||||||
File diff suppressed because it is too large
Load diff
|
|
@ -9,7 +9,7 @@
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
|
|
||||||
<H1><a name="Scilab">39 SWIG and Scilab</a></H1>
|
<H1><a name="Scilab">35 SWIG and Scilab</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -39,7 +39,7 @@
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Scilab_wrapping_pointers">Pointers</a>
|
<li><a href="#Scilab_wrapping_pointers">Pointers</a>
|
||||||
<ul>
|
<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>
|
<li><a href="#Scilab_wrapping_pointers_null_pointers">Null pointers:</a>
|
||||||
</ul>
|
</ul>
|
||||||
<li><a href="#Scilab_wrapping_structs">Structures</a>
|
<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>
|
</p>
|
||||||
|
|
||||||
|
|
||||||
<H2><a name="Scilab_preliminaries">39.1 Preliminaries</a></H2>
|
<H2><a name="Scilab_preliminaries">35.1 Preliminaries</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -105,7 +105,7 @@ SWIG for Scilab supports C language. C++ is partially supported. See <a href="#S
|
||||||
</p>
|
</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>
|
<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;
|
double Foo = 3.0;
|
||||||
|
|
||||||
int fact(int n) {
|
int fact(int n) {
|
||||||
if (n < 0) {
|
if (n < 0) {
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
else if (n == 0) {
|
else if (n == 0) {
|
||||||
return 1;
|
return 1;
|
||||||
}
|
}
|
||||||
else {
|
else {
|
||||||
return n * fact(n-1);
|
return n * fact(n-1);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -139,7 +139,7 @@ Note: a code in an <tt>%inline</tt> section is both parsed and wrapped by SWIG,
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -182,7 +182,7 @@ The <tt>swig</tt> executable has several other command line options you can use.
|
||||||
</p>
|
</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>
|
<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.
|
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>
|
</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>
|
<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.
|
which means that Scilab has successfully loaded the shared library. The module functions and other symbols are now available in Scilab.
|
||||||
</p>
|
</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>
|
<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.
|
Note: for conciseness, we assume in the subsequent Scilab code examples that the modules have been beforehand built and loaded in Scilab.
|
||||||
</p>
|
</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>
|
<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 <gateway_id></td>
|
<td>Generate the gateway XML with the given <gateway_id></td>
|
||||||
</tr>
|
</tr>
|
||||||
|
|
||||||
|
<tr>
|
||||||
|
<td><tt>-targetversion</tt></td>
|
||||||
|
<td>Generate for Scilab target (major) version</td>
|
||||||
|
</tr>
|
||||||
|
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -315,10 +320,10 @@ $ swig -scilab -help
|
||||||
</pre></div>
|
</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>
|
<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.
|
There are a few exceptions, such as constants and enumerations, which can be wrapped directly as Scilab variables.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
In Scilab 5.x, identifier names are composed of 24 characters maximum (this limitation should disappear from Scilab 6.0 onwards).
|
In Scilab 5.x, identifier names are composed of 24 characters maximum (this limitation disappears from Scilab 6.0 onwards).
|
||||||
<br>Thus long function or variable names may be truncated and this can cause ambiguities.
|
<br>By default, variable, member, and function names longer than 24 characters are truncated, and a warning is produced for each truncation.
|
||||||
</p>
|
</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.
|
In these cases, the <a href="SWIG.html#SWIG_rename_ignore">%rename directive</a> can be used to choose a different Scilab name.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -369,7 +378,7 @@ ans =
|
||||||
24.
|
24.
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -422,7 +431,7 @@ In Scilab, parameters are passed by value. The output (and inout) parameters are
|
||||||
7.
|
7.
|
||||||
</pre></div>
|
</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>
|
<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 *OUTPUT, int *OUTPUT);
|
||||||
|
|
||||||
%{
|
%{
|
||||||
int divide(int n, int d, int q*, int *r) {
|
int divide(int n, int d, int q*, int *r) {
|
||||||
if (d != 0) {
|
if (d != 0) {
|
||||||
*q = n / d;
|
*q = n / d;
|
||||||
*r = n % d;
|
*r = n % d;
|
||||||
return 1;
|
return 1;
|
||||||
}
|
} else {
|
||||||
else return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
}
|
||||||
%}
|
%}
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -470,7 +480,7 @@ int divide(int n, int d, int q*, int *r) {
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -539,10 +549,10 @@ It works the same:</p>
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -683,7 +693,7 @@ are mapped to Scilab variables, with the same name:
|
||||||
3.14
|
3.14
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -748,14 +758,14 @@ typedef enum { RED, BLUE, GREEN } color;
|
||||||
|
|
||||||
</pre></div>
|
</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>
|
<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.
|
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>
|
||||||
<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).
|
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>
|
<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.
|
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).
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -851,7 +861,7 @@ ans =
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -867,7 +877,7 @@ Using the previous <tt>SWIG_this()</tt> and <tt>SWIG_ptr()</tt>, it is possible
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -886,8 +896,8 @@ Let's see it on an example of a struct with two members:
|
||||||
%inline %{
|
%inline %{
|
||||||
|
|
||||||
typedef struct {
|
typedef struct {
|
||||||
int x;
|
int x;
|
||||||
int arr[4];
|
int arr[4];
|
||||||
} Foo;
|
} Foo;
|
||||||
|
|
||||||
%}
|
%}
|
||||||
|
|
@ -963,7 +973,7 @@ ans =
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
|
|
@ -976,7 +986,7 @@ Note: the pointer to the struct works as described in <a href="Scilab_wrapping_p
|
||||||
--> delete_Bar(b);
|
--> delete_Bar(b);
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -1027,7 +1037,7 @@ ans =
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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>
|
</p>
|
||||||
|
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
|
|
@ -1044,7 +1054,7 @@ Note: like structs, class pointers are mapped as described in <a href="Scilab_wr
|
||||||
--> delete_Point(p);
|
--> delete_Point(p);
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -1119,25 +1129,25 @@ But we can use either use the <tt>get_perimeter()</tt> function of the parent cl
|
||||||
18.84
|
18.84
|
||||||
</pre></div>
|
</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>
|
<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>
|
||||||
|
|
||||||
<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>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
%module example
|
%module example
|
||||||
|
|
||||||
void magnify(Square *square, double factor) {
|
void magnify(Square *square, double factor) {
|
||||||
square->size *= factor;
|
square->size *= factor;
|
||||||
};
|
};
|
||||||
|
|
||||||
void magnify(Circle *circle, double factor) {
|
void magnify(Circle *circle, double factor) {
|
||||||
square->radius *= factor;
|
square->radius *= factor;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -1159,7 +1169,7 @@ void magnify(Circle *circle, double factor) {
|
||||||
</pre></div>
|
</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>
|
<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.
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -1242,7 +1252,7 @@ struct triplet {
|
||||||
}
|
}
|
||||||
};
|
};
|
||||||
|
|
||||||
%template(IntTriplet) triplet<int,int,int>;
|
%template(IntTriplet) triplet<int, int, int>;
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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.
|
More details on template support can be found in the <a href="SWIGPlus.html#SWIGPlus_nn30">templates</a> documentation.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1320,7 +1330,7 @@ private:
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
--> c1 = new_Complex(3, 7);
|
--> c1 = new_Complex(3, 7);
|
||||||
|
|
||||||
--> c2 = Complex_plus(c, new_Complex(1,1));
|
--> c2 = Complex_plus(c, new_Complex(1, 1));
|
||||||
|
|
||||||
--> Complex_toDouble(c2)
|
--> Complex_toDouble(c2)
|
||||||
ans =
|
ans =
|
||||||
|
|
@ -1329,7 +1339,7 @@ private:
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -1354,7 +1364,7 @@ namespace foo {
|
||||||
}
|
}
|
||||||
|
|
||||||
struct Vector {
|
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>
|
</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>
|
<p>
|
||||||
|
|
@ -1431,7 +1441,7 @@ void throw_exception() throw(char const *) {
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
-->throw_exception()
|
-->throw_exception()
|
||||||
!--error 999
|
!--error 999
|
||||||
SWIG/Scilab: Exception (char const *) occured: Bye world !
|
SWIG/Scilab: Exception (char const *) occurred: Bye world !
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1448,7 +1458,7 @@ It can be used with the <tt>lasterror()</tt> function as following:
|
||||||
--> lasterror()
|
--> lasterror()
|
||||||
ans =
|
ans =
|
||||||
|
|
||||||
SWIG/Scilab: Exception (char const *) occured: Bye world !
|
SWIG/Scilab: Exception (char const *) occurred: Bye world !
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -1478,7 +1488,7 @@ void throw_stl_invalid_arg(int i) throw(std::invalid_argument) {
|
||||||
<div class="targetlang"><pre>
|
<div class="targetlang"><pre>
|
||||||
--> throw_int();
|
--> throw_int();
|
||||||
!--error 999
|
!--error 999
|
||||||
SWIG/Scilab: Exception (int) occured: 12
|
SWIG/Scilab: Exception (int) occurred: 12
|
||||||
|
|
||||||
-->throw_stl_invalid_arg(-1);
|
-->throw_stl_invalid_arg(-1);
|
||||||
!--error 999
|
!--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.
|
See the <a href="SWIGPlus.html#SWIGPlus">SWIG C++ documentation</a> for more details.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
The Standard Template Library (STL) is partially supported. See <a href="#Scilab_typemaps_stl">STL</a> for more details.
|
The Standard Template Library (STL) is partially supported. See <a href="#Scilab_typemaps_stl">STL</a> for more details.
|
||||||
</p>
|
</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>
|
<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>
|
<p>
|
||||||
|
|
@ -1606,15 +1616,15 @@ void printArray(int values[], int len) {
|
||||||
[ 0 1 2 3 ]
|
[ 0 1 2 3 ]
|
||||||
</pre></div>
|
</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>
|
<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>
|
||||||
|
|
||||||
<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>
|
</p>
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1635,17 +1645,17 @@ double **create_matrix() {
|
||||||
return M;
|
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) {
|
double get_matrix(double **M, int i, int j) {
|
||||||
return M[i][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) {
|
void set_matrix(double **M, int i, int j, double val) {
|
||||||
M[i][j] = 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) {
|
void print_matrix(double **M, int nbRows, int nbCols) {
|
||||||
int i, j;
|
int i, j;
|
||||||
for (i = 0; i < 2; i++) {
|
for (i = 0; i < 2; i++) {
|
||||||
|
|
@ -1679,7 +1689,7 @@ void print_matrix(double **M, int nbRows, int nbCols) {
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -1768,11 +1778,11 @@ void absolute(int *matrix, int matrixNbRow, int matrixNbCol,
|
||||||
The remarks made earlier for arrays also apply here:
|
The remarks made earlier for arrays also apply here:
|
||||||
</p>
|
</p>
|
||||||
<ul>
|
<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>
|
<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>
|
</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>
|
<p>
|
||||||
|
|
@ -1972,7 +1982,7 @@ ans =
|
||||||
--> delete_PersonPtrSet(p);
|
--> delete_PersonPtrSet(p);
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -1996,7 +2006,7 @@ For example, to initialize the module <tt>example</tt>:
|
||||||
--> example_Init();
|
--> example_Init();
|
||||||
</pre></div>
|
</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>
|
<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.
|
<li>the <tt>builder</tt> mode. In this mode, Scilab is responsible of building.
|
||||||
</ul>
|
</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>
|
<p>
|
||||||
|
|
@ -2024,7 +2034,7 @@ This mode is the best option to use when you have to integrate the module build
|
||||||
</p>
|
</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>
|
<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:
|
Let's give an example how to build a module <tt>example</tt>, composed of two sources, and using a library dependency:
|
||||||
</p>
|
</p>
|
||||||
<ul>
|
<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>
|
<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>
|
</ul>
|
||||||
|
|
||||||
|
|
@ -2061,17 +2071,17 @@ The command is:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="shell"><pre>
|
<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>
|
</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>
|
<p>
|
||||||
In this part we give some details about the generated Scilab scripts.
|
In this part we give some details about the generated Scilab scripts.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -2081,12 +2091,12 @@ In this part we give some details about the generated Scilab scripts.
|
||||||
ilib_name = "examplelib";
|
ilib_name = "examplelib";
|
||||||
files = ["example_wrap.c"];
|
files = ["example_wrap.c"];
|
||||||
libs = [];
|
libs = [];
|
||||||
table = ["fact","_wrap_fact";"Foo_set","_wrap_Foo_set";"Foo_get","_wrap_Foo_get";];
|
table = ["fact", "_wrap_fact";"Foo_set", "_wrap_Foo_set";"Foo_get", "_wrap_Foo_get";];
|
||||||
ilib_build(ilib_name,table,files,libs);
|
ilib_build(ilib_name, table, files, libs);
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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>
|
</p>
|
||||||
|
|
||||||
<ul>
|
<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>
|
<li><tt><b>table</b></tt>: two column string matrix containing a table of pairs of 'scilab function name', 'C function name'.</li>
|
||||||
</ul>
|
</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>
|
<p>
|
||||||
|
|
@ -2117,7 +2127,7 @@ list_functions = [ 'fact';
|
||||||
'Foo_set';
|
'Foo_set';
|
||||||
'Foo_get';
|
'Foo_get';
|
||||||
];
|
];
|
||||||
addinter(libexamplelib_path+'/libexamplelib.so','libexamplelib',list_functions);
|
addinter(libexamplelib_path+'/libexamplelib.so', 'libexamplelib', list_functions);
|
||||||
// remove temp. variables on stack
|
// remove temp. variables on stack
|
||||||
clear libexamplelib_path;
|
clear libexamplelib_path;
|
||||||
clear list_functions;
|
clear list_functions;
|
||||||
|
|
@ -2126,7 +2136,7 @@ clear get_file_path;
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<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>
|
</p>
|
||||||
<ul>
|
<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>
|
<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>
|
</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>
|
<ul>
|
||||||
|
|
|
||||||
|
|
@ -135,7 +135,7 @@ int wrap_fact(ClientData clientData, Tcl_Interp *interp, int argc, char *argv[])
|
||||||
}
|
}
|
||||||
arg0 = atoi(argv[1]);
|
arg0 = atoi(argv[1]);
|
||||||
result = fact(arg0);
|
result = fact(arg0);
|
||||||
sprintf(interp->result,"%d", result);
|
sprintf(interp->result, "%d", result);
|
||||||
return TCL_OK;
|
return TCL_OK;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -247,7 +247,7 @@ representation of a structure. For example,
|
||||||
struct Vector {
|
struct Vector {
|
||||||
Vector();
|
Vector();
|
||||||
~Vector();
|
~Vector();
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
};
|
};
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -302,7 +302,7 @@ class Vector {
|
||||||
public:
|
public:
|
||||||
Vector();
|
Vector();
|
||||||
~Vector();
|
~Vector();
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,14 +1,14 @@
|
||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||||
<html>
|
<html>
|
||||||
<head>
|
<head>
|
||||||
<title>SWIG-3.0 Documentation</title>
|
<title>SWIG-4.0 Documentation</title>
|
||||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||||
</head>
|
</head>
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Sections">SWIG-3.0 Documentation</a></H1>
|
<H1><a name="Sections">SWIG-4.0 Documentation</a></H1>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Last update : SWIG-3.0.11 (in progress)
|
Last update : SWIG-4.0.1 (in progress)
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Sections_Sections">Sections</a></H2>
|
<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="SWIG.html#SWIG">SWIG Basics</a> (Read this!)</li>
|
||||||
<li><a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a></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="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="Preprocessor.html#Preprocessor">The SWIG preprocessor</a></li>
|
||||||
<li><a href="Library.html#Library">The SWIG library</a></li>
|
<li><a href="Library.html#Library">The SWIG library</a></li>
|
||||||
<li><a href="Arguments.html#Arguments">Argument handling</a></li>
|
<li><a href="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="Customization.html#Customization">Customization features</a></li>
|
||||||
<li><a href="Contract.html#Contract">Contracts</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="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="Warnings.html#Warnings">Warning messages</a></li>
|
||||||
<li><a href="Modules.html#Modules">Working with Modules</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>
|
<li><a href="CCache.html#CCache">Using SWIG with ccache</a></li>
|
||||||
</ul>
|
</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>
|
<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="Android.html#Android">Android support</a></li>
|
||||||
<li><a href="CSharp.html#CSharp">C# 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="D.html#D">D support</a></li>
|
||||||
<li><a href="Go.html#Go">Go 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="Guile.html#Guile">Guile support</a></li>
|
||||||
<li><a href="Java.html#Java">Java 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="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="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="Octave.html#Octave">Octave support</a></li>
|
||||||
<li><a href="Perl5.html#Perl5">Perl5 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="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="Python.html#Python">Python support</a></li>
|
||||||
<li><a href="R.html#R">R support</a></li>
|
<li><a href="R.html#R">R support</a></li>
|
||||||
<li><a href="Ruby.html#Ruby">Ruby support</a></li>
|
<li><a href="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>
|
<li><a href="Tcl.html#Tcl">Tcl support</a></li>
|
||||||
</ul>
|
</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>
|
<H3><a name="Sections_developers_docs">Developer Documentation</a></H3>
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Tcl">40 SWIG and Tcl</a></H1>
|
<H1><a name="Tcl">36 SWIG and Tcl</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<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.
|
this is no longer supported.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Tcl_nn2">40.1 Preliminaries</a></H2>
|
<H2><a name="Tcl_nn2">36.1 Preliminaries</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<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.
|
need to compile this file and link it with the rest of your program.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -128,7 +128,7 @@ this is the case, you should probably make a symbolic link so that <tt>tcl.h</tt
|
||||||
header file.
|
header file.
|
||||||
</p>
|
</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>
|
<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>
|
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
|
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
|
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.
|
additional information.
|
||||||
</p>
|
</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.
|
<tt>-module</tt> command line option.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -230,7 +230,7 @@ minimal in most situations (and quite frankly not worth the extra
|
||||||
hassle in the opinion of this author).
|
hassle in the opinion of this author).
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -358,7 +358,7 @@ to the default system configuration (this requires root access and you will need
|
||||||
the man pages).
|
the man pages).
|
||||||
</p>
|
</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>
|
<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.
|
might want to investigate using a more formal standard such as COM.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -468,7 +468,7 @@ also introduce problems on platforms that support more than one
|
||||||
linking standard (e.g., -o32 and -n32 on Irix).
|
linking standard (e.g., -o32 and -n32 on Irix).
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -487,7 +487,7 @@ option will append the prefix to the name when creating a command and
|
||||||
call it "<tt>Foo_bar</tt>".
|
call it "<tt>Foo_bar</tt>".
|
||||||
</p>
|
</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>
|
<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>.
|
are always accessed with the namespace name such as <tt>Foo::bar</tt>.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -520,7 +520,7 @@ covers the process of using SWIG with Microsoft Visual C++.
|
||||||
although the procedure may be similar with other compilers.
|
although the procedure may be similar with other compilers.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -578,7 +578,7 @@ MSDOS > tclsh80
|
||||||
%
|
%
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -641,7 +641,7 @@ to get you started. With a little practice, you'll be making lots of
|
||||||
Tcl extensions.
|
Tcl extensions.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -652,7 +652,7 @@ classes. This section briefly covers the essential aspects of this
|
||||||
wrapping.
|
wrapping.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Tcl_nn15">40.3.1 Modules</a></H3>
|
<H3><a name="Tcl_nn15">36.3.1 Modules</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -686,7 +686,7 @@ To fix this, supply an extra argument to <tt>load</tt> like this:
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H3><a name="Tcl_nn16">40.3.2 Functions</a></H3>
|
<H3><a name="Tcl_nn16">36.3.2 Functions</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -711,7 +711,7 @@ like you think it does:
|
||||||
%
|
%
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -791,7 +791,7 @@ extern char *path; // Read-only (due to %immutable)
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -837,8 +837,8 @@ access constants in procedure bodies. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
proc blah {} {
|
proc blah {} {
|
||||||
global FOO
|
global FOO
|
||||||
bar $FOO
|
bar $FOO
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -865,7 +865,7 @@ its actual value or a symbolic identifier name. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
proc blah {} {
|
proc blah {} {
|
||||||
bar FOO
|
bar FOO
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
conversion. This allows the <tt>global</tt> statement to be omitted.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Tcl_nn19">40.3.5 Pointers</a></H3>
|
<H3><a name="Tcl_nn19">36.3.5 Pointers</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -949,16 +949,16 @@ example:
|
||||||
%inline %{
|
%inline %{
|
||||||
/* C-style cast */
|
/* C-style cast */
|
||||||
Bar *FooToBar(Foo *f) {
|
Bar *FooToBar(Foo *f) {
|
||||||
return (Bar *) f;
|
return (Bar *) f;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* C++-style cast */
|
/* C++-style cast */
|
||||||
Foo *BarToFoo(Bar *b) {
|
Foo *BarToFoo(Bar *b) {
|
||||||
return dynamic_cast<Foo*>(b);
|
return dynamic_cast<Foo*>(b);
|
||||||
}
|
}
|
||||||
|
|
||||||
Foo *IncrFoo(Foo *f, int i) {
|
Foo *IncrFoo(Foo *f, int i) {
|
||||||
return f+i;
|
return f+i;
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
</pre>
|
</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.
|
<tt>None</tt> if the conversion can't be performed.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Tcl_nn20">40.3.6 Structures</a></H3>
|
<H3><a name="Tcl_nn20">36.3.6 Structures</a></H3>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -981,7 +981,7 @@ This provides a very natural interface. For example,
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
struct Vector {
|
struct Vector {
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
};
|
};
|
||||||
|
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
@ -1028,12 +1028,12 @@ can also be forced to be read-only using the <tt>%immutable</tt> directive. For
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
struct Foo {
|
struct Foo {
|
||||||
...
|
...
|
||||||
%immutable;
|
%immutable;
|
||||||
int x; /* Read-only members */
|
int x; /* Read-only members */
|
||||||
char *name;
|
char *name;
|
||||||
%mutable;
|
%mutable;
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1054,7 +1054,7 @@ example, consider this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
struct Bar {
|
struct Bar {
|
||||||
int x[16];
|
int x[16];
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1100,11 +1100,11 @@ pointer. For example, suppose you have two structures like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
struct Foo {
|
struct Foo {
|
||||||
int a;
|
int a;
|
||||||
};
|
};
|
||||||
|
|
||||||
struct Bar {
|
struct Bar {
|
||||||
Foo f;
|
Foo f;
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1253,7 +1253,7 @@ Note: Tcl only destroys the underlying object if it has ownership. See the
|
||||||
memory management section that appears shortly.
|
memory management section that appears shortly.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1302,9 +1302,8 @@ To illustrate, suppose you have a class like this:
|
||||||
<pre>
|
<pre>
|
||||||
class Spam {
|
class Spam {
|
||||||
public:
|
public:
|
||||||
static void foo();
|
static void foo();
|
||||||
static int bar;
|
static int bar;
|
||||||
|
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1320,7 +1319,7 @@ In Tcl, the static member is accessed as follows:
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1369,7 +1368,7 @@ For instance:
|
||||||
It is safe to use multiple inheritance with SWIG.
|
It is safe to use multiple inheritance with SWIG.
|
||||||
</p>
|
</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>
|
<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).
|
when the return value is garbage collected).
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1457,9 +1456,9 @@ Similarly, if you have a class like this,
|
||||||
<pre>
|
<pre>
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
Foo();
|
Foo();
|
||||||
Foo(const Foo &);
|
Foo(const Foo &);
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1546,7 +1545,7 @@ first declaration takes precedence.
|
||||||
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1648,7 +1647,7 @@ There are ways to make this operator appear as part of the class using the <tt>%
|
||||||
Keep reading.
|
Keep reading.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1662,10 +1661,10 @@ submodules or packages. For example, if you have a file like this,
|
||||||
%module example
|
%module example
|
||||||
|
|
||||||
namespace foo {
|
namespace foo {
|
||||||
int fact(int n);
|
int fact(int n);
|
||||||
struct Vector {
|
struct Vector {
|
||||||
double x,y,z;
|
double x, y, z;
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1694,11 +1693,11 @@ For example:
|
||||||
%rename(Bar_spam) Bar::spam;
|
%rename(Bar_spam) Bar::spam;
|
||||||
|
|
||||||
namespace Foo {
|
namespace Foo {
|
||||||
int spam();
|
int spam();
|
||||||
}
|
}
|
||||||
|
|
||||||
namespace Bar {
|
namespace Bar {
|
||||||
int spam();
|
int spam();
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1712,7 +1711,7 @@ utilizes thousands of small deeply nested namespaces each with
|
||||||
identical symbol names, well, then you get what you deserve.
|
identical symbol names, well, then you get what you deserve.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1731,16 +1730,16 @@ For example:
|
||||||
|
|
||||||
template<class T1, class T2>
|
template<class T1, class T2>
|
||||||
struct pair {
|
struct pair {
|
||||||
typedef T1 first_type;
|
typedef T1 first_type;
|
||||||
typedef T2 second_type;
|
typedef T2 second_type;
|
||||||
T1 first;
|
T1 first;
|
||||||
T2 second;
|
T2 second;
|
||||||
pair();
|
pair();
|
||||||
pair(const T1&, const T2&);
|
pair(const T1&, const T2&);
|
||||||
~pair();
|
~pair();
|
||||||
};
|
};
|
||||||
|
|
||||||
%template(pairii) pair<int,int>;
|
%template(pairii) pair<int, int>;
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -1764,7 +1763,7 @@ More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</
|
||||||
examples will appear later.
|
examples will appear later.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1776,9 +1775,9 @@ that implements <tt>operator->()</tt> like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
template<class T> class SmartPtr {
|
template<class T> class SmartPtr {
|
||||||
...
|
...
|
||||||
T *operator->();
|
T *operator->();
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1791,8 +1790,8 @@ Then, if you have a class like this,
|
||||||
<pre>
|
<pre>
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
int x;
|
int x;
|
||||||
int bar();
|
int bar();
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1848,7 +1847,7 @@ simply use the <tt>__deref__()</tt> method. For example:
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -1861,7 +1860,7 @@ of low-level details were omitted. This section provides a brief overview
|
||||||
of how the proxy classes work.
|
of how the proxy classes work.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1874,9 +1873,9 @@ have a class like this
|
||||||
<pre>
|
<pre>
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
int x;
|
int x;
|
||||||
int spam(int);
|
int spam(int);
|
||||||
...
|
...
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -1887,19 +1886,19 @@ then SWIG transforms it into a set of low-level procedural wrappers. For example
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
Foo *new_Foo() {
|
Foo *new_Foo() {
|
||||||
return new Foo();
|
return new Foo();
|
||||||
}
|
}
|
||||||
void delete_Foo(Foo *f) {
|
void delete_Foo(Foo *f) {
|
||||||
delete f;
|
delete f;
|
||||||
}
|
}
|
||||||
int Foo_x_get(Foo *f) {
|
int Foo_x_get(Foo *f) {
|
||||||
return f->x;
|
return f->x;
|
||||||
}
|
}
|
||||||
void Foo_x_set(Foo *f, int value) {
|
void Foo_x_set(Foo *f, int value) {
|
||||||
f->x = value;
|
f->x = value;
|
||||||
}
|
}
|
||||||
int Foo_spam(Foo *f, int arg1) {
|
int Foo_spam(Foo *f, int arg1) {
|
||||||
return f->spam(arg1);
|
return f->spam(arg1);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1926,7 +1925,7 @@ function. This allows objects to be encapsulated objects that look a lot like
|
||||||
as shown in the last section.
|
as shown in the last section.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -1946,8 +1945,8 @@ ownership of the result. For example:
|
||||||
<pre>
|
<pre>
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
Foo();
|
Foo();
|
||||||
Foo bar();
|
Foo bar();
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -1976,9 +1975,9 @@ they came from. Therefore, the ownership is set to zero. For example:
|
||||||
<pre>
|
<pre>
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
...
|
...
|
||||||
Foo *spam();
|
Foo *spam();
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2012,8 +2011,8 @@ or global variable. For example, consider this interface:
|
||||||
%module example
|
%module example
|
||||||
|
|
||||||
struct Foo {
|
struct Foo {
|
||||||
int value;
|
int value;
|
||||||
Foo *next;
|
Foo *next;
|
||||||
};
|
};
|
||||||
|
|
||||||
Foo *head = 0;
|
Foo *head = 0;
|
||||||
|
|
@ -2065,10 +2064,10 @@ change the ownership of an object. For instance, consider code like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
class Node {
|
class Node {
|
||||||
Object *value;
|
Object *value;
|
||||||
public:
|
public:
|
||||||
void set_value(Object *v) { value = v; }
|
void set_value(Object *v) { value = v; }
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2114,7 +2113,7 @@ typemaps--an advanced topic discussed later.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -2125,7 +2124,7 @@ example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
void add(int x, int y, int *result) {
|
void add(int x, int y, int *result) {
|
||||||
*result = x + y;
|
*result = x + y;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2137,7 +2136,7 @@ or perhaps
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
int sub(int *x, int *y) {
|
int sub(int *x, int *y) {
|
||||||
return *x+*y;
|
return *x+*y;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2198,7 +2197,7 @@ If a function mutates one of its parameters like this,
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
void negate(int *x) {
|
void negate(int *x) {
|
||||||
*x = -(*x);
|
*x = -(*x);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2302,7 +2301,7 @@ set c [lindex $dim 1]
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H2><a name="Tcl_nn33">40.6 Exception handling </a></H2>
|
<H2><a name="Tcl_nn33">36.6 Exception handling </a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -2328,7 +2327,7 @@ class DoubleArray {
|
||||||
}
|
}
|
||||||
// Destroy an array
|
// Destroy an array
|
||||||
~DoubleArray() {
|
~DoubleArray() {
|
||||||
delete ptr;
|
delete ptr;
|
||||||
}
|
}
|
||||||
// Return the length of the array
|
// Return the length of the array
|
||||||
int length() {
|
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.
|
See the chapter on "<a href="Customization.html#Customization">Customization Features</a>" for more examples.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Tcl_nn34">40.7 Typemaps</a></H2>
|
<H2><a name="Tcl_nn34">36.7 Typemaps</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -2453,7 +2452,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
||||||
C-Tcl interface.
|
C-Tcl interface.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -2466,9 +2465,9 @@ you might define a typemap like this:
|
||||||
%module example
|
%module example
|
||||||
|
|
||||||
%typemap(in) int {
|
%typemap(in) int {
|
||||||
if (Tcl_GetIntFromObj(interp,$input,&$1) == TCL_ERROR)
|
if (Tcl_GetIntFromObj(interp, $input, &$1) == TCL_ERROR)
|
||||||
return TCL_ERROR;
|
return TCL_ERROR;
|
||||||
printf("Received an integer : %d\n",$1);
|
printf("Received an integer : %d\n", $1);
|
||||||
}
|
}
|
||||||
%inline %{
|
%inline %{
|
||||||
extern int fact(int n);
|
extern int fact(int n);
|
||||||
|
|
@ -2505,9 +2504,9 @@ You can refine this by supplying an optional parameter name. For example:
|
||||||
%module example
|
%module example
|
||||||
|
|
||||||
%typemap(in) int n {
|
%typemap(in) int n {
|
||||||
if (Tcl_GetIntFromObj(interp,$input,&$1) == TCL_ERROR)
|
if (Tcl_GetIntFromObj(interp, $input, &$1) == TCL_ERROR)
|
||||||
return TCL_ERROR;
|
return TCL_ERROR;
|
||||||
printf("n = %d\n",$1);
|
printf("n = %d\n", $1);
|
||||||
}
|
}
|
||||||
%inline %{
|
%inline %{
|
||||||
extern int fact(int n);
|
extern int fact(int n);
|
||||||
|
|
@ -2529,9 +2528,9 @@ the typemap system follows <tt>typedef</tt> declarations. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(in) int n {
|
%typemap(in) int n {
|
||||||
if (Tcl_GetIntFromObj(interp,$input,&$1) == TCL_ERROR)
|
if (Tcl_GetIntFromObj(interp, $input, &$1) == TCL_ERROR)
|
||||||
return TCL_ERROR;
|
return TCL_ERROR;
|
||||||
printf("n = %d\n",$1);
|
printf("n = %d\n", $1);
|
||||||
}
|
}
|
||||||
%inline %{
|
%inline %{
|
||||||
typedef int Integer;
|
typedef int Integer;
|
||||||
|
|
@ -2553,7 +2552,7 @@ Typemaps can also be defined for groups of consecutive arguments. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(in) (char *str, int len) {
|
%typemap(in) (char *str, int len) {
|
||||||
$1 = Tcl_GetStringFromObj($input,&$2);
|
$1 = Tcl_GetStringFromObj($input, &$2);
|
||||||
};
|
};
|
||||||
|
|
||||||
int count(char c, char *str, int len);
|
int count(char c, char *str, int len);
|
||||||
|
|
@ -2573,7 +2572,7 @@ parameter is omitted):
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -2586,7 +2585,7 @@ like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(out) int {
|
%typemap(out) int {
|
||||||
Tcl_SetObjResult(interp,Tcl_NewIntObj($1));
|
Tcl_SetObjResult(interp, Tcl_NewIntObj($1));
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -2711,7 +2710,7 @@ Initialize an argument to a value before any conversions occur.
|
||||||
Examples of these methods will appear shortly.
|
Examples of these methods will appear shortly.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -2782,7 +2781,7 @@ properly assigned.
|
||||||
The Tcl name of the wrapper function being created.
|
The Tcl name of the wrapper function being created.
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -2797,36 +2796,36 @@ used as a <tt>char **</tt> object.
|
||||||
|
|
||||||
// This tells SWIG to treat char ** as a special case
|
// This tells SWIG to treat char ** as a special case
|
||||||
%typemap(in) char ** {
|
%typemap(in) char ** {
|
||||||
Tcl_Obj **listobjv;
|
Tcl_Obj **listobjv;
|
||||||
int nitems;
|
int nitems;
|
||||||
int i;
|
int i;
|
||||||
if (Tcl_ListObjGetElements(interp, $input, &nitems, &listobjv) == TCL_ERROR) {
|
if (Tcl_ListObjGetElements(interp, $input, &nitems, &listobjv) == TCL_ERROR) {
|
||||||
return TCL_ERROR;
|
return TCL_ERROR;
|
||||||
}
|
}
|
||||||
$1 = (char **) malloc((nitems+1)*sizeof(char *));
|
$1 = (char **) malloc((nitems+1)*sizeof(char *));
|
||||||
for (i = 0; i < nitems; i++) {
|
for (i = 0; i < nitems; i++) {
|
||||||
$1[i] = Tcl_GetStringFromObj(listobjv[i],0);
|
$1[i] = Tcl_GetStringFromObj(listobjv[i], 0);
|
||||||
}
|
}
|
||||||
$1[i] = 0;
|
$1[i] = 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
// This gives SWIG some cleanup code that will get called after the function call
|
// This gives SWIG some cleanup code that will get called after the function call
|
||||||
%typemap(freearg) char ** {
|
%typemap(freearg) char ** {
|
||||||
if ($1) {
|
if ($1) {
|
||||||
free($1);
|
free($1);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
// Now a test functions
|
// Now a test functions
|
||||||
%inline %{
|
%inline %{
|
||||||
int print_args(char **argv) {
|
int print_args(char **argv) {
|
||||||
int i = 0;
|
int i = 0;
|
||||||
while (argv[i]) {
|
while (argv[i]) {
|
||||||
printf("argv[%d] = %s\n", i,argv[i]);
|
printf("argv[%d] = %s\n", i, argv[i]);
|
||||||
i++;
|
i++;
|
||||||
}
|
}
|
||||||
return i;
|
return i;
|
||||||
}
|
}
|
||||||
%}
|
%}
|
||||||
%include "tclsh.i"
|
%include "tclsh.i"
|
||||||
|
|
||||||
|
|
@ -2844,7 +2843,7 @@ argv[2] = Larry
|
||||||
3
|
3
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -2855,21 +2854,21 @@ function argument. For example :
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
// A typemap defining how to return an argument by appending it to the result
|
// A typemap defining how to return an argument by appending it to the result
|
||||||
%typemap(argout) double *outvalue {
|
%typemap(argout) double *outvalue {
|
||||||
Tcl_Obj *o = Tcl_NewDoubleObj($1);
|
Tcl_Obj *o = Tcl_NewDoubleObj($1);
|
||||||
Tcl_ListObjAppendElement(interp,$result,o);
|
Tcl_ListObjAppendElement(interp, $result, o);
|
||||||
}
|
}
|
||||||
|
|
||||||
// A typemap telling SWIG to ignore an argument for input
|
// A typemap telling SWIG to ignore an argument for input
|
||||||
// However, we still need to pass a pointer to the C function
|
// However, we still need to pass a pointer to the C function
|
||||||
%typemap(in,numinputs=0) double *outvalue (double temp) {
|
%typemap(in, numinputs=0) double *outvalue (double temp) {
|
||||||
$1 = &temp;
|
$1 = &temp;
|
||||||
}
|
}
|
||||||
|
|
||||||
// Now a function returning two values
|
// Now a function returning two values
|
||||||
int mypow(double a, double b, double *outvalue) {
|
int mypow(double a, double b, double *outvalue) {
|
||||||
if ((a < 0) || (b < 0)) return -1;
|
if ((a < 0) || (b < 0)) return -1;
|
||||||
*outvalue = pow(a,b);
|
*outvalue = pow(a, b);
|
||||||
return 0;
|
return 0;
|
||||||
};
|
};
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
|
|
@ -2886,7 +2885,7 @@ result, a Tcl function using these typemaps will work like this :
|
||||||
%
|
%
|
||||||
</pre></div>
|
</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>
|
<p>
|
||||||
|
|
@ -2962,7 +2961,7 @@ int Tcl_IsShared(Tcl_Obj *obj);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -2992,7 +2991,7 @@ work)
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(out) int, short, long {
|
%typemap(out) int, short, long {
|
||||||
Tcl_SetIntObj($result,(int) $1);
|
Tcl_SetIntObj($result, (int) $1);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -3004,10 +3003,10 @@ work)
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(in) float, double {
|
%typemap(in) float, double {
|
||||||
double temp;
|
double temp;
|
||||||
if (Tcl_GetDoubleFromObj(interp, $input, &temp) == TCL_ERROR)
|
if (Tcl_GetDoubleFromObj(interp, $input, &temp) == TCL_ERROR)
|
||||||
return TCL_ERROR;
|
return TCL_ERROR;
|
||||||
$1 = ($1_ltype) temp;
|
$1 = ($1_ltype) temp;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -3017,7 +3016,7 @@ work)
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(out) float, double {
|
%typemap(out) float, double {
|
||||||
Tcl_SetDoubleObj($result, $1);
|
Tcl_SetDoubleObj($result, $1);
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -3029,9 +3028,8 @@ work)
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(in) char * {
|
%typemap(in) char * {
|
||||||
int len;
|
int len;
|
||||||
$1 = Tcl_GetStringFromObj(interp, &len);
|
$1 = Tcl_GetStringFromObj(interp, &len);
|
||||||
}
|
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -3040,14 +3038,14 @@ work)
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(out,noblock=1,fragment="SWIG_FromCharPtr") char *, const char * {
|
%typemap(out, noblock=1, fragment="SWIG_FromCharPtr") char *, const char * {
|
||||||
Tcl_SetObjResult(interp,SWIG_FromCharPtr((const char *)$1));
|
Tcl_SetObjResult(interp, SWIG_FromCharPtr((const char *)$1));
|
||||||
}
|
}
|
||||||
|
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -3090,7 +3088,9 @@ is usually accessed as follows:
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
<pre>
|
<pre>
|
||||||
Foo *f;
|
Foo *f;
|
||||||
if (SWIG_ConvertPtr($input, (void **) &f, SWIGTYPE_p_Foo, 0) == -1) return NULL;
|
if (!SWIG_IsOK(SWIG_ConvertPtr($input, (void **) &f, SWIGTYPE_p_Foo, 0))) {
|
||||||
|
SWIG_exception_fail(SWIG_TypeError, "in method '$symname', expecting type Foo");
|
||||||
|
}
|
||||||
|
|
||||||
Tcl_Obj *;
|
Tcl_Obj *;
|
||||||
obj = SWIG_NewPointerObj(f, SWIGTYPE_p_Foo, 0);
|
obj = SWIG_NewPointerObj(f, SWIGTYPE_p_Foo, 0);
|
||||||
|
|
@ -3105,7 +3105,9 @@ variable <tt>$1_descriptor</tt>. For example:
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(in) Foo * {
|
%typemap(in) Foo * {
|
||||||
if ((SWIG_ConvertPtr($input,(void **) &$1, $1_descriptor,0)) == -1) return NULL;
|
if (!SWIG_IsOK(SWIG_ConvertPtr($input, (void **) &$1, $1_descriptor, 0))) {
|
||||||
|
SWIG_exception_fail(SWIG_TypeError, "in method '$symname', expecting type Foo");
|
||||||
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -3118,12 +3120,14 @@ For example:
|
||||||
<div class="indent">
|
<div class="indent">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(in) Foo * {
|
%typemap(in) Foo * {
|
||||||
if ((SWIG_ConvertPtr($input,(void **) &$1, $descriptor(Foo *), 0)) == -1) return NULL;
|
if (!SWIG_IsOK(SWIG_ConvertPtr($input, (void **) &$1, $descriptor(Foo *), 0))) {
|
||||||
|
SWIG_exception_fail(SWIG_TypeError, "in method '$symname', expecting type Foo");
|
||||||
|
}
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<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.
|
to use the <tt>load</tt> command instead.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -3211,28 +3215,28 @@ helper functions to access arrays :
|
||||||
|
|
||||||
%inline %{
|
%inline %{
|
||||||
double *new_double(int size) {
|
double *new_double(int size) {
|
||||||
return (double *) malloc(size*sizeof(double));
|
return (double *) malloc(size*sizeof(double));
|
||||||
}
|
}
|
||||||
void delete_double(double *a) {
|
void delete_double(double *a) {
|
||||||
free(a);
|
free(a);
|
||||||
}
|
}
|
||||||
double get_double(double *a, int index) {
|
double get_double(double *a, int index) {
|
||||||
return a[index];
|
return a[index];
|
||||||
}
|
}
|
||||||
void set_double(double *a, int index, double val) {
|
void set_double(double *a, int index, double val) {
|
||||||
a[index] = val;
|
a[index] = val;
|
||||||
}
|
}
|
||||||
int *new_int(int size) {
|
int *new_int(int size) {
|
||||||
return (int *) malloc(size*sizeof(int));
|
return (int *) malloc(size*sizeof(int));
|
||||||
}
|
}
|
||||||
void delete_int(int *a) {
|
void delete_int(int *a) {
|
||||||
free(a);
|
free(a);
|
||||||
}
|
}
|
||||||
int get_int(int *a, int index) {
|
int get_int(int *a, int index) {
|
||||||
return a[index];
|
return a[index];
|
||||||
}
|
}
|
||||||
int set_int(int *a, int index, int val) {
|
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).
|
with an out of bounds array access).
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -3415,7 +3419,7 @@ short, but clever Tcl script can be combined with SWIG to do many
|
||||||
interesting things.
|
interesting things.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
|
||||||
File diff suppressed because it is too large
Load diff
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Varargs">14 Variable Length Arguments</a></H1>
|
<H1><a name="Varargs">16 Variable Length Arguments</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -43,7 +43,7 @@ added in SWIG-1.3.12. Most other wrapper generation tools have
|
||||||
wisely chosen to avoid this issue.
|
wisely chosen to avoid this issue.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Varargs_nn2">14.1 Introduction</a></H2>
|
<H2><a name="Varargs_nn2">16.1 Introduction</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -95,7 +95,7 @@ int execlp(const char *path, const char *arg1, ...);
|
||||||
...
|
...
|
||||||
|
|
||||||
/* Example */
|
/* Example */
|
||||||
execlp("ls","ls","-l",NULL);
|
execlp("ls", "ls", "-l", NULL);
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -126,21 +126,21 @@ example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
List make_list(const char *s, ...) {
|
List make_list(const char *s, ...) {
|
||||||
va_list ap;
|
va_list ap;
|
||||||
List x;
|
List x;
|
||||||
...
|
...
|
||||||
va_start(ap, s);
|
va_start(ap, s);
|
||||||
while (s) {
|
while (s) {
|
||||||
x.append(s);
|
x.append(s);
|
||||||
s = va_arg(ap, const char *);
|
s = va_arg(ap, const char *);
|
||||||
}
|
}
|
||||||
va_end(ap);
|
va_end(ap);
|
||||||
return x;
|
return x;
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H2><a name="Varargs_nn3">14.2 The Problem</a></H2>
|
<H2><a name="Varargs_nn3">16.2 The Problem</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -188,12 +188,12 @@ In contrast, suppose you attempted to make some kind of wrapper around
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
int wrap_printf(const char *fmt, ...) {
|
int wrap_printf(const char *fmt, ...) {
|
||||||
va_list ap;
|
va_list ap;
|
||||||
va_start(ap,fmt);
|
va_start(ap, fmt);
|
||||||
...
|
...
|
||||||
printf(fmt,ap);
|
printf(fmt, ap);
|
||||||
...
|
...
|
||||||
va_end(ap);
|
va_end(ap);
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
are willing to get hands dirty. Keep reading.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -302,7 +302,7 @@ Read on for further solutions.
|
||||||
</p>
|
</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>
|
<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).
|
wrappers to such functions presents special problems (covered shortly).
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -423,8 +423,8 @@ Variable length arguments may be used in typemap specifications. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(in) (...) {
|
%typemap(in) (...) {
|
||||||
// Get variable length arguments (somehow)
|
// Get variable length arguments (somehow)
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
|
|
||||||
%typemap(in) (const char *fmt, ...) {
|
%typemap(in) (const char *fmt, ...) {
|
||||||
|
|
@ -471,15 +471,15 @@ like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
wrap_printf() {
|
wrap_printf() {
|
||||||
char *arg1;
|
char *arg1;
|
||||||
void *arg2;
|
void *arg2;
|
||||||
int result;
|
int result;
|
||||||
|
|
||||||
arg1 = "%s";
|
arg1 = "%s";
|
||||||
arg2 = (void *) PyString_AsString(arg2obj);
|
arg2 = (void *) PyString_AsString(arg2obj);
|
||||||
...
|
...
|
||||||
result = printf(arg1,arg2);
|
result = printf(arg1, arg2);
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -517,7 +517,7 @@ like this:
|
||||||
argc = PyTuple_Size(varargs);
|
argc = PyTuple_Size(varargs);
|
||||||
if (argc > 10) {
|
if (argc > 10) {
|
||||||
PyErr_SetString(PyExc_ValueError, "Too many arguments");
|
PyErr_SetString(PyExc_ValueError, "Too many arguments");
|
||||||
return NULL;
|
SWIG_fail;
|
||||||
}
|
}
|
||||||
for (i = 0; i < argc; i++) {
|
for (i = 0; i < argc; i++) {
|
||||||
PyObject *pyobj = PyTuple_GetItem(varargs, i);
|
PyObject *pyobj = PyTuple_GetItem(varargs, i);
|
||||||
|
|
@ -525,16 +525,19 @@ like this:
|
||||||
%#if PY_VERSION_HEX>=0x03000000
|
%#if PY_VERSION_HEX>=0x03000000
|
||||||
PyObject *pystr;
|
PyObject *pystr;
|
||||||
if (!PyUnicode_Check(pyobj)) {
|
if (!PyUnicode_Check(pyobj)) {
|
||||||
PyErr_SetString(PyExc_ValueError, "Expected a string");
|
PyErr_SetString(PyExc_ValueError, "Expected a string");
|
||||||
return NULL;
|
SWIG_fail;
|
||||||
}
|
}
|
||||||
pystr = PyUnicode_AsUTF8String(pyobj);
|
pystr = PyUnicode_AsUTF8String(pyobj);
|
||||||
|
if (!pystr) {
|
||||||
|
SWIG_fail;
|
||||||
|
}
|
||||||
str = strdup(PyBytes_AsString(pystr));
|
str = strdup(PyBytes_AsString(pystr));
|
||||||
Py_XDECREF(pystr);
|
Py_DECREF(pystr);
|
||||||
%#else
|
%#else
|
||||||
if (!PyString_Check(pyobj)) {
|
if (!PyString_Check(pyobj)) {
|
||||||
PyErr_SetString(PyExc_ValueError, "Expected a string");
|
PyErr_SetString(PyExc_ValueError, "Expected a string");
|
||||||
return NULL;
|
SWIG_fail;
|
||||||
}
|
}
|
||||||
str = PyString_AsString(pyobj);
|
str = PyString_AsString(pyobj);
|
||||||
%#endif
|
%#endif
|
||||||
|
|
@ -590,7 +593,7 @@ really want to elevate your guru status and increase your job
|
||||||
security, continue to the next section.
|
security, continue to the next section.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -626,23 +629,23 @@ example. For example:
|
||||||
of strings */
|
of strings */
|
||||||
|
|
||||||
%typemap(in) (...) {
|
%typemap(in) (...) {
|
||||||
char **argv;
|
char **argv;
|
||||||
int argc;
|
int argc;
|
||||||
int i;
|
int i;
|
||||||
|
|
||||||
argc = PyTuple_Size(varargs);
|
argc = PyTuple_Size(varargs);
|
||||||
argv = (char **) malloc(sizeof(char *)*(argc+1));
|
argv = (char **) malloc(sizeof(char *)*(argc+1));
|
||||||
for (i = 0; i < argc; i++) {
|
for (i = 0; i < argc; i++) {
|
||||||
PyObject *o = PyTuple_GetItem(varargs,i);
|
PyObject *o = PyTuple_GetItem(varargs, i);
|
||||||
if (!PyString_Check(o)) {
|
if (!PyString_Check(o)) {
|
||||||
PyErr_SetString(PyExc_ValueError,"Expected a string");
|
free(argv);
|
||||||
free(argv);
|
PyErr_SetString(PyExc_ValueError, "Expected a string");
|
||||||
return NULL;
|
SWIG_fail;
|
||||||
}
|
}
|
||||||
argv[i] = PyString_AsString(o);
|
argv[i] = PyString_AsString(o);
|
||||||
}
|
}
|
||||||
argv[i] = NULL;
|
argv[i] = NULL;
|
||||||
$1 = (void *) argv;
|
$1 = (void *) argv;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Rewrite the function call, using libffi */
|
/* Rewrite the function call, using libffi */
|
||||||
|
|
@ -676,11 +679,11 @@ example. For example:
|
||||||
&ffi_type_uint, types) == FFI_OK) {
|
&ffi_type_uint, types) == FFI_OK) {
|
||||||
ffi_call(&cif, (void (*)()) execlp, &result, values);
|
ffi_call(&cif, (void (*)()) execlp, &result, values);
|
||||||
} else {
|
} else {
|
||||||
PyErr_SetString(PyExc_RuntimeError, "Whoa!!!!!");
|
|
||||||
free(types);
|
free(types);
|
||||||
free(values);
|
free(values);
|
||||||
free(arg3);
|
free(arg3);
|
||||||
return NULL;
|
PyErr_SetString(PyExc_RuntimeError, "Whoa!!!!!");
|
||||||
|
SWIG_fail;
|
||||||
}
|
}
|
||||||
free(types);
|
free(types);
|
||||||
free(values);
|
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);
|
argc = PyTuple_Size(varargs);
|
||||||
argv = (vtype *) malloc(argc*sizeof(vtype));
|
argv = (vtype *) malloc(argc*sizeof(vtype));
|
||||||
for (i = 0; i < argc; i++) {
|
for (i = 0; i < argc; i++) {
|
||||||
PyObject *o = PyTuple_GetItem(varargs,i);
|
PyObject *o = PyTuple_GetItem(varargs, i);
|
||||||
if (PyInt_Check(o)) {
|
if (PyInt_Check(o)) {
|
||||||
argv[i].type = VT_INT;
|
argv[i].type = VT_INT;
|
||||||
argv[i].val.ivalue = PyInt_AsLong(o);
|
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].type = VT_POINTER;
|
||||||
argv[i].val.pvalue = (void *) PyString_AsString(o);
|
argv[i].val.pvalue = (void *) PyString_AsString(o);
|
||||||
} else {
|
} else {
|
||||||
PyErr_SetString(PyExc_ValueError,"Unsupported argument type");
|
|
||||||
free(argv);
|
free(argv);
|
||||||
|
PyErr_SetString(PyExc_ValueError, "Unsupported argument type");
|
||||||
return NULL;
|
return NULL;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
@ -793,11 +796,11 @@ As a more extreme example of libffi, here is some code that attempts to wrap <tt
|
||||||
&ffi_type_uint, types) == FFI_OK) {
|
&ffi_type_uint, types) == FFI_OK) {
|
||||||
ffi_call(&cif, (void (*)()) printf, &result, values);
|
ffi_call(&cif, (void (*)()) printf, &result, values);
|
||||||
} else {
|
} else {
|
||||||
PyErr_SetString(PyExc_RuntimeError, "Whoa!!!!!");
|
|
||||||
free(types);
|
free(types);
|
||||||
free(values);
|
free(values);
|
||||||
free(args);
|
free(args);
|
||||||
return NULL;
|
PyErr_SetString(PyExc_RuntimeError, "Whoa!!!!!");
|
||||||
|
SWIG_fail;
|
||||||
}
|
}
|
||||||
free(types);
|
free(types);
|
||||||
free(values);
|
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.
|
values. Please consult the chapter on each language module for more details.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -896,7 +899,7 @@ int my_vprintf(const char *fmt, ...) {
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H2><a name="Varargs_nn9">14.8 C++ Issues</a></H2>
|
<H2><a name="Varargs_nn9">16.8 C++ Issues</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -912,12 +915,12 @@ and it fully supports classes much like the <tt>%rename</tt> directive. For exa
|
||||||
|
|
||||||
class Foo {
|
class Foo {
|
||||||
public:
|
public:
|
||||||
virtual void bar(char *arg, ...); // gets varargs above
|
virtual void bar(char *arg, ...); // gets varargs above
|
||||||
};
|
};
|
||||||
|
|
||||||
class Spam: public Foo {
|
class Spam: public Foo {
|
||||||
public:
|
public:
|
||||||
virtual void bar(char *arg, ...); // gets varargs above
|
virtual void bar(char *arg, ...); // gets varargs above
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -952,9 +955,9 @@ are placed in <tt>arg2</tt>, <tt>arg3</tt>, and so forth. For example:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%feature("action") Foo::bar {
|
%feature("action") Foo::bar {
|
||||||
...
|
...
|
||||||
result = arg1->bar(arg2, arg3, etc.);
|
result = arg1->bar(arg2, arg3, etc.);
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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.
|
fully general wrapper to a varargs C++ member function.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Varargs_nn10">14.9 Discussion</a></H2>
|
<H2><a name="Varargs_nn10">16.9 Discussion</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -987,10 +990,10 @@ you might structure your interface like this:
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(const char *fmt, ...) {
|
%typemap(const char *fmt, ...) {
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
%feature("action") traceprintf {
|
%feature("action") traceprintf {
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Include some header file with traceprintf in it */
|
/* Include some header file with traceprintf in it */
|
||||||
|
|
@ -1011,7 +1014,7 @@ to control this:
|
||||||
<pre>
|
<pre>
|
||||||
#ifdef USE_LIBFFI
|
#ifdef USE_LIBFFI
|
||||||
%feature("action") printf {
|
%feature("action") printf {
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
#endif
|
#endif
|
||||||
#ifdef USE_OTHERFFI
|
#ifdef USE_OTHERFFI
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Warnings">15 Warning Messages</a></H1>
|
<H1><a name="Warnings">18 Warning Messages</a></H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -25,7 +25,8 @@
|
||||||
<li><a href="#Warnings_nn11">Preprocessor (200-299)</a>
|
<li><a href="#Warnings_nn11">Preprocessor (200-299)</a>
|
||||||
<li><a href="#Warnings_nn12">C/C++ Parser (300-399)</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_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_nn15">Language module specific (700-899) </a>
|
||||||
<li><a href="#Warnings_nn16">User defined (900-999)</a>
|
<li><a href="#Warnings_nn16">User defined (900-999)</a>
|
||||||
</ul>
|
</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>
|
<p>
|
||||||
|
|
@ -56,7 +57,7 @@ where the generated wrapper code will probably compile, but it may not
|
||||||
work like you expect.
|
work like you expect.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -112,16 +113,16 @@ suppress a warning for a method in a class hierarchy, you could do this:
|
||||||
%warnfilter(501) Object::foo;
|
%warnfilter(501) Object::foo;
|
||||||
class Object {
|
class Object {
|
||||||
public:
|
public:
|
||||||
int foo(int);
|
int foo(int);
|
||||||
int foo(double); // Silently ignored
|
int foo(double); // Silently ignored
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
|
|
||||||
class Derived : public Object {
|
class Derived : public Object {
|
||||||
public:
|
public:
|
||||||
int foo(int);
|
int foo(int);
|
||||||
int foo(double); // Silently ignored
|
int foo(double); // Silently ignored
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -136,7 +137,7 @@ Warnings can be suppressed for an entire class by supplying a class name. For e
|
||||||
|
|
||||||
class Object {
|
class Object {
|
||||||
public:
|
public:
|
||||||
... // All 501 warnings ignored in class
|
... // All 501 warnings ignored in class
|
||||||
};
|
};
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -148,7 +149,7 @@ your interface. Ignore the warning messages at your own peril.
|
||||||
</p>
|
</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>
|
<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.
|
or the <tt>-w</tt> option.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -259,7 +260,7 @@ Warning messages can be associated with typemaps using the
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%typemap(in, warning="901:You are really going to regret this usage of $1_type $1_name") blah * {
|
%typemap(in, warning="901:You are really going to regret this usage of $1_type $1_name") blah * {
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
@ -275,7 +276,7 @@ example.i:24: Warning 901: You are really going to regret this usage of blah * s
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</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>
|
<p>
|
||||||
|
|
@ -310,7 +311,7 @@ or
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H2><a name="Warnings_nn6">15.6 Commentary</a></H2>
|
<H2><a name="Warnings_nn6">18.6 Commentary</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -327,7 +328,7 @@ no obvious recovery. There is no mechanism for suppressing error
|
||||||
messages.
|
messages.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -336,7 +337,7 @@ option. This will cause SWIG to exit with a non successful exit code if a
|
||||||
warning is encountered.
|
warning is encountered.
|
||||||
</p>
|
</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>
|
<p>
|
||||||
|
|
@ -355,10 +356,10 @@ $ swig -python -Fmicrosoft example.i
|
||||||
example.i(4) : Syntax error in input(1).
|
example.i(4) : Syntax error in input(1).
|
||||||
</pre></div>
|
</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>
|
<ul>
|
||||||
|
|
@ -386,7 +387,7 @@ example.i(4) : Syntax error in input(1).
|
||||||
<li>126. The 'nestedworkaround' feature is deprecated.
|
<li>126. The 'nestedworkaround' feature is deprecated.
|
||||||
</ul>
|
</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>
|
<ul>
|
||||||
|
|
@ -398,7 +399,7 @@ example.i(4) : Syntax error in input(1).
|
||||||
<li>206. Unexpected tokens after #<em>directive</em> directive.
|
<li>206. Unexpected tokens after #<em>directive</em> directive.
|
||||||
</ul>
|
</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>
|
<ul>
|
||||||
|
|
@ -475,7 +476,7 @@ example.i(4) : Syntax error in input(1).
|
||||||
<li>395. operator delete[] ignored.
|
<li>395. operator delete[] ignored.
|
||||||
</ul>
|
</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>
|
<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>
|
<ul>
|
||||||
|
|
@ -533,9 +534,22 @@ example.i(4) : Syntax error in input(1).
|
||||||
<li>521. Illegal destructor name <em>name</em>. Ignored.
|
<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>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>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>
|
</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>
|
<ul>
|
||||||
|
|
@ -586,14 +600,14 @@ example.i(4) : Syntax error in input(1).
|
||||||
<li>871. Unrecognized pragma <em>pragma</em>. (Php).
|
<li>871. Unrecognized pragma <em>pragma</em>. (Php).
|
||||||
</ul>
|
</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>
|
<p>
|
||||||
These numbers can be used by your own application.
|
These numbers can be used by your own application.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H2><a name="Warnings_nn17">15.10 History</a></H2>
|
<H2><a name="Warnings_nn17">18.10 History</a></H2>
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -68,7 +68,7 @@ SWIG does not come with the usual Windows type installation program, however it
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<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>.
|
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>
|
</p>
|
||||||
|
|
||||||
|
|
@ -149,7 +149,7 @@ PERL5_LIB: D:\nsPerl5.004_04\lib\CORE\perl.lib<br>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>PYTHON_INCLUDE</tt></b> : Set this to the directory that contains Python.h<br>
|
<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>
|
Example using Python 2.1.1:<br>
|
||||||
<tt>
|
<tt>
|
||||||
PYTHON_INCLUDE: D:\python21\include<br>
|
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>
|
<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>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Windows_swig_exe">3.3.1 Building swig.exe on Windows</a></H3>
|
<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>
|
<ol>
|
||||||
<li>
|
<li>
|
||||||
Download the following packages from the <a href="http://www.mingw.org/download.shtml">MinGW download page</a>
|
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
|
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.
|
release list and some are in the Snapshot or Previous release list.
|
||||||
<ul>
|
<ul>
|
||||||
|
|
|
||||||
|
|
@ -5,6 +5,8 @@ Scripting.html
|
||||||
SWIG.html
|
SWIG.html
|
||||||
SWIGPlus.html
|
SWIGPlus.html
|
||||||
CPlusPlus11.html
|
CPlusPlus11.html
|
||||||
|
CPlusPlus14.html
|
||||||
|
CPlusPlus17.html
|
||||||
Preprocessor.html
|
Preprocessor.html
|
||||||
Library.html
|
Library.html
|
||||||
Arguments.html
|
Arguments.html
|
||||||
|
|
@ -12,31 +14,27 @@ Typemaps.html
|
||||||
Customization.html
|
Customization.html
|
||||||
Contract.html
|
Contract.html
|
||||||
Varargs.html
|
Varargs.html
|
||||||
|
Doxygen.html
|
||||||
Warnings.html
|
Warnings.html
|
||||||
Modules.html
|
Modules.html
|
||||||
CCache.html
|
CCache.html
|
||||||
Allegrocl.html
|
|
||||||
Android.html
|
Android.html
|
||||||
C.html
|
C.html
|
||||||
CSharp.html
|
CSharp.html
|
||||||
Chicken.html
|
|
||||||
D.html
|
D.html
|
||||||
Go.html
|
Go.html
|
||||||
Guile.html
|
Guile.html
|
||||||
Java.html
|
Java.html
|
||||||
Javascript.html
|
Javascript.html
|
||||||
Lisp.html
|
|
||||||
Lua.html
|
Lua.html
|
||||||
Modula3.html
|
|
||||||
Mzscheme.html
|
|
||||||
Ocaml.html
|
|
||||||
Octave.html
|
Octave.html
|
||||||
Perl5.html
|
Perl5.html
|
||||||
Php.html
|
Php.html
|
||||||
Pike.html
|
|
||||||
Python.html
|
Python.html
|
||||||
R.html
|
R.html
|
||||||
Ruby.html
|
Ruby.html
|
||||||
Scilab.html
|
Scilab.html
|
||||||
Tcl.html
|
Tcl.html
|
||||||
|
Mzscheme.html
|
||||||
|
Ocaml.html
|
||||||
Extending.html
|
Extending.html
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,11 @@
|
||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||||
<html>
|
<html>
|
||||||
<head>
|
<head>
|
||||||
<title>SWIG-3.0 Documentation</title>
|
<title>SWIG-4.0 Documentation</title>
|
||||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||||
</head>
|
</head>
|
||||||
<body bgcolor="#ffffff">
|
<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.
|
The SWIG documentation is available in one of the following formats.
|
||||||
<ul>
|
<ul>
|
||||||
|
|
|
||||||
|
|
@ -44,6 +44,8 @@ def getheadingname(m):
|
||||||
def getheadingtext(m, s):
|
def getheadingtext(m, s):
|
||||||
prevheadingtext_newstyle = m.group(2)
|
prevheadingtext_newstyle = m.group(2)
|
||||||
prevheadingtext_oldstyle = m.group(3)
|
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:
|
if len(prevheadingtext_oldstyle) == 0 and len(prevheadingtext_newstyle) == 0:
|
||||||
raise RuntimeError("No heading text in line:\n%s" % s)
|
raise RuntimeError("No heading text in line:\n%s" % s)
|
||||||
if len(prevheadingtext_oldstyle) > 0 and len(prevheadingtext_newstyle) > 0:
|
if len(prevheadingtext_oldstyle) > 0 and len(prevheadingtext_newstyle) > 0:
|
||||||
|
|
@ -72,7 +74,7 @@ name = ""
|
||||||
|
|
||||||
# Regexs for <h1>,... <h5> sections
|
# 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)
|
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)
|
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)
|
h4 = re.compile(r".*?<H4>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H4>", re.IGNORECASE)
|
||||||
|
|
|
||||||
|
|
@ -282,7 +282,7 @@ perl5_static_cpp: $(SRCDIR_SRCS)
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
|
|
||||||
perl5_run:
|
perl5_run:
|
||||||
$(RUNTOOL) $(PERL) $(PERL5_SCRIPT) $(RUNPIPE)
|
$(RUNTOOL) $(PERL) -I. $(PERL5_SCRIPT) $(RUNPIPE)
|
||||||
|
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
# Version display
|
# Version display
|
||||||
|
|
@ -334,8 +334,8 @@ else
|
||||||
SWIGOPTPY3 = -py3
|
SWIGOPTPY3 = -py3
|
||||||
endif
|
endif
|
||||||
|
|
||||||
PEP8 = @PEP8@
|
PYCODESTYLE = @PYCODESTYLE@
|
||||||
PEP8_FLAGS = --ignore=E402,E501,E30,W291,W391
|
PYCODESTYLE_FLAGS = --ignore=E252,E30,E402,E501,E731,W291,W391
|
||||||
|
|
||||||
# ----------------------------------------------------------------
|
# ----------------------------------------------------------------
|
||||||
# Build a C dynamically loadable module
|
# Build a C dynamically loadable module
|
||||||
|
|
@ -386,11 +386,11 @@ else
|
||||||
PYSCRIPT = $(RUNME)3.py
|
PYSCRIPT = $(RUNME)3.py
|
||||||
endif
|
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)
|
python_run: $(PYSCRIPT)
|
||||||
ifneq (,$(PEP8))
|
ifneq (,$(PYCODESTYLE))
|
||||||
$(COMPILETOOL) $(PEP8) $(PEP8_FLAGS) $(PYSCRIPT)
|
$(COMPILETOOL) $(PYCODESTYLE) $(PYCODESTYLE_FLAGS) $(PYSCRIPT)
|
||||||
endif
|
endif
|
||||||
env PYTHONPATH=$$PWD $(RUNTOOL) $(PYTHON) $(PYSCRIPT) $(RUNPIPE)
|
env PYTHONPATH=$$PWD $(RUNTOOL) $(PYTHON) $(PYSCRIPT) $(RUNPIPE)
|
||||||
|
|
||||||
|
|
@ -463,7 +463,7 @@ octave_cpp: $(SRCDIR_SRCS)
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
|
|
||||||
octave_run:
|
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
|
# Version display
|
||||||
|
|
@ -671,7 +671,7 @@ javascript_build: $(SRCDIR_SRCS)
|
||||||
javascript_build_cpp: $(SRCDIR_SRCS)
|
javascript_build_cpp: $(SRCDIR_SRCS)
|
||||||
ifeq (node,$(JSENGINE))
|
ifeq (node,$(JSENGINE))
|
||||||
sed -e 's|$$srcdir|./$(SRCDIR)|g' $(SRCDIR)binding.gyp.in > binding.gyp
|
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
|
else
|
||||||
$(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES) $(JSINCLUDES)
|
$(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)
|
$(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 -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
|
||||||
rm -rf obj
|
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 ######
|
##### MZSCHEME ######
|
||||||
##################################################################
|
##################################################################
|
||||||
|
|
@ -852,7 +813,7 @@ MZSCHEME = mzscheme
|
||||||
MZC = @MZC@
|
MZC = @MZC@
|
||||||
MZDYNOBJ = @MZDYNOBJ@
|
MZDYNOBJ = @MZDYNOBJ@
|
||||||
MZSCHEME_SO = @MZSCHEME_SO@
|
MZSCHEME_SO = @MZSCHEME_SO@
|
||||||
MZSCHEME_SCRIPT = $(RUNME).scm
|
MZSCHEME_SCRIPT = $(SRCDIR)$(RUNME).scm
|
||||||
|
|
||||||
# ----------------------------------------------------------------
|
# ----------------------------------------------------------------
|
||||||
# Build a C/C++ dynamically loadable module
|
# Build a C/C++ dynamically loadable module
|
||||||
|
|
@ -860,12 +821,12 @@ MZSCHEME_SCRIPT = $(RUNME).scm
|
||||||
|
|
||||||
mzscheme: $(SRCDIR_SRCS)
|
mzscheme: $(SRCDIR_SRCS)
|
||||||
$(SWIG) -mzscheme $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
$(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)
|
$(COMPILETOOL) $(MZC) --ld $(TARGET)$(MZSCHEME_SO) $(OBJS) $(IOBJS)
|
||||||
|
|
||||||
mzscheme_cpp: $(SRCDIR_SRCS)
|
mzscheme_cpp: $(SRCDIR_SRCS)
|
||||||
$(SWIG) -mzscheme -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
$(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)
|
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o $(LIBPREFIX)$(TARGET)$(MZSCHEME_SO) $(OBJS) $(IOBJS) $(MZDYNOBJ) $(CPP_DLLIBS)
|
||||||
|
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
|
|
@ -896,135 +857,88 @@ mzscheme_clean:
|
||||||
##### Ocaml #####
|
##### Ocaml #####
|
||||||
##################################################################
|
##################################################################
|
||||||
|
|
||||||
OCC=@OCAMLC@
|
OCC=$(COMPILETOOL) @OCAMLC@
|
||||||
OCAMLDLGEN=@OCAMLDLGEN@
|
OCC_WITH_PP=env TMPDIR=./localtmp $(OCC)
|
||||||
OCAMLFIND=@OCAMLFIND@
|
# 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)
|
||||||
OCAMLMKTOP=@OCAMLMKTOP@ $(SWIGWHERE)
|
OCAMLDLGEN=$(COMPILETOOL) @OCAMLDLGEN@
|
||||||
|
OCAMLFIND=$(COMPILETOOL) @OCAMLFIND@
|
||||||
|
OCAMLMKTOP=$(COMPILETOOL) @OCAMLMKTOP@
|
||||||
NOLINK ?= false
|
NOLINK ?= false
|
||||||
OCAMLPP= -pp "camlp4o ./swigp4.cmo"
|
OCAMLPP= -pp "camlp4o ./swigp4.cmo"
|
||||||
OCAMLP4WHERE=`$(COMPILETOOL) @CAMLP4@ -where`
|
OCAMLP4WHERE=`$(COMPILETOOL) @CAMLP4@ -where`
|
||||||
OCAMLCORE=\
|
|
||||||
rm -rf swig.mli swig.ml swigp4.ml && \
|
ocaml_core:
|
||||||
$(SWIG) -ocaml -co swig.mli 2>/dev/null && \
|
mkdir -p ./localtmp
|
||||||
$(SWIG) -ocaml -co swig.ml 2>/dev/null && \
|
$(SWIG) -ocaml -co swig.mli 2>/dev/null
|
||||||
$(SWIG) -ocaml -co swigp4.ml 2>/dev/null && \
|
$(SWIG) -ocaml -co swig.ml 2>/dev/null
|
||||||
$(OCC) -c swig.mli && \
|
$(SWIG) -ocaml -co swigp4.ml 2>/dev/null
|
||||||
$(OCC) -c swig.ml && \
|
$(OCC) -c swig.mli
|
||||||
$(OCC) -I $(OCAMLP4WHERE) -pp "camlp4o pa_extend.cmo q_MLast.cmo" \
|
$(OCC) -c swig.ml
|
||||||
-c swigp4.ml
|
$(OCC_WITH_PP) -I $(OCAMLP4WHERE) -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
|
||||||
|
|
||||||
ocaml_static: $(SRCDIR_SRCS)
|
ocaml_static: $(SRCDIR_SRCS)
|
||||||
$(OCAMLCORE)
|
|
||||||
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
||||||
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
|
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
|
||||||
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
||||||
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
|
$(OCC) -w -U -g -c $(INTERFACE:%.i=%.ml)
|
||||||
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
|
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
|
||||||
$(OCC) $(OCAMLPP) -c $(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)"
|
||||||
$(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)"
|
|
||||||
|
|
||||||
ocaml_dynamic: $(SRCDIR_SRCS)
|
ocaml_dynamic: $(SRCDIR_SRCS)
|
||||||
$(OCAMLCORE)
|
|
||||||
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
||||||
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
|
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
|
||||||
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) $(CCSHARED) -o $(INTERFACE:%.i=%@SO@) \
|
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) $(CCSHARED) -o $(INTERFACE:%.i=%@SO@) $(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) $(LIBS)
|
||||||
$(INTERFACE:%.i=%_wrap.@OBJEXT@) $(OBJS) $(LIBS)
|
$(OCAMLDLGEN) $(INTERFACE:%.i=%.ml) $(INTERFACE:%.i=%@SO@) > $(INTERFACE:%.i=%_dynamic.ml)
|
||||||
$(OCAMLDLGEN) $(INTERFACE:%.i=%.ml) $(INTERFACE:%.i=%@SO@) > \
|
|
||||||
$(INTERFACE:%.i=%_dynamic.ml)
|
|
||||||
mv $(INTERFACE:%.i=%_dynamic.ml) $(INTERFACE:%.i=%.ml)
|
mv $(INTERFACE:%.i=%_dynamic.ml) $(INTERFACE:%.i=%.ml)
|
||||||
rm $(INTERFACE:%.i=%.mli)
|
rm $(INTERFACE:%.i=%.mli)
|
||||||
$(OCAMLFIND) $(OCC) -g -c -package dl $(INTERFACE:%.i=%.ml)
|
$(OCAMLFIND) $(OCC) -g -c -package dl $(INTERFACE:%.i=%.ml)
|
||||||
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
|
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
|
||||||
$(OCC) $(OCAMLPP) -c $(PROGFILE)
|
$(NOLINK) || $(OCAMLFIND) $(OCC) -g -ccopt -g -cclib -g -custom -o $(RUNME) swig.cmo -package dl -linkpkg $(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo)
|
||||||
$(NOLINK) || $(OCAMLFIND) \
|
|
||||||
$(OCC) -g -ccopt -g -cclib -g -custom -o $(TARGET) \
|
|
||||||
swig.cmo \
|
|
||||||
-package dl -linkpkg \
|
|
||||||
$(INTERFACE:%.i=%.cmo) $(PROGFILE:%.ml=%.cmo)
|
|
||||||
|
|
||||||
ocaml_static_toplevel: $(SRCDIR_SRCS)
|
ocaml_static_toplevel: $(SRCDIR_SRCS)
|
||||||
$(OCAMLCORE)
|
|
||||||
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
$(SWIG) -ocaml $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
||||||
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
|
$(OCC) -g -c -ccopt -g -ccopt "$(INCLUDES)" $(ISRCS) $(SRCDIR_SRCS)
|
||||||
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
||||||
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
|
$(OCC) -w -U -g -c $(INTERFACE:%.i=%.ml)
|
||||||
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
|
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
|
||||||
$(OCC) $(OCAMLPP) -c $(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)
|
||||||
$(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)"
|
|
||||||
|
|
||||||
ocaml_static_cpp: $(SRCDIR_SRCS)
|
ocaml_static_cpp: $(SRCDIR_SRCS)
|
||||||
$(OCAMLCORE)
|
|
||||||
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
||||||
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
||||||
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
$(OCC) -cc '$(CXX) $(CPPFLAGS)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" $(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
|
||||||
$(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
|
|
||||||
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
||||||
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
|
$(OCC) -w -U -g -c $(INTERFACE:%.i=%.ml)
|
||||||
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
|
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
|
||||||
$(OCC) $(OCAMLPP) -c $(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)'
|
||||||
$(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'
|
|
||||||
|
|
||||||
ocaml_static_cpp_toplevel: $(SRCDIR_SRCS)
|
ocaml_static_cpp_toplevel: $(SRCDIR_SRCS)
|
||||||
$(OCAMLCORE)
|
|
||||||
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
||||||
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
||||||
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
$(OCC) -cc '$(CXX) $(CPPFLAGS)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" $(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
|
||||||
$(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS)
|
|
||||||
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
$(OCC) -g -c $(INTERFACE:%.i=%.mli)
|
||||||
$(OCC) -g -c $(INTERFACE:%.i=%.ml)
|
$(OCC) -w -U -g -c $(INTERFACE:%.i=%.ml)
|
||||||
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
|
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
|
||||||
$(OCC) $(OCAMLPP) -c $(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)
|
||||||
$(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'
|
|
||||||
|
|
||||||
ocaml_dynamic_cpp: $(SRCDIR_SRCS)
|
ocaml_dynamic_cpp: $(SRCDIR_SRCS)
|
||||||
$(OCAMLCORE)
|
|
||||||
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
$(SWIG) -ocaml -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
||||||
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
cp $(ICXXSRCS) $(ICXXSRCS:%.cxx=%.c)
|
||||||
$(OCC) -cc '$(CXX) -Wno-write-strings' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" \
|
$(OCC) -cc '$(CXX) $(CPPFLAGS)' -g -c -ccopt -g -ccopt "-xc++ $(INCLUDES)" $(ICXXSRCS:%.cxx=%.c) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) -ccopt -fPIC
|
||||||
$(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)
|
||||||
$(CXXSHARED) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o $(INTERFACE:%.i=%@SO@) \
|
$(OCAMLDLGEN) $(INTERFACE:%.i=%.ml) $(INTERFACE:%.i=%@SO@) > $(INTERFACE:%.i=%_dynamic.ml)
|
||||||
$(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)
|
mv $(INTERFACE:%.i=%_dynamic.ml) $(INTERFACE:%.i=%.ml)
|
||||||
rm $(INTERFACE:%.i=%.mli)
|
rm $(INTERFACE:%.i=%.mli)
|
||||||
$(OCAMLFIND) $(OCC) -g -c -package dl $(INTERFACE:%.i=%.ml)
|
$(OCAMLFIND) $(OCC) -g -c -package dl $(INTERFACE:%.i=%.ml)
|
||||||
test -z "$(PROGFILE)" || test -f "$(PROGFILE)" && \
|
test -z "$(PROGFILE)" || $(OCC_WITH_PP) -o $(PROGFILE:%.ml=%) $(OCAMLPP) -c $(SRCDIR)$(PROGFILE)
|
||||||
$(OCC) $(OCAMLPP) -c $(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)'
|
||||||
$(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'
|
|
||||||
|
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
# Run ocaml example
|
# Run ocaml example
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
|
|
||||||
ocaml_run:
|
ocaml_run:
|
||||||
$(RUNTOOL) ./$(TARGET) $(RUNPIPE)
|
$(RUNTOOL) ./$(RUNME) $(RUNPIPE)
|
||||||
|
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
# Version display
|
# Version display
|
||||||
|
|
@ -1038,9 +952,10 @@ ocaml_version:
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
|
|
||||||
ocaml_clean:
|
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 core @EXTRA_CLEAN@
|
||||||
rm -f *.@OBJEXT@ *@SO@
|
rm -f *.@OBJEXT@ *@SO@
|
||||||
|
rm -rf ./localtmp
|
||||||
|
|
||||||
##################################################################
|
##################################################################
|
||||||
##### RUBY ######
|
##### RUBY ######
|
||||||
|
|
@ -1116,7 +1031,7 @@ ruby_clean:
|
||||||
rm -f *.@OBJEXT@ *$(RUBY_SO)
|
rm -f *.@OBJEXT@ *$(RUBY_SO)
|
||||||
|
|
||||||
##################################################################
|
##################################################################
|
||||||
##### PHP ######
|
##### PHP7 ######
|
||||||
##################################################################
|
##################################################################
|
||||||
|
|
||||||
PHP = @PHP@
|
PHP = @PHP@
|
||||||
|
|
@ -1129,7 +1044,7 @@ PHP_SCRIPT = $(SRCDIR)$(RUNME).php
|
||||||
# -------------------------------------------------------------------
|
# -------------------------------------------------------------------
|
||||||
|
|
||||||
php: $(SRCDIR_SRCS)
|
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)
|
$(CC) -c $(CCSHARED) $(CPPFLAGS) $(CFLAGS) $(SRCDIR_SRCS) $(ISRCS) $(INCLUDES) $(PHP_INCLUDE)
|
||||||
$(LDSHARED) $(CFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(PHP_SO)
|
$(LDSHARED) $(CFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(PHP_SO)
|
||||||
|
|
||||||
|
|
@ -1138,7 +1053,7 @@ php: $(SRCDIR_SRCS)
|
||||||
# --------------------------------------------------------------------
|
# --------------------------------------------------------------------
|
||||||
|
|
||||||
php_cpp: $(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)
|
$(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)
|
$(CXXSHARED) $(CXXFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(PHP_SO)
|
||||||
|
|
||||||
|
|
@ -1147,7 +1062,7 @@ php_cpp: $(SRCDIR_SRCS)
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
|
|
||||||
php_run:
|
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
|
# Version display
|
||||||
|
|
@ -1165,194 +1080,6 @@ php_clean:
|
||||||
rm -f core @EXTRA_CLEAN@
|
rm -f core @EXTRA_CLEAN@
|
||||||
rm -f *.@OBJEXT@ *$(PHP_SO)
|
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 ######
|
##### CSHARP ######
|
||||||
##################################################################
|
##################################################################
|
||||||
|
|
@ -1367,7 +1094,7 @@ CSHARPCFLAGS = @CSHARPCFLAGS@
|
||||||
CSHARPFLAGS =
|
CSHARPFLAGS =
|
||||||
CSHARPOPTIONS =
|
CSHARPOPTIONS =
|
||||||
CSHARPSO = @CSHARPSO@
|
CSHARPSO = @CSHARPSO@
|
||||||
CSHARP_RUNME = $(CSHARPCILINTERPRETER) $(CSHARPCILINTERPRETER_FLAGS) ./$(RUNME).exe
|
CSHARP_RUNME = ./$(RUNME).exe
|
||||||
|
|
||||||
# ----------------------------------------------------------------
|
# ----------------------------------------------------------------
|
||||||
# Build a CSharp dynamically loadable module (C)
|
# Build a CSharp dynamically loadable module (C)
|
||||||
|
|
@ -1405,7 +1132,7 @@ csharp_compile: $(SRCDIR_SRCS)
|
||||||
# -----------------------------------------------------------------
|
# -----------------------------------------------------------------
|
||||||
|
|
||||||
csharp_run:
|
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
|
# Version display
|
||||||
|
|
@ -1547,42 +1274,6 @@ allegrocl_clean:
|
||||||
rm -f core @EXTRA_CLEAN@
|
rm -f core @EXTRA_CLEAN@
|
||||||
rm -f *.@OBJEXT@ *@SO@
|
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 ######
|
##### CFFI ######
|
||||||
##################################################################
|
##################################################################
|
||||||
|
|
@ -1623,46 +1314,6 @@ cffi_clean:
|
||||||
rm -f core @EXTRA_CLEAN@
|
rm -f core @EXTRA_CLEAN@
|
||||||
rm -f *.@OBJEXT@ *@SO@
|
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 ######
|
##### R ######
|
||||||
##################################################################
|
##################################################################
|
||||||
|
|
@ -1687,7 +1338,7 @@ r: $(SRCDIR_SRCS)
|
||||||
ifneq ($(SRCDIR_SRCS),)
|
ifneq ($(SRCDIR_SRCS),)
|
||||||
$(CC) -g -c $(CPPFLAGS) $(CFLAGS) $(R_CFLAGS) $(SRCDIR_SRCS) $(INCLUDES)
|
$(CC) -g -c $(CPPFLAGS) $(CFLAGS) $(R_CFLAGS) $(SRCDIR_SRCS) $(INCLUDES)
|
||||||
endif
|
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++)
|
# Build a R dynamically loadable module (C++)
|
||||||
|
|
@ -1697,7 +1348,7 @@ r_cpp: $(SRCDIR_CXXSRCS)
|
||||||
ifneq ($(SRCDIR_CXXSRCS),)
|
ifneq ($(SRCDIR_CXXSRCS),)
|
||||||
$(CXX) -g -c $(CPPFLAGS) $(CXXFLAGS) $(R_CFLAGS) $(SRCDIR_CXXSRCS) $(INCLUDES)
|
$(CXX) -g -c $(CPPFLAGS) $(CXXFLAGS) $(R_CFLAGS) $(SRCDIR_CXXSRCS) $(INCLUDES)
|
||||||
endif
|
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
|
# Run R example
|
||||||
|
|
@ -1864,7 +1515,8 @@ GOPACK = `if $(GO1) ; then echo go tool pack; else echo gopack; fi`
|
||||||
|
|
||||||
GOPACKAGE = $(notdir $(INTERFACE:.i=.a))
|
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`
|
GOOBJEXT = `if $(GO15); then echo o; else echo $(GOC:c=); fi`
|
||||||
GOGCOBJS = $(GOSRCS:.go=.$(GOOBJEXT))
|
GOGCOBJS = $(GOSRCS:.go=.$(GOOBJEXT))
|
||||||
|
|
@ -1874,8 +1526,18 @@ GOGCCOBJS = $(GOSRCS:.go=.@OBJEXT@)
|
||||||
# Build a Go module (C)
|
# 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)
|
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 \
|
if $(GO12) || $(GO13) || $(GO15) || $(GOGCC); then \
|
||||||
$(CC) -g -c $(CPPFLAGS) $(CFLAGS) $(SRCDIR_SRCS) $(ISRCS) $(INCLUDES); \
|
$(CC) -g -c $(CPPFLAGS) $(CFLAGS) $(SRCDIR_SRCS) $(ISRCS) $(INCLUDES); \
|
||||||
else \
|
else \
|
||||||
|
|
@ -1910,11 +1572,12 @@ go_nocgo: $(SRCDIR_SRCS)
|
||||||
fi; \
|
fi; \
|
||||||
fi
|
fi
|
||||||
|
|
||||||
go: $(SRCDIR_SRCS)
|
go: $(SRCDIR_SRCS) $(GOPATHPARENTDIR)/go.mod
|
||||||
$(SWIG) -go -cgo $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
$(SWIG) -go -import-prefix swigtests $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
|
||||||
@mkdir gopath 2>/dev/null || true
|
@mkdir gopath 2>/dev/null || true
|
||||||
@mkdir gopath/src 2>/dev/null || true
|
@mkdir gopath/$(GOMOD) 2>/dev/null || true
|
||||||
@mkdir gopath/src/$(INTERFACE:.i=) 2>/dev/null || true
|
@mkdir gopath/$(GOMOD)/src 2>/dev/null || true
|
||||||
|
@mkdir $(GOPATHDIR) 2>/dev/null || true
|
||||||
rm -f $(GOPATHDIR)/*
|
rm -f $(GOPATHDIR)/*
|
||||||
cp $(ISRCS) $(GOPATHDIR)/
|
cp $(ISRCS) $(GOPATHDIR)/
|
||||||
if test -f $(IWRAP:.i=.h); then \
|
if test -f $(IWRAP:.i=.h); then \
|
||||||
|
|
@ -1924,7 +1587,7 @@ go: $(SRCDIR_SRCS)
|
||||||
cp $(SRCDIR_SRCS) $(GOPATHDIR)/; \
|
cp $(SRCDIR_SRCS) $(GOPATHDIR)/; \
|
||||||
fi
|
fi
|
||||||
cp $(GOSRCS) $(GOPATHDIR)/
|
cp $(GOSRCS) $(GOPATHDIR)/
|
||||||
GOPATH=`pwd`/gopath; \
|
GOPATH=`pwd`/gopath/$(GOMOD); \
|
||||||
export GOPATH; \
|
export GOPATH; \
|
||||||
CGO_CPPFLAGS="$(CPPFLAGS) $(INCLUDES) -I `cd $(SRCDIR) && pwd` -I `pwd`"; \
|
CGO_CPPFLAGS="$(CPPFLAGS) $(INCLUDES) -I `cd $(SRCDIR) && pwd` -I `pwd`"; \
|
||||||
export CGO_CPPFLAGS; \
|
export CGO_CPPFLAGS; \
|
||||||
|
|
@ -1933,17 +1596,16 @@ go: $(SRCDIR_SRCS)
|
||||||
CGO_LDFLAGS="$(LDFLAGS) -lm"; \
|
CGO_LDFLAGS="$(LDFLAGS) -lm"; \
|
||||||
export CGO_LDFLAGS; \
|
export CGO_LDFLAGS; \
|
||||||
(cd $(GOPATHDIR)/ && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o $(GOPACKAGE))
|
(cd $(GOPATHDIR)/ && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o $(GOPACKAGE))
|
||||||
cp $(GOPATHDIR)/$(GOPACKAGE) $(dir $(INTERFACE))/$(GOPACKAGE)
|
|
||||||
if $(GOGCC); then \
|
if $(GOGCC); then \
|
||||||
cp $(dir $(INTERFACE))/$(GOPACKAGE) $(dir $(INTERFACE))/$(GOPACKAGE:.a=.gox); \
|
cp $(GOPATHDIR)/$(GOPACKAGE) $(GOPATHDIR)/$(GOPACKAGE:.a=.gox); \
|
||||||
fi
|
fi
|
||||||
if test -f $(SRCDIR)$(RUNME).go; then \
|
if test -f $(SRCDIR)$(RUNME).go; then \
|
||||||
if $(GOGCC) ; then \
|
if $(GOGCC) ; then \
|
||||||
$(COMPILETOOL) $(GCCGO) -c -g $(SRCDIR)$(RUNME).go; \
|
$(COMPILETOOL) $(GCCGO) -c -g -I $(GOPATHDIR) $(SRCDIR)$(RUNME).go; \
|
||||||
$(COMPILETOOL) $(GCCGO) -o $(RUNME) $(RUNME).@OBJEXT@ $(dir $(INTERFACE))/$(GOPACKAGE); \
|
$(COMPILETOOL) $(GCCGO) -o $(RUNME) $(RUNME).@OBJEXT@ $(GOPATHDIR)/$(GOPACKAGE); \
|
||||||
elif $(GO12) || $(GO13) || $(GO15); then \
|
elif $(GO12) || $(GO13) || $(GO15); then \
|
||||||
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -o $(RUNME).$(GOOBJEXT) $(SRCDIR)$(RUNME).go; \
|
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -I $(GOPATHDIR) -o $(RUNME).$(GOOBJEXT) $(SRCDIR)$(RUNME).go; \
|
||||||
$(COMPILETOOL) $(GOTOOL) $(GOLD) -linkmode external -extld "$(CC)" -extldflags "$(CFLAGS) $(LDFLAGS)" -o $(RUNME) $(RUNME).$(GOOBJEXT); \
|
$(COMPILETOOL) $(GOTOOL) $(GOLD) -L $(GOPATHDIR) -linkmode external -extld "$(CC)" -extldflags "$(CFLAGS) $(LDFLAGS)" -o $(RUNME) $(RUNME).$(GOOBJEXT); \
|
||||||
else \
|
else \
|
||||||
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) $(SRCDIR)$(RUNME).go; \
|
$(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); \
|
$(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)
|
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 $(GO12) || $(GO13) || $(GO15) || $(GOGCC); then \
|
||||||
if test -n "$(SRCDIR_CXXSRCS)$(SRCDIR_SRCS)"; then \
|
if test -n "$(SRCDIR_CXXSRCS)$(SRCDIR_SRCS)"; then \
|
||||||
$(CXX) -g -c $(CPPFLAGS) $(CXXFLAGS) $(SRCDIR_CXXSRCS) $(SRCDIR_SRCS) $(INCLUDES); \
|
$(CXX) -g -c $(CPPFLAGS) $(CXXFLAGS) $(SRCDIR_CXXSRCS) $(SRCDIR_SRCS) $(INCLUDES); \
|
||||||
|
|
@ -2002,11 +1664,12 @@ go_cpp_nocgo: $(SRCDIR_SRCS)
|
||||||
fi; \
|
fi; \
|
||||||
fi
|
fi
|
||||||
|
|
||||||
go_cpp: $(SRCDIR_SRCS)
|
go_cpp: $(SRCDIR_SRCS) $(GOPATHPARENTDIR)/go.mod
|
||||||
$(SWIG) -go -c++ -cgo $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
$(SWIG) -go -c++ -import-prefix swigtests $(GOOPT) $(GOSWIGARG) $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
|
||||||
@mkdir gopath 2>/dev/null || true
|
@mkdir gopath 2>/dev/null || true
|
||||||
@mkdir gopath/src 2>/dev/null || true
|
@mkdir gopath/$(GOMOD) 2>/dev/null || true
|
||||||
@mkdir gopath/src/$(INTERFACE:.i=) 2>/dev/null || true
|
@mkdir gopath/$(GOMOD)/src 2>/dev/null || true
|
||||||
|
@mkdir $(GOPATHDIR) 2>/dev/null || true
|
||||||
rm -f $(GOPATHDIR)/*
|
rm -f $(GOPATHDIR)/*
|
||||||
cp $(ICXXSRCS) $(GOPATHDIR)/
|
cp $(ICXXSRCS) $(GOPATHDIR)/
|
||||||
if test -f $(IWRAP:.i=.h); then \
|
if test -f $(IWRAP:.i=.h); then \
|
||||||
|
|
@ -2019,7 +1682,7 @@ go_cpp: $(SRCDIR_SRCS)
|
||||||
cp $(SRCDIR_SRCS) $(GOPATHDIR)/; \
|
cp $(SRCDIR_SRCS) $(GOPATHDIR)/; \
|
||||||
fi
|
fi
|
||||||
cp $(GOSRCS) $(GOPATHDIR)/
|
cp $(GOSRCS) $(GOPATHDIR)/
|
||||||
GOPATH=`pwd`/gopath; \
|
GOPATH=`pwd`/gopath/$(GOMOD); \
|
||||||
export GOPATH; \
|
export GOPATH; \
|
||||||
CGO_CPPFLAGS="$(CPPFLAGS) $(INCLUDES) -I `cd $(SRCDIR) && pwd` -I `pwd`"; \
|
CGO_CPPFLAGS="$(CPPFLAGS) $(INCLUDES) -I `cd $(SRCDIR) && pwd` -I `pwd`"; \
|
||||||
export CGO_CPPFLAGS; \
|
export CGO_CPPFLAGS; \
|
||||||
|
|
@ -2030,17 +1693,16 @@ go_cpp: $(SRCDIR_SRCS)
|
||||||
CGO_LDFLAGS="$(LDFLAGS) -lm"; \
|
CGO_LDFLAGS="$(LDFLAGS) -lm"; \
|
||||||
export CGO_LDFLAGS; \
|
export CGO_LDFLAGS; \
|
||||||
(cd $(GOPATHDIR) && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o $(GOPACKAGE))
|
(cd $(GOPATHDIR) && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o $(GOPACKAGE))
|
||||||
cp $(GOPATHDIR)/$(GOPACKAGE) $(dir $(INTERFACE))/$(GOPACKAGE)
|
|
||||||
if $(GOGCC); then \
|
if $(GOGCC); then \
|
||||||
cp $(dir $(INTERFACE))/$(GOPACKAGE) $(dir $(INTERFACE))/$(GOPACKAGE:.a=.gox); \
|
cp $(GOPATHDIR)/$(GOPACKAGE) $(GOPATHDIR)/$(GOPACKAGE:.a=.gox); \
|
||||||
fi
|
fi
|
||||||
if test -f $(SRCDIR)$(RUNME).go; then \
|
if test -f $(SRCDIR)$(RUNME).go; then \
|
||||||
if $(GOGCC) ; then \
|
if $(GOGCC) ; then \
|
||||||
$(COMPILETOOL) $(GCCGO) -g -c $(SRCDIR)$(RUNME).go; \
|
$(COMPILETOOL) $(GCCGO) -g -c -I $(GOPATHDIR) $(SRCDIR)$(RUNME).go; \
|
||||||
$(COMPILETOOL) $(GCCGO) -o $(RUNME) $(RUNME).@OBJEXT@ $(dir $(INTERFACE))/$(GOPACKAGE) -lstdc++; \
|
$(COMPILETOOL) $(GCCGO) -o $(RUNME) $(RUNME).@OBJEXT@ $(GOPATHDIR)/$(GOPACKAGE) -lstdc++; \
|
||||||
elif $(GO12) || $(GO13) || $(GO15); then \
|
elif $(GO12) || $(GO13) || $(GO15); then \
|
||||||
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -o $(RUNME).$(GOOBJEXT) $(SRCDIR)$(RUNME).go; \
|
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) -I $(GOPATHDIR) -o $(RUNME).$(GOOBJEXT) $(SRCDIR)$(RUNME).go; \
|
||||||
$(COMPILETOOL) $(GOTOOL) $(GOLD) -linkmode external -extld "$(CXX)" -extldflags "$(CXXFLAGS) $(LDFLAGS)" -o $(RUNME) $(RUNME).$(GOOBJEXT); \
|
$(COMPILETOOL) $(GOTOOL) $(GOLD) -L $(GOPATHDIR) -linkmode external -extld "$(CXX)" -extldflags "$(CXXFLAGS) $(LDFLAGS)" -o $(RUNME) $(RUNME).$(GOOBJEXT); \
|
||||||
else \
|
else \
|
||||||
$(COMPILETOOL) $(GO) $(GOCOMPILEARG) $(SRCDIR)$(RUNME).go; \
|
$(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); \
|
$(COMPILETOOL) $(GOTOOL) $(GOLD) -r $${GOROOT:-`go env GOROOT`}/pkg/$${GOOS:-`go env GOOS`}_$${GOARCH:-`go env GOARCH`}:. -o $(RUNME) $(RUNME).$(GOOBJEXT); \
|
||||||
|
|
|
||||||
|
|
@ -36,6 +36,6 @@ func DeleteGoCallback(p GoCallback) {
|
||||||
p.deleteCallback()
|
p.deleteCallback()
|
||||||
}
|
}
|
||||||
|
|
||||||
func (p *goCallback) Run() {
|
func (p *overwrittenMethodsOnCallback) Run() {
|
||||||
fmt.Println("GoCallback.Run")
|
fmt.Println("GoCallback.Run")
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -3,8 +3,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
"./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
"example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -32,7 +32,7 @@ type overwrittenMethodsOnFooBarAbstract struct {
|
||||||
fb FooBarAbstract
|
fb FooBarAbstract
|
||||||
|
|
||||||
// If additional constructor arguments have been given they are typically
|
// 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 {
|
func (om *overwrittenMethodsOnFooBarAbstract) Foo() string {
|
||||||
|
|
@ -59,7 +59,7 @@ func NewFooBarGo() FooBarGo {
|
||||||
// The memory of the FooBarAbstract director object instance can be
|
// The memory of the FooBarAbstract director object instance can be
|
||||||
// automatically freed once the FooBarGo instance is garbage collected by
|
// automatically freed once the FooBarGo instance is garbage collected by
|
||||||
// uncommenting the following line. Please make sure to understand the
|
// 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
|
// DeleteFooBarGo should be deleted if a finalizer is in use or the fooBarGo
|
||||||
// struct needs additional data to prevent double deletion.
|
// struct needs additional data to prevent double deletion.
|
||||||
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)
|
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)
|
||||||
|
|
|
||||||
|
|
@ -1,9 +1,10 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
"./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
"os"
|
"os"
|
||||||
|
|
||||||
|
"example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func Compare(name string, got string, exp string) error {
|
func Compare(name string, got string, exp string) error {
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -3,8 +3,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -3,8 +3,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
"./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
"example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -3,8 +3,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
. "./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
. "example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -3,8 +3,9 @@
|
||||||
package main
|
package main
|
||||||
|
|
||||||
import (
|
import (
|
||||||
"./example"
|
|
||||||
"fmt"
|
"fmt"
|
||||||
|
|
||||||
|
"example"
|
||||||
)
|
)
|
||||||
|
|
||||||
func main() {
|
func main() {
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,3 @@
|
||||||
#!./matrix \
|
|
||||||
-e do-test -s
|
|
||||||
!#
|
|
||||||
;;; Authors: David Beazley <beazley@cs.uchicago.edu>, 1999
|
;;; Authors: David Beazley <beazley@cs.uchicago.edu>, 1999
|
||||||
;;; Martin Froehlich <MartinFroehlich@ACM.org>, 2000
|
;;; Martin Froehlich <MartinFroehlich@ACM.org>, 2000
|
||||||
;;;
|
;;;
|
||||||
|
|
@ -15,7 +12,7 @@
|
||||||
;;; Explanation: The three lines at the beginning of this script are
|
;;; Explanation: The three lines at the beginning of this script are
|
||||||
;;; telling the kernel to load the enhanced guile interpreter named
|
;;; telling the kernel to load the enhanced guile interpreter named
|
||||||
;;; "matrix"; to execute the function "do-test" (-e option) after loading
|
;;; "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
|
;;; even finer tuning. SEE ALSO: Section "Guile Scripts" in the "Guile
|
||||||
;;; reference manual -- Part I: Preliminaries".
|
;;; reference manual -- Part I: Preliminaries".
|
||||||
;;;
|
;;;
|
||||||
|
|
|
||||||
|
|
@ -15,14 +15,14 @@ back to this behavior, use: */
|
||||||
|
|
||||||
void divide_l(int a, int b, int *OUTPUT, int *OUTPUT);
|
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;
|
%values_as_vector;
|
||||||
/* vectors instead of lists will be used. */
|
/* vectors instead of lists will be used. */
|
||||||
|
|
||||||
void divide_v(int a, int b, int *OUTPUT, int *OUTPUT);
|
void divide_v(int a, int b, int *OUTPUT, int *OUTPUT);
|
||||||
|
|
||||||
/* Multiple values for multiple-value continuations.
|
/* 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;
|
||||||
/* multiple values are passed to the multiple-value
|
/* multiple values are passed to the multiple-value
|
||||||
continuation, as created by `call-with-values' or the
|
continuation, as created by `call-with-values' or the
|
||||||
|
|
|
||||||
|
|
@ -1,21 +1,18 @@
|
||||||
/* Simple example from documentation */
|
|
||||||
/* File : example.c */
|
/* File : example.c */
|
||||||
|
|
||||||
#include <time.h>
|
/* A global variable */
|
||||||
|
double Foo = 3.0;
|
||||||
|
|
||||||
double My_variable = 3.0;
|
/* Compute the greatest common divisor of positive integers */
|
||||||
|
int gcd(int x, int y) {
|
||||||
int fact(int n) {
|
int g;
|
||||||
if (n <= 1) return 1;
|
g = y;
|
||||||
else return n*fact(n-1);
|
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(<ime);
|
|
||||||
return ctime(<ime);
|
|
||||||
}
|
|
||||||
|
|
|
||||||
|
|
@ -5,10 +5,8 @@
|
||||||
%}
|
%}
|
||||||
|
|
||||||
%inline %{
|
%inline %{
|
||||||
extern double My_variable;
|
extern int gcd(int x, int y);
|
||||||
extern int fact(int);
|
extern double Foo;
|
||||||
extern int mod(int n, int m);
|
|
||||||
extern char *get_time();
|
|
||||||
%}
|
%}
|
||||||
|
|
||||||
%include guile/guilemain.i
|
%include guile/guilemain.i
|
||||||
|
|
|
||||||
|
|
@ -3,24 +3,20 @@
|
||||||
(for-each display args)
|
(for-each display args)
|
||||||
(newline))
|
(newline))
|
||||||
|
|
||||||
(mdisplay-newline (get-time) "My variable = " (My-variable))
|
; Call our gcd() function
|
||||||
|
|
||||||
(do ((i 0 (1+ i)))
|
(define x 42)
|
||||||
((= 14 i))
|
(define y 105)
|
||||||
(mdisplay-newline i " factorial is " (fact i)))
|
(define g (gcd x y))
|
||||||
|
(mdisplay-newline "The gcd of " x " and " y " is " g)
|
||||||
|
|
||||||
(define (mods i imax j jmax)
|
; Manipulate the Foo global variable
|
||||||
(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))))
|
|
||||||
|
|
||||||
(mods 1 150 1 150)
|
; Output its current value
|
||||||
|
(mdisplay-newline "Foo = " (Foo))
|
||||||
|
|
||||||
(mdisplay-newline "My-variable = " (My-variable))
|
; Change its value
|
||||||
|
(Foo 3.1415926)
|
||||||
(exit (and (= 1932053504 (fact 13))
|
|
||||||
(= 745470.0 (My-variable))))
|
|
||||||
|
|
||||||
|
; See if the change took effect
|
||||||
|
(mdisplay-newline "Foo = " (Foo))
|
||||||
|
|
|
||||||
|
|
@ -17,9 +17,8 @@ std::vector<double> half(const std::vector<double>& v) {
|
||||||
}
|
}
|
||||||
|
|
||||||
void halve_in_place(std::vector<double>& v) {
|
void halve_in_place(std::vector<double>& v) {
|
||||||
// would you believe this is the same as the above?
|
for (std::vector<double>::iterator it = v.begin(); it != v.end(); ++it)
|
||||||
std::transform(v.begin(),v.end(),v.begin(),
|
*it /= 2.0;
|
||||||
std::bind2nd(std::divides<double>(),2.0));
|
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -2,6 +2,7 @@
|
||||||
callback
|
callback
|
||||||
class
|
class
|
||||||
constants
|
constants
|
||||||
|
doxygen
|
||||||
enum
|
enum
|
||||||
extend
|
extend
|
||||||
funcptr
|
funcptr
|
||||||
|
|
|
||||||
21
Examples/java/doxygen/Makefile
Normal file
21
Examples/java/doxygen/Makefile
Normal 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
48
Examples/java/doxygen/example.cxx
Normal 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
162
Examples/java/doxygen/example.dsp
Normal 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
107
Examples/java/doxygen/example.h
Normal 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
17
Examples/java/doxygen/example.i
Normal 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
63
Examples/java/doxygen/runme.java
Normal 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.");
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
@ -76,7 +76,7 @@ public class runme {
|
||||||
System.out.println( " Trying to set 'status'" );
|
System.out.println( " Trying to set 'status'" );
|
||||||
try {
|
try {
|
||||||
Method m = example.class.getDeclaredMethod("setStatus", new Class[] {Integer.class});
|
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" );
|
System.out.println( "Hey, what's going on?!?! This shouldn't work" );
|
||||||
}
|
}
|
||||||
catch (NoSuchMethodException e) {
|
catch (NoSuchMethodException e) {
|
||||||
|
|
|
||||||
|
|
@ -30,5 +30,5 @@ f.enum_test(example.Foo.LUDICROUS);
|
||||||
// enum value BLUE of enum color is accessed as property of cconst
|
// enum value BLUE of enum color is accessed as property of cconst
|
||||||
console.log("example.BLUE= " + example.BLUE);
|
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);
|
console.log("example.speed.LUDICROUS= " + example.Foo.LUDICROUS);
|
||||||
|
|
|
||||||
|
|
@ -16,30 +16,26 @@ public:
|
||||||
char msg[256];
|
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 {
|
class Test {
|
||||||
public:
|
public:
|
||||||
int simple() throw(int) {
|
int simple() {
|
||||||
throw(37);
|
throw(37);
|
||||||
return 1;
|
return 1;
|
||||||
}
|
}
|
||||||
int message() throw(const char *) {
|
int message() {
|
||||||
throw("I died.");
|
throw("I died.");
|
||||||
return 1;
|
return 1;
|
||||||
}
|
}
|
||||||
int hosed() throw(Exc) {
|
int hosed() {
|
||||||
throw(Exc(42,"Hosed"));
|
throw(Exc(42,"Hosed"));
|
||||||
return 1;
|
return 1;
|
||||||
}
|
}
|
||||||
int unknown() throw(A*) {
|
int unknown() {
|
||||||
static A a;
|
static A a;
|
||||||
throw &a;
|
throw &a;
|
||||||
return 1;
|
return 1;
|
||||||
}
|
}
|
||||||
int multi(int x) throw(int, const char *, Exc) {
|
int multi(int x) {
|
||||||
if (x == 1) throw(37);
|
if (x == 1) throw(37);
|
||||||
if (x == 2) throw("Bleah!");
|
if (x == 2) throw("Bleah!");
|
||||||
if (x == 3) throw(Exc(42,"No-go-diggy-die"));
|
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
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -7,6 +7,12 @@
|
||||||
|
|
||||||
%include "std_string.i"
|
%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 */
|
/* Let's just grab the original header file here */
|
||||||
%include "example.h"
|
%include "example.h"
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -10,7 +10,7 @@ try{
|
||||||
if(error == -1) {
|
if(error == -1) {
|
||||||
console.log("t.unknown() didn't throw");
|
console.log("t.unknown() didn't throw");
|
||||||
} else {
|
} 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) {
|
if(error == -1) {
|
||||||
console.log("t.simple() did not throw");
|
console.log("t.simple() did not throw");
|
||||||
} else {
|
} 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) {
|
if(error == -1) {
|
||||||
console.log("t.message() did not throw");
|
console.log("t.message() did not throw");
|
||||||
} else {
|
} 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) {
|
if(error == -1) {
|
||||||
console.log("t.hosed() did not throw");
|
console.log("t.hosed() did not throw");
|
||||||
} else {
|
} 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) {
|
if(error == -1) {
|
||||||
console.log("t.multi(" + i + ") did not throw");
|
console.log("t.multi(" + i + ") did not throw");
|
||||||
} else {
|
} 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
Loading…
Add table
Add a link
Reference in a new issue