Merge branch 'master' into array_fix
This commit is contained in:
William S Fulton
GitHub
commit
1a4dc82931
1964 changed files with 57298 additions and 30865 deletions
25
.gitignore
vendored
25
.gitignore
vendored
|
|
@ -66,6 +66,7 @@ CCache/ccache_swig_config.h
|
|||
CCache/config.h
|
||||
CCache/config.log
|
||||
CCache/config.status
|
||||
CCache/config_win32.h
|
||||
Examples/Makefile
|
||||
Examples/d/example.mk
|
||||
Examples/guile/Makefile
|
||||
|
|
@ -85,6 +86,8 @@ swig.spec
|
|||
# Build Artifacts
|
||||
.dirstamp
|
||||
CCache/ccache-swig
|
||||
CCache/ccache-swig.1
|
||||
CCache/web/ccache-swig-man.html
|
||||
Lib/swigwarn.swg
|
||||
Source/CParse/parser.c
|
||||
Source/CParse/parser.h
|
||||
|
|
@ -149,14 +152,29 @@ Examples/guile/*/my-guile
|
|||
Examples/test-suite/java/*/
|
||||
Examples/java/*/*.java
|
||||
!Examples/java/*/runme.java
|
||||
Examples/java/doxygen/javadocs
|
||||
|
||||
# Javascript
|
||||
Examples/test-suite/javascript/*/
|
||||
*.gyp
|
||||
|
||||
# OCaml
|
||||
Examples/test-suite/ocaml/*.ml*
|
||||
Examples/test-suite/ocaml/*.cm*
|
||||
Examples/test-suite/ocaml/*_runme
|
||||
!Examples/test-suite/ocaml/*runme.ml
|
||||
Examples/ocaml/**/example.ml*
|
||||
Examples/ocaml/**/runme
|
||||
Examples/ocaml/**/runme_top
|
||||
Examples/ocaml/**/*.cm*
|
||||
Examples/ocaml/**/swig.ml*
|
||||
Examples/ocaml/**/swigp4.ml
|
||||
|
||||
# Octave
|
||||
swigexample*.oct
|
||||
Examples/test-suite/octave/*.oct
|
||||
Examples/test-suite/octave/octheaders.hpp
|
||||
Examples/test-suite/octave/octheaders.hpp.gch
|
||||
|
||||
# Perl5
|
||||
Examples/test-suite/perl5/*.pm
|
||||
|
|
@ -177,11 +195,16 @@ Examples/php/*/example.php
|
|||
/__pycache__/
|
||||
Examples/test-suite/python/*.py
|
||||
!Examples/test-suite/python/*runme.py
|
||||
Examples/python/*/example.py
|
||||
Examples/python/**/bar.py
|
||||
Examples/python/**/base.py
|
||||
Examples/python/**/example.py
|
||||
Examples/python/**/foo.py
|
||||
Examples/python/**/robin.py
|
||||
Examples/python/**/runme3.py
|
||||
Examples/python/**/spam.py
|
||||
Examples/python/import_packages/module_is_init/pkg1/__init__.py
|
||||
Examples/python/import_packages/namespace_pkg/path4.zip
|
||||
Examples/python/doxygen/example.html
|
||||
|
||||
# R
|
||||
Examples/test-suite/r/*.R
|
||||
|
|
|
|||
646
.travis.yml
646
.travis.yml
|
|
@ -4,307 +4,454 @@ matrix:
|
|||
- compiler: clang
|
||||
os: linux
|
||||
env: SWIGLANG=
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: clang
|
||||
os: linux
|
||||
env: SWIGLANG= BUILDSYSTEM=cmake
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=
|
||||
sudo: required
|
||||
dist: trusty
|
||||
env: SWIGLANG= BUILDSYSTEM=cmake
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
|
||||
sudo: required
|
||||
dist: trusty
|
||||
env: SWIGLANG= GCC=4.4
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= SWIG_CC=gcc-6 SWIG_CXX=g++-6
|
||||
sudo: required
|
||||
dist: trusty
|
||||
env: SWIGLANG= GCC=4.6
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= GCC=4.7
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= GCC=4.8
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= GCC=4.9
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= GCC=6
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= GCC=7
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= GCC=8
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG= GCC=9
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=csharp
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=d
|
||||
sudo: required
|
||||
dist: trusty
|
||||
env: SWIGLANG=d VER=2.066.0
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=go
|
||||
sudo: required
|
||||
dist: trusty
|
||||
env: SWIGLANG=d VER=2.086.1
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=go VER=1.5
|
||||
sudo: required
|
||||
dist: trusty
|
||||
env: SWIGLANG=go VER=1.3
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=go VER=1.8
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=go VER=1.12
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=guile
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=java
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=javascript ENGINE=node
|
||||
env: SWIGLANG=javascript ENGINE=node VER=6 CPP11=1
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=javascript ENGINE=node VER=8 CPP11=1
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=javascript ENGINE=node VER=10 CPP11=1
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=javascript ENGINE=node VER=12 CPP11=1
|
||||
sudo: required
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=javascript ENGINE=jsc
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=javascript ENGINE=v8
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=lua
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=lua VER=5.3
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=octave SWIGJOBS=-j2 # 3.2
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=octave SWIGJOBS=-j2 VER=3.8
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=octave SWIGJOBS=-j2 VER=4.0
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=perl5
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=php5
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=php VER=7.0
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=php VER=7.1
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python VER=2.4
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python VER=2.5
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python VER=2.6
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python # 2.7
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.2
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.3
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.4
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.5
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin VER=2.6
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.4
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5 SWIGOPTPY3=
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-O
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-classic
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=r
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=1.9.3
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.0.0
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.3.0
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=scilab
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=tcl
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- os: linux
|
||||
env: SWIGLANG=csharp SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- os: linux
|
||||
env: SWIGLANG=java SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- os: linux
|
||||
env: SWIGLANG=python SWIG_CC=gcc-5 SWIG_CXX=g++-5 CPP11=1
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- os: linux
|
||||
env: SWIGLANG=csharp SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- os: linux
|
||||
env: SWIGLANG=java SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- os: linux
|
||||
env: SWIGLANG=python SWIG_CC=gcc-6 SWIG_CXX=g++-6 CPP14=1
|
||||
sudo: required
|
||||
dist: trusty
|
||||
- compiler: gcc
|
||||
os: osx
|
||||
env: SWIGLANG=
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=csharp
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=go
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=guile
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=java
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=lua
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=perl5
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=php5
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=python
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=python PY3=3
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=ruby
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG=tcl
|
||||
|
||||
allow_failures:
|
||||
# Lots of failing tests currently
|
||||
env: SWIGLANG=mzscheme
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ocaml
|
||||
sudo: required
|
||||
dist: trusty
|
||||
# Not quite working yet
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=octave SWIGJOBS=-j2
|
||||
dist: xenial # Octave v4.0.0
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=octave SWIGJOBS=-j2 CPP11=1
|
||||
dist: bionic # Octave v4.2.2
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=perl5
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=php VER=7.0
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=php VER=7.1
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=php VER=7.2
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=php VER=7.3
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python # 2.7
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.2
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.3
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.4
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.5
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.6
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.7
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.8
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python PY3=3 VER=3.9
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES="-builtin -O"
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin GCC=6 CPP11=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin GCC=6 CPP11=1 PY3=3 VER=3.9
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.4
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.7
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.8
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.9
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES="-builtin -O" PY3=3 VER=3.9
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.9 SWIGOPTPY3=
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-O
|
||||
sudo: required
|
||||
dist: trusty
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=python SWIG_FEATURES=-O PY3=3 VER=3.9
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=r
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=1.9
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.0
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.1
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.2
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.3
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.4
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.5
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.6
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ruby VER=2.7
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=scilab
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=tcl
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=csharp CPP11=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=go VER=1.6 CPP11=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=java CPP11=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=python CPP11=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=r CPP11=1 # Note: making 'R CMD SHLIB' use a different compiler is non-trivial
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=ruby CPP11=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=tcl CPP11=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=csharp GCC=6 CPP14=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=go VER=1.6 GCC=6 CPP14=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=java GCC=6 CPP14=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=python GCC=6 CPP14=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=ruby GCC=6 CPP14=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=tcl GCC=6 CPP14=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=java GCC=7 CPP14=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=python GCC=7 CPP14=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=csharp GCC=8 CPP17=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=java GCC=8 CPP17=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=python GCC=8 CPP17=1 PY3=3 VER=3.9
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=csharp GCC=9 CPP17=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=java GCC=9 CPP17=1
|
||||
dist: xenial
|
||||
- os: linux
|
||||
env: SWIGLANG=python GCC=9 CPP17=1 PY3=3 VER=3.9
|
||||
dist: xenial
|
||||
- os: linux
|
||||
arch: s390x
|
||||
env: SWIGLANG=ruby CPP11=1
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=
|
||||
- compiler: gcc
|
||||
os: osx
|
||||
env: SWIGLANG= BUILDSYSTEM=cmake
|
||||
- compiler: clang
|
||||
os: osx
|
||||
env: SWIGLANG= BUILDSYSTEM=cmake
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=csharp
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=go
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=guile CSTD=c11
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=java
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=lua
|
||||
# octave-6.1 not working
|
||||
# - compiler: clang
|
||||
# os: osx
|
||||
# osx_image: xcode12.2
|
||||
# env: SWIGLANG=octave SWIGJOBS=-j2 CPP11=1
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=perl5
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=python
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=python PY3=3
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=ruby
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=tcl
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=java CPP17=1
|
||||
- compiler: clang
|
||||
os: osx
|
||||
osx_image: xcode12.2
|
||||
env: SWIGLANG=python PY3=3 CPP17=1
|
||||
|
||||
allow_failures:
|
||||
# Newer version of D not yet working/supported
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=d VER=2.086.1
|
||||
dist: xenial
|
||||
# seg fault in director_basic testcase
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=php VER=7.2
|
||||
dist: xenial
|
||||
# Experimental languages
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=mzscheme
|
||||
dist: xenial
|
||||
- compiler: gcc
|
||||
os: linux
|
||||
env: SWIGLANG=ocaml
|
||||
dist: xenial
|
||||
|
||||
before_install:
|
||||
- date -u
|
||||
- uname -a
|
||||
- if test "$TRAVIS_OS_NAME" = "linux"; then lscpu && cat /proc/cpuinfo | grep "model name" && cat /proc/meminfo | grep MemTotal; fi
|
||||
- if test "$TRAVIS_OS_NAME" = "linux"; then lscpu; grep "model name" /proc/cpuinfo || echo 'Unknown CPU model'; grep "MemTotal" /proc/meminfo || echo 'Unknown system memory amount'; fi
|
||||
- if test "$TRAVIS_OS_NAME" = "osx"; then sysctl -a | grep brand_string; fi
|
||||
# Travis overrides CC environment with compiler predefined values
|
||||
- if test -n "$SWIG_CC"; then export CC="$SWIG_CC"; fi
|
||||
- if test -n "$SWIG_CXX"; then export CXX="$SWIG_CXX"; fi
|
||||
# Travis overrides CC environment with compiler predefined values
|
||||
- if test -n "$GCC"; then export CC="gcc-$GCC" && export CXX="g++-$GCC"; fi
|
||||
install:
|
||||
- if test "$TRAVIS_OS_NAME" = "linux"; then source Tools/travis-linux-install.sh; fi
|
||||
- if test "$TRAVIS_OS_NAME" = "osx"; then source Tools/travis-osx-install.sh; fi
|
||||
- ls -la $(which $CC) $(which $CXX) && $CC --version && $CXX --version
|
||||
script:
|
||||
- if test "$BUILDSYSTEM" = "cmake"; then mkdir -p build/build && cd build/build && cmake -DCMAKE_INSTALL_PREFIX=~/.local ../.. && make install && ctest --output-on-failure -V && exit 0; fi
|
||||
- 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
|
||||
- ls -la $(which $CC)
|
||||
- ls -la $(which $CXX)
|
||||
- $CC --version
|
||||
- $CXX --version
|
||||
script:
|
||||
- echo 'Configuring...' && echo -en 'travis_fold:start:script.1\\r'
|
||||
- if test -n "$CPP17"; then CONFIGOPTS+=(--enable-cpp11-testing --without-maximum-compile-warnings "CXXFLAGS=-std=c++17 -Wall -Wextra" "CFLAGS=-std=c17 -Wall -Wextra") && export CSTD=c17 && export CPPSTD=c++17; fi
|
||||
- if test -n "$SWIGLANG"; then CONFIGOPTS+=(--without-alllang --with-$WITHLANG); fi
|
||||
- echo "${CONFIGOPTS[@]}"
|
||||
- ./autogen.sh && mkdir -p build/build && cd build/build && ../../configure "${CONFIGOPTS[@]}"
|
||||
|
|
@ -324,5 +471,6 @@ script:
|
|||
- if test -n "$SWIGLANG"; then make $SWIGJOBS check-$SWIGLANG-examples CFLAGS="$cflags" CXXFLAGS="$cxxflags"; fi
|
||||
- if test -n "$SWIGLANG"; then make $SWIGJOBS check-$SWIGLANG-test-suite CFLAGS="$cflags" CXXFLAGS="$cxxflags"; fi
|
||||
- echo 'Cleaning...' && echo -en 'travis_fold:start:script.3\\r'
|
||||
- make check-maintainer-clean && ../../configure $CONFIGOPTS
|
||||
# Skip on osx as often fails with: rm: Resource temporarily unavailable
|
||||
- if test "$TRAVIS_OS_NAME" != "osx"; then make check-maintainer-clean && ../../configure $CONFIGOPTS; fi
|
||||
- echo -en 'travis_fold:end:script.3\\r'
|
||||
|
|
|
|||
20
ANNOUNCE
20
ANNOUNCE
|
|
@ -1,8 +1,8 @@
|
|||
*** ANNOUNCE: SWIG 3.0.12 (in progress) ***
|
||||
*** ANNOUNCE: SWIG 4.1.0 (in progress) ***
|
||||
|
||||
http://www.swig.org
|
||||
|
||||
We're pleased to announce SWIG-3.0.12, the latest SWIG release.
|
||||
We're pleased to announce SWIG-4.1.0, the latest SWIG release.
|
||||
|
||||
What is SWIG?
|
||||
=============
|
||||
|
|
@ -10,13 +10,11 @@ What is SWIG?
|
|||
SWIG is a software development tool that reads C/C++ header files and
|
||||
generates the wrapper code needed to make C and C++ code accessible
|
||||
from other programming languages including Perl, Python, Tcl, Ruby,
|
||||
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme, CHICKEN),
|
||||
D, Ocaml, Pike, Modula-3, Octave, R, Scilab, Common Lisp (CLISP,
|
||||
Allegro CL, CFFI, UFFI). SWIG can also export its parse tree in
|
||||
the form of XML and Lisp s-expressions. Major applications of SWIG
|
||||
include generation of scripting language extension modules, rapid
|
||||
prototyping, testing, and user interface development for large
|
||||
C/C++ systems.
|
||||
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D,
|
||||
Ocaml, Octave, R, Scilab. SWIG can also export its parse tree in
|
||||
the form of XML. Major applications of SWIG include generation of
|
||||
scripting language extension modules, rapid prototyping, testing,
|
||||
and user interface development for large C/C++ systems.
|
||||
|
||||
Release Notes
|
||||
=============
|
||||
|
|
@ -27,11 +25,11 @@ Availability
|
|||
============
|
||||
The release is available for download on Sourceforge at
|
||||
|
||||
http://prdownloads.sourceforge.net/swig/swig-3.0.12.tar.gz
|
||||
http://prdownloads.sourceforge.net/swig/swig-4.1.0.tar.gz
|
||||
|
||||
A Windows version is also available at
|
||||
|
||||
http://prdownloads.sourceforge.net/swig/swigwin-3.0.12.zip
|
||||
http://prdownloads.sourceforge.net/swig/swigwin-4.1.0.zip
|
||||
|
||||
Please report problems with this release to the swig-devel mailing list,
|
||||
details at http://www.swig.org/mail.html.
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ bindir=@bindir@
|
|||
mandir=@mandir@
|
||||
INSTALLCMD=@INSTALL@
|
||||
PACKAGE_NAME=@PACKAGE_NAME@
|
||||
PROGRAM_NAME=@PROGRAM_NAME@
|
||||
# Soft link test can be skipped on systems that don't support soft linking
|
||||
NOSOFTLINKSTEST=
|
||||
|
||||
|
|
@ -17,13 +18,10 @@ SWIG=swig
|
|||
SWIG_LIB=../$(srcdir)/../Lib
|
||||
EXEEXT=@EXEEXT@
|
||||
|
||||
# Use standard autoconf approach to transform executable name using --program-prefix and --program-suffix
|
||||
transform = @program_transform_name@
|
||||
|
||||
LIBS= @LIBS@
|
||||
OBJS= ccache.o mdfour.o hash.o execute.o util.o args.o stats.o \
|
||||
cleanup.o snprintf.o unify.o
|
||||
HEADERS = ccache.h mdfour.h
|
||||
HEADERS = ccache.h mdfour.h config.h config_win32.h
|
||||
|
||||
all: $(PACKAGE_NAME)$(EXEEXT)
|
||||
|
||||
|
|
@ -32,7 +30,7 @@ Makefile: $(srcdir)/Makefile.in ./config.status
|
|||
$(SHELL) ./config.status
|
||||
|
||||
# Note that HTML documentation is actually generated and used from the main SWIG documentation Makefile
|
||||
docs: $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/ccache-man.html
|
||||
docs: $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/$(PACKAGE_NAME)-man.html
|
||||
|
||||
$(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
|
||||
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
|
||||
|
|
@ -40,40 +38,43 @@ $(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
|
|||
$(srcdir)/$(PACKAGE_NAME).1: $(srcdir)/ccache.yo
|
||||
-yodl2man -o $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/ccache.yo
|
||||
|
||||
$(srcdir)/web/ccache-man.html: $(srcdir)/ccache.yo
|
||||
yodl2html -o $(srcdir)/web/ccache-man.html $(srcdir)/ccache.yo
|
||||
$(srcdir)/web/$(PACKAGE_NAME)-man.html: $(srcdir)/ccache.yo
|
||||
yodl2html -o $(srcdir)/web/$(PACKAGE_NAME)-man.html $(srcdir)/ccache.yo
|
||||
|
||||
install: $(PACKAGE_NAME)$(EXEEXT)
|
||||
@echo "Installing $(PACKAGE_NAME)"
|
||||
@echo "Installing $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)"
|
||||
@echo "Installing $(DESTDIR)${bindir}/$(PROGRAM_NAME)$(EXEEXT)"
|
||||
${INSTALLCMD} -d $(DESTDIR)${bindir}
|
||||
${INSTALLCMD} -m 755 $(PACKAGE_NAME)$(EXEEXT) $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
|
||||
${INSTALLCMD} -m 755 $(PACKAGE_NAME)$(EXEEXT) $(DESTDIR)${bindir}/$(PROGRAM_NAME)$(EXEEXT)
|
||||
|
||||
install-docs: $(srcdir)/$(PACKAGE_NAME).1
|
||||
@echo "Installing $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1"
|
||||
@echo "Installing $(DESTDIR)${mandir}/man1/$(PROGRAM_NAME).1"
|
||||
${INSTALLCMD} -d $(DESTDIR)${mandir}/man1
|
||||
${INSTALLCMD} -m 644 $(srcdir)/$(PACKAGE_NAME).1 $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
|
||||
${INSTALLCMD} -m 644 $(srcdir)/$(PACKAGE_NAME).1 $(DESTDIR)${mandir}/man1/$(PROGRAM_NAME).1
|
||||
|
||||
uninstall: $(PACKAGE_NAME)$(EXEEXT)
|
||||
rm -f $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
|
||||
rm -f $(DESTDIR)${bindir}/$(PROGRAM_NAME)$(EXEEXT)
|
||||
|
||||
uninstall-docs: $(srcdir)/$(PACKAGE_NAME).1
|
||||
rm -f $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
|
||||
rm -f $(DESTDIR)${mandir}/man1/$(PROGRAM_NAME).1
|
||||
|
||||
clean:
|
||||
clean: clean-docs
|
||||
/bin/rm -f $(OBJS) *~ $(PACKAGE_NAME)$(EXEEXT)
|
||||
|
||||
clean-docs:
|
||||
rm -f $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/$(PACKAGE_NAME)-man.html
|
||||
|
||||
test: test.sh
|
||||
SWIG_LIB='$(SWIG_LIB)' PATH=../..:$$PATH SWIG='$(SWIG)' CC='$(CC)' NOSOFTLINKSTEST='$(NOSOFTLINKSTEST)' $(srcdir)/test.sh
|
||||
SWIG_LIB='$(SWIG_LIB)' PATH=../..:$$PATH SWIG='$(SWIG)' CC='$(CC)' NOSOFTLINKSTEST='$(NOSOFTLINKSTEST)' CCACHE='../$(PACKAGE_NAME)' CCACHE_PROG=$(PROGRAM_NAME) $(srcdir)/test.sh
|
||||
|
||||
check: test
|
||||
|
||||
distclean: clean
|
||||
/bin/rm -f Makefile config.h config.sub config.log build-stamp config.status ccache_swig_config.h
|
||||
/bin/rm -f Makefile config.h config.sub config.log build-stamp config.status ccache_swig_config.h config_win32.h
|
||||
/bin/rm -rf autom4te.cache
|
||||
|
||||
maintainer-clean: distclean
|
||||
/bin/rm -f $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/ccache-man.html
|
||||
/bin/rm -f $(srcdir)/$(PACKAGE_NAME).1 $(srcdir)/web/$(PACKAGE_NAME)-man.html
|
||||
|
||||
|
||||
# FIXME: To fix this, test.sh needs to be able to take ccache from the
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
#include "config.h"
|
||||
#else
|
||||
#include <sys/locking.h>
|
||||
#define PACKAGE_NAME "ccache-swig.exe"
|
||||
#include "config_win32.h"
|
||||
#endif
|
||||
|
||||
#include <stdio.h>
|
||||
|
|
@ -51,7 +51,7 @@
|
|||
#define STATUS_FATAL 4
|
||||
#define STATUS_NOCACHE 5
|
||||
|
||||
#define MYNAME PACKAGE_NAME
|
||||
#define MYNAME PROGRAM_NAME
|
||||
|
||||
#define LIMIT_MULTIPLE 0.8
|
||||
|
||||
|
|
|
|||
3
CCache/config_win32.h.in
Normal file
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_CONFIG_HEADER(config.h)
|
||||
AC_CONFIG_FILES([config_win32.h])
|
||||
|
||||
dnl Checks for programs.
|
||||
AC_PROG_CC
|
||||
|
|
@ -14,6 +15,20 @@ AC_PROG_CPP
|
|||
AC_PROG_INSTALL
|
||||
AC_ARG_PROGRAM # for program_transform_name
|
||||
|
||||
AC_SUBST(PROGRAM_NAME)
|
||||
if test "x$program_prefix" != "xNONE" -a "x$program_prefix" != "x"
|
||||
then
|
||||
PROGRAM_NAME="$program_prefix$PACKAGE_NAME"
|
||||
else
|
||||
PROGRAM_NAME="$PACKAGE_NAME"
|
||||
fi
|
||||
if test "x$program_suffix" != "xNONE" -a "x$program_suffix" != "x"
|
||||
then
|
||||
PROGRAM_NAME="$PROGRAM_NAME$program_suffix"
|
||||
fi
|
||||
|
||||
AC_DEFINE_UNQUOTED(PROGRAM_NAME, "$PROGRAM_NAME", [Define my program name])
|
||||
|
||||
AC_DEFINE([_GNU_SOURCE], 1,
|
||||
[Define _GNU_SOURCE so that we get all necessary prototypes])
|
||||
|
||||
|
|
|
|||
|
|
@ -292,6 +292,7 @@ static size_t dopr(char *buffer, size_t maxlen, const char *format, va_list args
|
|||
break;
|
||||
case 'X':
|
||||
flags |= DP_F_UP;
|
||||
/* FALLTHROUGH */
|
||||
case 'x':
|
||||
flags |= DP_F_UNSIGNED;
|
||||
if (cflags == DP_C_SHORT)
|
||||
|
|
@ -314,6 +315,7 @@ static size_t dopr(char *buffer, size_t maxlen, const char *format, va_list args
|
|||
break;
|
||||
case 'E':
|
||||
flags |= DP_F_UP;
|
||||
/* FALLTHROUGH */
|
||||
case 'e':
|
||||
if (cflags == DP_C_LDOUBLE)
|
||||
fvalue = va_arg (args, LDOUBLE);
|
||||
|
|
@ -322,6 +324,7 @@ static size_t dopr(char *buffer, size_t maxlen, const char *format, va_list args
|
|||
break;
|
||||
case 'G':
|
||||
flags |= DP_F_UP;
|
||||
/* FALLTHROUGH */
|
||||
case 'g':
|
||||
if (cflags == DP_C_LDOUBLE)
|
||||
fvalue = va_arg (args, LDOUBLE);
|
||||
|
|
|
|||
|
|
@ -20,7 +20,12 @@ fi
|
|||
PATH="`echo $PATH | \
|
||||
sed -e 's!:/usr\(/local\)*/lib\([0-9]\)*/ccache\(/\)*!!g'`"
|
||||
|
||||
CCACHE=../ccache-swig
|
||||
if test -n "$CCACHE"; then
|
||||
CCACHE="$CCACHE"
|
||||
else
|
||||
CCACHE=../ccache-swig
|
||||
fi
|
||||
|
||||
TESTDIR=test.$$
|
||||
|
||||
test_failed() {
|
||||
|
|
@ -406,6 +411,10 @@ swigtests() {
|
|||
# main program
|
||||
rm -rf $TESTDIR
|
||||
mkdir $TESTDIR
|
||||
if test -n "$CCACHE_PROG"; then
|
||||
ln -s $CCACHE $TESTDIR/$CCACHE_PROG
|
||||
CCACHE=./$CCACHE_PROG
|
||||
fi
|
||||
cd $TESTDIR || exit 1
|
||||
|
||||
unset CCACHE_DIR
|
||||
|
|
@ -442,14 +451,16 @@ swigtests
|
|||
|
||||
if test -z "$NOSOFTLINKSTEST"; then
|
||||
testsuite="link"
|
||||
ln -s $CCACHE $COMPILER
|
||||
CCACHE_COMPILE="./$COMPILER"
|
||||
compilername=`basename $COMPILER`
|
||||
ln -s $CCACHE ./$compilername
|
||||
CCACHE_COMPILE="./$compilername"
|
||||
basetests
|
||||
rm "./$COMPILER"
|
||||
ln -s $CCACHE $SWIG
|
||||
CCACHE_COMPILE="./$SWIG"
|
||||
rm "./$compilername"
|
||||
compilername=`basename $SWIG`
|
||||
ln -s $CCACHE ./$compilername
|
||||
CCACHE_COMPILE="./$compilername"
|
||||
swigtests
|
||||
rm "./$SWIG"
|
||||
rm "./$compilername"
|
||||
else
|
||||
echo "skipping testsuite link"
|
||||
fi
|
||||
|
|
|
|||
|
|
@ -4,15 +4,89 @@ 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.12 (in progress)
|
||||
============================
|
||||
Version 4.1.0 (in progress)
|
||||
===========================
|
||||
|
||||
2016-12-31: ajrheading1
|
||||
Issue #860 - Remove use of std::unary_function and std::binary_function
|
||||
which is deprecated in C++11.
|
||||
2021-03-01: xantares, Oliver Buchtala, geographika
|
||||
#1040 Add support for building SWIG with CMake. See documentation in Windows.html.
|
||||
|
||||
2016-12-30: olly
|
||||
[PHP7] Register internal 'swig_runtime_data_type_pointer' constant
|
||||
as "CONST_PERSISTENT" to avoid segmentation fault on module unload.
|
||||
Fixes https://github.com/swig/swig/issues/859 reported by Timotheus
|
||||
Pokorra - thanks also to Javier Torres for a minimal reproducer.
|
||||
2021-03-01: vadz
|
||||
#1952 Fix incorrect warning "Unknown Doxygen command: ."
|
||||
|
||||
2021-02-28: p2k
|
||||
#969 [Javascript] v8/node - prevent crash calling a constructor without new keyword.
|
||||
|
||||
2021-02-28: alecmev
|
||||
#405 #1121 [Javascript] Fix OUTPUT typemaps on methods that don't return void.
|
||||
The output value is appended to the return value.
|
||||
|
||||
2021-02-26: murillo128, wsfulton
|
||||
#1269 [Javascript] Fix handling of large positive unsigned long and
|
||||
unsigned long long values.
|
||||
|
||||
2021-02-24: tomleavy, yegorich, tungntpham
|
||||
#1746 [Javascript] Add support for Node v12.
|
||||
SWIG support is now for Node v6 and later only.
|
||||
|
||||
2020-10-10: wsfulton
|
||||
#252 complex can now be used as a C identifier and doesn't give a syntax error.
|
||||
|
||||
2020-10-10: lpsinger
|
||||
#1770 Correct C complex support.
|
||||
_Complex is now parsed as a keyword rather than complex as per the C99 standard.
|
||||
The complex macro is available in the ccomplex.i library file along with other
|
||||
complex number handling provided by the complex.h header.
|
||||
|
||||
2020-10-07: ZackerySpytz
|
||||
[Python] #1812 Fix the error handling for the PyObject_GetBuffer() calls in
|
||||
pybuffer.i.
|
||||
|
||||
2020-10-07: treitmayr
|
||||
#1824 Add missing space in director method declaration returning
|
||||
const pointer.
|
||||
|
||||
2020-10-07: adelva1984
|
||||
#1859 Remove all (two) exceptions from SWIG executable.
|
||||
|
||||
2020-09-25: wsfulton
|
||||
[C#, Java] #1874 Add ability to change the modifiers for the interface
|
||||
generated when using the %interface macros.
|
||||
|
||||
For C# use the 'csinterfacemodifiers' typemap.
|
||||
For Java use the 'javainterfacemodifiers' typemap.
|
||||
|
||||
For example:
|
||||
|
||||
%typemap(csinterfacemodifiers) X "internal interface"
|
||||
|
||||
|
||||
2020-09-24: geefr
|
||||
[C#] #1868 Fix wchar_t* csvarout typemap for member variable wrappers.
|
||||
|
||||
2020-08-28: wsfulton
|
||||
[Java] #1862 Fix crashes in swig_connect_director during director class construction
|
||||
when using the director class from multiple threads - a race condition initialising
|
||||
block scope static variables. The fix is guaranteed when using C++11, but most
|
||||
compilers also fix it when using C++03/C++98.
|
||||
|
||||
2020-08-16: wsfulton
|
||||
[Python] Add missing initializer for member ‘_heaptypeobject::ht_module’ when using
|
||||
-builtin to complete Python 3.9 support.
|
||||
|
||||
2020-08-16: wsfulton
|
||||
[Python] Remove PyEval_InitThreads() call for Python 3.7 and later as Python calls
|
||||
it automatically now. This removes a deprecation warning when using Python 3.9.
|
||||
|
||||
2020-08-15: wsfulton
|
||||
[Python] All Python examples and tests are written to be Python 2 and Python 3
|
||||
compatible, removing the need for 2to3 to run the examples or test-suite.
|
||||
|
||||
2020-08-13: wsfulton
|
||||
[C#] Add support for void *VOID_INT_PTR for member variables.
|
||||
|
||||
2020-07-29: chrisburr
|
||||
#1843 [Python] Compilation error fix in SwigPyBuiltin_SetMetaType when using PyPy.
|
||||
|
||||
2020-06-14: ZackerySpytz
|
||||
#1642 #1809 Fix virtual comparison operators in director classes - remove incorrect
|
||||
space in the function name, for example, operator= = is now operator==.
|
||||
|
|
|
|||
161
CMakeLists.txt
Normal file
161
CMakeLists.txt
Normal file
|
|
@ -0,0 +1,161 @@
|
|||
cmake_minimum_required (VERSION 3.2)
|
||||
|
||||
if (NOT DEFINED CMAKE_BUILD_TYPE)
|
||||
set (CMAKE_BUILD_TYPE Release CACHE STRING "Build type")
|
||||
endif ()
|
||||
|
||||
project (swig)
|
||||
|
||||
if (POLICY CMP0074)
|
||||
cmake_policy (SET CMP0074 NEW)
|
||||
endif()
|
||||
|
||||
file (STRINGS configure.ac line LIMIT_COUNT 1 REGEX "AC_INIT\\(.*\\)" )
|
||||
if (line MATCHES "AC_INIT\\(\\[(.*)\\],[ \t]*\\[(.*)\\],[ \t]*\\[(.*)\\]\\)" )
|
||||
set (SWIG_VERSION ${CMAKE_MATCH_2})
|
||||
set (PACKAGE_BUGREPORT ${CMAKE_MATCH_3})
|
||||
else ()
|
||||
message (SEND_ERROR "Could not parse version from configure.ac")
|
||||
endif ()
|
||||
|
||||
set (SWIG_ROOT ${PROJECT_SOURCE_DIR})
|
||||
|
||||
set (SWIG_LIB share/swig/${SWIG_VERSION})
|
||||
|
||||
# Project wide configuration variables
|
||||
# ------------------------------------
|
||||
|
||||
set (SWIG_SOURCE_DIR ${SWIG_ROOT}/Source CACHE INTERNAL "Path of swig sources" FORCE)
|
||||
|
||||
set (PACKAGE_NAME swig)
|
||||
set (PACKAGE_VERSION ${SWIG_VERSION})
|
||||
|
||||
# Configure
|
||||
# ---------
|
||||
|
||||
list (APPEND CMAKE_MODULE_PATH ${SWIG_ROOT}/Tools/cmake)
|
||||
|
||||
include (CheckIncludeFiles)
|
||||
include (CheckIncludeFile)
|
||||
include (CheckIncludeFileCXX)
|
||||
include (CheckTypeSize)
|
||||
include (CheckSymbolExists)
|
||||
include (CheckFunctionExists)
|
||||
include (CheckLibraryExists)
|
||||
include (CheckCSourceCompiles)
|
||||
|
||||
# HACK: didn't get the bool check working for Visual Studio 2008
|
||||
if (MSVC)
|
||||
set(HAVE_BOOL 1)
|
||||
else()
|
||||
set (CMAKE_EXTRA_INCLUDE_FILES stdbool.h)
|
||||
check_type_size ("bool" HAVE_BOOL)
|
||||
set (CMAKE_EXTRA_INCLUDE_FILES)
|
||||
endif()
|
||||
|
||||
check_include_file ("inttypes.h" HAVE_INTTYPES_H)
|
||||
check_include_file ("stddef.h" HAVE_STDDEF_H)
|
||||
check_include_file ("stdint.h" HAVE_STDINT_H)
|
||||
check_include_file ("stdio.h" HAVE_STDIO_H)
|
||||
check_include_file ("stdlib.h" HAVE_STDLIB_H)
|
||||
check_include_file ("string.h" HAVE_STRING_H)
|
||||
check_include_file ("strings.h" HAVE_STRINGS_H)
|
||||
check_include_file ("sys/stat.h" HAVE_SYS_STAT_H)
|
||||
check_include_file ("sys/types.h" HAVE_SYS_TYPES_H)
|
||||
check_include_file ("unistd.h" HAVE_UNISTD_H)
|
||||
check_include_files ("stdlib.h;stdarg.h;string.h;float.h" STDC_HEADERS)
|
||||
|
||||
check_include_file_cxx ("boost/shared_ptr.hpp" HAVE_BOOST)
|
||||
check_library_exists (dl dlopen "" HAVE_LIBDL)
|
||||
check_function_exists (popen HAVE_POPEN)
|
||||
|
||||
set (PCRE_REQUIRED_ARG "REQUIRED" CACHE STRING "required arg")
|
||||
find_package (PCRE ${PCRE_REQUIRED_ARG})
|
||||
if (PCRE_FOUND)
|
||||
set (HAVE_PCRE 1)
|
||||
include_directories (${PCRE_INCLUDE_DIRS})
|
||||
endif()
|
||||
|
||||
if (WIN32)
|
||||
file (TO_NATIVE_PATH ${CMAKE_INSTALL_PREFIX}/${SWIG_LIB} SWIG_LIB_WIN_UNIX)
|
||||
endif ()
|
||||
configure_file (${SWIG_ROOT}/Tools/cmake/swigconfig.h.in
|
||||
${CMAKE_CURRENT_BINARY_DIR}/Source/Include/swigconfig.h)
|
||||
|
||||
find_package (BISON REQUIRED)
|
||||
|
||||
|
||||
# Compiler flags
|
||||
# --------------
|
||||
|
||||
include_directories (
|
||||
${SWIG_SOURCE_DIR}/CParse
|
||||
${SWIG_SOURCE_DIR}/Include
|
||||
${SWIG_SOURCE_DIR}/DOH
|
||||
${SWIG_SOURCE_DIR}/Swig
|
||||
${SWIG_SOURCE_DIR}/Preprocessor
|
||||
${SWIG_SOURCE_DIR}/Modules
|
||||
${PROJECT_BINARY_DIR}/Source/Include
|
||||
${PROJECT_BINARY_DIR}/Source/CParse
|
||||
${PROJECT_SOURCE_DIR}/Source/Doxygen
|
||||
)
|
||||
|
||||
# generate the parser source code (depends on bison)
|
||||
file (MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/Source/CParse)
|
||||
|
||||
BISON_TARGET (swig_parser
|
||||
${SWIG_SOURCE_DIR}/CParse/parser.y
|
||||
${PROJECT_BINARY_DIR}/Source/CParse/parser.c
|
||||
)
|
||||
|
||||
# generate swigwarn.swg
|
||||
file (READ ${SWIG_SOURCE_DIR}/Include/swigwarn.h SWIG_WARN_H)
|
||||
string (REGEX REPLACE "#define WARN([^ \\t]*)[ \\t]*([0-9]+)" "%define SWIGWARN\\1 \\2 %enddef" SWIG_WARN_SWG ${SWIG_WARN_H})
|
||||
file (WRITE ${CMAKE_CURRENT_BINARY_DIR}/swigwarn.swg ${SWIG_WARN_SWG})
|
||||
set_property (SOURCE ${CMAKE_CURRENT_BINARY_DIR}/swigwarn.swg PROPERTY GENERATED 1)
|
||||
|
||||
# install lib
|
||||
install (DIRECTORY ${SWIG_ROOT}/Lib/ DESTINATION ${SWIG_LIB})
|
||||
install (FILES ${CMAKE_CURRENT_BINARY_DIR}/swigwarn.swg DESTINATION ${SWIG_LIB})
|
||||
|
||||
# sources
|
||||
# ---------
|
||||
file (GLOB DOH_SOURCES ${SWIG_SOURCE_DIR}/DOH/*.c)
|
||||
file (GLOB CPARSE_SOURCES ${SWIG_SOURCE_DIR}/CParse/*.c)
|
||||
list (APPEND CPARSE_SOURCES)
|
||||
file (GLOB PREPROCESSOR_SOURCES ${SWIG_SOURCE_DIR}/Preprocessor/*.c)
|
||||
file (GLOB CORE_SOURCES ${SWIG_SOURCE_DIR}/Swig/*.c)
|
||||
file (GLOB DOXYGEN_SOURCES ${SWIG_SOURCE_DIR}/Doxygen/*.cxx)
|
||||
file (GLOB MODULES_SOURCES ${SWIG_SOURCE_DIR}/Modules/*.cxx)
|
||||
|
||||
add_executable (swig
|
||||
${CPARSE_SOURCES}
|
||||
${DOH_SOURCES}
|
||||
${DOXYGEN_SOURCES}
|
||||
${MODULES_SOURCES}
|
||||
${CORE_SOURCES}
|
||||
${PREPROCESSOR_SOURCES}
|
||||
${PROJECT_BINARY_DIR}/Source/Include/swigconfig.h
|
||||
${SWIG_SOURCE_DIR}/Include/swigwarn.h
|
||||
${PROJECT_BINARY_DIR}/Source/CParse/parser.c
|
||||
${PROJECT_BINARY_DIR}/Source/CParse/parser.h
|
||||
)
|
||||
if (PCRE_FOUND)
|
||||
target_link_libraries (swig ${PCRE_LIBRARIES})
|
||||
endif ()
|
||||
install (TARGETS swig DESTINATION bin)
|
||||
|
||||
# 'make package-source' creates tarballs
|
||||
set (CPACK_PACKAGE_NAME ${PACKAGE_NAME})
|
||||
set (CPACK_SOURCE_GENERATOR "TGZ;TBZ2")
|
||||
set (CPACK_SOURCE_IGNORE_FILES "/.git;/build;.*~;${CPACK_SOURCE_IGNORE_FILES}")
|
||||
set (CPACK_SOURCE_PACKAGE_FILE_NAME ${PACKAGE_NAME}-${PACKAGE_VERSION})
|
||||
include (CPack)
|
||||
|
||||
# few tests
|
||||
enable_testing ()
|
||||
add_test (NAME cmd_version COMMAND swig -version)
|
||||
add_test (NAME cmd_swiglib COMMAND swig -swiglib)
|
||||
add_test (NAME cmd_external_runtime COMMAND swig -external-runtime ext_rt.h)
|
||||
set_tests_properties(cmd_external_runtime PROPERTIES ENVIRONMENT "SWIG_LIB=${PROJECT_SOURCE_DIR}/Lib")
|
||||
|
||||
|
|
@ -19,6 +19,7 @@ Active SWIG Developers:
|
|||
Oliver Buchtala (oliver.buchtala@gmail.com) (Javascript)
|
||||
Neha Narang (narangneha03@gmail.com) (Javascript)
|
||||
Simon Marchetto (simon.marchetto@scilab-enterprises.com) (Scilab)
|
||||
Zackery Spytz (zspytz@gmail.com) (OCaml, SWIG core)
|
||||
|
||||
Past SWIG developers and major contributors include:
|
||||
Dave Beazley (dave-swig@dabeaz.com) (SWIG core, Python, Tcl, Perl)
|
||||
|
|
@ -28,7 +29,7 @@ Past SWIG developers and major contributors include:
|
|||
Mikel Bancroft (mikel@franz.com) (Allegro CL)
|
||||
Surendra Singhi (efuzzyone@netscape.net) (CLISP, CFFI)
|
||||
Marcelo Matus (mmatus@acms.arizona.edu) (SWIG core, Python, UTL[python,perl,tcl,ruby])
|
||||
Art Yerkes (ayerkes@speakeasy.net) (Ocaml)
|
||||
Art Yerkes (ayerkes@speakeasy.net) (OCaml)
|
||||
Lyle Johnson (lyle@users.sourceforge.net) (Ruby)
|
||||
Charlie Savage (cfis@interserv.com) (Ruby)
|
||||
Thien-Thi Nguyen (ttn@glug.org) (build/test/misc)
|
||||
|
|
@ -62,7 +63,8 @@ Past SWIG developers and major contributors include:
|
|||
John Lenz (Guile, MzScheme updates, Chicken module, runtime system)
|
||||
Baozeng Ding <sploving1@163.com> (Scilab)
|
||||
Ian Lance Taylor (Go)
|
||||
Vadim Zeitlin (PCRE, Python)
|
||||
Dmitry Kabak (userdima@gmail.com) (Doxygen)
|
||||
Vadim Zeitlin (PCRE, Python, Doxygen)
|
||||
Stefan Zager (szager@gmail.com) (Python)
|
||||
Vincent Couvert (Scilab)
|
||||
Sylvestre Ledru (Scilab)
|
||||
|
|
|
|||
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
|
||||
common approach is to store the mod pointer in some global variable in the
|
||||
target language, but if the language provides an alternative place to store data
|
||||
(like the chicken module), then that is good too.
|
||||
then that is good too.
|
||||
|
||||
The way the code is set up, SetModule should only be called when GetModule
|
||||
returns NULL, and if SetModule is called a second time, the behavior is
|
||||
|
|
@ -105,7 +105,7 @@ Standard Functions
|
|||
These functions are not required and their API is not formalized, but almost all
|
||||
language modules implement them for consistency across languages. Throughout
|
||||
this discussion, I will use LangType to represent the underlying language type
|
||||
(C_word in chicken, Scheme_Object * in mzscheme, PyObject * in python, etc)
|
||||
(Scheme_Object * in mzscheme, PyObject * in python, etc)
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -236,7 +236,7 @@ The following functions can be used to help debug SWIG parse trees.
|
|||
|
||||
<blockquote>
|
||||
Prints the tag-structure of the parse tree to standard output. <tt>node</tt> is the top-level parse tree node. <tt>prefix</tt> is
|
||||
a string prefix thats added to the start of each line. Normally, you would specify the empty string or NIL for <tt>prefix</tt>.
|
||||
a string prefix that's added to the start of each line. Normally, you would specify the empty string or NIL for <tt>prefix</tt>.
|
||||
This function is called by the <tt>-debug-tags</tt> option to SWIG.
|
||||
|
||||
<pre>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Allegrocl">18 SWIG and Allegro Common Lisp</a></H1>
|
||||
<H1><a name="Allegrocl">20 SWIG and Allegro Common Lisp</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -129,16 +129,16 @@ It is significant to note that, while this is a vendor-specific
|
|||
module, we would like to acknowledge the current and ongoing
|
||||
work by developers in the open source lisp community that are
|
||||
working on similar interfaces to implementation-independent
|
||||
foreign function interfaces (UFFI or CFFI, for example). Such
|
||||
foreign function interfaces (CFFI, for example). Such
|
||||
work can only benefit the lisp community, and we would not
|
||||
be unhappy to see some enterprising folk use this work to add
|
||||
to it.
|
||||
</p>
|
||||
|
||||
<H2><a name="Allegrocl_nn2">18.1 Basics</a></H2>
|
||||
<H2><a name="Allegrocl_nn2">20.1 Basics</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Allegrocl_nn3">18.1.1 Running SWIG</a></H3>
|
||||
<H3><a name="Allegrocl_nn3">20.1.1 Running SWIG</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -155,7 +155,7 @@ SWIG directives. SWIG can be furnished with a header file, but an
|
|||
interface can also be generated without library headers by supplying a
|
||||
simple text file--called the interface file, which is typically named
|
||||
with a <tt>.i</tt> extension--containing any foreign declarations of
|
||||
identifiers you wish to use. The most common approach is to use a an
|
||||
identifiers you wish to use. The most common approach is to use an
|
||||
interface file with directives to parse the needed headers. A straight
|
||||
parse of library headers will result in usable code, but SWIG
|
||||
directives provides much freedom in how a user might tailor the
|
||||
|
|
@ -360,7 +360,7 @@ need to link in the Allegro shared library. The library you create from
|
|||
the C++ wrapper will be what you then load into Allegro CL.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn4">18.1.2 Command Line Options</a></H3>
|
||||
<H3><a name="Allegrocl_nn4">20.1.2 Command Line Options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -396,7 +396,7 @@ See <a href="#Allegrocl_nn47">Section 17.5 Identifier converter
|
|||
functions</a> for more details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn5">18.1.3 Inserting user code into generated files</a></H3>
|
||||
<H3><a name="Allegrocl_nn5">20.1.3 Inserting user code into generated files</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -436,7 +436,7 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Allegrocl_nn6">18.2 Wrapping Overview</a></H2>
|
||||
<H2><a name="Allegrocl_nn6">20.2 Wrapping Overview</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -446,7 +446,7 @@ New users to SWIG are encouraged to read
|
|||
interested in generating an interface to C++.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn7">18.2.1 Function Wrapping</a></H3>
|
||||
<H3><a name="Allegrocl_nn7">20.2.1 Function Wrapping</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -499,7 +499,7 @@ interested in generating an interface to C++.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn8">18.2.2 Foreign Wrappers</a></H3>
|
||||
<H3><a name="Allegrocl_nn8">20.2.2 Foreign Wrappers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -512,7 +512,7 @@ interested in generating an interface to C++.
|
|||
typemap.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn9">18.2.3 FFI Wrappers</a></H3>
|
||||
<H3><a name="Allegrocl_nn9">20.2.3 FFI Wrappers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -593,7 +593,7 @@ char *xxx();
|
|||
ff:def-foreign-call's.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn10">18.2.4 Non-overloaded Defuns</a></H3>
|
||||
<H3><a name="Allegrocl_nn10">20.2.4 Non-overloaded Defuns</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -606,11 +606,11 @@ char *xxx();
|
|||
this function can be manipulated via the <tt>lout</tt> typemap.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn11">18.2.5 Overloaded Defuns</a></H3>
|
||||
<H3><a name="Allegrocl_nn11">20.2.5 Overloaded Defuns</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
In the case of overloaded functions, mulitple layers are
|
||||
In the case of overloaded functions, multiple layers are
|
||||
generated. First, all the overloads for a given name are separated
|
||||
out into groups based on arity, and are wrapped in
|
||||
defmethods. Each method calls a distinct wrapper function, but are
|
||||
|
|
@ -622,7 +622,7 @@ char *xxx();
|
|||
can be manipulated via the <tt>lout</tt> typemap.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn12">18.2.6 What about constant and variable access?</a></H3>
|
||||
<H3><a name="Allegrocl_nn12">20.2.6 What about constant and variable access?</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -635,7 +635,7 @@ char *xxx();
|
|||
into the foreign module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn13">18.2.7 Object Wrapping</a></H3>
|
||||
<H3><a name="Allegrocl_nn13">20.2.7 Object Wrapping</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -657,7 +657,7 @@ char *xxx();
|
|||
foreign function interface.
|
||||
</p>
|
||||
|
||||
<H2><a name="Allegrocl_nn14">18.3 Wrapping Details</a></H2>
|
||||
<H2><a name="Allegrocl_nn14">20.3 Wrapping Details</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -665,7 +665,7 @@ char *xxx();
|
|||
translated into lisp.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn15">18.3.1 Namespaces</a></H3>
|
||||
<H3><a name="Allegrocl_nn15">20.3.1 Namespaces</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -742,7 +742,7 @@ namespace car {
|
|||
function such as <tt>(car '(1 2 3)</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn16">18.3.2 Constants</a></H3>
|
||||
<H3><a name="Allegrocl_nn16">20.3.2 Constants</a></H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -803,7 +803,7 @@ namespace car {
|
|||
not use the <tt>-nocwrap</tt> command-line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn17">18.3.3 Variables</a></H3>
|
||||
<H3><a name="Allegrocl_nn17">20.3.3 Variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -881,7 +881,7 @@ globalvar> (globalvar.nnn::glob_float)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn18">18.3.4 Enumerations</a></H3>
|
||||
<H3><a name="Allegrocl_nn18">20.3.4 Enumerations</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -957,7 +957,7 @@ EXPORT const int ACL_ENUM___FOO3__SWIG_0 = FOO3;
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn19">18.3.5 Arrays</a></H3>
|
||||
<H3><a name="Allegrocl_nn19">20.3.5 Arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1105,10 +1105,10 @@ namespace BAR {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn20">18.3.6 Classes and Structs and Unions (oh my!)</a></H3>
|
||||
<H3><a name="Allegrocl_nn20">20.3.6 Classes and Structs and Unions (oh my!)</a></H3>
|
||||
|
||||
|
||||
<H4><a name="Allegrocl_nn21">18.3.6.1 CLOS wrapping of</a></H4>
|
||||
<H4><a name="Allegrocl_nn21">20.3.6.1 CLOS wrapping of</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1123,7 +1123,7 @@ namespace BAR {
|
|||
integer values.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn22">18.3.6.2 CLOS Inheritance</a></H4>
|
||||
<H4><a name="Allegrocl_nn22">20.3.6.2 CLOS Inheritance</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1136,7 +1136,7 @@ namespace BAR {
|
|||
parameter.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn23">18.3.6.3 Member fields and functions</a></H4>
|
||||
<H4><a name="Allegrocl_nn23">20.3.6.3 Member fields and functions</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1152,7 +1152,7 @@ namespace BAR {
|
|||
the interface does nothing for <tt>friend</tt> directives,
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn24">18.3.6.4 Why not directly access C++ classes using foreign types?</a></H4>
|
||||
<H4><a name="Allegrocl_nn24">20.3.6.4 Why not directly access C++ classes using foreign types?</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1170,11 +1170,11 @@ namespace BAR {
|
|||
use the more robust wrapper functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn25">18.3.7 Templates</a></H3>
|
||||
<H3><a name="Allegrocl_nn25">20.3.7 Templates</a></H3>
|
||||
|
||||
|
||||
|
||||
<H4><a name="Allegrocl_nn26">18.3.7.1 Generating wrapper code for templates</a></H4>
|
||||
<H4><a name="Allegrocl_nn26">20.3.7.1 Generating wrapper code for templates</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1187,7 +1187,7 @@ them. This is done via the
|
|||
directive.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn27">18.3.7.2 Implicit Template instantiation</a></H4>
|
||||
<H4><a name="Allegrocl_nn27">20.3.7.2 Implicit Template instantiation</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1197,7 +1197,7 @@ to include these templated classes in the foreign-type and CLOS
|
|||
class schema.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn28">18.3.8 Typedef, Templates, and Synonym Types</a></H3>
|
||||
<H3><a name="Allegrocl_nn28">20.3.8 Typedef, Templates, and Synonym Types</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1239,7 +1239,7 @@ int zzz(A *inst = 0); /* return inst->x + inst->y */
|
|||
We resolve this issue, by noting synonym relationships between
|
||||
types while generating the interface. A Primary type is selected
|
||||
(more on this below) from the candidate list of synonyms. For
|
||||
all other synonyms, intead of generating a distinct CLOS class
|
||||
all other synonyms, instead of generating a distinct CLOS class
|
||||
definition, we generate a form that expands to:
|
||||
</p>
|
||||
<div class="targetlang">
|
||||
|
|
@ -1277,7 +1277,7 @@ synonym>
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn29">18.3.8.1 Choosing a primary type</a></H4>
|
||||
<H4><a name="Allegrocl_nn29">20.3.8.1 Choosing a primary type</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1298,7 +1298,7 @@ synonym>
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Allegrocl_nn30">18.3.9 Function overloading/Parameter defaulting</a></H3>
|
||||
<H3><a name="Allegrocl_nn30">20.3.9 Function overloading/Parameter defaulting</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1461,7 +1461,7 @@ overload>
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn31">18.3.10 Operator wrapping and Operator overloading</a></H3>
|
||||
<H3><a name="Allegrocl_nn31">20.3.10 Operator wrapping and Operator overloading</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1607,7 +1607,7 @@ opoverload>
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn32">18.3.11 Varargs</a></H3>
|
||||
<H3><a name="Allegrocl_nn32">20.3.11 Varargs</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1628,7 +1628,7 @@ opoverload>
|
|||
with other ways such functions can be wrapped.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn33">18.3.12 C++ Exceptions</a></H3>
|
||||
<H3><a name="Allegrocl_nn33">20.3.12 C++ Exceptions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1640,7 +1640,7 @@ opoverload>
|
|||
implemented.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn34">18.3.13 Pass by value, pass by reference</a></H3>
|
||||
<H3><a name="Allegrocl_nn34">20.3.13 Pass by value, pass by reference</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1652,7 +1652,7 @@ opoverload>
|
|||
newly defined types.
|
||||
</p>
|
||||
|
||||
<H2><a name="Allegrocl_nn35">18.4 Typemaps</a></H2>
|
||||
<H2><a name="Allegrocl_nn35">20.4 Typemaps</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1663,7 +1663,7 @@ opoverload>
|
|||
on <a href="Typemaps.html#Typemaps">Typemaps</a> for more information.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn36">18.4.1 Code Generation in the C++ Wrapper</a></H3>
|
||||
<H3><a name="Allegrocl_nn36">20.4.1 Code Generation in the C++ Wrapper</a></H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -1693,7 +1693,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn37">18.4.1.1 IN Typemap</a></H4>
|
||||
<H4><a name="Allegrocl_nn37">20.4.1.1 IN Typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1728,7 +1728,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn38">18.4.1.2 OUT Typemap</a></H4>
|
||||
<H4><a name="Allegrocl_nn38">20.4.1.2 OUT Typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1752,7 +1752,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn39">18.4.1.3 CTYPE Typemap</a></H4>
|
||||
<H4><a name="Allegrocl_nn39">20.4.1.3 CTYPE Typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1784,7 +1784,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
these <a href="Typemaps.html#Typemaps_nn25">common typemaps</a> here.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn40">18.4.2 Code generation in Lisp wrappers</a></H3>
|
||||
<H3><a name="Allegrocl_nn40">20.4.2 Code generation in Lisp wrappers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1803,7 +1803,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
<a href="#Allegrocl_nn15">16.3.1 Namespaces</a> for details.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn41">18.4.2.1 LIN Typemap</a></H4>
|
||||
<H4><a name="Allegrocl_nn41">20.4.2.1 LIN Typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1846,7 +1846,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn42">18.4.2.2 LOUT Typemap</a></H4>
|
||||
<H4><a name="Allegrocl_nn42">20.4.2.2 LOUT Typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1889,7 +1889,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn43">18.4.2.3 FFITYPE Typemap</a></H4>
|
||||
<H4><a name="Allegrocl_nn43">20.4.2.3 FFITYPE Typemap</a></H4>
|
||||
|
||||
|
||||
|
||||
|
|
@ -1939,7 +1939,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn44">18.4.2.4 LISPTYPE Typemap</a></H4>
|
||||
<H4><a name="Allegrocl_nn44">20.4.2.4 LISPTYPE Typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1959,7 +1959,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn45">18.4.2.5 LISPCLASS Typemap</a></H4>
|
||||
<H4><a name="Allegrocl_nn45">20.4.2.5 LISPCLASS Typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1983,7 +1983,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn46">18.4.3 Modifying SWIG behavior using typemaps</a></H3>
|
||||
<H3><a name="Allegrocl_nn46">20.4.3 Modifying SWIG behavior using typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2017,10 +2017,10 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Allegrocl_nn47">18.5 Identifier Converter functions</a></H2>
|
||||
<H2><a name="Allegrocl_nn47">20.5 Identifier Converter functions</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Allegrocl_nn48">18.5.1 Creating symbols in the lisp environment</a></H3>
|
||||
<H3><a name="Allegrocl_nn48">20.5.1 Creating symbols in the lisp environment</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2041,11 +2041,11 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
of arguments.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn49">18.5.2 Existing identifier-converter functions</a></H3>
|
||||
<H3><a name="Allegrocl_nn49">20.5.2 Existing identifier-converter functions</a></H3>
|
||||
|
||||
|
||||
<p>Two basic identifier routines have been defined.
|
||||
<H4><a name="Allegrocl_nn50">18.5.2.1 identifier-convert-null</a></H4>
|
||||
<H4><a name="Allegrocl_nn50">20.5.2.1 identifier-convert-null</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2054,7 +2054,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
strings, from which a symbol will be created.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn51">18.5.2.2 identifier-convert-lispify</a></H4>
|
||||
<H4><a name="Allegrocl_nn51">20.5.2.2 identifier-convert-lispify</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2063,7 +2063,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
same symbol transformations.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn52">18.5.2.3 Default identifier to symbol conversions</a></H4>
|
||||
<H4><a name="Allegrocl_nn52">20.5.2.3 Default identifier to symbol conversions</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2072,7 +2072,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
default naming conventions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn53">18.5.3 Defining your own identifier-converter</a></H3>
|
||||
<H3><a name="Allegrocl_nn53">20.5.3 Defining your own identifier-converter</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2128,7 +2128,7 @@ indicating the number of arguments passed to the routine indicated by
|
|||
this identifier.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn54">18.5.4 Instructing SWIG to use a particular identifier-converter</a></H3>
|
||||
<H3><a name="Allegrocl_nn54">20.5.4 Instructing SWIG to use a particular identifier-converter</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Android">19 SWIG and Android</a></H1>
|
||||
<H1><a name="Android">22 SWIG and Android</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -31,7 +31,7 @@ This chapter describes SWIG's support of Android.
|
|||
|
||||
|
||||
|
||||
<H2><a name="Android_overview">19.1 Overview</a></H2>
|
||||
<H2><a name="Android_overview">22.1 Overview</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -41,14 +41,14 @@ Everything in the <a href="Java.html#Java">Java chapter</a> applies to generatin
|
|||
This chapter contains a few Android specific notes and examples.
|
||||
</p>
|
||||
|
||||
<H2><a name="Android_examples">19.2 Android examples</a></H2>
|
||||
<H2><a name="Android_examples">22.2 Android examples</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Android_examples_intro">19.2.1 Examples introduction</a></H3>
|
||||
<H3><a name="Android_examples_intro">22.2.1 Examples introduction</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
The examples require the <a href="http://developer.android.com/sdk/index.html">Android SDK</a> and <a href="http://developer.android.com/tools/sdk/ndk/index.html">Android NDK</a> which can be installed as per instructions in the links.
|
||||
The examples require the <a href="https://developer.android.com/sdk/">Android SDK</a> and <a href="https://developer.android.com/ndk/">Android NDK</a> which can be installed as per instructions in the links.
|
||||
The Eclipse version is not required for these examples as just the command line tools are used (shown for Linux as the host, but Windows will be very similar, if not identical in most places).
|
||||
Add the SDK tools and NDK tools to your path and create a directory somewhere for your Android projects (adjust PATH as necessary to where you installed the tools):
|
||||
</p>
|
||||
|
|
@ -77,7 +77,7 @@ $ android list targets
|
|||
The following examples are shipped with SWIG under the Examples/android directory and include a Makefile to build and install each example.
|
||||
</p>
|
||||
|
||||
<H3><a name="Android_example_simple">19.2.2 Simple C example</a></H3>
|
||||
<H3><a name="Android_example_simple">22.2.2 Simple C example</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -326,7 +326,7 @@ include $(BUILD_SHARED_LIBRARY)
|
|||
</div>
|
||||
|
||||
<p>
|
||||
See the <a href="http://developer.android.com/sdk/ndk/index.html">Android NDK documentation</a> for more on the NDK build system and getting started with the NDK.
|
||||
See the <a href="https://developer.android.com/ndk/">Android NDK documentation</a> for more on the NDK build system and getting started with the NDK.
|
||||
A simple invocation of ndk-build will compile the .c files and generate a shared object/system library. Output will be similar to:
|
||||
</p>
|
||||
|
||||
|
|
@ -399,7 +399,7 @@ Run the app again and this time you will see the output pictured below, showing
|
|||
<center><img src="android-simple.png" alt="Android screenshot of SwigSimple example"></center>
|
||||
|
||||
|
||||
<H3><a name="Android_example_class">19.2.3 C++ class example</a></H3>
|
||||
<H3><a name="Android_example_class">22.2.3 C++ class example</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -409,7 +409,7 @@ All the steps required to compile and use a simple hierarchy of classes for shap
|
|||
|
||||
<p>
|
||||
First create an Android project called <tt>SwigClass</tt> in a subdirectory called <tt>class</tt>.
|
||||
The steps below create and build a the JNI C++ app.
|
||||
The steps below create and build the JNI C++ app.
|
||||
Adjust the <tt>--target</tt> id as mentioned earlier in the <a href="Android.html#Android_examples_intro">Examples introduction</a>.
|
||||
</p>
|
||||
|
||||
|
|
@ -747,7 +747,7 @@ Run the app to see the result of calling the C++ code from Java:
|
|||
|
||||
<center><img src="android-class.png" alt="Android screenshot of SwigClass example"></center>
|
||||
|
||||
<H3><a name="Android_examples_other">19.2.4 Other examples</a></H3>
|
||||
<H3><a name="Android_examples_other">22.2.4 Other examples</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -759,7 +759,7 @@ Note that the 'extend' example is demonstrates the directors feature.
|
|||
Normally C++ exception handling and the STL is not available by default in the version of g++ shipped with Android, but this example turns these features on as described in the next section.
|
||||
</p>
|
||||
|
||||
<H2><a name="Android_stl">19.3 C++ STL</a></H2>
|
||||
<H2><a name="Android_stl">22.3 C++ STL</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Arguments">10 Argument Handling</a></H1>
|
||||
<H1><a name="Arguments">13 Argument Handling</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -32,7 +32,7 @@
|
|||
|
||||
|
||||
<p>
|
||||
In Chapter 3, SWIG's treatment of basic datatypes and pointers was
|
||||
In Chapter 5, SWIG's treatment of basic datatypes and pointers was
|
||||
described. In particular, primitive types such as <tt>int</tt> and
|
||||
<tt>double</tt> are mapped to corresponding types in the target
|
||||
language. For everything else, pointers are used to refer to
|
||||
|
|
@ -43,7 +43,7 @@ return multiple values through the arguments of a function. This chapter
|
|||
describes some of the techniques for doing this.
|
||||
</p>
|
||||
|
||||
<H2><a name="Arguments_nn2">10.1 The typemaps.i library</a></H2>
|
||||
<H2><a name="Arguments_nn2">13.1 The typemaps.i library</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -51,7 +51,7 @@ This section describes the <tt>typemaps.i</tt> library file--commonly used to
|
|||
change certain properties of argument conversion.
|
||||
</p>
|
||||
|
||||
<H3><a name="Arguments_nn3">10.1.1 Introduction</a></H3>
|
||||
<H3><a name="Arguments_nn3">13.1.1 Introduction</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -195,7 +195,7 @@ else. To clear a typemap, the <tt>%clear</tt> directive should be used. For e
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Arguments_nn4">10.1.2 Input parameters</a></H3>
|
||||
<H3><a name="Arguments_nn4">13.1.2 Input parameters</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -248,7 +248,7 @@ When the function is used in the scripting language interpreter, it will work li
|
|||
result = add(3, 4)
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Arguments_nn5">10.1.3 Output parameters</a></H3>
|
||||
<H3><a name="Arguments_nn5">13.1.3 Output parameters</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -315,7 +315,7 @@ iresult, dresult = foo(3.5, 2)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Arguments_nn6">10.1.4 Input/Output parameters</a></H3>
|
||||
<H3><a name="Arguments_nn6">13.1.4 Input/Output parameters</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -380,7 +380,7 @@ rather than directly overwriting the value of the original input object.
|
|||
SWIG. Backwards compatibility is preserved, but deprecated.
|
||||
</p>
|
||||
|
||||
<H3><a name="Arguments_nn7">10.1.5 Using different names</a></H3>
|
||||
<H3><a name="Arguments_nn7">13.1.5 Using different names</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -414,7 +414,7 @@ Typemap declarations are lexically scoped so a typemap takes effect from the poi
|
|||
file or a matching <tt>%clear</tt> declaration.
|
||||
</p>
|
||||
|
||||
<H2><a name="Arguments_nn8">10.2 Applying constraints to input values</a></H2>
|
||||
<H2><a name="Arguments_nn8">13.2 Applying constraints to input values</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -424,7 +424,7 @@ insure that a value is positive, or that a pointer is non-NULL. This
|
|||
can be accomplished including the <tt>constraints.i</tt> library file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Arguments_nn9">10.2.1 Simple constraint example</a></H3>
|
||||
<H3><a name="Arguments_nn9">13.2.1 Simple constraint example</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -450,7 +450,7 @@ the arguments violate the constraint condition, a scripting language
|
|||
exception will be raised. As a result, it is possible to catch bad
|
||||
values, prevent mysterious program crashes and so on.</p>
|
||||
|
||||
<H3><a name="Arguments_nn10">10.2.2 Constraint methods</a></H3>
|
||||
<H3><a name="Arguments_nn10">13.2.2 Constraint methods</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -466,7 +466,7 @@ NONNULL Non-NULL pointer (pointers only).
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Arguments_nn11">10.2.3 Applying constraints to new datatypes</a></H3>
|
||||
<H3><a name="Arguments_nn11">13.2.3 Applying constraints to new datatypes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="CCache">17 Using SWIG with ccache - ccache-swig(1) manpage</a></H1>
|
||||
<H1><a name="CCache">21 Using SWIG with ccache - ccache-swig(1) manpage</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -35,7 +35,7 @@
|
|||
|
||||
|
||||
<p>
|
||||
<H2><a name="CCache_nn2">17.1 NAME</a></H2>
|
||||
<H2><a name="CCache_nn2">21.1 NAME</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -43,7 +43,7 @@
|
|||
ccache-swig - a fast compiler cache
|
||||
|
||||
<p>
|
||||
<H2><a name="CCache_nn3">17.2 SYNOPSIS</a></H2>
|
||||
<H2><a name="CCache_nn3">21.2 SYNOPSIS</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -53,7 +53,7 @@ ccache-swig <compiler> [COMPILER OPTIONS]
|
|||
<p>
|
||||
<compiler> [COMPILER OPTIONS]
|
||||
<p>
|
||||
<H2><a name="CCache_nn4">17.3 DESCRIPTION</a></H2>
|
||||
<H2><a name="CCache_nn4">21.3 DESCRIPTION</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -62,7 +62,7 @@ by caching previous compiles and detecting when the same compile is
|
|||
being done again. ccache-swig is ccache plus support for SWIG. ccache
|
||||
and ccache-swig are used interchangeably in this document.
|
||||
<p>
|
||||
<H2><a name="CCache_nn5">17.4 OPTIONS SUMMARY</a></H2>
|
||||
<H2><a name="CCache_nn5">21.4 OPTIONS SUMMARY</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -82,7 +82,7 @@ Here is a summary of the options to ccache-swig.
|
|||
</pre>
|
||||
|
||||
<p>
|
||||
<H2><a name="CCache_nn6">17.5 OPTIONS</a></H2>
|
||||
<H2><a name="CCache_nn6">21.5 OPTIONS</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -124,7 +124,7 @@ rounded down to the nearest multiple of 16 kilobytes.
|
|||
<p>
|
||||
</dl>
|
||||
<p>
|
||||
<H2><a name="CCache_nn7">17.6 INSTALLATION</a></H2>
|
||||
<H2><a name="CCache_nn7">21.6 INSTALLATION</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -156,7 +156,7 @@ This will work as long as /usr/local/bin comes before the path to gcc
|
|||
Note! Do not use a hard link, use a symbolic link. A hardlink will
|
||||
cause "interesting" problems.
|
||||
<p>
|
||||
<H2><a name="CCache_nn8">17.7 EXTRA OPTIONS</a></H2>
|
||||
<H2><a name="CCache_nn8">21.7 EXTRA OPTIONS</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -176,7 +176,7 @@ file). By using --ccache-skip you can force an option to not be
|
|||
treated as an input file name and instead be passed along to the
|
||||
compiler as a command line option.
|
||||
<p>
|
||||
<H2><a name="CCache_nn9">17.8 ENVIRONMENT VARIABLES</a></H2>
|
||||
<H2><a name="CCache_nn9">21.8 ENVIRONMENT VARIABLES</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -315,7 +315,7 @@ the use of '#pragma SWIG'.
|
|||
<p>
|
||||
</dl>
|
||||
<p>
|
||||
<H2><a name="CCache_nn10">17.9 CACHE SIZE MANAGEMENT</a></H2>
|
||||
<H2><a name="CCache_nn10">21.9 CACHE SIZE MANAGEMENT</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -328,7 +328,7 @@ When these limits are reached ccache will reduce the cache to 20%
|
|||
below the numbers you specified in order to avoid doing the cache
|
||||
clean operation too often.
|
||||
<p>
|
||||
<H2><a name="CCache_nn11">17.10 CACHE COMPRESSION</a></H2>
|
||||
<H2><a name="CCache_nn11">21.10 CACHE COMPRESSION</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -339,7 +339,7 @@ performance slowdown, it significantly increases the number of files
|
|||
that fit in the cache. You can turn off compression setting the
|
||||
CCACHE_NOCOMPRESS environment variable.
|
||||
<p>
|
||||
<H2><a name="CCache_nn12">17.11 HOW IT WORKS</a></H2>
|
||||
<H2><a name="CCache_nn12">21.11 HOW IT WORKS</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -364,7 +364,7 @@ compiler output that you would get without the cache. If you ever
|
|||
discover a case where ccache changes the output of your compiler then
|
||||
please let me know.
|
||||
<p>
|
||||
<H2><a name="CCache_nn13">17.12 USING CCACHE WITH DISTCC</a></H2>
|
||||
<H2><a name="CCache_nn13">21.12 USING CCACHE WITH DISTCC</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -378,7 +378,7 @@ option. You just need to set the environment variable CCACHE_PREFIX to
|
|||
'distcc' and ccache will prefix the command line used with the
|
||||
compiler with the command 'distcc'.
|
||||
<p>
|
||||
<H2><a name="CCache_nn14">17.13 SHARING A CACHE</a></H2>
|
||||
<H2><a name="CCache_nn14">21.13 SHARING A CACHE</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -407,11 +407,11 @@ following conditions need to be met:
|
|||
versions of ccache that do not support compression.
|
||||
</ul>
|
||||
<p>
|
||||
<H2><a name="CCache_nn15">17.14 HISTORY</a></H2>
|
||||
<H2><a name="CCache_nn15">21.14 HISTORY</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
ccache was inspired by the compilercache shell script script written
|
||||
ccache was inspired by the compilercache shell script written
|
||||
by Erik Thiele and I would like to thank him for an excellent piece of
|
||||
work. See
|
||||
<a href="http://www.erikyyy.de/compilercache/">http://www.erikyyy.de/compilercache/</a>
|
||||
|
|
@ -423,7 +423,7 @@ I wrote ccache because I wanted to get a bit more speed out of a
|
|||
compiler cache and I wanted to remove some of the limitations of the
|
||||
shell-script version.
|
||||
<p>
|
||||
<H2><a name="CCache_nn16">17.15 DIFFERENCES FROM COMPILERCACHE</a></H2>
|
||||
<H2><a name="CCache_nn16">21.15 DIFFERENCES FROM COMPILERCACHE</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -441,7 +441,7 @@ are:
|
|||
<li> ccache avoids a double call to cpp on a cache miss
|
||||
</ul>
|
||||
<p>
|
||||
<H2><a name="CCache_nn17">17.16 CREDITS</a></H2>
|
||||
<H2><a name="CCache_nn17">21.16 CREDITS</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -453,12 +453,12 @@ Thanks to the following people for their contributions to ccache
|
|||
<li> Paul Russell for many suggestions and the debian packaging
|
||||
</ul>
|
||||
<p>
|
||||
<H2><a name="CCache_nn18">17.17 AUTHOR</a></H2>
|
||||
<H2><a name="CCache_nn18">21.17 AUTHOR</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
ccache was written by Andrew Tridgell
|
||||
<a href="http://samba.org/~tridge/">http://samba.org/~tridge/</a>.
|
||||
<a href="https://www.samba.org/~tridge/">https://www.samba.org/~tridge/</a>.
|
||||
ccache was adapted to create ccache-swig for use with SWIG by William Fulton.
|
||||
<p>
|
||||
If you wish to report a problem or make a suggestion then please email
|
||||
|
|
|
|||
|
|
@ -32,6 +32,7 @@
|
|||
<li><a href="#CPlusPlus11_alias_templates">Type alias and alias templates</a>
|
||||
<li><a href="#CPlusPlus11_unrestricted_unions">Unrestricted unions</a>
|
||||
<li><a href="#CPlusPlus11_variadic_templates">Variadic templates</a>
|
||||
<li><a href="#CPlusPlus11_new_char_literals">New character literals</a>
|
||||
<li><a href="#CPlusPlus11_new_string_literals">New string literals</a>
|
||||
<li><a href="#CPlusPlus11_user_defined_literals">User-defined literals</a>
|
||||
<li><a href="#CPlusPlus11_thread_local_storage">Thread-local storage</a>
|
||||
|
|
@ -42,6 +43,7 @@
|
|||
<li><a href="#CPlusPlus11_noexcept">Exception specifications and noexcept</a>
|
||||
<li><a href="#CPlusPlus11_alignment">Control and query object alignment</a>
|
||||
<li><a href="#CPlusPlus11_attributes">Attributes</a>
|
||||
<li><a href="#CPlusPlus11_ref_qualifiers">Methods with ref-qualifiers</a>
|
||||
</ul>
|
||||
<li><a href="#CPlusPlus11_standard_library_changes">Standard library changes</a>
|
||||
<ul>
|
||||
|
|
@ -334,6 +336,10 @@ int i; int j;
|
|||
decltype(i+j) k; // syntax error
|
||||
</pre></div>
|
||||
|
||||
<p>SWIG does not support <tt>auto</tt> as a type specifier for variables, only
|
||||
for specifying the return type of <a href="#CPlusPlus11_lambda_functions_and_expressions">lambdas</a>
|
||||
and <a href="#CPlusPlus11_alternate_function_syntax">functions</a>.</p>
|
||||
|
||||
<H3><a name="CPlusPlus11_range_based_for_loop">7.2.7 Range-based for-loop</a></H3>
|
||||
|
||||
|
||||
|
|
@ -713,7 +719,24 @@ const int SIZE = sizeof...(ClassName<int, int>);
|
|||
In the above example <tt>SIZE</tt> is of course wrapped as a constant.
|
||||
</p>
|
||||
|
||||
<H3><a name="CPlusPlus11_new_string_literals">7.2.19 New string literals</a></H3>
|
||||
<H3><a name="CPlusPlus11_new_char_literals">7.2.19 New character literals</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
C++11 adds support for UCS-2 and UCS-4 character literals.
|
||||
These character literals are preceded by either 'u' or 'U'.
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
char16_t a = u'a';
|
||||
char32_t b = U'b';
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
<b>Compatibility note:</b> SWIG-4.0.0 was the first version to support these Universal Coded Character Set (UCS) character literals.
|
||||
</p>
|
||||
|
||||
<H3><a name="CPlusPlus11_new_string_literals">7.2.20 New string literals</a></H3>
|
||||
|
||||
|
||||
<p>SWIG supports wide string and Unicode string constants and raw string literals.</p>
|
||||
|
|
@ -743,7 +766,7 @@ Note: There is a bug currently where SWIG's preprocessor incorrectly parses an o
|
|||
inside raw string literals.
|
||||
</p>
|
||||
|
||||
<H3><a name="CPlusPlus11_user_defined_literals">7.2.20 User-defined literals</a></H3>
|
||||
<H3><a name="CPlusPlus11_user_defined_literals">7.2.21 User-defined literals</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -810,7 +833,7 @@ OutputType var2 = 1234_suffix;
|
|||
OutputType var3 = 3.1416_suffix;
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="CPlusPlus11_thread_local_storage">7.2.21 Thread-local storage</a></H3>
|
||||
<H3><a name="CPlusPlus11_thread_local_storage">7.2.22 Thread-local storage</a></H3>
|
||||
|
||||
|
||||
<p>SWIG correctly parses the <tt>thread_local</tt> keyword. For example, variables
|
||||
|
|
@ -830,7 +853,7 @@ A variable will be thread local if accessed from different threads from the targ
|
|||
same way that it will be thread local if accessed from C++ code.
|
||||
</p>
|
||||
|
||||
<H3><a name="CPlusPlus11_defaulted_deleted">7.2.22 Explicitly defaulted functions and deleted functions</a></H3>
|
||||
<H3><a name="CPlusPlus11_defaulted_deleted">7.2.23 Explicitly defaulted functions and deleted functions</a></H3>
|
||||
|
||||
|
||||
<p>SWIG handles explicitly defaulted functions, that is, <tt>= default</tt> added to a function declaration. Deleted definitions, which are also called deleted functions, have <tt>= delete</tt> added to the function declaration.
|
||||
|
|
@ -868,16 +891,17 @@ This is a C++ compile time check and SWIG does not make any attempt to detect if
|
|||
so in this case it is entirely possible to pass an int instead of a double to <tt>f</tt> from Java, Python etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="CPlusPlus11_type_long_long_int">7.2.23 Type long long int</a></H3>
|
||||
<H3><a name="CPlusPlus11_type_long_long_int">7.2.24 Type long long int</a></H3>
|
||||
|
||||
|
||||
<p>SWIG correctly parses and uses the new <tt>long long</tt> type already introduced in C99 some time ago.</p>
|
||||
|
||||
<H3><a name="CPlusPlus11_static_assertions">7.2.24 Static assertions</a></H3>
|
||||
<H3><a name="CPlusPlus11_static_assertions">7.2.25 Static assertions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG correctly parses the new <tt>static_assert</tt> declarations.
|
||||
SWIG correctly parses the new <tt>static_assert</tt> declarations (though 3.0.12 and earlier
|
||||
had a bug which meant this wasn't accepted at file scope).
|
||||
This is a C++ compile time directive so there isn't anything useful that SWIG can do with it.
|
||||
</p>
|
||||
|
||||
|
|
@ -888,7 +912,7 @@ struct Check {
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="CPlusPlus11_sizeof">7.2.25 Allow sizeof to work on members of classes without an explicit object</a></H3>
|
||||
<H3><a name="CPlusPlus11_sizeof">7.2.26 Allow sizeof to work on members of classes without an explicit object</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -909,7 +933,7 @@ const int SIZE = sizeof(A::member); // does not work with C++03. Okay with C++11
|
|||
8
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="CPlusPlus11_noexcept">7.2.26 Exception specifications and noexcept</a></H3>
|
||||
<H3><a name="CPlusPlus11_noexcept">7.2.27 Exception specifications and noexcept</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -925,7 +949,7 @@ int noex2(int) noexcept(true);
|
|||
int noex3(int, bool) noexcept(false);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="CPlusPlus11_alignment">7.2.27 Control and query object alignment</a></H3>
|
||||
<H3><a name="CPlusPlus11_alignment">7.2.28 Control and query object alignment</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -957,7 +981,7 @@ Use the preprocessor to work around this for now:
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="CPlusPlus11_attributes">7.2.28 Attributes</a></H3>
|
||||
<H3><a name="CPlusPlus11_attributes">7.2.29 Attributes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -970,6 +994,104 @@ int [[attr1]] i [[attr2, attr3]];
|
|||
[[noreturn, nothrow]] void f [[noreturn]] ();
|
||||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="CPlusPlus11_ref_qualifiers">7.2.30 Methods with ref-qualifiers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
C++11 non-static member functions can be declared with ref-qualifiers.
|
||||
Member functions declared with a <tt>&</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>
|
||||
|
||||
|
||||
|
|
@ -994,7 +1116,8 @@ Variadic template support requires further work to provide substantial tuple wra
|
|||
|
||||
<p>
|
||||
The new hash tables in the STL are <tt>unordered_set</tt>, <tt>unordered_multiset</tt>, <tt>unordered_map</tt>, <tt>unordered_multimap</tt>.
|
||||
These are not available in SWIG, but in principle should be easily implemented by adapting the current STL containers.
|
||||
These are not available in all target languages.
|
||||
Any missing support can in principle be easily implemented by adapting the current STL containers.
|
||||
</p>
|
||||
|
||||
<H3><a name="CPlusPlus11_regular_expressions">7.3.4 Regular expressions</a></H3>
|
||||
|
|
@ -1175,5 +1298,6 @@ Phew, that is a lot of hard work to get a callback working.
|
|||
You could just go with the more attractive option of just using <tt>double</tt> as the return type in the function declaration instead of <tt>result_of</tt>!
|
||||
</p>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
60
Doc/Manual/CPlusPlus14.html
Normal file
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>
|
||||
42
Doc/Manual/CPlusPlus20.html
Normal file
42
Doc/Manual/CPlusPlus20.html
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG and C++20</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="CPlusPlus20">10 SWIG and C++20</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#CPlusPlus20_introduction">Introduction</a>
|
||||
<li><a href="#CPlusPlus20_core_language_changes">Core language changes</a>
|
||||
<li><a href="#CPlusPlus20_standard_library_changes">Standard library changes</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
|
||||
|
||||
<H2><a name="CPlusPlus20_introduction">10.1 Introduction</a></H2>
|
||||
|
||||
|
||||
<p>This chapter gives you a brief overview about the SWIG
|
||||
implementation of the C++20 standard.
|
||||
Work has only just begun on adding C++20 support.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Compatibility note:</b> SWIG-4.1.0 is the first version to support any C++20 features.
|
||||
</p>
|
||||
|
||||
<H2><a name="CPlusPlus20_core_language_changes">10.2 Core language changes</a></H2>
|
||||
|
||||
|
||||
<H2><a name="CPlusPlus20_standard_library_changes">10.3 Standard library changes</a></H2>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -6,7 +6,7 @@
|
|||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="CSharp">20 SWIG and C#</a></H1>
|
||||
<H1><a name="CSharp">23 SWIG and C#</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -44,7 +44,8 @@
|
|||
<li><a href="#CSharp_date_marshalling">Date marshalling using the csin typemap and associated attributes</a>
|
||||
<li><a href="#CSharp_date_properties">A date example demonstrating marshalling of C# properties</a>
|
||||
<li><a href="#CSharp_date_pre_post_directors">Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a>
|
||||
<li><a href="#CSharp_partial_classes">Turning wrapped classes into partial classes</a>
|
||||
<li><a href="#CSharp_partial_classes">Turning proxy classes into partial classes</a>
|
||||
<li><a href="#CSharp_sealed_proxy_class">Turning proxy classes into sealed classes</a>
|
||||
<li><a href="#CSharp_extending_proxy_class">Extending proxy classes with additional C# code</a>
|
||||
<li><a href="#CSharp_enum_underlying_type">Underlying type for enums</a>
|
||||
</ul>
|
||||
|
|
@ -54,7 +55,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="CSharp_introduction">20.1 Introduction</a></H2>
|
||||
<H2><a name="CSharp_introduction">23.1 Introduction</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -63,18 +64,24 @@ The wrapper code implementation uses C# and the Platform Invoke (PInvoke) interf
|
|||
The PInvoke interface has been chosen over Microsoft's Managed C++ interface as it is portable to both Microsoft Windows and non-Microsoft platforms.
|
||||
PInvoke is part of the ECMA/ISO C# specification.
|
||||
It is also better suited for robust production environments due to the Managed C++ flaw called the
|
||||
<a href="http://msdn.microsoft.com/en-us/library/aa290048(VS.71).aspx">Mixed DLL Loading Problem</a>.
|
||||
<a href="https://msdn.microsoft.com/en-us/ie/aa290048(v=vs.94)">Mixed DLL Loading Problem</a>.
|
||||
SWIG C# works equally well on non-Microsoft operating systems such as Linux, Solaris and Apple Mac using
|
||||
<a href="http://www.mono-project.com/Main_Page">Mono</a> and <a href="http://www.dotgnu.org/pnet.html">Portable.NET</a>.
|
||||
<a href="https://www.mono-project.com/Main_Page/">Mono</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
SWIG 3 and later requires .NET 2.0 at a minimum.
|
||||
There are some minor exceptions, where the minimum required is .NET 4.0.
|
||||
This is when using the <tt>std::complex</tt> and <tt>std::list</tt> STL containers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To get the most out of this chapter an understanding of interop is required.
|
||||
The <a href="http://msdn.microsoft.com">Microsoft Developer Network (MSDN)</a> has a good reference guide in a section titled "Interop Marshaling".
|
||||
Monodoc, available from the Mono project, has a very useful section titled <a href="http://www.mono-project.com/docs/advanced/pinvoke/">Interop with native libraries</a>.
|
||||
The <a href="https://msdn.microsoft.com">Microsoft Developer Network (MSDN)</a> has a good reference guide in a section titled "Interop Marshaling".
|
||||
Monodoc, available from the Mono project, has a very useful section titled <a href="https://www.mono-project.com/docs/advanced/pinvoke/">Interop with native libraries</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_introduction_swig2_compatibility">20.1.1 SWIG 2 Compatibility</a></H3>
|
||||
<H3><a name="CSharp_introduction_swig2_compatibility">23.1.1 SWIG 2 Compatibility</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -82,7 +89,7 @@ In order to minimize name collisions between names generated based on input to S
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="CSharp_commandline">20.1.2 Additional command line options</a></H3>
|
||||
<H3><a name="CSharp_commandline">23.1.2 Additional command line options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -134,7 +141,7 @@ Note that the file extension (.cs) will not be automatically added and needs to
|
|||
Due to possible compiler limits it is not advisable to use <tt>-outfile</tt> for large projects.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_differences_java">20.2 Differences to the Java module</a></H2>
|
||||
<H2><a name="CSharp_differences_java">23.2 Differences to the Java module</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -231,8 +238,9 @@ javacode -> cscode
|
|||
javaimports -> csimports
|
||||
javabody -> csbody
|
||||
javafinalize -> csfinalize
|
||||
javadestruct -> csdestruct
|
||||
javadestruct_derived -> csdestruct_derived
|
||||
javadestruct -> csdisposing and csdispose
|
||||
javadestruct_derived -> csdisposing_derived and csdispose_derived
|
||||
javainterfacemodifiers -> csinterfacemodifiers
|
||||
javainterfacecode -> csinterfacecode
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -555,7 +563,7 @@ Windows users can also get the examples working using a
|
|||
<a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> environment for automatic configuration of the example makefiles.
|
||||
Any one of the 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">23.3 Void pointers</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -573,7 +581,7 @@ void * f(void *v);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="CSharp_arrays">20.4 C# Arrays</a></H2>
|
||||
<H2><a name="CSharp_arrays">23.4 C# Arrays</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -585,7 +593,7 @@ with one of the following three approaches; namely the SWIG C arrays library, P/
|
|||
pinned arrays.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_arrays_swig_library">20.4.1 The SWIG C arrays library</a></H3>
|
||||
<H3><a name="CSharp_arrays_swig_library">23.4.1 The SWIG C arrays library</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -622,7 +630,7 @@ example.print_array(c.cast()); // Pass to C
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling">20.4.2 Managed arrays using P/Invoke default array marshalling</a></H3>
|
||||
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling">23.4.2 Managed arrays using P/Invoke default array marshalling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -642,7 +650,7 @@ passing a direct reference as described in the next section.
|
|||
|
||||
<p>
|
||||
For more information on the subject, see the
|
||||
<a href="http://msdn.microsoft.com/en-us/library/z6cfh6e6(VS.80).aspx">Default Marshaling for Arrays</a> article
|
||||
<a href="https://docs.microsoft.com/en-us/dotnet/framework/interop/default-marshaling-for-arrays">Default Marshaling for Arrays</a> article
|
||||
on MSDN.
|
||||
</p>
|
||||
|
||||
|
|
@ -677,7 +685,7 @@ As a result, we get the following method in the module class:
|
|||
<div class="code">
|
||||
<pre>
|
||||
public static void myArrayCopy(int[] sourceArray, int[] targetArray, int nitems) {
|
||||
examplePINVOKE.myArrayCopy(sourceArray, targetArray, nitems);
|
||||
examplePINVOKE.myArrayCopy(sourceArray, targetArray, nitems);
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -749,7 +757,7 @@ and intermediary class method
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_arrays_pinning">20.4.3 Managed arrays using pinning</a></H3>
|
||||
<H3><a name="CSharp_arrays_pinning">23.4.3 Managed arrays using pinning</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -762,7 +770,7 @@ another thread may produce enough garbage to trigger garbage collection.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
For more information, see the <a href="http://msdn.microsoft.com/en-us/library/f58wzh21(VS.80).aspx">fixed statement</a> in the C# language reference.
|
||||
For more information, see the <a href="https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/fixed-statement">fixed statement</a> in the C# language reference.
|
||||
</p>
|
||||
|
||||
|
||||
|
|
@ -844,7 +852,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">23.5 C# Exceptions</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -941,7 +949,7 @@ set so should only be used when a C# exception is not created.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="CSharp_exception_example_check_typemap">20.5.1 C# exception example using "check" typemap</a></H3>
|
||||
<H3><a name="CSharp_exception_example_check_typemap">23.5.1 C# exception example using "check" typemap</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -997,9 +1005,9 @@ When the following C# code is executed:
|
|||
<div class="code">
|
||||
<pre>
|
||||
public class runme {
|
||||
static void Main() {
|
||||
example.positivesonly(-1);
|
||||
}
|
||||
static void Main() {
|
||||
example.positivesonly(-1);
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1123,7 +1131,7 @@ method and C# code does not handle pending exceptions via the canthrow attribute
|
|||
Actually it will issue this warning for any function beginning with <tt>SWIG_CSharpSetPendingException</tt>.
|
||||
</P>
|
||||
|
||||
<H3><a name="CSharp_exception_example_percent_exception">20.5.2 C# exception example using %exception</a></H3>
|
||||
<H3><a name="CSharp_exception_example_percent_exception">23.5.2 C# exception example using %exception</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1188,7 +1196,7 @@ The managed code generated does check for the pending exception as mentioned ear
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_exception_example_exception_specifications">20.5.3 C# exception example using exception specifications</a></H3>
|
||||
<H3><a name="CSharp_exception_example_exception_specifications">23.5.3 C# exception example using exception specifications</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1244,7 +1252,7 @@ SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
|
|||
Multiple catch handlers are generated should there be more than one exception specifications declared.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_custom_application_exception">20.5.4 Custom C# ApplicationException example</a></H3>
|
||||
<H3><a name="CSharp_custom_application_exception">23.5.4 Custom C# ApplicationException example</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1378,7 +1386,7 @@ try {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="CSharp_directors">20.6 C# Directors</a></H2>
|
||||
<H2><a name="CSharp_directors">23.6 C# Directors</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1391,7 +1399,7 @@ The following sections provide information on the C# director implementation and
|
|||
However, the <a href="Java.html#Java_directors">Java directors</a> section should also be read in order to gain more insight into directors.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_directors_example">20.6.1 Directors example</a></H3>
|
||||
<H3><a name="CSharp_directors_example">23.6.1 Directors example</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1512,7 +1520,7 @@ CSharpDerived - UIntMethod(123)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_directors_implementation">20.6.2 Directors implementation</a></H3>
|
||||
<H3><a name="CSharp_directors_implementation">23.6.2 Directors implementation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1574,9 +1582,9 @@ public class Base : global::System.IDisposable {
|
|||
|
||||
private void SwigDirectorConnect() {
|
||||
if (SwigDerivedClassHasMethod("UIntMethod", swigMethodTypes0))
|
||||
swigDelegate0 = new SwigDelegateBase_0(SwigDirectorUIntMethod);
|
||||
swigDelegate0 = new SwigDelegateBase_0(SwigDirectorMethodUIntMethod);
|
||||
if (SwigDerivedClassHasMethod("BaseBoolMethod", swigMethodTypes1))
|
||||
swigDelegate1 = new SwigDelegateBase_1(SwigDirectorBaseBoolMethod);
|
||||
swigDelegate1 = new SwigDelegateBase_1(SwigDirectorMethodBaseBoolMethod);
|
||||
examplePINVOKE.Base_director_connect(swigCPtr, swigDelegate0, swigDelegate1);
|
||||
}
|
||||
|
||||
|
|
@ -1586,11 +1594,11 @@ public class Base : global::System.IDisposable {
|
|||
return hasDerivedMethod;
|
||||
}
|
||||
|
||||
private uint SwigDirectorUIntMethod(uint x) {
|
||||
private uint SwigDirectorMethodUIntMethod(uint x) {
|
||||
return UIntMethod(x);
|
||||
}
|
||||
|
||||
private void SwigDirectorBaseBoolMethod(global::System.IntPtr b, bool flag) {
|
||||
private void SwigDirectorMethodBaseBoolMethod(global::System.IntPtr b, bool flag) {
|
||||
BaseBoolMethod(new Base(b, false), flag);
|
||||
}
|
||||
|
||||
|
|
@ -1619,9 +1627,9 @@ It uses a support method, <tt>SwigDerivedClassHasMethod()</tt>, which simply use
|
|||
BaseBoolMethod, with the list of required parameter types, exists in a subclass.
|
||||
If it does not exist, the delegate is not initialised as there is no need for unmanaged code to call back into managed C# code.
|
||||
However, if there is an overridden method in any subclass, the delegate is required.
|
||||
It is then initialised to the <tt>SwigDirectorBaseBoolMethod</tt> which in turn will call <tt>BaseBoolMethod</tt> if invoked.
|
||||
It is then initialised to the <tt>SwigDirectorMethodBaseBoolMethod</tt> which in turn will call <tt>BaseBoolMethod</tt> if invoked.
|
||||
The delegate is not initialised to the <tt>BaseBoolMethod</tt> directly as quite often types will need marshalling from the unmanaged type
|
||||
to the managed type in which case an intermediary method (<tt>SwigDirectorBaseBoolMethod</tt>) is required for the marshalling.
|
||||
to the managed type in which case an intermediary method (<tt>SwigDirectorMethodBaseBoolMethod</tt>) is required for the marshalling.
|
||||
In this case, the C# <tt>Base</tt> class needs to be created from the unmanaged <tt>IntPtr</tt> type.
|
||||
</p>
|
||||
|
||||
|
|
@ -1720,7 +1728,7 @@ before SWIG parses the Base class will change all the delegates to <tt>internal<
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_director_caveats">20.6.3 Director caveats</a></H3>
|
||||
<H3><a name="CSharp_director_caveats">23.6.3 Director caveats</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1768,11 +1776,11 @@ However, a call from C# to <tt>CSharpDefaults.DefaultMethod()</tt> will of cours
|
|||
should pass the call on to <tt>CSharpDefaults.DefaultMethod(int)</tt>using the C++ default value, as shown above.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_multiple_modules">20.7 Multiple modules</a></H2>
|
||||
<H2><a name="CSharp_multiple_modules">23.7 Multiple modules</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
When using <a href="Modules.html#Modules">multiple modules</a> it is is possible to compile each SWIG generated wrapper
|
||||
When using <a href="Modules.html#Modules">multiple modules</a> it is possible to compile each SWIG generated wrapper
|
||||
into a different assembly.
|
||||
However, by default the generated code may not compile if
|
||||
generated classes in one assembly use generated classes in another assembly.
|
||||
|
|
@ -1803,7 +1811,7 @@ the <tt>[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrows
|
|||
if you don't want users to easily stumble upon these so called 'internal workings' of the wrappers.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_typemap_examples">20.8 C# Typemap examples</a></H2>
|
||||
<H2><a name="CSharp_typemap_examples">23.8 C# Typemap examples</a></H2>
|
||||
|
||||
|
||||
This section includes a few examples of typemaps. For more examples, you
|
||||
|
|
@ -1811,7 +1819,7 @@ might look at the files "<tt>csharp.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
|
||||
|
||||
<H3><a name="CSharp_memory_management_member_variables">20.8.1 Memory management when returning references to member variables</a></H3>
|
||||
<H3><a name="CSharp_memory_management_member_variables">23.8.1 Memory management when returning references to member variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1827,7 +1835,7 @@ Consider the following C++ code:
|
|||
<pre>
|
||||
struct Wheel {
|
||||
int size;
|
||||
Wheel(int sz) : size(sz) {}
|
||||
Wheel(int sz = 0) : size(sz) {}
|
||||
};
|
||||
|
||||
class Bike {
|
||||
|
|
@ -1846,12 +1854,12 @@ and the following usage from C# after running the code through SWIG:
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
Wheel wheel = new Bike(10).getWheel();
|
||||
Console.WriteLine("wheel size: " + wheel.size);
|
||||
// Simulate a garbage collection
|
||||
global::System.GC.Collect();
|
||||
global::System.GC.WaitForPendingFinalizers();
|
||||
global::System.Console.WriteLine("wheel size: " + wheel.size);
|
||||
Wheel wheel = new Bike(10).getWheel();
|
||||
Console.WriteLine("wheel size: " + wheel.size);
|
||||
// Simulate a garbage collection
|
||||
global::System.GC.Collect();
|
||||
global::System.GC.WaitForPendingFinalizers();
|
||||
global::System.Console.WriteLine("wheel size: " + wheel.size);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -1935,7 +1943,7 @@ public class Bike : global::System.IDisposable {
|
|||
Note the <tt>addReference</tt> call.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_memory_management_objects">20.8.2 Memory management for objects passed to the C++ layer</a></H3>
|
||||
<H3><a name="CSharp_memory_management_objects">23.8.2 Memory management for objects passed to the C++ layer</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1980,27 +1988,27 @@ and more or less equivalent usage from C#
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
Container container = new Container();
|
||||
Element element = new Element(20);
|
||||
container.setElement(element);
|
||||
Container container = new Container();
|
||||
Element element = new Element(20);
|
||||
container.setElement(element);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The C++ code will always print out 20, but the value printed out may not be this in the C# equivalent code.
|
||||
In order to understand why, consider a garbage collection occuring...
|
||||
In order to understand why, consider a garbage collection occurring...
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
Container container = new Container();
|
||||
Element element = new Element(20);
|
||||
container.setElement(element);
|
||||
Console.WriteLine("element.value: " + container.getElement().value);
|
||||
// Simulate a garbage collection
|
||||
global::System.GC.Collect();
|
||||
global::System.GC.WaitForPendingFinalizers();
|
||||
global::System.Console.WriteLine("element.value: " + container.getElement().value);
|
||||
Container container = new Container();
|
||||
Element element = new Element(20);
|
||||
container.setElement(element);
|
||||
Console.WriteLine("element.value: " + container.getElement().value);
|
||||
// Simulate a garbage collection
|
||||
global::System.GC.Collect();
|
||||
global::System.GC.WaitForPendingFinalizers();
|
||||
global::System.Console.WriteLine("element.value: " + container.getElement().value);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -2019,42 +2027,55 @@ public class Container : global::System.IDisposable {
|
|||
// Ensure that the GC doesn't collect any Element set from C#
|
||||
// as the underlying C++ class stores a shallow copy
|
||||
private Element elementReference;
|
||||
private global::System.Runtime.InteropServices.HandleRef getCPtrAndAddReference(Element element) {
|
||||
elementReference = element;
|
||||
return Element.getCPtr(element);
|
||||
}
|
||||
|
||||
public void setElement(Element e) {
|
||||
examplePINVOKE.Container_setElement(swigCPtr, getCPtrAndAddReference(e));
|
||||
examplePINVOKE.Container_setElement(swigCPtr, Element.getCPtr(e));
|
||||
elementReference = e;
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The following typemaps will generate the desired code.
|
||||
The 'csin' typemap matches the input parameter type for the <tt>setElement</tt> method.
|
||||
The 'cscode' typemap simply adds in the specified code into the C# proxy class.
|
||||
The following typemaps can be used to generate this code:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%typemap(csin) Element *e "getCPtrAndAddReference($csinput)"
|
||||
|
||||
%typemap(cscode) Container %{
|
||||
// Ensure that the GC doesn't collect any Element set from C#
|
||||
// as the underlying C++ class stores a shallow copy
|
||||
private Element elementReference;
|
||||
private global::System.Runtime.InteropServices.HandleRef getCPtrAndAddReference(Element element) {
|
||||
elementReference = element;
|
||||
return Element.getCPtr(element);
|
||||
}
|
||||
%}
|
||||
|
||||
%typemap(csin,
|
||||
post=" elementReference = $csinput;"
|
||||
) Element *e "Element.getCPtr($csinput)"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The 'cscode' typemap simply adds in the specified code into the C# proxy class.
|
||||
The 'csin' typemap matches the input parameter type and name for the <tt>setElement</tt> method and
|
||||
the 'post' typemap attribute allows adding code after the PInvoke call.
|
||||
The 'post' code is generated into a finally block after the PInvoke call so the resulting code isn't quite
|
||||
as mentioned earlier, <tt>setElement</tt> is actually:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
public void setElement(Element e) {
|
||||
try {
|
||||
examplePINVOKE.Container_setElement(swigCPtr, Element.getCPtr(e));
|
||||
} finally {
|
||||
elementReference = e;
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_date_marshalling">20.8.3 Date marshalling using the csin typemap and associated attributes</a></H3>
|
||||
<H3><a name="CSharp_date_marshalling">23.8.3 Date marshalling using the csin typemap and associated attributes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2127,7 +2148,7 @@ The <tt>CDate &</tt> and <tt>const CDate &</tt> C# code is generated fro
|
|||
|
||||
<p>
|
||||
where '$csclassname' is translated into the proxy class name, <tt>CDate</tt> and '$csinput' is translated into the name of the parameter, eg <tt>dateIn</tt>.
|
||||
From C#, the intention is then to call into a modifed API with something like:
|
||||
From C#, the intention is then to call into a modified API with something like:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -2340,7 +2361,7 @@ public class example {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_date_properties">20.8.4 A date example demonstrating marshalling of C# properties</a></H3>
|
||||
<H3><a name="CSharp_date_properties">23.8.4 A date example demonstrating marshalling of C# properties</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2440,7 +2461,7 @@ Some points to note:
|
|||
<li>The 'csin' typemap has 'pre', 'post' and 'cshin' attributes, and these are all ignored in the property set. The code in these attributes must instead be replicated within the 'csvarin' typemap. The line creating the <tt>temp$csinput</tt> variable is such an example; it is identical to what is in the 'pre' attribute.
|
||||
</ul>
|
||||
|
||||
<H3><a name="CSharp_date_pre_post_directors">20.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a></H3>
|
||||
<H3><a name="CSharp_date_pre_post_directors">23.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2483,7 +2504,7 @@ The generated proxy class code will then contain the following wrapper for calli
|
|||
|
||||
<div class="code"><pre>
|
||||
...
|
||||
private void SwigDirectorsomeCallback(global::System.IntPtr date) {
|
||||
private void SwigDirectorMethodsomeCallback(global::System.IntPtr date) {
|
||||
System.DateTime tempdate = new System.DateTime();
|
||||
try {
|
||||
someCallback(out tempdate);
|
||||
|
|
@ -2502,7 +2523,7 @@ Pay special attention to the memory management issues, using these attributes.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="CSharp_partial_classes">20.8.6 Turning wrapped classes into partial classes</a></H3>
|
||||
<H3><a name="CSharp_partial_classes">23.8.6 Turning proxy classes into partial classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2602,7 +2623,97 @@ demonstrating that the class contains methods calling both unmanaged code - <tt>
|
|||
The following example is an alternative approach to adding managed code to the generated proxy class.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_extending_proxy_class">20.8.7 Extending proxy classes with additional C# code</a></H3>
|
||||
<H3><a name="CSharp_sealed_proxy_class">23.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">23.8.8 Extending proxy classes with additional C# code</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2641,13 +2752,13 @@ public class ExtendMe : global::System.IDisposable {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_enum_underlying_type">20.8.8 Underlying type for enums</a></H3>
|
||||
<H3><a name="CSharp_enum_underlying_type">23.8.9 Underlying type for enums</a></H3>
|
||||
|
||||
|
||||
<P>
|
||||
C# enums use int as the underlying type for each enum item.
|
||||
If you wish to change the underlying type to something else, then use the <tt>csbase</tt> typemap.
|
||||
For example when your C++ code uses a value larget than int, this is necessary as the C# compiler will not compile values which are too large to fit into an int.
|
||||
For example when your C++ code uses a value larger than int, this is necessary as the C# compiler will not compile values which are too large to fit into an int.
|
||||
Here is an example:
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Chicken">21 SWIG and Chicken</a></H1>
|
||||
<H1><a name="Chicken">23 SWIG and Chicken</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -72,7 +72,7 @@
|
|||
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn2">21.1 Preliminaries</a></H2>
|
||||
<H2><a name="Chicken_nn2">23.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -89,7 +89,7 @@
|
|||
directory for the basic steps to run SWIG CHICKEN.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn3">21.1.1 Running SWIG in C mode</a></H3>
|
||||
<H3><a name="Chicken_nn3">23.1.1 Running SWIG in C mode</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,7 +122,7 @@
|
|||
object files and linked into your project.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn4">21.1.2 Running SWIG in C++ mode</a></H3>
|
||||
<H3><a name="Chicken_nn4">23.1.2 Running SWIG in C++ mode</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -151,10 +151,10 @@
|
|||
object files and linked into your project.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn5">21.2 Code Generation</a></H2>
|
||||
<H2><a name="Chicken_nn5">23.2 Code Generation</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Chicken_nn6">21.2.1 Naming Conventions</a></H3>
|
||||
<H3><a name="Chicken_nn6">23.2.1 Naming Conventions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -170,7 +170,7 @@
|
|||
<tt>%rename</tt> SWIG directive in the SWIG interface file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn7">21.2.2 Modules</a></H3>
|
||||
<H3><a name="Chicken_nn7">23.2.2 Modules</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -192,7 +192,7 @@
|
|||
(uses <i>modulename</i>))</code> CHICKEN Scheme form.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn8">21.2.3 Constants and Variables</a></H3>
|
||||
<H3><a name="Chicken_nn8">23.2.3 Constants and Variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -229,7 +229,7 @@
|
|||
for info on how to apply the %feature.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn9">21.2.4 Functions</a></H3>
|
||||
<H3><a name="Chicken_nn9">23.2.4 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -248,7 +248,7 @@
|
|||
parameters). The return values can then be accessed with <code>(call-with-values)</code>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn10">21.2.5 Exceptions</a></H3>
|
||||
<H3><a name="Chicken_nn10">23.2.5 Exceptions</a></H3>
|
||||
|
||||
|
||||
<p>The SWIG chicken module has support for exceptions thrown from
|
||||
|
|
@ -290,7 +290,7 @@
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H2><a name="Chicken_nn11">21.3 TinyCLOS</a></H2>
|
||||
<H2><a name="Chicken_nn11">23.3 TinyCLOS</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -333,7 +333,7 @@
|
|||
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn12">21.4 Linkage</a></H2>
|
||||
<H2><a name="Chicken_nn12">23.4 Linkage</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -354,7 +354,7 @@
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Chicken_nn13">21.4.1 Static binary or shared library linked at compile time</a></H3>
|
||||
<H3><a name="Chicken_nn13">23.4.1 Static binary or shared library linked at compile time</a></H3>
|
||||
|
||||
|
||||
<p>We can easily use csc to build a static binary.</p>
|
||||
|
|
@ -395,7 +395,7 @@ in which case the test script does not need to be linked with example.so. The t
|
|||
be run with <tt>csi</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn14">21.4.2 Building chicken extension libraries</a></H3>
|
||||
<H3><a name="Chicken_nn14">23.4.2 Building chicken extension libraries</a></H3>
|
||||
|
||||
|
||||
<p>Building a shared library like in the above section only works if the library
|
||||
|
|
@ -453,7 +453,7 @@ distributed and used by anyone, even if SWIG is not installed.</p>
|
|||
<p>See the <tt>Examples/chicken/egg</tt> directory in the SWIG source for an example that builds
|
||||
two eggs, one using the first method and one using the second method.</p>
|
||||
|
||||
<H3><a name="Chicken_nn15">21.4.3 Linking multiple SWIG modules with TinyCLOS</a></H3>
|
||||
<H3><a name="Chicken_nn15">23.4.3 Linking multiple SWIG modules with TinyCLOS</a></H3>
|
||||
|
||||
|
||||
<p>Linking together multiple modules that share type information using the <code>%import</code>
|
||||
|
|
@ -477,7 +477,7 @@ with <code>(declare (uses ...))</code>.
|
|||
To create an extension library or an egg, just create a <tt>module_load.scm</tt> file that <code>(declare (uses ...))</code>
|
||||
all the modules.</p>
|
||||
|
||||
<H2><a name="Chicken_nn16">21.5 Typemaps</a></H2>
|
||||
<H2><a name="Chicken_nn16">23.5 Typemaps</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -486,7 +486,7 @@ all the modules.</p>
|
|||
<code>Lib/chicken/chicken.swg</code>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn17">21.6 Pointers</a></H2>
|
||||
<H2><a name="Chicken_nn17">23.6 Pointers</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -519,7 +519,7 @@ all the modules.</p>
|
|||
type. flags is either zero or SWIG_POINTER_DISOWN (see below).
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_collection">21.6.1 Garbage collection</a></H3>
|
||||
<H3><a name="Chicken_collection">23.6.1 Garbage collection</a></H3>
|
||||
|
||||
|
||||
<p>If the owner flag passed to <code>SWIG_NewPointerObj</code> is 1, <code>NewPointerObj</code> will add a
|
||||
|
|
@ -550,7 +550,7 @@ all the modules.</p>
|
|||
must be called manually.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn18">21.7 Unsupported features and known problems</a></H2>
|
||||
<H2><a name="Chicken_nn18">23.7 Unsupported features and known problems</a></H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -560,7 +560,7 @@ all the modules.</p>
|
|||
<a href="SWIGPlus.html#SWIGPlus_default_args">%feature(compactdefaultargs)</a>.</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Chicken_nn19">21.7.1 TinyCLOS problems with Chicken version <= 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
|
||||
|
|
|
|||
|
|
@ -46,6 +46,11 @@
|
|||
<ul>
|
||||
<li><a href="Introduction.html#Introduction_nn2">What is SWIG?</a>
|
||||
<li><a href="Introduction.html#Introduction_nn3">Why use SWIG?</a>
|
||||
<li><a href="Introduction.html#Introduction_target_languages">Target languages</a>
|
||||
<ul>
|
||||
<li><a href="Introduction.html#Introduction_supported_status">Supported status</a>
|
||||
<li><a href="Introduction.html#Introduction_experimental_status">Experimental status</a>
|
||||
</ul>
|
||||
<li><a href="Introduction.html#Introduction_nn4">A SWIG example</a>
|
||||
<ul>
|
||||
<li><a href="Introduction.html#Introduction_nn5">SWIG interface file</a>
|
||||
|
|
@ -90,9 +95,9 @@
|
|||
<ul>
|
||||
<li><a href="Windows.html#Windows_swig_exe">Building swig.exe on Windows</a>
|
||||
<ul>
|
||||
<li><a href="Windows.html#Windows_cmake">Building swig.exe using CMake</a>
|
||||
<li><a href="Windows.html#Windows_mingw_msys">Building swig.exe using MinGW and MSYS</a>
|
||||
<li><a href="Windows.html#Windows_cygwin">Building swig.exe using Cygwin</a>
|
||||
<li><a href="Windows.html#Windows_building_alternatives">Building swig.exe alternatives</a>
|
||||
</ul>
|
||||
<li><a href="Windows.html#Windows_examples_cygwin">Running the examples on Windows using Cygwin</a>
|
||||
</ul>
|
||||
|
|
@ -228,7 +233,6 @@
|
|||
<li><a href="SWIGPlus.html#SWIGPlus_nn12">Static members</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_member_data">Member data</a>
|
||||
</ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_default_args">Default arguments</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn15">Protection</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn16">Enums and constants</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn17">Friends</a>
|
||||
|
|
@ -236,16 +240,27 @@
|
|||
<li><a href="SWIGPlus.html#SWIGPlus_nn19">Pass and return by value</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn20">Inheritance</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn21">A brief discussion of multiple inheritance, pointers, and type checking</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_overloaded_methods">Wrapping Overloaded Functions and Methods</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_default_args">Default arguments</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_overloaded_methods">Overloaded functions and methods</a>
|
||||
<ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn24">Dispatch function generation</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn25">Ambiguity in Overloading</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn25">Ambiguity in overloading</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn27">Comments on overloading</a>
|
||||
</ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn28">Wrapping overloaded operators</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn28">Overloaded operators</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_class_extension">Class extension</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn30">Templates</a>
|
||||
<ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_directive">The %template directive</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_functions">Function templates</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_classes">Default template arguments</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_class_inheritance">Template base classes</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_specialization">Template specialization</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_member">Member templates</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_scoping">Scoping and templates</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_more">More on templates</a>
|
||||
</ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_namespaces">Namespaces</a>
|
||||
<ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nspace">The nspace feature for namespaces</a>
|
||||
|
|
@ -259,6 +274,11 @@
|
|||
<li><a href="SWIGPlus.html#SWIGPlus_nn35">Using declarations and inheritance</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nested_classes">Nested classes</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_const">A brief rant about const-correctness</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_target_language_callbacks">Callbacks to the target language</a>
|
||||
<ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_director_classes_introduction">Introduction to director classes</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_directors_for_function_pointers">Using directors and target language callbacks</a>
|
||||
</ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn42">Where to go for more information</a>
|
||||
</ul>
|
||||
</div>
|
||||
|
|
@ -290,6 +310,7 @@
|
|||
<li><a href="CPlusPlus11.html#CPlusPlus11_alias_templates">Type alias and alias templates</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_unrestricted_unions">Unrestricted unions</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_variadic_templates">Variadic templates</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_new_char_literals">New character literals</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_new_string_literals">New string literals</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_user_defined_literals">User-defined literals</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_thread_local_storage">Thread-local storage</a>
|
||||
|
|
@ -300,6 +321,7 @@
|
|||
<li><a href="CPlusPlus11.html#CPlusPlus11_noexcept">Exception specifications and noexcept</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_alignment">Control and query object alignment</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_attributes">Attributes</a>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_ref_qualifiers">Methods with ref-qualifiers</a>
|
||||
</ul>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11_standard_library_changes">Standard library changes</a>
|
||||
<ul>
|
||||
|
|
@ -318,7 +340,51 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Preprocessor.html#Preprocessor">8 Preprocessing</a></h3>
|
||||
<h3><a href="CPlusPlus14.html#CPlusPlus14">8 SWIG and C++14</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="CPlusPlus14.html#CPlusPlus14_introduction">Introduction</a>
|
||||
<li><a href="CPlusPlus14.html#CPlusPlus14_core_language_changes">Core language changes</a>
|
||||
<ul>
|
||||
<li><a href="CPlusPlus14.html#CPlusPlus14_binary_literals">Binary integer literals</a>
|
||||
</ul>
|
||||
<li><a href="CPlusPlus14.html#CPlusPlus14_standard_library_changes">Standard library changes</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CPlusPlus17.html#CPlusPlus17">9 SWIG and C++17</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="CPlusPlus17.html#CPlusPlus17_introduction">Introduction</a>
|
||||
<li><a href="CPlusPlus17.html#CPlusPlus17_core_language_changes">Core language changes</a>
|
||||
<ul>
|
||||
<li><a href="CPlusPlus17.html#CPlusPlus17_nested_namespaces">Nested namespace definitions</a>
|
||||
<li><a href="CPlusPlus17.html#CPlusPlus17_u8_char_literals">UTF-8 character literals</a>
|
||||
<li><a href="CPlusPlus17.html#CPlusPlus17_hexadecimal_floating_literals">Hexadecimal floating literals</a>
|
||||
</ul>
|
||||
<li><a href="CPlusPlus17.html#CPlusPlus17_standard_library_changes">Standard library changes</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CPlusPlus20.html#CPlusPlus20">10 SWIG and C++20</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="CPlusPlus20.html#CPlusPlus20_introduction">Introduction</a>
|
||||
<li><a href="CPlusPlus20.html#CPlusPlus20_core_language_changes">Core language changes</a>
|
||||
<li><a href="CPlusPlus20.html#CPlusPlus20_standard_library_changes">Standard library changes</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Preprocessor.html#Preprocessor">11 Preprocessing</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -341,32 +407,39 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Library.html#Library">9 SWIG library</a></h3>
|
||||
<h3><a href="Library.html#Library">12 SWIG library</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Library.html#Library_nn2">The %include directive and library search path</a>
|
||||
<li><a href="Library.html#Library_nn3">C Arrays and Pointers</a>
|
||||
<li><a href="Library.html#Library_nn3">C arrays and pointers</a>
|
||||
<ul>
|
||||
<li><a href="Library.html#Library_nn4">cpointer.i</a>
|
||||
<li><a href="Library.html#Library_carrays">carrays.i</a>
|
||||
<li><a href="Library.html#Library_nn6">cmalloc.i</a>
|
||||
<li><a href="Library.html#Library_nn7">cdata.i</a>
|
||||
</ul>
|
||||
<li><a href="Library.html#Library_nn8">C String Handling</a>
|
||||
<li><a href="Library.html#Library_nn8">C string handling</a>
|
||||
<ul>
|
||||
<li><a href="Library.html#Library_nn9">Default string handling</a>
|
||||
<li><a href="Library.html#Library_nn10">Passing binary data</a>
|
||||
<li><a href="Library.html#Library_nn11">Using %newobject to release memory</a>
|
||||
<li><a href="Library.html#Library_nn12">cstring.i</a>
|
||||
</ul>
|
||||
<li><a href="Library.html#Library_stl_cpp_library">STL/C++ Library</a>
|
||||
<li><a href="Library.html#Library_stl_cpp_library">STL/C++ library</a>
|
||||
<ul>
|
||||
<li><a href="Library.html#Library_std_string">std::string</a>
|
||||
<li><a href="Library.html#Library_std_vector">std::vector</a>
|
||||
<li><a href="Library.html#Library_stl_exceptions">STL exceptions</a>
|
||||
<li><a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a>
|
||||
<ul>
|
||||
<li><a href="Library.html#Library_shared_ptr_basics">shared_ptr basics</a>
|
||||
<li><a href="Library.html#Library_shared_ptr_inheritance">shared_ptr and inheritance</a>
|
||||
<li><a href="Library.html#Library_shared_ptr_overloading">shared_ptr and method overloading</a>
|
||||
<li><a href="Library.html#Library_shared_ptr_templates">shared_ptr and templates</a>
|
||||
<li><a href="Library.html#Library_shared_ptr_directors">shared_ptr and directors</a>
|
||||
</ul>
|
||||
<li><a href="Library.html#Library_std_auto_ptr">auto_ptr smart pointer</a>
|
||||
</ul>
|
||||
<li><a href="Library.html#Library_nn16">Utility Libraries</a>
|
||||
|
|
@ -377,7 +450,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Arguments.html#Arguments">10 Argument Handling</a></h3>
|
||||
<h3><a href="Arguments.html#Arguments">13 Argument Handling</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -400,7 +473,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Typemaps.html#Typemaps">11 Typemaps</a></h3>
|
||||
<h3><a href="Typemaps.html#Typemaps">14 Typemaps</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -461,7 +534,7 @@
|
|||
<li><a href="Typemaps.html#Typemaps_nn35">"memberin" typemap</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn36">"varin" typemap</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn37">"varout" typemap</a>
|
||||
<li><a href="Typemaps.html#throws_typemap">"throws" typemap</a>
|
||||
<li><a href="Typemaps.html#Typemaps_throws_typemap">"throws" typemap</a>
|
||||
</ul>
|
||||
<li><a href="Typemaps.html#Typemaps_nn39">Some typemap examples</a>
|
||||
<ul>
|
||||
|
|
@ -483,6 +556,9 @@
|
|||
<li><a href="Typemaps.html#Typemaps_runtime_type_checker_usage">Usage</a>
|
||||
</ul>
|
||||
<li><a href="Typemaps.html#Typemaps_overloading">Typemaps and overloading</a>
|
||||
<ul>
|
||||
<li><a href="Typemaps.html#Typemaps_typecheck_pointer">SWIG_TYPECHECK_POINTER precedence level and the typecheck typemap</a>
|
||||
</ul>
|
||||
<li><a href="Typemaps.html#Typemaps_nn48">More about %apply and %clear</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn47">Passing data between typemaps</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn52">C++ "this" pointer</a>
|
||||
|
|
@ -491,7 +567,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Customization.html#Customization">12 Customization Features</a></h3>
|
||||
<h3><a href="Customization.html#Customization">15 Customization Features</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -519,7 +595,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Contract.html#Contract">13 Contracts</a></h3>
|
||||
<h3><a href="Contract.html#Contract">16 Contracts</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -532,7 +608,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Varargs.html#Varargs">14 Variable Length Arguments</a></h3>
|
||||
<h3><a href="Varargs.html#Varargs">17 Variable Length Arguments</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -550,7 +626,55 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Warnings.html#Warnings">15 Warning Messages</a></h3>
|
||||
<h3><a href="Doxygen.html#Doxygen">18 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">19 Warning Messages</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -569,7 +693,8 @@
|
|||
<li><a href="Warnings.html#Warnings_nn11">Preprocessor (200-299)</a>
|
||||
<li><a href="Warnings.html#Warnings_nn12">C/C++ Parser (300-399)</a>
|
||||
<li><a href="Warnings.html#Warnings_nn13">Types and typemaps (400-499) </a>
|
||||
<li><a href="Warnings.html#Warnings_nn14">Code generation (500-599)</a>
|
||||
<li><a href="Warnings.html#Warnings_nn14">Code generation (500-559)</a>
|
||||
<li><a href="Warnings.html#Warnings_doxygen">Doxygen comments (560-599)</a>
|
||||
<li><a href="Warnings.html#Warnings_nn15">Language module specific (700-899) </a>
|
||||
<li><a href="Warnings.html#Warnings_nn16">User defined (900-999)</a>
|
||||
</ul>
|
||||
|
|
@ -578,7 +703,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Modules.html#Modules">16 Working with Modules</a></h3>
|
||||
<h3><a href="Modules.html#Modules">20 Working with Modules</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -594,7 +719,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CCache.html#CCache">17 Using SWIG with ccache - ccache-swig(1) manpage</a></h3>
|
||||
<h3><a href="CCache.html#CCache">21 Using SWIG with ccache - ccache-swig(1) manpage</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -620,91 +745,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Allegrocl.html#Allegrocl">18 SWIG and Allegro Common Lisp</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn2">Basics</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn3">Running SWIG</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn4">Command Line Options</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn5">Inserting user code into generated files</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn6">Wrapping Overview</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn7">Function Wrapping</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn8">Foreign Wrappers</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn9">FFI Wrappers</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn10">Non-overloaded Defuns</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn11">Overloaded Defuns</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn12">What about constant and variable access?</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn13">Object Wrapping</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn14">Wrapping Details</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn15">Namespaces</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn16">Constants</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn17">Variables</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn18">Enumerations</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn19">Arrays</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn20">Classes and Structs and Unions (oh my!)</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn21">CLOS wrapping of</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn22">CLOS Inheritance</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn23">Member fields and functions</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn24">Why not directly access C++ classes using foreign types?</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn25">Templates</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn26">Generating wrapper code for templates</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn27">Implicit Template instantiation</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn28">Typedef, Templates, and Synonym Types</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn29">Choosing a primary type</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn30">Function overloading/Parameter defaulting</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn31">Operator wrapping and Operator overloading</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn32">Varargs</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn33">C++ Exceptions</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn34">Pass by value, pass by reference</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn35">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn36">Code Generation in the C++ Wrapper</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn37">IN Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn38">OUT Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn39">CTYPE Typemap</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn40">Code generation in Lisp wrappers</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn41">LIN Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn42">LOUT Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn43">FFITYPE Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn44">LISPTYPE Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn45">LISPCLASS Typemap</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn46">Modifying SWIG behavior using typemaps</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn47">Identifier Converter functions</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn48">Creating symbols in the lisp environment</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn49">Existing identifier-converter functions</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn50">identifier-convert-null</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn51">identifier-convert-lispify</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn52">Default identifier to symbol conversions</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn53">Defining your own identifier-converter</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn54">Instructing SWIG to use a particular identifier-converter</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Android.html#Android">19 SWIG and Android</a></h3>
|
||||
<h3><a href="Android.html#Android">22 SWIG and Android</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -722,7 +763,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CSharp.html#CSharp">20 SWIG and C#</a></h3>
|
||||
<h3><a href="CSharp.html#CSharp">23 SWIG and C#</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -761,7 +802,8 @@
|
|||
<li><a href="CSharp.html#CSharp_date_marshalling">Date marshalling using the csin typemap and associated attributes</a>
|
||||
<li><a href="CSharp.html#CSharp_date_properties">A date example demonstrating marshalling of C# properties</a>
|
||||
<li><a href="CSharp.html#CSharp_date_pre_post_directors">Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a>
|
||||
<li><a href="CSharp.html#CSharp_partial_classes">Turning wrapped classes into partial classes</a>
|
||||
<li><a href="CSharp.html#CSharp_partial_classes">Turning proxy classes into partial classes</a>
|
||||
<li><a href="CSharp.html#CSharp_sealed_proxy_class">Turning proxy classes into sealed classes</a>
|
||||
<li><a href="CSharp.html#CSharp_extending_proxy_class">Extending proxy classes with additional C# code</a>
|
||||
<li><a href="CSharp.html#CSharp_enum_underlying_type">Underlying type for enums</a>
|
||||
</ul>
|
||||
|
|
@ -769,45 +811,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Chicken.html#Chicken">21 SWIG and Chicken</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Chicken.html#Chicken_nn2">Preliminaries</a>
|
||||
<ul>
|
||||
<li><a href="Chicken.html#Chicken_nn3">Running SWIG in C mode</a>
|
||||
<li><a href="Chicken.html#Chicken_nn4">Running SWIG in C++ mode</a>
|
||||
</ul>
|
||||
<li><a href="Chicken.html#Chicken_nn5">Code Generation</a>
|
||||
<ul>
|
||||
<li><a href="Chicken.html#Chicken_nn6">Naming Conventions</a>
|
||||
<li><a href="Chicken.html#Chicken_nn7">Modules</a>
|
||||
<li><a href="Chicken.html#Chicken_nn8">Constants and Variables</a>
|
||||
<li><a href="Chicken.html#Chicken_nn9">Functions</a>
|
||||
<li><a href="Chicken.html#Chicken_nn10">Exceptions</a>
|
||||
</ul>
|
||||
<li><a href="Chicken.html#Chicken_nn11">TinyCLOS</a>
|
||||
<li><a href="Chicken.html#Chicken_nn12">Linkage</a>
|
||||
<ul>
|
||||
<li><a href="Chicken.html#Chicken_nn13">Static binary or shared library linked at compile time</a>
|
||||
<li><a href="Chicken.html#Chicken_nn14">Building chicken extension libraries</a>
|
||||
<li><a href="Chicken.html#Chicken_nn15">Linking multiple SWIG modules with TinyCLOS</a>
|
||||
</ul>
|
||||
<li><a href="Chicken.html#Chicken_nn16">Typemaps</a>
|
||||
<li><a href="Chicken.html#Chicken_nn17">Pointers</a>
|
||||
<ul>
|
||||
<li><a href="Chicken.html#Chicken_collection">Garbage collection</a>
|
||||
</ul>
|
||||
<li><a href="Chicken.html#Chicken_nn18">Unsupported features and known problems</a>
|
||||
<ul>
|
||||
<li><a href="Chicken.html#Chicken_nn19">TinyCLOS problems with Chicken version <= 1.92</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="D.html#D">22 SWIG and D</a></h3>
|
||||
<h3><a href="D.html#D">24 SWIG and D</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -841,7 +845,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Go.html#Go">23 SWIG and Go</a></h3>
|
||||
<h3><a href="Go.html#Go">25 SWIG and Go</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -885,7 +889,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Guile.html#Guile">24 SWIG and Guile</a></h3>
|
||||
<h3><a href="Guile.html#Guile">26 SWIG and Guile</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -921,7 +925,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Java.html#Java">25 SWIG and Java</a></h3>
|
||||
<h3><a href="Java.html#Java">27 SWIG and Java</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1010,12 +1014,16 @@
|
|||
<li><a href="Java.html#Java_directors_threading">Director threading issues</a>
|
||||
<li><a href="Java.html#Java_directors_performance">Director performance tuning</a>
|
||||
<li><a href="Java.html#Java_exceptions_from_directors">Java exceptions from directors</a>
|
||||
<ul>
|
||||
<li><a href="Java.html#Java_customizing_director_exceptions">Customizing director exceptions</a>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><a href="Java.html#Java_allprotected">Accessing protected members</a>
|
||||
<li><a href="Java.html#Java_common_customization">Common customization features</a>
|
||||
<ul>
|
||||
<li><a href="Java.html#Java_helper_functions">C/C++ helper functions</a>
|
||||
<li><a href="Java.html#Java_class_extension">Class extension with %extend</a>
|
||||
<li><a href="Java.html#Java_proxycode">Class extension with %proxycode</a>
|
||||
<li><a href="Java.html#Java_exception_handling">Exception handling with %exception and %javaexception</a>
|
||||
<li><a href="Java.html#Java_method_access">Method access with %javamethodmodifiers</a>
|
||||
</ul>
|
||||
|
|
@ -1071,7 +1079,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Javascript.html#Javascript">26 SWIG and Javascript</a></h3>
|
||||
<h3><a href="Javascript.html#Javascript">28 SWIG and Javascript</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1113,30 +1121,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Lisp.html#Lisp">27 SWIG and Common Lisp</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Lisp.html#Lisp_nn2">Allegro Common Lisp</a>
|
||||
<li><a href="Lisp.html#Lisp_nn3">Common Foreign Function Interface(CFFI)</a>
|
||||
<ul>
|
||||
<li><a href="Lisp.html#Lisp_nn4">Additional Commandline Options </a>
|
||||
<li><a href="Lisp.html#Lisp_nn5">Generating CFFI bindings</a>
|
||||
<li><a href="Lisp.html#Lisp_nn6">Generating CFFI bindings for C++ code</a>
|
||||
<li><a href="Lisp.html#Lisp_nn7">Inserting user code into generated files</a>
|
||||
</ul>
|
||||
<li><a href="Lisp.html#Lisp_nn8">CLISP</a>
|
||||
<ul>
|
||||
<li><a href="Lisp.html#Lisp_nn9">Additional Commandline Options </a>
|
||||
<li><a href="Lisp.html#Lisp_nn10">Details on CLISP bindings</a>
|
||||
</ul>
|
||||
<li><a href="Lisp.html#Lisp_nn11">UFFI </a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Lua.html#Lua">28 SWIG and Lua</a></h3>
|
||||
<h3><a href="Lua.html#Lua">29 SWIG and Lua</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1204,108 +1189,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Modula3.html#Modula3">29 SWIG and Modula-3</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Modula3.html#Modula3_modula3_overview">Overview</a>
|
||||
<ul>
|
||||
<li><a href="Modula3.html#Modula3_motivation">Motivation</a>
|
||||
</ul>
|
||||
<li><a href="Modula3.html#Modula3_conception">Conception</a>
|
||||
<ul>
|
||||
<li><a href="Modula3.html#Modula3_cinterface">Interfaces to C libraries</a>
|
||||
<li><a href="Modula3.html#Modula3_cppinterface">Interfaces to C++ libraries</a>
|
||||
</ul>
|
||||
<li><a href="Modula3.html#Modula3_preliminaries">Preliminaries</a>
|
||||
<ul>
|
||||
<li><a href="Modula3.html#Modula3_compilers">Compilers</a>
|
||||
<li><a href="Modula3.html#Modula3_commandline">Additional Commandline Options</a>
|
||||
</ul>
|
||||
<li><a href="Modula3.html#Modula3_typemaps">Modula-3 typemaps</a>
|
||||
<ul>
|
||||
<li><a href="Modula3.html#Modula3_inoutparam">Inputs and outputs</a>
|
||||
<li><a href="Modula3.html#Modula3_ordinals">Subranges, Enumerations, Sets</a>
|
||||
<li><a href="Modula3.html#Modula3_class">Objects</a>
|
||||
<li><a href="Modula3.html#Modula3_imports">Imports</a>
|
||||
<li><a href="Modula3.html#Modula3_exceptions">Exceptions</a>
|
||||
<li><a href="Modula3.html#Modula3_typemap_example">Example</a>
|
||||
</ul>
|
||||
<li><a href="Modula3.html#Modula3_hints">More hints to the generator</a>
|
||||
<ul>
|
||||
<li><a href="Modula3.html#Modula3_features">Features</a>
|
||||
<li><a href="Modula3.html#Modula3_pragmas">Pragmas</a>
|
||||
</ul>
|
||||
<li><a href="Modula3.html#Modula3_remarks">Remarks</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Mzscheme.html#Mzscheme">30 SWIG and MzScheme/Racket</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Mzscheme.html#MzScheme_nn2">Creating native structures</a>
|
||||
<li><a href="Mzscheme.html#MzScheme_simple">Simple example</a>
|
||||
<li><a href="Mzscheme.html#MzScheme_external_docs">External documentation</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ocaml.html#Ocaml">31 SWIG and Ocaml</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn2">Preliminaries</a>
|
||||
<ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn3">Running SWIG</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn4">Compiling the code</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn5">The camlp4 module</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn6">Using your module</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn7">Compilation problems and compiling with C++</a>
|
||||
</ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn8">The low-level Ocaml/C interface</a>
|
||||
<ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn9">The generated module</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn10">Enums</a>
|
||||
<ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn11">Enum typing in Ocaml</a>
|
||||
</ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn12">Arrays</a>
|
||||
<ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn13">Simple types of bounded arrays</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn14">Complex and unbounded arrays</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn15">Using an object</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn16">Example typemap for a function taking float * and int</a>
|
||||
</ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn17">C++ Classes</a>
|
||||
<ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn18">STL vector and string Example</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn19">C++ Class Example</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn20">Compiling the example</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn21">Sample Session</a>
|
||||
</ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn22">Director Classes</a>
|
||||
<ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn23">Director Introduction</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn24">Overriding Methods in Ocaml</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn25">Director Usage Example</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn26">Creating director objects</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn27">Typemaps for directors, directorin, directorout, directorargout</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn28">typemap</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn29">directorout typemap</a>
|
||||
<li><a href="Ocaml.html#Ocaml_nn30">directorargout typemap</a>
|
||||
</ul>
|
||||
<li><a href="Ocaml.html#Ocaml_nn31">Exceptions</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Octave.html#Octave">32 SWIG and Octave</a></h3>
|
||||
<h3><a href="Octave.html#Octave">30 SWIG and Octave</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1345,7 +1229,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Perl5.html#Perl5">33 SWIG and Perl5</a></h3>
|
||||
<h3><a href="Perl5.html#Perl5">31 SWIG and Perl5</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1421,7 +1305,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Php.html#Php">34 SWIG and PHP</a></h3>
|
||||
<h3><a href="Php.html#Php">32 SWIG and PHP</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1462,31 +1346,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Pike.html#Pike">35 SWIG and Pike</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Pike.html#Pike_nn2">Preliminaries</a>
|
||||
<ul>
|
||||
<li><a href="Pike.html#Pike_nn3">Running SWIG</a>
|
||||
<li><a href="Pike.html#Pike_nn4">Getting the right header files</a>
|
||||
<li><a href="Pike.html#Pike_nn5">Using your module</a>
|
||||
</ul>
|
||||
<li><a href="Pike.html#Pike_nn6">Basic C/C++ Mapping</a>
|
||||
<ul>
|
||||
<li><a href="Pike.html#Pike_nn7">Modules</a>
|
||||
<li><a href="Pike.html#Pike_nn8">Functions</a>
|
||||
<li><a href="Pike.html#Pike_nn9">Global variables</a>
|
||||
<li><a href="Pike.html#Pike_nn10">Constants and enumerated types</a>
|
||||
<li><a href="Pike.html#Pike_nn11">Constructors and Destructors</a>
|
||||
<li><a href="Pike.html#Pike_nn12">Static Members</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Python.html#Python">36 SWIG and Python</a></h3>
|
||||
<h3><a href="Python.html#Python">33 SWIG and Python</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1501,7 +1361,8 @@
|
|||
<li><a href="Python.html#Python_nn9">Using your module</a>
|
||||
<li><a href="Python.html#Python_nn10">Compilation of C++ extensions</a>
|
||||
<li><a href="Python.html#Python_nn11">Compiling for 64-bit platforms</a>
|
||||
<li><a href="Python.html#Python_nn12">Building Python Extensions under Windows</a>
|
||||
<li><a href="Python.html#Python_nn12">Building Python extensions under Windows</a>
|
||||
<li><a href="Python.html#Python_commandline">Additional Python commandline options</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn13">A tour of basic C/C++ wrapping</a>
|
||||
<ul>
|
||||
|
|
@ -1534,7 +1395,6 @@
|
|||
<li><a href="Python.html#Python_builtin_overloads">Operator overloads and slots -- use them!</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn30">Memory management</a>
|
||||
<li><a href="Python.html#Python_nn31">Python 2.2 and classic classes</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_directors">Cross language polymorphism</a>
|
||||
<ul>
|
||||
|
|
@ -1552,6 +1412,10 @@
|
|||
<li><a href="Python.html#Python_nn42">Adding additional Python code</a>
|
||||
<li><a href="Python.html#Python_nn43">Class extension with %extend</a>
|
||||
<li><a href="Python.html#Python_nn44">Exception handling with %exception</a>
|
||||
<li><a href="Python.html#Python_optimization">Optimization options</a>
|
||||
<ul>
|
||||
<li><a href="Python.html#Python_fastproxy">-fastproxy</a>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn45">Tips and techniques</a>
|
||||
<ul>
|
||||
|
|
@ -1576,6 +1440,7 @@
|
|||
<li><a href="Python.html#Python_nn62">Mapping Python tuples into small arrays</a>
|
||||
<li><a href="Python.html#Python_nn63">Mapping sequences to C arrays</a>
|
||||
<li><a href="Python.html#Python_nn64">Pointer handling</a>
|
||||
<li><a href="Python.html#Python_memory_management_member_variables">Memory management when returning references to member variables</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn65">Docstring Features</a>
|
||||
<ul>
|
||||
|
|
@ -1596,12 +1461,13 @@
|
|||
<li><a href="Python.html#Python_absrelimports">Absolute and relative imports</a>
|
||||
<li><a href="Python.html#Python_absimport">Enforcing absolute import semantics</a>
|
||||
<li><a href="Python.html#Python_importfrominit">Importing from __init__.py</a>
|
||||
<li><a href="Python.html#Python_implicit_namespace_packages">Implicit Namespace Packages</a>
|
||||
<li><a href="Python.html#Python_package_search">Searching for the wrapper module</a>
|
||||
<li><a href="Python.html#Python_implicit_namespace_packages">Implicit namespace packages</a>
|
||||
<li><a href="Python.html#Python_package_search">Location of modules</a>
|
||||
<ul>
|
||||
<li><a href="Python.html#Python_package_search_both_package_modules">Both modules in the same package</a>
|
||||
<li><a href="Python.html#Python_package_search_wrapper_split">Split modules</a>
|
||||
<li><a href="Python.html#Python_package_search_both_global_modules">Both modules are global</a>
|
||||
<li><a href="Python.html#Python_package_search_wrapper_split">Split modules custom configuration</a>
|
||||
<li><a href="Python.html#Python_custom_module_import">More on customizing the module import code</a>
|
||||
<li><a href="Python.html#Python_package_search_static">Statically linked C modules</a>
|
||||
</ul>
|
||||
</ul>
|
||||
|
|
@ -1613,11 +1479,16 @@
|
|||
<li><a href="Python.html#Python_nn77">Byte string output conversion</a>
|
||||
<li><a href="Python.html#Python_2_unicode">Python 2 Unicode</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_multithreaded">Support for Multithreaded Applications</a>
|
||||
<ul>
|
||||
<li><a href="Python.html#Python_thread_UI">UI for Enabling Multithreading Support</a>
|
||||
<li><a href="Python.html#Python_thread_performance">Multithread Performance</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="R.html#R">37 SWIG and R</a></h3>
|
||||
<h3><a href="R.html#R">34 SWIG and R</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1628,12 +1499,15 @@
|
|||
<li><a href="R.html#R_nn5">General policy</a>
|
||||
<li><a href="R.html#R_language_conventions">Language conventions</a>
|
||||
<li><a href="R.html#R_nn6">C++ classes</a>
|
||||
<ul>
|
||||
<li><a href="R.html#R_class_examples">Examples</a>
|
||||
</ul>
|
||||
<li><a href="R.html#R_nn7">Enumerations</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ruby.html#Ruby">38 SWIG and Ruby</a></h3>
|
||||
<h3><a href="Ruby.html#Ruby">35 SWIG and Ruby</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1771,7 +1645,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Scilab.html#Scilab">39 SWIG and Scilab</a></h3>
|
||||
<h3><a href="Scilab.html#Scilab">36 SWIG and Scilab</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1802,7 +1676,7 @@
|
|||
</ul>
|
||||
<li><a href="Scilab.html#Scilab_wrapping_pointers">Pointers</a>
|
||||
<ul>
|
||||
<li><a href="Scilab.html#Scilab_wrapping_pointers_pointer_adresses">Utility functions</a>
|
||||
<li><a href="Scilab.html#Scilab_wrapping_pointers_utility_functions">Utility functions</a>
|
||||
<li><a href="Scilab.html#Scilab_wrapping_pointers_null_pointers">Null pointers:</a>
|
||||
</ul>
|
||||
<li><a href="Scilab.html#Scilab_wrapping_structs">Structures</a>
|
||||
|
|
@ -1840,7 +1714,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Tcl.html#Tcl">40 SWIG and Tcl</a></h3>
|
||||
<h3><a href="Tcl.html#Tcl">37 SWIG and Tcl</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1906,7 +1780,74 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Extending.html#Extending">41 Extending SWIG to support new languages</a></h3>
|
||||
<h3><a href="Mzscheme.html#Mzscheme">38 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">39 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">40 Extending SWIG to support new languages</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1964,8 +1905,13 @@
|
|||
<li><a href="Extending.html#Extending_running_test_suite">Running the test-suite</a>
|
||||
</ul>
|
||||
<li><a href="Extending.html#Extending_nn43">Documentation</a>
|
||||
<li><a href="Extending.html#Extending_prerequisites">Prerequisites for adding a new language module to the SWIG distribution</a>
|
||||
<li><a href="Extending.html#Extending_coding_style_guidelines">Coding style guidelines</a>
|
||||
<li><a href="Extending.html#Extending_language_status">Target language status</a>
|
||||
<ul>
|
||||
<li><a href="Extending.html#Extending_supported_status">Supported status</a>
|
||||
<li><a href="Extending.html#Extending_experimental_status">Experimental status</a>
|
||||
</ul>
|
||||
<li><a href="Extending.html#Extending_prerequisites">Prerequisites for adding a new language module to the SWIG distribution</a>
|
||||
</ul>
|
||||
<li><a href="Extending.html#Extending_debugging_options">Debugging Options</a>
|
||||
<li><a href="Extending.html#Extending_nn46">Guide to parse tree nodes</a>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Contract">13 Contracts</a></H1>
|
||||
<H1><a name="Contract">16 Contracts</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -39,7 +39,7 @@ When one of the rules is violated by a script, a runtime exception is
|
|||
generated rather than having the program continue to execute.
|
||||
</p>
|
||||
|
||||
<H2><a name="Contract_nn2">13.1 The %contract directive</a></H2>
|
||||
<H2><a name="Contract_nn2">16.1 The %contract directive</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -95,7 +95,7 @@ RuntimeError: Contract violation: require: (arg1>=0)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Contract_nn3">13.2 %contract and classes</a></H2>
|
||||
<H2><a name="Contract_nn3">16.2 %contract and classes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -174,7 +174,7 @@ specified for the derived class all must hold. In the above example,
|
|||
this means that both the arguments to <tt>Spam::bar</tt> must be positive.
|
||||
</p>
|
||||
|
||||
<H2><a name="Contract_nn4">13.3 Constant aggregation and %aggregate_check</a></H2>
|
||||
<H2><a name="Contract_nn4">16.3 Constant aggregation and %aggregate_check</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -263,7 +263,7 @@ Regrettably, there is no automatic way to perform similar checks with enums valu
|
|||
release.
|
||||
</p>
|
||||
|
||||
<H2><a name="Contract_nn5">13.4 Notes</a></H2>
|
||||
<H2><a name="Contract_nn5">16.4 Notes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Customization">12 Customization Features</a></H1>
|
||||
<H1><a name="Customization">15 Customization Features</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -46,7 +46,7 @@ of exception handling is presented. Then, a more general-purpose
|
|||
customization mechanism known as "features" is described.
|
||||
</p>
|
||||
|
||||
<H2><a name="Customization_exception">12.1 Exception handling with %exception</a></H2>
|
||||
<H2><a name="Customization_exception">15.1 Exception handling with %exception</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -101,7 +101,7 @@ for exception handling. That directive is deprecated--<tt>%exception</tt>
|
|||
provides the same functionality, but is substantially more flexible.
|
||||
</p>
|
||||
|
||||
<H3><a name="Customization_nn3">12.1.1 Handling exceptions in C code</a></H3>
|
||||
<H3><a name="Customization_nn3">15.1.1 Handling exceptions in C code</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -169,7 +169,7 @@ Each target language has its own approach to creating a runtime error/exception
|
|||
and for Perl it is the <tt>croak</tt> method shown above.
|
||||
</p>
|
||||
|
||||
<H3><a name="Customization_nn4">12.1.2 Exception handling with longjmp()</a></H3>
|
||||
<H3><a name="Customization_nn4">15.1.2 Exception handling with longjmp()</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -245,7 +245,7 @@ Note: This implementation is only intended to illustrate the general idea. To m
|
|||
modify it to handle nested <tt>try</tt> declarations.
|
||||
</p>
|
||||
|
||||
<H3><a name="Customization_nn5">12.1.3 Handling C++ exceptions</a></H3>
|
||||
<H3><a name="Customization_nn5">15.1.3 Handling C++ exceptions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -280,7 +280,7 @@ class OutOfMemory {};
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Customization_allowexcept">12.1.4 Exception handlers for variables</a></H3>
|
||||
<H3><a name="Customization_allowexcept">15.1.4 Exception handlers for variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -305,7 +305,7 @@ The <tt>%allowexception</tt> feature works like any other feature and so can be
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Customization_nn6">12.1.5 Defining different exception handlers</a></H3>
|
||||
<H3><a name="Customization_nn6">15.1.5 Defining different exception handlers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -356,7 +356,7 @@ In this case, the exception handler is only attached to declarations
|
|||
named "allocate". This would include both global and member
|
||||
functions. The names supplied to <tt>%exception</tt> follow the same
|
||||
rules as for <tt>%rename</tt> described in the section on
|
||||
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a>.
|
||||
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>.
|
||||
For example, if you wanted to define
|
||||
an exception handler for a specific class, you might write this:
|
||||
</p>
|
||||
|
|
@ -442,7 +442,7 @@ declarations. However, it never really worked that well and the new
|
|||
%exception directive is much better.
|
||||
</p>
|
||||
|
||||
<H3><a name="Customization_exception_special_variables">12.1.6 Special variables for %exception</a></H3>
|
||||
<H3><a name="Customization_exception_special_variables">15.1.6 Special variables for %exception</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -516,7 +516,7 @@ The special variables are often used in situations where method calls are logged
|
|||
$action
|
||||
}
|
||||
catch (MemoryError) {
|
||||
croak("Out of memory in $decl");
|
||||
croak("Out of memory in $decl");
|
||||
}
|
||||
}
|
||||
void log(const char *message);
|
||||
|
|
@ -545,7 +545,7 @@ Below shows the expansions for the 1st of the overloaded <tt>something</tt> wrap
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Customization_nn7">12.1.7 Using The SWIG exception library</a></H3>
|
||||
<H3><a name="Customization_nn7">15.1.7 Using The SWIG exception library</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -600,7 +600,7 @@ SWIG_NullReferenceError
|
|||
The <tt>SWIG_exception()</tt> function can also be used in typemaps.
|
||||
</p>
|
||||
|
||||
<H2><a name="Customization_ownership">12.2 Object ownership and %newobject</a></H2>
|
||||
<H2><a name="Customization_ownership">15.2 Object ownership and %newobject</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -757,7 +757,7 @@ char *strdup(const char *s);
|
|||
The results might not be what you expect.
|
||||
</p>
|
||||
|
||||
<H2><a name="Customization_features">12.3 Features and the %feature directive</a></H2>
|
||||
<H2><a name="Customization_features">15.3 Features and the %feature directive</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -796,7 +796,7 @@ involving <tt>%feature</tt>:
|
|||
</div>
|
||||
|
||||
<p>
|
||||
The name matching rules outlined in the <a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a>
|
||||
The name matching rules outlined in the <a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>
|
||||
section applies to all <tt>%feature</tt> directives.
|
||||
In fact the <tt>%rename</tt> directive is just a special form of <tt>%feature</tt>.
|
||||
The matching rules mean that features are very flexible and can be applied with
|
||||
|
|
@ -839,7 +839,7 @@ The following are all equivalent:
|
|||
The syntax in the first variation will generate the <tt>{ }</tt> delimiters used whereas the other variations will not.
|
||||
</p>
|
||||
|
||||
<H3><a name="Customization_feature_attributes">12.3.1 Feature attributes</a></H3>
|
||||
<H3><a name="Customization_feature_attributes">15.3.1 Feature attributes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -880,7 +880,7 @@ In the following example, <tt>MyExceptionClass</tt> is the name of the Java clas
|
|||
Further details can be obtained from the <a href="Java.html#Java_exception_handling">Java exception handling</a> section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Customization_feature_flags">12.3.2 Feature flags</a></H3>
|
||||
<H3><a name="Customization_feature_flags">15.3.2 Feature flags</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -978,7 +978,7 @@ in the <tt>swig.swg</tt> Library file. The following shows the alternative synta
|
|||
The concept of clearing features is discussed next.
|
||||
</p>
|
||||
|
||||
<H3><a name="Customization_clearing_features">12.3.3 Clearing features</a></H3>
|
||||
<H3><a name="Customization_clearing_features">15.3.3 Clearing features</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1071,7 +1071,7 @@ The three macros below show this for the "except" feature:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Customization_features_default_args">12.3.4 Features and default arguments</a></H3>
|
||||
<H3><a name="Customization_features_default_args">15.3.4 Features and default arguments</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1146,7 +1146,7 @@ specifying or not specifying default arguments in a feature is not applicable as
|
|||
in SWIG-1.3.23 when the approach to wrapping methods with default arguments was changed.
|
||||
</p>
|
||||
|
||||
<H3><a name="Customization_features_example">12.3.5 Feature example</a></H3>
|
||||
<H3><a name="Customization_features_example">15.3.5 Feature example</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="D">22 SWIG and D</a></H1>
|
||||
<H1><a name="D">24 SWIG and D</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -41,7 +41,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="D_introduction">22.1 Introduction</a></H2>
|
||||
<H2><a name="D_introduction">24.1 Introduction</a></H2>
|
||||
|
||||
|
||||
<p>From the <a href="http://www.digitalmars.com/d/">D Programming Language</a> web site: <em>D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. [...] The D language is statically typed and compiles directly to machine code.</em> As such, it is not very surprising that D is able to directly <a href="http://www.digitalmars.com/d/1.0/interfaceToC.html">interface with C libraries</a>. Why would a SWIG module for D be needed then in the first place?</p>
|
||||
|
|
@ -53,10 +53,10 @@
|
|||
<p>To help addressing these issues, the SWIG C# module has been forked to support D. Is has evolved quite a lot since then, but there are still many similarities, so if you do not find what you are looking for on this page, it might be worth having a look at the chapter on <a href="CSharp.html#CSharp">C#</a> (and also on <a href="Java.html#Java">Java</a>, since the C# module was in turn forked from it).</p>
|
||||
|
||||
|
||||
<H2><a name="D_command_line_invocation">22.2 Command line invocation</a></H2>
|
||||
<H2><a name="D_command_line_invocation">24.2 Command line invocation</a></H2>
|
||||
|
||||
|
||||
<p>To activate the D module, pass the <tt>-d</tt> option to SWIG at the command line. The same standard command line switches as with any other language module are available, plus the following D specific ones:</p>
|
||||
<p>To activate the D module, pass the <tt>-d</tt> option to SWIG at the command line. The same standard command line options as with any other language module are available, plus the following D specific ones:</p>
|
||||
|
||||
<dl>
|
||||
<dt><tt>-d2</tt></dt>
|
||||
|
|
@ -66,8 +66,8 @@
|
|||
|
||||
<dt><a name="D_splitproxy"></a><tt>-splitproxy</tt></dt>
|
||||
<dd>
|
||||
<p>By default, SWIG generates two D modules: the <em>proxy</em> module, named like the source module (either specified via the <tt>%module</tt> directive or via the <tt>module</tt> command line switch), which contains all the proxy classes, functions, enums, etc., and the <em>intermediary</em> module (named like the proxy module, but suffixed with <tt>_im</tt>), which contains all the <tt>extern(C)</tt> function declarations and other private parts only used internally by the proxy module.</p>
|
||||
<p>If the split proxy mode is enabled by passing this switch at the command line, all proxy classes and enums are emitted to their own D module instead. The main proxy module only contains free functions and constants in this case.</p>
|
||||
<p>By default, SWIG generates two D modules: the <em>proxy</em> module, named like the source module (either specified via the <tt>%module</tt> directive or via the <tt>module</tt> command line option), which contains all the proxy classes, functions, enums, etc., and the <em>intermediary</em> module (named like the proxy module, but suffixed with <tt>_im</tt>), which contains all the <tt>extern(C)</tt> function declarations and other private parts only used internally by the proxy module.</p>
|
||||
<p>If the split proxy mode is enabled by passing this option at the command line, all proxy classes and enums are emitted to their own D module instead. The main proxy module only contains free functions and constants in this case.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>-package <pkg></tt></dt>
|
||||
|
|
@ -77,16 +77,16 @@
|
|||
|
||||
<dt><tt>-wrapperlibrary <wl></tt></dt>
|
||||
<dd>
|
||||
<p>The code SWIG generates to dynamically load the C/C++ wrapper layer looks for a library called <tt>$module_wrap</tt> by default. With this switch, you can override the name of the file the wrapper code loads at runtime (the <tt>lib</tt> prefix and the suffix for shared libraries are appended automatically, depending on the OS).</p>
|
||||
<p>The code SWIG generates to dynamically load the C/C++ wrapper layer looks for a library called <tt>$module_wrap</tt> by default. With this option, you can override the name of the file the wrapper code loads at runtime (the <tt>lib</tt> prefix and the suffix for shared libraries are appended automatically, depending on the OS).</p>
|
||||
<p>This might especially be useful if you want to invoke SWIG several times on separate modules, but compile the resulting code into a single shared library.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_typemaps">22.3 Typemaps</a></H2>
|
||||
<H2><a name="D_typemaps">24.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">24.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>
|
||||
|
|
@ -107,12 +107,12 @@
|
|||
csimports <-> dimports
|
||||
csbody <-> dbody
|
||||
csfinalize <-> ddestructor
|
||||
csdestruct <-> ddispose
|
||||
csdestruct_derived <-> ddispose_derived
|
||||
csdisposing <-> ddispose
|
||||
csdisposing_derived <-> ddispose_derived
|
||||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="D_ctype_imtype_dtype">22.3.2 ctype, imtype, dtype</a></H3>
|
||||
<H3><a name="D_ctype_imtype_dtype">24.3.2 ctype, imtype, dtype</a></H3>
|
||||
|
||||
|
||||
<p>Mapping of types between the C/C++ library, the C/C++ library wrapper exposing the C functions, the D wrapper module importing these functions and the D proxy code.</p>
|
||||
|
|
@ -120,7 +120,7 @@
|
|||
<p>The <tt>ctype</tt> typemap is used to determine the types to use in the C wrapper functions. The types from the <tt>imtype</tt> typemap are used in the extern(C) declarations of these functions in the intermediary D module. The <tt>dtype</tt> typemap contains the D types used in the D proxy module/class.</p>
|
||||
|
||||
|
||||
<H3><a name="D_in_out_directorin_direcetorout">22.3.3 in, out, directorin, directorout</a></H3>
|
||||
<H3><a name="D_in_out_directorin_direcetorout">24.3.3 in, out, directorin, directorout</a></H3>
|
||||
|
||||
|
||||
<p>Used for converting between the types for C/C++ and D when generating the code for the wrapper functions (on the C++ side).</p>
|
||||
|
|
@ -130,7 +130,7 @@
|
|||
<p>The <tt>directorin</tt> typemap is used to convert parameters to the type used in the D director callback function, its return value is processed by <tt>directorout</tt> (see below).</p>
|
||||
|
||||
|
||||
<H3><a name="D_din_dout_ddirectorin_ddirectorout">22.3.4 din, dout, ddirectorin, ddirectorout</a></H3>
|
||||
<H3><a name="D_din_dout_ddirectorin_ddirectorout">24.3.4 din, dout, ddirectorin, ddirectorout</a></H3>
|
||||
|
||||
|
||||
<p>Typemaps for code generation in D proxy and type wrapper classes.</p>
|
||||
|
|
@ -157,13 +157,13 @@
|
|||
dtype DClass.method(dtype a)</pre></div>
|
||||
|
||||
|
||||
<H3><a name="D_typecheck_typemaps">22.3.5 typecheck typemaps</a></H3>
|
||||
<H3><a name="D_typecheck_typemaps">24.3.5 typecheck typemaps</a></H3>
|
||||
|
||||
|
||||
<p>Because, unlike many scripting languages supported by SWIG, D does not need any dynamic dispatch helper to access an overloaded function, the purpose of these is merely to issue a warning for overloaded C++ functions that cannot be overloaded in D (as more than one C++ type maps to a single D type).</p>
|
||||
|
||||
|
||||
<H3><a name="D_code_injection_typemaps">22.3.6 Code injection typemaps</a></H3>
|
||||
<H3><a name="D_code_injection_typemaps">24.3.6 Code injection typemaps</a></H3>
|
||||
|
||||
|
||||
<p>These typemaps are used for generating the skeleton of proxy classes for C++ types.</p>
|
||||
|
|
@ -174,8 +174,11 @@
|
|||
|
||||
<p><a name="D_class_code_typemaps"></a><tt>dconstructor</tt>, <tt>ddestructor</tt>, <tt>ddispose</tt> and <tt>ddispose_derived</tt> are used to generate the class constructor, destructor and <tt>dispose()</tt> method, respectively. The auxiliary code for handling the pointer to the C++ object is stored in <tt>dbody</tt> and <tt>dbody_derived</tt>. You can override them for specific types.</p>
|
||||
|
||||
<p>
|
||||
Code can also be injected into the D proxy class using <tt>%proxycode</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="D_special_variables">22.3.7 Special variable macros</a></H3>
|
||||
<H3><a name="D_special_variables">24.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>
|
||||
|
|
@ -277,7 +280,7 @@ class SomeClass : AnInterface, AnotherInterface {
|
|||
...
|
||||
}
|
||||
</pre></div>
|
||||
<p>For this to work, <tt>AnInterface</tt> and <tt>AnotherInterface</tt> have to be in scope. If SWIG is not in split proxy mode, this is already the case, but it it is, they have to be added to the import list via the <tt>dimports</tt> typemap. Additionally, the import statement depends on the package SWIG is configured to emit the modules to.</p>
|
||||
<p>For this to work, <tt>AnInterface</tt> and <tt>AnotherInterface</tt> have to be in scope. If SWIG is not in split proxy mode, this is already the case, but if it is, they have to be added to the import list via the <tt>dimports</tt> typemap. Additionally, the import statement depends on the package SWIG is configured to emit the modules to.</p>
|
||||
<p>The <tt>$importtype</tt> macro helps you to elegantly solve this problem:</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(dimports) RemoteMpe %{
|
||||
|
|
@ -296,7 +299,7 @@ $importtype(AnotherInterface)
|
|||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_features">22.4 D and %feature</a></H2>
|
||||
<H2><a name="D_features">24.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>
|
||||
|
|
@ -326,7 +329,7 @@ struct A {
|
|||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_pragmas">22.5 Pragmas</a></H2>
|
||||
<H2><a name="D_pragmas">24.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>
|
||||
|
|
@ -365,7 +368,7 @@ struct A {
|
|||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_exceptions">22.6 D Exceptions</a></H2>
|
||||
<H2><a name="D_exceptions">24.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>
|
||||
|
|
@ -375,7 +378,7 @@ struct A {
|
|||
<p>As this feature is implemented in exactly the same way it is for C#, please see the <a href="CSharp.html#CSharp_exceptions">C# documentation</a> for a more detailed explanation.</p>
|
||||
|
||||
|
||||
<H2><a name="D_directors">22.7 D Directors</a></H2>
|
||||
<H2><a name="D_directors">24.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>
|
||||
|
|
@ -384,16 +387,16 @@ struct A {
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="D_other_features">22.8 Other features</a></H2>
|
||||
<H2><a name="D_other_features">24.8 Other features</a></H2>
|
||||
|
||||
|
||||
<H3><a name="D_nspace">22.8.1 Extended namespace support (nspace)</a></H3>
|
||||
<H3><a name="D_nspace">24.8.1 Extended namespace support (nspace)</a></H3>
|
||||
|
||||
|
||||
<p>By default, SWIG flattens all C++ namespaces into a single target language namespace, but as for Java and C#, the <a href="SWIGPlus.html#SWIGPlus_nspace"><tt>nspace</tt></a> feature is supported for D. If it is active, C++ namespaces are mapped to D packages/modules. Note, however, that like for the other languages, <em>free</em> variables and functions are not supported yet; currently, they are all allows written to the main proxy D module.</p>
|
||||
|
||||
|
||||
<H3><a name="D_native_pointer_support">22.8.2 Native pointer support</a></H3>
|
||||
<H3><a name="D_native_pointer_support">24.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>
|
||||
|
|
@ -405,7 +408,7 @@ struct A {
|
|||
<p>To determine if a type should be considered primitive, the <tt>cprimitive</tt> attribute on its <tt>dtype</tt> attribute is used. For example, the <tt>dtype</tt> typemap for <tt>float</tt> has <tt>cprimitive="1"</tt>, so the code from the <tt>nativepointer</tt> attribute is taken into account e.g. for <tt>float **</tt> or the function pointer <tt>float (*)(float *)</tt>.</p>
|
||||
|
||||
|
||||
<H3><a name="D_operator_overloading">22.8.3 Operator overloading</a></H3>
|
||||
<H3><a name="D_operator_overloading">24.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>
|
||||
|
|
@ -417,7 +420,7 @@ struct A {
|
|||
<p>There are also some cases where the operators can be translated to D, but the differences in the implementation details are big enough that a rather involved scheme would be required for automatic wrapping them, which has not been implemented yet. This affects, for example, the array subscript operator, <tt>[]</tt>, in combination with assignments - while <tt>operator []</tt> in C++ simply returns a reference which is then written to, D resorts to a separate <tt>opIndexAssign</tt> method -, or implicit casting (which was introduced in D2 via <tt>alias this</tt>). Despite the lack of automatic support, manually handling these cases should be perfectly possible.</p>
|
||||
|
||||
|
||||
<H3><a name="D_test_suite">22.8.4 Running the test-suite</a></H3>
|
||||
<H3><a name="D_test_suite">24.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>
|
||||
|
|
@ -425,14 +428,14 @@ struct A {
|
|||
<p>Note: If you want to use GDC on Linux or another platform which requires you to link <tt>libdl</tt> for dynamically loading the shared library, you might have to add <tt>-ldl</tt> manually to the <tt>d_compile</tt> target in <tt>Examples/Makefile</tt>, because GDC does not currently honor the <tt>pragma(lib, ...)</tt> statement.</p>
|
||||
|
||||
|
||||
<H2><a name="D_typemap_examples">22.9 D Typemap examples</a></H2>
|
||||
<H2><a name="D_typemap_examples">24.9 D Typemap examples</a></H2>
|
||||
|
||||
|
||||
<p>There are no D-specific typemap examples yet. However, with the above <a href="D.html#D_typemap_name_comparison">name comparison table</a>, you should be able to get an idea what can be done by looking at the <a href="CSharp.html#CSharp_typemap_examples">corresponding C# section</a>.</p>
|
||||
|
||||
|
||||
|
||||
<H2><a name="D_planned_features">22.10 Work in progress and planned features</a></H2>
|
||||
<H2><a name="D_planned_features">24.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>
|
||||
|
|
|
|||
1750
Doc/Manual/Doxygen.html
Normal file
1750
Doc/Manual/Doxygen.html
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Extending">41 Extending SWIG to support new languages</a></H1>
|
||||
<H1><a name="Extending">40 Extending SWIG to support new languages</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -64,8 +64,13 @@
|
|||
<li><a href="#Extending_running_test_suite">Running the test-suite</a>
|
||||
</ul>
|
||||
<li><a href="#Extending_nn43">Documentation</a>
|
||||
<li><a href="#Extending_prerequisites">Prerequisites for adding a new language module to the SWIG distribution</a>
|
||||
<li><a href="#Extending_coding_style_guidelines">Coding style guidelines</a>
|
||||
<li><a href="#Extending_language_status">Target language status</a>
|
||||
<ul>
|
||||
<li><a href="#Extending_supported_status">Supported status</a>
|
||||
<li><a href="#Extending_experimental_status">Experimental status</a>
|
||||
</ul>
|
||||
<li><a href="#Extending_prerequisites">Prerequisites for adding a new language module to the SWIG distribution</a>
|
||||
</ul>
|
||||
<li><a href="#Extending_debugging_options">Debugging Options</a>
|
||||
<li><a href="#Extending_nn46">Guide to parse tree nodes</a>
|
||||
|
|
@ -76,7 +81,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="Extending_nn2">41.1 Introduction</a></H2>
|
||||
<H2><a name="Extending_nn2">40.1 Introduction</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -92,7 +97,7 @@ Also, this chapter is not meant to be a hand-holding tutorial. As a starting po
|
|||
you should probably look at one of SWIG's existing modules.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn3">41.2 Prerequisites</a></H2>
|
||||
<H2><a name="Extending_nn3">40.2 Prerequisites</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,7 +127,7 @@ obvious, but almost all SWIG directives as well as the low-level generation of
|
|||
wrapper code are driven by C++ datatypes.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn4">41.3 The Big Picture</a></H2>
|
||||
<H2><a name="Extending_nn4">40.3 The Big Picture</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -159,7 +164,7 @@ role in making the system work. For example, both typemaps and declaration anno
|
|||
based on pattern matching and interact heavily with the underlying type system.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn5">41.4 Execution Model</a></H2>
|
||||
<H2><a name="Extending_nn5">40.4 Execution Model</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -204,7 +209,7 @@ latter stage of compilation.
|
|||
The next few sections briefly describe some of these stages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn6">41.4.1 Preprocessing</a></H3>
|
||||
<H3><a name="Extending_nn6">40.4.1 Preprocessing</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -278,14 +283,14 @@ or <tt>perl5.swg</tt>.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
As a debugging aide, the text that SWIG feeds to its C++ parser can be
|
||||
As a debugging aid, the text that SWIG feeds to its C++ parser can be
|
||||
obtained by running <tt>swig -E interface.i</tt>. This output
|
||||
probably isn't too useful in general, but it will show how macros have
|
||||
been expanded as well as everything else that goes into the low-level
|
||||
construction of the wrapper code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn7">41.4.2 Parsing</a></H3>
|
||||
<H3><a name="Extending_nn7">40.4.2 Parsing</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -386,7 +391,7 @@ returning a <tt>foo</tt> and taking types <tt>a</tt> and <tt>b</tt> as
|
|||
arguments).
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn8">41.4.3 Parse Trees</a></H3>
|
||||
<H3><a name="Extending_nn8">40.4.3 Parse Trees</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -641,7 +646,7 @@ $ swig -c++ -python -debug-module 4 example.i
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn9">41.4.4 Attribute namespaces</a></H3>
|
||||
<H3><a name="Extending_nn9">40.4.4 Attribute namespaces</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -660,7 +665,7 @@ that matches the name of the target language. For example, <tt>python:foo</tt>
|
|||
<tt>perl:foo</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn10">41.4.5 Symbol Tables</a></H3>
|
||||
<H3><a name="Extending_nn10">40.4.5 Symbol Tables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -729,7 +734,7 @@ For instance, the following example uses <tt>%rename</tt> in reverse to generate
|
|||
<div class="code">
|
||||
<pre>
|
||||
%rename(foo) foo_i(int);
|
||||
%rename(foo) foo_d(double;
|
||||
%rename(foo) foo_d(double);
|
||||
|
||||
void foo_i(int);
|
||||
void foo_d(double);
|
||||
|
|
@ -751,7 +756,7 @@ example.i:5. Previous declaration is foo_i(int )
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn11">41.4.6 The %feature directive</a></H3>
|
||||
<H3><a name="Extending_nn11">40.4.6 The %feature directive</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -807,7 +812,7 @@ For example, the exception code above is simply
|
|||
stored without any modifications.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn12">41.4.7 Code Generation</a></H3>
|
||||
<H3><a name="Extending_nn12">40.4.7 Code Generation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -929,7 +934,7 @@ public :
|
|||
The role of these functions is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn13">41.4.8 SWIG and XML</a></H3>
|
||||
<H3><a name="Extending_nn13">40.4.8 SWIG and XML</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -942,7 +947,7 @@ internal data structures, it may be useful to keep XML in the back of
|
|||
your mind as a model.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn14">41.5 Primitive Data Structures</a></H2>
|
||||
<H2><a name="Extending_nn14">40.5 Primitive Data Structures</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -988,7 +993,7 @@ typedef Hash Typetab;
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn15">41.5.1 Strings</a></H3>
|
||||
<H3><a name="Extending_nn15">40.5.1 Strings</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1129,7 +1134,7 @@ Returns the number of replacements made (if any).
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn16">41.5.2 Hashes</a></H3>
|
||||
<H3><a name="Extending_nn16">40.5.2 Hashes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1206,7 +1211,7 @@ Returns the list of hash table keys.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn17">41.5.3 Lists</a></H3>
|
||||
<H3><a name="Extending_nn17">40.5.3 Lists</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1295,7 +1300,7 @@ If <tt>t</tt> is not a standard object, it is assumed to be a <tt>char *</tt>
|
|||
and is used to create a String object.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn18">41.5.4 Common operations</a></H3>
|
||||
<H3><a name="Extending_nn18">40.5.4 Common operations</a></H3>
|
||||
|
||||
|
||||
The following operations are applicable to all datatypes.
|
||||
|
|
@ -1350,7 +1355,7 @@ objects and report errors.
|
|||
Gets the line number associated with <tt>x</tt>.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn19">41.5.5 Iterating over Lists and Hashes</a></H3>
|
||||
<H3><a name="Extending_nn19">40.5.5 Iterating over Lists and Hashes</a></H3>
|
||||
|
||||
|
||||
To iterate over the elements of a list or a hash table, the following functions are used:
|
||||
|
|
@ -1395,7 +1400,7 @@ for (j = First(j); j.item; j= Next(j)) {
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn20">41.5.6 I/O</a></H3>
|
||||
<H3><a name="Extending_nn20">40.5.6 I/O</a></H3>
|
||||
|
||||
|
||||
Special I/O functions are used for all internal I/O. These operations
|
||||
|
|
@ -1529,7 +1534,7 @@ Printf(f, "%s\n", s);
|
|||
Similarly, the preprocessor and parser all operate on string-files.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn21">41.6 Navigating and manipulating parse trees</a></H2>
|
||||
<H2><a name="Extending_nn21">40.6 Navigating and manipulating parse trees</a></H2>
|
||||
|
||||
|
||||
Parse trees are built as collections of hash tables. Each node is a hash table in which
|
||||
|
|
@ -1576,7 +1581,7 @@ return the node for the first class member.
|
|||
|
||||
<div class="indent">
|
||||
Returns the last child node. You might use this if you wanted to append a new
|
||||
node to the of a class.
|
||||
node to the children of a class.
|
||||
</div>
|
||||
|
||||
<p>
|
||||
|
|
@ -1663,7 +1668,7 @@ Deletes a node from the parse tree. Deletion reconnects siblings and properly u
|
|||
the parent so that sibling nodes are unaffected.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn22">41.7 Working with attributes</a></H2>
|
||||
<H2><a name="Extending_nn22">40.7 Working with attributes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1780,7 +1785,7 @@ the attribute is optional. <tt>Swig_restore()</tt> must always be called after
|
|||
function.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn23">41.8 Type system</a></H2>
|
||||
<H2><a name="Extending_nn23">40.8 Type system</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1789,7 +1794,7 @@ pointers, references, and pointers to members. A detailed discussion of
|
|||
type theory is impossible here. However, let's cover the highlights.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn24">41.8.1 String encoding of types</a></H3>
|
||||
<H3><a name="Extending_nn24">40.8.1 String encoding of types</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1890,7 +1895,7 @@ make the final type, the two parts are just joined together using
|
|||
string concatenation.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn25">41.8.2 Type construction</a></H3>
|
||||
<H3><a name="Extending_nn25">40.8.2 Type construction</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2059,7 +2064,7 @@ Returns the prefix of a type. For example, if <tt>ty</tt> is
|
|||
<tt>ty</tt> is unmodified.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn26">41.8.3 Type tests</a></H3>
|
||||
<H3><a name="Extending_nn26">40.8.3 Type tests</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2146,7 +2151,7 @@ Checks if <tt>ty</tt> is a varargs type.
|
|||
Checks if <tt>ty</tt> is a templatized type.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn27">41.8.4 Typedef and inheritance</a></H3>
|
||||
<H3><a name="Extending_nn27">40.8.4 Typedef and inheritance</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2248,7 +2253,7 @@ Fully reduces <tt>ty</tt> according to typedef rules. Resulting datatype
|
|||
will consist only of primitive typenames.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn28">41.8.5 Lvalues</a></H3>
|
||||
<H3><a name="Extending_nn28">40.8.5 Lvalues</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2285,7 +2290,7 @@ Literal y; // type = 'Literal', ltype='p.char'
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn29">41.8.6 Output functions</a></H3>
|
||||
<H3><a name="Extending_nn29">40.8.6 Output functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2347,7 +2352,7 @@ SWIG, but is most commonly associated with type-descriptor objects
|
|||
that appear in wrappers (e.g., <tt>SWIGTYPE_p_double</tt>).
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn30">41.9 Parameters</a></H2>
|
||||
<H2><a name="Extending_nn30">40.9 Parameters</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2446,7 +2451,7 @@ included. Used to emit prototypes.
|
|||
Returns the number of required (non-optional) arguments in <tt>p</tt>.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn31">41.10 Writing a Language Module</a></H2>
|
||||
<H2><a name="Extending_nn31">40.10 Writing a Language Module</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2461,7 +2466,7 @@ describes the creation of a minimal Python module. You should be able to extra
|
|||
this to other languages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn32">41.10.1 Execution model</a></H3>
|
||||
<H3><a name="Extending_nn32">40.10.1 Execution model</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2471,7 +2476,7 @@ the parsing of command line options, all aspects of code generation are controll
|
|||
different methods of the <tt>Language</tt> that must be defined by your module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_starting_out">41.10.2 Starting out</a></H3>
|
||||
<H3><a name="Extending_starting_out">40.10.2 Starting out</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2579,7 +2584,7 @@ that activates your module. For example, <tt>swig -python foo.i</tt>. The
|
|||
messages from your new module should appear.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn34">41.10.3 Command line options</a></H3>
|
||||
<H3><a name="Extending_nn34">40.10.3 Command line options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2592,36 +2597,36 @@ command line options, simply use code similar to this:
|
|||
<pre>
|
||||
void Language::main(int argc, char *argv[]) {
|
||||
for (int i = 1; i < argc; i++) {
|
||||
if (argv[i]) {
|
||||
if (strcmp(argv[i], "-interface") == 0) {
|
||||
if (argv[i+1]) {
|
||||
interface = NewString(argv[i+1]);
|
||||
Swig_mark_arg(i);
|
||||
Swig_mark_arg(i+1);
|
||||
i++;
|
||||
} else {
|
||||
Swig_arg_error();
|
||||
}
|
||||
} else if (strcmp(argv[i], "-globals") == 0) {
|
||||
if (argv[i+1]) {
|
||||
global_name = NewString(argv[i+1]);
|
||||
Swig_mark_arg(i);
|
||||
Swig_mark_arg(i+1);
|
||||
i++;
|
||||
} else {
|
||||
Swig_arg_error();
|
||||
}
|
||||
} else if ((strcmp(argv[i], "-proxy") == 0)) {
|
||||
proxy_flag = 1;
|
||||
Swig_mark_arg(i);
|
||||
} else if (strcmp(argv[i], "-keyword") == 0) {
|
||||
use_kw = 1;
|
||||
Swig_mark_arg(i);
|
||||
} else if (strcmp(argv[i], "-help") == 0) {
|
||||
fputs(usage, stderr);
|
||||
}
|
||||
...
|
||||
if (argv[i]) {
|
||||
if (strcmp(argv[i], "-interface") == 0) {
|
||||
if (argv[i+1]) {
|
||||
interface = NewString(argv[i+1]);
|
||||
Swig_mark_arg(i);
|
||||
Swig_mark_arg(i+1);
|
||||
i++;
|
||||
} else {
|
||||
Swig_arg_error();
|
||||
}
|
||||
} else if (strcmp(argv[i], "-globals") == 0) {
|
||||
if (argv[i+1]) {
|
||||
global_name = NewString(argv[i+1]);
|
||||
Swig_mark_arg(i);
|
||||
Swig_mark_arg(i+1);
|
||||
i++;
|
||||
} else {
|
||||
Swig_arg_error();
|
||||
}
|
||||
} else if ((strcmp(argv[i], "-proxy") == 0)) {
|
||||
proxy_flag = 1;
|
||||
Swig_mark_arg(i);
|
||||
} else if (strcmp(argv[i], "-keyword") == 0) {
|
||||
use_kw = 1;
|
||||
Swig_mark_arg(i);
|
||||
} else if (strcmp(argv[i], "-help") == 0) {
|
||||
fputs(usage, stderr);
|
||||
}
|
||||
...
|
||||
}
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
|
@ -2638,7 +2643,7 @@ to mark the option as valid. If you forget to do this, SWIG will terminate wit
|
|||
unrecognized command line option error.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn35">41.10.4 Configuration and preprocessing</a></H3>
|
||||
<H3><a name="Extending_nn35">40.10.4 Configuration and preprocessing</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2687,7 +2692,7 @@ an implementation file <tt>python.cxx</tt> and a configuration file
|
|||
<tt>python.swg</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn36">41.10.5 Entry point to code generation</a></H3>
|
||||
<H3><a name="Extending_nn36">40.10.5 Entry point to code generation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2745,7 +2750,7 @@ int Python::top(Node *n) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn37">41.10.6 Module I/O and wrapper skeleton</a></H3>
|
||||
<H3><a name="Extending_nn37">40.10.6 Module I/O and wrapper skeleton</a></H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to mgossage -->
|
||||
|
|
@ -2893,7 +2898,7 @@ functionWrapper : void Shape_y_set(Shape *self, double y)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn38">41.10.7 Low-level code generators</a></H3>
|
||||
<H3><a name="Extending_nn38">40.10.7 Low-level code generators</a></H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to mgossage -->
|
||||
|
|
@ -3026,7 +3031,7 @@ virtual int functionWrapper(Node *n) {
|
|||
/* Close the function(error) */
|
||||
Printv(wrapper->code, "return ERROR;\n", "}\n", NIL);
|
||||
|
||||
/* final substititions if applicable */
|
||||
/* final substitutions if applicable */
|
||||
...
|
||||
|
||||
/* Dump the function out */
|
||||
|
|
@ -3047,7 +3052,7 @@ but without the typemaps, there is still work to do.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Extending_configuration_files">41.10.8 Configuration files</a></H3>
|
||||
<H3><a name="Extending_configuration_files">40.10.8 Configuration files</a></H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to ttn -->
|
||||
|
|
@ -3164,7 +3169,7 @@ these kinds of problems.
|
|||
</p>
|
||||
|
||||
<dt> <b>Examples/Makefile.in</b>
|
||||
<dd> Nothing special here; see comments at top the of this file
|
||||
<dd> Nothing special here; see comments at the top of this file
|
||||
and look to the existing languages for examples.
|
||||
|
||||
<dt> <b>Examples/qux99/check.list</b>
|
||||
|
|
@ -3191,7 +3196,7 @@ politely displays the ignoring language message.
|
|||
</dl>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn40">41.10.9 Runtime support</a></H3>
|
||||
<H3><a name="Extending_nn40">40.10.9 Runtime support</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3200,7 +3205,7 @@ Discuss the kinds of functions typically needed for SWIG runtime support (e.g.
|
|||
the SWIG files that implement those functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn41">41.10.10 Standard library files</a></H3>
|
||||
<H3><a name="Extending_nn41">40.10.10 Standard library files</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3219,7 +3224,7 @@ The following are the minimum that are usually supported:
|
|||
Please copy these and modify for any new language.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn42">41.10.11 User examples</a></H3>
|
||||
<H3><a name="Extending_nn42">40.10.11 User examples</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3248,7 +3253,7 @@ during this process, see the section on <a href="#Extending_configuration_files"
|
|||
files</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_test_suite">41.10.12 Test driven development and the test-suite</a></H3>
|
||||
<H3><a name="Extending_test_suite">40.10.12 Test driven development and the test-suite</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3307,7 +3312,7 @@ It is therefore essential that the runtime tests are written in a manner that di
|
|||
but error/exception out with an error message on stderr on failure.
|
||||
</p>
|
||||
|
||||
<H4><a name="Extending_running_test_suite">41.10.12.1 Running the test-suite</a></H4>
|
||||
<H4><a name="Extending_running_test_suite">40.10.12.1 Running the test-suite</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3499,7 +3504,7 @@ It can be run in the same way as the other language test-suites, replacing [lang
|
|||
The test cases used and the way it works is described in <tt>Examples/test-suite/errors/Makefile.in</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn43">41.10.13 Documentation</a></H3>
|
||||
<H3><a name="Extending_nn43">40.10.13 Documentation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3531,64 +3536,7 @@ Some topics that you'll want to be sure to address include:
|
|||
if available.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Extending_prerequisites">41.10.14 Prerequisites for adding a new language module to the SWIG distribution</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
If you wish for a new language module to be distributed with SWIG,
|
||||
which we encourage for all popular languages, there are a few requirements.
|
||||
While we appreciate that getting all aspects of a new language working
|
||||
won't happen at the outset, there are a set of minimum requirements before
|
||||
a module can be committed into the official Github repository for distribution with future
|
||||
versions of SWIG. The following are really a summary of this whole section with
|
||||
details being outlined earlier on.
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
Demonstrate basic C code working by porting the "simple" example including
|
||||
a runtime test, see for example <tt>Examples/python/simple</tt>.
|
||||
</li>
|
||||
<li>
|
||||
Demonstrate basic C++ code working by porting the "class" example including
|
||||
a runtime test, see for example <tt>Examples/python/class</tt>.
|
||||
</li>
|
||||
<li>
|
||||
Modify <tt>configure.ac</tt>, <tt>Makefile.in</tt> and <tt>Examples/Makefile.in</tt> to run
|
||||
these examples. Please make sure that if the new language is not
|
||||
installed properly on a box, <tt>make -k check</tt> should still work by
|
||||
skipping the tests and examples for the new language module.
|
||||
</li>
|
||||
<li>
|
||||
Get the test-suite running for the new language (<tt>make check-[lang]-test-suite</tt>).
|
||||
While the test-suite tests many corner cases,
|
||||
we'd expect the majority of it to work by compiling the generated code
|
||||
correctly as most of the corner cases are covered in the SWIG core. Get
|
||||
at least one C and one C++ runtime test running in the test-suite.
|
||||
</li>
|
||||
<li>
|
||||
Provide a chapter in the html documentation on the basics of using
|
||||
the language module.
|
||||
</li>
|
||||
<li>
|
||||
Ensure your source code is formatted according to the <a href="#Extending_coding_style_guidelines">coding style guidelines</a>.
|
||||
</li>
|
||||
<li>
|
||||
Finally, email the SWIG developers with a patch and a demonstration of
|
||||
commitment to maintaining the language module,
|
||||
certainly in the short term and ideally long term.
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
Once accepted into the official Git repository, development efforts should concentrate on
|
||||
getting the entire test-suite to work with plenty of runtime tests.
|
||||
Runtime tests should be for existing testcases and new test cases
|
||||
should be added should there be an area not already covered by
|
||||
the existing tests.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_coding_style_guidelines">41.10.15 Coding style guidelines</a></H3>
|
||||
<H3><a name="Extending_coding_style_guidelines">40.10.14 Coding style guidelines</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3612,7 +3560,193 @@ The generated C/C++ code should also follow this style as close as possible. How
|
|||
should be avoided as unlike the SWIG developers, users will never have consistent tab settings.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_debugging_options">41.11 Debugging Options</a></H2>
|
||||
|
||||
<H3><a name="Extending_language_status">40.10.15 Target language status</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
Target languages are given a status of either 'Supported' or 'Experimental' depending on their maturity as broadly outlined in
|
||||
the <a href="Introduction.html#Introduction_target_languages">Target language introduction</a>.
|
||||
This section provides more details on how this status is given.
|
||||
</p>
|
||||
|
||||
<H4><a name="Extending_supported_status">40.10.15.1 Supported status</a></H4>
|
||||
|
||||
|
||||
<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.
|
||||
The level of documentation should be comprehensive and match the standard of the other mature modules.
|
||||
Python and Java are good references.</li>
|
||||
<li>
|
||||
It passes all of the main SWIG test-suite.
|
||||
The main test-suite is defined by the tests in the C_TEST_CASES, CPP_TEST_CASES and MULTI_CPP_TEST_CASES lists in Examples/test-suite/common.mk.
|
||||
The tests in CPP11_TEST_CASES will also be required in the near future.
|
||||
</li>
|
||||
<li>
|
||||
The test-suite must also include at least twenty wide-ranging runtime tests.
|
||||
The most mature languages have a few hundred runtime tests.
|
||||
Note that porting runtime tests from another language module is a quick and easy way to achieve this.
|
||||
</li>
|
||||
<li>
|
||||
It supports the vast majority of SWIG features.
|
||||
Some more advanced features, such as, directors, full nested class support and target language namespaces (nspace) may be unimplemented.
|
||||
A few support libraries may be missing, for example, a small number of STL libraries.</li>
|
||||
<li>
|
||||
It provides strong backwards compatibility between releases.
|
||||
Each point release must aim to be fully backwards compatible.
|
||||
A point release version is the 3rd version digit, so each of the x.y.* versions should be backwards compatible.
|
||||
Backwards compatibility breakages can occur in a new major or minor version if absolutely necessary and if documented.
|
||||
A major or minor version is the first or second digit in the three digit version.
|
||||
</li>
|
||||
<li>
|
||||
Fixing unintended regressions in the Supported languages will be given higher priority over experimental languages by the core SWIG developers.
|
||||
</li>
|
||||
<li>
|
||||
Examples must be available and run successfully.
|
||||
</li>
|
||||
<li>
|
||||
The examples and test-suite must be fully functioning on the Travis Continuous Integration platform.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<H4><a name="Extending_experimental_status">40.10.15.2 Experimental status</a></H4>
|
||||
|
||||
|
||||
<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 is in need of help to finish development.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Some minimum requirements and notes about languages with the 'Experimental' status:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Will at least implement basic functionality - support wrapping C functions and simple C++ classes and templates.
|
||||
</li>
|
||||
<li>
|
||||
Have its own documentation chapter containing a reasonable level of detail.
|
||||
The documentation must provide enough basic functionality for a user to get started.
|
||||
</li>
|
||||
<li>
|
||||
Have fully functional examples of basic functionality (the simple and class examples).
|
||||
</li>
|
||||
<li>
|
||||
The test-suite must be implemented and include a few runtime tests for both C and C++ test cases.
|
||||
</li>
|
||||
<li>
|
||||
Failing tests must be put into one of the FAILING_CPP_TESTS or FAILING_C_TESTS lists in the test-suite.
|
||||
This will ensure the test-suite can be superficially made to pass by ignoring failing tests.
|
||||
The number of tests in these lists should be no greater than half of the number of tests in the full test-suite.
|
||||
</li>
|
||||
<li>
|
||||
The examples and test-suite must also be fully functioning on the Travis Continuous Integration platform.
|
||||
However, experimental languages will be set as 'allow_failures'.
|
||||
This means that pull requests and normal development commits will not break the entire Travis build should an experimental language fail.
|
||||
</li>
|
||||
<li>
|
||||
Any new failed tests will be fixed on a 'best effort' basis by core developers with no promises made.
|
||||
</li>
|
||||
<li>
|
||||
If a language module has an official maintainer, then the maintainer will be requested to focus on fixing test-suite regressions and commit to migrating the module to become a 'Supported' module.
|
||||
</li>
|
||||
<li>
|
||||
If a module does not have an official maintainer, then, as maintenance will be on a 'best efforts' basis by the core maintainers, no guarantees will be provided from one release to the next and regressions may creep in.
|
||||
</li>
|
||||
<li>
|
||||
Experimental target languages will have a (suppressible) warning explaining the Experimental sub-standard status and encourage users to help improve it.
|
||||
</li>
|
||||
<li>
|
||||
No backwards compatibility is guaranteed as the module is effectively 'in development'.
|
||||
If a language module has an official maintainer, then a backwards compatibility guarantee may be provided at the maintainer's discretion and should be documented as such.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Extending_prerequisites">40.10.16 Prerequisites for adding a new language module to the SWIG distribution</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
New target language modules can be included in SWIG and contributions are encouraged for popular languages.
|
||||
In order to be considered for inclusion, a language must at a minimum fit the 'Experimental' status described above.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Below are some practical steps that should help meet these requirements.
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
The "simple" example needs to be working to demonstrate basic C code wrappers.
|
||||
Port the example from another language, such as from <tt>Examples/python/simple</tt>.
|
||||
</li>
|
||||
<li>
|
||||
The "class" example needs to be working to demonstrate basic C++ code wrappers.
|
||||
Port the example from another language, such as from <tt>Examples/python/class</tt>.
|
||||
</li>
|
||||
<li>
|
||||
Modify <tt>configure.ac</tt>, <tt>Makefile.in</tt> and <tt>Examples/Makefile.in</tt> to run
|
||||
these examples. Please make sure that if the new language is not
|
||||
installed properly on a box, <tt>make -k check</tt> should still work by
|
||||
skipping the tests and examples for the new language module.
|
||||
</li>
|
||||
<li>
|
||||
Copying an existing language module and adapting the source for it is likely to be the most efficient
|
||||
approach to fully developing a new module as a number of corner cases are covered in the existing implementations.
|
||||
The most advanced scripting languages are Python and Ruby.
|
||||
The most advanced compiled target languages are Java and C#.
|
||||
</li>
|
||||
<li>
|
||||
Get the <a href="#Extending_running_test_suite">test-suite</a> running for the new language (<tt>make check-[lang]-test-suite</tt>).
|
||||
While the test-suite tests many corner cases,
|
||||
we'd expect the majority of it to work without much effort once the generated code is compiling
|
||||
correctly for basic functionality as most of the corner cases are covered in the SWIG core. Aim to first get
|
||||
one C and one C++ runtime test running in the test-suite.
|
||||
Adding further runtime tests should be a lot easier afterwards by porting existing runtime tests from another language module.
|
||||
</li>
|
||||
<li>
|
||||
The structure and contents of the html documentation chapter can be copied and adapted from one of the other language modules.
|
||||
</li>
|
||||
<li>
|
||||
Source code can be formatted correctly using the info in the <a href="#Extending_coding_style_guidelines">coding style guidelines</a> section.
|
||||
</li>
|
||||
<li>
|
||||
When ready, post a patch on Github, join the swig-devel mailing list and email the SWIG developers with a demonstration of
|
||||
commitment to maintaining the language module,
|
||||
certainly in the short term and ideally long term.
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
Once accepted into the official Git repository, development efforts should concentrate on
|
||||
getting the entire test-suite to work
|
||||
in order to migrate the language module to the 'Supported' status.
|
||||
Runtime tests should be added for existing testcases and new test cases
|
||||
can be added should there be an area not already covered by
|
||||
the existing tests.
|
||||
</p>
|
||||
|
||||
|
||||
<H2><a name="Extending_debugging_options">40.11 Debugging Options</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3639,7 +3773,7 @@ There are various command line options which can aid debugging a SWIG interface
|
|||
The complete list of command line options for SWIG are available by running <tt>swig -help</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn46">41.12 Guide to parse tree nodes</a></H2>
|
||||
<H2><a name="Extending_nn46">40.12 Guide to parse tree nodes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4047,7 +4181,7 @@ extern "X" { ... } declaration.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_further_info">41.13 Further Development Information</a></H2>
|
||||
<H2><a name="Extending_further_info">40.13 Further Development Information</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Go">23 SWIG and Go</a></H1>
|
||||
<H1><a name="Go">25 SWIG and Go</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -57,7 +57,7 @@ the Go programming language
|
|||
see <a href="http://golang.org/">golang.org</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Go_overview">23.1 Overview</a></H2>
|
||||
<H2><a name="Go_overview">25.1 Overview</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -86,7 +86,7 @@ type-safe as well. In case of type issues the build will fail and hence SWIG's
|
|||
are not used.
|
||||
</p>
|
||||
|
||||
<H2><a name="Go_examples">23.2 Examples</a></H2>
|
||||
<H2><a name="Go_examples">25.2 Examples</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -101,7 +101,7 @@ SWIG interface file extension for backwards compatibility with Go 1.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Go_running_swig">23.3 Running SWIG with Go</a></H2>
|
||||
<H2><a name="Go_running_swig">25.3 Running SWIG with Go</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -125,16 +125,15 @@ Go distribution. To generate code for gccgo, you should also use the
|
|||
</p>
|
||||
|
||||
<p>
|
||||
When using the <tt>-cgo</tt> option, SWIG will generate files that can be used
|
||||
directly by <tt>go build</tt>. Starting with the Go 1.5 distribution the
|
||||
<tt>-cgo</tt> option has to be given. Put your SWIG interface file in a
|
||||
directory under GOPATH/src, and give it a name that does <b>not</b> end in the
|
||||
.swig or .swigcxx extension. Typically the SWIG interface file extension is .i
|
||||
in this case.
|
||||
By default SWIG will generate files that can be used directly
|
||||
by <tt>go build</tt>. This requires Go 1.2 or later. Put your SWIG
|
||||
interface file in a directory under GOPATH/src, and give it a name
|
||||
that does <b>not</b> end in the .swig or .swigcxx extension.
|
||||
Typically the SWIG interface file extension is .i in this case.
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -go -cgo example.i
|
||||
% swig -go example.i
|
||||
% go install
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -144,15 +143,16 @@ usual.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
To use SWIG without the <tt>-cgo</tt> option, more steps are required. Recall
|
||||
that this only works with Go versions before 1.5. When using Go version 1.2 or
|
||||
later, or when using gccgo, the code generated by SWIG can be linked directly
|
||||
into the Go program. A typical command sequence when using the Go compiler of
|
||||
the Go distribution would look like this:
|
||||
SWIG can be used without cgo, via the <tt>-no-cgo</tt> option, but
|
||||
more steps are required. This only works with Go versions before 1.5.
|
||||
When using Go version 1.2 or later, or when using gccgo, the code
|
||||
generated by SWIG can be linked directly into the Go program. A
|
||||
typical command sequence when using the Go compiler of the Go
|
||||
distribution would look like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -go example.i
|
||||
% swig -go -no-cgo example.i
|
||||
% gcc -c code.c # The C library being wrapped.
|
||||
% gcc -c example_wrap.c
|
||||
% go tool 6g example.go
|
||||
|
|
@ -169,7 +169,7 @@ sequence for this approach would look like this:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -go -use-shlib example.i
|
||||
% swig -go -no-cgo -use-shlib example.i
|
||||
% gcc -c -fpic example.c
|
||||
% gcc -c -fpic example_wrap.c
|
||||
% gcc -shared example.o example_wrap.o -o example.so
|
||||
|
|
@ -181,7 +181,7 @@ sequence for this approach would look like this:
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Go_commandline">23.3.1 Go-specific Commandline Options</a></H3>
|
||||
<H3><a name="Go_commandline">25.3.1 Go-specific Commandline Options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -200,10 +200,15 @@ swig -go -help
|
|||
|
||||
<tr>
|
||||
<td>-cgo</td>
|
||||
<td>Generate files to be used as input for the Go cgo tool. This
|
||||
option is required for Go 1.5 and later, and works for Go 1.2 and
|
||||
later. In the future this option will likely become the
|
||||
default.</td>
|
||||
<td>Generate files to be used as input for the Go cgo tool. This is
|
||||
the default.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-no-cgo</td>
|
||||
<td>Generate files that can be used directly, rather than via the Go
|
||||
cgo tool. This option does not work with Go 1.5 or later. It is
|
||||
required for versions of Go before 1.2.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
|
@ -261,18 +266,25 @@ swig -go -help
|
|||
ignored.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-import-prefix <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>
|
||||
|
||||
|
||||
<H3><a name="Go_outputs">23.3.2 Generated Wrapper Files</a></H3>
|
||||
<H3><a name="Go_outputs">25.3.2 Generated Wrapper Files</a></H3>
|
||||
|
||||
|
||||
<p>There are two different approaches to generating wrapper files,
|
||||
controlled by SWIG's <tt>-cgo</tt> option. The <tt>-cgo</tt> option
|
||||
works with Go version 1.2 or later. It is required when using Go
|
||||
version 1.5 or later.</p>
|
||||
controlled by SWIG's <tt>-no-cgo</tt> option. The <tt>-no-cgo</tt>
|
||||
option only works with version of Go before 1.5. It is required
|
||||
when using versions of Go before 1.2.</p>
|
||||
|
||||
<p>With or without the <tt>-cgo</tt> option, SWIG will generate the
|
||||
<p>With or without the <tt>-no-cgo</tt> option, SWIG will generate the
|
||||
following files when generating wrapper code:</p>
|
||||
|
||||
<ul>
|
||||
|
|
@ -296,8 +308,8 @@ or C++ compiler.
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<p>When neither the <tt>-cgo</tt> nor the <tt>-gccgo</tt> option is
|
||||
used, SWIG will also generate an additional file:</p>
|
||||
<p>When the <tt>-no-cgo</tt> option is used, and the <tt>-gccgo</tt>
|
||||
option is not used, SWIG will also generate an additional file:</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -308,7 +320,7 @@ combined with the compiled MODULE.go using go tool pack.
|
|||
</ul>
|
||||
|
||||
|
||||
<H2><a name="Go_basic_tour">23.4 A tour of basic C/C++ wrapping</a></H2>
|
||||
<H2><a name="Go_basic_tour">25.4 A tour of basic C/C++ wrapping</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -318,7 +330,7 @@ modifications have to occur. This section briefly covers the
|
|||
essential aspects of this wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_package">23.4.1 Go Package Name</a></H3>
|
||||
<H3><a name="Go_package">25.4.1 Go Package Name</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -328,7 +340,7 @@ directive. You may override this by using SWIG's <tt>-package</tt>
|
|||
command line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_names">23.4.2 Go Names</a></H3>
|
||||
<H3><a name="Go_names">25.4.2 Go Names</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -360,7 +372,7 @@ followed by that name, and the destructor will be
|
|||
named <tt>Delete</tt> followed by that name.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_constants">23.4.3 Go Constants</a></H3>
|
||||
<H3><a name="Go_constants">25.4.3 Go Constants</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -368,7 +380,7 @@ C/C++ constants created via <tt>#define</tt> or the <tt>%constant</tt>
|
|||
directive become Go constants, declared with a <tt>const</tt>
|
||||
declaration.
|
||||
|
||||
<H3><a name="Go_enumerations">23.4.4 Go Enumerations</a></H3>
|
||||
<H3><a name="Go_enumerations">25.4.4 Go Enumerations</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -378,7 +390,7 @@ usual). The values of the enumeration will become variables in Go;
|
|||
code should avoid modifying those variables.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_classes">23.4.5 Go Classes</a></H3>
|
||||
<H3><a name="Go_classes">25.4.5 Go Classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -456,7 +468,7 @@ returns a go interface. If the returned pointer can be null, you can check
|
|||
for this by calling the Swigcptr() method.
|
||||
</p>
|
||||
|
||||
<H4><a name="Go_class_memory">23.4.5.1 Go Class Memory Management</a></H4>
|
||||
<H4><a name="Go_class_memory">25.4.5.1 Go Class Memory Management</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -471,7 +483,7 @@ The most Go idiomatic way to manage the memory for some C++ class is to call
|
|||
<tt><a href="https://golang.org/doc/effective_go.html#defer">defer</a></tt> of
|
||||
the <tt>DeleteClassName</tt> call. Using <tt>defer</tt> ensures that the memory
|
||||
of the C++ object is freed as soon as the function containing the <tt>defer</tt>
|
||||
statement returns. Furthemore <tt>defer</tt> works great for short-lived
|
||||
statement returns. Furthermore <tt>defer</tt> works great for short-lived
|
||||
objects and fits nicely C++'s RAII idiom. Example:
|
||||
</p>
|
||||
<div class="code">
|
||||
|
|
@ -512,7 +524,7 @@ func main() {
|
|||
|
||||
<p>
|
||||
Using <tt>defer</tt> has limitations though, especially when it comes to
|
||||
long-lived C++ objects whichs lifetimes are hard to predict. For such C++
|
||||
long-lived C++ objects whose lifetimes are hard to predict. For such C++
|
||||
objects a common technique is to store the C++ object into a Go object, and to
|
||||
use the Go function <tt>runtime.SetFinalizer</tt> to add a finalizer which frees
|
||||
the C++ object when the Go object is freed. It is strongly recommended to read
|
||||
|
|
@ -578,7 +590,7 @@ func (o *GoClassName) Close() {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Go_class_inheritance">23.4.5.2 Go Class Inheritance</a></H4>
|
||||
<H4><a name="Go_class_inheritance">25.4.5.2 Go Class Inheritance</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -590,16 +602,16 @@ Doing the reverse will require an explicit type assertion, which will
|
|||
be checked dynamically.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_templates">23.4.6 Go Templates</a></H3>
|
||||
<H3><a name="Go_templates">25.4.6 Go Templates</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
In order to use C++ templates in Go, you must tell SWIG to create
|
||||
wrappers for a particular template instantation. To do this, use
|
||||
wrappers for a particular template instantiation. To do this, use
|
||||
the <tt>%template</tt> directive.
|
||||
|
||||
|
||||
<H3><a name="Go_director_classes">23.4.7 Go Director Classes</a></H3>
|
||||
<H3><a name="Go_director_classes">25.4.7 Go Director Classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -611,13 +623,13 @@ work is necessary.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
This subchapter gives a step by step guide how to properly sublass a C++ class
|
||||
This subchapter gives a step by step guide how to properly subclass a C++ class
|
||||
with a Go type. In general it is strongly recommended to follow this guide
|
||||
completely to avoid common pitfalls with directors in Go.
|
||||
</p>
|
||||
|
||||
|
||||
<H4><a name="Go_director_example_cpp_code">23.4.7.1 Example C++ code</a></H4>
|
||||
<H4><a name="Go_director_example_cpp_code">25.4.7.1 Example C++ code</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -639,12 +651,12 @@ public:
|
|||
virtual ~FooBarAbstract() {};
|
||||
|
||||
std::string FooBar() {
|
||||
return this->Foo() + ", " + this->Bar();
|
||||
return this->Foo() + ", " + this->Bar();
|
||||
};
|
||||
|
||||
protected:
|
||||
virtual std::string Foo() {
|
||||
return "Foo";
|
||||
return "Foo";
|
||||
};
|
||||
|
||||
virtual std::string Bar() = 0;
|
||||
|
|
@ -689,7 +701,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Go_director_enable">23.4.7.2 Enable director feature</a></H4>
|
||||
<H4><a name="Go_director_enable">25.4.7.2 Enable director feature</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -724,7 +736,7 @@ documentation on directors.
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Go_director_ctor_dtor">23.4.7.3 Constructor and destructor</a></H4>
|
||||
<H4><a name="Go_director_ctor_dtor">25.4.7.3 Constructor and destructor</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -777,7 +789,7 @@ embedding</a>.
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Go_director_overriding">23.4.7.4 Override virtual methods</a></H4>
|
||||
<H4><a name="Go_director_overriding">25.4.7.4 Override virtual methods</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -785,10 +797,12 @@ In order to override virtual methods on a C++ class with Go methods the
|
|||
<tt>NewDirectorClassName</tt> constructor functions receives a
|
||||
<tt>DirectorInterface</tt> argument. The methods in the <tt>
|
||||
DirectorInterface</tt> are a subset of the public and protected virtual methods
|
||||
of the C++ class. If the <tt>DirectorInterface</tt> contains a method with a
|
||||
of the C++ class.
|
||||
Virtual methods that have a final specifier are unsurprisingly excluded.
|
||||
If the <tt>DirectorInterface</tt> contains a method with a
|
||||
matching signature to a virtual method of the C++ class then the virtual C++
|
||||
method will be overwritten with the Go method. As Go doesn't support protected
|
||||
methods all overriden protected virtual C++ methods will be public in Go.
|
||||
methods all overridden protected virtual C++ methods will be public in Go.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -843,7 +857,7 @@ the Go methods.
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Go_director_base_methods">23.4.7.5 Call base methods</a></H4>
|
||||
<H4><a name="Go_director_base_methods">25.4.7.5 Call base methods</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -880,7 +894,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Go_director_subclass">23.4.7.6 Subclass via embedding</a></H4>
|
||||
<H4><a name="Go_director_subclass">25.4.7.6 Subclass via embedding</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -941,14 +955,14 @@ methods of the <tt>FooBarAbstract</tt> C++ class by means of embedding. The
|
|||
public <tt>FooBarGo</tt> interface type includes the <tt>FooBarAbstract</tt>
|
||||
interface and hence <tt>FooBarGo</tt> can be used as a drop in replacement for
|
||||
<tt>FooBarAbstract</tt> while the reverse isn't possible and would raise a
|
||||
compile time error. Furthemore the constructor and destructor functions <tt>
|
||||
compile time error. Furthermore the constructor and destructor functions <tt>
|
||||
NewFooBarGo</tt> and <tt>DeleteFooBarGo</tt> take care of all the director
|
||||
specifics and to the user the class appears as any other SWIG wrapped C++
|
||||
class.
|
||||
</p>
|
||||
|
||||
|
||||
<H4><a name="Go_director_finalizer">23.4.7.7 Memory management with runtime.SetFinalizer</a></H4>
|
||||
<H4><a name="Go_director_finalizer">25.4.7.7 Memory management with runtime.SetFinalizer</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1013,7 +1027,7 @@ before using <tt>runtime.SetFinalizer</tt> to know all of its gotchas.
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Go_director_foobargo_class">23.4.7.8 Complete FooBarGo example class</a></H4>
|
||||
<H4><a name="Go_director_foobargo_class">25.4.7.8 Complete FooBarGo example class</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1054,7 +1068,7 @@ type overwrittenMethodsOnFooBarAbstract struct {
|
|||
fb FooBarAbstract
|
||||
|
||||
// If additional constructor arguments have been given they are typically
|
||||
// stored here so that the overriden methods can use them.
|
||||
// stored here so that the overridden methods can use them.
|
||||
}
|
||||
|
||||
func (om *overwrittenMethodsOnFooBarAbstract) Foo() string {
|
||||
|
|
@ -1081,7 +1095,7 @@ func NewFooBarGo() FooBarGo {
|
|||
// The memory of the FooBarAbstract director object instance can be
|
||||
// automatically freed once the FooBarGo instance is garbage collected by
|
||||
// uncommenting the following line. Please make sure to understand the
|
||||
// runtime.SetFinalizer specific gotchas before doing this. Furthemore
|
||||
// runtime.SetFinalizer specific gotchas before doing this. Furthermore
|
||||
// DeleteFooBarGo should be deleted if a finalizer is in use or the fooBarGo
|
||||
// struct needs additional data to prevent double deletion.
|
||||
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)
|
||||
|
|
@ -1142,7 +1156,7 @@ SWIG/Examples/go/director/</a>.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Go_primitive_type_mappings">23.4.8 Default Go primitive type mappings</a></H3>
|
||||
<H3><a name="Go_primitive_type_mappings">25.4.8 Default Go primitive type mappings</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1249,7 +1263,7 @@ that typemap, or add new values, to control how C/C++ types are mapped
|
|||
into Go types.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_output_arguments">23.4.9 Output arguments</a></H3>
|
||||
<H3><a name="Go_output_arguments">25.4.9 Output arguments</a></H3>
|
||||
|
||||
|
||||
<p>Because of limitations in the way output arguments are processed in swig,
|
||||
|
|
@ -1289,7 +1303,7 @@ fraction := modulename.Modf(5.0, ptr)
|
|||
</pre>
|
||||
</div>
|
||||
<p>Since this is ugly, you may want to wrap the swig-generated API with
|
||||
some <a href="#Embedded_go_code">additional functions written in go</a> that
|
||||
some <a href="#Go_adding_additional_code">additional functions written in go</a> that
|
||||
hide the ugly details.</p>
|
||||
|
||||
<p>There are no <code>char *OUTPUT</code> typemaps. However you can
|
||||
|
|
@ -1302,7 +1316,7 @@ void f(char *output);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Go_adding_additional_code">23.4.10 Adding additional go code</a></H3>
|
||||
<H3><a name="Go_adding_additional_code">25.4.10 Adding additional go code</a></H3>
|
||||
|
||||
|
||||
<p>Often the APIs generated by swig are not very natural in go, especially if
|
||||
|
|
@ -1397,7 +1411,7 @@ func bar() {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Go_typemaps">23.4.11 Go typemaps</a></H3>
|
||||
<H3><a name="Go_typemaps">25.4.11 Go typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Guile">24 SWIG and Guile</a></H1>
|
||||
<H1><a name="Guile">26 SWIG and Guile</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -48,7 +48,7 @@
|
|||
<p>
|
||||
This section details guile-specific support in SWIG.
|
||||
|
||||
<H2><a name="Guile_nn1">24.1 Supported Guile Versions</a></H2>
|
||||
<H2><a name="Guile_nn1">26.1 Supported Guile Versions</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -62,7 +62,7 @@ improved performance. This is currently not tested with swig
|
|||
so your mileage may vary. To be safe set environment variable
|
||||
GUILE_AUTO_COMPILE to 0 when using swig generated guile code.
|
||||
|
||||
<H2><a name="Guile_nn2">24.2 Meaning of "Module"</a></H2>
|
||||
<H2><a name="Guile_nn2">26.2 Meaning of "Module"</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -70,7 +70,7 @@ There are three different concepts of "module" involved, defined
|
|||
separately for SWIG, Guile, and Libtool. To avoid horrible confusion,
|
||||
we explicitly prefix the context, e.g., "guile-module".
|
||||
|
||||
<H2><a name="Guile_nn3">24.3 Old GH Guile API</a></H2>
|
||||
<H2><a name="Guile_nn3">26.3 Old GH Guile API</a></H2>
|
||||
|
||||
|
||||
<p>Guile 1.8 and older could be interfaced using two different api's, the SCM
|
||||
|
|
@ -81,7 +81,7 @@ or the GH API. The GH interface to guile is deprecated. Read more about why in
|
|||
version of SWIG that can still generate guile GH wrapper code is 2.0.9. Please
|
||||
use that version if you really need the GH wrapper code.
|
||||
|
||||
<H2><a name="Guile_nn4">24.4 Linkage</a></H2>
|
||||
<H2><a name="Guile_nn4">26.4 Linkage</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -89,7 +89,7 @@ Guile support is complicated by a lack of user community cohesiveness,
|
|||
which manifests in multiple shared-library usage conventions. A set of
|
||||
policies implementing a usage convention is called a <b>linkage</b>.
|
||||
|
||||
<H3><a name="Guile_nn5">24.4.1 Simple Linkage</a></H3>
|
||||
<H3><a name="Guile_nn5">26.4.1 Simple Linkage</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -194,7 +194,7 @@ placed between the <code>define-module</code> form and the
|
|||
<code>SWIG_init</code> via a preprocessor define to avoid symbol
|
||||
clashes. For this case, however, passive linkage is available.
|
||||
|
||||
<H3><a name="Guile_nn6">24.4.2 Passive Linkage</a></H3>
|
||||
<H3><a name="Guile_nn6">26.4.2 Passive Linkage</a></H3>
|
||||
|
||||
|
||||
<p>Passive linkage is just like simple linkage, but it generates an
|
||||
|
|
@ -204,7 +204,7 @@ package name (see below).
|
|||
<p>You should use passive linkage rather than simple linkage when you
|
||||
are using multiple modules.
|
||||
|
||||
<H3><a name="Guile_nn7">24.4.3 Native Guile Module Linkage</a></H3>
|
||||
<H3><a name="Guile_nn7">26.4.3 Native Guile Module Linkage</a></H3>
|
||||
|
||||
|
||||
<p>SWIG can also generate wrapper code that does all the Guile module
|
||||
|
|
@ -245,7 +245,7 @@ Newer Guile versions have a shorthand procedure for this:
|
|||
</div>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Guile_nn8">24.4.4 Old Auto-Loading Guile Module Linkage</a></H3>
|
||||
<H3><a name="Guile_nn8">26.4.4 Old Auto-Loading Guile Module Linkage</a></H3>
|
||||
|
||||
|
||||
<p>Guile used to support an autoloading facility for object-code
|
||||
|
|
@ -271,7 +271,7 @@ option, SWIG generates an exported module initialization function with
|
|||
an appropriate name.
|
||||
|
||||
|
||||
<H3><a name="Guile_nn9">24.4.5 Hobbit4D Linkage</a></H3>
|
||||
<H3><a name="Guile_nn9">26.4.5 Hobbit4D Linkage</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -296,7 +296,7 @@ my/lib/libfoo.so.X.Y.Z and friends. This scheme is still very
|
|||
experimental; the (hobbit4d link) conventions are not well understood.
|
||||
</p>
|
||||
|
||||
<H2><a name="Guile_nn10">24.5 Underscore Folding</a></H2>
|
||||
<H2><a name="Guile_nn10">26.5 Underscore Folding</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -308,7 +308,7 @@ complained so far.
|
|||
<code>%rename</code> to specify the Guile name of the wrapped
|
||||
functions and variables (see CHANGES).
|
||||
|
||||
<H2><a name="Guile_nn11">24.6 Typemaps</a></H2>
|
||||
<H2><a name="Guile_nn11">26.6 Typemaps</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -400,7 +400,7 @@ constant will appear as a scheme variable. See
|
|||
<a href="Customization.html#Customization_features">Features and the %feature directive</a>
|
||||
for info on how to apply the %feature.</p>
|
||||
|
||||
<H2><a name="Guile_nn12">24.7 Representation of pointers as smobs</a></H2>
|
||||
<H2><a name="Guile_nn12">26.7 Representation of pointers as smobs</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -421,7 +421,7 @@ representing the expected pointer type. See also
|
|||
If the Scheme object passed was not a SWIG smob representing a compatible
|
||||
pointer, a <code>wrong-type-arg</code> exception is raised.
|
||||
|
||||
<H3><a name="Guile_nn14">24.7.1 Smobs</a></H3>
|
||||
<H3><a name="Guile_nn14">26.7.1 Smobs</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -440,7 +440,7 @@ structure describing this type. If a generated GOOPS module has been loaded, sm
|
|||
the corresponding GOOPS class.</p>
|
||||
|
||||
|
||||
<H3><a name="Guile_nn15">24.7.2 Garbage Collection</a></H3>
|
||||
<H3><a name="Guile_nn15">26.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,
|
||||
|
|
@ -454,14 +454,14 @@ is exactly like described in <a href="Customization.html#Customization_ownership
|
|||
Object ownership and %newobject</a> in the SWIG manual. All typemaps use an $owner var, and
|
||||
the guile module replaces $owner with 0 or 1 depending on feature:new.</p>
|
||||
|
||||
<H2><a name="Guile_nn16">24.8 Native Guile pointers</a></H2>
|
||||
<H2><a name="Guile_nn16">26.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">24.9 Exception Handling</a></H2>
|
||||
<H2><a name="Guile_nn17">26.9 Exception Handling</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -487,7 +487,7 @@ mapping:
|
|||
The default when not specified here is to use "swig-error".
|
||||
See Lib/exception.i for details.
|
||||
|
||||
<H2><a name="Guile_nn18">24.10 Procedure documentation</a></H2>
|
||||
<H2><a name="Guile_nn18">26.10 Procedure documentation</a></H2>
|
||||
|
||||
|
||||
<p>If invoked with the command-line option <code>-procdoc
|
||||
|
|
@ -522,7 +522,7 @@ like this:
|
|||
typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
|
||||
details.
|
||||
|
||||
<H2><a name="Guile_nn19">24.11 Procedures with setters</a></H2>
|
||||
<H2><a name="Guile_nn19">26.11 Procedures with setters</a></H2>
|
||||
|
||||
|
||||
<p>For global variables, SWIG creates a single wrapper procedure
|
||||
|
|
@ -550,7 +550,7 @@ struct members, the procedures <code>(<var>struct</var>-<var>member</var>-get
|
|||
pointer)</code> and <code>(<var>struct-member</var>-set pointer
|
||||
value)</code> are <em>not</em> generated.
|
||||
|
||||
<H2><a name="Guile_nn20">24.12 GOOPS Proxy Classes</a></H2>
|
||||
<H2><a name="Guile_nn20">26.12 GOOPS Proxy Classes</a></H2>
|
||||
|
||||
|
||||
<p>SWIG can also generate classes and generic functions for use with
|
||||
|
|
@ -696,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.
|
||||
</p>
|
||||
|
||||
<H3><a name="Guile_nn21">24.12.1 Naming Issues</a></H3>
|
||||
<H3><a name="Guile_nn21">26.12.1 Naming Issues</a></H3>
|
||||
|
||||
|
||||
<p>As you can see in the example above, there are potential naming conflicts. The default exported
|
||||
|
|
@ -733,7 +733,7 @@ guile-modules. For example,</p>
|
|||
(use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:)))
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Guile_nn22">24.12.2 Linking</a></H3>
|
||||
<H3><a name="Guile_nn22">26.12.2 Linking</a></H3>
|
||||
|
||||
|
||||
<p>The guile-modules generated above all need to be linked together. GOOPS support requires
|
||||
|
|
|
|||
|
|
@ -13,6 +13,11 @@
|
|||
<ul>
|
||||
<li><a href="#Introduction_nn2">What is SWIG?</a>
|
||||
<li><a href="#Introduction_nn3">Why use SWIG?</a>
|
||||
<li><a href="#Introduction_target_languages">Target languages</a>
|
||||
<ul>
|
||||
<li><a href="#Introduction_supported_status">Supported status</a>
|
||||
<li><a href="#Introduction_experimental_status">Experimental status</a>
|
||||
</ul>
|
||||
<li><a href="#Introduction_nn4">A SWIG example</a>
|
||||
<ul>
|
||||
<li><a href="#Introduction_nn5">SWIG interface file</a>
|
||||
|
|
@ -144,7 +149,79 @@ it provides a wide variety of customization features that let you change almost
|
|||
every aspect of the language bindings. This is the main reason why SWIG has such a large
|
||||
user manual ;-).
|
||||
|
||||
<H2><a name="Introduction_nn4">2.3 A SWIG example</a></H2>
|
||||
<H2><a name="Introduction_target_languages">2.3 Target languages</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG in essence is a tool to generate code for making C/C++ code available to various other programming languages.
|
||||
These higher level programming languages are the target languages for the SWIG code generator and C or C++ are the input languages.
|
||||
A single target language must be specified when SWIG is run.
|
||||
This results in generating code for C/C++ and the specified target language to interface with each other.
|
||||
SWIG can be invoked multiple times, but with a different target language specified on each invocation.
|
||||
This ability to interface C/C++ to many different target languages is one of SWIG's core strengths and features.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
SWIG is very broadly composed of two components.
|
||||
A core component creates a parse tree from the input ISO C/C++ and SWIG directives (extensions to the C/C++ standards).
|
||||
The parse tree is then passed to a second component, one of the target language modules for generating code specific to a higher level language.
|
||||
SWIG supports many different target languages.
|
||||
These target languages are given a status of either Supported or Experimental.
|
||||
This status is provided to indicate the level of maturity to expect when using a particular target language as not all target languages are fully developed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The second part of the SWIG documentation contains a chapter for each target level language.
|
||||
Each chapter will state the status (Supported or Experimental) for that language.
|
||||
</p>
|
||||
|
||||
<H3><a name="Introduction_supported_status">2.3.1 Supported status</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
A target language is given the 'Supported' status when
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>It is in a mature, well functioning state.</li>
|
||||
<li>It has its own comprehensive chapter in the documentation.</li>
|
||||
<li>It passes all of the main SWIG test-suite and has a range of working examples.</li>
|
||||
<li>It supports the vast majority of SWIG features.</li>
|
||||
<li>It provides strong backwards compatibility between releases.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The above is a short summary and further details are outlined in the <a href="Extending.html#Extending_supported_status">Supported status</a> section in the Extending chapter.
|
||||
The good news is that all the well-known and most popular languages have this status.
|
||||
</p>
|
||||
|
||||
<H3><a name="Introduction_experimental_status">2.3.2 Experimental status</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
A target language is given the 'Experimental' status when
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>It is of sub-standard quality, failing to meet the above 'Supported' status.</li>
|
||||
<li>It is somewhere between the mid to mature stage of development.</li>
|
||||
<li>It does not guarantee any backwards compatibility between releases.</li>
|
||||
<li>It is in need of help to finish development.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Anyone using an experimental target language is strongly urged to assist with development of the target language module if they wish to use it.
|
||||
</p>
|
||||
<p>
|
||||
SWIG displays a warning when an experimental target language is used in order to set expectations and emphasize the experimental status of the target language.
|
||||
The usual <a href="Warnings.html#Warnings_suppression">warning suppression</a> techniques can be used if required.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The above is a short summary and further details are outlined in the <a href="Extending.html#Extending_experimental_status">Experimental status</a> section in the Extending chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Introduction_nn4">2.4 A SWIG example</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -155,7 +232,7 @@ following C code:
|
|||
<div class="code"><pre>
|
||||
/* File : example.c */
|
||||
|
||||
double My_variable = 3.0;
|
||||
double My_variable = 3.0;
|
||||
|
||||
/* Compute factorial of n */
|
||||
int fact(int n) {
|
||||
|
|
@ -177,7 +254,7 @@ variable <tt>My_variable</tt> from Tcl. You start by making a SWIG
|
|||
interface file as shown below (by convention, these files carry a .i
|
||||
suffix) :
|
||||
|
||||
<H3><a name="Introduction_nn5">2.3.1 SWIG interface file</a></H3>
|
||||
<H3><a name="Introduction_nn5">2.4.1 SWIG interface file</a></H3>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -196,13 +273,13 @@ extern int my_mod(int n, int m);
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
The interface file contains ANSI C function prototypes and variable
|
||||
The interface file contains ISO C function prototypes and variable
|
||||
declarations. The <tt>%module</tt> directive defines the name of the
|
||||
module that will be created by SWIG. The <tt>%{ %}</tt> block
|
||||
provides a location for inserting additional code, such as C header
|
||||
files or additional C declarations, into the generated C wrapper code.
|
||||
|
||||
<H3><a name="Introduction_nn6">2.3.2 The swig command</a></H3>
|
||||
<H3><a name="Introduction_nn6">2.4.2 The swig command</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -235,7 +312,7 @@ and variables declared in the SWIG interface. A look at the file
|
|||
<tt>example_wrap.c</tt> reveals a hideous mess. However, you
|
||||
almost never need to worry about it.
|
||||
|
||||
<H3><a name="Introduction_nn7">2.3.3 Building a Perl5 module</a></H3>
|
||||
<H3><a name="Introduction_nn7">2.4.3 Building a Perl5 module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -261,7 +338,7 @@ unix >
|
|||
</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>
|
||||
|
|
@ -285,7 +362,7 @@ Type "copyright", "credits" or "license" for more information.
|
|||
7.5
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Introduction_nn9">2.3.5 Shortcuts</a></H3>
|
||||
<H3><a name="Introduction_nn9">2.4.5 Shortcuts</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -311,7 +388,7 @@ print $example::My_variable + 4.5, "\n";
|
|||
7.5
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Introduction_nn10">2.4 Supported C/C++ language features</a></H2>
|
||||
<H2><a name="Introduction_nn10">2.5 Supported C/C++ language features</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -323,7 +400,7 @@ major features include:
|
|||
|
||||
<ul>
|
||||
<li>Full C99 preprocessing.
|
||||
<li>All ANSI C and C++ datatypes.
|
||||
<li>All ISO C and C++ datatypes.
|
||||
<li>Functions, variables, and constants.
|
||||
<li>Classes.
|
||||
<li>Single and multiple inheritance.
|
||||
|
|
@ -336,7 +413,10 @@ major features include:
|
|||
</ul>
|
||||
|
||||
<p>
|
||||
Most of C++11 is also supported. Details are in the <a href="CPlusPlus11.html#CPlusPlus11">C++11</a> section.
|
||||
Most of C++11 is also supported. Details are in the <a href="CPlusPlus11.html#CPlusPlus11">C++11</a> chapter.
|
||||
C++14 support is covered in the <a href="CPlusPlus14.html#CPlusPlus14">C++14</a> chapter.
|
||||
C++17 support is covered in the <a href="CPlusPlus17.html#CPlusPlus17">C++17</a> chapter.
|
||||
C++20 support is covered in the <a href="CPlusPlus20.html#CPlusPlus20">C++20</a> chapter.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -350,7 +430,7 @@ wrapping simple C++ code. In fact, SWIG is able to handle C++ code that
|
|||
stresses the very limits of many C++ compilers.
|
||||
|
||||
|
||||
<H2><a name="Introduction_nn11">2.5 Non-intrusive interface building</a></H2>
|
||||
<H2><a name="Introduction_nn11">2.6 Non-intrusive interface building</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -362,7 +442,7 @@ interface and reuse the code in other applications. It is also
|
|||
possible to support different types of interfaces depending on the application.
|
||||
</p>
|
||||
|
||||
<H2><a name="Introduction_build_system">2.6 Incorporating SWIG into a build system</a></H2>
|
||||
<H2><a name="Introduction_build_system">2.7 Incorporating SWIG into a build system</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -385,13 +465,13 @@ for further information on this and other Autoconf macros.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
There is growing support for SWIG in some build tools, for example <a href="http://cmake.org">CMake</a>
|
||||
There is growing support for SWIG in some build tools, for example <a href="https://cmake.org">CMake</a>
|
||||
is a cross-platform, open-source build manager with built in support for SWIG. CMake can detect the SWIG executable
|
||||
and many of the target language libraries for linking against.
|
||||
CMake knows how to build shared libraries and loadable modules on many different operating systems.
|
||||
This allows easy cross platform SWIG development. It can also generate the custom commands necessary for
|
||||
driving SWIG from IDEs and makefiles. All of this can be done from a single cross platform input file.
|
||||
The following example is a CMake input file for creating a python wrapper for the SWIG interface file, example.i:
|
||||
The following example is a CMake input file for creating a Python wrapper for the SWIG interface file, example.i:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -420,7 +500,7 @@ which will invoke SWIG and compile the generated C++ files into _example.so (UNI
|
|||
For other target languages on Windows a dll, instead of a .pyd file, is usually generated.
|
||||
</p>
|
||||
|
||||
<H2><a name="Introduction_nn12">2.7 Hands off code generation</a></H2>
|
||||
<H2><a name="Introduction_nn12">2.8 Hands off code generation</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -433,7 +513,7 @@ it allows others to forget about the low-level implementation
|
|||
details.
|
||||
</p>
|
||||
|
||||
<H2><a name="Introduction_nn13">2.8 SWIG and freedom</a></H2>
|
||||
<H2><a name="Introduction_nn13">2.9 SWIG and freedom</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -452,7 +532,7 @@ to work with complicated and unusual C/C++ applications.
|
|||
Ironically, the freedom that SWIG provides is countered by an
|
||||
extremely conservative approach to code generation. At its core, SWIG
|
||||
tries to distill even the most advanced C++ code down to a small
|
||||
well-defined set of interface building techniques based on ANSI C
|
||||
well-defined set of interface building techniques based on ISO C
|
||||
programming. Because of this, you will find that SWIG interfaces can
|
||||
be easily compiled by virtually every C/C++ compiler and that they can
|
||||
be used on any platform. Again, this is an important part of staying out
|
||||
|
|
|
|||
1094
Doc/Manual/Java.html
1094
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">
|
||||
<html>
|
||||
<head>
|
||||
<link rel="stylesheet" type="text/css" href="./style.css">
|
||||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
<title></title>
|
||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<H1><a name="Javascript">26 SWIG and Javascript</a></H1>
|
||||
<H1><a name="Javascript">28 SWIG and Javascript</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -52,21 +52,21 @@
|
|||
|
||||
<p>This chapter describes SWIG's support of Javascript. It does not cover SWIG basics, but only information that is specific to this module.</p>
|
||||
|
||||
<H2><a name="Javascript_overview">26.1 Overview</a></H2>
|
||||
<H2><a name="Javascript_overview">28.1 Overview</a></H2>
|
||||
|
||||
|
||||
<p>Javascript is a prototype-based scripting language that is dynamic, weakly typed and has first-class functions. Its arguably the most popular language for web development.
|
||||
Javascript has gone beyond being a browser-based scripting language and with <a href="http://nodejs.org">node.js</a>, it is also used as a backend development language.</p>
|
||||
Javascript has gone beyond being a browser-based scripting language and with <a href="https://nodejs.org">node.js</a>, it is also used as a backend development language.</p>
|
||||
<p>Native Javascript extensions can be used for applications that embed a web-browser view or that embed a Javascript engine (such as <em>node.js</em>). Extending a general purpose web-browser is not possible as this would be a severe security issue.</p>
|
||||
<p>SWIG Javascript currently supports <strong>JavascriptCore</strong>, the Javascript engine used by <code>Safari/Webkit</code>, and <a href="https://developers.google.com/v8"><strong>v8</strong></a>, which is used by <code>Chromium</code> and <code>node.js</code>.</p>
|
||||
<p><a href="http://www.webkit.org/">WebKit</a> is a modern browser implementation available as open-source which can be embedded into an application.
|
||||
<p>SWIG Javascript currently supports <strong>JavascriptCore</strong>, the Javascript engine used by <code>Safari/Webkit</code>, and <a href="https://v8.dev/"><strong>v8</strong></a>, which is used by <code>Chromium</code> and <code>node.js</code>.</p>
|
||||
<p><a href="https://webkit.org/">WebKit</a> is a modern browser implementation available as open-source which can be embedded into an application.
|
||||
With <a href="https://github.com/rogerwang/node-webkit">node-webkit</a> there is a platform which uses Google's <code>Chromium</code> as Web-Browser widget and <code>node.js</code> for javascript extensions.
|
||||
</p>
|
||||
|
||||
<H2><a name="Javascript_preliminaries">26.2 Preliminaries</a></H2>
|
||||
<H2><a name="Javascript_preliminaries">28.2 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Javascript_running_swig">26.2.1 Running SWIG</a></H3>
|
||||
<H3><a name="Javascript_running_swig">28.2.1 Running SWIG</a></H3>
|
||||
|
||||
|
||||
<p>Suppose that you defined a SWIG module such as the following:</p>
|
||||
|
|
@ -101,7 +101,7 @@ that era had a component > 99. For example:</p>
|
|||
<pre>
|
||||
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
|
||||
</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">
|
||||
<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++.
|
||||
</p>
|
||||
|
||||
<H3><a name="Javascript_running_tests_examples">26.2.2 Running Tests and Examples</a></H3>
|
||||
<H3><a name="Javascript_running_tests_examples">28.2.2 Running Tests and Examples</a></H3>
|
||||
|
||||
|
||||
<p>The configuration for tests and examples currently supports Linux and Mac only and not MinGW (Windows) yet.</p>
|
||||
|
|
@ -153,7 +153,7 @@ $ make check-javascript-test-suite ENGINE=jsc</pre>
|
|||
$ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Javascript_known_issues">26.2.3 Known Issues</a></H3>
|
||||
<H3><a name="Javascript_known_issues">28.2.3 Known Issues</a></H3>
|
||||
|
||||
|
||||
<p>At the moment, the Javascript generators pass all tests syntactically, i.e., the generated source code compiles. However, there are still remaining runtime issues.</p>
|
||||
|
|
@ -161,21 +161,20 @@ $ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
|
|||
<ul>
|
||||
<li><p>Default optional arguments do not work for all targeted interpreters</p></li>
|
||||
<li><p>Multiple output arguments do not work for JSC</p></li>
|
||||
<li><p>C89 incompatibily: the JSC generator might still generate C89 violating code</p></li>
|
||||
<li><p>C89 incompatibility: the JSC generator might still generate C89 violating code</p></li>
|
||||
<li><p><code>long long</code> is not supported</p></li>
|
||||
<li><p><code>%native</code> is not supported</p></li>
|
||||
<li><p>Javascript callbacks are not supported</p></li>
|
||||
<li><p><code>instanceOf</code> does not work under JSC</p></li>
|
||||
</ul>
|
||||
|
||||
<p>The primary development environment has been Linux (Ubuntu 12.04). Windows and 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">28.3 Integration</a></H2>
|
||||
|
||||
|
||||
<p>This chapter gives a short introduction how to use a native Javascript extension: as a <code>node.js</code> module, and as an extension for an embedded Webkit.</p>
|
||||
|
||||
<H3><a name="Javascript_node_extensions">26.3.1 Creating node.js Extensions</a></H3>
|
||||
<H3><a name="Javascript_node_extensions">28.3.1 Creating node.js Extensions</a></H3>
|
||||
|
||||
|
||||
<p>To install <code>node.js</code> you can download an installer from their <a href="https://launchpad.net/~chris-lea/+archive/node.js">web-site</a> for Mac OS X and Windows. For Linux you can either build the source yourself and run <code>sudo checkinstall</code> or keep to the (probably stone-age) packaged version. For Ubuntu there is a <a href="https://launchpad.net/~chris-lea/+archive/ubuntu/node.js/">PPA</a> available.</p>
|
||||
|
|
@ -221,7 +220,7 @@ require("./build/Release/example")</pre>
|
|||
</div>
|
||||
<p>A more detailed explanation is given in the <a href="#Javascript_examples">Examples</a> section.</p>
|
||||
|
||||
<H4><a name="Javascript_troubleshooting">26.3.1.1 Troubleshooting</a></H4>
|
||||
<H4><a name="Javascript_troubleshooting">28.3.1.1 Troubleshooting</a></H4>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -233,12 +232,12 @@ require("./build/Release/example")</pre>
|
|||
$ sudo apt-get remove gyp</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Javascript_embedded_webkit">26.3.2 Embedded Webkit</a></H3>
|
||||
<H3><a name="Javascript_embedded_webkit">28.3.2 Embedded Webkit</a></H3>
|
||||
|
||||
|
||||
<p>Webkit is pre-installed on Mac OS X and available as a library for GTK.</p>
|
||||
|
||||
<H4><a name="Javascript_osx">26.3.2.1 Mac OS X</a></H4>
|
||||
<H4><a name="Javascript_osx">28.3.2.1 Mac OS X</a></H4>
|
||||
|
||||
|
||||
<p>There is general information about programming with WebKit on <a href="https://developer.apple.com/library/mac/documentation/cocoa/conceptual/DisplayWebContent/DisplayWebContent.html">Apple Developer Documentation</a>. Details about <code>Cocoa</code> programming are not covered here.</p>
|
||||
|
|
@ -286,10 +285,10 @@ extern bool example_initialize(JSGlobalContextRef context, JSObjectRef* exports)
|
|||
@end</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Javascript_gtk">26.3.2.2 GTK</a></H4>
|
||||
<H4><a name="Javascript_gtk">28.3.2.2 GTK</a></H4>
|
||||
|
||||
|
||||
<p>There is general information about programming GTK at <a href="https://developer.gnome.org/gtk2/">GTK documentation</a> and in the <a href="https://developer.gnome.org/gtk-tutorial">GTK tutorial</a>, and for Webkit there is a <a href="http://webkitgtk.org/reference/webkitgtk/stable/index.html">Webkit GTK+ API Reference</a>.</p>
|
||||
<p>There is general information about programming GTK at <a href="https://developer.gnome.org/gtk2/">GTK documentation</a> and in the <a href="https://developer.gnome.org/gtk-tutorial/">GTK tutorial</a>, and for Webkit there is a <a href="http://webkitgtk.org/reference/webkitgtk/stable/index.html">Webkit GTK+ API Reference</a>.</p>
|
||||
<p>An integration of a native extension 'example' would look like this:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
|
|
@ -331,7 +330,7 @@ int main(int argc, char* argv[])
|
|||
}</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Javascript_applications_webkit">26.3.3 Creating Applications with node-webkit</a></H3>
|
||||
<H3><a name="Javascript_applications_webkit">28.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>
|
||||
|
|
@ -422,12 +421,12 @@ open new windows, and many more things.
|
|||
};</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Javascript_examples">26.4 Examples</a></H2>
|
||||
<H2><a name="Javascript_examples">28.4 Examples</a></H2>
|
||||
|
||||
|
||||
<p>Some basic examples are shown here in more detail.</p>
|
||||
|
||||
<H3><a name="Javascript_simple_example">26.4.1 Simple</a></H3>
|
||||
<H3><a name="Javascript_simple_example">28.4.1 Simple</a></H3>
|
||||
|
||||
|
||||
<p>The common example <code>simple</code> looks like this:</p>
|
||||
|
|
@ -477,7 +476,7 @@ example.Foo = 3.1415926;</pre>
|
|||
|
||||
<p><b>Note</b>: ECMAScript 5, the currently implemented Javascript standard, does not have modules. <code>node.js</code> and other implementations provide this mechanism defined by the <a href="http://wiki.commonjs.org/wiki/CommonJS">CommonJS</a> group. For browsers this is provided by <a href="http://browserify.org">Browserify</a>, for instance.</p>
|
||||
|
||||
<H3><a name="Javascript_class_example">26.4.2 Class</a></H3>
|
||||
<H3><a name="Javascript_class_example">28.4.2 Class</a></H3>
|
||||
|
||||
|
||||
<p>The common example <code>class</code> defines three classes, <code>Shape</code>, <code>Circle</code>, and <code>Square</code>:</p>
|
||||
|
|
@ -604,15 +603,15 @@ at ReadStream.EventEmitter.emit (events.js:98:17)
|
|||
at emitKey (readline.js:1095:12)</pre>
|
||||
</div>
|
||||
<p>
|
||||
<b>Note</b>: In ECMAScript 5 there is no concept for classes. Instead each function can be used as a constructor function which is executed by the 'new' operator. Furthermore, during construction the key property <code>prototype</code> of the constructor function is used to attach a prototype instance to the created object. A prototype is essentially an object itself that is the first-class delegate of a class used whenever the access to a property of an object fails. The very same prototype instance is shared among all instances of one type. Prototypal inheritance is explained in more detail on in <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain">Inheritance and the prototype chain</a>, for instance.
|
||||
<b>Note</b>: In ECMAScript 5 there is no concept for classes. Instead each function can be used as a constructor function which is executed by the 'new' operator. Furthermore, during construction the key property <code>prototype</code> of the constructor function is used to attach a prototype instance to the created object. A prototype is essentially an object itself that is the first-class delegate of a class used whenever the access to a property of an object fails. The very same prototype instance is shared among all instances of one type. Prototypal inheritance is explained in more detail on in <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain">Inheritance and the prototype chain</a>, for instance.
|
||||
</p>
|
||||
|
||||
<H2><a name="Javascript_implementation">26.5 Implementation</a></H2>
|
||||
<H2><a name="Javascript_implementation">28.5 Implementation</a></H2>
|
||||
|
||||
|
||||
<p>The Javascript Module implementation has taken a very different approach compared to other language modules in order to support different Javascript interpreters.</p>
|
||||
|
||||
<H3><a name="Javascript_source_code">26.5.1 Source Code</a></H3>
|
||||
<H3><a name="Javascript_source_code">28.5.1 Source Code</a></H3>
|
||||
|
||||
|
||||
<p>The Javascript module is implemented in <code>Source/Modules/javascript.cxx</code>. It dispatches the code generation to a <code>JSEmitter</code> instance, <code>V8Emitter</code> or <code>JSCEmitter</code>. Additionally there are some helpers: <code>Template</code>, for templated code generation, and <code>JSEmitterState</code>, which is used to manage state information during AST traversal. This rough map shall make it easier to find a way through this huge source file:</p>
|
||||
|
|
@ -713,7 +712,7 @@ Template::Template(const String *code_) { ... }
|
|||
...</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Javascript_code_templates">26.5.2 Code Templates</a></H3>
|
||||
<H3><a name="Javascript_code_templates">28.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>
|
||||
|
|
@ -752,7 +751,7 @@ t_register.replace("$jsparent", state.clazz(NAME_MANGLED))
|
|||
</div>
|
||||
<p><code>Template</code> creates a copy of that string and <code>Template::replace</code> uses Swig's <code>Replaceall</code> to replace variables in the template. <code>Template::trim</code> can be used to eliminate leading and trailing whitespaces. <code>Template::print</code> is used to write the final template string to a Swig <code>DOH</code> (based on <code>Printv</code>). All methods allow chaining.</p>
|
||||
|
||||
<H3><a name="Javascript_emitter">26.5.3 Emitter</a></H3>
|
||||
<H3><a name="Javascript_emitter">28.5.3 Emitter</a></H3>
|
||||
|
||||
|
||||
<p>The Javascript module delegates code generation to a <code>JSEmitter</code> instance. The following extract shows the essential interface:</p>
|
||||
|
|
@ -871,7 +870,7 @@ int JAVASCRIPT::classHandler(Node *n) {
|
|||
</div>
|
||||
<p>In <code>enterClass</code> the emitter stores state information that is necessary when processing class members. In <code>exitClass</code> the wrapper code for the whole class is generated.</p>
|
||||
|
||||
<H3><a name="Javascript_emitter_states">26.5.4 Emitter states</a></H3>
|
||||
<H3><a name="Javascript_emitter_states">28.5.4 Emitter states</a></H3>
|
||||
|
||||
|
||||
<p>For storing information during the AST traversal the emitter provides a <code>JSEmitterState</code> with different slots to store data representing the scopes global, class, function, and variable.</p>
|
||||
|
|
@ -915,7 +914,7 @@ state.clazz(NAME, Getattr(n, "sym:name"));</pre>
|
|||
<p>State information can be retrieved using <code>state.clazz(NAME)</code> or with <code>Getattr</code> on <code>state.clazz()</code> which actually returns a <code>Hash</code> instance.</p>
|
||||
|
||||
|
||||
<H3><a name="Javascript_jsc_exceptions">26.5.5 Handling Exceptions in JavascriptCore</a></H3>
|
||||
<H3><a name="Javascript_jsc_exceptions">28.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>
|
||||
|
|
|
|||
|
|
@ -7,31 +7,38 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Library">9 SWIG library</a></H1>
|
||||
<H1><a name="Library">12 SWIG library</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#Library_nn2">The %include directive and library search path</a>
|
||||
<li><a href="#Library_nn3">C Arrays and Pointers</a>
|
||||
<li><a href="#Library_nn3">C arrays and pointers</a>
|
||||
<ul>
|
||||
<li><a href="#Library_nn4">cpointer.i</a>
|
||||
<li><a href="#Library_carrays">carrays.i</a>
|
||||
<li><a href="#Library_nn6">cmalloc.i</a>
|
||||
<li><a href="#Library_nn7">cdata.i</a>
|
||||
</ul>
|
||||
<li><a href="#Library_nn8">C String Handling</a>
|
||||
<li><a href="#Library_nn8">C string handling</a>
|
||||
<ul>
|
||||
<li><a href="#Library_nn9">Default string handling</a>
|
||||
<li><a href="#Library_nn10">Passing binary data</a>
|
||||
<li><a href="#Library_nn11">Using %newobject to release memory</a>
|
||||
<li><a href="#Library_nn12">cstring.i</a>
|
||||
</ul>
|
||||
<li><a href="#Library_stl_cpp_library">STL/C++ Library</a>
|
||||
<li><a href="#Library_stl_cpp_library">STL/C++ library</a>
|
||||
<ul>
|
||||
<li><a href="#Library_std_string">std::string</a>
|
||||
<li><a href="#Library_std_vector">std::vector</a>
|
||||
<li><a href="#Library_stl_exceptions">STL exceptions</a>
|
||||
<li><a href="#Library_std_shared_ptr">shared_ptr smart pointer</a>
|
||||
<ul>
|
||||
<li><a href="#Library_shared_ptr_basics">shared_ptr basics</a>
|
||||
<li><a href="#Library_shared_ptr_inheritance">shared_ptr and inheritance</a>
|
||||
<li><a href="#Library_shared_ptr_overloading">shared_ptr and method overloading</a>
|
||||
<li><a href="#Library_shared_ptr_templates">shared_ptr and templates</a>
|
||||
<li><a href="#Library_shared_ptr_directors">shared_ptr and directors</a>
|
||||
</ul>
|
||||
<li><a href="#Library_std_auto_ptr">auto_ptr smart pointer</a>
|
||||
</ul>
|
||||
<li><a href="#Library_nn16">Utility Libraries</a>
|
||||
|
|
@ -60,7 +67,7 @@ Alternative libraries provide similar functionality. Please read this chapter
|
|||
carefully if you used the old libraries.
|
||||
</p>
|
||||
|
||||
<H2><a name="Library_nn2">9.1 The %include directive and library search path</a></H2>
|
||||
<H2><a name="Library_nn2">12.1 The %include directive and library search path</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -92,7 +99,7 @@ Set the environment variable to hold an alternative library directory.
|
|||
The directories that are searched are displayed when using <tt>-verbose</tt> commandline option.
|
||||
</p>
|
||||
|
||||
<H2><a name="Library_nn3">9.2 C Arrays and Pointers</a></H2>
|
||||
<H2><a name="Library_nn3">12.2 C arrays and pointers</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -104,7 +111,7 @@ pointers as class-like objects. Since these functions provide direct access to
|
|||
memory, their use is potentially unsafe and you should exercise caution.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_nn4">9.2.1 cpointer.i</a></H3>
|
||||
<H3><a name="Library_nn4">12.2.1 cpointer.i</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -320,7 +327,7 @@ In this example, the function <tt>int_to_uint()</tt> would be used to cast type
|
|||
<b>Note:</b> When working with simple pointers, typemaps can often be used to provide more seamless operation.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_carrays">9.2.2 carrays.i</a></H3>
|
||||
<H3><a name="Library_carrays">12.2.2 carrays.i</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -411,13 +418,13 @@ void print_array(double x[10]);
|
|||
Now, in a scripting language, you might write this:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
a = new_doubleArray(10) # Create an array
|
||||
a = new_doubleArray(10) # Create an array
|
||||
for i in range(0, 10):
|
||||
doubleArray_setitem(a, i, 2*i) # Set a value
|
||||
print_array(a) # Pass to C
|
||||
delete_doubleArray(a) # Destroy array
|
||||
doubleArray_setitem(a, i, 2 * i) # Set a value
|
||||
print_array(a) # Pass to C
|
||||
delete_doubleArray(a) # Destroy array
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -475,12 +482,12 @@ void print_array(double x[10]);
|
|||
Allows you to do this:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
import example
|
||||
c = example.doubleArray(10) # Create double[10]
|
||||
for i in range(0, 10):
|
||||
c[i] = 2*i # Assign values
|
||||
c[i] = 2 * i # Assign values
|
||||
example.print_array(c) # Pass to C
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -496,9 +503,10 @@ you should consider using a special array object rather than a bare pointer.
|
|||
<p>
|
||||
<b>Note:</b> <tt>%array_functions()</tt> and <tt>%array_class()</tt> should not be
|
||||
used with types of <tt>char</tt> or <tt>char *</tt>.
|
||||
SWIG's default handling of these types is to handle them as character strings and the two macros do not do enough to change this.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_nn6">9.2.3 cmalloc.i</a></H3>
|
||||
<H3><a name="Library_nn6">12.2.3 cmalloc.i</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -659,7 +667,7 @@ Now, in a script:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Library_nn7">9.2.4 cdata.i</a></H3>
|
||||
<H3><a name="Library_nn7">12.2.4 cdata.i</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -761,7 +769,7 @@ char *cdata_<em>name</em>(type* ptr, int nitems)
|
|||
Clearly they are unsafe.
|
||||
</p>
|
||||
|
||||
<H2><a name="Library_nn8">9.3 C String Handling</a></H2>
|
||||
<H2><a name="Library_nn8">12.3 C string handling</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -781,7 +789,7 @@ morality. The modules in this section provide basic functionality
|
|||
for manipulating raw C strings.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_nn9">9.3.1 Default string handling</a></H3>
|
||||
<H3><a name="Library_nn9">12.3.1 Default string handling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -801,7 +809,7 @@ target language. In other words, if you were using a language like Tcl,
|
|||
and you wrote this,
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
% foo Hello
|
||||
</pre>
|
||||
|
|
@ -822,7 +830,7 @@ interpreter and lead to a crash). Furthermore, the default behavior does
|
|||
not work well with binary data. Instead, strings are assumed to be NULL-terminated.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_nn10">9.3.2 Passing binary data</a></H3>
|
||||
<H3><a name="Library_nn10">12.3.2 Passing binary data</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -852,7 +860,7 @@ size_t parity(char *str, size_t len, size_t initial);
|
|||
Now, in the target language, you can use binary string data like this:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
>>> s = "H\x00\x15eg\x09\x20"
|
||||
>>> parity(s, 0)
|
||||
|
|
@ -864,7 +872,7 @@ In the wrapper function, the passed string will be expanded to a pointer and len
|
|||
The <tt>(char *STRING, int LENGTH)</tt> multi-argument typemap is also available in addition to <tt>(char *STRING, size_t LENGTH)</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_nn11">9.3.3 Using %newobject to release memory</a></H3>
|
||||
<H3><a name="Library_nn11">12.3.3 Using %newobject to release memory</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -905,7 +913,7 @@ however, you may need to provide your own "newfree" typemap for other types.
|
|||
See <a href="Customization.html#Customization_ownership">Object ownership and %newobject</a> for more details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_nn12">9.3.4 cstring.i</a></H3>
|
||||
<H3><a name="Library_nn12">12.3.4 cstring.i</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1357,7 +1365,7 @@ to accomplish this in SWIG. This library provides support for a few common tech
|
|||
</li>
|
||||
|
||||
<li>If used in C++, this library uses <tt>new</tt> and <tt>delete []</tt> for memory
|
||||
allocation. If using ANSI C, the library uses <tt>malloc()</tt> and <tt>free()</tt>.
|
||||
allocation. If using C, the library uses <tt>malloc()</tt> and <tt>free()</tt>.
|
||||
</li>
|
||||
|
||||
<li>Rather than manipulating <tt>char *</tt> directly, you might consider using a special string
|
||||
|
|
@ -1365,7 +1373,7 @@ structure or class instead.
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H2><a name="Library_stl_cpp_library">9.4 STL/C++ Library</a></H2>
|
||||
<H2><a name="Library_stl_cpp_library">12.4 STL/C++ library</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1385,16 +1393,24 @@ The following table shows which C++ classes are supported and the equivalent SWI
|
|||
<td><b>SWIG Interface library file</b></td>
|
||||
</tr>
|
||||
|
||||
<tr> <td>std::array (C++11)</td> <td>array</td> <td>std_array.i</td> </tr>
|
||||
<tr> <td>std::auto_ptr</td> <td>memory</td> <td>std_auto_ptr.i</td> </tr>
|
||||
<tr> <td>std::complex</td> <td>complex</td> <td>std_complex.i</td> </tr>
|
||||
<tr> <td>std::deque</td> <td>deque</td> <td>std_deque.i</td> </tr>
|
||||
<tr> <td>std::list</td> <td>list</td> <td>std_list.i</td> </tr>
|
||||
<tr> <td>std::map</td> <td>map</td> <td>std_map.i</td> </tr>
|
||||
<tr> <td>std::multimap (C++11)</td> <td>multimap</td> <td>std_multimap.i</td> </tr>
|
||||
<tr> <td>std::multiset (C++11)</td> <td>multiset</td> <td>std_multiset.i</td> </tr>
|
||||
<tr> <td>std::pair</td> <td>utility</td> <td>std_pair.i</td> </tr>
|
||||
<tr> <td>std::set</td> <td>set</td> <td>std_set.i</td> </tr>
|
||||
<tr> <td>std::string</td> <td>string</td> <td>std_string.i</td> </tr>
|
||||
<tr> <td>std::unordered_map (C++11)</td> <td>unordered_map</td> <td>std_unordered_map.i</td> </tr>
|
||||
<tr> <td>std::unordered_multimap (C++11)</td> <td>unordered_multimap</td> <td>std_unordered_multimap.i</td> </tr>
|
||||
<tr> <td>std::unordered_multiset (C++11)</td> <td>unordered_multiset</td> <td>std_unordered_multiset.i</td> </tr>
|
||||
<tr> <td>std::unordered_set (C++11)</td> <td>unordered_set</td> <td>std_unordered_set.i</td> </tr>
|
||||
<tr> <td>std::vector</td> <td>vector</td> <td>std_vector.i</td> </tr>
|
||||
<tr> <td>std::array</td> <td>array (C++11)</td> <td>std_array.i</td> </tr>
|
||||
<tr> <td>std::shared_ptr</td> <td>shared_ptr (C++11)</td> <td>std_shared_ptr.i</td> </tr>
|
||||
<tr> <td>std::wstring</td> <td>wstring</td> <td>std_wstring.i</td> </tr>
|
||||
<tr> <td>std::shared_ptr (C++11)</td> <td>shared_ptr</td> <td>std_shared_ptr.i</td> </tr>
|
||||
|
||||
</table>
|
||||
|
||||
|
|
@ -1404,7 +1420,7 @@ Please look for the library files in the appropriate language library directory.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Library_std_string">9.4.1 std::string</a></H3>
|
||||
<H3><a name="Library_std_string">12.4.1 std::string</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1460,7 +1476,7 @@ In the target language:
|
|||
<div class="targetlang">
|
||||
<pre>
|
||||
x = my_struct();
|
||||
x.foo="Hello World"; # assign with string
|
||||
x.foo = "Hello World"; # assign with string
|
||||
print x.foo; # print as string
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1488,7 +1504,7 @@ void foo(string s, const String &t); // std_string typemaps still applie
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Library_std_vector">9.4.2 std::vector</a></H3>
|
||||
<H3><a name="Library_std_vector">12.4.2 std::vector</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1565,8 +1581,8 @@ std::vector<double> half(const std::vector<double>& v) {
|
|||
}
|
||||
|
||||
void halve_in_place(std::vector<double>& v) {
|
||||
std::transform(v.begin(), v.end(), v.begin(),
|
||||
std::bind2nd(std::divides<double>(), 2.0));
|
||||
for (std::vector<double>::iterator it = v.begin(); it != v.end(); ++it)
|
||||
*it /= 2.0;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1667,7 +1683,7 @@ if you want to make their head explode.
|
|||
details and the public API exposed to the interpreter vary.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_stl_exceptions">9.4.3 STL exceptions</a></H3>
|
||||
<H3><a name="Library_stl_exceptions">12.4.3 STL exceptions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1717,7 +1733,10 @@ The <tt>%exception</tt> directive can be used by placing the following code befo
|
|||
Any thrown STL exceptions will then be gracefully handled instead of causing a crash.
|
||||
</p>
|
||||
|
||||
<H3><a name="Library_std_shared_ptr">9.4.4 shared_ptr smart pointer</a></H3>
|
||||
<H3><a name="Library_std_shared_ptr">12.4.4 shared_ptr smart pointer</a></H3>
|
||||
|
||||
|
||||
<H4><a name="Library_shared_ptr_basics">12.4.4.1 shared_ptr basics</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1813,8 +1832,11 @@ System.out.println(val1 + " " + val2);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Library_shared_ptr_inheritance">12.4.4.2 shared_ptr and inheritance</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
This shared_ptr library works quite differently to SWIG's normal, but somewhat limited,
|
||||
The shared_ptr library works quite differently to SWIG's normal, but somewhat limited,
|
||||
<a href="SWIGPlus.html#SWIGPlus_smart_pointers">smart pointer handling</a>.
|
||||
The shared_ptr library does not generate extra wrappers, just for smart pointer handling, in addition to the proxy class.
|
||||
The normal proxy class including inheritance relationships is generated as usual.
|
||||
|
|
@ -1892,7 +1914,7 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%include "boost_shared_ptr.i"
|
||||
%include <boost_shared_ptr.i>
|
||||
%shared_ptr(GrandParent);
|
||||
%shared_ptr(Parent);
|
||||
%shared_ptr(Child);
|
||||
|
|
@ -1901,14 +1923,79 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Library_shared_ptr_overloading">12.4.4.3 shared_ptr and method overloading</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
<b>Note:</b> There is somewhat limited support for <tt>%shared_ptr</tt> and the director feature
|
||||
and the degrees of success varies among the different target languages.
|
||||
Please help to improve this support by providing patches with improvements.
|
||||
A C++ compiler can disambiguate a method overloaded by a shared_ptr and one using the raw underlying type.
|
||||
For example, either one of these methods can be called in C++:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
int age(std::shared_ptr<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">12.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">12.4.4.5 shared_ptr and directors</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
The languages that support shared_ptr also have support for using shared_ptr with directors.
|
||||
</p>
|
||||
|
||||
|
||||
<H3><a name="Library_std_auto_ptr">9.4.5 auto_ptr smart pointer</a></H3>
|
||||
<H3><a name="Library_std_auto_ptr">12.4.5 auto_ptr smart pointer</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1957,10 +2044,10 @@ int value = k.getValue();
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Library_nn16">9.5 Utility Libraries</a></H2>
|
||||
<H2><a name="Library_nn16">12.5 Utility Libraries</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Library_nn17">9.5.1 exception.i</a></H3>
|
||||
<H3><a name="Library_nn17">12.5.1 exception.i</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,11 +7,10 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Lisp">27 SWIG and Common Lisp</a></H1>
|
||||
<H1><a name="Lisp">29 SWIG and Common Lisp</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#Lisp_nn2">Allegro Common Lisp</a>
|
||||
<li><a href="#Lisp_nn3">Common Foreign Function Interface(CFFI)</a>
|
||||
<ul>
|
||||
<li><a href="#Lisp_nn4">Additional Commandline Options </a>
|
||||
|
|
@ -19,12 +18,9 @@
|
|||
<li><a href="#Lisp_nn6">Generating CFFI bindings for C++ code</a>
|
||||
<li><a href="#Lisp_nn7">Inserting user code into generated files</a>
|
||||
</ul>
|
||||
<li><a href="#Lisp_nn8">CLISP</a>
|
||||
<ul>
|
||||
<li><a href="#Lisp_nn9">Additional Commandline Options </a>
|
||||
<li><a href="#Lisp_nn10">Details on CLISP bindings</a>
|
||||
</ul>
|
||||
<li><a href="#Lisp_nn11">UFFI </a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -38,26 +34,17 @@
|
|||
finance, and also common in computer science education.
|
||||
There are more than 9 different implementations of common lisp which
|
||||
are available, all have different foreign function
|
||||
interfaces. SWIG currently supports only the Allegro Common
|
||||
Lisp, Common Foreign Function Interface(CFFI), CLisp and UFFI
|
||||
foreign function interfaces.
|
||||
</p>
|
||||
<H2><a name="Lisp_nn2">27.1 Allegro Common Lisp</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
Allegro Common Lisp support in SWIG has been updated to include
|
||||
support for both C and C++. You can read about the interface
|
||||
<a href="Allegrocl.html#Allegrocl">here</a>
|
||||
interfaces. SWIG currently supports the
|
||||
Common Foreign Function Interface(CFFI).
|
||||
</p>
|
||||
|
||||
<H2><a name="Lisp_nn3">27.2 Common Foreign Function Interface(CFFI)</a></H2>
|
||||
<H2><a name="Lisp_nn3">29.2 Common Foreign Function Interface(CFFI)</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
CFFI, the Common Foreign Function Interface, is a portable foreign
|
||||
function interface for ANSI Common Lisp systems, similar in
|
||||
spirit to UFFI. Unlike UFFI, CFFI requires only a small set of
|
||||
function interface for ANSI Common Lisp systems.
|
||||
CFFI requires only a small set of
|
||||
low-level functionality from the Lisp implementation, such as
|
||||
calling a foreign function by name, allocating foreign memory,
|
||||
and dereferencing pointers.
|
||||
|
|
@ -78,18 +65,9 @@ swig -cffi -module <i>module-name</i> <i>file-name</i>
|
|||
files and the various things which you can do with them.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lisp_nn4">27.2.1 Additional Commandline Options </a></H3>
|
||||
<H3><a name="Lisp_nn4">29.2.1 Additional Commandline Options </a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
The following table list the additional commandline options available for the CLISP module. They can also be seen by using:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
swig -cffi -help
|
||||
</pre></div>
|
||||
<br/>
|
||||
|
||||
<table summary="CFFI specific options">
|
||||
<tr>
|
||||
<th> CFFI specific options</th>
|
||||
|
|
@ -119,12 +97,15 @@ swig -cffi -help
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lisp_nn5">27.2.2 Generating CFFI bindings</a></H3>
|
||||
<H3><a name="Lisp_nn5">29.2.2 Generating CFFI bindings</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
||||
As we mentioned earlier the ideal way to use SWIG is to use interface
|
||||
files. To illustrate the use of it, let's assume that we have a
|
||||
file named <i>test.h</i> with the following C code:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
#define y 5
|
||||
|
|
@ -155,7 +136,10 @@ void lispsort_double (int n, double * array);
|
|||
enum color { RED, BLUE, GREEN};
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
Corresponding to this we will write a simple interface file:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%module test
|
||||
|
||||
|
|
@ -163,7 +147,9 @@ Corresponding to this we will write a simple interface file:
|
|||
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The generated SWIG Code will be:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
;;;SWIG wrapper code starts here
|
||||
|
|
@ -395,7 +381,7 @@ The feature <i>intern_function</i> ensures that all C names are
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lisp_nn6">27.2.3 Generating CFFI bindings for C++ code</a></H3>
|
||||
<H3><a name="Lisp_nn6">29.2.3 Generating CFFI bindings for C++ code</a></H3>
|
||||
|
||||
|
||||
<p>This feature to SWIG (for CFFI) is very new and still far from
|
||||
|
|
@ -430,8 +416,10 @@ Also, while parsing the C++ file and generating C wrapper code SWIG
|
|||
%include "target/header.h"
|
||||
|
||||
</pre></div>
|
||||
<p>
|
||||
Various features which were available for C headers can also be used
|
||||
here. The target header which we are going to use here is:
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
namespace OpenDemo {
|
||||
class Test
|
||||
|
|
@ -478,8 +466,10 @@ namespace OpenDemo {
|
|||
%include "test.cpp"
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
SWIG generates 3 files, the first one is a C wrap which we don't show,
|
||||
the second is the plain CFFI wrapper which is as shown below:
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
(cffi:defcfun ("_wrap_Test_x_set" Test_x_set) :void
|
||||
(self :pointer)
|
||||
|
|
@ -528,11 +518,13 @@ SWIG generates 3 files, the first one is a C wrap which we don't show,
|
|||
(cffi:defcfun ("_wrap_RandomUnitVectorOnXZPlane" RandomUnitVectorOnXZPlane) :pointer)
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The output is pretty good but it fails in disambiguating overloaded
|
||||
functions such as the constructor, in this case. One way of
|
||||
resolving this problem is to make the interface use the rename
|
||||
directiv, but hopefully there are better solutions.
|
||||
In addition SWIG also generates, a CLOS file
|
||||
</p>
|
||||
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -568,7 +560,7 @@ If you have any questions, suggestions, patches, etc., related to CFFI
|
|||
module feel free to contact us on the SWIG mailing list, and
|
||||
also please add a "[CFFI]" tag in the subject line.
|
||||
|
||||
<H3><a name="Lisp_nn7">27.2.4 Inserting user code into generated files</a></H3>
|
||||
<H3><a name="Lisp_nn7">29.2.4 Inserting user code into generated files</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -608,195 +600,5 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Lisp_nn8">27.3 CLISP</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
<a href="http://clisp.cons.org">CLISP</a> is a feature-loaded
|
||||
implementation of common lisp which is portable across most of the
|
||||
operating system environments and hardware. CLISP includes an
|
||||
interpreter, a compiler, a debugger, CLOS, MOP, a foreign
|
||||
language interface, i18n, regular expressions, a socket
|
||||
interface, and more. An X11 interface is available through CLX,
|
||||
Garnet and CLUE/CLIO. Command line editing is provided by
|
||||
readline. CLISP runs Maxima, ACL2 and many other Common Lisp
|
||||
packages.
|
||||
</p>
|
||||
<p>
|
||||
To run the clisp module of SWIG requires very little effort, you
|
||||
just need to execute:
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
swig -clisp -module <i>module-name</i> <i>file-name</i>
|
||||
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
Because of the high level nature of the CLISP FFI, the bindings
|
||||
generated by SWIG may not be absolutely correct, and you may need
|
||||
to modify them. The good thing is that you don't need to complex
|
||||
interface file for the CLISP module. The CLISP module tries to
|
||||
produce code which is both human readable and easily modifyable.
|
||||
</p>
|
||||
<H3><a name="Lisp_nn9">27.3.1 Additional Commandline Options </a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
The following table list the additional commandline options available for the CLISP module. They can also be seen by using:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
swig -clisp -help
|
||||
</pre></div>
|
||||
<br/>
|
||||
<table summary="CLISP specific options">
|
||||
<tr>
|
||||
<th>CLISP specific options</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-extern-all</td>
|
||||
<td>If this option is given then clisp definitions for all the functions<br/>
|
||||
and global variables will be created otherwise only definitions for<br/>
|
||||
externed functions and variables are created.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-generate-typedef</td>
|
||||
<td>If this option is given then def-c-type will be used to generate<br/>
|
||||
shortcuts according to the typedefs in the input.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lisp_nn10">27.3.2 Details on CLISP bindings</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
As mentioned earlier the CLISP bindings generated by SWIG may need
|
||||
some modifications. The clisp module creates a lisp file with
|
||||
the same name as the module name. This
|
||||
lisp file contains a 'defpackage' declaration, with the
|
||||
package name same as the module name. This package uses the
|
||||
'common-lisp' and 'ffi' packages. Also, package exports all
|
||||
the functions, structures and variables for which an ffi
|
||||
binding was generated.<br/>
|
||||
After generating the defpackage statement, the clisp module also
|
||||
sets the default language.
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
(defpackage :test
|
||||
(:use :common-lisp :ffi)
|
||||
(:export
|
||||
:make-bar
|
||||
:bar-x
|
||||
:bar-y
|
||||
:bar-a
|
||||
:bar-b
|
||||
:bar-z
|
||||
:bar-n
|
||||
:pointer_func
|
||||
:func123
|
||||
:make-cfunr
|
||||
:lispsort_double
|
||||
:test123))
|
||||
|
||||
(in-package :test)
|
||||
|
||||
(default-foreign-language :stdc)
|
||||
</pre></div>
|
||||
<p>
|
||||
The ffi wrappers for functions and variables are generated as shown
|
||||
below. When functions have arguments of type "double * array",
|
||||
SWIG doesn't knows whether it is an 'out' argument or it is
|
||||
an array which will be passed, so SWIG plays it safe by
|
||||
declaring it as an '(array (ffi:c-ptr DOUBLE-FLOAT))'. For
|
||||
arguments of type "int **z[100]" where SWIG has more
|
||||
information, i.e., it knows that 'z' is an array of pointers to
|
||||
pointers of integers, SWIG defines it to be '(z (ffi:c-ptr
|
||||
(ffi:c-array (ffi:c-ptr (ffi:c-ptr ffi:int)) 100)))'
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
extern "C" {
|
||||
int pointer_func(void (*ClosureFun)( void* _fun, void* _data, void* _evt ), int y);
|
||||
|
||||
int func123(div_t * x, int **z[100], int y[][1000][10]);
|
||||
|
||||
void lispsort_double (int n, double * array);
|
||||
|
||||
void test123(float x , double y);
|
||||
|
||||
}
|
||||
</pre></div>
|
||||
<div class="targetlang"><pre>
|
||||
(ffi:def-call-out pointer_func
|
||||
(:name "pointer_func")
|
||||
(:arguments (ClosureFun (ffi:c-function (:arguments (arg0 (ffi:c-pointer NIL))
|
||||
(arg1 (ffi:c-pointer NIL))
|
||||
(arg2 (ffi:c-pointer NIL)))
|
||||
(:return-type NIL)))
|
||||
(y ffi:int))
|
||||
(:return-type ffi:int)
|
||||
(:library +library-name+))
|
||||
|
||||
(ffi:def-call-out func123
|
||||
(:name "func123")
|
||||
(:arguments (x (ffi:c-pointer div_t))
|
||||
(z (ffi:c-ptr (ffi:c-array (ffi:c-ptr (ffi:c-ptr ffi:int)) 100)))
|
||||
(y (ffi:c-ptr (ffi:c-ptr (ffi:c-array ffi:int (1000 10))))))
|
||||
(:return-type ffi:int)
|
||||
(:library +library-name+))
|
||||
|
||||
|
||||
(ffi:def-call-out lispsort_double
|
||||
(:name "lispsort_double")
|
||||
(:arguments (n ffi:int)
|
||||
(array (ffi:c-ptr DOUBLE-FLOAT)))
|
||||
(:return-type NIL)
|
||||
(:library +library-name+))
|
||||
|
||||
(ffi:def-call-out test123
|
||||
(:name "test")
|
||||
(:arguments (x SINGLE-FLOAT)
|
||||
(y DOUBLE-FLOAT))
|
||||
(:return-type NIL)
|
||||
(:library +library-name+))
|
||||
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The module also handles strutcures and #define constants as shown
|
||||
below. SWIG automatically adds the constructors and accessors
|
||||
created for the struct to the list of symbols exported by the
|
||||
package.
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
struct bar {
|
||||
short x, y;
|
||||
char a, b;
|
||||
int *z[1000];
|
||||
struct bar * n;
|
||||
};
|
||||
|
||||
#define max 1000
|
||||
</pre></div>
|
||||
<div class="targetlang"><pre>
|
||||
(ffi:def-c-struct bar
|
||||
(x :type ffi:short)
|
||||
(y :type ffi:short)
|
||||
(a :type character)
|
||||
(b :type character)
|
||||
(z :type (ffi:c-array (ffi:c-ptr ffi:int) 1000))
|
||||
(n :type (ffi:c-pointer bar)))
|
||||
|
||||
(defconstant max 1000)
|
||||
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lisp_nn11">27.4 UFFI </a></H2>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Lua">28 SWIG and Lua</a></H1>
|
||||
<H1><a name="Lua">29 SWIG and Lua</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -77,20 +77,20 @@
|
|||
|
||||
|
||||
<p>
|
||||
Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in clean C (that is, in the common subset of ANSI C and C++). 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>
|
||||
eLua stands for Embedded Lua (can be thought of as a flavor of Lua) and offers the full implementation of the Lua programming language to the embedded world, extending it with specific features for efficient and portable software embedded development. eLua runs on smaller devices like microcontrollers and provides the full features of the regular Lua desktop version. More information on eLua can be found here: <a href="http://www.eluaproject.net">http://www.eluaproject.net</a>
|
||||
</p>
|
||||
|
||||
<H2><a name="Lua_nn2">28.1 Preliminaries</a></H2>
|
||||
<H2><a name="Lua_nn2">29.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
The current SWIG implementation is designed to work with Lua 5.0.x, 5.1.x and 5.2.x. It should work with later versions of Lua, but certainly not with Lua 4.0 due to substantial API changes. It is possible to either static link or dynamic link a Lua module into the interpreter (normally Lua static links its libraries, as dynamic linking is not available on all platforms). SWIG also has support for eLua starting from eLua 0.8. Due to substantial changes between SWIG 2.x and SWIG 3.0 and unavailability of testing platform, eLua status was downgraded to 'experimental'.
|
||||
</p>
|
||||
|
||||
<H2><a name="Lua_nn3">28.2 Running SWIG</a></H2>
|
||||
<H2><a name="Lua_nn3">29.2 Running SWIG</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -138,14 +138,14 @@ $ swig -lua -eluac example.i
|
|||
The <tt>-elua</tt> option puts all the C function wrappers and variable get/set wrappers in rotables. It also generates a metatable which will control the access to these variables from eLua. It also offers a significant amount of module size compression. On the other hand, the <tt>-eluac</tt> option puts all the wrappers in a single rotable. With this option, no matter how huge the module, it will consume no additional microcontroller SRAM (crass compression). There is a catch though: Metatables are not generated with <tt>-eluac</tt>. To access any value from eLua, one must directly call the wrapper function associated with that value.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_commandline">28.2.1 Additional command line options</a></H3>
|
||||
<H3><a name="Lua_commandline">29.2.1 Additional command line options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
The following table list the additional commandline options available for the Lua module. They can also be seen by using:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
<div class="shell"><pre>
|
||||
swig -lua -help
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -179,7 +179,7 @@ swig -lua -help
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Lua_nn4">28.2.2 Compiling and Linking and Interpreter</a></H3>
|
||||
<H3><a name="Lua_nn4">29.2.2 Compiling and Linking and Interpreter</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -250,7 +250,7 @@ LUALIB_API int ( luaopen_mod )(lua_State *L );
|
|||
More information on building and configuring eLua can be found here: <a href="http://www.eluaproject.net/doc/v0.8/en_building.html">http://www.eluaproject.net/doc/v0.8/en_building.html</a>
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn5">28.2.3 Compiling a dynamic module</a></H3>
|
||||
<H3><a name="Lua_nn5">29.2.3 Compiling a dynamic module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -318,7 +318,7 @@ Is quite obvious (Go back and consult the Lua documents on how to enable loadlib
|
|||
|
||||
|
||||
|
||||
<H3><a name="Lua_nn6">28.2.4 Using your module</a></H3>
|
||||
<H3><a name="Lua_nn6">29.2.4 Using your module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -336,19 +336,19 @@ $ ./my_lua
|
|||
>
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_nn7">28.3 A tour of basic C/C++ wrapping</a></H2>
|
||||
<H2><a name="Lua_nn7">29.3 A tour of basic C/C++ wrapping</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
By default, SWIG tries to build a very natural Lua interface to your C/C++ code. This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
<H3><a name="Lua_nn8">28.3.1 Modules</a></H3>
|
||||
<H3><a name="Lua_nn8">29.3.1 Modules</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
The SWIG module directive specifies the name of the Lua module. If you specify `module example', then everything is wrapped into a Lua table 'example' containing all the functions and variables. When choosing a module name, make sure you don't use the same name as a built-in Lua command or standard module name.
|
||||
</p>
|
||||
<H3><a name="Lua_nn9">28.3.2 Functions</a></H3>
|
||||
<H3><a name="Lua_nn9">29.3.2 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -389,7 +389,7 @@ It is also possible to rename the module with an assignment.
|
|||
24
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn10">28.3.3 Global variables</a></H3>
|
||||
<H3><a name="Lua_nn10">29.3.3 Global variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -477,7 +477,7 @@ If you have used the <tt>-eluac</tt> option for your eLua module, you will have
|
|||
In general, functions of the form <tt>"variable_get()"</tt> and <tt>"variable_set()"</tt> are automatically generated by SWIG for use with <tt>-eluac</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn11">28.3.4 Constants and enums</a></H3>
|
||||
<H3><a name="Lua_nn11">29.3.4 Constants and enums</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -512,7 +512,7 @@ If you're using eLua and have used <tt>-elua</tt> or <tt>-eluac</tt> to generate
|
|||
Hello World
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Lua_nn13">28.3.4.1 Constants/enums and classes/structures</a></H4>
|
||||
<H4><a name="Lua_nn13">29.3.4.1 Constants/enums and classes/structures</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -568,7 +568,7 @@ If the <tt>-no-old-metatable-bindings</tt> option is used, then these old-style
|
|||
It is worth mentioning, that <tt>example.Test.TEST1</tt> and <tt>example.Test_TEST1</tt> are different entities and changing one does not change the other.
|
||||
Given the fact that these are constantes and they are not supposed to be changed, it is up to you to avoid such issues.
|
||||
</p>
|
||||
<H3><a name="Lua_nn12">28.3.5 Pointers</a></H3>
|
||||
<H3><a name="Lua_nn12">29.3.5 Pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -606,7 +606,7 @@ Lua enforces the integrity of its userdata, so it is virtually impossible to cor
|
|||
nil
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_structures">28.3.6 Structures</a></H3>
|
||||
<H3><a name="Lua_structures">29.3.6 Structures</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -710,7 +710,7 @@ For eLua with the <tt>-eluac</tt> option, structure manipulation has to be perfo
|
|||
In general, functions of the form <tt>"new_struct()"</tt>, <tt>"struct_member_get()"</tt>, <tt>"struct_member_set()"</tt> and <tt>"free_struct()"</tt> are automatically generated by SWIG for each structure defined in C. (Please note: This doesn't apply for modules generated with the <tt>-elua</tt> option)
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn14">28.3.7 C++ classes</a></H3>
|
||||
<H3><a name="Lua_nn14">29.3.7 C++ classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -747,7 +747,8 @@ Stout
|
|||
<p>
|
||||
Class data members are accessed in the same manner as C structures. Static class members present a special problem for Lua, as Lua doesn't have support for such features. Therefore, SWIG generates wrappers that try to work around some of these issues. To illustrate, suppose you have a class like this:
|
||||
</p>
|
||||
<div class="targetlang"><pre>class Spam {
|
||||
<div class="code"><pre>
|
||||
class Spam {
|
||||
public:
|
||||
static void foo();
|
||||
static int bar;
|
||||
|
|
@ -756,7 +757,7 @@ public:
|
|||
<p>
|
||||
In Lua, C++ static members can be accessed as follows:
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
<div class="targetlang"><pre>
|
||||
> example.Spam.foo() -- calling Spam::foo()
|
||||
> a=example.Spam.bar -- reading Spam::bar
|
||||
> example.Spam.bar=b -- writing to Spam::bar
|
||||
|
|
@ -774,7 +775,7 @@ It is not (currently) possible to access static members of an instance:
|
|||
<b>Compatibility Note:</b> In versions prior to SWIG-3.0.0 only the following names would work:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
<div class="targetlang"><pre>
|
||||
> example.Spam_foo() -- calling Spam::foo()
|
||||
> a=example.Spam_bar -- reading Spam::bar
|
||||
> example.Spam_bar=b -- writing to Spam::bar
|
||||
|
|
@ -785,7 +786,7 @@ Both style names are generated by default now.
|
|||
However, if the <tt>-no-old-metatable-bindings</tt> option is used, then the backward compatible names are not generated in addition to ordinary ones.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn15">28.3.8 C++ inheritance</a></H3>
|
||||
<H3><a name="Lua_nn15">29.3.8 C++ inheritance</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -810,7 +811,7 @@ then the function <tt>spam()</tt> accepts a Foo pointer or a pointer to any clas
|
|||
<p>
|
||||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
<H3><a name="Lua_nn16">28.3.9 Pointers, references, values, and arrays</a></H3>
|
||||
<H3><a name="Lua_nn16">29.3.9 Pointers, references, values, and arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -841,7 +842,7 @@ Foo spam7();
|
|||
<p>
|
||||
then all three functions will return a pointer to some Foo object. Since the third function (spam7) returns a value, newly allocated memory is used to hold the result and a pointer is returned (Lua will release this memory when the return value is garbage collected). The other two are pointers which are assumed to be managed by the C code and so will not be garbage collected.
|
||||
</p>
|
||||
<H3><a name="Lua_nn17">28.3.10 C++ overloaded functions</a></H3>
|
||||
<H3><a name="Lua_nn17">29.3.10 C++ overloaded functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -927,7 +928,7 @@ Please refer to the "SWIG and C++" chapter for more information about overloadin
|
|||
<p>
|
||||
Dealing with the Lua coercion mechanism, the priority is roughly (integers, floats, strings, userdata). But it is better to rename the functions rather than rely upon the ordering.
|
||||
</p>
|
||||
<H3><a name="Lua_nn18">28.3.11 C++ operators</a></H3>
|
||||
<H3><a name="Lua_nn18">29.3.11 C++ operators</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -964,7 +965,8 @@ When wrapped, it works like you expect:
|
|||
<p>
|
||||
One restriction with operator overloading support is that SWIG is not able to fully handle operators that aren't defined as part of the class. For example, if you had code like this
|
||||
</p>
|
||||
<div class="targetlang"><pre>class Complex {
|
||||
<div class="code"><pre>
|
||||
class Complex {
|
||||
...
|
||||
friend Complex operator+(double, const Complex &c);
|
||||
...
|
||||
|
|
@ -973,7 +975,8 @@ friend Complex operator+(double, const Complex &c);
|
|||
<p>
|
||||
then SWIG doesn't know what to do with the friend function--in fact, it simply ignores it and issues a warning. You can still wrap the operator, but you may have to encapsulate it in a special function. For example:
|
||||
</p>
|
||||
<div class="targetlang"><pre>%rename(Complex_add_dc) operator+(double, const Complex &);
|
||||
<div class="code"><pre>
|
||||
%rename(Complex_add_dc) operator+(double, const Complex &);
|
||||
...
|
||||
Complex operator+(double, const Complex &c);
|
||||
</pre></div>
|
||||
|
|
@ -984,7 +987,7 @@ There are ways to make this operator appear as part of the class using the <tt>%
|
|||
Also, be aware that certain operators don't map cleanly to Lua, and some Lua operators don't map cleanly to C++ operators. For instance, overloaded assignment operators don't map to Lua semantics and will be ignored, and C++ doesn't support Lua's concatenation operator (<tt>..</tt>).
|
||||
</p>
|
||||
<p>
|
||||
In order to keep maximum compatibility within the different languages in SWIG, the Lua bindings uses the same set of operator names as python. Although internally it renames the functions to something else (on order to work with Lua).
|
||||
In order to keep maximum compatibility within the different languages in SWIG, the Lua bindings uses the same set of operator names as Python. Although internally it renames the functions to something else (on order to work with Lua).
|
||||
<p>
|
||||
The current list of operators which can be overloaded (and the alternative function names) are:<ul>
|
||||
<li><tt>__add__</tt> operator+
|
||||
|
|
@ -1008,11 +1011,10 @@ The following operators cannot be overloaded (mainly because they are not suppor
|
|||
<p>
|
||||
SWIG also accepts the <tt>__str__()</tt> member function which converts an object to a string. This function should return a const char*, preferably to static memory. This will be used for the <tt>print()</tt> and <tt>tostring()</tt> functions in Lua. Assuming the complex class has a function
|
||||
</p>
|
||||
<div class="code"><pre>const char* __str__()
|
||||
{
|
||||
static char buffer[255];
|
||||
sprintf(buffer, "Complex(%g, %g)", this->re(), this->im());
|
||||
return buffer;
|
||||
<div class="code"><pre>const char* __str__() {
|
||||
static char buffer[255];
|
||||
sprintf(buffer, "Complex(%g, %g)", this->re(), this->im());
|
||||
return buffer;
|
||||
}
|
||||
</pre></div>
|
||||
<p>
|
||||
|
|
@ -1031,11 +1033,10 @@ Complex(10, 12)
|
|||
<p>
|
||||
It is also possible to overload the operator<tt>[]</tt>, but currently this cannot be automatically performed. To overload the operator<tt>[]</tt> you need to provide two functions, <tt>__getitem__()</tt> and <tt>__setitem__()</tt>
|
||||
</p>
|
||||
<div class="code"><pre>class Complex
|
||||
{
|
||||
//....
|
||||
double __getitem__(int i)const; // i is the index, returns the data
|
||||
void __setitem__(int i, double d); // i is the index, d is the data
|
||||
<div class="code"><pre>class Complex {
|
||||
//....
|
||||
double __getitem__(int i)const; // i is the index, returns the data
|
||||
void __setitem__(int i, double d); // i is the index, d is the data
|
||||
};
|
||||
</pre></div>
|
||||
<p>
|
||||
|
|
@ -1061,7 +1062,7 @@ operators and pseudo-operators):</p>
|
|||
</ul>
|
||||
<p>No other lua metafunction is inherited. For example, __gc is not inherited and must be redefined in every class. <tt>__tostring</tt> is subject to a special handling. If absent in class and in class bases, a default one will be provided by SWIG.
|
||||
</p>
|
||||
<H3><a name="Lua_nn19">28.3.12 Class extension with %extend</a></H3>
|
||||
<H3><a name="Lua_nn19">29.3.12 Class extension with %extend</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1118,7 +1119,7 @@ true
|
|||
Extend works with both C and C++ code, on classes and structs. It does not modify the underlying object in any way---the extensions only show up in the Lua interface. The only item to take note of is the code has to use the '$self' instead of 'this', and that you cannot access protected/private members of the code (as you are not officially part of the class).
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn20">28.3.13 Using %newobject to release memory</a></H3>
|
||||
<H3><a name="Lua_nn20">29.3.13 Using %newobject to release memory</a></H3>
|
||||
|
||||
|
||||
<p> If you have a function that allocates memory like this,</p>
|
||||
|
|
@ -1142,7 +1143,7 @@ char *foo();
|
|||
</div>
|
||||
<p> This will release the allocated memory.</p>
|
||||
|
||||
<H3><a name="Lua_nn21">28.3.14 C++ templates</a></H3>
|
||||
<H3><a name="Lua_nn21">29.3.14 C++ templates</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1177,7 +1178,7 @@ In Lua:
|
|||
<p>
|
||||
Obviously, there is more to template wrapping than shown in this example. More details can be found in the SWIG and C++ chapter. Some more complicated examples will appear later.
|
||||
</p>
|
||||
<H3><a name="Lua_nn22">28.3.15 C++ Smart Pointers</a></H3>
|
||||
<H3><a name="Lua_nn22">29.3.15 C++ Smart Pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1229,7 +1230,7 @@ If you ever need to access the underlying pointer returned by <tt>operator->(
|
|||
> f = p:__deref__() -- Returns underlying Foo *
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn23">28.3.16 C++ Exceptions</a></H3>
|
||||
<H3><a name="Lua_nn23">29.3.16 C++ Exceptions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1372,7 +1373,7 @@ and the "<a href="Customization.html#Customization_exception">Exception handling
|
|||
add exception specification to functions or globally (respectively).
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_namespaces">28.3.17 Namespaces </a></H3>
|
||||
<H3><a name="Lua_namespaces">29.3.17 Namespaces </a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1423,7 +1424,7 @@ Now, from Lua usage is as follows:
|
|||
19
|
||||
>
|
||||
</pre></div>
|
||||
<H4><a name="Lua_nn27">28.3.17.1 Compatibility Note </a></H4>
|
||||
<H4><a name="Lua_nn27">29.3.17.1 Compatibility Note </a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1439,7 +1440,7 @@ If SWIG is running in a backwards compatible way, i.e. without the <tt>-no-old-m
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H4><a name="Lua_nn29">28.3.17.2 Names </a></H4>
|
||||
<H4><a name="Lua_nn29">29.3.17.2 Names </a></H4>
|
||||
|
||||
|
||||
<p> If SWIG is launched without <tt>-no-old-metatable-bindings</tt> option, then it enters backward-compatible mode. While in this mode, it tries
|
||||
|
|
@ -1448,6 +1449,7 @@ Those names are in a form <tt>$classname_$symbolname</tt> and are added to the s
|
|||
If %nspace is enabled, then class namespace is taken as scope. If there is no namespace, or %nspace is disabled,
|
||||
then module is considered a class namespace.</p>
|
||||
<p> Consider the following C++ code </p>
|
||||
|
||||
<div class="code"><pre>%module example
|
||||
%nspace MyWorld::Test;
|
||||
namespace MyWorld {
|
||||
|
|
@ -1483,11 +1485,12 @@ surrounding scope without any prefixing. Pretending that Test2 is a struct, not
|
|||
>
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Lua_nn30">28.3.17.3 Inheritance </a></H4>
|
||||
<H4><a name="Lua_nn30">29.3.17.3 Inheritance </a></H4>
|
||||
|
||||
|
||||
<p> The internal organization of inheritance has changed.
|
||||
Consider the following C++ code:</p>
|
||||
|
||||
<div class="code"><pre>%module example
|
||||
class Base {
|
||||
public:
|
||||
|
|
@ -1504,6 +1507,7 @@ were squashed and added to corresponding derived class <tt>ST</tt>: Everything f
|
|||
was copied to <tt>.fn</tt> table of class Derived and so on. This was a recursive procedure, so in the end the whole
|
||||
inheritance tree of derived class was squashed into derived class. </p>
|
||||
<p> That means that any changes done to class Base after module initialization wouldn't affect class Derived:</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
base = example.Base()
|
||||
der = example.Derived()
|
||||
|
|
@ -1518,18 +1522,20 @@ nil
|
|||
</pre></div>
|
||||
<p> This behaviour was changed. Now unless -squash-bases option is provided, Derived store a list of it's bases and if some symbol is not found in it's own service tables
|
||||
then its bases are searched for it. Option -squash-bases will effectively return old behaviour.
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
> print(der.new_func) -- Now it works
|
||||
function
|
||||
>
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_nn24">28.4 Typemaps</a></H2>
|
||||
<H2><a name="Lua_nn24">29.4 Typemaps</a></H2>
|
||||
|
||||
|
||||
<p>This section explains what typemaps are and how to use them. The default wrapping behaviour of SWIG is enough in most cases. However sometimes SWIG may need a little additional assistance to know which typemap to apply to provide the best wrapping. This section will be explaining how to use typemaps to best effect</p>
|
||||
|
||||
<H3><a name="Lua_nn25">28.4.1 What is a typemap?</a></H3>
|
||||
<H3><a name="Lua_nn25">29.4.1 What is a typemap?</a></H3>
|
||||
|
||||
|
||||
<p>A typemap is nothing more than a code generation rule that is attached to a specific C datatype. For example, to convert integers from Lua to C, you might define a typemap like this:</p>
|
||||
|
|
@ -1557,7 +1563,7 @@ Received an integer : 6
|
|||
720
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn26">28.4.2 Using typemaps</a></H3>
|
||||
<H3><a name="Lua_nn26">29.4.2 Using typemaps</a></H3>
|
||||
|
||||
|
||||
<p>There are many ready written typemaps built into SWIG for all common types (int, float, short, long, char*, enum and more), which SWIG uses automatically, with no effort required on your part.</p>
|
||||
|
|
@ -1610,7 +1616,7 @@ void swap(int *sx, int *sy);
|
|||
|
||||
<p>Note: C++ references must be handled exactly the same way. However SWIG will automatically wrap a <tt>const int&</tt> as an input parameter (since that it obviously input).</p>
|
||||
|
||||
<H3><a name="Lua_typemap_arrays">28.4.3 Typemaps and arrays</a></H3>
|
||||
<H3><a name="Lua_typemap_arrays">29.4.3 Typemaps and arrays</a></H3>
|
||||
|
||||
|
||||
<p>Arrays present a challenge for SWIG, because like pointers SWIG does not know whether these are input or output values, nor
|
||||
|
|
@ -1674,7 +1680,7 @@ and Lua tables to be 1..N, (the indexing follows the norm for the language). In
|
|||
|
||||
<p>Note: SWIG also can support arrays of pointers in a similar manner.</p>
|
||||
|
||||
<H3><a name="Lua_typemaps_ptr_ptr_functions">28.4.4 Typemaps and pointer-pointer functions</a></H3>
|
||||
<H3><a name="Lua_typemaps_ptr_ptr_functions">29.4.4 Typemaps and pointer-pointer functions</a></H3>
|
||||
|
||||
|
||||
<p>Several C++ libraries use a pointer-pointer functions to create its objects. These functions require a pointer to a pointer which is then filled with the pointer to the new object. Microsoft's COM and DirectX as well as many other libraries have this kind of function. An example is given below:</p>
|
||||
|
|
@ -1708,7 +1714,7 @@ int Create_Math(iMath** pptr); // its creator (assume it mallocs)
|
|||
ptr=nil -- the iMath* will be GC'ed as normal
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_writing_typemaps">28.5 Writing typemaps</a></H2>
|
||||
<H2><a name="Lua_writing_typemaps">29.5 Writing typemaps</a></H2>
|
||||
|
||||
|
||||
<p>This section describes how you can modify SWIG's default wrapping behavior for various C/C++ datatypes using the <tt>%typemap</tt> directive. This is an advanced topic that assumes familiarity with the Lua C API as well as the material in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter.</p>
|
||||
|
|
@ -1717,7 +1723,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
|
|||
|
||||
<p>Before proceeding, you should read the previous section on using typemaps, and look at the existing typemaps found in luatypemaps.swg and typemaps.i. These are both well documented and fairly easy to read. You should not attempt to write your own typemaps until you have read and can understand both of these files (they may well also give you an idea to base your work on).</p>
|
||||
|
||||
<H3><a name="Lua_typemaps_write">28.5.1 Typemaps you can write</a></H3>
|
||||
<H3><a name="Lua_typemaps_write">29.5.1 Typemaps you can write</a></H3>
|
||||
|
||||
|
||||
<p>There are many different types of typemap that can be written, the full list can be found in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter. However the following are the most commonly used ones.</p>
|
||||
|
|
@ -1730,7 +1736,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
|
|||
(the syntax for the typecheck is different from the typemap, see typemaps for details).</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Lua_nn31">28.5.2 SWIG's Lua-C API</a></H3>
|
||||
<H3><a name="Lua_nn31">29.5.2 SWIG's Lua-C API</a></H3>
|
||||
|
||||
|
||||
<p>This section explains the SWIG specific Lua-C API. It does not cover the main Lua-C api, as this is well documented and not worth covering.</p>
|
||||
|
|
@ -1779,7 +1785,7 @@ This macro, when called within the context of a SWIG wrapped function, will disp
|
|||
<div class="indent">
|
||||
Similar to SWIG_fail_arg, except that it will display the swig_type_info information instead.</div>
|
||||
|
||||
<H2><a name="Lua_nn32">28.6 Customization of your Bindings</a></H2>
|
||||
<H2><a name="Lua_nn32">29.6 Customization of your Bindings</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1788,7 +1794,7 @@ This section covers adding of some small extra bits to your module to add the la
|
|||
|
||||
|
||||
|
||||
<H3><a name="Lua_nn33">28.6.1 Writing your own custom wrappers</a></H3>
|
||||
<H3><a name="Lua_nn33">29.6.1 Writing your own custom wrappers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1807,7 +1813,7 @@ int native_function(lua_State*L) // my native code
|
|||
The <tt>%native</tt> directive in the above example, tells SWIG that there is a function <tt>int native_function(lua_State*L);</tt> which is to be added into the module under the name '<tt>my_func</tt>'. SWIG will not add any wrapper for this function, beyond adding it into the function table. How you write your code is entirely up to you.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn34">28.6.2 Adding additional Lua code</a></H3>
|
||||
<H3><a name="Lua_nn34">29.6.2 Adding additional Lua code</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1845,7 +1851,7 @@ Good uses for this feature is adding of new code, or writing helper functions to
|
|||
See Examples/lua/arrays for an example of this code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Lua_nn35">28.7 Details on the Lua binding</a></H2>
|
||||
<H2><a name="Lua_nn35">29.7 Details on the Lua binding</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1856,7 +1862,7 @@ See Examples/lua/arrays for an example of this code.
|
|||
</i>
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn36">28.7.1 Binding global data into the module.</a></H3>
|
||||
<H3><a name="Lua_nn36">29.7.1 Binding global data into the module.</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1916,7 +1922,7 @@ end
|
|||
<p>
|
||||
That way when you call '<tt>a=example.Foo</tt>', the interpreter looks at the table 'example' sees that there is no field 'Foo' and calls __index. This will in turn check in '.get' table and find the existence of 'Foo' and then return the value of the C function call 'Foo_get()'. Similarly for the code '<tt>example.Foo=10</tt>', the interpreter will check the table, then call the __newindex which will then check the '.set' table and call the C function 'Foo_set(10)'.
|
||||
</p>
|
||||
<H3><a name="Lua_nn37">28.7.2 Userdata and Metatables</a></H3>
|
||||
<H3><a name="Lua_nn37">29.7.2 Userdata and Metatables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1996,7 +2002,7 @@ Note: Both the opaque structures (like the FILE*) and normal wrapped classes/str
|
|||
<p>
|
||||
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' & '__call' to the class' metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming its an operator overload.
|
||||
</p>
|
||||
<H3><a name="Lua_nn38">28.7.3 Memory management</a></H3>
|
||||
<H3><a name="Lua_nn38">29.7.3 Memory management</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -89,3 +89,9 @@ linkchecker2:
|
|||
cp *.png linkchecker-tmp
|
||||
(cd linkchecker-tmp && linkchecker --config=../linkchecker.config -F text --no-warnings SWIGDocumentation.html)
|
||||
|
||||
# Simple check for relative links (there shouldn't be any), they don't translate properly creating the .pdf doc
|
||||
# with wkhtmltopdf. For example, href="SWIG.html" needs to be href="SWIG.html#SWIG"
|
||||
linkchecker3:
|
||||
@echo "The following list should just contain SWIGDocumentation.html and SWIGDocumentation.pdf,"
|
||||
@echo "as all links should have an anchor (with a #) or be a full url beginning http."
|
||||
grep 'href="' *.html | sed -e 's/.*href="\(.*\)">.*$$/\1/' | grep -v "#" | grep -v "^http" | grep -v "^style.css"
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Modula3">29 SWIG and Modula-3</a></H1>
|
||||
<H1><a name="Modula3">31 SWIG and Modula-3</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -55,7 +55,7 @@ especially
|
|||
<a href="Typemaps.html#Typemaps">typemaps</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_modula3_overview">29.1 Overview</a></H2>
|
||||
<H2><a name="Modula3_modula3_overview">31.1 Overview</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -85,7 +85,7 @@ FFTW
|
|||
</li>
|
||||
</ol>
|
||||
|
||||
<H3><a name="Modula3_motivation">29.1.1 Motivation</a></H3>
|
||||
<H3><a name="Modula3_motivation">31.1.1 Motivation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -132,10 +132,10 @@ functions), but it doesn't allow you to easily integrate a Modula-3 module into
|
|||
a C/C++ project.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_conception">29.2 Conception</a></H2>
|
||||
<H2><a name="Modula3_conception">31.2 Conception</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_cinterface">29.2.1 Interfaces to C libraries</a></H3>
|
||||
<H3><a name="Modula3_cinterface">31.2.1 Interfaces to C libraries</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -284,7 +284,7 @@ and the principal type must be renamed (<tt>%typemap</tt>).
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_cppinterface">29.2.2 Interfaces to C++ libraries</a></H3>
|
||||
<H3><a name="Modula3_cppinterface">31.2.2 Interfaces to C++ libraries</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -385,10 +385,10 @@ There is no C++ library I wrote a SWIG interface for,
|
|||
so I'm not sure if this is possible or sensible, yet.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_preliminaries">29.3 Preliminaries</a></H2>
|
||||
<H2><a name="Modula3_preliminaries">31.3 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_compilers">29.3.1 Compilers</a></H3>
|
||||
<H3><a name="Modula3_compilers">31.3.1 Compilers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -401,7 +401,7 @@ For testing examples I use Critical Mass cm3.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_commandline">29.3.2 Additional Commandline Options</a></H3>
|
||||
<H3><a name="Modula3_commandline">31.3.2 Additional Commandline Options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -478,10 +478,10 @@ Instead generate templates for some basic typemaps.
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H2><a name="Modula3_typemaps">29.4 Modula-3 typemaps</a></H2>
|
||||
<H2><a name="Modula3_typemaps">31.4 Modula-3 typemaps</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_inoutparam">29.4.1 Inputs and outputs</a></H3>
|
||||
<H3><a name="Modula3_inoutparam">31.4.1 Inputs and outputs</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -695,7 +695,7 @@ consist of the following parts:
|
|||
</table>
|
||||
|
||||
|
||||
<H3><a name="Modula3_ordinals">29.4.2 Subranges, Enumerations, Sets</a></H3>
|
||||
<H3><a name="Modula3_ordinals">31.4.2 Subranges, Enumerations, Sets</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -747,7 +747,7 @@ that I'd like to automate.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_class">29.4.3 Objects</a></H3>
|
||||
<H3><a name="Modula3_class">31.4.3 Objects</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -760,7 +760,7 @@ is not really useful, yet.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_imports">29.4.4 Imports</a></H3>
|
||||
<H3><a name="Modula3_imports">31.4.4 Imports</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -793,7 +793,7 @@ IMPORT M3toC;
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Modula3_exceptions">29.4.5 Exceptions</a></H3>
|
||||
<H3><a name="Modula3_exceptions">31.4.5 Exceptions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -817,7 +817,7 @@ you should declare
|
|||
<tt>%typemap("m3wrapinconv:throws") blah * %{OSError.E%}</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Modula3_typemap_example">29.4.6 Example</a></H3>
|
||||
<H3><a name="Modula3_typemap_example">31.4.6 Example</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -864,10 +864,10 @@ where almost everything is generated by a typemap:
|
|||
</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">
|
||||
|
|
@ -904,7 +904,7 @@ where almost everything is generated by a typemap:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Modula3_pragmas">29.5.2 Pragmas</a></H3>
|
||||
<H3><a name="Modula3_pragmas">31.5.2 Pragmas</a></H3>
|
||||
|
||||
|
||||
<table border summary="Modula-3 pragmas">
|
||||
|
|
@ -927,7 +927,7 @@ where almost everything is generated by a typemap:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H2><a name="Modula3_remarks">29.6 Remarks</a></H2>
|
||||
<H2><a name="Modula3_remarks">31.6 Remarks</a></H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Modules">16 Working with Modules</a></H1>
|
||||
<H1><a name="Modules">20 Working with Modules</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="Modules_introduction">16.1 Modules Introduction</a></H2>
|
||||
<H2><a name="Modules_introduction">20.1 Modules Introduction</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -78,7 +78,7 @@ where you want to create a collection of modules.
|
|||
Each module in the collection is created via separate invocations of SWIG.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modules_nn1">16.2 Basics</a></H2>
|
||||
<H2><a name="Modules_nn1">20.2 Basics</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -177,7 +177,7 @@ in parallel from multiple threads as SWIG provides no locking - for more on that
|
|||
issue, read on.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modules_nn2">16.3 The SWIG runtime code</a></H2>
|
||||
<H2><a name="Modules_nn2">20.3 The SWIG runtime code</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -243,7 +243,7 @@ can peacefully coexist. So the type structures are separated by the
|
|||
is empty. Only modules compiled with the same pair will share type information.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modules_external_run_time">16.4 External access to the runtime</a></H2>
|
||||
<H2><a name="Modules_external_run_time">20.4 External access to the runtime</a></H2>
|
||||
|
||||
|
||||
<p>As described in <a href="Typemaps.html#Typemaps_runtime_type_checker">The run-time type checker</a>,
|
||||
|
|
@ -282,7 +282,7 @@ SWIG_TYPE_TABLE to be the same as the module whose types you are trying to
|
|||
access.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modules_nn4">16.5 A word of caution about static libraries</a></H2>
|
||||
<H2><a name="Modules_nn4">20.5 A word of caution about static libraries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -293,7 +293,7 @@ into it. This is very often <b>NOT</b> what you want and it can lead to unexpect
|
|||
behavior. When working with dynamically loadable modules, you should try to work exclusively with shared libraries.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modules_nn5">16.6 References</a></H2>
|
||||
<H2><a name="Modules_nn5">20.6 References</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -301,7 +301,7 @@ Due to the complexity of working with shared libraries and multiple modules, it
|
|||
an outside reference. John Levine's "Linkers and Loaders" is highly recommended.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modules_nn6">16.7 Reducing the wrapper file size</a></H2>
|
||||
<H2><a name="Modules_nn6">20.7 Reducing the wrapper file size</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Mzscheme">30 SWIG and MzScheme/Racket</a></H1>
|
||||
<H1><a name="Mzscheme">38 SWIG and MzScheme/Racket</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
<p>
|
||||
This section contains information on SWIG's support of Racket, formally known as MzScheme.
|
||||
|
||||
<H2><a name="MzScheme_nn2">30.1 Creating native structures</a></H2>
|
||||
<H2><a name="MzScheme_nn2">38.1 Creating native structures</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -65,7 +65,7 @@ Then in scheme, you can use regular struct access procedures like
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="MzScheme_simple">30.2 Simple example</a></H2>
|
||||
<H2><a name="MzScheme_simple">38.2 Simple example</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -166,11 +166,11 @@ Some points of interest:
|
|||
<li> The above requests mzc to create an extension using the CGC garbage-collector. The alternative -- the 3m collector -- has generally better performance, but work is still required for SWIG to emit code which is compatible with it.
|
||||
</ul>
|
||||
|
||||
<H2><a name="MzScheme_external_docs">30.3 External documentation</a></H2>
|
||||
<H2><a name="MzScheme_external_docs">38.3 External documentation</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
See the <a href="http://docs.racket-lang.org/inside/index.html">C API</a> for more description of using the mechanism for adding extensions. The main documentation is <a href="http://docs.racket-lang.org/">here</a>.
|
||||
See the <a href="https://docs.racket-lang.org/inside/index.html">C API</a> for more description of using the mechanism for adding extensions. The main documentation is <a href="https://docs.racket-lang.org/">here</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Ocaml">31 SWIG and Ocaml</a></H1>
|
||||
<H1><a name="Ocaml">39 SWIG and OCaml</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -47,12 +47,16 @@
|
|||
<li><a href="#Ocaml_nn25">Director Usage Example</a>
|
||||
<li><a href="#Ocaml_nn26">Creating director objects</a>
|
||||
<li><a href="#Ocaml_nn27">Typemaps for directors, directorin, directorout, directorargout</a>
|
||||
<li><a href="#Ocaml_nn28">typemap</a>
|
||||
<li><a href="#Ocaml_nn28">directorin typemap</a>
|
||||
<li><a href="#Ocaml_nn29">directorout typemap</a>
|
||||
<li><a href="#Ocaml_nn30">directorargout typemap</a>
|
||||
</ul>
|
||||
<li><a href="#Ocaml_nn31">Exceptions</a>
|
||||
</ul>
|
||||
<li><a href="#Ocaml_nn32">Documentation Features</a>
|
||||
<ul>
|
||||
<li><a href="#Ocaml_nn33">Module docstring</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -84,11 +88,11 @@ If you're not familiar with the Objective Caml language, you can visit
|
|||
<a href="http://ocaml.org/">The Ocaml Website</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn2">31.1 Preliminaries</a></H2>
|
||||
<H2><a name="Ocaml_nn2">39.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG 3.0 works with Ocaml 3.08.3 and above. Given the choice,
|
||||
SWIG is compatible with OCaml 3.12.0 and above. Given the choice,
|
||||
you should use the latest stable release. The SWIG Ocaml module has
|
||||
been tested on Linux (x86, PPC, Sparc) and Cygwin on Windows. The
|
||||
best way to determine whether your system will work is to compile the
|
||||
|
|
@ -102,7 +106,7 @@ file Examples/Makefile illustrate how to compile and link SWIG modules that
|
|||
will be loaded dynamically. This has only been tested on Linux so far.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn3">31.1.1 Running SWIG</a></H3>
|
||||
<H3><a name="Ocaml_nn3">39.1.1 Running SWIG</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -125,7 +129,7 @@ you will compile the file <tt>example_wrap.c</tt> with <tt>ocamlc</tt> or
|
|||
the resulting .ml and .mli files as well, and do the final link with -custom
|
||||
(not needed for native link).</p>
|
||||
|
||||
<H3><a name="Ocaml_nn4">31.1.2 Compiling the code</a></H3>
|
||||
<H3><a name="Ocaml_nn4">39.1.2 Compiling the code</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -142,7 +146,7 @@ Use <tt>ocamlc</tt> or <tt>ocamlopt</tt> to compile your SWIG interface like:
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
% swig -ocaml -co swig.mli ; swig -ocaml co swig.ml
|
||||
% swig -ocaml -co swig.mli ; swig -ocaml -co swig.ml
|
||||
% ocamlc -c swig.mli ; ocamlc -c swig.ml
|
||||
% ocamlc -c -ccopt "-I/usr/include/foo" example_wrap.c
|
||||
% ocamlc -c example.mli
|
||||
|
|
@ -162,7 +166,7 @@ in C++ mode, you must:</p>
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ocaml_nn5">31.1.3 The camlp4 module</a></H3>
|
||||
<H3><a name="Ocaml_nn5">39.1.3 The camlp4 module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -238,7 +242,7 @@ let b = C_string (getenv "PATH")
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn6">31.1.4 Using your module</a></H3>
|
||||
<H3><a name="Ocaml_nn6">39.1.4 Using your module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -252,7 +256,7 @@ option to build your functions into the primitive list. This
|
|||
option is not needed when you build native code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn7">31.1.5 Compilation problems and compiling with C++</a></H3>
|
||||
<H3><a name="Ocaml_nn7">39.1.5 Compilation problems and compiling with C++</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -263,7 +267,7 @@ liberal with pointer types may not compile under the C++ compiler.
|
|||
Most code meant to be compiled as C++ will not have problems.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn8">31.2 The low-level Ocaml/C interface</a></H2>
|
||||
<H2><a name="Ocaml_nn8">39.2 The low-level Ocaml/C interface</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -336,7 +340,7 @@ appended. Upon return to caml space, the fnhelper function
|
|||
beautifies the result. A list containing a single item degrades to
|
||||
only that item (i.e. [ C_int 3 ] -> C_int 3), and a list
|
||||
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
|
||||
when functions have only one return value, such as constructors,
|
||||
and operators. In addition, string, pointer, and object
|
||||
|
|
@ -363,7 +367,7 @@ value items pass through directly, but you must make your own type
|
|||
signature for a function that uses value in this way.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn9">31.2.1 The generated module</a></H3>
|
||||
<H3><a name="Ocaml_nn9">39.2.1 The generated module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -397,7 +401,7 @@ it describes the output SWIG will generate for class definitions.
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn10">31.2.2 Enums</a></H3>
|
||||
<H3><a name="Ocaml_nn10">39.2.2 Enums</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -460,7 +464,7 @@ val x : Enum_test.c_obj = C_enum `a
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ocaml_nn11">31.2.2.1 Enum typing in Ocaml</a></H4>
|
||||
<H4><a name="Ocaml_nn11">39.2.2.1 Enum typing in Ocaml</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -473,10 +477,10 @@ functions imported from different modules. You must convert values to master
|
|||
values using the swig_val function before sharing them with another module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn12">31.2.3 Arrays</a></H3>
|
||||
<H3><a name="Ocaml_nn12">39.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">39.2.3.1 Simple types of bounded arrays</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -497,7 +501,7 @@ arrays of simple types with known bounds in your code, but this only works
|
|||
for arrays whose bounds are completely specified.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn14">31.2.3.2 Complex and unbounded arrays</a></H4>
|
||||
<H4><a name="Ocaml_nn14">39.2.3.2 Complex and unbounded arrays</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -510,7 +514,7 @@ SWIG can't predict which of these methods will be used in the array,
|
|||
so you have to specify it for yourself in the form of a typemap.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn15">31.2.3.3 Using an object</a></H4>
|
||||
<H4><a name="Ocaml_nn15">39.2.3.3 Using an object</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -524,7 +528,7 @@ Consider writing an object when the ending condition of your array is complex,
|
|||
such as using a required sentinel, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn16">31.2.3.4 Example typemap for a function taking float * and int</a></H4>
|
||||
<H4><a name="Ocaml_nn16">39.2.3.4 Example typemap for a function taking float * and int</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -575,7 +579,7 @@ void printfloats( float *tab, int len );
|
|||
</pre></td></tr></table>
|
||||
|
||||
|
||||
<H3><a name="Ocaml_nn17">31.2.4 C++ Classes</a></H3>
|
||||
<H3><a name="Ocaml_nn17">39.2.4 C++ Classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -618,7 +622,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the
|
|||
returned value for the same object.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn18">31.2.4.1 STL vector and string Example</a></H4>
|
||||
<H4><a name="Ocaml_nn18">39.2.4.1 STL vector and string Example</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -660,7 +664,7 @@ module.
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
bash-2.05a$ ./example_top
|
||||
bash-2.05a$ ./runme_top
|
||||
Objective Caml version 3.06
|
||||
|
||||
Camlp4 Parsing version 3.06
|
||||
|
|
@ -698,7 +702,7 @@ baz
|
|||
#
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn19">31.2.4.2 C++ Class Example</a></H4>
|
||||
<H4><a name="Ocaml_nn19">39.2.4.2 C++ Class Example</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -728,7 +732,7 @@ public:
|
|||
};
|
||||
</pre></td></tr></table>
|
||||
|
||||
<H4><a name="Ocaml_nn20">31.2.4.3 Compiling the example</a></H4>
|
||||
<H4><a name="Ocaml_nn20">39.2.4.3 Compiling the example</a></H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -746,7 +750,7 @@ bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
|
|||
-L$QTPATH/lib -cclib -lqt
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn21">31.2.4.4 Sample Session</a></H4>
|
||||
<H4><a name="Ocaml_nn21">39.2.4.4 Sample Session</a></H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -773,10 +777,10 @@ Assuming you have a working installation of QT, you will see a window
|
|||
containing the string "hi" in a button.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn22">31.2.5 Director Classes</a></H3>
|
||||
<H3><a name="Ocaml_nn22">39.2.5 Director Classes</a></H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn23">31.2.5.1 Director Introduction</a></H4>
|
||||
<H4><a name="Ocaml_nn23">39.2.5.1 Director Introduction</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -803,7 +807,7 @@ class foo {
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn24">31.2.5.2 Overriding Methods in Ocaml</a></H4>
|
||||
<H4><a name="Ocaml_nn24">39.2.5.2 Overriding Methods in Ocaml</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -831,11 +835,11 @@ In this example, I'll examine the objective caml code involved in providing
|
|||
an overloaded class. This example is contained in Examples/ocaml/shapes.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn25">31.2.5.3 Director Usage Example</a></H4>
|
||||
<H4><a name="Ocaml_nn25">39.2.5.3 Director Usage Example</a></H4>
|
||||
|
||||
|
||||
<table border="1" bgcolor="#dddddd" summary="Director usage example">
|
||||
<tr><th><center>example_prog.ml</center>
|
||||
<tr><th><center>runme.ml</center>
|
||||
</th></tr>
|
||||
<tr><td><pre>
|
||||
open Swig
|
||||
|
|
@ -854,13 +858,15 @@ let triangle_class pts ob meth args =
|
|||
| _ -> raise (Failure "cover needs two double arguments."))
|
||||
| _ -> (invoke ob) meth args ;;
|
||||
|
||||
...
|
||||
|
||||
let triangle =
|
||||
new_derived_object
|
||||
new_shape
|
||||
(triangle_class ((0.0, 0.0), (0.5, 1.0), (1.0, 0.0)))
|
||||
(triangle_class ((0.0, 0.0), (0.5, 1.0), (1.0, 0.6)))
|
||||
'() ;;
|
||||
|
||||
let _ = _draw_shape_coverage '(triangle, C_int 60, C_int 20) ;;
|
||||
let _ = _draw_shape_coverage '(triangle, 60, 20) ;;
|
||||
</pre></td></tr>
|
||||
</table>
|
||||
|
||||
|
|
@ -890,7 +896,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the
|
|||
program in C++.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn26">31.2.5.4 Creating director objects</a></H4>
|
||||
<H4><a name="Ocaml_nn26">39.2.5.4 Creating director objects</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -931,7 +937,7 @@ object from causing a core dump, as long as the object is destroyed
|
|||
properly.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn27">31.2.5.5 Typemaps for directors, directorin, directorout, directorargout</a></H4>
|
||||
<H4><a name="Ocaml_nn27">39.2.5.5 Typemaps for directors, directorin, directorout, directorargout</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -942,7 +948,7 @@ well as a function return value in the same way you provide function arguments,
|
|||
and to receive arguments the same way you normally receive function returns.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn28">31.2.5.6 typemap</a></H4>
|
||||
<H4><a name="Ocaml_nn28">39.2.5.6 directorin typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -953,7 +959,7 @@ code receives when you are called. In general, a simple <tt>directorin</tt> typ
|
|||
can use the same body as a simple <tt>out</tt> typemap.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn29">31.2.5.7 directorout typemap</a></H4>
|
||||
<H4><a name="Ocaml_nn29">39.2.5.7 directorout typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -964,7 +970,7 @@ for the same type, except when there are special requirements for object
|
|||
ownership, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn30">31.2.5.8 directorargout typemap</a></H4>
|
||||
<H4><a name="Ocaml_nn30">39.2.5.8 directorargout typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -981,14 +987,134 @@ In the event that you don't specify all of the necessary values, integral
|
|||
values will read zero, and struct or object returns have undefined results.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn31">31.2.6 Exceptions</a></H3>
|
||||
<H3><a name="Ocaml_nn31">39.2.6 Exceptions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
Catching exceptions is now supported using SWIG's %exception feature. A simple
|
||||
but not too useful example is provided by the throw_exception testcase in
|
||||
Examples/test-suite. You can provide your own exceptions, too.
|
||||
If an error occurs in a C or C++ function, you may want to convert that error into an OCaml
|
||||
exception. To do this, you can use the <tt>%exception</tt> directive. The <tt>%exception</tt>
|
||||
directive simply lets you rewrite part of the generated wrapper code to include an error check.
|
||||
It is detailed in full in the <a href="Customization.html#Customization_exception">Exception handling with %exception</a> section.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In C, a function often indicates an error by returning a status code (e.g. a negative number
|
||||
or a NULL pointer). Here is a simple example of how you might handle that:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%exception malloc {
|
||||
$action
|
||||
if (result == NULL) {
|
||||
caml_failwith("Not enough memory");
|
||||
}
|
||||
}
|
||||
void *malloc(size_t nbytes);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In OCaml:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
# let a = _malloc (C_int 20000000000);;
|
||||
Exception: Failure "Not enough memory".
|
||||
#
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
If a library provides some kind of general error handling framework, you can also use
|
||||
that. For example:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%exception {
|
||||
$action
|
||||
if (err_occurred()) {
|
||||
caml_failwith(err_message());
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
If no declaration name is given to <tt>%exception</tt>, it is applied to all wrapper functions.
|
||||
<tt>$action</tt> is a SWIG special variable and is replaced by the C/C++ function call being wrapped.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
C++ exceptions are also easy to handle. We can catch a C++ exception and rethrow it as
|
||||
an OCaml exception like this:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%exception getitem {
|
||||
try {
|
||||
$action
|
||||
} catch (std::out_of_range &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">39.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">39.3.1 Module docstring</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
The first documentation comment of an <tt>mli</tt> file is the comment
|
||||
associated with the entire module. SWIG supports this by setting an
|
||||
option of the <tt>%module</tt> directive. For example:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%module(docstring="This is the example module's docstring") example
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
When you have more than just a line or so, you can retain the
|
||||
readability of the <tt>%module</tt> directive by using a macro. For
|
||||
example:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%define DOCSTRING
|
||||
"The `XmlResource` class allows program resources defining menus,
|
||||
controls on a panel, etc. to be loaded from an XML file."
|
||||
%enddef
|
||||
|
||||
%module(docstring=DOCSTRING) xrc
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Octave">32 SWIG and Octave</a></H1>
|
||||
<H1><a name="Octave">30 SWIG and Octave</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -60,16 +60,23 @@ This chapter is intended to give an introduction to using the module. You should
|
|||
Also, there are a dozen or so examples in the Examples/octave directory, and hundreds in the test suite (Examples/test-suite and Examples/test-suite/octave).
|
||||
</p>
|
||||
|
||||
<H2><a name="Octave_nn2">32.1 Preliminaries</a></H2>
|
||||
<H2><a name="Octave_nn2">30.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
As of SWIG 3.0.7, the Octave module is regularly tested with Octave versions 3.2.4, 3.8.1, and 4.0.0.
|
||||
Use of older Octave versions is not recommended, as these versions are no longer tested with SWIG.
|
||||
SWIG is regularly tested against the following versions of Octave: 3.8, 4.0, 4.2.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Every effort is made to maintain backward compatibility with older versions of Octave.
|
||||
This cannot be guaranteed however, as in recent times new Octave releases have required nontrivial updates to SWIG, which may break backward compatibility for older Octave versions against which SWIG is not regularly tested.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The SWIG runtime exports the function <tt>swig_octave_prereq()</tt> for checking the version of Octave.
|
||||
</p>
|
||||
|
||||
<H2><a name="Octave_nn3">32.2 Running SWIG</a></H2>
|
||||
<H2><a name="Octave_nn3">30.2 Running SWIG</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -101,7 +108,7 @@ The <tt>-c++</tt> option is also required when wrapping C++ code:
|
|||
This creates a C++ source file "example_wrap.cpp". A C++ file is generated even when wrapping C code as Octave is itself written in C++ and requires wrapper code to be in the same language. The generated C++ source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application (in this case, the gcd implementation) to create an extension module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn4">32.2.1 Command-line options</a></H3>
|
||||
<H3><a name="Octave_nn4">30.2.1 Command-line options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -124,7 +131,7 @@ The special name "." loads C global variables into the module namespace, i.e. al
|
|||
The <em>-opprefix</em> options sets the prefix of the names of global/friend <a href="#Octave_nn18">operator</a> functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn5">32.2.2 Compiling a dynamic module</a></H3>
|
||||
<H3><a name="Octave_nn5">30.2.2 Compiling a dynamic module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -151,7 +158,7 @@ $ mkoctfile example_wrap.cpp example.c
|
|||
|
||||
<div class="targetlang"><pre>octave:1> swigexample</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn6">32.2.3 Using your module</a></H3>
|
||||
<H3><a name="Octave_nn6">30.2.3 Using your module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -169,10 +176,10 @@ octave:4> swigexample.cvar.Foo=4;
|
|||
octave:5> swigexample.cvar.Foo
|
||||
ans = 4 </pre></div>
|
||||
|
||||
<H2><a name="Octave_nn7">32.3 A tour of basic C/C++ wrapping</a></H2>
|
||||
<H2><a name="Octave_nn7">30.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">30.3.1 Modules</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -217,7 +224,7 @@ octave:4> swigexample.gcd(4, 6)
|
|||
ans = 2
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn9">32.3.2 Functions</a></H3>
|
||||
<H3><a name="Octave_nn9">30.3.2 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -234,7 +241,7 @@ int fact(int n); </pre></div>
|
|||
<div class="targetlang"><pre>octave:1> swigexample.fact(4)
|
||||
24 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn10">32.3.3 Global variables</a></H3>
|
||||
<H3><a name="Octave_nn10">30.3.3 Global variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -287,7 +294,7 @@ octave:2> swigexample.PI=3.142;
|
|||
octave:3> swigexample.PI
|
||||
ans = 3.1420 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn11">32.3.4 Constants and enums</a></H3>
|
||||
<H3><a name="Octave_nn11">30.3.4 Constants and enums</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -309,7 +316,7 @@ swigexample.SCONST="Hello World"
|
|||
swigexample.SUNDAY=0
|
||||
.... </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn12">32.3.5 Pointers</a></H3>
|
||||
<H3><a name="Octave_nn12">30.3.5 Pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -356,7 +363,7 @@ octave:2> f=swigexample.fopen("not there", "r");
|
|||
error: value on right hand side of assignment is undefined
|
||||
error: evaluating assignment expression near line 2, column 2 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn13">32.3.6 Structures and C++ classes</a></H3>
|
||||
<H3><a name="Octave_nn13">30.3.6 Structures and C++ classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -491,7 +498,7 @@ ans = 1
|
|||
Depending on the ownership setting of a <tt>swig_ref</tt>, it may call C++ destructors when its reference count goes to zero. See the section on memory management below for details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn15">32.3.7 C++ inheritance</a></H3>
|
||||
<H3><a name="Octave_nn15">30.3.7 C++ inheritance</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -500,7 +507,7 @@ This information contains the full class hierarchy. When an indexing operation (
|
|||
the tree is walked to find a match in the current class as well as any of its bases. The lookup is then cached in the <tt>swig_ref</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn17">32.3.8 C++ overloaded functions</a></H3>
|
||||
<H3><a name="Octave_nn17">30.3.8 C++ overloaded functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -510,7 +517,7 @@ The dispatch function selects which overload to call (if any) based on the passe
|
|||
<tt>typecheck</tt> typemaps are used to analyze each argument, as well as assign precedence. See the chapter on typemaps for details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn18">32.3.9 C++ operators</a></H3>
|
||||
<H3><a name="Octave_nn18">30.3.9 C++ operators</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -614,7 +621,7 @@ On the C++ side, the default mappings are as follows:
|
|||
Octave can also utilise friend (i.e. non-member) operators with a simple %rename: see the example in the Examples/octave/operator directory.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn19">32.3.10 Class extension with %extend</a></H3>
|
||||
<H3><a name="Octave_nn19">30.3.10 Class extension with %extend</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -653,7 +660,7 @@ Similarly, Octave can use the <tt>__float__</tt> method to convert an object to
|
|||
Octave 3.8.0 and later versions will also map unary functions X() to the corresponding <tt>__X__</tt> method, where X includes: abs(), acos(), acosh(), angle(), arg(), asin(), asinh(), atan(), atanh(), cbrt(), ceil(), conj(), cos(), cosh(), dawson(), erf(), erfc(), erfcinv(), erfcx(), erfi(), erfinv(), exp(), expm1(), finite(), fix(), floor(), gamma(), imag(), isalnum(), isalpha(), isascii(), iscntrl(), isdigit(), isgraph(), isinf(), islower(), isna(), isnan(), isprint(), ispunct(), isspace(), isupper(), isxdigit(), lgamma(), log(), log10(), log1p(), log2(), real(), round(), roundb(), signbit(), signum(), sin(), sinh(), sqrt(), tan(), tanh(), toascii(), tolower(), toupper()
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn20">32.3.11 C++ templates</a></H3>
|
||||
<H3><a name="Octave_nn20">30.3.11 C++ templates</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -730,10 +737,10 @@ ans =
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Octave_nn21">32.3.12 C++ Smart Pointers</a></H3>
|
||||
<H3><a name="Octave_nn21">30.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">30.3.12.1 The shared_ptr Smart Pointer</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -744,14 +751,14 @@ in the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Octave_smart_pointers_generic">32.3.12.2 Generic Smart Pointers</a></H4>
|
||||
<H4><a name="Octave_smart_pointers_generic">30.3.12.2 Generic Smart Pointers</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
C++ smart pointers are fully supported as in other modules.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn22">32.3.13 Directors (calling Octave from C++ code)</a></H3>
|
||||
<H3><a name="Octave_nn22">30.3.13 Directors (calling Octave from C++ code)</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -832,14 +839,14 @@ c-side routine called
|
|||
octave-side routine called
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn23">32.3.14 Threads</a></H3>
|
||||
<H3><a name="Octave_nn23">30.3.14 Threads</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
The use of threads in wrapped Director code is not supported; i.e., an Octave-side implementation of a C++ class must be called from the Octave interpreter's thread. Anything fancier (apartment/queue model, whatever) is left to the user. Without anything fancier, this amounts to the limitation that Octave must drive the module... like, for example, an optimization package that calls Octave to evaluate an objective function.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn24">32.3.15 Memory management</a></H3>
|
||||
<H3><a name="Octave_nn24">30.3.15 Memory management</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -873,14 +880,14 @@ The %newobject directive may be used to control this behavior for pointers retur
|
|||
In the case where one wishes for the C++ side to own an object that was created in Octave (especially a Director object), one can use the __disown() method to invert this logic. Then letting the Octave reference count go to zero will not destroy the object, but destroying the object will invalidate the Octave-side object if it still exists (and call destructors of other C++ bases in the case of multiple inheritance/<tt>subclass()</tt>'ing).
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn25">32.3.16 STL support</a></H3>
|
||||
<H3><a name="Octave_nn25">30.3.16 STL support</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
Various STL library files are provided for wrapping STL containers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn26">32.3.17 Matrix typemaps</a></H3>
|
||||
<H3><a name="Octave_nn26">30.3.17 Matrix typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Perl5">33 SWIG and Perl5</a></H1>
|
||||
<H1><a name="Perl5">31 SWIG and Perl5</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -97,7 +97,7 @@ later. We're no longer testing regularly with older versions, but
|
|||
Perl 5.6 seems to mostly work, while older versions don't.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn2">33.1 Overview</a></H2>
|
||||
<H2><a name="Perl5_nn2">31.1 Overview</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -118,11 +118,11 @@ described. Advanced customization features, typemaps, and other
|
|||
options are found near the end of the chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn3">33.2 Preliminaries</a></H2>
|
||||
<H2><a name="Perl5_nn3">31.2 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
To build a Perl5 module, run SWIG using the <tt>-perl</tt> option as
|
||||
To build a Perl5 module, run SWIG using the <tt>-perl</tt> or <tt>-perl5</tt> option as
|
||||
follows:
|
||||
</p>
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ To build the module, you will need to compile the file
|
|||
<tt>example_wrap.c</tt> and link it with the rest of your program.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn4">33.2.1 Getting the right header files</a></H3>
|
||||
<H3><a name="Perl5_nn4">31.2.1 Getting the right header files</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -175,7 +175,7 @@ $ perl -e 'use Config; print "$Config{archlib}\n";'
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn5">33.2.2 Compiling a dynamic module</a></H3>
|
||||
<H3><a name="Perl5_nn5">31.2.2 Compiling a dynamic module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -208,7 +208,7 @@ the target should be named `<tt>example.so</tt>',
|
|||
`<tt>example.sl</tt>', or the appropriate dynamic module name on your system.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn6">33.2.3 Building a dynamic module with MakeMaker</a></H3>
|
||||
<H3><a name="Perl5_nn6">31.2.3 Building a dynamic module with MakeMaker</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -242,7 +242,7 @@ the preferred approach to compilation. More information about MakeMaker can be
|
|||
found in "Programming Perl, 2nd ed." by Larry Wall, Tom Christiansen,
|
||||
and Randal Schwartz.</p>
|
||||
|
||||
<H3><a name="Perl5_nn7">33.2.4 Building a static version of Perl</a></H3>
|
||||
<H3><a name="Perl5_nn7">31.2.4 Building a static version of Perl</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -311,7 +311,7 @@ added to it. Depending on your machine, you may need to link with
|
|||
additional libraries such as <tt>-lsocket, -lnsl, -ldl</tt>, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn8">33.2.5 Using the module</a></H3>
|
||||
<H3><a name="Perl5_nn8">31.2.5 Using the module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -464,7 +464,7 @@ system configuration (this requires root access and you will need to
|
|||
read the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn9">33.2.6 Compilation problems and compiling with C++</a></H3>
|
||||
<H3><a name="Perl5_nn9">31.2.6 Compilation problems and compiling with C++</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -607,7 +607,7 @@ have to find the macro that conflicts and add an #undef into the .i file. Pleas
|
|||
any conflicting macros you find to <a href="http://www.swig.org/mail.html">swig-user mailing list</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn10">33.2.7 Compiling for 64-bit platforms</a></H3>
|
||||
<H3><a name="Perl5_nn10">31.2.7 Compiling for 64-bit platforms</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -634,7 +634,7 @@ also introduce problems on platforms that support more than one
|
|||
linking standard (e.g., -o32 and -n32 on Irix).
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn11">33.3 Building Perl Extensions under Windows</a></H2>
|
||||
<H2><a name="Perl5_nn11">31.3 Building Perl Extensions under Windows</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -645,7 +645,7 @@ section assumes you are using SWIG with Microsoft Visual C++
|
|||
although the procedure may be similar with other compilers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn12">33.3.1 Running SWIG from Developer Studio</a></H3>
|
||||
<H3><a name="Perl5_nn12">31.3.1 Running SWIG from Developer Studio</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -708,7 +708,7 @@ print "$a\n";
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn13">33.3.2 Using other compilers</a></H3>
|
||||
<H3><a name="Perl5_nn13">31.3.2 Using other compilers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -716,7 +716,7 @@ SWIG is known to work with Cygwin and may work with other compilers on Windows.
|
|||
For general hints and suggestions refer to the <a href="Windows.html#Windows">Windows</a> chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn14">33.4 The low-level interface</a></H2>
|
||||
<H2><a name="Perl5_nn14">31.4 The low-level interface</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -726,7 +726,7 @@ can be used to control your application. However, it is also used to
|
|||
construct more user-friendly proxy classes as described in the next section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn15">33.4.1 Functions</a></H3>
|
||||
<H3><a name="Perl5_nn15">31.4.1 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -749,7 +749,7 @@ use example;
|
|||
$a = &example::fact(2);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn16">33.4.2 Global variables</a></H3>
|
||||
<H3><a name="Perl5_nn16">31.4.2 Global variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -819,7 +819,7 @@ extern char *path; // Declared later in the input
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn17">33.4.3 Constants</a></H3>
|
||||
<H3><a name="Perl5_nn17">31.4.3 Constants</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -859,7 +859,7 @@ print example::FOO, "\n";
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn18">33.4.4 Pointers</a></H3>
|
||||
<H3><a name="Perl5_nn18">31.4.4 Pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -949,7 +949,7 @@ Foo *BarToFoo(Bar *b) {
|
|||
}
|
||||
|
||||
Foo *IncrFoo(Foo *f, int i) {
|
||||
return f+i;
|
||||
return f+i;
|
||||
}
|
||||
%}
|
||||
</pre>
|
||||
|
|
@ -968,7 +968,7 @@ as XS and <tt>xsubpp</tt>. Given the advancement of the SWIG typesystem and the
|
|||
SWIG and XS, this is no longer supported.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn19">33.4.5 Structures</a></H3>
|
||||
<H3><a name="Perl5_nn19">31.4.5 Structures</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1057,7 +1057,7 @@ produces a single accessor function like this:
|
|||
<div class="code">
|
||||
<pre>
|
||||
int *Foo_x_get(Foo *self) {
|
||||
return self->x;
|
||||
return self->x;
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1092,17 +1092,17 @@ generates accessor functions such as this:
|
|||
<div class="code">
|
||||
<pre>
|
||||
Foo *Bar_f_get(Bar *b) {
|
||||
return &b->f;
|
||||
return &b->f;
|
||||
}
|
||||
|
||||
void Bar_f_set(Bar *b, Foo *val) {
|
||||
b->f = *val;
|
||||
b->f = *val;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn20">33.4.6 C++ classes</a></H3>
|
||||
<H3><a name="Perl5_nn20">31.4.6 C++ classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1167,7 +1167,7 @@ provides direct access to C++ objects. A higher level interface using Perl prox
|
|||
can be built using these low-level accessors. This is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn21">33.4.7 C++ classes and type-checking</a></H3>
|
||||
<H3><a name="Perl5_nn21">31.4.7 C++ classes and type-checking</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1203,7 +1203,7 @@ If necessary, the type-checker also adjusts the value of the pointer (as is nece
|
|||
multiple inheritance is used).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn22">33.4.8 C++ overloaded functions</a></H3>
|
||||
<H3><a name="Perl5_nn22">31.4.8 C++ overloaded functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1247,7 +1247,7 @@ example::Spam_foo_d($s, 3.14);
|
|||
Please refer to the "SWIG Basics" chapter for more information.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn23">33.4.9 Operators</a></H3>
|
||||
<H3><a name="Perl5_nn23">31.4.9 Operators</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1274,7 +1274,7 @@ The following C++ operators are currently supported by the Perl module:
|
|||
<li>operator or </li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Perl5_nn24">33.4.10 Modules and packages</a></H3>
|
||||
<H3><a name="Perl5_nn24">31.4.10 Modules and packages</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1369,7 +1369,7 @@ print Foo::fact(4), "\n"; # Call a function in package FooBar
|
|||
</pre></div>
|
||||
-->
|
||||
|
||||
<H2><a name="Perl5_nn25">33.5 Input and output parameters</a></H2>
|
||||
<H2><a name="Perl5_nn25">31.5 Input and output parameters</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1588,7 +1588,7 @@ print "$c\n";
|
|||
<b>Note:</b> The <tt>REFERENCE</tt> feature is only currently supported for numeric types (integers and floating point).
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn26">33.6 Exception handling</a></H2>
|
||||
<H2><a name="Perl5_nn26">31.6 Exception handling</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1633,9 +1633,8 @@ class DoubleArray {
|
|||
void setitem(int i, double val) {
|
||||
if ((i >= 0) && (i < n))
|
||||
ptr[i] = val;
|
||||
else {
|
||||
else
|
||||
throw RangeError();
|
||||
}
|
||||
}
|
||||
};
|
||||
</pre></div>
|
||||
|
|
@ -1753,7 +1752,7 @@ This is still supported, but it is deprecated. The newer <tt>%exception</tt> di
|
|||
functionality, but it has additional capabilities that make it more powerful.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn27">33.7 Remapping datatypes with typemaps</a></H2>
|
||||
<H2><a name="Perl5_nn27">31.7 Remapping datatypes with typemaps</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1770,7 +1769,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Perl interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn28">33.7.1 A simple typemap example</a></H3>
|
||||
<H3><a name="Perl5_nn28">31.7.1 A simple typemap example</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1874,7 +1873,7 @@ example::count("e", "Hello World");
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn29">33.7.2 Perl5 typemaps</a></H3>
|
||||
<H3><a name="Perl5_nn29">31.7.2 Perl5 typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1888,9 +1887,9 @@ like this:
|
|||
<div class="targetlang">
|
||||
<pre>
|
||||
%typemap(out) int {
|
||||
$result = sv_newmortal();
|
||||
set_setiv($result, (IV) $1);
|
||||
argvi++;
|
||||
$result = sv_newmortal();
|
||||
sv_setiv($result, (IV) $1);
|
||||
argvi++;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1979,7 +1978,7 @@ Return of C++ member data (all languages).
|
|||
Check value of input parameter.
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn30">33.7.3 Typemap variables</a></H3>
|
||||
<H3><a name="Perl5_nn30">31.7.3 Typemap variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2050,7 +2049,7 @@ properly assigned.
|
|||
The Perl name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn31">33.7.4 Useful functions</a></H3>
|
||||
<H3><a name="Perl5_nn31">31.7.4 Useful functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2119,7 +2118,7 @@ int sv_isa(SV *, char *0;
|
|||
</div>
|
||||
|
||||
|
||||
<H2><a name="Perl5_nn32">33.8 Typemap Examples</a></H2>
|
||||
<H2><a name="Perl5_nn32">31.8 Typemap Examples</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2128,7 +2127,7 @@ might look at the files "<tt>perl5.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn33">33.8.1 Converting a Perl5 array to a char **</a></H3>
|
||||
<H3><a name="Perl5_nn33">31.8.1 Converting a Perl5 array to a char **</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2220,7 +2219,7 @@ print @$b, "\n"; # Print it out
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn34">33.8.2 Return values</a></H3>
|
||||
<H3><a name="Perl5_nn34">31.8.2 Return values</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2249,7 +2248,7 @@ can be done using the <tt>EXTEND()</tt> macro as in:
|
|||
}
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn35">33.8.3 Returning values from arguments</a></H3>
|
||||
<H3><a name="Perl5_nn35">31.8.3 Returning values from arguments</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2303,7 +2302,7 @@ print "multout(7, 13) = @r\n";
|
|||
($x, $y) = multout(7, 13);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn36">33.8.4 Accessing array structure members</a></H3>
|
||||
<H3><a name="Perl5_nn36">31.8.4 Accessing array structure members</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2313,8 +2312,8 @@ Consider the following data structure:
|
|||
<div class="code"><pre>
|
||||
#define SIZE 8
|
||||
typedef struct {
|
||||
int values[SIZE];
|
||||
...
|
||||
int values[SIZE];
|
||||
...
|
||||
} Foo;
|
||||
|
||||
</pre></div>
|
||||
|
|
@ -2328,10 +2327,10 @@ To make the member writable, a "memberin" typemap can be used.
|
|||
|
||||
<div class="code"><pre>
|
||||
%typemap(memberin) int [SIZE] {
|
||||
int i;
|
||||
for (i = 0; i < SIZE; i++) {
|
||||
$1[i] = $input[i];
|
||||
}
|
||||
int i;
|
||||
for (i = 0; i < SIZE; i++) {
|
||||
$1[i] = $input[i];
|
||||
}
|
||||
}
|
||||
|
||||
</pre></div>
|
||||
|
|
@ -2366,7 +2365,7 @@ the "in" typemap in the previous section would be used to convert an
|
|||
to copy the converted array into a C data structure.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn37">33.8.5 Turning Perl references into C pointers</a></H3>
|
||||
<H3><a name="Perl5_nn37">31.8.5 Turning Perl references into C pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2431,7 +2430,7 @@ print "$c\n";
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn38">33.8.6 Pointer handling</a></H3>
|
||||
<H3><a name="Perl5_nn38">31.8.6 Pointer handling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2516,7 +2515,7 @@ For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Perl5_nn39">33.9 Proxy classes</a></H2>
|
||||
<H2><a name="Perl5_nn39">31.9 Proxy classes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2532,7 +2531,7 @@ to the underlying code. This section describes the implementation
|
|||
details of the proxy interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn40">33.9.1 Preliminaries</a></H3>
|
||||
<H3><a name="Perl5_nn40">31.9.1 Preliminaries</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2554,7 +2553,7 @@ SWIG creates a collection of high-level Perl wrappers. In your scripts, you wil
|
|||
high level wrappers. The wrappers, in turn, interact with the low-level procedural module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn41">33.9.2 Structure and class wrappers</a></H3>
|
||||
<H3><a name="Perl5_nn41">31.9.2 Structure and class wrappers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2600,48 +2599,48 @@ package example::Vector;
|
|||
%BLESSEDMEMBERS = ();
|
||||
|
||||
sub new () {
|
||||
my $self = shift;
|
||||
my @args = @_;
|
||||
$self = vectorc::new_Vector(@args);
|
||||
return undef if (!defined($self));
|
||||
bless $self, "example::Vector";
|
||||
$OWNER{$self} = 1;
|
||||
my %retval;
|
||||
tie %retval, "example::Vector", $self;
|
||||
return bless \%retval, "Vector";
|
||||
my $self = shift;
|
||||
my @args = @_;
|
||||
$self = vectorc::new_Vector(@args);
|
||||
return undef if (!defined($self));
|
||||
bless $self, "example::Vector";
|
||||
$OWNER{$self} = 1;
|
||||
my %retval;
|
||||
tie %retval, "example::Vector", $self;
|
||||
return bless \%retval, "Vector";
|
||||
}
|
||||
|
||||
sub DESTROY {
|
||||
return unless $_[0]->isa('HASH');
|
||||
my $self = tied(%{$_[0]});
|
||||
delete $ITERATORS{$self};
|
||||
if (exists $OWNER{$self}) {
|
||||
examplec::delete_Vector($self));
|
||||
delete $OWNER{$self};
|
||||
}
|
||||
return unless $_[0]->isa('HASH');
|
||||
my $self = tied(%{$_[0]});
|
||||
delete $ITERATORS{$self};
|
||||
if (exists $OWNER{$self}) {
|
||||
examplec::delete_Vector($self));
|
||||
delete $OWNER{$self};
|
||||
}
|
||||
}
|
||||
|
||||
sub FETCH {
|
||||
my ($self, $field) = @_;
|
||||
my $member_func = "vectorc::Vector_${field}_get";
|
||||
my $val = &$member_func($self);
|
||||
if (exists $BLESSEDMEMBERS{$field}) {
|
||||
return undef if (!defined($val));
|
||||
my %retval;
|
||||
tie %retval, $BLESSEDMEMBERS{$field}, $val;
|
||||
return bless \%retval, $BLESSEDMEMBERS{$field};
|
||||
}
|
||||
return $val;
|
||||
my ($self, $field) = @_;
|
||||
my $member_func = "vectorc::Vector_${field}_get";
|
||||
my $val = &$member_func($self);
|
||||
if (exists $BLESSEDMEMBERS{$field}) {
|
||||
return undef if (!defined($val));
|
||||
my %retval;
|
||||
tie %retval, $BLESSEDMEMBERS{$field}, $val;
|
||||
return bless \%retval, $BLESSEDMEMBERS{$field};
|
||||
}
|
||||
return $val;
|
||||
}
|
||||
|
||||
sub STORE {
|
||||
my ($self, $field, $newval) = @_;
|
||||
my $member_func = "vectorc::Vector_${field}_set";
|
||||
if (exists $BLESSEDMEMBERS{$field}) {
|
||||
&$member_func($self, tied(%{$newval}));
|
||||
} else {
|
||||
&$member_func($self, $newval);
|
||||
}
|
||||
my ($self, $field, $newval) = @_;
|
||||
my $member_func = "vectorc::Vector_${field}_set";
|
||||
if (exists $BLESSEDMEMBERS{$field}) {
|
||||
&$member_func($self, tied(%{$newval}));
|
||||
} else {
|
||||
&$member_func($self, $newval);
|
||||
}
|
||||
}
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -2681,7 +2680,7 @@ $v->DESTROY();
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn42">33.9.3 Object Ownership</a></H3>
|
||||
<H3><a name="Perl5_nn42">31.9.3 Object Ownership</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2768,7 +2767,7 @@ counting, garbage collection, or advanced features one might find in
|
|||
sophisticated languages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn43">33.9.4 Nested Objects</a></H3>
|
||||
<H3><a name="Perl5_nn43">31.9.4 Nested Objects</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2821,7 +2820,7 @@ $p->{f}->{x} = 0.0;
|
|||
%${$p->{v}} = ( x=>0, y=>0, z=>0);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn44">33.9.5 Proxy Functions</a></H3>
|
||||
<H3><a name="Perl5_nn44">31.9.5 Proxy Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2842,11 +2841,11 @@ this:
|
|||
|
||||
<div class="targetlang"><pre>
|
||||
sub dot_product {
|
||||
my @args = @_;
|
||||
$args[0] = tied(%{$args[0]}); # Get the real pointer values
|
||||
$args[1] = tied(%{$args[1]});
|
||||
my $result = vectorc::dot_product(@args);
|
||||
return $result;
|
||||
my @args = @_;
|
||||
$args[0] = tied(%{$args[0]}); # Get the real pointer values
|
||||
$args[1] = tied(%{$args[1]});
|
||||
my $result = vectorc::dot_product(@args);
|
||||
return $result;
|
||||
}
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -2855,7 +2854,7 @@ This function replaces the original function, but operates in an
|
|||
identical manner.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn45">33.9.6 Inheritance</a></H3>
|
||||
<H3><a name="Perl5_nn45">31.9.6 Inheritance</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2931,7 +2930,7 @@ particular, inheritance of data members is extremely tricky (and I'm
|
|||
not even sure if it really works).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn46">33.9.7 Modifying the proxy methods</a></H3>
|
||||
<H3><a name="Perl5_nn46">31.9.7 Modifying the proxy methods</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2959,7 +2958,7 @@ public:
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Perl5_nn47">33.10 Adding additional Perl code</a></H2>
|
||||
<H2><a name="Perl5_nn47">31.10 Adding additional Perl code</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2985,7 +2984,7 @@ sub set_transform
|
|||
for (my $j = 0; $j < 4, $j++)
|
||||
{
|
||||
mat44_set($a, $i, $j, $x->[i][j])
|
||||
}
|
||||
}
|
||||
}
|
||||
example.set_transform($im, $a);
|
||||
free_mat44($a);
|
||||
|
|
@ -3010,7 +3009,7 @@ set_transform($im, $a);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Perl5_directors">33.11 Cross language polymorphism</a></H2>
|
||||
<H2><a name="Perl5_directors">31.11 Cross language polymorphism</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3044,7 +3043,7 @@ proxy classes, director classes, and C wrapper functions takes care of
|
|||
all the cross-language method routing transparently.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn48">33.11.1 Enabling directors</a></H3>
|
||||
<H3><a name="Perl5_nn48">31.11.1 Enabling directors</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3071,7 +3070,7 @@ globally, to specific classes, and to specific methods, like this:
|
|||
// generate directors for all classes that have virtual methods
|
||||
%feature("director");
|
||||
|
||||
// generate directors for all virtual methods in class Foo
|
||||
// generate directors for the virtual methods in class Foo
|
||||
%feature("director") Foo;
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -3089,7 +3088,7 @@ directors for specific classes or methods. So for example,
|
|||
</div>
|
||||
|
||||
<p>
|
||||
will generate directors for all virtual methods of class Foo except
|
||||
will generate directors for the virtual methods of class Foo except
|
||||
bar().
|
||||
</p>
|
||||
|
||||
|
|
@ -3104,14 +3103,14 @@ the methods one() and two() (but not three()):
|
|||
%feature("director") Foo;
|
||||
class Foo {
|
||||
public:
|
||||
Foo(int foo);
|
||||
virtual void one();
|
||||
virtual void two();
|
||||
Foo(int foo);
|
||||
virtual void one();
|
||||
virtual void two();
|
||||
};
|
||||
|
||||
class Bar: public Foo {
|
||||
public:
|
||||
virtual void three();
|
||||
virtual void three();
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -3134,7 +3133,7 @@ sub one {
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn49">33.11.2 Director classes</a></H3>
|
||||
<H3><a name="Perl5_nn49">31.11.2 Director classes</a></H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -3154,7 +3153,8 @@ For simplicity let's ignore the <tt>Swig::Director</tt> class and refer to the
|
|||
original C++ class as the director's base class. By default, a director
|
||||
class extends all virtual methods in the inheritance chain of its base
|
||||
class (see the preceding section for how to modify this behavior).
|
||||
Thus all virtual method calls, whether they originate in C++ or in
|
||||
Virtual methods that have a final specifier are unsurprisingly excluded.
|
||||
Thus the virtual method calls, whether they originate in C++ or in
|
||||
Perl via proxy classes, eventually end up in at the implementation in
|
||||
the director class. The job of the director methods is to route these
|
||||
method calls to the appropriate place in the inheritance chain. By
|
||||
|
|
@ -3214,7 +3214,7 @@ so there is no need for the extra overhead involved with routing the
|
|||
calls through Perl.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn50">33.11.3 Ownership and object destruction</a></H3>
|
||||
<H3><a name="Perl5_nn50">31.11.3 Ownership and object destruction</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3263,7 +3263,7 @@ sub DESTROY {
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn51">33.11.4 Exception unrolling</a></H3>
|
||||
<H3><a name="Perl5_nn51">31.11.4 Exception unrolling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3279,9 +3279,9 @@ suffice in most cases:
|
|||
<div class="code">
|
||||
<pre>
|
||||
%feature("director:except") {
|
||||
if ($error != NULL) {
|
||||
throw Swig::DirectorMethodException();
|
||||
}
|
||||
if ($error != NULL) {
|
||||
throw Swig::DirectorMethodException();
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -3305,8 +3305,8 @@ suitable exception handler:
|
|||
<div class="code">
|
||||
<pre>
|
||||
%exception {
|
||||
try { $action }
|
||||
catch (Swig::DirectorException &e) { SWIG_fail; }
|
||||
try { $action }
|
||||
catch (Swig::DirectorException &e) { SWIG_fail; }
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -3319,7 +3319,7 @@ Swig::DirectorMethodException is thrown, Perl will register the
|
|||
exception as soon as the C wrapper function returns.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn52">33.11.5 Overhead and code bloat</a></H3>
|
||||
<H3><a name="Perl5_nn52">31.11.5 Overhead and code bloat</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3353,7 +3353,7 @@ directive) for only those methods that are likely to be extended in
|
|||
Perl.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn53">33.11.6 Typemaps</a></H3>
|
||||
<H3><a name="Perl5_nn53">31.11.6 Typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Php">34 SWIG and PHP</a></H1>
|
||||
<H1><a name="Php">32 SWIG and PHP</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -50,20 +50,13 @@
|
|||
|
||||
|
||||
<p>
|
||||
In this chapter, we discuss SWIG's support of PHP. The PHP module
|
||||
was extensively rewritten in release 1.3.26, and support for generating
|
||||
OO wrappers for PHP5 was added in 1.3.30. The PHP module now supports most
|
||||
of the features available in some of the other languages.
|
||||
In this chapter, we discuss SWIG's support of PHP. SWIG currently supports
|
||||
generating wrappers for PHP7. Support for PHP5 was removed in SWIG 4.0.0
|
||||
and support for PHP4 was removed in SWIG 1.3.37.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
SWIG supports generating wrappers for PHP5 and PHP7. Support for PHP4 was removed
|
||||
in SWIG 1.3.37.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Currently any PHP5 or PHP7 release should work, but we don't regularly test with
|
||||
PHP < 5.3.
|
||||
Currently any PHP7 release should work.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -77,13 +70,13 @@ your extension into php directly, you will need the complete PHP source tree
|
|||
available.
|
||||
</p>
|
||||
|
||||
<H2><a name="Php_nn1">34.1 Generating PHP Extensions</a></H2>
|
||||
<H2><a name="Php_nn1">32.1 Generating PHP Extensions</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
To build a PHP extension, run swig using the <tt>-php5</tt> or
|
||||
<tt>-php7</tt> option as follows (<tt>-php</tt> is also supported
|
||||
and currently is an alias for <tt>-php5</tt>):
|
||||
To build a PHP extension, run swig using the <tt>-php7</tt> option as follows
|
||||
(<tt>-php</tt> is also supported and currently is an alias for <tt>-php7</tt>
|
||||
but prior to SWIG 4.0.0 it was an alias for <tt>-php5</tt>):
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -107,9 +100,7 @@ also contain PHP class wrappers.
|
|||
SWIG can generate PHP extensions from C++ libraries as well when
|
||||
given the <tt>-c++</tt> option. The support for C++ is discussed in
|
||||
more detail in <a href="#Php_nn2_6">section 27.2.6</a>. The generated
|
||||
C++ wrapper will be called example_wrap.cpp (for PHP5) or
|
||||
example_wrap.cxx (for PHP7 where the default has been changed to align
|
||||
with SWIG's default for every other language). You can specify a
|
||||
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>
|
||||
|
|
@ -128,7 +119,7 @@ and it doesn't play nicely with package system. We don't recommend
|
|||
this approach, or provide explicit support for it.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn1_1">34.1.1 Building a loadable extension</a></H3>
|
||||
<H3><a name="Php_nn1_1">32.1.1 Building a loadable extension</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -143,7 +134,7 @@ least work for Linux though):
|
|||
gcc -shared example_wrap.o example.o -o example.so
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Php_nn1_3">34.1.2 Using PHP Extensions</a></H3>
|
||||
<H3><a name="Php_nn1_3">32.1.2 Using PHP Extensions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -162,8 +153,8 @@ If the module is in PHP's default extension directory, you can omit the path.
|
|||
|
||||
<p>
|
||||
For some SAPIs (for example, the CLI SAPI) you can instead use the
|
||||
<a href="http://php.net/manual/en/function.dl.php">dl() function</a> to load
|
||||
an extension at run time, by adding a like like this to the start of each
|
||||
<a href="https://www.php.net/manual/en/function.dl.php">dl() function</a> to load
|
||||
an extension at run time, by adding a line like this to the start of each
|
||||
PHP script which uses your extension:
|
||||
</p>
|
||||
|
||||
|
|
@ -172,8 +163,8 @@ PHP script which uses your extension:
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
But note that this doesn't work when running PHP through a webserver in PHP5.3
|
||||
and later - you'll need to use <tt>extension</tt> in <tt>php.ini</tt> as
|
||||
But note that <tt>dl()</tt> isn't supported when running PHP through a
|
||||
webserver - you'll need to use <tt>extension</tt> in <tt>php.ini</tt> as
|
||||
described above.
|
||||
</p>
|
||||
|
||||
|
|
@ -191,7 +182,7 @@ This PHP module also defines the PHP classes for the wrapped API, so you'll
|
|||
almost certainly want to include it anyway.
|
||||
</p>
|
||||
|
||||
<H2><a name="Php_nn2">34.2 Basic PHP interface</a></H2>
|
||||
<H2><a name="Php_nn2">32.2 Basic PHP interface</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -199,10 +190,11 @@ It is important to understand that PHP uses a single global namespace
|
|||
into which all symbols from extension modules are loaded. It is quite
|
||||
possible for names of symbols in one extension module to clash with
|
||||
other symbols unless care is taken to <tt>%rename</tt> them. At present
|
||||
SWIG doesn't have support for the namespace feature added in PHP 5.3.
|
||||
SWIG doesn't have support for generating wrappers which make use of PHP's
|
||||
namespace feature.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_1">34.2.1 Constants</a></H3>
|
||||
<H3><a name="Php_nn2_1">32.2.1 Constants</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -239,10 +231,12 @@ echo "E = " . E . "\n";
|
|||
<p>
|
||||
There's one peculiarity of how constants work in PHP which it is useful
|
||||
to note (this is not specific to SWIG though) - if you try to use an undeclared
|
||||
constant, PHP will emit a notice and then expand the constant to a string
|
||||
version of the constant's name. Unfortunately it is easy to miss the notice
|
||||
if you're using PHP in a webserver, as it will probably end up in error.log or
|
||||
similar.
|
||||
constant, PHP will emit a warning (or a notice in PHP 7.1 and earlier) and then
|
||||
expand the constant to a string version of the constant's name. Unfortunately
|
||||
it is easy to miss the warning message if you're using PHP in a webserver as
|
||||
it will probably end up in error.log or similar. Apparently this will throw
|
||||
an Error in a future version of PHP, but until then it's something to be
|
||||
aware of.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -276,11 +270,10 @@ if(EASY_TO_MISPEL) {
|
|||
<p>
|
||||
The mis-spelled constant will become the string 'EASY_TO_MISPEL', which
|
||||
is treated as true by the if test, when the value of the intended constant
|
||||
would be treated as false! Modern versions of PHP will at least issue
|
||||
a PHP notice by default when this happens.
|
||||
would be treated as false!
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_2">34.2.2 Global Variables</a></H3>
|
||||
<H3><a name="Php_nn2_2">32.2.2 Global Variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -329,7 +322,7 @@ undefined.
|
|||
At this time SWIG does not support custom accessor methods.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_3">34.2.3 Functions</a></H3>
|
||||
<H3><a name="Php_nn2_3">32.2.3 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -382,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">32.2.4 Overloading</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -390,8 +383,7 @@ Although PHP does not support overloading functions natively, swig
|
|||
will generate dispatch functions which will use <tt>%typecheck</tt>
|
||||
typemaps to allow overloading. This dispatch function's operation and
|
||||
precedence is described in <a
|
||||
href="SWIGPlus.html#SWIGPlus_overloaded_methods">Wrapping
|
||||
Overloaded Functions and Methods</a>.
|
||||
href="SWIGPlus.html#SWIGPlus_overloaded_methods">Overloaded functions and methods</a>.
|
||||
</p>
|
||||
|
||||
<!-- This isn't correct for 1.3.30 and needs rewriting to reflect reality
|
||||
|
|
@ -438,7 +430,7 @@ taking the integer argument.
|
|||
</p>
|
||||
-->
|
||||
|
||||
<H3><a name="Php_nn2_5">34.2.5 Pointers and References</a></H3>
|
||||
<H3><a name="Php_nn2_5">32.2.5 Pointers and References</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -526,13 +518,6 @@ this, one needs to include <b>phppointers.i</b> which defines the
|
|||
named typemap REF.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Prior to SWIG 3.0, the REF typemaps relied on PHP's call-time
|
||||
pass-by-reference, which was deprecated in PHP 5.3 and removed in PHP 5.4.
|
||||
So if you use these REF typemaps, you should ensure that SWIG≥3.0 is
|
||||
used to generate wrappers from your interface file.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In case you write your own typemaps, SWIG supports an attribute called
|
||||
<tt>byref</tt>: if you set that, then SWIG will make sure that the generated
|
||||
|
|
@ -583,7 +568,7 @@ PHP in a number of ways: by using <tt>unset</tt> on an existing
|
|||
variable, or assigning <tt>NULL</tt> to a variable.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_6">34.2.6 Structures and C++ classes</a></H3>
|
||||
<H3><a name="Php_nn2_6">32.2.6 Structures and C++ classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -644,7 +629,7 @@ Would be used in the following way from PHP:
|
|||
Member variables and methods are accessed using the <tt>-></tt> operator.
|
||||
</p>
|
||||
|
||||
<H4><a name="Php_nn2_6_1">34.2.6.1 Using -noproxy</a></H4>
|
||||
<H4><a name="Php_nn2_6_1">32.2.6.1 Using -noproxy</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -670,7 +655,7 @@ Complex_im_set($obj, $d);
|
|||
Complex_im_get($obj);
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Php_nn2_6_2">34.2.6.2 Constructors and Destructors</a></H4>
|
||||
<H4><a name="Php_nn2_6_2">32.2.6.2 Constructors and Destructors</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -711,7 +696,7 @@ the programmer can either reassign the variable or call
|
|||
<tt>unset($v)</tt>
|
||||
</p>
|
||||
|
||||
<H4><a name="Php_nn2_6_3">34.2.6.3 Static Member Variables</a></H4>
|
||||
<H4><a name="Php_nn2_6_3">32.2.6.3 Static Member Variables</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -754,7 +739,7 @@ Ko::threats(10);
|
|||
echo "There have now been " . Ko::threats() . " threats\n";
|
||||
|
||||
</pre></div>
|
||||
<H4><a name="Php_nn2_6_4">34.2.6.4 Static Member Functions</a></H4>
|
||||
<H4><a name="Php_nn2_6_4">32.2.6.4 Static Member Functions</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -776,7 +761,7 @@ Ko::threats();
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H4><a name="Php_nn2_6_5">34.2.6.5 Specifying Implemented Interfaces</a></H4>
|
||||
<H4><a name="Php_nn2_6_5">32.2.6.5 Specifying Implemented Interfaces</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -794,7 +779,7 @@ so:
|
|||
If there are multiple interfaces, just list them separated by commas.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_7">34.2.7 PHP Pragmas, Startup and Shutdown code</a></H3>
|
||||
<H3><a name="Php_nn2_7">32.2.7 PHP Pragmas, Startup and Shutdown code</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -820,6 +805,15 @@ Results in the following in "example.php"
|
|||
echo "example.php execution\n";
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The <b>version</b> pragma can be used to add version to generated PHP extension module. The version is inserted in the zend_module_entry block.
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%module example
|
||||
%pragma(php) version="1.5"
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The <b>include</b> pragma is a short cut to add include statements to
|
||||
the example.php file.
|
||||
|
|
@ -882,7 +876,7 @@ The <tt>%rinit</tt> and <tt>%rshutdown</tt> statements are very similar but inse
|
|||
into the request init (PHP_RINIT_FUNCTION) and request shutdown (PHP_RSHUTDOWN_FUNCTION) code respectively.
|
||||
</p>
|
||||
|
||||
<H2><a name="Php_nn3">34.3 Cross language polymorphism</a></H2>
|
||||
<H2><a name="Php_nn3">32.3 Cross language polymorphism</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -917,7 +911,7 @@ wrapper functions takes care of all the cross-language method routing
|
|||
transparently.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_1">34.3.1 Enabling directors</a></H3>
|
||||
<H3><a name="Php_nn3_1">32.3.1 Enabling directors</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -944,7 +938,7 @@ globally, to specific classes, and to specific methods, like this:
|
|||
// generate directors for all classes that have virtual methods
|
||||
%feature("director");
|
||||
|
||||
// generate directors for all virtual methods in class Foo
|
||||
// generate directors for the virtual methods in class Foo
|
||||
%feature("director") Foo;
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -962,7 +956,7 @@ directors for specific classes or methods. So for example,
|
|||
</div>
|
||||
|
||||
<p>
|
||||
will generate directors for all virtual methods of class Foo except
|
||||
will generate directors for the virtual methods of class Foo except
|
||||
bar().
|
||||
</p>
|
||||
|
||||
|
|
@ -977,14 +971,14 @@ the methods one() and two() (but not three()):
|
|||
%feature("director") Foo;
|
||||
class Foo {
|
||||
public:
|
||||
Foo(int foo);
|
||||
virtual void one();
|
||||
virtual void two();
|
||||
Foo(int foo);
|
||||
virtual void one();
|
||||
virtual void two();
|
||||
};
|
||||
|
||||
class Bar: public Foo {
|
||||
public:
|
||||
virtual void three();
|
||||
virtual void three();
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1006,7 +1000,7 @@ class MyFoo extends Foo {
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Php_nn3_2">34.3.2 Director classes</a></H3>
|
||||
<H3><a name="Php_nn3_2">32.3.2 Director classes</a></H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -1027,7 +1021,8 @@ For simplicity let's ignore the <tt>Swig::Director</tt> class and refer to the
|
|||
original C++ class as the director's base class. By default, a director
|
||||
class extends all virtual methods in the inheritance chain of its base
|
||||
class (see the preceding section for how to modify this behavior).
|
||||
Thus all virtual method calls, whether they originate in C++ or in
|
||||
Virtual methods that have a final specifier are unsurprisingly excluded.
|
||||
Thus the virtual method calls, whether they originate in C++ or in
|
||||
PHP via proxy classes, eventually end up in at the implementation in the
|
||||
director class. The job of the director methods is to route these method
|
||||
calls to the appropriate place in the inheritance chain. By "appropriate
|
||||
|
|
@ -1086,7 +1081,7 @@ so there is no need for the extra overhead involved with routing the
|
|||
calls through PHP.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_3">34.3.3 Ownership and object destruction</a></H3>
|
||||
<H3><a name="Php_nn3_3">32.3.3 Ownership and object destruction</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1116,12 +1111,12 @@ Here is an example:
|
|||
<pre>
|
||||
class Foo {
|
||||
public:
|
||||
...
|
||||
...
|
||||
};
|
||||
class FooContainer {
|
||||
public:
|
||||
void addFoo(Foo *);
|
||||
...
|
||||
void addFoo(Foo *);
|
||||
...
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1142,7 +1137,7 @@ In this example, we are assuming that FooContainer will take care of
|
|||
deleting all the Foo pointers it contains at some point.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_4">34.3.4 Exception unrolling</a></H3>
|
||||
<H3><a name="Php_nn3_4">32.3.4 Exception unrolling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1166,9 +1161,9 @@ should suffice in most cases:
|
|||
<div class="code">
|
||||
<pre>
|
||||
%feature("director:except") {
|
||||
if ($error == FAILURE) {
|
||||
throw Swig::DirectorMethodException();
|
||||
}
|
||||
if ($error == FAILURE) {
|
||||
throw Swig::DirectorMethodException();
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1195,8 +1190,8 @@ suitable exception handler:
|
|||
<div class="code">
|
||||
<pre>
|
||||
%exception {
|
||||
try { $action }
|
||||
catch (Swig::DirectorException &e) { SWIG_fail; }
|
||||
try { $action }
|
||||
catch (Swig::DirectorException &e) { SWIG_fail; }
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1209,7 +1204,7 @@ Swig::DirectorMethodException is thrown, PHP will register the exception
|
|||
as soon as the C wrapper function returns.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_5">34.3.5 Overhead and code bloat</a></H3>
|
||||
<H3><a name="Php_nn3_5">32.3.5 Overhead and code bloat</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1242,7 +1237,7 @@ optimized by selectively enabling director methods (using the %feature
|
|||
directive) for only those methods that are likely to be extended in PHP.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_6">34.3.6 Typemaps</a></H3>
|
||||
<H3><a name="Php_nn3_6">32.3.6 Typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1256,7 +1251,7 @@ need to be supported.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Php_nn3_7">34.3.7 Miscellaneous</a></H3>
|
||||
<H3><a name="Php_nn3_7">32.3.7 Miscellaneous</a></H3>
|
||||
|
||||
|
||||
<p> Director typemaps for STL classes are mostly in place, and hence you
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Pike">35 SWIG and Pike</a></H1>
|
||||
<H1><a name="Pike">37 SWIG and Pike</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -47,10 +47,10 @@ least, make sure you read the "<a href="SWIG.html#SWIG">SWIG Basics</a>"
|
|||
chapter.<br>
|
||||
</p>
|
||||
|
||||
<H2><a name="Pike_nn2">35.1 Preliminaries</a></H2>
|
||||
<H2><a name="Pike_nn2">37.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Pike_nn3">35.1.1 Running SWIG</a></H3>
|
||||
<H3><a name="Pike_nn3">37.1.1 Running SWIG</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -95,7 +95,7 @@ can use the <tt>-o</tt> option:
|
|||
<div class="code">
|
||||
<pre>$ <b>swig -pike -o pseudonym.c example.i</b><br></pre>
|
||||
</div>
|
||||
<H3><a name="Pike_nn4">35.1.2 Getting the right header files</a></H3>
|
||||
<H3><a name="Pike_nn4">37.1.2 Getting the right header files</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -115,7 +115,7 @@ You're looking for files with the names <tt>global.h</tt>, <tt>program.h</tt>
|
|||
and so on.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn5">35.1.3 Using your module</a></H3>
|
||||
<H3><a name="Pike_nn5">37.1.3 Using your module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -130,10 +130,10 @@ Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
|
|||
(1) Result: 24
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Pike_nn6">35.2 Basic C/C++ Mapping</a></H2>
|
||||
<H2><a name="Pike_nn6">37.2 Basic C/C++ Mapping</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Pike_nn7">35.2.1 Modules</a></H3>
|
||||
<H3><a name="Pike_nn7">37.2.1 Modules</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -144,7 +144,7 @@ concerned), SWIG's <tt>%module</tt> directive doesn't really have any
|
|||
significance.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn8">35.2.2 Functions</a></H3>
|
||||
<H3><a name="Pike_nn8">37.2.2 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -169,7 +169,7 @@ exactly as you'd expect it to:
|
|||
(1) Result: 24
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Pike_nn9">35.2.3 Global variables</a></H3>
|
||||
<H3><a name="Pike_nn9">37.2.3 Global variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -198,7 +198,7 @@ will result in two functions, <tt>Foo_get()</tt> and <tt>Foo_set()</tt>:
|
|||
(3) Result: 3.141590
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Pike_nn10">35.2.4 Constants and enumerated types</a></H3>
|
||||
<H3><a name="Pike_nn10">37.2.4 Constants and enumerated types</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -206,7 +206,7 @@ Enumerated types in C/C++ declarations are wrapped as Pike constants,
|
|||
not as Pike enums.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn11">35.2.5 Constructors and Destructors</a></H3>
|
||||
<H3><a name="Pike_nn11">37.2.5 Constructors and Destructors</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -214,7 +214,7 @@ Constructors are wrapped as <tt>create()</tt> methods, and destructors are
|
|||
wrapped as <tt>destroy()</tt> methods, for Pike classes.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn12">35.2.6 Static Members</a></H3>
|
||||
<H3><a name="Pike_nn12">37.2.6 Static Members</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -230,8 +230,8 @@ For example, given this C++ class declaration:
|
|||
class Shape
|
||||
{
|
||||
public:
|
||||
static void print();
|
||||
static int nshapes;
|
||||
static void print();
|
||||
static int nshapes;
|
||||
};
|
||||
</pre></div>
|
||||
|
||||
|
|
|
|||
|
|
@ -69,6 +69,9 @@ over a period of 10 years starting from the year 2000. The final version in the
|
|||
series was 1.3.40, but in truth the 1.3.x series had been stable for many years.
|
||||
An official stable version was released along with the decision to make SWIG
|
||||
license changes and this gave rise to version 2.0.0 in 2010.
|
||||
Version 3.0.0 was released in 2014 focusing on adding C++11 support and C++ nested classes.
|
||||
Version 4.0.0 was released in 2019 to add in Doxygen support.
|
||||
Some target languages were disabled as part of a clean up and others were given a new status of either 'Supported' or 'Experimental'.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preface_license">1.3 SWIG License</a></H2>
|
||||
|
|
@ -364,7 +367,7 @@ a number of packages to be installed. Full instructions at
|
|||
<p>
|
||||
SWIG is known to work on various flavors of OS X. Follow the Unix installation
|
||||
instructions above. However, as of this writing, there is still great deal of
|
||||
inconsistency with how shared libaries are handled by various scripting languages
|
||||
inconsistency with how shared libraries are handled by various scripting languages
|
||||
on OS X.
|
||||
</p>
|
||||
|
||||
|
|
@ -435,7 +438,7 @@ don't intend to use these features in your own programs.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
Note: The test-suite currently contains over 500 tests. If you
|
||||
Note: The test-suite currently contains over 600 tests. If you
|
||||
have many different target languages installed and a slow machine, it
|
||||
might take more than an hour to run the test-suite.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Preprocessor">8 Preprocessing</a></H1>
|
||||
<H1><a name="Preprocessor">11 Preprocessing</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -38,7 +38,7 @@ However, a number of modifications and enhancements have been made. This
|
|||
chapter describes some of these modifications.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_nn2">8.1 File inclusion</a></H2>
|
||||
<H2><a name="Preprocessor_nn2">11.1 File inclusion</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -64,7 +64,7 @@ By default, the <tt>#include</tt> is ignored unless you run SWIG with the
|
|||
is that you often don't want SWIG to try and wrap everything included
|
||||
in standard header system headers and auxiliary files.
|
||||
|
||||
<H2><a name="Preprocessor_nn3">8.2 File imports</a></H2>
|
||||
<H2><a name="Preprocessor_nn3">11.2 File imports</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -93,7 +93,7 @@ The <tt>-importall</tt> directive tells SWIG to follow all <tt>#include</tt> sta
|
|||
as imports. This might be useful if you want to extract type definitions from system
|
||||
header files without generating any wrappers.
|
||||
|
||||
<H2><a name="Preprocessor_condition_compilation">8.3 Conditional Compilation</a></H2>
|
||||
<H2><a name="Preprocessor_condition_compilation">11.3 Conditional Compilation</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -109,31 +109,25 @@ SWIGIMPORTED Defined when SWIG is importing a file with <tt>%
|
|||
SWIG_VERSION Hexadecimal (binary-coded decimal) number containing SWIG version,
|
||||
such as 0x010311 (corresponding to SWIG-1.3.11).
|
||||
|
||||
SWIGALLEGROCL Defined when using Allegro CL
|
||||
SWIGCFFI Defined when using CFFI
|
||||
SWIGCHICKEN Defined when using CHICKEN
|
||||
SWIGCLISP Defined when using CLISP
|
||||
SWIGCSHARP Defined when using C#
|
||||
SWIGD Defined when using D
|
||||
SWIGGO Defined when using Go
|
||||
SWIGGUILE Defined when using Guile
|
||||
SWIGJAVA Defined when using Java
|
||||
SWIGJAVASCRIPT Defined when using Javascript
|
||||
SWIG_JAVASCRIPT_JSC Defined when using Javascript for JavascriptCore
|
||||
SWIG_JAVASCRIPT_V8 Defined when using Javascript for v8 or node.js
|
||||
SWIG_JAVASCRIPT_JSC Defined when using Javascript with -jsc
|
||||
SWIG_JAVASCRIPT_V8 Defined when using Javascript with -v8 or -node
|
||||
SWIGLUA Defined when using Lua
|
||||
SWIGMODULA3 Defined when using Modula-3
|
||||
SWIGMZSCHEME Defined when using Mzscheme
|
||||
SWIGOCAML Defined when using Ocaml
|
||||
SWIGOCAML Defined when using OCaml
|
||||
SWIGOCTAVE Defined when using Octave
|
||||
SWIGPERL Defined when using Perl
|
||||
SWIGPHP Defined when using PHP5 or PHP7
|
||||
SWIGPHP5 Defined when using PHP5
|
||||
SWIGPHP Defined when using PHP (any version)
|
||||
SWIGPHP7 Defined when using PHP7
|
||||
SWIGPIKE Defined when using Pike
|
||||
SWIGPYTHON Defined when using Python
|
||||
SWIGR Defined when using R
|
||||
SWIGRUBY Defined when using Ruby
|
||||
SWIGSCILAB Defined when using Scilab
|
||||
SWIGSEXP Defined when using S-expressions
|
||||
SWIGTCL Defined when using Tcl
|
||||
SWIGXML Defined when using XML
|
||||
</pre></div>
|
||||
|
|
@ -146,20 +140,32 @@ In addition, SWIG defines the following set of standard C/C++ macros:
|
|||
<pre>
|
||||
__LINE__ Current line number
|
||||
__FILE__ Current file name
|
||||
__STDC__ Defined to indicate ANSI C
|
||||
__STDC__ Defined to indicate ISO C
|
||||
__cplusplus Defined when -c++ option used
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Interface files can look at these symbols as necessary to change the
|
||||
way in which an interface is generated or to mix SWIG directives with
|
||||
C code. These symbols are also defined within the C code generated by
|
||||
SWIG (except for the symbol `<tt>SWIG</tt>' which is only defined
|
||||
within the SWIG compiler).
|
||||
The following are language specific symbols that might be defined:
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_nn5">8.4 Macro Expansion</a></H2>
|
||||
<div class="code"><pre>
|
||||
SWIG_D_VERSION Unsigned integer target version when using D
|
||||
SWIGGO_CGO Defined when using Go for cgo
|
||||
SWIGGO_GCCGO Defined when using Go for gccgo
|
||||
SWIGGO_INTGO_SIZE Size of the Go type int when using Go (32 or 64)
|
||||
SWIGPYTHON_PY3 Defined when using Python with -py3
|
||||
SWIGPYTHON_BUILTIN Defined when using Python with -builtin
|
||||
SWIG_RUBY_AUTORENAME Defined when using Ruby with -autorename
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
Interface files can look at these symbols as necessary to change the
|
||||
way in which an interface is generated or to mix SWIG directives with
|
||||
C code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_nn5">11.4 Macro Expansion</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -188,9 +194,9 @@ More complex macros can be defined in the standard way. For example:
|
|||
<pre>
|
||||
#define EXTERN extern
|
||||
#ifdef __STDC__
|
||||
#define _ANSI(args) (args)
|
||||
#define ISOC_(args) (args)
|
||||
#else
|
||||
#define _ANSI(args) ()
|
||||
#define ISOC_(args) ()
|
||||
#endif
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -214,7 +220,7 @@ like <tt>#x</tt>. This is a non-standard SWIG extension.
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H2><a name="Preprocessor_nn6">8.5 SWIG Macros</a></H2>
|
||||
<H2><a name="Preprocessor_nn6">11.5 SWIG Macros</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -260,7 +266,7 @@ many of SWIG's advanced features and libraries are built using this mechanism (s
|
|||
support).
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_nn7">8.6 C99 and GNU Extensions</a></H2>
|
||||
<H2><a name="Preprocessor_nn7">11.6 C99 and GNU Extensions</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -316,14 +322,14 @@ interface building. However, they are used internally to implement a number of
|
|||
SWIG directives and are provided to make SWIG more compatible with C99 code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_delimiters">8.7 Preprocessing and delimiters</a></H2>
|
||||
<H2><a name="Preprocessor_delimiters">11.7 Preprocessing and delimiters</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
The preprocessor handles { }, " " and %{ %} delimiters differently.
|
||||
</p>
|
||||
|
||||
<H3><a name="Preprocessor_nn8">8.7.1 Preprocessing and %{ ... %} & " ... " delimiters</a></H3>
|
||||
<H3><a name="Preprocessor_nn8">11.7.1 Preprocessing and %{ ... %} & " ... " delimiters</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -348,7 +354,7 @@ the contents of the <tt>%{ ... %}</tt> block are copied without
|
|||
modification to the output (including all preprocessor directives).
|
||||
</p>
|
||||
|
||||
<H3><a name="Preprocessor_nn9">8.7.2 Preprocessing and { ... } delimiters</a></H3>
|
||||
<H3><a name="Preprocessor_nn9">11.7.2 Preprocessing and { ... } delimiters</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -390,7 +396,7 @@ to actually go into the wrapper file, prefix the preprocessor directives with <t
|
|||
SWIG will strip the extra <tt>%</tt> and leave the preprocessor directive in the code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_typemap_delimiters">8.8 Preprocessor and Typemaps</a></H2>
|
||||
<H2><a name="Preprocessor_typemap_delimiters">11.8 Preprocessor and Typemaps</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -461,17 +467,17 @@ would generate
|
|||
</div>
|
||||
|
||||
|
||||
<H2><a name="Preprocessor_nn10">8.9 Viewing preprocessor output</a></H2>
|
||||
<H2><a name="Preprocessor_nn10">11.9 Viewing preprocessor output</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
Like many compilers, SWIG supports a <tt>-E</tt> command line option to display the output from the preprocessor.
|
||||
When the <tt>-E</tt> switch is used, SWIG will not generate any wrappers.
|
||||
When the <tt>-E</tt> option is used, SWIG will not generate any wrappers.
|
||||
Instead the results after the preprocessor has run are displayed.
|
||||
This might be useful as an aid to debugging and viewing the results of macro expansions.
|
||||
</p>
|
||||
|
||||
<H2><a name="Preprocessor_warning_error">8.10 The #error and #warning directives</a></H2>
|
||||
<H2><a name="Preprocessor_warning_error">11.10 The #error and #warning directives</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="R">37 SWIG and R</a></H1>
|
||||
<H1><a name="R">34 SWIG and R</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -17,6 +17,9 @@
|
|||
<li><a href="#R_nn5">General policy</a>
|
||||
<li><a href="#R_language_conventions">Language conventions</a>
|
||||
<li><a href="#R_nn6">C++ classes</a>
|
||||
<ul>
|
||||
<li><a href="#R_class_examples">Examples</a>
|
||||
</ul>
|
||||
<li><a href="#R_nn7">Enumerations</a>
|
||||
</ul>
|
||||
</div>
|
||||
|
|
@ -28,13 +31,19 @@
|
|||
R is a GPL'ed open source statistical and plotting environment.
|
||||
Information about R can be found at <a
|
||||
href="http://www.r-project.org/">www.r-project.org</a>.
|
||||
|
||||
The R bindings are under active development. They have been used to
|
||||
compile and run an R interface to QuantLib running on Mandriva Linux
|
||||
with gcc. The R bindings also work on Microsoft Windows using Visual C++.
|
||||
</p>
|
||||
|
||||
<H2><a name="R_nn2">37.1 Bugs</a></H2>
|
||||
<p>
|
||||
The R bindings are under active development. They have been used to
|
||||
compile and run an R interface to QuantLib running on Mandriva Linux
|
||||
with gcc. They are also used to create the SimpleITK R package, which
|
||||
runs on Linux and MacOS. SWIG is used to create all wrapper
|
||||
interfaces
|
||||
to <a href="http://http://www.simpleitk.org/">SimpleITK</a>. The R
|
||||
bindings also work on Microsoft Windows using Visual C++.
|
||||
</p>
|
||||
|
||||
<H2><a name="R_nn2">34.1 Bugs</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -42,11 +51,13 @@ Currently the following features are not implemented or broken:
|
|||
</p>
|
||||
|
||||
<ul>
|
||||
<li>Garbage collection of created objects
|
||||
<li>Garbage collection of some created objects. Finalizers are
|
||||
available for wrapped C++ classes and are called by the
|
||||
garbage collection system.
|
||||
<li>C Array wrappings
|
||||
</ul>
|
||||
|
||||
<H2><a name="R_nn3">37.2 Using R and SWIG</a></H2>
|
||||
<H2><a name="R_nn3">34.2 Using R and SWIG</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -113,11 +124,10 @@ cacheMetaData(1)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The cacheMetaData(1) will cause R to refresh its object tables.
|
||||
Without it, inheritance of wrapped objects may fail.
|
||||
|
||||
<p>
|
||||
These two files can be loaded in any order
|
||||
These two files can be loaded in any order.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -129,7 +139,7 @@ These two files can be loaded in any order
|
|||
<li>If you do not set the output file name appropriately, you might see errors like
|
||||
<div class="shell">
|
||||
<pre>
|
||||
> fact(4)
|
||||
> fact(4)
|
||||
Error in .Call("R_swig_fact", s_arg1, as.logical(.copy), PACKAGE = "example") :
|
||||
"R_swig_fact" not available for .Call() for package "example"
|
||||
</pre>
|
||||
|
|
@ -137,25 +147,32 @@ Error in .Call("R_swig_fact", s_arg1, as.logical(.copy), PACKAGE = "example") :
|
|||
<li>Make sure the architecture of the shared library(x64 for instance), matches the architecture of the R program you want to load your shared library into
|
||||
</ul>
|
||||
|
||||
<H2><a name="R_nn4">37.3 Precompiling large R files</a></H2>
|
||||
<H2><a name="R_nn4">34.3 Precompiling large R files</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
In cases where the R file is large, one make save a lot of loading
|
||||
time by precompiling the R wrapper. This can be done by creating the
|
||||
file makeRData.R which contains the following
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<div class="code"><pre>
|
||||
source('BigFile.R')
|
||||
save(list=ls(all=TRUE), file="BigFile.RData", compress=TRUE)
|
||||
q(save="no")
|
||||
</pre>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
This will generate a compiled R file called BigFile.RData that
|
||||
will save a large amount of loading time.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There is no need to precompile large R files if the SWIG-generated code is being included
|
||||
in an R package. The package infrastructure provides this service during package installation.
|
||||
</p>
|
||||
|
||||
|
||||
<H2><a name="R_nn5">37.4 General policy</a></H2>
|
||||
<H2><a name="R_nn5">34.4 General policy</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -164,34 +181,193 @@ wrapping over the underlying functions and rely on the R type system
|
|||
to provide R syntax.
|
||||
</p>
|
||||
|
||||
<H2><a name="R_language_conventions">37.5 Language conventions</a></H2>
|
||||
<H2><a name="R_language_conventions">34.5 Language conventions</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
getitem and setitem use C++ conventions (i.e. zero based indices). [<-
|
||||
getitem and setitem use C++ conventions (i.e. zero based indices). [<-
|
||||
and [ are overloaded to allow for R syntax (one based indices and
|
||||
slices)
|
||||
</p>
|
||||
|
||||
<H2><a name="R_nn6">37.6 C++ classes</a></H2>
|
||||
<H2><a name="R_nn6">34.6 C++ classes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
C++ objects are implemented as external pointer objects with the class
|
||||
being the mangled name of the class. The C++ classes are encapsulated
|
||||
as an SEXP with an external pointer type. The class is the mangled
|
||||
name of the class. The nice thing about R is that is allows you to
|
||||
keep track of the pointer object which removes the necessity for a lot
|
||||
of the proxy class baggage you see in other languages.
|
||||
Wrapping of C++ classes for R works quite well. R has a special
|
||||
type, known as an external reference, that can be used as a pointer
|
||||
to arbitary things, including C++ classes. The proxy layers generated
|
||||
for other classes are not required.
|
||||
</p>
|
||||
|
||||
<H2><a name="R_nn7">37.7 Enumerations</a></H2>
|
||||
<p>
|
||||
SWIG currently creates a custom hierarchy of R classes derived from the
|
||||
external reference type and implements
|
||||
type checking and function overloading in the R code it generates. In
|
||||
the future we hope to utilise the built in R6 class structures.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The R interface has the following capabilities:
|
||||
</p>
|
||||
<ul>
|
||||
<li> Destructor methods are registered and called automatically by the R garbage collector.
|
||||
<li> A range of std::vector types are converted automatically to R equivalents via the std_vector.i library.
|
||||
<li> The $ operator is used for method access.
|
||||
<li> Variable accessors are automatically generated and called via the $, [, [[, $<-, [<-, [[<- operators.
|
||||
</ul>
|
||||
|
||||
<H3><a name="R_class_examples">34.6.1 Examples</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
enumerations are characters which are then converted back and forth to
|
||||
ints before calling the C routines. All of the enumeration code is
|
||||
done in R.
|
||||
Consider the following simple example:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
class Vehicle {
|
||||
private:
|
||||
int m_axles;
|
||||
|
||||
public:
|
||||
int Axles() {
|
||||
return(m_axles);
|
||||
}
|
||||
|
||||
bool Available;
|
||||
|
||||
Vehicle() {
|
||||
Available=false;
|
||||
m_axles=2;
|
||||
}
|
||||
|
||||
Vehicle(int ax) {
|
||||
Available=false;
|
||||
m_axles=ax;
|
||||
}
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The following options are available in R:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
v1 <- Vehicle()
|
||||
v2 <- Vehicle(4)
|
||||
# access members
|
||||
v1$Axles()
|
||||
[1] 2
|
||||
v2$Axles
|
||||
[1] 4
|
||||
v1$Available
|
||||
[1] FALSE
|
||||
# Set availabilty
|
||||
v1$Available <- TRUE
|
||||
v1$Available
|
||||
[1] TRUE
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
A useful trick to determine the methods that are available is to
|
||||
query the R method definition as follows:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
# display the methods for the class
|
||||
getMethod("$", class(v1))
|
||||
|
||||
Method Definition:
|
||||
|
||||
function (x, name)
|
||||
{
|
||||
accessorFuns = list(Axles = Vehicle_Axles, Available = Vehicle_Available_get)
|
||||
vaccessors = c("Available")
|
||||
idx = pmatch(name, names(accessorFuns))
|
||||
if (is.na(idx))
|
||||
return(callNextMethod(x, name))
|
||||
f = accessorFuns[[idx]]
|
||||
if (is.na(match(name, vaccessors)))
|
||||
function(...) {
|
||||
f(x, ...)
|
||||
}
|
||||
else f(x)
|
||||
}
|
||||
|
||||
Signatures:
|
||||
x
|
||||
target "_p_Vehicle"
|
||||
defined "_p_Vehicle"
|
||||
|
||||
</pre>
|
||||
</div>
|
||||
<p>
|
||||
The names in the <tt>accessorFuns</tt> list correspond to class methods while names in the <tt>vaccessors</tt> section
|
||||
correspond to variables that may be modified.
|
||||
</p>
|
||||
<H2><a name="R_nn7">34.7 Enumerations</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
R doesn't have a native enumeration type. Enumerations are represented
|
||||
as character strings in R, with calls to R functions that convert back
|
||||
and forth between integers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
enum colour { red=-1, blue, green = 10 };
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
will be initialized by the following call in R:
|
||||
</p>
|
||||
|
||||
<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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The relevant functions, for debugging purposes, are <tt>enumToInteger</tt> and
|
||||
<tt>enumFromInteger</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Anonymous enumerations are ignored by the binding generation process,
|
||||
leaving no way of accessing the value of anonymous enumerations from R
|
||||
code.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Ruby">38 SWIG and Ruby</a></H1>
|
||||
<H1><a name="Ruby">35 SWIG and Ruby</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -149,10 +149,10 @@
|
|||
|
||||
<p>This chapter describes SWIG's support of Ruby.</p>
|
||||
|
||||
<H2><a name="Ruby_nn2">38.1 Preliminaries</a></H2>
|
||||
<H2><a name="Ruby_nn2">35.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p> SWIG 3.0 is known to work with Ruby versions 1.8 and later.
|
||||
<p> SWIG 4.0 is known to work with Ruby versions 1.9 and later.
|
||||
Given the choice, you should use the latest stable version of Ruby. You
|
||||
should also determine if your system supports shared libraries and
|
||||
dynamic loading. SWIG will work with or without dynamic loading, but
|
||||
|
|
@ -164,7 +164,7 @@ read the "<a href="SWIG.html#SWIG">SWIG Basics</a>"
|
|||
chapter. It is also assumed that the reader has a basic understanding
|
||||
of Ruby. </p>
|
||||
|
||||
<H3><a name="Ruby_nn3">38.1.1 Running SWIG</a></H3>
|
||||
<H3><a name="Ruby_nn3">35.1.1 Running SWIG</a></H3>
|
||||
|
||||
|
||||
<p> To build a Ruby module, run SWIG using the <tt>-ruby</tt>
|
||||
|
|
@ -188,36 +188,21 @@ if compiling a C++ extension) that contains all of the code needed to
|
|||
build a Ruby extension module. To finish building the module, you need
|
||||
to compile this file and link it with the rest of your program. </p>
|
||||
|
||||
<H3><a name="Ruby_nn4">38.1.2 Getting the right header files</a></H3>
|
||||
<H3><a name="Ruby_nn4">35.1.2 Getting the right header files</a></H3>
|
||||
|
||||
|
||||
<p> In order to compile the wrapper code, the compiler needs the <tt>ruby.h</tt>
|
||||
header file. This file is usually contained in a directory such as </p>
|
||||
|
||||
<div class="code shell diagram">
|
||||
<pre>/usr/lib/ruby/1.8/x86_64-linux-gnu/ruby.h
|
||||
/usr/include/ruby-2.1.0/ruby.h
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p> The exact location may vary on your machine, but the above
|
||||
location is typical. If you are not entirely sure where Ruby is
|
||||
installed, you can run Ruby to find out. For example: </p>
|
||||
header file and its dependencies, notably <tt>ruby/config.h</tt> which is
|
||||
found in a different, architecture-dependent, directory. The best way to find
|
||||
the compiler options needed to compile the code is to ask Ruby itself:</p>
|
||||
|
||||
<div class="code shell">
|
||||
<pre>$ ruby -e 'puts $:.join("\n")'
|
||||
/usr/local/lib/site_ruby/2.1.0
|
||||
/usr/local/lib/x86_64-linux-gnu/site_ruby
|
||||
/usr/local/lib/site_ruby
|
||||
/usr/lib/ruby/vendor_ruby/2.1.0
|
||||
/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.1.0
|
||||
/usr/lib/ruby/vendor_ruby
|
||||
/usr/lib/ruby/2.1.0
|
||||
/usr/lib/x86_64-linux-gnu/ruby/2.1.0
|
||||
<pre>$ ruby -rrbconfig -e 'puts "-I#{RbConfig::CONFIG[%q{rubyhdrdir}]} -I#{RbConfig::CONFIG[%q{rubyarchhdrdir}]}"'
|
||||
-I/usr/include/ruby-2.1.0 -I/usr/include/x86_64-linux-gnu/ruby-2.1.0
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn5">38.1.3 Compiling a dynamic module</a></H3>
|
||||
<H3><a name="Ruby_nn5">35.1.3 Compiling a dynamic module</a></H3>
|
||||
|
||||
|
||||
<p> Ruby extension modules are typically compiled into shared
|
||||
|
|
@ -290,7 +275,7 @@ manual pages for your compiler and linker to determine the correct set
|
|||
of options. You might also check the <a href="https://github.com/swig/swig/wiki">SWIG Wiki</a>
|
||||
for additional information. </p>
|
||||
|
||||
<H3><a name="Ruby_nn6">38.1.4 Using your module</a></H3>
|
||||
<H3><a name="Ruby_nn6">35.1.4 Using your module</a></H3>
|
||||
|
||||
|
||||
<p> Ruby <i>module</i> names must be capitalized,
|
||||
|
|
@ -320,7 +305,7 @@ begins with: </p>
|
|||
<p> will result in an extension module using the feature name
|
||||
"example" and Ruby module name "Example". </p>
|
||||
|
||||
<H3><a name="Ruby_nn7">38.1.5 Static linking</a></H3>
|
||||
<H3><a name="Ruby_nn7">35.1.5 Static linking</a></H3>
|
||||
|
||||
|
||||
<p> An alternative approach to dynamic linking is to rebuild the
|
||||
|
|
@ -335,7 +320,7 @@ finding the Ruby source, adding an entry to the <tt>ext/Setup</tt>
|
|||
file, adding your directory to the list of extensions in the file, and
|
||||
finally rebuilding Ruby. </p>
|
||||
|
||||
<H3><a name="Ruby_nn8">38.1.6 Compilation of C++ extensions</a></H3>
|
||||
<H3><a name="Ruby_nn8">35.1.6 Compilation of C++ extensions</a></H3>
|
||||
|
||||
|
||||
<p> On most machines, C++ extension modules should be linked
|
||||
|
|
@ -367,7 +352,7 @@ $libs = append_library($libs, "supc++")
|
|||
create_makefile('example')</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Ruby_nn9">38.2 Building Ruby Extensions under Windows 95/NT</a></H2>
|
||||
<H2><a name="Ruby_nn9">35.2 Building Ruby Extensions under Windows 95/NT</a></H2>
|
||||
|
||||
|
||||
<p> Building a SWIG extension to Ruby under Windows 95/NT is
|
||||
|
|
@ -392,7 +377,7 @@ order to build extensions, you may need to download the source
|
|||
distribution to the Ruby package, as you will need the Ruby header
|
||||
files. </p>
|
||||
|
||||
<H3><a name="Ruby_nn10">38.2.1 Running SWIG from Developer Studio</a></H3>
|
||||
<H3><a name="Ruby_nn10">35.2.1 Running SWIG from Developer Studio</a></H3>
|
||||
|
||||
|
||||
<p> If you are developing your application within Microsoft
|
||||
|
|
@ -456,13 +441,13 @@ Foo = 3.0
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Ruby_nn11">38.3 The Ruby-to-C/C++ Mapping</a></H2>
|
||||
<H2><a name="Ruby_nn11">35.3 The Ruby-to-C/C++ Mapping</a></H2>
|
||||
|
||||
|
||||
<p> This section describes the basics of how SWIG maps C or C++
|
||||
declarations in your SWIG interface files to Ruby constructs. </p>
|
||||
|
||||
<H3><a name="Ruby_nn12">38.3.1 Modules</a></H3>
|
||||
<H3><a name="Ruby_nn12">35.3.1 Modules</a></H3>
|
||||
|
||||
|
||||
<p> The SWIG <tt>%module</tt> directive specifies
|
||||
|
|
@ -534,7 +519,7 @@ option to wrap everything into the global module, take care that the
|
|||
names of your constants, classes and methods don't conflict with any of
|
||||
Ruby's built-in names. </p>
|
||||
|
||||
<H3><a name="Ruby_nn13">38.3.2 Functions</a></H3>
|
||||
<H3><a name="Ruby_nn13">35.3.2 Functions</a></H3>
|
||||
|
||||
|
||||
<p> Global functions are wrapped as Ruby module methods. For
|
||||
|
|
@ -568,7 +553,7 @@ irb(main):002:0> <b>Example.fact(4)</b>
|
|||
24</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn14">38.3.3 Variable Linking</a></H3>
|
||||
<H3><a name="Ruby_nn14">35.3.3 Variable Linking</a></H3>
|
||||
|
||||
|
||||
<p> C/C++ global variables are wrapped as a pair of singleton
|
||||
|
|
@ -630,7 +615,25 @@ directive. For example: </p>
|
|||
effect until it is explicitly disabled using <tt>%mutable</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ruby_nn15">38.3.4 Constants</a></H3>
|
||||
<p>Note: When SWIG is invoked with the <tt>-globalmodule</tt> option in
|
||||
effect, the C/C++ global variables will be translated into Ruby global
|
||||
variables. Type-checking and the optional read-only characteristic are
|
||||
available in the same way as described above. However the example would
|
||||
then have to be modified and executed in the following way:
|
||||
|
||||
<div class="code targetlang">
|
||||
<pre>$ <b>irb</b>
|
||||
irb(main):001:0> <b>require 'Example'</b>
|
||||
true
|
||||
irb(main):002:0> <b>$variable1 = 2</b>
|
||||
2
|
||||
irb(main):003:0> <b>$Variable2 = 4 * 10.3</b>
|
||||
41.2
|
||||
irb(main):004:0> <b>$Variable2</b>
|
||||
41.2</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn15">35.3.4 Constants</a></H3>
|
||||
|
||||
|
||||
<p> C/C++ constants are wrapped as module constants initialized
|
||||
|
|
@ -658,7 +661,7 @@ irb(main):002:0> <b>Example::PI</b>
|
|||
3.14159</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn16">38.3.5 Pointers</a></H3>
|
||||
<H3><a name="Ruby_nn16">35.3.5 Pointers</a></H3>
|
||||
|
||||
|
||||
<p> "Opaque" pointers to arbitrary C/C++ types (i.e. types that
|
||||
|
|
@ -682,7 +685,7 @@ returns an instance of an internally generated Ruby class: </p>
|
|||
<p> A <tt>NULL</tt> pointer is always represented by
|
||||
the Ruby <tt>nil</tt> object. </p>
|
||||
|
||||
<H3><a name="Ruby_nn17">38.3.6 Structures</a></H3>
|
||||
<H3><a name="Ruby_nn17">35.3.6 Structures</a></H3>
|
||||
|
||||
|
||||
<p> C/C++ structs are wrapped as Ruby classes, with accessor
|
||||
|
|
@ -787,7 +790,7 @@ void Bar_f_set(Bar *b, Foo *val) {
|
|||
}</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn18">38.3.7 C++ classes</a></H3>
|
||||
<H3><a name="Ruby_nn18">35.3.7 C++ classes</a></H3>
|
||||
|
||||
|
||||
<p> Like structs, C++ classes are wrapped by creating a new Ruby
|
||||
|
|
@ -842,7 +845,7 @@ Ale
|
|||
3</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn19">38.3.8 C++ Inheritance</a></H3>
|
||||
<H3><a name="Ruby_nn19">35.3.8 C++ Inheritance</a></H3>
|
||||
|
||||
|
||||
<p> The SWIG type-checker is fully aware of C++ inheritance.
|
||||
|
|
@ -995,7 +998,7 @@ inherit from both <tt>Base1</tt> and <tt>Base2</tt>
|
|||
(i.e. they exhibit <a href="http://c2.com/cgi/wiki?DuckTyping">"Duck
|
||||
Typing"</a>). </p>
|
||||
|
||||
<H3><a name="Ruby_nn20">38.3.9 C++ Overloaded Functions</a></H3>
|
||||
<H3><a name="Ruby_nn20">35.3.9 C++ Overloaded Functions</a></H3>
|
||||
|
||||
|
||||
<p> C++ overloaded functions, methods, and constructors are
|
||||
|
|
@ -1085,7 +1088,7 @@ arises--in this case, the first declaration takes precedence. </p>
|
|||
<p>Please refer to the <a href="SWIGPlus.html#SWIGPlus">"SWIG
|
||||
and C++"</a> chapter for more information about overloading. </p>
|
||||
|
||||
<H3><a name="Ruby_nn21">38.3.10 C++ Operators</a></H3>
|
||||
<H3><a name="Ruby_nn21">35.3.10 C++ Operators</a></H3>
|
||||
|
||||
|
||||
<p> For the most part, overloaded operators are handled
|
||||
|
|
@ -1127,7 +1130,7 @@ c = Example.add_complex(a, b)</pre>
|
|||
is discussed in the <a href="#Ruby_operator_overloading">section
|
||||
on operator overloading</a>. </p>
|
||||
|
||||
<H3><a name="Ruby_nn22">38.3.11 C++ namespaces</a></H3>
|
||||
<H3><a name="Ruby_nn22">35.3.11 C++ namespaces</a></H3>
|
||||
|
||||
|
||||
<p> SWIG is aware of C++ namespaces, but namespace names do not
|
||||
|
|
@ -1184,7 +1187,7 @@ and create extension modules for each namespace separately. If your
|
|||
program utilizes thousands of small deeply nested namespaces each with
|
||||
identical symbol names, well, then you get what you deserve. </p>
|
||||
|
||||
<H3><a name="Ruby_nn23">38.3.12 C++ templates</a></H3>
|
||||
<H3><a name="Ruby_nn23">35.3.12 C++ templates</a></H3>
|
||||
|
||||
|
||||
<p> C++ templates don't present a huge problem for SWIG. However,
|
||||
|
|
@ -1226,7 +1229,7 @@ irb(main):004:0> <b>p.second</b>
|
|||
4</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn23_1">38.3.13 C++ Standard Template Library (STL)</a></H3>
|
||||
<H3><a name="Ruby_nn23_1">35.3.13 C++ Standard Template Library (STL)</a></H3>
|
||||
|
||||
|
||||
<p> On a related note, the standard SWIG library contains a
|
||||
|
|
@ -1319,7 +1322,7 @@ puts v
|
|||
shown in these examples. More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a>
|
||||
chapter.</p>
|
||||
|
||||
<H3><a name="Ruby_C_STL_Functors">38.3.14 C++ STL Functors</a></H3>
|
||||
<H3><a name="Ruby_C_STL_Functors">35.3.14 C++ STL Functors</a></H3>
|
||||
|
||||
|
||||
<p>Some containers in the STL allow you to modify their default
|
||||
|
|
@ -1380,7 +1383,7 @@ b
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_C_Iterators">38.3.15 C++ STL Iterators</a></H3>
|
||||
<H3><a name="Ruby_C_Iterators">35.3.15 C++ STL Iterators</a></H3>
|
||||
|
||||
|
||||
<p>The STL is well known for the use of iterators. There
|
||||
|
|
@ -1463,10 +1466,10 @@ i
|
|||
|
||||
<p>If you'd rather have STL classes without any iterators, you should define <tt>-DSWIG_NO_EXPORT_ITERATOR_METHODS</tt> when running swig.</p>
|
||||
|
||||
<H3><a name="Ruby_nn24">38.3.16 C++ Smart Pointers</a></H3>
|
||||
<H3><a name="Ruby_nn24">35.3.16 C++ Smart Pointers</a></H3>
|
||||
|
||||
|
||||
<H4><a name="Ruby_smart_pointers_shared_ptr">38.3.16.1 The shared_ptr Smart Pointer</a></H4>
|
||||
<H4><a name="Ruby_smart_pointers_shared_ptr">35.3.16.1 The shared_ptr Smart Pointer</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1477,7 +1480,7 @@ in the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Ruby_smart_pointers_generic">38.3.16.2 Generic Smart Pointers</a></H4>
|
||||
<H4><a name="Ruby_smart_pointers_generic">35.3.16.2 Generic Smart Pointers</a></H4>
|
||||
|
||||
|
||||
<p> In certain C++ programs, it is common to use classes that
|
||||
|
|
@ -1542,7 +1545,7 @@ method. For example: </p>
|
|||
<pre>irb(main):004:0> <b>f = p.__deref__()</b> # Returns underlying Foo *</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn25">38.3.17 Cross-Language Polymorphism</a></H3>
|
||||
<H3><a name="Ruby_nn25">35.3.17 Cross-Language Polymorphism</a></H3>
|
||||
|
||||
|
||||
<p> SWIG's Ruby module supports cross-language polymorphism
|
||||
|
|
@ -1551,7 +1554,7 @@ module. Rather than duplicate the information presented in the <a href="Python.h
|
|||
section just notes the differences that you need to be aware of when
|
||||
using this feature with Ruby. </p>
|
||||
|
||||
<H4><a name="Ruby_nn26">38.3.17.1 Exception Unrolling</a></H4>
|
||||
<H4><a name="Ruby_nn26">35.3.17.1 Exception Unrolling</a></H4>
|
||||
|
||||
|
||||
<p> Whenever a C++ director class routes one of its virtual
|
||||
|
|
@ -1574,7 +1577,7 @@ method is "wrapped" using the <tt>rb_rescue2()</tt>
|
|||
function from Ruby's C API. If any Ruby exception is raised, it will be
|
||||
caught here and a C++ exception is raised in its place. </p>
|
||||
|
||||
<H2><a name="Ruby_nn27">38.4 Naming</a></H2>
|
||||
<H2><a name="Ruby_nn27">35.4 Naming</a></H2>
|
||||
|
||||
|
||||
<p>Ruby has several common naming conventions. Constants are
|
||||
|
|
@ -1612,7 +1615,7 @@ generated
|
|||
by SWIG, it is turned off by default in SWIG 1.3.28. However, it is
|
||||
planned to become the default option in future releases.</p>
|
||||
|
||||
<H3><a name="Ruby_nn28">38.4.1 Defining Aliases</a></H3>
|
||||
<H3><a name="Ruby_nn28">35.4.1 Defining Aliases</a></H3>
|
||||
|
||||
|
||||
<p> It's a fairly common practice in the Ruby built-ins and
|
||||
|
|
@ -1682,7 +1685,7 @@ matching rules used for other kinds of features apply (see the chapter
|
|||
on <a href="Customization.html#Customization">"Customization
|
||||
Features"</a>) for more details).</p>
|
||||
|
||||
<H3><a name="Ruby_nn29">38.4.2 Predicate Methods</a></H3>
|
||||
<H3><a name="Ruby_nn29">35.4.2 Predicate Methods</a></H3>
|
||||
|
||||
|
||||
<p> Ruby methods that return a boolean value and end in a
|
||||
|
|
@ -1731,7 +1734,7 @@ using SWIG's "features" mechanism and so the same name matching rules
|
|||
used for other kinds of features apply (see the chapter on <a href="Customization.html#Customization">"Customization
|
||||
Features"</a>) for more details). </p>
|
||||
|
||||
<H3><a name="Ruby_nn30">38.4.3 Bang Methods</a></H3>
|
||||
<H3><a name="Ruby_nn30">35.4.3 Bang Methods</a></H3>
|
||||
|
||||
|
||||
<p> Ruby methods that modify an object in-place and end in an
|
||||
|
|
@ -1763,7 +1766,7 @@ using SWIG's "features" mechanism and so the same name matching rules
|
|||
used for other kinds of features apply (see the chapter on <a href="Customization.html#Customization">"Customization
|
||||
Features"</a>) for more details). </p>
|
||||
|
||||
<H3><a name="Ruby_nn31">38.4.4 Getters and Setters</a></H3>
|
||||
<H3><a name="Ruby_nn31">35.4.4 Getters and Setters</a></H3>
|
||||
|
||||
|
||||
<p> Often times a C++ library will expose properties through
|
||||
|
|
@ -1798,7 +1801,7 @@ irb(main):003:0> <b>puts foo.value</b></pre>
|
|||
%rename("value=") Foo::setValue(int value);</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Ruby_nn32">38.5 Input and output parameters</a></H2>
|
||||
<H2><a name="Ruby_nn32">35.5 Input and output parameters</a></H2>
|
||||
|
||||
|
||||
<p> A common problem in some C programs is handling parameters
|
||||
|
|
@ -1937,10 +1940,10 @@ void get_dimensions(Matrix *m, int *rows, int*columns);</pre>
|
|||
<pre>r, c = Example.get_dimensions(m)</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Ruby_nn33">38.6 Exception handling </a></H2>
|
||||
<H2><a name="Ruby_nn33">35.6 Exception handling </a></H2>
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn34">38.6.1 Using the %exception directive </a></H3>
|
||||
<H3><a name="Ruby_nn34">35.6.1 Using the %exception directive </a></H3>
|
||||
|
||||
|
||||
<p>The SWIG <tt>%exception</tt> directive can be
|
||||
|
|
@ -2049,7 +2052,7 @@ methods and functions named <tt>getitem</tt> and <tt>setitem</tt>.
|
|||
limited to C++ exception handling. See the chapter on <a href="Customization.html#Customization">Customization
|
||||
Features</a> for more examples.</p>
|
||||
|
||||
<H3><a name="Ruby_nn34_2">38.6.2 Handling Ruby Blocks </a></H3>
|
||||
<H3><a name="Ruby_nn34_2">35.6.2 Handling Ruby Blocks </a></H3>
|
||||
|
||||
|
||||
<p>One of the highlights of Ruby and most of its standard library
|
||||
|
|
@ -2116,7 +2119,7 @@ a special in typemap, like:</p>
|
|||
|
||||
<p>For more information on typemaps, see <a href="#Ruby_nn37">Typemaps</a>.</p>
|
||||
|
||||
<H3><a name="Ruby_nn35">38.6.3 Raising exceptions </a></H3>
|
||||
<H3><a name="Ruby_nn35">35.6.3 Raising exceptions </a></H3>
|
||||
|
||||
|
||||
<p>There are three ways to raise exceptions from C++ code to
|
||||
|
|
@ -2273,7 +2276,7 @@ function. The first argument passed to <tt>rb_raise()</tt>
|
|||
is the exception type. You can raise a custom exception type or one of
|
||||
the built-in Ruby exception types.</p>
|
||||
|
||||
<H3><a name="Ruby_nn36">38.6.4 Exception classes </a></H3>
|
||||
<H3><a name="Ruby_nn36">35.6.4 Exception classes </a></H3>
|
||||
|
||||
|
||||
<p>Starting with SWIG 1.3.28, the Ruby module supports the <tt>%exceptionclass</tt>
|
||||
|
|
@ -2310,7 +2313,7 @@ end </pre>
|
|||
<p>For another example look at swig/Examples/ruby/exception_class.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ruby_nn37">38.7 Typemaps</a></H2>
|
||||
<H2><a name="Ruby_nn37">35.7 Typemaps</a></H2>
|
||||
|
||||
|
||||
<p> This section describes how you can modify SWIG's default
|
||||
|
|
@ -2325,7 +2328,7 @@ a required part of using SWIG---the default wrapping behavior is enough
|
|||
in most cases. Typemaps are only used if you want to change some aspect
|
||||
of the primitive C-Ruby interface.</p>
|
||||
|
||||
<H3><a name="Ruby_nn38">38.7.1 What is a typemap?</a></H3>
|
||||
<H3><a name="Ruby_nn38">35.7.1 What is a typemap?</a></H3>
|
||||
|
||||
|
||||
<p> A typemap is nothing more than a code generation rule that is
|
||||
|
|
@ -2482,7 +2485,7 @@ to be used as follows (notice how the length parameter is omitted): </p>
|
|||
2</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_Typemap_scope">38.7.2 Typemap scope</a></H3>
|
||||
<H3><a name="Ruby_Typemap_scope">35.7.2 Typemap scope</a></H3>
|
||||
|
||||
|
||||
<p> Once defined, a typemap remains in effect for all of the
|
||||
|
|
@ -2528,7 +2531,7 @@ where the class itself is defined. For example:</p>
|
|||
};</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_Copying_a_typemap">38.7.3 Copying a typemap</a></H3>
|
||||
<H3><a name="Ruby_Copying_a_typemap">35.7.3 Copying a typemap</a></H3>
|
||||
|
||||
|
||||
<p> A typemap is copied by using assignment. For example:</p>
|
||||
|
|
@ -2570,7 +2573,7 @@ rules as for <tt>
|
|||
%apply (char *buf, int len) { (char *buffer, int size) }; // Multiple arguments</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_Deleting_a_typemap">38.7.4 Deleting a typemap</a></H3>
|
||||
<H3><a name="Ruby_Deleting_a_typemap">35.7.4 Deleting a typemap</a></H3>
|
||||
|
||||
|
||||
<p> A typemap can be deleted by simply defining no code. For
|
||||
|
|
@ -2595,7 +2598,7 @@ defined by typemaps, clearing a fundamental type like <tt>int</tt>
|
|||
will make that type unusable unless you also define a new set of
|
||||
typemaps immediately after the clear operation.</p>
|
||||
|
||||
<H3><a name="Ruby_Placement_of_typemaps">38.7.5 Placement of typemaps</a></H3>
|
||||
<H3><a name="Ruby_Placement_of_typemaps">35.7.5 Placement of typemaps</a></H3>
|
||||
|
||||
|
||||
<p> Typemap declarations can be declared in the global scope,
|
||||
|
|
@ -2666,13 +2669,13 @@ In this example, this is done using the class declaration <tt>class
|
|||
string</tt>
|
||||
.</p>
|
||||
|
||||
<H3><a name="Ruby_nn39">38.7.6 Ruby typemaps</a></H3>
|
||||
<H3><a name="Ruby_nn39">35.7.6 Ruby typemaps</a></H3>
|
||||
|
||||
|
||||
<p>The following list details all of the typemap methods that
|
||||
can be used by the Ruby module: </p>
|
||||
|
||||
<H4><a name="Ruby_in_typemap">38.7.6.1 "in" typemap</a></H4>
|
||||
<H4><a name="Ruby_in_typemap">35.7.6.1 "in" typemap</a></H4>
|
||||
|
||||
|
||||
<p>Converts Ruby objects to input
|
||||
|
|
@ -2739,7 +2742,7 @@ arguments to be specified. For example:</p>
|
|||
|
||||
<p> At this time, only zero or one arguments may be converted.</p>
|
||||
|
||||
<H4><a name="Ruby_typecheck_typemap">38.7.6.2 "typecheck" typemap</a></H4>
|
||||
<H4><a name="Ruby_typecheck_typemap">35.7.6.2 "typecheck" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "typecheck" typemap is used to support overloaded
|
||||
|
|
@ -2761,7 +2764,7 @@ program uses overloaded methods, you should also define a collection of
|
|||
"typecheck" typemaps. More details about this follow in a later section
|
||||
on "Typemaps and Overloading."</p>
|
||||
|
||||
<H4><a name="Ruby_out_typemap">38.7.6.3 "out" typemap</a></H4>
|
||||
<H4><a name="Ruby_out_typemap">35.7.6.3 "out" typemap</a></H4>
|
||||
|
||||
|
||||
<p>Converts return value of a C function
|
||||
|
|
@ -2812,7 +2815,7 @@ version of the C datatype matched by the typemap.</td>
|
|||
</table>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_arginit_typemap">38.7.6.4 "arginit" typemap</a></H4>
|
||||
<H4><a name="Ruby_arginit_typemap">35.7.6.4 "arginit" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "arginit" typemap is used to set the initial value of a
|
||||
|
|
@ -2827,7 +2830,7 @@ applications. For example:</p>
|
|||
}</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_default_typemap">38.7.6.5 "default" typemap</a></H4>
|
||||
<H4><a name="Ruby_default_typemap">35.7.6.5 "default" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "default" typemap is used to turn an argument into a
|
||||
|
|
@ -2852,7 +2855,7 @@ arguments that follow must have default values. See the <a href="SWIG.html#SWIG_
|
|||
Default/optional arguments</a> section for further information on
|
||||
default argument wrapping.</p>
|
||||
|
||||
<H4><a name="Ruby_check_typemap">38.7.6.6 "check" typemap</a></H4>
|
||||
<H4><a name="Ruby_check_typemap">35.7.6.6 "check" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "check" typemap is used to supply value checking code
|
||||
|
|
@ -2867,7 +2870,7 @@ arguments have been converted. For example:</p>
|
|||
}</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_argout_typemap_">38.7.6.7 "argout" typemap</a></H4>
|
||||
<H4><a name="Ruby_argout_typemap_">35.7.6.7 "argout" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "argout" typemap is used to return values from arguments.
|
||||
|
|
@ -2921,7 +2924,7 @@ some function like SWIG_Ruby_AppendOutput.</p>
|
|||
|
||||
<p> See the <tt>typemaps.i</tt> library for examples.</p>
|
||||
|
||||
<H4><a name="Ruby_freearg_typemap_">38.7.6.8 "freearg" typemap</a></H4>
|
||||
<H4><a name="Ruby_freearg_typemap_">35.7.6.8 "freearg" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "freearg" typemap is used to cleanup argument data. It is
|
||||
|
|
@ -2948,7 +2951,7 @@ This code is also placed into a special variable <tt>$cleanup</tt>
|
|||
that may be used in other typemaps whenever a wrapper function needs to
|
||||
abort prematurely.</p>
|
||||
|
||||
<H4><a name="Ruby_newfree_typemap">38.7.6.9 "newfree" typemap</a></H4>
|
||||
<H4><a name="Ruby_newfree_typemap">35.7.6.9 "newfree" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "newfree" typemap is used in conjunction with the <tt>%newobject</tt>
|
||||
|
|
@ -2972,7 +2975,7 @@ string *foo();</pre>
|
|||
<p> See <a href="Customization.html#Customization_ownership">Object
|
||||
ownership and %newobject</a> for further details.</p>
|
||||
|
||||
<H4><a name="Ruby_memberin_typemap">38.7.6.10 "memberin" typemap</a></H4>
|
||||
<H4><a name="Ruby_memberin_typemap">35.7.6.10 "memberin" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "memberin" typemap is used to copy data from<em> an
|
||||
|
|
@ -2990,21 +2993,21 @@ example:</p>
|
|||
already provides a default implementation for arrays, strings, and
|
||||
other objects.</p>
|
||||
|
||||
<H4><a name="Ruby_varin_typemap">38.7.6.11 "varin" typemap</a></H4>
|
||||
<H4><a name="Ruby_varin_typemap">35.7.6.11 "varin" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "varin" typemap is used to convert objects in the target
|
||||
language to C for the purposes of assigning to a C/C++ global variable.
|
||||
This is implementation specific.</p>
|
||||
|
||||
<H4><a name="Ruby_varout_typemap_">38.7.6.12 "varout" typemap</a></H4>
|
||||
<H4><a name="Ruby_varout_typemap_">35.7.6.12 "varout" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "varout" typemap is used to convert a C/C++ object to an
|
||||
object in the target language when reading a C/C++ global variable.
|
||||
This is implementation specific.</p>
|
||||
|
||||
<H4><a name="Ruby_throws_typemap">38.7.6.13 "throws" typemap</a></H4>
|
||||
<H4><a name="Ruby_throws_typemap">35.7.6.13 "throws" typemap</a></H4>
|
||||
|
||||
|
||||
<p> The "throws" typemap is only used when SWIG parses a C++
|
||||
|
|
@ -3045,7 +3048,7 @@ specification yet they do throw exceptions, SWIG cannot know how to
|
|||
deal with them. For a neat way to handle these, see the <a href="Customization.html#Customization_exception">Exception
|
||||
handling with %exception</a> section.</p>
|
||||
|
||||
<H4><a name="Ruby_directorin_typemap">38.7.6.14 directorin typemap</a></H4>
|
||||
<H4><a name="Ruby_directorin_typemap">35.7.6.14 directorin typemap</a></H4>
|
||||
|
||||
|
||||
<p>Converts C++ objects in director
|
||||
|
|
@ -3104,7 +3107,7 @@ referring to the class itself.</td>
|
|||
</table>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_directorout_typemap">38.7.6.15 directorout typemap</a></H4>
|
||||
<H4><a name="Ruby_directorout_typemap">35.7.6.15 directorout typemap</a></H4>
|
||||
|
||||
|
||||
<p>Converts Ruby objects in director
|
||||
|
|
@ -3177,7 +3180,7 @@ exception.
|
|||
|
||||
</p>
|
||||
|
||||
<H4><a name="Ruby_directorargout_typemap">38.7.6.16 directorargout typemap</a></H4>
|
||||
<H4><a name="Ruby_directorargout_typemap">35.7.6.16 directorargout typemap</a></H4>
|
||||
|
||||
|
||||
<p>Output argument processing in director
|
||||
|
|
@ -3235,19 +3238,19 @@ referring to the instance of the class itself</td>
|
|||
</table>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_ret_typemap">38.7.6.17 ret typemap</a></H4>
|
||||
<H4><a name="Ruby_ret_typemap">35.7.6.17 ret typemap</a></H4>
|
||||
|
||||
|
||||
<p>Cleanup of function return values
|
||||
</p>
|
||||
|
||||
<H4><a name="Ruby_globalin_typemap">38.7.6.18 globalin typemap</a></H4>
|
||||
<H4><a name="Ruby_globalin_typemap">35.7.6.18 globalin typemap</a></H4>
|
||||
|
||||
|
||||
<p>Setting of C global variables
|
||||
</p>
|
||||
|
||||
<H3><a name="Ruby_nn40">38.7.7 Typemap variables</a></H3>
|
||||
<H3><a name="Ruby_nn40">35.7.7 Typemap variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3297,7 +3300,7 @@ so that their values can be properly assigned. </div>
|
|||
<div class="indent">The Ruby name of the wrapper function
|
||||
being created. </div>
|
||||
|
||||
<H3><a name="Ruby_nn41">38.7.8 Useful Functions</a></H3>
|
||||
<H3><a name="Ruby_nn41">35.7.8 Useful Functions</a></H3>
|
||||
|
||||
|
||||
<p> When you write a typemap, you usually have to work directly
|
||||
|
|
@ -3312,7 +3315,7 @@ stick to the swig functions instead of the native Ruby functions.
|
|||
That should help you avoid having to rewrite a lot of typemaps
|
||||
across multiple languages.</p>
|
||||
|
||||
<H4><a name="Ruby_nn42">38.7.8.1 C Datatypes to Ruby Objects</a></H4>
|
||||
<H4><a name="Ruby_nn42">35.7.8.1 C Datatypes to Ruby Objects</a></H4>
|
||||
|
||||
|
||||
<div class="diagram">
|
||||
|
|
@ -3354,11 +3357,11 @@ SWIG_From_float(float)</td>
|
|||
</table>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_nn43">38.7.8.2 Ruby Objects to C Datatypes</a></H4>
|
||||
<H4><a name="Ruby_nn43">35.7.8.2 Ruby Objects to C Datatypes</a></H4>
|
||||
|
||||
|
||||
<p>Here, while the Ruby versions return the value directly, the SWIG
|
||||
versions do not, but return a status value to indicate success (<tt>SWIG_OK</tt>). While more akward to use, this allows you to write typemaps that report more helpful error messages, like:</p>
|
||||
versions do not, but return a status value to indicate success (<tt>SWIG_OK</tt>). While more awkward to use, this allows you to write typemaps that report more helpful error messages, like:</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
|
|
@ -3422,7 +3425,7 @@ versions do not, but return a status value to indicate success (<tt>SWIG_OK</tt>
|
|||
</table>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_nn44">38.7.8.3 Macros for VALUE</a></H4>
|
||||
<H4><a name="Ruby_nn44">35.7.8.3 Macros for VALUE</a></H4>
|
||||
|
||||
|
||||
<p> <tt>RSTRING_LEN(str)</tt> </p>
|
||||
|
|
@ -3445,7 +3448,7 @@ versions do not, but return a status value to indicate success (<tt>SWIG_OK</tt>
|
|||
|
||||
<div class="indent">pointer to array storage</div>
|
||||
|
||||
<H4><a name="Ruby_nn45">38.7.8.4 Exceptions</a></H4>
|
||||
<H4><a name="Ruby_nn45">35.7.8.4 Exceptions</a></H4>
|
||||
|
||||
|
||||
<p> <tt>void rb_raise(VALUE exception, const char *fmt,
|
||||
|
|
@ -3524,7 +3527,7 @@ message to standard error if Ruby was invoked with the <tt>-w</tt>
|
|||
flag. The given format string <i>fmt</i> and remaining
|
||||
arguments are interpreted as with <tt>printf()</tt>. </div>
|
||||
|
||||
<H4><a name="Ruby_nn46">38.7.8.5 Iterators</a></H4>
|
||||
<H4><a name="Ruby_nn46">35.7.8.5 Iterators</a></H4>
|
||||
|
||||
|
||||
<p> <tt>void rb_iter_break()</tt> </p>
|
||||
|
|
@ -3570,14 +3573,14 @@ VALUE), VALUE value)</tt></p>
|
|||
<div class="indent"> Equivalent to Ruby's <tt>throw</tt>.
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn47">38.7.9 Typemap Examples</a></H3>
|
||||
<H3><a name="Ruby_nn47">35.7.9 Typemap Examples</a></H3>
|
||||
|
||||
|
||||
<p> This section includes a few examples of typemaps. For more
|
||||
examples, you might look at the examples in the <tt>Example/ruby</tt>
|
||||
directory. </p>
|
||||
|
||||
<H3><a name="Ruby_nn48">38.7.10 Converting a Ruby array to a char **</a></H3>
|
||||
<H3><a name="Ruby_nn48">35.7.10 Converting a Ruby array to a char **</a></H3>
|
||||
|
||||
|
||||
<p> A common problem in many C programs is the processing of
|
||||
|
|
@ -3642,7 +3645,7 @@ array. Since dynamic memory allocation is used to allocate memory for
|
|||
the array, the "freearg" typemap is used to later release this memory
|
||||
after the execution of the C function. </p>
|
||||
|
||||
<H3><a name="Ruby_nn49">38.7.11 Collecting arguments in a hash</a></H3>
|
||||
<H3><a name="Ruby_nn49">35.7.11 Collecting arguments in a hash</a></H3>
|
||||
|
||||
|
||||
<p> Ruby's solution to the "keyword arguments" capability of some
|
||||
|
|
@ -3719,7 +3722,7 @@ value: </p>
|
|||
<pre>%typemap(in) (int nattributes, const char **names, const int *values)
|
||||
(VALUE keys_arr, int i, VALUE key, VALUE val) {
|
||||
Check_Type($input, T_HASH);
|
||||
<b>$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, NULL));</b>
|
||||
<b>$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, Qnil));</b>
|
||||
}</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -3732,7 +3735,7 @@ the keys and values from the hash: </p>
|
|||
<pre>%typemap(in) (int nattributes, const char **names, const int *values)
|
||||
(VALUE keys_arr, int i, VALUE key, VALUE val) {
|
||||
Check_Type($input, T_HASH);
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, NULL));
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, Qnil));
|
||||
<b>$2 = NULL;
|
||||
$3 = NULL;
|
||||
if ($1 > 0) {
|
||||
|
|
@ -3751,13 +3754,13 @@ of the keys) and then start looping over the elements in that array: </p>
|
|||
<pre>%typemap(in) (int nattributes, const char **names, const int *values)
|
||||
(VALUE keys_arr, int i, VALUE key, VALUE val) {
|
||||
Check_Type($input, T_HASH);
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, NULL));
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, Qnil));
|
||||
$2 = NULL;
|
||||
$3 = NULL;
|
||||
if ($1 > 0) {
|
||||
$2 = (char **) malloc($1*sizeof(char *));
|
||||
$3 = (int *) malloc($1*sizeof(int));
|
||||
<b>keys_arr = rb_funcall($input, rb_intern("keys"), 0, NULL);
|
||||
<b>keys_arr = rb_funcall($input, rb_intern("keys"), 0, Qnil);
|
||||
for (i = 0; i < $1; i++) {
|
||||
}</b>
|
||||
}
|
||||
|
|
@ -3773,13 +3776,13 @@ corresponding to that key in the hash: </p>
|
|||
<pre>%typemap(in) (int nattributes, const char **names, const int *values)
|
||||
(VALUE keys_arr, int i, VALUE key, VALUE val) {
|
||||
Check_Type($input, T_HASH);
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, NULL));
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, Qnil));
|
||||
$2 = NULL;
|
||||
$3 = NULL;
|
||||
if ($1 > 0) {
|
||||
$2 = (char **) malloc($1*sizeof(char *));
|
||||
$3 = (int *) malloc($1*sizeof(int));
|
||||
keys_arr = rb_funcall($input, rb_intern("keys"), 0, NULL);
|
||||
keys_arr = rb_funcall($input, rb_intern("keys"), 0, Qnil);
|
||||
for (i = 0; i < $1; i++) {
|
||||
<b>key = rb_ary_entry(keys_arr, i);
|
||||
val = rb_hash_aref($input, key);</b>
|
||||
|
|
@ -3796,13 +3799,13 @@ value is a <tt>Fixnum</tt>: </p>
|
|||
<pre>%typemap(in) (int nattributes, const char **names, const int *values)
|
||||
(VALUE keys_arr, int i, VALUE key, VALUE val) {
|
||||
Check_Type($input, T_HASH);
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, NULL));
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, Qnil));
|
||||
$2 = NULL;
|
||||
$3 = NULL;
|
||||
if ($1 > 0) {
|
||||
$2 = (char **) malloc($1*sizeof(char *));
|
||||
$3 = (int *) malloc($1*sizeof(int));
|
||||
keys_arr = rb_funcall($input, rb_intern("keys"), 0, NULL);
|
||||
keys_arr = rb_funcall($input, rb_intern("keys"), 0, Qnil);
|
||||
for (i = 0; i < $1; i++) {
|
||||
key = rb_ary_entry(keys_arr, i);
|
||||
val = rb_hash_aref($input, key);
|
||||
|
|
@ -3820,13 +3823,13 @@ equivalents and store them in our local C arrays: </p>
|
|||
<pre>%typemap(in) (int nattributes, const char **names, const int *values)
|
||||
(VALUE keys_arr, int i, VALUE key, VALUE val) {
|
||||
Check_Type($input, T_HASH);
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, NULL));
|
||||
$1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, Qnil));
|
||||
$2 = NULL;
|
||||
$3 = NULL;
|
||||
if ($1 > 0) {
|
||||
$2 = (char **) malloc($1*sizeof(char *));
|
||||
$3 = (int *) malloc($1*sizeof(int));
|
||||
keys_arr = rb_funcall($input, rb_intern("keys"), 0, NULL);
|
||||
keys_arr = rb_funcall($input, rb_intern("keys"), 0, Qnil);
|
||||
for (i = 0; i < $1; i++) {
|
||||
key = rb_ary_entry(keys_arr, i);
|
||||
val = rb_hash_aref($input, key);
|
||||
|
|
@ -3856,7 +3859,7 @@ memory leak. Fortunately, this typemap is a lot easier to write: </p>
|
|||
program that uses the extension, can be found in the <tt>Examples/ruby/hashargs</tt>
|
||||
directory of the SWIG distribution. </p>
|
||||
|
||||
<H3><a name="Ruby_nn50">38.7.12 Pointer handling</a></H3>
|
||||
<H3><a name="Ruby_nn50">35.7.12 Pointer handling</a></H3>
|
||||
|
||||
|
||||
<p> Occasionally, it might be necessary to convert pointer values
|
||||
|
|
@ -3915,7 +3918,7 @@ For example: </p>
|
|||
}</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_nn51">38.7.12.1 Ruby Datatype Wrapping</a></H4>
|
||||
<H4><a name="Ruby_nn51">35.7.12.1 Ruby Datatype Wrapping</a></H4>
|
||||
|
||||
|
||||
<p> <tt>VALUE Data_Wrap_Struct(VALUE class, void
|
||||
|
|
@ -3942,7 +3945,7 @@ as above. </div>
|
|||
type <i>c-type</i> from the data object <i>obj</i>
|
||||
and assigns that pointer to <i>ptr</i>. </div>
|
||||
|
||||
<H3><a name="Ruby_nn52">38.7.13 Example: STL Vector to Ruby Array</a></H3>
|
||||
<H3><a name="Ruby_nn52">35.7.13 Example: STL Vector to Ruby Array</a></H3>
|
||||
|
||||
|
||||
<p>Another use for macros and type maps is to create a Ruby array
|
||||
|
|
@ -4034,7 +4037,7 @@ STL with ruby, you are advised to use the standard swig STL library,
|
|||
which does much more than this. Refer to the section called
|
||||
the<a href="#Ruby_nn23_1"> C++ Standard Template Library</a>.
|
||||
|
||||
<H2><a name="Ruby_nn65">38.8 Docstring Features</a></H2>
|
||||
<H2><a name="Ruby_nn65">35.8 Docstring Features</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4068,7 +4071,7 @@ generate ri documentation from a c wrap file, you could do:</p>
|
|||
$ rdoc -r file_wrap.c
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Ruby_nn66">38.8.1 Module docstring</a></H3>
|
||||
<H3><a name="Ruby_nn66">35.8.1 Module docstring</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4098,7 +4101,7 @@ layout of controls on a panel, etc. to be loaded from an XML file."
|
|||
%module(docstring=DOCSTRING) xrc</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn67">38.8.2 %feature("autodoc")</a></H3>
|
||||
<H3><a name="Ruby_nn67">35.8.2 %feature("autodoc")</a></H3>
|
||||
|
||||
|
||||
<p>Since SWIG does know everything about the function it wraps,
|
||||
|
|
@ -4119,7 +4122,7 @@ several options for autodoc controlled by the value given to the
|
|||
feature, described below.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ruby_nn68">38.8.2.1 %feature("autodoc", "0")</a></H4>
|
||||
<H4><a name="Ruby_nn68">35.8.2.1 %feature("autodoc", "0")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4143,7 +4146,7 @@ Then Ruby code like this will be generated:
|
|||
...</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_autodoc1">38.8.2.2 %feature("autodoc", "1")</a></H4>
|
||||
<H4><a name="Ruby_autodoc1">35.8.2.2 %feature("autodoc", "1")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4163,7 +4166,7 @@ this:
|
|||
...</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_autodoc2">38.8.2.3 %feature("autodoc", "2")</a></H4>
|
||||
<H4><a name="Ruby_autodoc2">35.8.2.3 %feature("autodoc", "2")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4175,7 +4178,7 @@ parameter types with the "2" option will result in Ruby code like
|
|||
this:
|
||||
</p>
|
||||
|
||||
<H4><a name="Ruby_feature_autodoc3">38.8.2.4 %feature("autodoc", "3")</a></H4>
|
||||
<H4><a name="Ruby_feature_autodoc3">35.8.2.4 %feature("autodoc", "3")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4196,7 +4199,7 @@ Parameters:
|
|||
bar - Bar</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ruby_nn70">38.8.2.5 %feature("autodoc", "docstring")</a></H4>
|
||||
<H4><a name="Ruby_nn70">35.8.2.5 %feature("autodoc", "docstring")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4212,7 +4215,7 @@ generated string. For example:
|
|||
void GetPosition(int* OUTPUT, int* OUTPUT);</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn71">38.8.3 %feature("docstring")</a></H3>
|
||||
<H3><a name="Ruby_nn71">35.8.3 %feature("docstring")</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4223,10 +4226,10 @@ docstring associated with classes, function or methods are output.
|
|||
If an item already has an autodoc string then it is combined with the
|
||||
docstring and they are output together. </p>
|
||||
|
||||
<H2><a name="Ruby_nn53">38.9 Advanced Topics</a></H2>
|
||||
<H2><a name="Ruby_nn53">35.9 Advanced Topics</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Ruby_operator_overloading">38.9.1 Operator overloading</a></H3>
|
||||
<H3><a name="Ruby_operator_overloading">35.9.1 Operator overloading</a></H3>
|
||||
|
||||
|
||||
<p> SWIG allows operator overloading with, by using the <tt>%extend</tt>
|
||||
|
|
@ -4407,7 +4410,7 @@ separate method for handling <i>inequality</i> since Ruby
|
|||
parses the expression <i>a != b</i> as <i>!(a == b)</i>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ruby_nn55">38.9.2 Creating Multi-Module Packages</a></H3>
|
||||
<H3><a name="Ruby_nn55">35.9.2 Creating Multi-Module Packages</a></H3>
|
||||
|
||||
|
||||
<p> The chapter on <a href="Modules.html#Modules">Working
|
||||
|
|
@ -4533,7 +4536,7 @@ irb(main):005:0> <b>c.getX()</b>
|
|||
5.0</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ruby_nn56">38.9.3 Specifying Mixin Modules</a></H3>
|
||||
<H3><a name="Ruby_nn56">35.9.3 Specifying Mixin Modules</a></H3>
|
||||
|
||||
|
||||
<p> The Ruby language doesn't support multiple inheritance, but
|
||||
|
|
@ -4600,7 +4603,7 @@ matching rules used for other kinds of features apply (see the chapter
|
|||
on <a href="Customization.html#Customization">"Customization
|
||||
Features"</a>) for more details). </p>
|
||||
|
||||
<H2><a name="Ruby_nn57">38.10 Memory Management</a></H2>
|
||||
<H2><a name="Ruby_nn57">35.10 Memory Management</a></H2>
|
||||
|
||||
|
||||
<p>One of the most common issues in generating SWIG bindings for
|
||||
|
|
@ -4623,7 +4626,7 @@ to C++ (or vice versa) depending on what function or methods are
|
|||
invoked. Clearly, developing a SWIG wrapper requires a thorough
|
||||
understanding of how the underlying library manages memory.</p>
|
||||
|
||||
<H3><a name="Ruby_nn58">38.10.1 Mark and Sweep Garbage Collector </a></H3>
|
||||
<H3><a name="Ruby_nn58">35.10.1 Mark and Sweep Garbage Collector </a></H3>
|
||||
|
||||
|
||||
<p>Ruby uses a mark and sweep garbage collector. When the garbage
|
||||
|
|
@ -4654,7 +4657,7 @@ any memory has been allocated in creating the underlying C struct or
|
|||
C++ struct, then a "free" function must be defined that deallocates
|
||||
this memory. </p>
|
||||
|
||||
<H3><a name="Ruby_nn59">38.10.2 Object Ownership</a></H3>
|
||||
<H3><a name="Ruby_nn59">35.10.2 Object Ownership</a></H3>
|
||||
|
||||
|
||||
<p>As described above, memory management depends on clearly
|
||||
|
|
@ -4799,7 +4802,7 @@ public:
|
|||
|
||||
<p> This code can be seen in swig/examples/ruby/tracking.</p>
|
||||
|
||||
<H3><a name="Ruby_nn60">38.10.3 Object Tracking</a></H3>
|
||||
<H3><a name="Ruby_nn60">35.10.3 Object Tracking</a></H3>
|
||||
|
||||
|
||||
<p>The remaining parts of this section will use the class library
|
||||
|
|
@ -5025,7 +5028,7 @@ However, if you implement your own free functions (see below) you may
|
|||
also have to call the <tt>SWIG_RubyRemoveTracking</tt> and <tt>RubyUnlinkObjects</tt>
|
||||
methods.</p>
|
||||
|
||||
<H3><a name="Ruby_nn61">38.10.4 Mark Functions</a></H3>
|
||||
<H3><a name="Ruby_nn61">35.10.4 Mark Functions</a></H3>
|
||||
|
||||
|
||||
<p>With a bit more testing, we see that our class library still
|
||||
|
|
@ -5154,7 +5157,7 @@ irb(main):016:0></pre>
|
|||
|
||||
<p>This code can be seen in swig/examples/ruby/mark_function.</p>
|
||||
|
||||
<H3><a name="Ruby_nn62">38.10.5 Free Functions</a></H3>
|
||||
<H3><a name="Ruby_nn62">35.10.5 Free Functions</a></H3>
|
||||
|
||||
|
||||
<p>By default, SWIG creates a "free" function that is called when
|
||||
|
|
@ -5322,7 +5325,7 @@ been freed, and thus raises a runtime exception.</p>
|
|||
|
||||
<p>This code can be seen in swig/examples/ruby/free_function.</p>
|
||||
|
||||
<H3><a name="Ruby_nn63">38.10.6 Embedded Ruby and the C++ Stack</a></H3>
|
||||
<H3><a name="Ruby_nn63">35.10.6 Embedded Ruby and the C++ Stack</a></H3>
|
||||
|
||||
|
||||
<p>As has been said, the Ruby GC runs and marks objects before
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@
|
|||
|
||||
<p>
|
||||
This chapter describes the basic operation of SWIG, the structure of its
|
||||
input files, and how it handles standard ANSI C declarations. C++ support is
|
||||
input files, and how it handles standard ISO C declarations. C++ support is
|
||||
described in the next chapter. However, C++ programmers should still read this
|
||||
chapter to understand the basics.
|
||||
Specific details about each target language are described in later
|
||||
|
|
@ -103,71 +103,156 @@ To run SWIG, use the <tt>swig</tt> command with options and a filename like this
|
|||
</p>
|
||||
|
||||
<div class="shell"><pre>
|
||||
swig [ <em>options</em> ] filename
|
||||
swig [ options ] filename
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
where <tt>filename</tt> is a SWIG interface file or a C/C++ header file.
|
||||
Below is a subset of <em>options</em> that can be used.
|
||||
Full help can be seen by running <tt>swig -help</tt>.
|
||||
Below is the common set of options that can be used.
|
||||
Additional options are also defined for each target language. A full list
|
||||
can be obtained by typing <tt>swig -help</tt> or <tt>swig
|
||||
<em>-<lang></em> -help</tt> for language <em><lang></em> specific options.
|
||||
can be obtained by running <tt>swig
|
||||
<em>-<lang></em> -help</tt> for language <em><lang></em> specific options,
|
||||
for example, <tt>swig -ruby -help</tt> for Ruby.
|
||||
</p>
|
||||
|
||||
<div class="shell"><pre>
|
||||
-allegrocl Generate ALLEGROCL wrappers
|
||||
-chicken Generate CHICKEN wrappers
|
||||
-clisp Generate CLISP wrappers
|
||||
-cffi Generate CFFI wrappers
|
||||
-csharp Generate C# wrappers
|
||||
-d Generate D wrappers
|
||||
-go Generate Go wrappers
|
||||
-guile Generate Guile wrappers
|
||||
-java Generate Java wrappers
|
||||
-javascript Generate Javascript wrappers
|
||||
-lua Generate Lua wrappers
|
||||
-modula3 Generate Modula 3 wrappers
|
||||
-mzscheme Generate Mzscheme wrappers
|
||||
-ocaml Generate Ocaml wrappers
|
||||
-octave Generate Octave wrappers
|
||||
-perl Generate Perl wrappers
|
||||
-php5 Generate PHP5 wrappers
|
||||
-php7 Generate PHP7 wrappers
|
||||
-pike Generate Pike wrappers
|
||||
-python Generate Python wrappers
|
||||
-r Generate R (aka GNU S) wrappers
|
||||
-ruby Generate Ruby wrappers
|
||||
-scilab Generate Scilab wrappers
|
||||
-sexp Generate Lisp S-Expressions wrappers
|
||||
-tcl Generate Tcl wrappers
|
||||
-uffi Generate Common Lisp / UFFI wrappers
|
||||
-xml Generate XML wrappers
|
||||
Supported Target Language Options
|
||||
-csharp - Generate C# wrappers
|
||||
-d - Generate D wrappers
|
||||
-go - Generate Go wrappers
|
||||
-guile - Generate Guile wrappers
|
||||
-java - Generate Java wrappers
|
||||
-javascript - Generate Javascript wrappers
|
||||
-lua - Generate Lua wrappers
|
||||
-octave - Generate Octave wrappers
|
||||
-perl5 - Generate Perl 5 wrappers
|
||||
-php7 - Generate PHP 7 wrappers
|
||||
-python - Generate Python wrappers
|
||||
-r - Generate R (aka GNU S) wrappers
|
||||
-ruby - Generate Ruby wrappers
|
||||
-scilab - Generate Scilab wrappers
|
||||
-tcl8 - Generate Tcl 8 wrappers
|
||||
-xml - Generate XML wrappers
|
||||
|
||||
-c++ Enable C++ processing
|
||||
-cppext <em>ext</em> Change file extension of C++ generated files to <em>ext</em>
|
||||
(default is cxx, except for PHP5 which uses cpp)
|
||||
-D<em>symbol</em> Define a preprocessor symbol
|
||||
-Fmicrosoft Display error/warning messages in Microsoft format
|
||||
-Fstandard Display error/warning messages in commonly used format
|
||||
-help Display all options
|
||||
-I<em>dir</em> Add a directory to the file include path
|
||||
-l<em>ifile</em> Include SWIG library file <ifile>
|
||||
-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 Report location of SWIG library and exit
|
||||
-version Display SWIG version number
|
||||
Experimental Target Language Options
|
||||
-mzscheme - Generate MzScheme/Racket wrappers
|
||||
-ocaml - Generate OCaml wrappers
|
||||
|
||||
General Options
|
||||
-addextern - Add extra extern declarations
|
||||
-c++ - Enable C++ processing
|
||||
-co <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>
|
||||
|
||||
<p>
|
||||
Arguments may also be passed in a command-line options file (also known as a
|
||||
response file) which is useful if they exceed the system command line length
|
||||
limit. To do this, put the arguments in a file, then provide the file name
|
||||
prefixed with <tt>@</tt> like so:
|
||||
</p>
|
||||
|
||||
<div class="shell"><pre>
|
||||
swig @<em>file</em>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The options read from the file are inserted in place of the file option. If the
|
||||
file does not exist, or cannot be read, then the option will be treated
|
||||
literally and not removed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Options in the file are separated by whitespace. A whitespace character may be
|
||||
included in an option by surrounding the entire option in either single or
|
||||
double quotes. Any character (including a backslash) may be included by
|
||||
prefixing the character to be included with a backslash. The file may itself
|
||||
contain additional <tt>@file</tt> options; any such options will be processed
|
||||
recursively.
|
||||
</p>
|
||||
|
||||
<H3><a name="SWIG_nn3">5.1.1 Input format</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
As input, SWIG expects a file containing ANSI C/C++ declarations and
|
||||
As input, SWIG expects a file containing ISO C/C++ declarations and
|
||||
special SWIG directives. More often than not, this is a special SWIG
|
||||
interface file which is usually denoted with a special <tt>.i</tt> or
|
||||
<tt>.swg</tt> suffix. In certain cases, SWIG can be used directly on
|
||||
|
|
@ -185,7 +270,7 @@ The most common format of a SWIG interface is as follows:
|
|||
%{
|
||||
#include "myheader.h"
|
||||
%}
|
||||
// Now list ANSI C/C++ declarations
|
||||
// Now list ISO C/C++ declarations
|
||||
int foo;
|
||||
int bar(int x);
|
||||
...
|
||||
|
|
@ -389,7 +474,7 @@ For example
|
|||
/* bar not wrapped unless foo has been defined and
|
||||
the declaration of bar within foo has already been parsed */
|
||||
int foo::bar(int) {
|
||||
... whatever ...
|
||||
... whatever ...
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -741,6 +826,32 @@ However, for the same conservative reasons even a constant with a simple cast wi
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
This logic can lead to false attempts at converting <tt>#define</tt> into <tt>%constant</tt> though.
|
||||
For example the following case does not have any undefined symbols within the macro:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
// For indicating pure virtual functions such as: virtual void f() PURE;
|
||||
#define PURE = 0
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
A warning is issued:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
pure.h:1: Warning 305: Bad constant value (ignored).
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In such cases simply ignore the warning or suppress it using the normal warning suppression techniques.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The use of constant expressions is allowed, but SWIG does not evaluate
|
||||
them. Rather, it passes them through to the output file and lets the C
|
||||
|
|
@ -1043,14 +1154,14 @@ expect :</p>
|
|||
<div class="targetlang"><pre>
|
||||
# Copy a file
|
||||
def filecopy(source, target):
|
||||
f1 = fopen(source, "r")
|
||||
f2 = fopen(target, "w")
|
||||
buffer = malloc(8192)
|
||||
nbytes = fread(buffer, 8192, 1, f1)
|
||||
while (nbytes > 0):
|
||||
fwrite(buffer, 8192, 1, f2)
|
||||
nbytes = fread(buffer, 8192, 1, f1)
|
||||
free(buffer)
|
||||
f1 = fopen(source, "r")
|
||||
f2 = fopen(target, "w")
|
||||
buffer = malloc(8192)
|
||||
nbytes = fread(buffer, 8192, 1, f1)
|
||||
while (nbytes > 0):
|
||||
fwrite(buffer, 8192, 1, f2)
|
||||
nbytes = fread(buffer, 8192, 1, f1)
|
||||
free(buffer)
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -1236,9 +1347,9 @@ creating a wrapper equivalent to the following:
|
|||
|
||||
<div class="code"><pre>
|
||||
double wrap_dot_product(Vector *a, Vector *b) {
|
||||
Vector x = *a;
|
||||
Vector y = *b;
|
||||
return dot_product(x, y);
|
||||
Vector x = *a;
|
||||
Vector y = *b;
|
||||
return dot_product(x, y);
|
||||
}
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -1266,12 +1377,12 @@ pointers. As a result, SWIG creates a wrapper like this:
|
|||
|
||||
<div class="code"><pre>
|
||||
Vector *wrap_cross_product(Vector *v1, Vector *v2) {
|
||||
Vector x = *v1;
|
||||
Vector y = *v2;
|
||||
Vector *result;
|
||||
result = (Vector *) malloc(sizeof(Vector));
|
||||
*(result) = cross(x, y);
|
||||
return result;
|
||||
Vector x = *v1;
|
||||
Vector y = *v2;
|
||||
Vector *result;
|
||||
result = (Vector *) malloc(sizeof(Vector));
|
||||
*(result) = cross(x, y);
|
||||
return result;
|
||||
}
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -1280,10 +1391,10 @@ or if SWIG was run with the <tt>-c++</tt> option:</p>
|
|||
|
||||
<div class="code"><pre>
|
||||
Vector *wrap_cross(Vector *v1, Vector *v2) {
|
||||
Vector x = *v1;
|
||||
Vector y = *v2;
|
||||
Vector *result = new Vector(cross(x, y)); // Uses default copy constructor
|
||||
return result;
|
||||
Vector x = *v1;
|
||||
Vector y = *v2;
|
||||
Vector *result = new Vector(cross(x, y)); // Uses default copy constructor
|
||||
return result;
|
||||
}
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -1736,6 +1847,16 @@ already defined in the target scripting language. However, if you are
|
|||
careful about namespaces and your use of modules, you can usually
|
||||
avoid these problems.</p>
|
||||
|
||||
<p>
|
||||
When wrapping C code, simple use of identifiers/symbols with <tt>%rename</tt> usually suffices.
|
||||
When wrapping C++ code, simple use of simple identifiers/symbols with <tt>%rename</tt> might be too
|
||||
limiting when using C++ features such as function overloading, default arguments, namespaces, template specialization etc.
|
||||
If you are using the <tt>%rename</tt> directive and C++, make sure you read the
|
||||
<a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a> chapter and in particular the section on
|
||||
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a>
|
||||
for method overloading and default arguments.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Closely related to <tt>%rename</tt> is the <tt>%ignore</tt> directive. <tt>%ignore</tt> instructs SWIG
|
||||
to ignore declarations that match a given identifier. For example:
|
||||
|
|
@ -2078,7 +2199,7 @@ except those consisting of capital letters only:
|
|||
<p>
|
||||
Finally, variants of <tt>%rename</tt> and <tt>%ignore</tt> directives can be used to help
|
||||
wrap C++ overloaded functions and methods or C++ methods which use default arguments. This is described in the
|
||||
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Ambiguity resolution and renaming</a> section in the C++ chapter.
|
||||
<a href="SWIGPlus.html#SWIGPlus_ambiguity_resolution_renaming">Renaming and ambiguity resolution</a> section in the C++ chapter.
|
||||
</p>
|
||||
|
||||
|
||||
|
|
@ -2147,7 +2268,7 @@ used in Tcl as follows :</p>
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
Although the ANSI C standard does not allow default arguments, default
|
||||
Although the ISO C standard does not allow default arguments, default
|
||||
arguments specified in a SWIG interface work with both C and C++.
|
||||
</p>
|
||||
|
||||
|
|
@ -2167,7 +2288,7 @@ in the C++ chapter for further details.
|
|||
<p>
|
||||
Occasionally, a C library may include functions that expect to receive
|
||||
pointers to functions--possibly to serve as callbacks. SWIG
|
||||
provides full support for function pointers provided that the callback
|
||||
provides full support for function pointers when the callback
|
||||
functions are defined in C and not in the target language. For example,
|
||||
consider a function like this:
|
||||
</p>
|
||||
|
|
@ -2311,14 +2432,16 @@ And now, a final note about function pointer support. Although SWIG
|
|||
does not normally allow callback functions to be written in the target language, this
|
||||
can be accomplished with the use of typemaps and other advanced SWIG features.
|
||||
See the <a href="Typemaps.html#Typemaps">Typemaps chapter</a> for more about typemaps
|
||||
and individual target language chapters for more on callbacks and the 'director' feature.
|
||||
and individual target language chapters for more on callbacks.
|
||||
The 'director' feature can be used to make callbacks from C/C++ into the target language,
|
||||
see <a href="SWIGPlus.html#SWIGPlus_target_language_callbacks">Callbacks to the target language</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="SWIG_nn31">5.5 Structures and unions</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
This section describes the behavior of SWIG when processing ANSI C structures and union declarations. Extensions to
|
||||
This section describes the behavior of SWIG when processing ISO C structures and union declarations. Extensions to
|
||||
handle C++ are described in the next section.
|
||||
</p>
|
||||
|
||||
|
|
@ -2368,10 +2491,10 @@ defined in the interface. For example:
|
|||
|
||||
<div class="code"><pre>
|
||||
struct Vector *new_Vector() {
|
||||
return (Vector *) calloc(1, sizeof(struct Vector));
|
||||
return (Vector *) calloc(1, sizeof(struct Vector));
|
||||
}
|
||||
void delete_Vector(struct Vector *obj) {
|
||||
free(obj);
|
||||
free(obj);
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -2602,10 +2725,10 @@ like this:
|
|||
<div class="code">
|
||||
<pre>
|
||||
WORD Foo_w_get(Foo *f) {
|
||||
return f->w;
|
||||
return f->w;
|
||||
}
|
||||
void Foo_w_set(FOO *f, WORD value) {
|
||||
f->w = value;
|
||||
f->w = value;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -2896,7 +3019,7 @@ instead of a method. To do this, you might write some code like this:
|
|||
<pre>
|
||||
// Add a new attribute to Vector
|
||||
%extend Vector {
|
||||
const double magnitude;
|
||||
const double magnitude;
|
||||
}
|
||||
// Now supply the implementation of the Vector_magnitude_get function
|
||||
%{
|
||||
|
|
@ -3140,9 +3263,9 @@ output of SWIG is structured first.</p>
|
|||
|
||||
|
||||
<p>
|
||||
When SWIG creates its output file, it is broken up into five sections
|
||||
When SWIG creates its output C/C++ file, it is broken up into five sections
|
||||
corresponding to runtime code, headers, wrapper functions, and module
|
||||
initialization code (in that order).
|
||||
initialization code (in that order).
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
|
@ -3176,9 +3299,37 @@ the module upon loading.
|
|||
|
||||
|
||||
<p>
|
||||
Code is inserted into the appropriate code section by using one
|
||||
of the code insertion directives listed below. The order of the sections in
|
||||
the wrapper file is as shown:
|
||||
The <tt>%insert</tt> directive enables inserting blocks of code into a given section of the generated code.
|
||||
It can be used in one of two ways:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%insert("section") "filename"
|
||||
%insert("section") %{ ... %}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The first will dump the contents of the file in the given <tt>filename</tt> into the named <tt>section</tt>.
|
||||
The second inserts the code between the braces into the named <tt>section</tt>.
|
||||
For example, the following adds code into the runtime section:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%insert("runtime") %{
|
||||
... code in runtime section ...
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
There are the 5 sections, however, some target languages add in additional sections and some of these result in code being generated into a target language file instead of the C/C++ wrapper file.
|
||||
These are documented when available in the target language chapters.
|
||||
Macros named after the code sections are available as additional directives and these macro directives are normally used instead of <tt>%insert</tt>.
|
||||
For example, <tt>%runtime</tt> is used instead of <tt>%insert("runtime")</tt>.
|
||||
The valid sections and order of the sections in the generated C/C++ wrapper file is as shown:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -3265,11 +3416,27 @@ Vector *new_Vector() {
|
|||
return (Vector *) malloc(sizeof(Vector));
|
||||
}
|
||||
%}
|
||||
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The <tt>%inline</tt> directive inserts all of the code that follows
|
||||
This is the same as writing:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%{
|
||||
/* Create a new vector */
|
||||
Vector *new_Vector() {
|
||||
return (Vector *) malloc(sizeof(Vector));
|
||||
}
|
||||
%}
|
||||
|
||||
/* Create a new vector */
|
||||
Vector *new_Vector() {
|
||||
return (Vector *) malloc(sizeof(Vector));
|
||||
}
|
||||
</pre></div>
|
||||
<p>
|
||||
In other words, the <tt>%inline</tt> directive inserts all of the code that follows
|
||||
verbatim into the header portion of an interface file. The code is
|
||||
then parsed by both the SWIG preprocessor and parser.
|
||||
Thus, the above example creates a new command <tt>new_Vector</tt> using only one
|
||||
|
|
@ -3277,6 +3444,11 @@ declaration. Since the code inside an <tt>%inline %{ ... %}</tt> block
|
|||
is given to both the C compiler and SWIG, it is illegal to include any
|
||||
SWIG directives inside a <tt>%{ ... %}</tt> block.</p>
|
||||
|
||||
|
||||
<p>
|
||||
<b>Note:</b> The usual SWIG C preprocessor rules apply to code in <tt>%apply</tt> blocks when SWIG parses this code. For example, as mentioned earlier, <a href="SWIG.html#SWIG_nn6">SWIG's C Preprocessor</a> does not follow <tt>#include</tt> directives by default.
|
||||
</p>
|
||||
|
||||
<H3><a name="SWIG_nn44">5.6.4 Initialization blocks</a></H3>
|
||||
|
||||
|
||||
|
|
@ -3292,6 +3464,18 @@ initialization on module loading, you could write this:
|
|||
%}
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
Please note that some language backends (e.g. C# or Java) don't have any
|
||||
initialization function, hence you should define a global object performing
|
||||
the necessary initialization for them instead:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%init %{
|
||||
static struct MyInit { MyInit() { init_variables(); } } myInit;
|
||||
%}
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="SWIG_nn45">5.7 An Interface Building Strategy</a></H2>
|
||||
|
||||
|
||||
|
|
@ -3323,7 +3507,7 @@ interface to your program.
|
|||
SWIG's <tt>%include</tt> directive to process an entire C
|
||||
source/header file.
|
||||
|
||||
<li>Make sure everything in the interface file uses ANSI C/C++ syntax.
|
||||
<li>Make sure everything in the interface file uses ISO C/C++ syntax.
|
||||
|
||||
<li>Make sure all necessary `<tt>typedef</tt>' declarations and
|
||||
type-information is available in the interface file.
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -9,7 +9,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Scilab">39 SWIG and Scilab</a></H1>
|
||||
<H1><a name="Scilab">36 SWIG and Scilab</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -39,7 +39,7 @@
|
|||
</ul>
|
||||
<li><a href="#Scilab_wrapping_pointers">Pointers</a>
|
||||
<ul>
|
||||
<li><a href="#Scilab_wrapping_pointers_pointer_adresses">Utility functions</a>
|
||||
<li><a href="#Scilab_wrapping_pointers_utility_functions">Utility functions</a>
|
||||
<li><a href="#Scilab_wrapping_pointers_null_pointers">Null pointers:</a>
|
||||
</ul>
|
||||
<li><a href="#Scilab_wrapping_structs">Structures</a>
|
||||
|
|
@ -88,11 +88,11 @@ This chapter explains how to use SWIG for Scilab. After this introduction, you s
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Scilab_preliminaries">39.1 Preliminaries</a></H2>
|
||||
<H2><a name="Scilab_preliminaries">36.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG for Scilab supports Linux. Other operating sytems haven't been tested.
|
||||
SWIG for Scilab supports Linux. Other operating systems haven't been tested.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -105,7 +105,7 @@ SWIG for Scilab supports C language. C++ is partially supported. See <a href="#S
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Scilab_running_swig">39.2 Running SWIG</a></H2>
|
||||
<H2><a name="Scilab_running_swig">36.2 Running SWIG</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -121,15 +121,15 @@ In this example we bind from C a function and a global variable into Scilab. The
|
|||
double Foo = 3.0;
|
||||
|
||||
int fact(int n) {
|
||||
if (n < 0) {
|
||||
return 0;
|
||||
}
|
||||
else if (n == 0) {
|
||||
return 1;
|
||||
}
|
||||
else {
|
||||
return n * fact(n-1);
|
||||
}
|
||||
if (n < 0) {
|
||||
return 0;
|
||||
}
|
||||
else if (n == 0) {
|
||||
return 1;
|
||||
}
|
||||
else {
|
||||
return n * fact(n-1);
|
||||
}
|
||||
}
|
||||
%}
|
||||
</pre></div>
|
||||
|
|
@ -139,7 +139,7 @@ Note: a code in an <tt>%inline</tt> section is both parsed and wrapped by SWIG,
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Scilab_running_swig_generating_module">39.2.1 Generating the module</a></H3>
|
||||
<H3><a name="Scilab_running_swig_generating_module">36.2.1 Generating the module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -182,7 +182,7 @@ The <tt>swig</tt> executable has several other command line options you can use.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Scilab_running_swig_building_module">39.2.2 Building the module</a></H3>
|
||||
<H3><a name="Scilab_running_swig_building_module">36.2.2 Building the module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -202,7 +202,7 @@ $ gcc -shared example_wrap.o -o libexample.so
|
|||
Note: we supposed in this example that the path to the Scilab include directory is <tt>/usr/local/include/scilab</tt> (which is the case in a Debian environment), this should be changed for another environment.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_running_swig_loading_module">39.2.3 Loading the module</a></H3>
|
||||
<H3><a name="Scilab_running_swig_loading_module">36.2.3 Loading the module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -226,7 +226,7 @@ Link done.
|
|||
which means that Scilab has successfully loaded the shared library. The module functions and other symbols are now available in Scilab.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_running_swig_using_module">39.2.4 Using the module</a></H3>
|
||||
<H3><a name="Scilab_running_swig_using_module">36.2.4 Using the module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -260,7 +260,7 @@ ans =
|
|||
Note: for conciseness, we assume in the subsequent Scilab code examples that the modules have been beforehand built and loaded in Scilab.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_running_swig_options">39.2.5 Scilab command line options</a></H3>
|
||||
<H3><a name="Scilab_running_swig_options">36.2.5 Scilab command line options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -304,6 +304,11 @@ The following table lists the Scilab specific command line options in addition t
|
|||
<td>Generate the gateway XML with the given <gateway_id></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt>-targetversion</tt></td>
|
||||
<td>Generate for Scilab target (major) version</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
|
||||
<p>
|
||||
|
|
@ -315,10 +320,10 @@ $ swig -scilab -help
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H2><a name="Scilab_wrapping">39.3 A basic tour of C/C++ wrapping</a></H2>
|
||||
<H2><a name="Scilab_wrapping">36.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">36.3.1 Overview</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -327,18 +332,22 @@ This means that functions, structs, classes, variables, etc... are interfaced th
|
|||
There are a few exceptions, such as constants and enumerations, which can be wrapped directly as Scilab variables.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_wrapping_identifiers">39.3.2 Identifiers</a></H3>
|
||||
<H3><a name="Scilab_wrapping_identifiers">36.3.2 Identifiers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
In Scilab 5.x, identifier names are composed of 24 characters maximum (this limitation should disappear from Scilab 6.0 onwards).
|
||||
<br>Thus long function or variable names may be truncated and this can cause ambiguities.
|
||||
In Scilab 5.x, identifier names are composed of 24 characters maximum (this limitation disappears from Scilab 6.0 onwards).
|
||||
<br>By default, variable, member, and function names longer than 24 characters are truncated, and a warning is produced for each truncation.
|
||||
</p>
|
||||
<p>This happens especially when wrapping structs/classes, for which the wrapped function name is composed of the struct/class name and field names.
|
||||
<p>This can cause ambiguities, especially when wrapping structs/classes, for which the wrapped function name is composed of the struct/class name and field names.
|
||||
In these cases, the <a href="SWIG.html#SWIG_rename_ignore">%rename directive</a> can be used to choose a different Scilab name.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_wrapping_functions">39.3.3 Functions</a></H3>
|
||||
<p>
|
||||
Note: truncations can be disabled by specifying the target version 6 of Scilab in the <tt>targetversion</tt> argument (i.e. <tt>-targetversion 6</tt>).
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_wrapping_functions">36.3.3 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -369,7 +378,7 @@ ans =
|
|||
24.
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Scilab_nn13">39.3.3.1 Argument passing</a></H4>
|
||||
<H4><a name="Scilab_nn13">36.3.3.1 Argument passing</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -422,7 +431,7 @@ In Scilab, parameters are passed by value. The output (and inout) parameters are
|
|||
7.
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Scilab_nn14">39.3.3.2 Multiple output arguments</a></H4>
|
||||
<H4><a name="Scilab_nn14">36.3.3.2 Multiple output arguments</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -471,7 +480,7 @@ int divide(int n, int d, int *OUTPUT, int *OUTPUT);
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Scilab_wrapping_global_variables">39.3.4 Global variables</a></H3>
|
||||
<H3><a name="Scilab_wrapping_global_variables">36.3.4 Global variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -540,10 +549,10 @@ It works the same:</p>
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Scilab_wrapping_constants_and_enums">39.3.5 Constants and enumerations</a></H3>
|
||||
<H3><a name="Scilab_wrapping_constants_and_enums">36.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">36.3.5.1 Constants</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -684,7 +693,7 @@ are mapped to Scilab variables, with the same name:
|
|||
3.14
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Scilab_wrapping_enums">39.3.5.2 Enumerations</a></H4>
|
||||
<H4><a name="Scilab_wrapping_enums">36.3.5.2 Enumerations</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -749,14 +758,14 @@ typedef enum { RED, BLUE, GREEN } color;
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Scilab_wrapping_pointers">39.3.6 Pointers</a></H3>
|
||||
<H3><a name="Scilab_wrapping_pointers">36.3.6 Pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
Pointers are supported by SWIG. A pointer can be returned from a wrapped C/C++ function, stored in a Scilab variable, and used in input argument of another C/C++ function.
|
||||
</p>
|
||||
<p>
|
||||
Also, thanks to the SWIG runtime which stores informations about types, pointer types are tracked between exchanges Scilab and the native code. Indeed pointer types are stored alongside the pointer adress.
|
||||
Also, thanks to the SWIG runtime which stores information about types, pointer types are tracked between exchanges Scilab and the native code. Indeed pointer types are stored alongside the pointer address.
|
||||
A pointer is mapped to a Scilab structure (<a href="https://help.scilab.org/docs/5.5.2/en_US/tlist.html">tlist</a>), which contains as fields the pointer address and the pointer type (in fact a pointer to the type information structure in the SWIG runtime).
|
||||
<br>
|
||||
Why a native pointer is not mapped to a Scilab pointer (type name: "pointer", type ID: 128) ? The big advantage of mapping to a <tt>tlist</tt> is that it exposes a new type for the pointer in Scilab, type which can be acessed in Scilab with the <a href="https://help.scilab.org/docs/5.5.2/en_US/typeof.html">typeof</a> function, and manipulated using the <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a> mechanism.
|
||||
|
|
@ -811,7 +820,7 @@ Note: the type name <tt>_p_FILE</tt> which means "pointer to FILE".
|
|||
The user of a pointer is responsible for freeing it or, like in the example, closing any resources associated with it (just as is required in a C program).
|
||||
</p>
|
||||
|
||||
<H4><a name="Scilab_wrapping_pointers_pointer_adresses">39.3.6.1 Utility functions</a></H4>
|
||||
<H4><a name="Scilab_wrapping_pointers_utility_functions">36.3.6.1 Utility functions</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -852,7 +861,7 @@ ans =
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H4><a name="Scilab_wrapping_pointers_null_pointers">39.3.6.2 Null pointers:</a></H4>
|
||||
<H4><a name="Scilab_wrapping_pointers_null_pointers">36.3.6.2 Null pointers:</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -868,7 +877,7 @@ Using the previous <tt>SWIG_this()</tt> and <tt>SWIG_ptr()</tt>, it is possible
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Scilab_wrapping_structs">39.3.7 Structures</a></H3>
|
||||
<H3><a name="Scilab_wrapping_structs">36.3.7 Structures</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -887,8 +896,8 @@ Let's see it on an example of a struct with two members:
|
|||
%inline %{
|
||||
|
||||
typedef struct {
|
||||
int x;
|
||||
int arr[4];
|
||||
int x;
|
||||
int arr[4];
|
||||
} Foo;
|
||||
|
||||
%}
|
||||
|
|
@ -964,7 +973,7 @@ ans =
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
Note: the pointer to the struct works as described in <a href="Scilab_wrapping_pointers">Pointers</a>. For example, the type of the struct pointer can be get with <tt>typeof</tt>, as following:
|
||||
Note: the pointer to the struct works as described in <a href="#Scilab_wrapping_pointers">Pointers</a>. For example, the type of the struct pointer can be get with <tt>typeof</tt>, as following:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -977,7 +986,7 @@ Note: the pointer to the struct works as described in <a href="Scilab_wrapping_p
|
|||
--> delete_Bar(b);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Scilab_wrapping_cpp_classes">39.3.8 C++ classes</a></H3>
|
||||
<H3><a name="Scilab_wrapping_cpp_classes">36.3.8 C++ classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1028,7 +1037,7 @@ ans =
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
Note: like structs, class pointers are mapped as described in <a href="Scilab_wrapping_pointers">Pointers</a>. Let's give an example which shows that each class pointer type is a new type in Scilab that can be used for example (through <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a>) to implement a custom print for the <tt>Point</tt> class:
|
||||
Note: like structs, class pointers are mapped as described in <a href="#Scilab_wrapping_pointers">Pointers</a>. Let's give an example which shows that each class pointer type is a new type in Scilab that can be used for example (through <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a>) to implement a custom print for the <tt>Point</tt> class:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
@ -1045,7 +1054,7 @@ Note: like structs, class pointers are mapped as described in <a href="Scilab_wr
|
|||
--> delete_Point(p);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Scilab_wrapping_cpp_inheritance">39.3.9 C++ inheritance</a></H3>
|
||||
<H3><a name="Scilab_wrapping_cpp_inheritance">36.3.9 C++ inheritance</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1120,25 +1129,25 @@ But we can use either use the <tt>get_perimeter()</tt> function of the parent cl
|
|||
18.84
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Scilab_wrapping_cpp_overloading">39.3.10 C++ overloading</a></H3>
|
||||
<H3><a name="Scilab_wrapping_cpp_overloading">36.3.10 C++ overloading</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
As explained in <a href="SWIGPlus.html#SWIGPlus_overloaded_methods">6.15</a> SWIG provides support for overloaded functions and constructors.
|
||||
As explained in <a href="SWIGPlus.html#SWIGPlus_overloaded_methods">Overloaded functions and methods</a> SWIG provides support for overloaded functions and constructors.
|
||||
</p>
|
||||
|
||||
<p>As SWIG knows pointer types, the overloading works also with pointer types, here is is an example with a function <tt>magnify</tt> overloaded for the previous classes <tt>Shape</tt> and <tt>Circle</tt>:
|
||||
<p>As SWIG knows pointer types, the overloading works also with pointer types, here is an example with a function <tt>magnify</tt> overloaded for the previous classes <tt>Shape</tt> and <tt>Circle</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
%module example
|
||||
|
||||
void magnify(Square *square, double factor) {
|
||||
square->size *= factor;
|
||||
square->size *= factor;
|
||||
};
|
||||
|
||||
void magnify(Circle *circle, double factor) {
|
||||
square->radius *= factor;
|
||||
square->radius *= factor;
|
||||
};
|
||||
</pre></div>
|
||||
|
||||
|
|
@ -1160,7 +1169,7 @@ void magnify(Circle *circle, double factor) {
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Scilab_wrapping_pointers_references_values_arrays">39.3.11 Pointers, references, values, and arrays</a></H3>
|
||||
<H3><a name="Scilab_wrapping_pointers_references_values_arrays">36.3.11 Pointers, references, values, and arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1218,7 +1227,7 @@ All these functions will return a pointer to an instance of <tt>Foo</tt>.
|
|||
As the function <tt>spam7</tt> returns a value, new instance of <tt>Foo</tt> has to be allocated, and a pointer on this instance is returned.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_wrapping_cpp_templates">39.3.12 C++ templates</a></H3>
|
||||
<H3><a name="Scilab_wrapping_cpp_templates">36.3.12 C++ templates</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1277,7 +1286,7 @@ Then in Scilab:
|
|||
More details on template support can be found in the <a href="SWIGPlus.html#SWIGPlus_nn30">templates</a> documentation.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_wrapping_cpp_operators">39.3.13 C++ operators</a></H3>
|
||||
<H3><a name="Scilab_wrapping_cpp_operators">36.3.13 C++ operators</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1330,7 +1339,7 @@ private:
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Scilab_wrapping_cpp_namespaces">39.3.14 C++ namespaces</a></H3>
|
||||
<H3><a name="Scilab_wrapping_cpp_namespaces">36.3.14 C++ namespaces</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1408,7 +1417,7 @@ Note: the <a href="SWIGPlus.html#SWIGPlus_nspace">nspace</a> feature is not supp
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Scilab_wrapping_cpp_exceptions">39.3.15 C++ exceptions</a></H3>
|
||||
<H3><a name="Scilab_wrapping_cpp_exceptions">36.3.15 C++ exceptions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1432,7 +1441,7 @@ void throw_exception() throw(char const *) {
|
|||
<div class="targetlang"><pre>
|
||||
-->throw_exception()
|
||||
!--error 999
|
||||
SWIG/Scilab: Exception (char const *) occured: Bye world !
|
||||
SWIG/Scilab: Exception (char const *) occurred: Bye world !
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -1449,7 +1458,7 @@ It can be used with the <tt>lasterror()</tt> function as following:
|
|||
--> lasterror()
|
||||
ans =
|
||||
|
||||
SWIG/Scilab: Exception (char const *) occured: Bye world !
|
||||
SWIG/Scilab: Exception (char const *) occurred: Bye world !
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -1479,7 +1488,7 @@ void throw_stl_invalid_arg(int i) throw(std::invalid_argument) {
|
|||
<div class="targetlang"><pre>
|
||||
--> throw_int();
|
||||
!--error 999
|
||||
SWIG/Scilab: Exception (int) occured: 12
|
||||
SWIG/Scilab: Exception (int) occurred: 12
|
||||
|
||||
-->throw_stl_invalid_arg(-1);
|
||||
!--error 999
|
||||
|
|
@ -1491,17 +1500,17 @@ More complex or custom exception types require specific exception typemaps to be
|
|||
See the <a href="SWIGPlus.html#SWIGPlus">SWIG C++ documentation</a> for more details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_wrapping_cpp_stl">39.3.16 C++ STL</a></H3>
|
||||
<H3><a name="Scilab_wrapping_cpp_stl">36.3.16 C++ STL</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
The Standard Template Library (STL) is partially supported. See <a href="#Scilab_typemaps_stl">STL</a> for more details.
|
||||
</p>
|
||||
|
||||
<H2><a name="Scilab_typemaps">39.4 Type mappings and libraries</a></H2>
|
||||
<H2><a name="Scilab_typemaps">36.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">36.4.1 Default primitive type mappings</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1552,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">36.4.2 Arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1607,15 +1616,15 @@ void printArray(int values[], int len) {
|
|||
[ 0 1 2 3 ]
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Scilab_typemaps_pointer-to-pointers">39.4.3 Pointer-to-pointers</a></H3>
|
||||
<H3><a name="Scilab_typemaps_pointer-to-pointers">36.4.3 Pointer-to-pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
There are no specific typemaps for pointer-to-pointers, they are are mapped as pointers in Scilab.
|
||||
There are no specific typemaps for pointer-to-pointers, they are mapped as pointers in Scilab.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Pointer-to-pointers are sometimes used to implement matrices in C. The following is a an example of this:
|
||||
Pointer-to-pointers are sometimes used to implement matrices in C. The following is an example of this:
|
||||
</p>
|
||||
|
||||
|
||||
|
|
@ -1680,7 +1689,7 @@ void print_matrix(double **M, int nbRows, int nbCols) {
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Scilab_typemaps_matrices">39.4.4 Matrices</a></H3>
|
||||
<H3><a name="Scilab_typemaps_matrices">36.4.4 Matrices</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1773,7 +1782,7 @@ The remarks made earlier for arrays also apply here:
|
|||
<li>There is no control while converting <tt>double</tt> values to integers, <tt>double</tt> values are truncated without any checking or warning.</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Scilab_typemaps_stl">39.4.5 STL</a></H3>
|
||||
<H3><a name="Scilab_typemaps_stl">36.4.5 STL</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1973,7 +1982,7 @@ ans =
|
|||
--> delete_PersonPtrSet(p);
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Scilab_module_initialization">39.5 Module initialization</a></H2>
|
||||
<H2><a name="Scilab_module_initialization">36.5 Module initialization</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1997,7 +2006,7 @@ For example, to initialize the module <tt>example</tt>:
|
|||
--> example_Init();
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Scilab_building_modes">39.6 Building modes</a></H2>
|
||||
<H2><a name="Scilab_building_modes">36.6 Building modes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2012,7 +2021,7 @@ To produce a dynamic module, when generating the wrapper, there are two possibil
|
|||
<li>the <tt>builder</tt> mode. In this mode, Scilab is responsible of building.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Scilab_building_modes_nobuilder_mode">39.6.1 No-builder mode</a></H3>
|
||||
<H3><a name="Scilab_building_modes_nobuilder_mode">36.6.1 No-builder mode</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2025,7 +2034,7 @@ This mode is the best option to use when you have to integrate the module build
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Scilab_building_modes_builder_mode">39.6.2 Builder mode</a></H3>
|
||||
<H3><a name="Scilab_building_modes_builder_mode">36.6.2 Builder mode</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2053,7 +2062,7 @@ In this mode, the following SWIG options may be used to setup the build:
|
|||
Let's give an example how to build a module <tt>example</tt>, composed of two sources, and using a library dependency:
|
||||
</p>
|
||||
<ul>
|
||||
<li>the sources are <tt>baa1.c</tt> and <tt>baa2.c</tt> (and are stored in in the current directory)</li>
|
||||
<li>the sources are <tt>baa1.c</tt> and <tt>baa2.c</tt> (and are stored in the current directory)</li>
|
||||
<li>the library is <tt>libfoo</tt> in <tt>/opt/foo</tt> (headers stored in <tt>/opt/foo/include</tt>, and shared library in <tt>/opt/foo/lib</tt>)</li>
|
||||
</ul>
|
||||
|
||||
|
|
@ -2065,14 +2074,14 @@ The command is:
|
|||
$ swig -scilab -builder -buildercflags -I/opt/foo/include -builderldflags "-L/opt/foo/lib -lfoo" -buildersources baa1.cxx, baa2.cxx example.i
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Scilab_generated_scripts">39.7 Generated scripts</a></H2>
|
||||
<H2><a name="Scilab_generated_scripts">36.7 Generated scripts</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
In this part we give some details about the generated Scilab scripts.
|
||||
</p>
|
||||
|
||||
<H3><a name="Scilab_generated_scripts_builder_script">39.7.1 Builder script</a></H3>
|
||||
<H3><a name="Scilab_generated_scripts_builder_script">36.7.1 Builder script</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2097,7 +2106,7 @@ ilib_build(ilib_name, table, files, libs);
|
|||
<li><tt><b>table</b></tt>: two column string matrix containing a table of pairs of 'scilab function name', 'C function name'.</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Scilab_generated_scripts_loader_script">39.7.2 Loader script</a></H3>
|
||||
<H3><a name="Scilab_generated_scripts_loader_script">36.7.2 Loader script</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2136,7 +2145,7 @@ clear get_file_path;
|
|||
</ul>
|
||||
|
||||
|
||||
<H2><a name="Scilab_other_resources">39.8 Other resources</a></H2>
|
||||
<H2><a name="Scilab_other_resources">36.8 Other resources</a></H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG-3.0 Documentation</title>
|
||||
<title>SWIG-4.0 Documentation</title>
|
||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Sections">SWIG-3.0 Documentation</a></H1>
|
||||
<H1><a name="Sections">SWIG-4.0 Documentation</a></H1>
|
||||
|
||||
<p>
|
||||
Last update : SWIG-3.0.12 (in progress)
|
||||
Last update : SWIG-4.1.0 (in progress)
|
||||
</p>
|
||||
|
||||
<H2><a name="Sections_Sections">Sections</a></H2>
|
||||
|
|
@ -22,6 +22,9 @@ Last update : SWIG-3.0.12 (in progress)
|
|||
<li><a href="SWIG.html#SWIG">SWIG Basics</a> (Read this!)</li>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a></li>
|
||||
<li><a href="CPlusPlus11.html#CPlusPlus11">SWIG and C++11</a></li>
|
||||
<li><a href="CPlusPlus14.html#CPlusPlus14">SWIG and C++14</a></li>
|
||||
<li><a href="CPlusPlus17.html#CPlusPlus17">SWIG and C++17</a></li>
|
||||
<li><a href="CPlusPlus20.html#CPlusPlus20">SWIG and C++20</a></li>
|
||||
<li><a href="Preprocessor.html#Preprocessor">The SWIG preprocessor</a></li>
|
||||
<li><a href="Library.html#Library">The SWIG library</a></li>
|
||||
<li><a href="Arguments.html#Arguments">Argument handling</a></li>
|
||||
|
|
@ -29,32 +32,26 @@ Last update : SWIG-3.0.12 (in progress)
|
|||
<li><a href="Customization.html#Customization">Customization features</a></li>
|
||||
<li><a href="Contract.html#Contract">Contracts</a></li>
|
||||
<li><a href="Varargs.html#Varargs">Variable length arguments</a></li>
|
||||
<li><a href="Doxygen.html#Doxygen">Doxygen documentation comments</a></li>
|
||||
<li><a href="Warnings.html#Warnings">Warning messages</a></li>
|
||||
<li><a href="Modules.html#Modules">Working with Modules</a></li>
|
||||
<li><a href="CCache.html#CCache">Using SWIG with ccache</a></li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Sections_language_modules">Language Module Documentation</a></H3>
|
||||
<H3><a name="Sections_language_modules">Supported Language Modules Documentation</a></H3>
|
||||
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl">Allegro Common Lisp support</a></li>
|
||||
<li><a href="Android.html#Android">Android support</a></li>
|
||||
<li><a href="CSharp.html#CSharp">C# support</a></li>
|
||||
<li><a href="Chicken.html#Chicken">Chicken support</a></li>
|
||||
<li><a href="D.html#D">D support</a></li>
|
||||
<li><a href="Go.html#Go">Go support</a></li>
|
||||
<li><a href="Guile.html#Guile">Guile support</a></li>
|
||||
<li><a href="Java.html#Java">Java support</a></li>
|
||||
<li><a href="Javascript.html#Javascript">Javascript support</a></li>
|
||||
<li><a href="Lisp.html#Lisp">Common Lisp support</a></li>
|
||||
<li><a href="Lua.html#Lua">Lua support</a></li>
|
||||
<li><a href="Modula3.html#Modula3">Modula3 support</a></li>
|
||||
<li><a href="Mzscheme.html#Mzscheme">MzScheme/Racket support</a></li>
|
||||
<li><a href="Ocaml.html#Ocaml">Ocaml support</a></li>
|
||||
<li><a href="Octave.html#Octave">Octave support</a></li>
|
||||
<li><a href="Perl5.html#Perl5">Perl5 support</a></li>
|
||||
<li><a href="Php.html#Php">PHP support</a></li>
|
||||
<li><a href="Pike.html#Pike">Pike support</a></li>
|
||||
<li><a href="Python.html#Python">Python support</a></li>
|
||||
<li><a href="R.html#R">R support</a></li>
|
||||
<li><a href="Ruby.html#Ruby">Ruby support</a></li>
|
||||
|
|
@ -62,6 +59,13 @@ Last update : SWIG-3.0.12 (in progress)
|
|||
<li><a href="Tcl.html#Tcl">Tcl support</a></li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Sections_experimental_language_modules">Experimental Language Modules Documentation</a></H3>
|
||||
|
||||
<ul>
|
||||
<li><a href="Mzscheme.html#Mzscheme">MzScheme/Racket support</a></li>
|
||||
<li><a href="Ocaml.html#Ocaml">OCaml support</a></li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Sections_developers_docs">Developer Documentation</a></H3>
|
||||
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Tcl">40 SWIG and Tcl</a></H1>
|
||||
<H1><a name="Tcl">37 SWIG and Tcl</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -84,11 +84,11 @@ Tcl 8.0 or a later release. Earlier releases of SWIG supported Tcl 7.x, but
|
|||
this is no longer supported.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn2">40.1 Preliminaries</a></H2>
|
||||
<H2><a name="Tcl_nn2">37.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
To build a Tcl module, run SWIG using the <tt>-tcl</tt> option :
|
||||
To build a Tcl module, run SWIG using the <tt>-tcl</tt> or <tt>-tcl8</tt> option :
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -110,7 +110,7 @@ build a Tcl extension module. To finish building the module, you
|
|||
need to compile this file and link it with the rest of your program.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn3">40.1.1 Getting the right header files</a></H3>
|
||||
<H3><a name="Tcl_nn3">37.1.1 Getting the right header files</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -128,7 +128,7 @@ this is the case, you should probably make a symbolic link so that <tt>tcl.h</tt
|
|||
header file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn4">40.1.2 Compiling a dynamic module</a></H3>
|
||||
<H3><a name="Tcl_nn4">37.1.2 Compiling a dynamic module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -164,7 +164,7 @@ The name of the module is specified using the <tt>%module</tt> directive or the
|
|||
<tt>-module</tt> command line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn5">40.1.3 Static linking</a></H3>
|
||||
<H3><a name="Tcl_nn5">37.1.3 Static linking</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -230,7 +230,7 @@ minimal in most situations (and quite frankly not worth the extra
|
|||
hassle in the opinion of this author).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn6">40.1.4 Using your module</a></H3>
|
||||
<H3><a name="Tcl_nn6">37.1.4 Using your module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -358,7 +358,7 @@ to the default system configuration (this requires root access and you will need
|
|||
the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn7">40.1.5 Compilation of C++ extensions</a></H3>
|
||||
<H3><a name="Tcl_nn7">37.1.5 Compilation of C++ extensions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -441,7 +441,7 @@ erratic program behavior. If working with lots of software components, you
|
|||
might want to investigate using a more formal standard such as COM.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn8">40.1.6 Compiling for 64-bit platforms</a></H3>
|
||||
<H3><a name="Tcl_nn8">37.1.6 Compiling for 64-bit platforms</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -468,7 +468,7 @@ also introduce problems on platforms that support more than one
|
|||
linking standard (e.g., -o32 and -n32 on Irix).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn9">40.1.7 Setting a package prefix</a></H3>
|
||||
<H3><a name="Tcl_nn9">37.1.7 Setting a package prefix</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -487,7 +487,7 @@ option will append the prefix to the name when creating a command and
|
|||
call it "<tt>Foo_bar</tt>".
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn10">40.1.8 Using namespaces</a></H3>
|
||||
<H3><a name="Tcl_nn10">37.1.8 Using namespaces</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -509,7 +509,7 @@ When the <tt>-namespace</tt> option is used, objects in the module
|
|||
are always accessed with the namespace name such as <tt>Foo::bar</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn11">40.2 Building Tcl/Tk Extensions under Windows 95/NT</a></H2>
|
||||
<H2><a name="Tcl_nn11">37.2 Building Tcl/Tk Extensions under Windows 95/NT</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -520,7 +520,7 @@ covers the process of using SWIG with Microsoft Visual C++.
|
|||
although the procedure may be similar with other compilers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn12">40.2.1 Running SWIG from Developer Studio</a></H3>
|
||||
<H3><a name="Tcl_nn12">37.2.1 Running SWIG from Developer Studio</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -578,7 +578,7 @@ MSDOS > tclsh80
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn13">40.2.2 Using NMAKE</a></H3>
|
||||
<H3><a name="Tcl_nn13">37.2.2 Using NMAKE</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -641,7 +641,7 @@ to get you started. With a little practice, you'll be making lots of
|
|||
Tcl extensions.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn14">40.3 A tour of basic C/C++ wrapping</a></H2>
|
||||
<H2><a name="Tcl_nn14">37.3 A tour of basic C/C++ wrapping</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -652,7 +652,7 @@ classes. This section briefly covers the essential aspects of this
|
|||
wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn15">40.3.1 Modules</a></H3>
|
||||
<H3><a name="Tcl_nn15">37.3.1 Modules</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -686,7 +686,7 @@ To fix this, supply an extra argument to <tt>load</tt> like this:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn16">40.3.2 Functions</a></H3>
|
||||
<H3><a name="Tcl_nn16">37.3.2 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -711,7 +711,7 @@ like you think it does:
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn17">40.3.3 Global variables</a></H3>
|
||||
<H3><a name="Tcl_nn17">37.3.3 Global variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -791,7 +791,7 @@ extern char *path; // Read-only (due to %immutable)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn18">40.3.4 Constants and enums</a></H3>
|
||||
<H3><a name="Tcl_nn18">37.3.4 Constants and enums</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -875,7 +875,7 @@ When an identifier name is given, it is used to perform an implicit hash-table l
|
|||
conversion. This allows the <tt>global</tt> statement to be omitted.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn19">40.3.5 Pointers</a></H3>
|
||||
<H3><a name="Tcl_nn19">37.3.5 Pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -958,7 +958,7 @@ Foo *BarToFoo(Bar *b) {
|
|||
}
|
||||
|
||||
Foo *IncrFoo(Foo *f, int i) {
|
||||
return f+i;
|
||||
return f+i;
|
||||
}
|
||||
%}
|
||||
</pre>
|
||||
|
|
@ -971,7 +971,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
|
|||
<tt>None</tt> if the conversion can't be performed.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn20">40.3.6 Structures</a></H3>
|
||||
<H3><a name="Tcl_nn20">37.3.6 Structures</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1054,7 +1054,7 @@ example, consider this:
|
|||
<div class="code">
|
||||
<pre>
|
||||
struct Bar {
|
||||
int x[16];
|
||||
int x[16];
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1253,7 +1253,7 @@ Note: Tcl only destroys the underlying object if it has ownership. See the
|
|||
memory management section that appears shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn21">40.3.7 C++ classes</a></H3>
|
||||
<H3><a name="Tcl_nn21">37.3.7 C++ classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1319,7 +1319,7 @@ In Tcl, the static member is accessed as follows:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn22">40.3.8 C++ inheritance</a></H3>
|
||||
<H3><a name="Tcl_nn22">37.3.8 C++ inheritance</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1368,7 +1368,7 @@ For instance:
|
|||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn23">40.3.9 Pointers, references, values, and arrays</a></H3>
|
||||
<H3><a name="Tcl_nn23">37.3.9 Pointers, references, values, and arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1422,7 +1422,7 @@ to hold the result and a pointer is returned (Tcl will release this memory
|
|||
when the return value is garbage collected).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn24">40.3.10 C++ overloaded functions</a></H3>
|
||||
<H3><a name="Tcl_nn24">37.3.10 C++ overloaded functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1456,9 +1456,9 @@ Similarly, if you have a class like this,
|
|||
<pre>
|
||||
class Foo {
|
||||
public:
|
||||
Foo();
|
||||
Foo(const Foo &);
|
||||
...
|
||||
Foo();
|
||||
Foo(const Foo &);
|
||||
...
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1545,7 +1545,7 @@ first declaration takes precedence.
|
|||
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn25">40.3.11 C++ operators</a></H3>
|
||||
<H3><a name="Tcl_nn25">37.3.11 C++ operators</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1647,7 +1647,7 @@ There are ways to make this operator appear as part of the class using the <tt>%
|
|||
Keep reading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn26">40.3.12 C++ namespaces</a></H3>
|
||||
<H3><a name="Tcl_nn26">37.3.12 C++ namespaces</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1693,11 +1693,11 @@ For example:
|
|||
%rename(Bar_spam) Bar::spam;
|
||||
|
||||
namespace Foo {
|
||||
int spam();
|
||||
int spam();
|
||||
}
|
||||
|
||||
namespace Bar {
|
||||
int spam();
|
||||
int spam();
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1711,7 +1711,7 @@ utilizes thousands of small deeply nested namespaces each with
|
|||
identical symbol names, well, then you get what you deserve.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn27">40.3.13 C++ templates</a></H3>
|
||||
<H3><a name="Tcl_nn27">37.3.13 C++ templates</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1763,7 +1763,7 @@ More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</
|
|||
examples will appear later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn28">40.3.14 C++ Smart Pointers</a></H3>
|
||||
<H3><a name="Tcl_nn28">37.3.14 C++ Smart Pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1847,7 +1847,7 @@ simply use the <tt>__deref__()</tt> method. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn29">40.4 Further details on the Tcl class interface</a></H2>
|
||||
<H2><a name="Tcl_nn29">37.4 Further details on the Tcl class interface</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1860,7 +1860,7 @@ of low-level details were omitted. This section provides a brief overview
|
|||
of how the proxy classes work.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn30">40.4.1 Proxy classes</a></H3>
|
||||
<H3><a name="Tcl_nn30">37.4.1 Proxy classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1886,19 +1886,19 @@ then SWIG transforms it into a set of low-level procedural wrappers. For example
|
|||
<div class="code">
|
||||
<pre>
|
||||
Foo *new_Foo() {
|
||||
return new Foo();
|
||||
return new Foo();
|
||||
}
|
||||
void delete_Foo(Foo *f) {
|
||||
delete f;
|
||||
delete f;
|
||||
}
|
||||
int Foo_x_get(Foo *f) {
|
||||
return f->x;
|
||||
return f->x;
|
||||
}
|
||||
void Foo_x_set(Foo *f, int value) {
|
||||
f->x = value;
|
||||
f->x = value;
|
||||
}
|
||||
int Foo_spam(Foo *f, int arg1) {
|
||||
return f->spam(arg1);
|
||||
return f->spam(arg1);
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1925,7 +1925,7 @@ function. This allows objects to be encapsulated objects that look a lot like
|
|||
as shown in the last section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn31">40.4.2 Memory management</a></H3>
|
||||
<H3><a name="Tcl_nn31">37.4.2 Memory management</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1945,8 +1945,8 @@ ownership of the result. For example:
|
|||
<pre>
|
||||
class Foo {
|
||||
public:
|
||||
Foo();
|
||||
Foo bar();
|
||||
Foo();
|
||||
Foo bar();
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1975,9 +1975,9 @@ they came from. Therefore, the ownership is set to zero. For example:
|
|||
<pre>
|
||||
class Foo {
|
||||
public:
|
||||
...
|
||||
Foo *spam();
|
||||
...
|
||||
...
|
||||
Foo *spam();
|
||||
...
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -2011,8 +2011,8 @@ or global variable. For example, consider this interface:
|
|||
%module example
|
||||
|
||||
struct Foo {
|
||||
int value;
|
||||
Foo *next;
|
||||
int value;
|
||||
Foo *next;
|
||||
};
|
||||
|
||||
Foo *head = 0;
|
||||
|
|
@ -2113,7 +2113,7 @@ typemaps--an advanced topic discussed later.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Tcl_nn32">40.5 Input and output parameters</a></H2>
|
||||
<H2><a name="Tcl_nn32">37.5 Input and output parameters</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2301,7 +2301,7 @@ set c [lindex $dim 1]
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn33">40.6 Exception handling </a></H2>
|
||||
<H2><a name="Tcl_nn33">37.6 Exception handling </a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2435,7 +2435,7 @@ Since SWIG's exception handling is user-definable, you are not limited to C++ ex
|
|||
See the chapter on "<a href="Customization.html#Customization">Customization Features</a>" for more examples.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn34">40.7 Typemaps</a></H2>
|
||||
<H2><a name="Tcl_nn34">37.7 Typemaps</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2452,7 +2452,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Tcl interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn35">40.7.1 What is a typemap?</a></H3>
|
||||
<H3><a name="Tcl_nn35">37.7.1 What is a typemap?</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2465,9 +2465,9 @@ you might define a typemap like this:
|
|||
%module example
|
||||
|
||||
%typemap(in) int {
|
||||
if (Tcl_GetIntFromObj(interp, $input, &$1) == TCL_ERROR)
|
||||
return TCL_ERROR;
|
||||
printf("Received an integer : %d\n", $1);
|
||||
if (Tcl_GetIntFromObj(interp, $input, &$1) == TCL_ERROR)
|
||||
return TCL_ERROR;
|
||||
printf("Received an integer : %d\n", $1);
|
||||
}
|
||||
%inline %{
|
||||
extern int fact(int n);
|
||||
|
|
@ -2572,7 +2572,7 @@ parameter is omitted):
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn36">40.7.2 Tcl typemaps</a></H3>
|
||||
<H3><a name="Tcl_nn36">37.7.2 Tcl typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2585,7 +2585,7 @@ like this:
|
|||
<div class="code">
|
||||
<pre>
|
||||
%typemap(out) int {
|
||||
Tcl_SetObjResult(interp, Tcl_NewIntObj($1));
|
||||
Tcl_SetObjResult(interp, Tcl_NewIntObj($1));
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -2710,7 +2710,7 @@ Initialize an argument to a value before any conversions occur.
|
|||
Examples of these methods will appear shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn37">40.7.3 Typemap variables</a></H3>
|
||||
<H3><a name="Tcl_nn37">37.7.3 Typemap variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2781,7 +2781,7 @@ properly assigned.
|
|||
The Tcl name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn38">40.7.4 Converting a Tcl list to a char ** </a></H3>
|
||||
<H3><a name="Tcl_nn38">37.7.4 Converting a Tcl list to a char ** </a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2843,7 +2843,7 @@ argv[2] = Larry
|
|||
3
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn39">40.7.5 Returning values in arguments</a></H3>
|
||||
<H3><a name="Tcl_nn39">37.7.5 Returning values in arguments</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2885,7 +2885,7 @@ result, a Tcl function using these typemaps will work like this :
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn40">40.7.6 Useful functions</a></H3>
|
||||
<H3><a name="Tcl_nn40">37.7.6 Useful functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2961,7 +2961,7 @@ int Tcl_IsShared(Tcl_Obj *obj);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn41">40.7.7 Standard typemaps</a></H3>
|
||||
<H3><a name="Tcl_nn41">37.7.7 Standard typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3045,7 +3045,7 @@ work)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn42">40.7.8 Pointer handling</a></H3>
|
||||
<H3><a name="Tcl_nn42">37.7.8 Pointer handling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3127,7 +3127,7 @@ For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn43">40.8 Turning a SWIG module into a Tcl Package.</a></H2>
|
||||
<H2><a name="Tcl_nn43">37.8 Turning a SWIG module into a Tcl Package.</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3199,7 +3199,7 @@ As a final note, most SWIG examples do not yet use the
|
|||
to use the <tt>load</tt> command instead.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn44">40.9 Building new kinds of Tcl interfaces (in Tcl)</a></H2>
|
||||
<H2><a name="Tcl_nn44">37.9 Building new kinds of Tcl interfaces (in Tcl)</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3215,28 +3215,28 @@ helper functions to access arrays :
|
|||
|
||||
%inline %{
|
||||
double *new_double(int size) {
|
||||
return (double *) malloc(size*sizeof(double));
|
||||
return (double *) malloc(size*sizeof(double));
|
||||
}
|
||||
void delete_double(double *a) {
|
||||
free(a);
|
||||
free(a);
|
||||
}
|
||||
double get_double(double *a, int index) {
|
||||
return a[index];
|
||||
return a[index];
|
||||
}
|
||||
void set_double(double *a, int index, double val) {
|
||||
a[index] = val;
|
||||
a[index] = val;
|
||||
}
|
||||
int *new_int(int size) {
|
||||
return (int *) malloc(size*sizeof(int));
|
||||
return (int *) malloc(size*sizeof(int));
|
||||
}
|
||||
void delete_int(int *a) {
|
||||
free(a);
|
||||
free(a);
|
||||
}
|
||||
int get_int(int *a, int index) {
|
||||
return a[index];
|
||||
return a[index];
|
||||
}
|
||||
int set_int(int *a, int index, int val) {
|
||||
a[index] = val;
|
||||
a[index] = val;
|
||||
}
|
||||
%}
|
||||
|
||||
|
|
@ -3298,7 +3298,7 @@ danger of blowing something up (although it is easily accomplished
|
|||
with an out of bounds array access).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn45">40.9.1 Proxy classes</a></H3>
|
||||
<H3><a name="Tcl_nn45">37.9.1 Proxy classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3419,7 +3419,7 @@ short, but clever Tcl script can be combined with SWIG to do many
|
|||
interesting things.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn46">40.10 Tcl/Tk Stubs</a></H2>
|
||||
<H2><a name="Tcl_nn46">37.10 Tcl/Tk Stubs</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Varargs">14 Variable Length Arguments</a></H1>
|
||||
<H1><a name="Varargs">17 Variable Length Arguments</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -43,7 +43,7 @@ added in SWIG-1.3.12. Most other wrapper generation tools have
|
|||
wisely chosen to avoid this issue.
|
||||
</p>
|
||||
|
||||
<H2><a name="Varargs_nn2">14.1 Introduction</a></H2>
|
||||
<H2><a name="Varargs_nn2">17.1 Introduction</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -140,7 +140,7 @@ List make_list(const char *s, ...) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Varargs_nn3">14.2 The Problem</a></H2>
|
||||
<H2><a name="Varargs_nn3">17.2 The Problem</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -233,7 +233,7 @@ can also support real varargs wrapping (with stack-frame manipulation) if you
|
|||
are willing to get hands dirty. Keep reading.
|
||||
</p>
|
||||
|
||||
<H2><a name="Varargs_nn4">14.3 Default varargs support</a></H2>
|
||||
<H2><a name="Varargs_nn4">17.3 Default varargs support</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -302,7 +302,7 @@ Read on for further solutions.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Varargs_nn5">14.4 Argument replacement using %varargs</a></H2>
|
||||
<H2><a name="Varargs_nn5">17.4 Argument replacement using %varargs</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -413,7 +413,7 @@ mixed argument types such as <tt>printf()</tt>. Providing general purpose
|
|||
wrappers to such functions presents special problems (covered shortly).
|
||||
</p>
|
||||
|
||||
<H2><a name="Varargs_nn6">14.5 Varargs and typemaps</a></H2>
|
||||
<H2><a name="Varargs_nn6">17.5 Varargs and typemaps</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -423,8 +423,8 @@ Variable length arguments may be used in typemap specifications. For example:
|
|||
<div class="code">
|
||||
<pre>
|
||||
%typemap(in) (...) {
|
||||
// Get variable length arguments (somehow)
|
||||
...
|
||||
// Get variable length arguments (somehow)
|
||||
...
|
||||
}
|
||||
|
||||
%typemap(in) (const char *fmt, ...) {
|
||||
|
|
@ -529,8 +529,11 @@ like this:
|
|||
SWIG_fail;
|
||||
}
|
||||
pystr = PyUnicode_AsUTF8String(pyobj);
|
||||
if (!pystr) {
|
||||
SWIG_fail;
|
||||
}
|
||||
str = strdup(PyBytes_AsString(pystr));
|
||||
Py_XDECREF(pystr);
|
||||
Py_DECREF(pystr);
|
||||
%#else
|
||||
if (!PyString_Check(pyobj)) {
|
||||
PyErr_SetString(PyExc_ValueError, "Expected a string");
|
||||
|
|
@ -590,7 +593,7 @@ really want to elevate your guru status and increase your job
|
|||
security, continue to the next section.
|
||||
</p>
|
||||
|
||||
<H2><a name="Varargs_nn7">14.6 Varargs wrapping with libffi</a></H2>
|
||||
<H2><a name="Varargs_nn7">17.6 Varargs wrapping with libffi</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -842,7 +845,7 @@ provide an argument number for the first extra argument. This can be used to in
|
|||
values. Please consult the chapter on each language module for more details.
|
||||
</p>
|
||||
|
||||
<H2><a name="Varargs_nn8">14.7 Wrapping of va_list</a></H2>
|
||||
<H2><a name="Varargs_nn8">17.7 Wrapping of va_list</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -896,7 +899,7 @@ int my_vprintf(const char *fmt, ...) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Varargs_nn9">14.8 C++ Issues</a></H2>
|
||||
<H2><a name="Varargs_nn9">17.8 C++ Issues</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -965,7 +968,7 @@ design or to provide an alternative interface using a helper function than it is
|
|||
fully general wrapper to a varargs C++ member function.
|
||||
</p>
|
||||
|
||||
<H2><a name="Varargs_nn10">14.9 Discussion</a></H2>
|
||||
<H2><a name="Varargs_nn10">17.9 Discussion</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Warnings">15 Warning Messages</a></H1>
|
||||
<H1><a name="Warnings">19 Warning Messages</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -25,7 +25,8 @@
|
|||
<li><a href="#Warnings_nn11">Preprocessor (200-299)</a>
|
||||
<li><a href="#Warnings_nn12">C/C++ Parser (300-399)</a>
|
||||
<li><a href="#Warnings_nn13">Types and typemaps (400-499) </a>
|
||||
<li><a href="#Warnings_nn14">Code generation (500-599)</a>
|
||||
<li><a href="#Warnings_nn14">Code generation (500-559)</a>
|
||||
<li><a href="#Warnings_doxygen">Doxygen comments (560-599)</a>
|
||||
<li><a href="#Warnings_nn15">Language module specific (700-899) </a>
|
||||
<li><a href="#Warnings_nn16">User defined (900-999)</a>
|
||||
</ul>
|
||||
|
|
@ -36,7 +37,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="Warnings_nn2">15.1 Introduction</a></H2>
|
||||
<H2><a name="Warnings_nn2">19.1 Introduction</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -56,7 +57,7 @@ where the generated wrapper code will probably compile, but it may not
|
|||
work like you expect.
|
||||
</p>
|
||||
|
||||
<H2><a name="Warnings_suppression">15.2 Warning message suppression</a></H2>
|
||||
<H2><a name="Warnings_suppression">19.2 Warning message suppression</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -148,7 +149,7 @@ your interface. Ignore the warning messages at your own peril.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Warnings_nn4">15.3 Enabling extra warnings</a></H2>
|
||||
<H2><a name="Warnings_nn4">19.3 Enabling extra warnings</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -221,7 +222,7 @@ that is, any warnings suppressed or added in <tt>%warnfilter</tt>, <tt>#pragma S
|
|||
or the <tt>-w</tt> option.
|
||||
</p>
|
||||
|
||||
<H2><a name="Warnings_nn5">15.4 Issuing a warning message</a></H2>
|
||||
<H2><a name="Warnings_nn5">19.4 Issuing a warning message</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -275,7 +276,7 @@ example.i:24: Warning 901: You are really going to regret this usage of blah * s
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Warnings_symbolic_symbols">15.5 Symbolic symbols</a></H2>
|
||||
<H2><a name="Warnings_symbolic_symbols">19.5 Symbolic symbols</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -310,7 +311,7 @@ or
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Warnings_nn6">15.6 Commentary</a></H2>
|
||||
<H2><a name="Warnings_nn6">19.6 Commentary</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -327,7 +328,7 @@ no obvious recovery. There is no mechanism for suppressing error
|
|||
messages.
|
||||
</p>
|
||||
|
||||
<H2><a name="Warnings_nn7">15.7 Warnings as errors</a></H2>
|
||||
<H2><a name="Warnings_nn7">19.7 Warnings as errors</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -336,7 +337,7 @@ option. This will cause SWIG to exit with a non successful exit code if a
|
|||
warning is encountered.
|
||||
</p>
|
||||
|
||||
<H2><a name="Warnings_nn8">15.8 Message output format</a></H2>
|
||||
<H2><a name="Warnings_nn8">19.8 Message output format</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -355,10 +356,10 @@ $ swig -python -Fmicrosoft example.i
|
|||
example.i(4) : Syntax error in input(1).
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Warnings_nn9">15.9 Warning number reference</a></H2>
|
||||
<H2><a name="Warnings_nn9">19.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">19.9.1 Deprecated features (100-199)</a></H3>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -386,7 +387,7 @@ example.i(4) : Syntax error in input(1).
|
|||
<li>126. The 'nestedworkaround' feature is deprecated.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn11">15.9.2 Preprocessor (200-299)</a></H3>
|
||||
<H3><a name="Warnings_nn11">19.9.2 Preprocessor (200-299)</a></H3>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -398,7 +399,7 @@ example.i(4) : Syntax error in input(1).
|
|||
<li>206. Unexpected tokens after #<em>directive</em> directive.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn12">15.9.3 C/C++ Parser (300-399)</a></H3>
|
||||
<H3><a name="Warnings_nn12">19.9.3 C/C++ Parser (300-399)</a></H3>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -475,7 +476,7 @@ example.i(4) : Syntax error in input(1).
|
|||
<li>395. operator delete[] ignored.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn13">15.9.4 Types and typemaps (400-499) </a></H3>
|
||||
<H3><a name="Warnings_nn13">19.9.4 Types and typemaps (400-499) </a></H3>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -506,7 +507,7 @@ example.i(4) : Syntax error in input(1).
|
|||
|
||||
|
||||
|
||||
<H3><a name="Warnings_nn14">15.9.5 Code generation (500-599)</a></H3>
|
||||
<H3><a name="Warnings_nn14">19.9.5 Code generation (500-559)</a></H3>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -533,9 +534,22 @@ example.i(4) : Syntax error in input(1).
|
|||
<li>521. Illegal destructor name <em>name</em>. Ignored.
|
||||
<li>522. Use of an illegal constructor name '<em>name</em>' in %extend is deprecated, the constructor name should be '<em>name</em>'.
|
||||
<li>523. Use of an illegal destructor name '<em>name</em>' in %extend is deprecated, the destructor name should be '<em>name</em>'.
|
||||
<li>524. Experimental target language. Target language <em>language</em> specified by <em>lang</em> is an experimental language. Please read about SWIG experimental languages, <em>htmllink</em>.
|
||||
<li>525. Destructor <em>declaration</em> is final, <em>name</em> cannot be a director class.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn15">15.9.6 Language module specific (700-899) </a></H3>
|
||||
<H3><a name="Warnings_doxygen">19.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">19.9.7 Language module specific (700-899) </a></H3>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -586,14 +600,14 @@ example.i(4) : Syntax error in input(1).
|
|||
<li>871. Unrecognized pragma <em>pragma</em>. (Php).
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn16">15.9.7 User defined (900-999)</a></H3>
|
||||
<H3><a name="Warnings_nn16">19.9.8 User defined (900-999)</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
These numbers can be used by your own application.
|
||||
</p>
|
||||
|
||||
<H2><a name="Warnings_nn17">15.10 History</a></H2>
|
||||
<H2><a name="Warnings_nn17">19.10 History</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!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>
|
||||
<head>
|
||||
<title>Getting started on Windows</title>
|
||||
|
|
@ -33,9 +33,9 @@
|
|||
<ul>
|
||||
<li><a href="#Windows_swig_exe">Building swig.exe on Windows</a>
|
||||
<ul>
|
||||
<li><a href="#Windows_cmake">Building swig.exe using CMake</a>
|
||||
<li><a href="#Windows_mingw_msys">Building swig.exe using MinGW and MSYS</a>
|
||||
<li><a href="#Windows_cygwin">Building swig.exe using Cygwin</a>
|
||||
<li><a href="#Windows_building_alternatives">Building swig.exe alternatives</a>
|
||||
</ul>
|
||||
<li><a href="#Windows_examples_cygwin">Running the examples on Windows using Cygwin</a>
|
||||
</ul>
|
||||
|
|
@ -68,7 +68,7 @@ SWIG does not come with the usual Windows type installation program, however it
|
|||
|
||||
|
||||
<p>
|
||||
The swigwin distribution contains the SWIG Windows executable, swig.exe, which will run on 32 bit versions of Windows, ie Windows 95 and later.
|
||||
The swigwin distribution contains the SWIG Windows 32-bit executable, swig.exe, which will run on both 32-bit and 64-bit versions of Windows.
|
||||
If you want to build your own swig.exe have a look at <a href="#Windows_swig_exe">Building swig.exe on Windows</a>.
|
||||
</p>
|
||||
|
||||
|
|
@ -77,10 +77,10 @@ If you want to build your own swig.exe have a look at <a href="#Windows_swig_exe
|
|||
|
||||
|
||||
<p>
|
||||
Using Microsoft Visual C++ is the most common approach to compiling and linking SWIG's output.
|
||||
Microsoft Visual C++ is the most commonly used compiler for compiling and linking SWIG's output on Windows.
|
||||
The Examples directory has a few Visual C++ project files (.dsp files).
|
||||
These were produced by Visual C++ 6.
|
||||
Newer versions of Visual Studio should be able to open and convert these project files.
|
||||
Newer versions of Visual Studio are able to open and convert these project files.
|
||||
Each C# example comes with a Visual Studio 2005 solution and associated project files instead of Visual C++ 6 project files.
|
||||
The project files have been set up to execute SWIG in a custom build rule for the SWIG interface (.i) file.
|
||||
Alternatively run the <a href="#Windows_examples_cygwin">examples using Cygwin</a>.
|
||||
|
|
@ -95,9 +95,11 @@ More information on each of the examples is available with the examples distribu
|
|||
Ensure the SWIG executable is as supplied in the SWIG root directory in order for the examples to work.
|
||||
Most languages require some environment variables to be set <b>before</b> running Visual C++.
|
||||
Note that Visual C++ must be re-started to pick up any changes in environment variables.
|
||||
Open up an example .dsp file, Visual C++ will create a workspace for you (.dsw file).
|
||||
Ensure the Release build is selected then do a Rebuild All from the Build menu.
|
||||
The required environment variables are displayed with their current values.
|
||||
Open up an example .dsp file, Visual C++ will prompt you to upgrade the project and convert
|
||||
it into an MSBuild project (.vcxproj file) and Solution (.sln file).
|
||||
Note that older versions of Visual C++ will simply create a workspace for you (.dsw file).
|
||||
Ensure the Release build is selected then do a Rebuild Solution from the Build menu.
|
||||
The required environment variables are displayed with their current values during the build.
|
||||
</p>
|
||||
<p>
|
||||
The list of required environment variables for each module language is also listed below.
|
||||
|
|
@ -111,7 +113,7 @@ If you are interested in how the project files are set up there is explanatory i
|
|||
|
||||
<p>
|
||||
The C# examples do not require any environment variables to be set as a C# project file is included.
|
||||
Just open up the .sln solution file in Visual Studio .NET 2003 or later, select Release Build, and do a Rebuild All from the Build menu.
|
||||
Just open up the .sln solution file in Visual Studio 2005 or later, select Release Build, and do a Rebuild Solution from the Build menu.
|
||||
The accompanying C# and C++ project files are automatically used by the solution file.
|
||||
</p>
|
||||
|
||||
|
|
@ -149,7 +151,7 @@ PERL5_LIB: D:\nsPerl5.004_04\lib\CORE\perl.lib<br>
|
|||
|
||||
<p>
|
||||
<b><tt>PYTHON_INCLUDE</tt></b> : Set this to the directory that contains Python.h<br>
|
||||
<b><tt>PYTHON_LIB</tt></b> : Set this to the python library including path for linking<p>
|
||||
<b><tt>PYTHON_LIB</tt></b> : Set this to the Python library including path for linking<p>
|
||||
Example using Python 2.1.1:<br>
|
||||
<tt>
|
||||
PYTHON_INCLUDE: D:\python21\include<br>
|
||||
|
|
@ -211,7 +213,7 @@ If you do not have access to Visual C++ you will have to set up project files /
|
|||
|
||||
|
||||
<p>
|
||||
SWIG can also be compiled and run using <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> which provides a Unix like front end to Windows and comes free with gcc, an ANSI C/C++ compiler. However, this is not a recommended approach as the prebuilt executable is supplied.
|
||||
SWIG can also be compiled and run using <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> which provides a Unix like front end to Windows and comes free with gcc, an ISO C/C++ compiler. However, this is not a recommended approach as the prebuilt executable is supplied.
|
||||
</p>
|
||||
|
||||
<H3><a name="Windows_swig_exe">3.3.1 Building swig.exe on Windows</a></H3>
|
||||
|
|
@ -224,7 +226,77 @@ This information is provided for those that want to modify the SWIG source code
|
|||
Normally this is not needed, so most people will want to ignore this section.
|
||||
</p>
|
||||
|
||||
<H4><a name="Windows_mingw_msys">3.3.1.1 Building swig.exe using MinGW and MSYS</a></H4>
|
||||
<H4><a name="Windows_cmake">3.3.1.1 Building swig.exe using CMake</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG can also be built using <a href="https://cmake.org/">CMake</a> and Visual Studio rather than autotools. As with the other approaches to
|
||||
building SWIG the dependencies need to be installed. The steps below are one of a number of ways of installing the dependencies without requiring Cygwin or MinGW.
|
||||
For fully working build steps always check the Continuous Integration setups currently detailed in the <a href="https://github.com/swig/swig/blob/master/appveyor.yml">Appveyor YAML file</a>.
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
Install Nuget from <a href="https://www.nuget.org/downloads">https://www.nuget.org/downloads</a> (v5.8.1 is used in this example, and installed to C:\Tools). Nuget is the package manager
|
||||
for .NET, but allows us to easily install <a href="https://www.pcre.org/">PCRE</a> and other dependencies required by SWIG.
|
||||
</li>
|
||||
<li>
|
||||
Install CMake using the following command: <pre>C:\Tools\nuget install CMake-win64 -Version 3.15.5 -OutputDirectory C:\Tools\CMake</pre>
|
||||
Alternatively you can download CMake from <a href="https://cmake.org/download/">https://cmake.org/download/</a>.
|
||||
</li>
|
||||
<li>
|
||||
Install Bison using the following command: <pre>C:\Tools\nuget install bison-win32 -Version 2.4.1.1 -OutputDirectory C:\Tools\bison</pre>
|
||||
Alternatively download Bison from <a href="https://sourceforge.net/projects/gnuwin32/files/bison/">https://sourceforge.net/projects/gnuwin32/files/bison/</a> (2.4.1 is used in this example)
|
||||
and save to a folder e.g. C:\Tools\Bison
|
||||
</li>
|
||||
<li>
|
||||
Install PCRE using Nuget using the following command: <pre>C:\Tools\nuget install pcre -Version 8.33.0.1 -OutputDirectory C:\Tools\pcre</pre>
|
||||
</li>
|
||||
<li>
|
||||
We will also need the SWIG source code. Either download a zipped archive from GitHub, or if git is installed clone the latest codebase
|
||||
using <pre>git clone https://github.com/swig/swig.git</pre>
|
||||
In this example we are assuming the source code is available at C:\swig
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
We are assuming Visual Studio 2017 is installed. For other versions of Visual Studio change <i>"Visual Studio 15 2017 Win64"</i> to the relevant
|
||||
<a href="https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#visual-studio-generators">Visual Studio Generator</a>.
|
||||
Now we have all the required dependencies we can build SWIG using the commands below. We add the required build tools to the system PATH, and then
|
||||
build a Release version of SWIG. If all runs successfully a new swig.exe should be generated in a /Release folder.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
cd C:\swig
|
||||
SET PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;C:\Tools\bison\bison-win32.2.4.1.1\tools\native\bin;%PATH%
|
||||
SET PCRE_ROOT=C:\Tools\pcre\pcre.8.33.0.1\build\native
|
||||
SET PCRE_PLATFORM=x64
|
||||
cmake -G "Visual Studio 15 2017 Win64" -DCMAKE_INSTALL_PREFIX="%CD:\=/%/install2" -DCMAKE_C_FLAGS="/DPCRE_STATIC" ^
|
||||
-DPCRE_INCLUDE_DIR=%PCRE_ROOT%/include -DPCRE_LIBRARY=%PCRE_ROOT%/lib/v110/%PCRE_PLATFORM%/Release/static/utf8/pcre8.lib .
|
||||
cmake --build . --config Release
|
||||
|
||||
REM to test the exe
|
||||
cd /Release
|
||||
swig.exe -help
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In addition to Release builds you can create a Debug build using:
|
||||
</p>
|
||||
<div class="shell">
|
||||
<pre>cmake --build . --config Debug</pre>
|
||||
</div>
|
||||
<p>
|
||||
A Visual Studio solution file should be generated named swig.sln. This can be opened and debugged by running the swig project and setting the
|
||||
Debugging Command Arguments. For example to debug one of the test-suite .i files included with the SWIG source use the following:
|
||||
</p>
|
||||
<div class="shell">
|
||||
<pre>-python -c++ -o C:\Temp\doxygen_parsing.cpp C:\swig\Examples\test-suite\doxygen_parsing.i</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Windows_mingw_msys">3.3.1.2 Building swig.exe using MinGW and MSYS</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -249,7 +321,7 @@ Execute the steps in the order shown and don't use spaces in path names. In fact
|
|||
<ol>
|
||||
<li>
|
||||
Download the following packages from the <a href="http://www.mingw.org/download.shtml">MinGW download page</a>
|
||||
or <a href="http://sourceforge.net/projects/mingw/files/">MinGW SourceForge download page</a>.
|
||||
or <a href="https://sourceforge.net/projects/mingw/files/">MinGW SourceForge download page</a>.
|
||||
Note that at the time of writing, the majority of these are in the Current
|
||||
release list and some are in the Snapshot or Previous release list.
|
||||
<ul>
|
||||
|
|
@ -342,7 +414,7 @@ make
|
|||
</ol>
|
||||
|
||||
|
||||
<H4><a name="Windows_cygwin">3.3.1.2 Building swig.exe using Cygwin</a></H4>
|
||||
<H4><a name="Windows_cygwin">3.3.1.3 Building swig.exe using Cygwin</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -353,15 +425,6 @@ Note that the Cygwin environment will also allow one to regenerate the autotool
|
|||
These files are generated using the <tt>autogen.sh</tt> script and will only need regenerating in circumstances such as changing the build system.
|
||||
</p>
|
||||
|
||||
<H4><a name="Windows_building_alternatives">3.3.1.3 Building swig.exe alternatives</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
If you don't want to install Cygwin or MinGW, use a different compiler to build
|
||||
SWIG. For example, all the source code files can be added to a Visual C++ project
|
||||
file in order to build swig.exe from the Visual C++ IDE.
|
||||
</p>
|
||||
|
||||
|
||||
<H3><a name="Windows_examples_cygwin">3.3.2 Running the examples on Windows using Cygwin</a></H3>
|
||||
|
||||
|
|
|
|||
|
|
@ -5,6 +5,9 @@ Scripting.html
|
|||
SWIG.html
|
||||
SWIGPlus.html
|
||||
CPlusPlus11.html
|
||||
CPlusPlus14.html
|
||||
CPlusPlus17.html
|
||||
CPlusPlus20.html
|
||||
Preprocessor.html
|
||||
Library.html
|
||||
Arguments.html
|
||||
|
|
@ -12,30 +15,26 @@ Typemaps.html
|
|||
Customization.html
|
||||
Contract.html
|
||||
Varargs.html
|
||||
Doxygen.html
|
||||
Warnings.html
|
||||
Modules.html
|
||||
CCache.html
|
||||
Allegrocl.html
|
||||
Android.html
|
||||
CSharp.html
|
||||
Chicken.html
|
||||
D.html
|
||||
Go.html
|
||||
Guile.html
|
||||
Java.html
|
||||
Javascript.html
|
||||
Lisp.html
|
||||
Lua.html
|
||||
Modula3.html
|
||||
Mzscheme.html
|
||||
Ocaml.html
|
||||
Octave.html
|
||||
Perl5.html
|
||||
Php.html
|
||||
Pike.html
|
||||
Python.html
|
||||
R.html
|
||||
Ruby.html
|
||||
Scilab.html
|
||||
Tcl.html
|
||||
Mzscheme.html
|
||||
Ocaml.html
|
||||
Extending.html
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG-3.0 Documentation</title>
|
||||
<title>SWIG-4.0 Documentation</title>
|
||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="index">SWIG-3.0 Documentation</a></H1>
|
||||
<H1><a name="index">SWIG-4.0 Documentation</a></H1>
|
||||
|
||||
The SWIG documentation is available in one of the following formats.
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -44,6 +44,8 @@ def getheadingname(m):
|
|||
def getheadingtext(m, s):
|
||||
prevheadingtext_newstyle = m.group(2)
|
||||
prevheadingtext_oldstyle = m.group(3)
|
||||
if prevheadingtext_oldstyle is None or prevheadingtext_newstyle is None:
|
||||
raise RuntimeError("Ill-formed heading in line:\n%s" % s)
|
||||
if len(prevheadingtext_oldstyle) == 0 and len(prevheadingtext_newstyle) == 0:
|
||||
raise RuntimeError("No heading text in line:\n%s" % s)
|
||||
if len(prevheadingtext_oldstyle) > 0 and len(prevheadingtext_newstyle) > 0:
|
||||
|
|
@ -72,7 +74,7 @@ name = ""
|
|||
|
||||
# Regexs for <h1>,... <h5> sections
|
||||
|
||||
h1 = re.compile(r".*?<H1>(<a.*?>\s*[\d\s]*(.*?)</a>)*[\d\s]*(.*?)</H1>", re.IGNORECASE)
|
||||
h1 = re.compile(r".*?<H1>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H1>", re.IGNORECASE)
|
||||
h2 = re.compile(r".*?<H2>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H2>", re.IGNORECASE)
|
||||
h3 = re.compile(r".*?<H3>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H3>", re.IGNORECASE)
|
||||
h4 = re.compile(r".*?<H4>(<a.*?>\s*[\d\.\s]*(.*?)</a>)*[\d\.\s]*(.*?)</H4>", re.IGNORECASE)
|
||||
|
|
|
|||
|
|
@ -65,6 +65,10 @@ div.diagram {
|
|||
font-family: "Courier New", Courier, "Courier 10 Pitch", monospace;
|
||||
}
|
||||
|
||||
div.diagram li {
|
||||
margin-left: 0;
|
||||
}
|
||||
|
||||
ul li p {
|
||||
margin-left: 0;
|
||||
margin-right: 0;
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -1,11 +0,0 @@
|
|||
#include <stdio.h>
|
||||
|
||||
int Circle (int x, int y, int radius) {
|
||||
/* Draw Circle */
|
||||
printf("Drawing the circle...\n");
|
||||
/* Return -1 to test contract post assertion */
|
||||
if (radius == 2)
|
||||
return -1;
|
||||
else
|
||||
return 1;
|
||||
}
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
/* File : example.i */
|
||||
|
||||
/* Basic C example for swig contract */
|
||||
/* Tiger, University of Chicago, 2003 */
|
||||
|
||||
%module example
|
||||
|
||||
%contract Circle (int x, int y, int radius) {
|
||||
require:
|
||||
x >= 0;
|
||||
y >= 0;
|
||||
radius > x;
|
||||
ensure:
|
||||
Circle >= 0;
|
||||
}
|
||||
|
||||
%inline %{
|
||||
extern int Circle (int x, int y, int radius);
|
||||
%}
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
import example
|
||||
# Call the Circle() function correctly
|
||||
|
||||
x = 1;
|
||||
y = 1;
|
||||
r = 3;
|
||||
|
||||
c = example.Circle(x, y, r)
|
||||
|
||||
# test post-assertion
|
||||
x = 1;
|
||||
y = 1;
|
||||
r = 2;
|
||||
|
||||
c = example.Circle(x, y, r)
|
||||
|
||||
print "The return value of Circle(%d, %d, %d) is %d" % (x,y,r,c)
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
import example
|
||||
|
||||
# Call the Circle() function correctly
|
||||
|
||||
x = 1;
|
||||
y = 1;
|
||||
r = 3;
|
||||
|
||||
c = example.Circle(x, y, r)
|
||||
|
||||
print "The return value of Circle(%d, %d, %d) is %d" % (x,y,r,c)
|
||||
|
||||
# test pre-assertion
|
||||
x = 1;
|
||||
y = -1;
|
||||
r = 3;
|
||||
|
||||
c = example.Circle(x, y, r)
|
||||
|
||||
print "The return value of Circle(%d, %d, %d) is %d" % (x,y,r,c)
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
%module example
|
||||
|
||||
%contract Circle::Circle(double radius) {
|
||||
require:
|
||||
radius > 0;
|
||||
}
|
||||
|
||||
%contract Circle::area(void) {
|
||||
ensure:
|
||||
area > 0;
|
||||
}
|
||||
|
||||
%contract Shape::move(double dx, double dy) {
|
||||
require:
|
||||
dx > 0;
|
||||
}
|
||||
|
||||
/* should be no effect, since there is no move() for class Circle */
|
||||
%contract Circle::move(double dx, double dy) {
|
||||
require:
|
||||
dy > 1;
|
||||
}
|
||||
|
||||
# include must be after contracts
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
%include "example.h"
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
import example
|
||||
|
||||
# Create the Circle object
|
||||
|
||||
r = 2;
|
||||
print " Creating circle (radium: %d) :" % r
|
||||
c = example.Circle(r)
|
||||
|
||||
# Set the location of the object
|
||||
|
||||
c.x = 20
|
||||
c.y = 30
|
||||
print " Here is its current position:"
|
||||
print " Circle = (%f, %f)" % (c.x,c.y)
|
||||
|
||||
# ----- Call some methods -----
|
||||
|
||||
print "\n Here are some properties of the Circle:"
|
||||
print " area = ", c.area()
|
||||
print " perimeter = ", c.perimeter()
|
||||
dx = 1;
|
||||
dy = 1;
|
||||
print " Moving with (%d, %d)..." % (dx, dy)
|
||||
c.move(dx, dy)
|
||||
|
||||
del c
|
||||
|
||||
print "==================================="
|
||||
|
||||
# test construction */
|
||||
r = -1;
|
||||
print " Creating circle (radium: %d) :" % r
|
||||
c = example.Circle(r)
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
import example
|
||||
|
||||
# Create the Circle object
|
||||
|
||||
r = 2;
|
||||
print " Creating circle (radium: %d) :" % r
|
||||
c = example.Circle(r)
|
||||
|
||||
# Set the location of the object
|
||||
|
||||
c.x = 20
|
||||
c.y = 30
|
||||
print " Here is its current position:"
|
||||
print " Circle = (%f, %f)" % (c.x,c.y)
|
||||
|
||||
# ----- Call some methods -----
|
||||
|
||||
print "\n Here are some properties of the Circle:"
|
||||
print " area = ", c.area()
|
||||
print " perimeter = ", c.perimeter()
|
||||
dx = 1;
|
||||
dy = 1;
|
||||
print " Moving with (%d, %d)..." % (dx, dy)
|
||||
c.move(dx, dy)
|
||||
|
||||
del c
|
||||
|
||||
print "==================================="
|
||||
|
||||
# test area function */
|
||||
r = 1;
|
||||
print " Creating circle (radium: %d) :" % r
|
||||
c = example.Circle(r)
|
||||
# Set the location of the object
|
||||
|
||||
c.x = 20
|
||||
c.y = 30
|
||||
print " Here is its current position:"
|
||||
print " Circle = (%f, %f)" % (c.x,c.y)
|
||||
|
||||
# ----- Call some methods -----
|
||||
|
||||
print "\n Here are some properties of the Circle:"
|
||||
print " area = ", c.area()
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
import example
|
||||
|
||||
# Create the Circle object
|
||||
|
||||
r = 2;
|
||||
print " Creating circle (radium: %d) :" % r
|
||||
c = example.Circle(r)
|
||||
|
||||
# Set the location of the object
|
||||
|
||||
c.x = 20
|
||||
c.y = 30
|
||||
print " Here is its current position:"
|
||||
print " Circle = (%f, %f)" % (c.x,c.y)
|
||||
|
||||
# ----- Call some methods -----
|
||||
|
||||
print "\n Here are some properties of the Circle:"
|
||||
print " area = ", c.area()
|
||||
print " perimeter = ", c.perimeter()
|
||||
dx = 1;
|
||||
dy = 1;
|
||||
print " Moving with (%d, %d)..." % (dx, dy)
|
||||
c.move(dx, dy)
|
||||
|
||||
del c
|
||||
|
||||
print "==================================="
|
||||
|
||||
# test move function */
|
||||
r = 2;
|
||||
print " Creating circle (radium: %d) :" % r
|
||||
c = example.Circle(r)
|
||||
# Set the location of the object
|
||||
|
||||
c.x = 20
|
||||
c.y = 30
|
||||
print " Here is its current position:"
|
||||
print " Circle = (%f, %f)" % (c.x,c.y)
|
||||
|
||||
# ----- Call some methods -----
|
||||
|
||||
print "\n Here are some properties of the Circle:"
|
||||
print " area = ", c.area()
|
||||
print " perimeter = ", c.perimeter()
|
||||
|
||||
# no error for Circle's pre-assertion
|
||||
dx = 1;
|
||||
dy = -1;
|
||||
print " Moving with (%d, %d)..." % (dx, dy)
|
||||
c.move(dx, dy)
|
||||
|
||||
# error with Shape's pre-assertion
|
||||
dx = -1;
|
||||
dy = 1;
|
||||
print " Moving with (%d, %d)..." % (dx, dy)
|
||||
c.move(dx, dy)
|
||||
|
|
@ -36,6 +36,6 @@ func DeleteGoCallback(p GoCallback) {
|
|||
p.deleteCallback()
|
||||
}
|
||||
|
||||
func (p *goCallback) Run() {
|
||||
func (p *overwrittenMethodsOnCallback) Run() {
|
||||
fmt.Println("GoCallback.Run")
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
"./example"
|
||||
"fmt"
|
||||
|
||||
"swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ type overwrittenMethodsOnFooBarAbstract struct {
|
|||
fb FooBarAbstract
|
||||
|
||||
// If additional constructor arguments have been given they are typically
|
||||
// stored here so that the overriden methods can use them.
|
||||
// stored here so that the overridden methods can use them.
|
||||
}
|
||||
|
||||
func (om *overwrittenMethodsOnFooBarAbstract) Foo() string {
|
||||
|
|
@ -59,7 +59,7 @@ func NewFooBarGo() FooBarGo {
|
|||
// The memory of the FooBarAbstract director object instance can be
|
||||
// automatically freed once the FooBarGo instance is garbage collected by
|
||||
// uncommenting the following line. Please make sure to understand the
|
||||
// runtime.SetFinalizer specific gotchas before doing this. Furthemore
|
||||
// runtime.SetFinalizer specific gotchas before doing this. Furthermore
|
||||
// DeleteFooBarGo should be deleted if a finalizer is in use or the fooBarGo
|
||||
// struct needs additional data to prevent double deletion.
|
||||
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)
|
||||
|
|
|
|||
|
|
@ -1,9 +1,10 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
"./example"
|
||||
"fmt"
|
||||
"os"
|
||||
|
||||
"swigtests/example"
|
||||
)
|
||||
|
||||
func Compare(name string, got string, exp string) error {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
"./example"
|
||||
"fmt"
|
||||
|
||||
"swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
. "./example"
|
||||
"fmt"
|
||||
|
||||
. "swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
"./example"
|
||||
"fmt"
|
||||
|
||||
"swigtests/example"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
# see top-level Makefile.in
|
||||
constants
|
||||
class
|
||||
port
|
||||
simple
|
||||
std_vector
|
||||
constants
|
||||
matrix
|
||||
multimap
|
||||
multivalue
|
||||
port
|
||||
simple
|
||||
std_vector
|
||||
|
|
|
|||
|
|
@ -1,6 +1,3 @@
|
|||
#!./matrix \
|
||||
-e do-test -s
|
||||
!#
|
||||
;;; Authors: David Beazley <beazley@cs.uchicago.edu>, 1999
|
||||
;;; Martin Froehlich <MartinFroehlich@ACM.org>, 2000
|
||||
;;;
|
||||
|
|
@ -15,7 +12,7 @@
|
|||
;;; Explanation: The three lines at the beginning of this script are
|
||||
;;; telling the kernel to load the enhanced guile interpreter named
|
||||
;;; "matrix"; to execute the function "do-test" (-e option) after loading
|
||||
;;; this script (-s option). There are a lot more options wich allow for
|
||||
;;; this script (-s option). There are a lot more options which allow for
|
||||
;;; even finer tuning. SEE ALSO: Section "Guile Scripts" in the "Guile
|
||||
;;; reference manual -- Part I: Preliminaries".
|
||||
;;;
|
||||
|
|
|
|||
|
|
@ -15,14 +15,14 @@ back to this behavior, use: */
|
|||
|
||||
void divide_l(int a, int b, int *OUTPUT, int *OUTPUT);
|
||||
|
||||
/* Multiple values as vectors. By issueing: */
|
||||
/* Multiple values as vectors. By issuing: */
|
||||
%values_as_vector;
|
||||
/* vectors instead of lists will be used. */
|
||||
|
||||
void divide_v(int a, int b, int *OUTPUT, int *OUTPUT);
|
||||
|
||||
/* Multiple values for multiple-value continuations.
|
||||
(This is the most elegant way.) By issueing: */
|
||||
(This is the most elegant way.) By issuing: */
|
||||
%multiple_values;
|
||||
/* multiple values are passed to the multiple-value
|
||||
continuation, as created by `call-with-values' or the
|
||||
|
|
|
|||
|
|
@ -1,21 +1,18 @@
|
|||
/* Simple example from documentation */
|
||||
/* File : example.c */
|
||||
|
||||
#include <time.h>
|
||||
/* A global variable */
|
||||
double Foo = 3.0;
|
||||
|
||||
double My_variable = 3.0;
|
||||
|
||||
int fact(int n) {
|
||||
if (n <= 1) return 1;
|
||||
else return n*fact(n-1);
|
||||
/* Compute the greatest common divisor of positive integers */
|
||||
int gcd(int x, int y) {
|
||||
int g;
|
||||
g = y;
|
||||
while (x > 0) {
|
||||
g = x;
|
||||
x = y % x;
|
||||
y = g;
|
||||
}
|
||||
return g;
|
||||
}
|
||||
|
||||
int mod(int n, int m) {
|
||||
return (n % m);
|
||||
}
|
||||
|
||||
char *get_time() {
|
||||
long ltime;
|
||||
time(<ime);
|
||||
return ctime(<ime);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -5,10 +5,8 @@
|
|||
%}
|
||||
|
||||
%inline %{
|
||||
extern double My_variable;
|
||||
extern int fact(int);
|
||||
extern int mod(int n, int m);
|
||||
extern char *get_time();
|
||||
extern int gcd(int x, int y);
|
||||
extern double Foo;
|
||||
%}
|
||||
|
||||
%include guile/guilemain.i
|
||||
|
|
|
|||
|
|
@ -3,24 +3,20 @@
|
|||
(for-each display args)
|
||||
(newline))
|
||||
|
||||
(mdisplay-newline (get-time) "My variable = " (My-variable))
|
||||
; Call our gcd() function
|
||||
|
||||
(do ((i 0 (1+ i)))
|
||||
((= 14 i))
|
||||
(mdisplay-newline i " factorial is " (fact i)))
|
||||
(define x 42)
|
||||
(define y 105)
|
||||
(define g (gcd x y))
|
||||
(mdisplay-newline "The gcd of " x " and " y " is " g)
|
||||
|
||||
(define (mods i imax j jmax)
|
||||
(if (< i imax)
|
||||
(if (< j jmax)
|
||||
(begin
|
||||
(My-variable (+ (My-variable) (mod i j)))
|
||||
(mods i imax (+ j 1) jmax))
|
||||
(mods (+ i 1) imax 1 jmax))))
|
||||
; Manipulate the Foo global variable
|
||||
|
||||
(mods 1 150 1 150)
|
||||
; Output its current value
|
||||
(mdisplay-newline "Foo = " (Foo))
|
||||
|
||||
(mdisplay-newline "My-variable = " (My-variable))
|
||||
|
||||
(exit (and (= 1932053504 (fact 13))
|
||||
(= 745470.0 (My-variable))))
|
||||
; Change its value
|
||||
(Foo 3.1415926)
|
||||
|
||||
; See if the change took effect
|
||||
(mdisplay-newline "Foo = " (Foo))
|
||||
|
|
|
|||
|
|
@ -17,9 +17,8 @@ std::vector<double> half(const std::vector<double>& v) {
|
|||
}
|
||||
|
||||
void halve_in_place(std::vector<double>& v) {
|
||||
// would you believe this is the same as the above?
|
||||
std::transform(v.begin(),v.end(),v.begin(),
|
||||
std::bind2nd(std::divides<double>(),2.0));
|
||||
for (std::vector<double>::iterator it = v.begin(); it != v.end(); ++it)
|
||||
*it /= 2.0;
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
callback
|
||||
class
|
||||
constants
|
||||
doxygen
|
||||
enum
|
||||
extend
|
||||
funcptr
|
||||
|
|
|
|||
|
|
@ -4,17 +4,18 @@ SWIG_LIB_DIR = $(TOP)/../$(TOP_BUILDDIR_TO_TOP_SRCDIR)Lib
|
|||
CXXSRCS = example.cxx
|
||||
TARGET = example
|
||||
INTERFACE = example.i
|
||||
LIBS =
|
||||
SWIGOPT =
|
||||
SWIGOPT = -doxygen
|
||||
JAVASRCS = *.java
|
||||
|
||||
check: build
|
||||
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' php5_run
|
||||
$(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)' \
|
||||
php5_cpp
|
||||
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)' php5_clean
|
||||
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' java_clean
|
||||
rm -rf javadocs
|
||||
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