XS-MLVP
/
swig
mirror of https://github.com/swig/swig
5
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'restore-compat-wrappers-names' into C 

Merge with the latest master including PR #2371.
This commit is contained in:
Vadim Zeitlin 2022-09-17 14:36:37 +02:00
parent 4748e4f379 3caf285742
commit 864f32159a
851 changed files with 21837 additions and 7327 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

114
.github/workflows/ci.yml vendored
View File

@ -13,6 +13,9 @@ on:
- 'Doc/**'
- 'appveyor.yml'
permissions:
contents: read
jobs:
build:
@ -24,12 +27,13 @@ jobs:
# By default, the name of the build is the language used and SWIG options, but matrix entries
# can define the additional "desc" field with any additional information to include in the name.
name: ${{ matrix.SWIGLANG || 'none' }}${{ matrix.PY3 }} ${{ matrix.ENGINE}} ${{ matrix.VER }} ${{ matrix.SWIG_FEATURES }} ${{ (matrix.compiler || 'gcc') }}${{ matrix.GCC }} ${{ matrix.CPPSTD }} ${{ matrix.CSTD }} ${{ matrix.desc }} ${{ matrix.continue-on-error && '(can fail)' }}
name: ${{ matrix.SWIGLANG || 'none' }}${{ matrix.PY2 }} ${{ matrix.ENGINE}} ${{ matrix.VER }} ${{ matrix.SWIG_FEATURES }} ${{ (matrix.compiler || 'gcc') }}${{ matrix.GCC }} ${{ matrix.CPPSTD }} ${{ matrix.CSTD }} ${{ matrix.desc }} ${{ matrix.continue-on-error && '(can fail)' }}
strategy:
matrix:
include:
- SWIGLANG: ""
CPPFLAGS: "-DDOH_POISON"
- SWIGLANG: ""
GCC: 7
- SWIGLANG: ""
@ -40,6 +44,9 @@ jobs:
GCC: 10
- SWIGLANG: ""
GCC: 11
- SWIGLANG: ""
GCC: 12
os: ubuntu-22.04
- SWIGLANG: ""
compiler: clang
- SWIGLANG: c
@ -65,74 +72,87 @@ jobs:
- SWIGLANG: go
VER: '1.17'
- SWIGLANG: guile
- SWIGLANG: guile
VER: '2.2'
- SWIGLANG: guile
VER: '3.0'
- SWIGLANG: java
- SWIGLANG: javascript
ENGINE: node
VER: '6'
CPPSTD: c++11
os: ubuntu-18.04
- SWIGLANG: javascript
ENGINE: node
VER: '8'
CPPSTD: c++11
os: ubuntu-18.04
- SWIGLANG: javascript
ENGINE: node
VER: '10'
CPPSTD: c++11
os: ubuntu-18.04
- SWIGLANG: javascript
ENGINE: node
VER: '12'
CPPSTD: c++11
- SWIGLANG: javascript
ENGINE: node
VER: '14'
CPPSTD: c++11
- SWIGLANG: javascript
ENGINE: node
VER: '16'
VER: '18'
CPPSTD: c++14
- SWIGLANG: javascript
ENGINE: jsc
os: ubuntu-18.04 # libwebkitgtk-dev dependency not available in 20.04.
- SWIGLANG: javascript
ENGINE: v8
os: ubuntu-18.04 # libv8-dev only actually provides v8 in 18.04.
VER: '4.0'
- SWIGLANG: lua
- SWIGLANG: lua
VER: '5.3'
- SWIGLANG: octave
CPPSTD: c++11
- SWIGLANG: perl5
- SWIGLANG: php
VER: '7.0'
- SWIGLANG: php
VER: '7.1'
- SWIGLANG: php
VER: '7.2'
- SWIGLANG: php
VER: '7.3'
- SWIGLANG: php
VER: '7.4'
- SWIGLANG: php
- SWIGLANG: php
VER: '8.1'
- SWIGLANG: python
PY2: 2
- SWIGLANG: python
PY3: 3
VER: '3.2'
os: ubuntu-18.04 # Python < 3.5 not available for 20.04.
- SWIGLANG: python
PY3: 3
VER: '3.3'
os: ubuntu-18.04 # Python < 3.5 not available for 20.04.
- SWIGLANG: python
PY3: 3
VER: '3.4'
os: ubuntu-18.04 # Python < 3.5 not available for 20.04.
- SWIGLANG: python
PY3: 3
VER: '3.5'
- SWIGLANG: python
PY3: 3
VER: '3.6'
- SWIGLANG: python
PY3: 3
VER: '3.7'
- SWIGLANG: python
PY3: 3
VER: '3.8'
- SWIGLANG: python
PY3: 3
VER: '3.9'
- SWIGLANG: python
PY3: 3
VER: '3.10'
- SWIGLANG: python
VER: '3.11'
- SWIGLANG: python
PY2: 2
SWIG_FEATURES: -builtin
- SWIGLANG: python
PY2: 2
SWIG_FEATURES: -builtin -O
- SWIGLANG: python
PY3: 3
SWIG_FEATURES: -builtin
- SWIGLANG: python
PY3: 3
SWIG_FEATURES: -builtin -O
- SWIGLANG: r
- SWIGLANG: ruby
@ -161,8 +181,14 @@ jobs:
- SWIGLANG: ruby
VER: '3.0'
CPPSTD: c++11
- SWIGLANG: ruby
VER: '3.1'
CPPSTD: c++11
- SWIGLANG: scilab
VER: '5.5.2'
- SWIGLANG: scilab
os: ubuntu-18.04 # scilab 6.0
- SWIGLANG: scilab
os: ubuntu-18.04 # scilab-6.1 in ubuntu-20.04 not yet working
- SWIGLANG: tcl
# c++11 testing
- SWIGLANG: csharp
@ -175,14 +201,17 @@ jobs:
CPPSTD: c++11
- SWIGLANG: java
CPPSTD: c++11
- SWIGLANG: javascript
ENGINE: jsc
VER: '4.1'
os: ubuntu-22.04
CPPSTD: c++11
- SWIGLANG: javascript
ENGINE: node
VER: '14'
CPPSTD: c++11
- SWIGLANG: lua
CPPSTD: c++11
# - SWIGLANG: octave
# CPPSTD: c++11
- SWIGLANG: perl5
CPPSTD: c++11
- SWIGLANG: php
@ -190,14 +219,12 @@ jobs:
CSTD: gnu11
- SWIGLANG: python
CPPSTD: c++11
PY3: 3
- SWIGLANG: r
CPPSTD: c++11
- SWIGLANG: ruby
CPPSTD: c++11
- SWIGLANG: scilab
CPPSTD: c++11
os: ubuntu-18.04 # scilab-6.1 in ubuntu-20.04 not yet working
- SWIGLANG: tcl
CPPSTD: c++11
# c++14 testing
@ -226,14 +253,12 @@ jobs:
CSTD: gnu11
- SWIGLANG: python
CPPSTD: c++14
PY3: 3
- SWIGLANG: r
CPPSTD: c++14
- SWIGLANG: ruby
CPPSTD: c++14
- SWIGLANG: scilab
CPPSTD: c++14
os: ubuntu-18.04 # scilab-6.1 in ubuntu-20.04 not yet working
- SWIGLANG: tcl
CPPSTD: c++14
# c++17 testing (using gcc11)
@ -253,7 +278,7 @@ jobs:
GCC: 11
- SWIGLANG: javascript
ENGINE: node
VER: '16'
VER: '18'
CPPSTD: c++17
GCC: 11
- SWIGLANG: lua
@ -272,7 +297,6 @@ jobs:
- SWIGLANG: python
CPPSTD: c++17
GCC: 11
PY3: 3
- SWIGLANG: r
CPPSTD: c++17
GCC: 11
@ -282,14 +306,21 @@ jobs:
- SWIGLANG: scilab
CPPSTD: c++17
GCC: 11
os: ubuntu-18.04 # scilab-6.1 in ubuntu-20.04 not yet working
- SWIGLANG: tcl
CPPSTD: c++17
GCC: 11
# c++20 testing (using gcc12)
# ubuntu-22.04 is currently experimental on Github Actions, so limit to just one language for now
- SWIGLANG: python
CPPSTD: c++20
GCC: 12
os: ubuntu-22.04
# Experimental languages (these are allowed to fail)
- SWIGLANG: mzscheme
continue-on-error: true
- SWIGLANG: ocaml
CPPSTD: c++17
GCC: 11
continue-on-error: true
os: ubuntu-18.04 # ocaml-4.08 in ubuntu-20.04 not yet working
# Run all of them, as opposed to aborting when one fails
@ -297,13 +328,14 @@ jobs:
env:
SWIGLANG: ${{ matrix.SWIGLANG }}
PY3: ${{ matrix.PY3 }}
PY2: ${{ matrix.PY2 }}
VER: ${{ matrix.VER }}
ENGINE: ${{ matrix.ENGINE }}
SWIG_FEATURES: ${{ matrix.SWIG_FEATURES }}
GCC: ${{ matrix.GCC }}
CSTD: ${{ matrix.CSTD }}
CPPSTD: ${{ matrix.CPPSTD }}
CPPFLAGS: ${{ matrix.CPPFLAGS }}
steps:
- name: Checkout
@ -316,6 +348,10 @@ jobs:
with:
key: ${{ matrix.os || 'ubuntu-20.04' }}-${{ matrix.compiler || 'gcc' }}${{ matrix.GCC }}
# Uncomment to debug via ssh, see https://github.com/mxschmitt/action-tmate
# - name: Setup tmate session
# uses: mxschmitt/action-tmate@v3
- name: Install Dependencies
run: |
set -x
@ -376,10 +412,12 @@ jobs:
c++11) export CSTD=c11 ;;
c++14) export CSTD=c11 ;;
c++17) export CSTD=c17 ;;
c++20) export CSTD=c17 ;;
esac
echo CSTD="$CSTD" >> $GITHUB_ENV
fi
if test -n "$CPPSTD"; then CONFIGOPTS+=(--enable-cpp11-testing "CXXFLAGS=-std=$CPPSTD $CXXFLAGS"); fi
if test -z "$CPPSTD"; then CONFIGOPTS+=("--disable-cpp11-testing"); fi
if test -n "$CPPSTD"; then CONFIGOPTS+=("CXXFLAGS=-std=$CPPSTD $CXXFLAGS"); fi
if test -n "$CSTD"; then CONFIGOPTS+=("CFLAGS=-std=$CSTD $CFLAGS"); fi
if test -n "$SWIGLANG"; then CONFIGOPTS+=(--without-alllang --with-$WITHLANG); fi
echo "${CONFIGOPTS[@]}"
@ -416,8 +454,8 @@ jobs:
esac
# Stricter compile flags for examples. Various headers and SWIG generated code prevents full use of -pedantic.
cflags=$($GITHUB_WORKSPACE/Tools/testflags.py --language $SWIGLANG --cflags --std=$CSTD --compiler=$CC) && echo $cflags
cxxflags=$($GITHUB_WORKSPACE/Tools/testflags.py --language $SWIGLANG --cxxflags --std=$CPPSTD --compiler=$CC) && echo $cxxflags
cflags=$($GITHUB_WORKSPACE/Tools/testflags.py --language $SWIGLANG --cflags --std=$CSTD --compiler=$CC)
cxxflags=$($GITHUB_WORKSPACE/Tools/testflags.py --language $SWIGLANG --cxxflags --std=$CPPSTD --compiler=$CC)
make check-$SWIGLANG-version
make check-$SWIGLANG-enabled
make $SWIGJOBS check-$SWIGLANG-examples CFLAGS="$cflags" CXXFLAGS="$cxxflags"

8
.gitignore vendored
View File

@ -160,6 +160,14 @@ Examples/java/doxygen/javadocs
Examples/test-suite/javascript/*/
*.gyp
# Lua
Examples/lua/dual/dual
Examples/lua/dual/swigluarun.h
Examples/lua/embed/embed
Examples/lua/embed2/embed2
Examples/lua/embed3/embed3
Examples/lua/embed3/swigluarun.h
# OCaml
Examples/test-suite/ocaml/*.ml*
Examples/test-suite/ocaml/*.cm*

499
.travis.yml
View File

@ -1,499 +0,0 @@
language: cpp
matrix:
include:
- compiler: clang
os: linux
env: SWIGLANG=
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG= BUILDSYSTEM=cmake
dist: xenial
- os: linux
env: SWIGLANG= GCC=4.4
dist: xenial
- os: linux
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
- os: linux
env: SWIGLANG= GCC=10
dist: focal
- compiler: gcc
os: linux
env: SWIGLANG=csharp
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=d VER=2.066.0
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=d VER=2.086.1
dist: xenial
- compiler: gcc
os: linux
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 CSTD=gnu99
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=go VER=1.16 CSTD=gnu99
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=guile
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=java
dist: xenial
- compiler: gcc
os: linux
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
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=node VER=14 CPP11=1
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=node VER=16 CPP14=1
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=jsc
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=javascript ENGINE=v8
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=lua
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=lua VER=5.3
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=mzscheme
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=ocaml
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.4
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=php VER=8.0
dist: xenial
- compiler: gcc
os: linux
env: SWIGLANG=php VER=7.0 CONFIGOPTS=--enable-cpp11-testing CPPSTD=c++11
dist: bionic
- compiler: gcc
os: linux
env: SWIGLANG=php VER=7.1 CONFIGOPTS=--enable-cpp11-testing CPPSTD=c++11
dist: bionic
- compiler: gcc
os: linux
env: SWIGLANG=php VER=7.2 CONFIGOPTS=--enable-cpp11-testing CPPSTD=c++11
dist: bionic
- compiler: gcc
os: linux
env: SWIGLANG=php VER=7.3 CONFIGOPTS=--enable-cpp11-testing CPPSTD=c++11
dist: bionic
- compiler: gcc
os: linux
env: SWIGLANG=php VER=7.4 CONFIGOPTS=--enable-cpp11-testing CPPSTD=c++11
dist: bionic
- compiler: gcc
os: linux
env: SWIGLANG=php VER=8.0 CONFIGOPTS=--enable-cpp11-testing CPPSTD=c++11
dist: bionic
- 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
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=ruby VER=3.0 CSTD=c99
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: clang
os: osx
osx_image: xcode12.2
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 CSTD=gnu99
- 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
# 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; 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 "$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 cmake --version && mkdir -p build/build && cd build/build && CXXFLAGS="-Wall -Wextra -Werror" CFLAGS="-Wall -Wextra -Werror" 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 "CXXFLAGS=-std=c++11 $CXXFLAGS" "CFLAGS=-std=c11 $CFLAGS") && export CSTD=c11 && export CPPSTD=c++11; fi
- if test -n "$CPP14"; then CONFIGOPTS+=(--enable-cpp11-testing "CXXFLAGS=-std=c++14 $CXXFLAGS" "CFLAGS=-std=c11 $CFLAGS") && export CSTD=c11 && export CPPSTD=c++14; fi
- if test -n "$CPP17"; then CONFIGOPTS+=(--enable-cpp11-testing "CXXFLAGS=-std=c++17 $CXXFLAGS" "CFLAGS=-std=c17 $CFLAGS") && 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[@]}"
- echo -en 'travis_fold:end:script.1\\r'
- make -s $SWIGJOBS
- ./swig -version && ./swig -pcreversion
- if test -z "$SWIGLANG"; then make -s $SWIGJOBS check-ccache; fi
- if test -z "$SWIGLANG"; then make -s $SWIGJOBS check-errors-test-suite; fi
- echo 'Installing...' && echo -en 'travis_fold:start:script.2\\r'
- if test -z "$SWIGLANG"; then sudo make -s install && swig -version && ccache-swig -V; fi
- echo -en 'travis_fold:end:script.2\\r'
# Stricter compile flags for examples. Various headers and SWIG generated code prevents full use of -pedantic.
- if test -n "$SWIGLANG"; then cflags=$($TRAVIS_BUILD_DIR/Tools/testflags.py --language $SWIGLANG --cflags --std=$CSTD --compiler=$CC) && echo $cflags; fi
- if test -n "$SWIGLANG"; then cxxflags=$($TRAVIS_BUILD_DIR/Tools/testflags.py --language $SWIGLANG --cxxflags --std=$CPPSTD --compiler=$CC) && echo $cxxflags; fi
- if test -n "$SWIGLANG"; then make -s check-$SWIGLANG-version; fi
- if test -n "$SWIGLANG"; then make check-$SWIGLANG-enabled; fi
- 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'
# 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'

4
ANNOUNCE
View File

@ -25,11 +25,11 @@ Availability
============
The release is available for download on Sourceforge at
http://prdownloads.sourceforge.net/swig/swig-4.1.0.tar.gz
https://prdownloads.sourceforge.net/swig/swig-4.1.0.tar.gz
A Windows version is also available at
http://prdownloads.sourceforge.net/swig/swigwin-4.1.0.zip
https://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.

44
CHANGES
View File

@ -3137,7 +3137,7 @@ Version 3.0.3 (30 Dec 2014)
2014-09-12: olly
[PHP] Add support for specifying any PHP interfaces a wrapped class
implements, e.g.: %typemap("phpinterfaces") MyIterator "Iterator";
implements, e.g.: %typemap("phpinterfaces") MyIterator "Iterator"
2014-09-11: olly
[PHP] Fix throwing a PHP exception through C++ from a subclassed
@ -8396,8 +8396,8 @@ Version 1.3.30 (November 13, 2006)
javabase/csbase typemap, eg in the following, 'Me' will be the base class,
no matter what Foo is really derived from in the C++ layer.
%typemap(javabase, replace="1") Foo "Me";
%typemap(csbase, replace="1") Foo "Me";
%typemap(javabase, replace="1") Foo "Me"
%typemap(csbase, replace="1") Foo "Me"
Previously it was not possible for the javabase/csbase typemaps to override the C++ base.
@ -9884,7 +9884,7 @@ Version 1.3.28 (February 12, 2006)
solutions is to write:
%typemap(in) A * {...}
%typemap(freeag) A * "";
%typemap(freeag) A * ""
overload 'freearg' with an empty definition.
@ -11314,20 +11314,20 @@ Version 1.3.27 (October 15, 2005)
then the typemap will be inserted without the block
imposed by the brackets, similar to
%typemap(in) Hello "...";
%typemap(in) Hello "..."
So, why you don't just use the quote style?, because:
1.- The quote style doesn't get preprocessed, for example
%typemap(in) Hello "$1= SWIG_macro($1);";
%typemap(in) Hello "$1= SWIG_macro($1);"
here, SWIG_macro doesn't get expanded
2.- Inside a quote typemap, you have to use
quotes carefully
%typemap(in) Hello "$1 = \"hello\" ";
%typemap(in) Hello "$1 = \"hello\" "
3.- You can't make emacs and/or other editors
to indent inside a string!.
@ -11529,7 +11529,7 @@ Version 1.3.26 (October 9, 2005)
%define hello(name, Type)
%define name ## a(Type)
%typemap(in) Type "hello;";
%typemap(in) Type "hello;"
%enddef
%enddef
@ -13525,7 +13525,7 @@ Version 1.3.23 (November 11, 2004)
whereupon the default of 0 was used. You can get the same behaviour for C
code by using the "default" typemap:
%typemap(default) int val "$1 = 0;";
%typemap(default) int val "$1 = 0;"
%{
void foo(int val);
%}
@ -13854,9 +13854,11 @@ Version 1.3.22 (September 4, 2004)
specifiers from the C type. This makes it possible, for instance, to control
whether a C "char" argument takes a Lisp character or a Lisp integer value.
The default (taking Lisp characters) is done by these built-in typemaps:
%typemap(ffitype) char ":char"; %typemap(lisptype) char "character";
%typemap(ffitype) char ":char"
%typemap(lisptype) char "character"
If char means an integer instead, use these typemaps:
%typemap(ffitype) char ":char"; %typemap(lisptype) char "integer";
%typemap(ffitype) char ":char"
%typemap(lisptype) char "integer"
08/22/2004: wsfulton
As discussed in bug #772453, the SWIG library directory is now installed
@ -18874,9 +18876,9 @@ Version 1.3.14 (August 12, 2002)
shadowinterface
Note that it is possible to target a particular proxy class:
%typemap(javaimports) Foo "import java.util.*";
%typemap(javaimports) Foo "import java.util.*"
or a particular type wrapper class:
%typemap(javaimports) double* "import java.math.*";
%typemap(javaimports) double* "import java.math.*"
Note that $javaclassname in these typemaps are substituted with either the proxy
classname when using proxy classes or the SWIGTYPE class name.
@ -19614,8 +19616,8 @@ Version 1.3.12 (June 2, 2002)
typemap must exactly match up with the "in" or "ignore"
typemap. For example:
%typemap(in) (char *data, int len) { ... };
%typemap(freearg) char *data { ... };
%typemap(in) (char *data, int len) { ... }
%typemap(freearg) char *data { ... }
void foo(char *data, int len);
@ -21071,7 +21073,7 @@ Version 1.3.11 (January 31, 2002)
Second, a typemap can force a no-match by defining
%typemap(in) sometype "pass";
%typemap(in) sometype "pass"
If this is used, the typemap system will *not* record a
typemap match for "sometype". This can be used to block
@ -21079,7 +21081,7 @@ Version 1.3.11 (January 31, 2002)
a typemap feature for some type, you could do this.
// Do not allow global variables of type 'const char *' to be set.
%typemap(varin) const char * "pass";
%typemap(varin) const char * "pass"
It might also be possible to use this to do subtle and
strange things with typemaps. For example, if you wanted to
@ -21093,8 +21095,8 @@ Version 1.3.11 (January 31, 2002)
... return a value ...
}
/* Block unqualified typemaps defined above */
%typemap(ignore) const blah * "pass";
%typemap(argout) const blah * "pass";
%typemap(ignore) const blah * "pass"
%typemap(argout) const blah * "pass"
%typemap(in) const blah * {
... get input value ...
}
@ -21871,7 +21873,7 @@ Version 1.3.10 (December 10, 2001)
%typemap directive can now accept nearly arbitrary keyword parameters.
For example:
%typemap(in,parse="i",doc="integer") int "...";
%typemap(in,parse="i",doc="integer") int "..."
The purpose of the keyword parameters is to supply code generation
hints to the target language module. The intepretation of the
@ -23949,7 +23951,7 @@ Version 1.3 Alpha 4 (September 4, 2000)
Typemaps can now be specified using string literals like
this:
%typemap(in) int "$target = SvIV($source);";
%typemap(in) int "$target = SvIV($source);"
When code is specified like this, it is *NOT* enclosed
inside a local scope (as with older typemap declarations).

816
CHANGES.current
View File

@ -7,6 +7,821 @@ the issue number to the end of the URL: https://github.com/swig/swig/issues/
Version 4.1.0 (in progress)
===========================
2022-09-17: wsfulton
Add missing typecheck typemaps for std::auto_ptr and std::unique_ptr to
fix overloading when using these types.
2022-09-17: wsfulton
[Guile] Add error checking to SWIGTYPE and SWIGTYPE & in typemaps to prevent
seg faults when passing #nil to these parameter types.
2022-09-16: wsfulton
#999 Provide SWIGTYPE MOVE typemaps in swigmove.i for implementing full
move semantics when passing parameters by value.
2022-08-31: wsfulton
#999 Improve move semantics when using rvalue references.
The SWIGTYPE && input typemaps now assume the object has been moved.
These typemaps have been changed assuming that after the function call,
the rvalue reference parameter has been moved. The parameter's proxy class
that owns the C++ object thus has the underlying pointer set to null
so that the (moved from, but still valid) C++ object cannot be used again
and the the object is additionally deleted.
*** POTENTIAL INCOMPATIBILITY ***
2022-08-28: wsfulton
[Octave] SWIG now marshalls a C/C++ NULL pointer into the null matrix, [].
SWIG has always marshalled the null matrix into a NULL pointer; this remains
and now we have consistency in representing a NULL pointer.
2022-08-26: wsfulton
[Racket] SWIG now marshalls a C/C++ NULL pointer into a null value by calling
scheme_make_null(), so that scheme's null? is true for a NULL C/C++ pointer value.
2022-08-18: wsfulton
[Racket] Add support for std::unique_ptr in std_unique_ptr.i.
Add support for std::auto_ptr in std_auto_ptr.i.
2022-08-13: wsfulton
[Guile] Add support for std::unique_ptr in std_unique_ptr.i.
Add support for std::auto_ptr in std_auto_ptr.i.
2022-08-11: wsfulton
[Lua] Add support for std::unique_ptr in std_unique_ptr.i.
Add support for std::auto_ptr in std_auto_ptr.i.
2022-08-05: wsfulton
[D] Fix occasional undefined behaviour with inheritance hierarchies, particularly
when using virtual inheritance as the pointers weren't correctly upcast from derived
class to base class when stored in the base's proxy class.
2022-08-05: wsfulton
[D] Add support for std::unique_ptr in std_unique_ptr.i.
Add support for std::auto_ptr in std_auto_ptr.i.
2022-08-03: wsfulton
[Javascript] Add support for std::unique_ptr in std_unique_ptr.i.
Add support for std::auto_ptr in std_auto_ptr.i.
2022-08-02: wsfulton
[Octave] Add support for std::unique_ptr in std_unique_ptr.i.
Add support for std::auto_ptr in std_auto_ptr.i.
2022-08-01: wsfulton
[Python] Add initialisers for additional members in PyHeapTypeObject
(builtin mode) for Python-3.11 - _ht_tpname, _spec_cache.
2022-07-30: wsfulton
C++20 has deprecated std::basic_string<>::reserve() and the C++11 method
std::basic_string<>::shrink_to_fit() is a replacement that can be used.
std_string.i and std_wstring.i provided wrappers for reserve with the following
template instantiations:
%template(string) std::basic_string<char>;
%template(wstring) std::basic_string<wchar_t>;
The reserve method is no longer wrapped, however the shrink_to_fit() method
can be used as an alternative from the target language (the generated wrappers
call reserve() instead if C++<=20).
Note that std::basic_string<>::reserve(size_t n) is still wrapped unchanged.
*** POTENTIAL INCOMPATIBILITY ***
2022-07-30: wsfulton
[Tcl] Add support for std::unique_ptr in std_unique_ptr.i.
Add support for std::auto_ptr in std_auto_ptr.i.
2022-07-27: ZackerySpytz, olly
#1678 Support parsing C++20 templated lambdas.
2022-07-27: ZackerySpytz, olly
#1622 Add support for the C++20 spaceship operator (<=>).
2022-07-26: olly
[Tcl] https://sourceforge.net/p/swig/bugs/977/
Fix handling of long long on 32-bit platforms. This fix raises
SWIG's minimum supported Tcl version to 8.4.0 (which was released
just under 20 years ago).
2022-07-26: olly
Fix incorrect operator precedence in preprocessor expressions.
2022-07-25: olly
Support for C++14 binary integer literals in preprocessor expressions.
2022-07-20: wsfulton
[C#, Java] Ensure the order of interfaces generated in proxy interfaces for the
%interface family of macros is the same as that parsed from the bases in C++.
2022-07-20: jicks, Ingener74, olly
#422 [Python] Fix mishandling of a Python class inheriting from
multiple SWIG-wrapped director classes.
2022-07-19: wsfulton
#692 [C#, Java, Perl, Python, Ruby] std::unique_ptr and std::auto_ptr typemaps
provided for inputs types in std_unique_ptr.i and std_auto_ptr.i.
Now these smart pointers can be used as input parameters to functions. A proxy
class instance transfers memory ownership of the underlying C++ object from the
proxy class to a smart pointer instance passed to the wrapped function.
2022-07-19: jschueller
[Python] #2314 Drop support for Python 3.2.
2022-07-19: olly
Remove remaining support code for classic macos, which has not been
supported by Apple for over 20 years now.
2022-07-12: wsfulton
#999 Performance optimisation for parameters passed by value that are C++11 movable.
The C++ wrappers create a temporary variable for a parameter to be passed to a
function. This is initially default constructed and then copy assigned from the
instance being passed in from the target language. This is unchanged, however,
when the temporary variable is passed to the wrapped function, it is now done using
std::move. If the type is move constructible, the move constructor will be used
instead of the copy constructor.
2022-07-12: wsfulton
[Perl] Add std::auto_ptr support in std_auto_ptr.i library file.
2022-07-12: erezgeva
[Perl] Add std::unique_ptr support in std_unique_ptr.i library file.
2022-07-07: olly
[xml] #2213 XML has been moved to "Experimental" target language
status. It's not in good shape and is likely to be removed unless
somebody steps up to bring it up to the expected standard (it fails
to even meet the criteria for "Experimental" currently).
2022-07-07: jmarrec
#1158 #2286 Add basic support for C++11 attributes. These are now
crudely ignored by SWIG's parser's tokeniser, which is better that
failing with a parse error.
2022-07-05: ianlancetaylor
[Go] #2245 Handle NULL pointers for string* conversions.
Rearrange generation of director methods and rename
receiver argument from p to swig_p.
2022-07-03: wsfulton
#999 Performance optimisation for directors for classes passed by value. The directorin
typemaps in the director methods now use std::move on the input parameter when
copying the object from the stack to the heap prior to the callback into the target
language, thereby taking advantage of move semantics if available.
2022-07-02: wsfulton
#1722 [C#, Java, Python, Ruby] Add std::unique_ptr support. Ported from std::auto_ptr.
Use the %unique_ptr(T) macro as follows for usage std::unique_ptr<T>. For example, for
a class called Klass:
%include "std_unique_ptr.i"
%unique_ptr(Klass)
Support is currently limited to only returning a std::unique_ptr from a function.
2022-06-29: wsfulton
#999 #1044 Enhance SWIGTYPE "out" typemaps to use std::move when copying
objects, thereby making use of move semantics when wrapping a function returning
by value if the returned type supports move semantics.
Wrapping functions that return move only types 'by value' now work out the box
without having to provide custom typemaps.
The implementation removed all casts in the "out" typemaps to allow the compiler to
appropriately choose calling a move constructor, where possible, otherwise a copy
constructor. The implementation also required modifying SwigValueWrapper to
change a cast operator from:
SwigValueWrapper::operator T&() const;
to
#if __cplusplus >=201103L
SwigValueWrapper::operator T&&() const;
#else
SwigValueWrapper::operator T&() const;
#endif
This is not backwards compatible for C++11 and later when using the valuewrapper feature
if a cast is explicitly being made in user supplied "out" typemaps. Suggested change
in custom "out" typemaps for C++11 and later code:
1. Try remove the cast altogether to let the compiler use an appropriate implicit cast.
2. Change the cast, for example, from static_cast<X &> to static_cast<X &&>, using the
__cplusplus macro if all versions of C++ need to be supported.
*** POTENTIAL INCOMPATIBILITY ***
2022-06-15: wsfulton
#2039 Add move assignment operator to SwigValueWrapper used by the
valuewrapper feature.
2022-06-04: sethrj
Enhance $typemap to support typemap attributes.
$typemap(method:attribute, typepattern)
For example:
%typemap(cstype, out="object") XClass "XClass"
%typemap(cscode) BarClass %{
$typemap(cstype:out, XClass) bar() {
return null;
}
which expands to
object bar() {
return null;
}
2022-05-30: wsfulton
[C#, D] Add new special variable expansion: $imfuncname.
Expands to the function name called in the intermediary class.
2022-05-30: LindleyF
[Java] #2042 Add new special variable expansion: $imfuncname.
Expands to the function name called in the intermediary class.
2022-05-28: jkuebart
[Java] On some versions of Android, specifically Android 6,
detaching the current thread from the JVM after every invocation
causes a memory leak.
Offer SWIG_JAVA_DETACH_ON_THREAD_END to configure a behaviour
where the JVM is only detached in the thread destructor.
See https://developer.android.com/training/articles/perf-jni#threads.
2022-05-27: xypron
[Python] #2277 Define PY_SSIZE_T_CLEAN macro before #include "Python.h" as
recommended in Python 3.7 and later.
To avoid this macro definition, add the following to your interface file so
that SWIG_NO_PY_SSIZE_T_CLEAN is defined at the beginning of the C++ wrappers:
%begin %{
#define SWIG_NO_PY_SSIZE_T_CLEAN
%}
2022-05-26: rokups
[C#] #1323 Modify SwigDerivedClassHasMethod for a more efficient director
implementation when calling virtual methods that are not overridden.
2022-05-15: erezgeva, eiselekd
[Lua, Perl, Octave, PHP, Tcl] #2275 #2276 #2283 Add argcargv.i library containing
(int ARGC, char **ARGV) multi-argument typemaps.
Document this library in Typemaps.html.
2022-05-07: KrisThielemans
[Python] Fix "too many initializers for 'PyHeapTypeObject'" errors
using PyPy 3.8 and later.
2022-05-04: wsfulton
[C#] Add C# wchar_t * director typemaps
2022-04-20: cminyard
Fix an issue where newlines were not properly generated
for godirectorin typemaps. If you have a virtual function
not assigned to zero, in some cases it won't generate a
newline and you will see errors:
example.go:1508:3: expected ';', found swig_r
when compiling the go code.
Also add an example of using goin and godirectorin and add
a test for this situation.
2022-04-29: jason-daly, JerryJoyce, wsfulton
[C#] #1233 Add wchar_t * and std::wstring Unicode string support on Linux.
2022-04-11: robinst
#2257 Fix new Ruby 3.2 warning "undefining the allocator of T_DATA
class swig_runtime_data".
2022-04-07: olly
#1750 SWIG now recognises and ignores Doxygen group commands `@{` and `@}`.
2022-04-06: wsfulton
./configure now enables C++11 and later C++ standards testing by default (when
running: 'make check').
The options to control this testing are the same:
./configure --enable-cpp11-testing
./configure --disable-cpp11-testing
But the former is now the default and the latter can be used to turn off C++11 and
later C++ standards testing.
2022-04-06: wsfulton
[Python] #1635 The "autodoc" feature no longer overrides Doxygen comments
in the generated docstring.
If a "docstring" feature is present it will still override a Doxygen comment.
If the "autodoc" feature is also present, the combined "autodoc" and "docstring"
will override the Doxygen comment. If no "docstring" is present then the
"autodoc" feature will not be generated when there is a Doxygen comment.
This way the "autodoc" feature can be specified and used to provide documentation
for 'missing' Doxygen comments.
*** POTENTIAL INCOMPATIBILITY ***
2022-04-01: olly
Remove undocumented and non-functional -browse command line option.
2022-03-26: eltoder
[Python] #1684 Use different capsule names with and without -builtin
Types generated with and without -builtin are not compatible. Mixing
them in a common type list leads to crashes. Avoid this by using
different capsule names: "type_pointer_capsule" without -builtin and
"type_pointer_capsule_builtin" with.
2022-03-25: wsfulton
The debug command line options that display parse tree nodes
(-debug-module, -debug-top, -debug-symtabs) now display previously hidden
linked list pointers which are useful for debugging parse trees.
Added new command line option -debug-quiet. This suppresses the display
of most linked list pointers and symbol table pointers in the parse tree nodes.
The keys in the parse tree node are now shown in alphabetical order.
2022-03-24: wsfulton
#2244 Fix using declaration in derived class bugs when all the base
class's overloaded methods were overridden in the derived class -
fixes "multiply defined" errors.
2022-03-23: wsfulton
[Python] #1779 The -py3 option is deprecated and now has no effect on the
code generated. Use of this option results in a deprecated warning.
The related SWIGPYTHON_PY3 macro that this option defined is no longer generated.
Note that %pythonnondynamic feature generates a metaclass that works on both
Python 2 and Python 3.
2022-03-21: wsfulton
[Python] #1779 pyabc.i for abstract base classes now supports versions of
Python prior to 3.3 by using the collection module for these older versions.
Python-3.3 and later continue to use the collections.abc module.
The -py3 option no longer has any effect on the %pythonabc feature.
2022-03-21: jschueller, jim-easterbrook, wsfulton
[Python] #2137 C++ static member functions no longer generate a "flattened"
name in the Python module. For example:
s = example.Spam()
s.foo() # Spam::foo() via an instance
example.Spam.foo() # Spam::foo() using class method
example.Spam_foo() # Spam::foo() "flattened" name
The "flattened" name is no longer generated, but can be generated
by using the new -flatstaticmethod option.
*** POTENTIAL INCOMPATIBILITY ***
2022-03-18: ianlancetaylor
[Go] #337 Implement %extend base methods in child classes.
2022-03-17: olly
[Python] #1779 SWIG's Python test-suite and examples are now
run with Python 3 by default. To run them with Python 2, set
PY2 to a non-empty value, e.g.:
make check-python-test-suite PY2=1
2022-03-16: olly
[Go] #683 -intgosize is now optional - if not specified the
generated C/C++ wrapper code will use ptrdiff_t for intgo and
size_t for uintgo.
2022-03-15: ianlancetaylor
[Go] Add typemaps for std::string*.
2022-03-15: ianlancetaylor
[Go] Don't convert arrays to pointers if there is a "gotype"
typemap entry.
2022-03-15: ianlancetaylor
[Go] Add documentation note about Go and C++ exceptions.
2022-03-12: wsfulton
#1524 %interface family of macros no longer contain the getter/setter
methods for wrapping variables. The interface only contains
virtual and non-virtual instance methods, that is, no static methods.
Enums are also no longer added to the interface (affects Java only where
they were missing from the proxy class, C# never had them in the interface).
*** POTENTIAL INCOMPATIBILITY ***
2022-03-12: wsfulton
#1277 Fixes for the family of %interface macros, %interface,
%interface_impl and %interface_custom fixes for overloaded methods
in an inheritance chain.
When C++ methods are not able to be overloaded in a derived class,
such as when they differ by just const, or the target language
parameters types are identical even when the C++ parameter types
are different, SWIG will ignore one of the overloaded methods with
a warning. A %ignore is required to explicitly ignore one of the
overloaded methods to avoid the warning message. Methods added
in the derived classes due to one of the %interface macros are now
similarly ignored/not added to the derived class.
The methods added to the derived classes can now also be modified
via %feature and %rename.
2022-03-08: ianlancetaylor
[Go] Treat a nil argument as a NULL pointer.
2022-03-08: ianlancetaylor
[Go] Add documentation notes about thread local storage.
2022-03-08: olly
#1006 SWIG now copes with an interface filename specified on the
command line which contains a closing parenthesis `)`, and more
generally with attributes to `%include` and `%import` which
are quoted and contain parentheses.
2022-03-07: Omar Medina
[Tcl] https://sourceforge.net/p/swig/bugs/1290/
Fix SWIG_AsWCharPtrAndSize() to actually assign to result
variable. It looks like SWIG/Tcl wide character handling is
currently fundamentally broken except on systems which use wide
characters as the system encoding, but this should fix wrapping
functions which take a wide string as a parameter on Microsoft
Windows.
2022-03-07: olly
[Javascript] #682 Fix handling of functions which take void*.
2022-03-06: olly
SWIG should now reliably exit with status 0 if the run was
successful and status 1 if there was an error (or a warning and
-Werror was in effect).
Previously in some situations SWIG would try to exit with the
status set to the number of errors encountered, but that's
problematic - for example if there were 256 errors this would
result in exit status 0 on most platforms. Also some error
statuses have special meanings e.g. those defined by <sysexits.h>.
Also SWIG/Javascript tried to exit with status -1 in a few places
(which typically results in exit status 255).
2022-03-05: wsfulton
#1441 Fix using declaration in derived class incorrectly introducing a method
from a base class when the using declaration is declared before the method
declaration. Problem occurred when within a namespace and the parameter types
in the method signatures were not fully qualified.
2022-03-05: ianlancetaylor
[Go] Treat non-const references as pointers.
2022-03-05: ianlancetaylor
In SWIG Go testsuite, fail test if "go build" fails.
2022-03-03: olly
#1901 #2223 SWIG should now always exit cleanly if memory
allocation fails, including removing any output files created
during the current run.
Previously most places in the code didn't check for a NULL return
from malloc()/realloc()/calloc() at all, typically resulting in
undefined behaviour; some places used assert() to check for a NULL
return (which is a misuse of assert() and such checks disappear if
built with NDEBUG defined leaving us back with undefined
behaviour).
2022-03-03: olly
#891 Report errors for typemap attributes without a value
(previously SWIG segfaulted) and for typemap types with a value
(previously the value was quietly ignored).
The old way of specifying a language name in the typemap attributes
is no longer supported (it has been deprecated for 16 years).
2022-03-02: geographika, wsfulton
[Python] #1951 Add Python variable annotations support.
Both function annotations and variable annotations are turned on using the
"python:annotations" feature. Example:
%feature("python:annotations", "c");
struct V {
float val;
};
The generated code contains a variable annotation containing the C float type:
class V(object):
val: "float" = property(_example.V_val_get, _example.V_val_set)
...
Python 3.5 and earlier do not support variable annotations, so variable
annotations can be turned off with a "python:annotations:novar" feature flag.
Example turning on function annotations but not variable annotations globally:
%feature("python:annotations", "c");
%feature("python:annotations:novar");
or via the command line:
-features python:annotations=c,python:annotations:novar
*** POTENTIAL INCOMPATIBILITY ***
2022-02-27: wsfulton
[Python] #735 #1561 Function annotations containing C/C++ types are no longer
generated when using the -py3 option. Function annotations support has been
moved to a feature to provide finer grained control. It can be turned on
globally by adding:
%feature("python:annotations", "c");
or by using the command line argument:
-features python:annotations=c
Also see entry dated 2022-03-02, regarding variable annotations.
*** POTENTIAL INCOMPATIBILITY ***
2022-02-26: wsfulton
#655 #1840 Add new warning WARN_LANG_USING_NAME_DIFFERENT to warn when a
method introduced by a using declaration in a derived class cannot
be used due to a conflict in names.
2022-02-24: olly
#1465 An invalid preprocessor expression is reported as a pair of
warnings with the second giving a more detailed message from the
expression evaluator. Previously SWIG prefixed the second message
with "Error:" - that was confusing as it's actually only a warning
by default so we've now dropped this prefix.
Before:
x.i:1: Warning 202: Could not evaluate expression '1.2'
x.i:1: Warning 202: Error: 'Floating point constant in preprocessor expression'
Now:
x.i:1: Warning 202: Could not evaluate expression '1.2'
x.i:1: Warning 202: Floating point constant in preprocessor expression
2022-02-23: olly
#1384 Fix a preprocessor expression evaluation bug. A
subexpression in parentheses lost its string/int type flag and
instead used whatever type was left in the stack entry from
previous use. In practice we mostly got away with this because
most preprocessor expressions are integer, but it could have
resulted in a preprocessor expression incorrectly evaluating as
zero. If -Wextra was in use you got a warning:
Warning 202: Error: 'Can't mix strings and integers in expression'
2022-02-21: davidcl
[Scilab] Improve 5.5.2, 6.0.0 and 6.1.0 support.
For Scilab 5, long names are reduced to small names preserving the
class prefix and accessor suffix (get or set).
For Scilab 6, long names with the class prefix and accessor suffix
should be used on the user code.
The `-targetversion` option has been removed as the generated code
now detects the Scilab version in loader.sce or builder.sce.
*** POTENTIAL INCOMPATIBILITY ***
2022-02-20: wsfulton
Fix %warnfilter warning suppress for warning 315 SWIGWARN_PARSE_USING_UNDEF.
2022-02-17: olly
[PHP] https://sourceforge.net/p/swig/bugs/1211/
Fix to call cleanup code in exception situations and not to invoke
the freearg typemap twice in certain situations.
2022-02-15: olly
#300 #368 Improve parser handling of % followed immediately by
an identifier. If it's not a recognised directive the scanner
now emits MODULO and then rescans what follows, and if the parser
then gives a syntax error we report it as an unknown directive.
This means that `a%b` is now allowed in an expression, and that
things like `%std::vector<std::string>` now give an error rather
than being quietly ignored.
2022-02-11: adr26
[Python] #2154 Fix memory leak.
SWIG python objects were being freed after the corresponding SWIG
module information was destroyed in Python 3, causing leaks when as
a result the object destructor could not be invoked. To prevent this
misordering, SWIG python objects now obtain a reference to the
Python capsule wrapping the module information, so that the module
information is correctly destroyed after all SWIG python objects
have been freed (and corresponding destructors invoked).
2022-02-10: olly
[Tcl] https://sourceforge.net/p/swig/bugs/1207/
https://sourceforge.net/p/swig/bugs/1213/
Fix Tcl generic input typemap for std::vector.
2022-02-07: sethrj
#2196 Add alternative syntax for specifying fragments in typemaps.
New syntax:
%typemap("in", fragment="frag1", fragment="frag2", fragment="frag3") {...}
which is equivalent to:
%typemap(in, fragment="frag1,frag2,frag3") {...}
2022-02-07: olly
#1806 Remove support for the "command" encoder, which was mostly
intended for use in `%rename` - most uses can be achieved using
the "regex" encoder, so we recommend using that instead.
The "command" encoder suffers from a number of issues - as the
documentation for it admitted, "[it] is extremely slow compared to
all the other [encoders] as it involves spawning a separate process
and using it for many declarations is not recommended" and that it
"should generally be avoided because of performance
considerations".
But it's also not portable. The design assumes that `/bin/sh`
supports `<<<` but that's a bash-specific feature so it doesn't
work on platforms where `/bin/sh` is not bash - it fails on
Debian, Ubuntu and probably some other Linux distros, plus most
non-Linux platforms. Microsoft Windows doesn't even have a
/bin/sh as standard.
Finally, no escaping of the passed string is done, so it has
potential security issues (though at least with %rename the input
is limited to valid C/C++ symbol names).
2022-02-06: olly
#2193 -DFOO on the SWIG command line now sets FOO to 1 for
consistency with C/C++ compiler preprocessors. Previously
SWIG set FOO to an empty value.
Existing invocations of SWIG with `-DFOO` where the empty value
matters can be updated to `-DFOO=` which should work with both
old and new releases of SWIG.
*** POTENTIAL INCOMPATIBILITY ***
2022-02-06: sethrj
#2194 Classes that are non-assignable due to const data or const
reference members are now automatically detected.
2022-02-04: friedrichatgc
[Octave] #1672 Fix for isobject for Octave 4.4 - 6.0.
2022-02-03: olly
[C#] #283 #998 Fix memory leak in directorin typemap for
std::string.
2022-02-03: olly
[Python] #967 Make `self` parameter available to user typemaps.
2022-02-03: teythoon
[Python] #801 Fix -Wunused-parameter warnings with builtin,
2022-02-03: teythoon
#801 Fix -Wstrict-prototypes warnings in generated pointer
functions.
2022-02-03: olly
#660 https://sourceforge.net/p/swig/bugs/1081/
Default parameter values containing method calls are now parsed and
handled - e.g. `x->foo(3,4)` and `y.z()`.
2022-02-02: olly
[Ruby] https://sourceforge.net/p/swig/bugs/1136/ Fix remove of prefix
from method name to only remove it at the start.
2022-02-01: olly
#231 Handle returning an object by reference in a C++ trailing
return type.
2022-02-01: davidcl
[Scilab] #745 use SWIG_<module>_Init() as a C module init function.
2022-02-01: olly
[OCaml] #2083 Fix to work when CAML_SAFE_STRING is on, which it is
by default in recent Ocaml releases.
2022-01-31: mreeez
https://sourceforge.net/p/swig/bugs/1147/
Fix copyToR() generated for a struct in a namespace.
2022-01-29: fschlimb
#655 Better handling of using declarations.
2022-01-29: dontpanic92
[Go] #676 Fix code generated for a C++ class with a non-capitalised
name.
2022-01-26: trex58
#1919 #1921 #1923 Various fixes for AIX portability.
2022-01-26: olly
#1935 Don't crash on an unclosed HTML tag in a doxygen comment
when -doxygen is specified.
2022-01-25: olly
Constant expressions now support member access with `.` such as
`foo.bar`. Previous this only worked in a case like `x->foo.bar`.
2022-01-25: olly
#2091 Support most cases of `sizeof` applied to an expression
in constant expressions. Previously there was only support for
`sizeof(<type>)` and expressions which syntactically look like a
type (such as `sizeof(foo)`).
2022-01-25: olly
#80 #635 https://sourceforge.net/p/swig/bugs/1139/
Add support for parsing common cases of `<` and `>` comparisons
in constant expressions. Adding full support for these seems hard
to do without introducing conflicts into the parser grammar, but in
fact all reported cases have had parentheses around the comparison
and we can support that with a few restrictions on the left side of
`<`.
2022-01-25: wsfulton
New warning 327 for extern templates, eg:
extern template class std::vector<int>;
extern template void Func<int>();
results in warning
example.i:3: Warning 327: Extern template ignored.
example.i:4: Warning 327: Extern template ignored.
Extern template classes previously resulted in warning 320.
2022-01-24: romintomasetti
#2131 #2157 C++11 extern function template parsing error fix.
2022-01-21: wsfulton
#2120 #2138 Replace legacy PCRE dependency with PCRE2.
This requires changes for building SWIG from source. See updated
html documentation in Preface.html and Windows.html. Updated
instructions are also shown when running ./configure if PCRE2 is not
found. Note that debian based systems can install PCRE2 using:
apt install libpcre2-dev
Note that https://github.com/swig/swig/wiki/Getting-Started also has
updated information for building from source.
2022-01-19: olly
[PHP] #2027 Automatically generate PHP type declarations for PHP 8.
The generate code still compiles for PHP 7.x, but without type
declarations since PHP 7.x has much more limited type declaration
support.
2022-01-18: olly
[Perl] #1629 Perl 5.8.0 is now the oldest version we aim to support.
2022-01-14: wsfulton
[Python] Fix %callback and specifying the callback function as a
static member function using Python staticmethod syntax, such as
Klass.memberfunction instead of Klass_memberfunction when using
-builtin and -fastproxy.
2022-01-11: wsfulton
[Python] Accept keyword arguments accessing static member functions when
using -builtin and kwargs feature and Python class staticmethod syntax.
The missing keyword argument support was only when using the
class staticmethod syntax, such as Klass.memberfunction, and not when
using the flat static method syntax, such as Klass_memberfunction.
2022-01-04: juierror
[Go] #2045 Add support for std::array in std_array.i.
2021-12-18: olly
[PHP] Add PHP keyword 'readonly' (added in 8.1) to the list SWIG
knows to automatically rename. This keyword is special in that PHP
allows it to be used as a function (or method) name.
2021-12-07: vstinner
[Python] #2116 Python 3.11 support: use Py_SET_TYPE()
2021-12-05: rwf1
[Octave] #2020 #1893 Add support for Octave 6 up to and including 6.4.
Also add support for compiling with -Bsymbolic which is used by default
by mkoctfile.
2021-12-02: jsenn
[Python] #2102 Fixed crashes when using embedded Python interpreters.
2021-11-12: wsfulton
[Javascript] v8 and node only. Fix mismatched new char[] and free()
when wrapping C code char arrays. Now calloc is now used instead of
@ -257,7 +1072,6 @@ Version 4.1.0 (in progress)
%typemap(csinterfacemodifiers) X "internal interface"
2020-09-24: geefr
[C#] #1868 Fix wchar_t* csvarout typemap for member variable wrappers.

11
CMakeLists.txt
View File

@ -73,11 +73,11 @@ if (MSVC)
set (CMAKE_CXX_FLAGS "/EHsc ${CMAKE_CXX_FLAGS}")
endif ()
option (WITH_PCRE "Enable pcre" ON)
option (WITH_PCRE "Enable PCRE" ON)
if (WITH_PCRE)
find_package (PCRE REQUIRED)
find_package (PCRE2 REQUIRED)
set (HAVE_PCRE 1)
include_directories (${PCRE_INCLUDE_DIRS})
include_directories (${PCRE2_INCLUDE_DIRS})
endif()
if (WIN32)
@ -145,8 +145,8 @@ add_executable (swig
${PROJECT_BINARY_DIR}/Source/CParse/parser.c
${PROJECT_BINARY_DIR}/Source/CParse/parser.h
)
if (PCRE_FOUND)
target_link_libraries (swig ${PCRE_LIBRARIES})
if (PCRE2_FOUND)
target_link_libraries (swig ${PCRE2_LIBRARIES})
endif ()
install (TARGETS swig DESTINATION bin)
@ -160,6 +160,7 @@ include (CPack)
# few tests
enable_testing ()
add_test (NAME cmd_version COMMAND swig -version)
add_test (NAME cmd_pcreversion COMMAND swig -pcreversion)
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")

4
Doc/Devel/cmdopt.html
View File

@ -60,7 +60,7 @@ and issues an error message if any unconsumed arguments are found.
<b><tt>void Swig_check_options()</tt></b>
<blockquote>
Checks all command line options to see if they have all been processed. If not, an error message is generated and
execution terminates with a call to <tt>exit()</tt>. This function is currently invoked in <tt>Source/Modules/main.cxx</tt> just before SWIG starts any processing of input files.
SWIG exits. This function is currently invoked in <tt>Source/Modules/main.cxx</tt> just before SWIG starts any processing of input files.
</blockquote>
<h2>Utility Function</h2>
@ -68,7 +68,7 @@ execution terminates with a call to <tt>exit()</tt>. This function is currentl
<b><tt>void Swig_arg_error())</tt></b>
<blockquote>
A generic function that issues an error message about being unable to parse command line options. SWIG is terminated by a call to <tt>exit()</tt>.
A generic function that issues an error message about being unable to parse command line options and SWIG exits.
</body>
</html>

52
Doc/Devel/internals.html
View File

@ -441,12 +441,12 @@ Resulting output:
<blockquote>
<pre>
hash len: 5
get: hashval2
hash item: hashval5 [h5]
hash item: hashval1 [h1]
hash item: hashval2 [h2]
hash item: hashval3 [h3]
list len: 5
get: listval2
list item: newlistval1
list item: listval2
list item: listval3
list item: listval5
</pre>
</blockquote>
@ -494,12 +494,12 @@ Resulting output:
<blockquote>
<pre>
list len: 5
get: listval2
list item: newlistval1
list item: listval2
list item: listval3
list item: listval5
hash len: 5
get: hashval2
hash item: hashval5 [h5]
hash item: hashval1 [h1]
hash item: hashval2 [h2]
hash item: hashval3 [h3]
</pre>
</blockquote>
@ -519,7 +519,27 @@ list item: listval5
<h3>2.10 Utility functions </h3>
</a>
[ TODO ]
<p>
DOH wraps some standard C library functions - these wrapped versions should
always be used in code in the SWIG tool itself (but not in generated code).
When compiling with GCC or clang, the original library function names are
marked as "poisoned" symbols so you should get an error if you accidentally
use one of the unwrapped functions. These functions are:
<ul>
<li><tt>Calloc(m,n)</tt> : wrapper for <tt>calloc(m,n)</tt> which exits on memory failure so never returns <tt>NULL</tt>.
<li><tt>Malloc(n)</tt> : wrapper for <tt>malloc(n)</tt> which exits on memory failure so never returns <tt>NULL</tt>.
<li><tt>Realloc(p,n)</tt> : wrapper for <tt>realloc(p,n)</tt> which exits on memory failure so never returns <tt>NULL</tt>.
<li><tt>Free(p)</tt> : wrapper for <tt>free(p)</tt> (doesn't currently do anything special, really done for consistency with <tt>Malloc()</tt> etc).
<li><tt>Exit(r)</tt> : wrapper for <tt>exit(r)</tt> which for SWIG removes generated files if <tt>r&gt;0</tt>.
</ul>
<tt>abort()</tt> is also poisoned - please use <tt>Exit(EXIT_FAILURE)</tt> instead so that generated files are removed.
</p>
<p>
[ TODO document others ]
</p>
<a name="3" href="#i3">
<h2>3. Types and Typemaps</h2>
@ -1194,12 +1214,12 @@ that are used after they have been deleted. This is because the DOH memory alloc
grabs a chunk of memory from the C memory allocator and manages the usage internally.
Stale DOH object usage can be checked for by defining <tt>DOH_DEBUG_MEMORY_POOLS</tt> in
<tt>memory.c</tt>. If an attempt to use an object is made after the reference count is
zero, an assertion is triggered instead of quietly re-using the stale object...
zero, a fatal error is triggered instead of quietly re-using the stale object:
</p>
<blockquote>
<pre>
swig: DOH/memory.c:91: DohCheck: Assertion `!DOH_object_already_deleted' failed.
Fatal internal error: Attempt to delete a non-DOH object.
</pre>
</blockquote>
@ -1209,7 +1229,7 @@ only recommended for diagnosing memory corruption problems.
</p>
<hr>
Copyright (C) 1999-2010 SWIG Development Team.
Copyright (C) 1999-2022 SWIG Development Team.
</body>
</html>

6
Doc/Devel/plan-gsoc-2012.txt
View File

@ -45,7 +45,7 @@ Functionality
-----------------
Note:
See 'http://www.stack.nl/~dimitri/doxygen/docblocks.html' for
See 'https://www.doxygen.nl/manual/docblocks.html' for
the detailed description of Doxygen syntax and terms used in this
section.
@ -72,10 +72,10 @@ Functionality
----
This section contains all doxygen tags taken from
http://www.stack.nl/~dimitri/doxygen/commands.html. If a tag is
https://www.doxygen.nl/manual/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.
tag with its contents is stripped out of the output.
Doxygen tags:

1
Doc/Devel/scanner.html
View File

@ -204,6 +204,7 @@ SWIG_TOKEN_LESSTHAN &lt;
SWIG_TOKEN_GREATERTHAN &gt;
SWIG_TOKEN_LTEQUAL &lt;=
SWIG_TOKEN_GTEQUAL &gt;=
SWIG_TOKEN_LTEQUALGT &lt;=&gt;
SWIG_TOKEN_NOT ~
SWIG_TOKEN_LNOT !
SWIG_TOKEN_LBRACKET [

4
Doc/Devel/tree.html
View File

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

424
Doc/Manual/CPlusPlus11.html
View File

@ -15,6 +15,11 @@
<li><a href="#CPlusPlus11_core_language_changes">Core language changes</a>
<ul>
<li><a href="#CPlusPlus11_rvalue_reference_and_move_semantics">Rvalue reference and move semantics</a>
<ul>
<li><a href="#CPlusPlus11_rvalue_reference_inputs">Rvalue reference inputs</a>
<li><a href="#CPlusPlus11_rvalue_reference_outputs">Rvalue reference outputs</a>
<li><a href="#CPlusPlus11_move_only">Movable and move-only types by value</a>
</ul>
<li><a href="#CPlusPlus11_generalized_constant_expressions">Generalized constant expressions</a>
<li><a href="#CPlusPlus11_extern_template">Extern template</a>
<li><a href="#CPlusPlus11_initializer_lists">Initializer lists</a>
@ -95,6 +100,7 @@ class MyClass {
...
std::vector&lt;int&gt; numbers;
public:
MyClass() : numbers() {}
MyClass(MyClass &amp;&amp;other) : numbers(std::move(other.numbers)) {}
MyClass &amp; operator=(MyClass &amp;&amp;other) {
numbers = std::move(other.numbers);
@ -104,8 +110,8 @@ public:
</pre></div>
<p>
Rvalue references are designed for C++ temporaries and so are not very useful when used from non-C++ target languages.
Generally you would just ignore them via <tt>%ignore</tt> before parsing the class.
Rvalue references are designed for C++ temporaries and are not particularly useful when used from non-C++ target languages.
One option is to just ignore them via <tt>%ignore</tt>.
For example, ignore the move constructor:
</p>
@ -113,8 +119,49 @@ For example, ignore the move constructor:
%ignore MyClass::MyClass(MyClass &amp;&amp;);
</pre></div>
<H4><a name="CPlusPlus11_rvalue_reference_inputs">7.2.1.1 Rvalue reference inputs</a></H4>
<p>
The plan is to ignore move constructors by default in a future version of SWIG. Note that both normal assignment operators as well as move assignment operators are ignored by default in most target languages with the following warning:
Rvalue reference parameters are useful as input parameters in C++ for implementing move semantics, such as,
in the move constructor and move assignment operator.
This type of usage can be useful from target languages too to avoid copying large objects.
</p>
<p>
If you do wrap a function/contructor with an rvalue reference parameter and pass a proxy class to it, SWIG will assume that after the call, the rvalue reference parameter object will have been 'moved'.
The proxy class passed as the rvalue reference, will own the underlying C++ object up until it is used as an rvalue reference parameter.
Afterwards, the proxy class will have the underlying C++ pointer set to the nullptr so that the proxy class instance cannot be used again and the underlying (moved from) C++ object will be deleted after the function/constructor call has returned.
</p>
<p>
In this way, the SWIG proxy class works much like an exclusively owned smart pointer (think of <tt>std::unique_ptr</tt>), passing ownership to the called C++ function/constructor.
Let's consider an example in Java using the wrapped proxy class from above:
</p>
<div class="targetlang"><pre>
MyClass mc = new MyClass();
MyClass mc1 = new MyClass(mc); // move constructor
MyClass mc2 = new MyClass(mc); // move constructor fails
</pre></div>
<p>
The second call to the move constructor will fail as the <tt>mc</tt> proxy instance has been moved.
Each target language handles the moved proxy class slightly differently when attempting to move it again, but typically you'll get an exception such as in Java:
</p>
<div class="shell">
<pre>
Exception in thread "main" java.lang.RuntimeException: Cannot release ownership as memory is not owned
at MyClass.swigRelease(MyClass.java:27)
at MyClass.&lt;init&gt;(MyClass.java:55)
at runme.main(runme.java:18)
</pre>
</div>
<p>
Note that both normal copy assignment operators as well as move assignment operators are ignored by default in the target languages with the following warning:
</p>
<div class="shell">
@ -123,6 +170,332 @@ example.i:18: Warning 503: Can't wrap 'operator =' unless renamed to a valid ide
</pre>
</div>
<p>
Using a <tt>%rename</tt> will remove the warning and also makes the move assignment operator available from the target language:
</p>
<div class="code"><pre>
%rename(MoveAssign) MyClass::operator=(MyClass &amp;&amp;);
</pre></div>
<p>
You can then use it, but like the move constructor example above, you cannot use
a proxy class once it has already been moved:
</p>
<div class="targetlang"><pre>
MyClass mc = new MyClass();
MyClass mc2 = mc.MoveAssign(mc);
MyClass mc3 = mc.MoveAssign(mc); // Use of mc again will fail
</pre></div>
<p>
It is of course perfectly possible in C++ for a function/constructor to not move an object passed to it in an rvalue reference parameter. The assumption that SWIG makes would then not hold and customisation of the appropriate input typemaps would be required.
For scripting languages, this would be for the 'in' typemap and for the non-scripting languages additional typemaps such as the 'javain' typemap, which is used to set the memory ownership of the underlying C++ object for Java, would also need copying and modifying appropriately.
</p>
<p>
<b>Compatibility note:</b>
SWIG-4.1.0 changed the way that rvalue reference parameters were handled and implemented typemaps assuming that the
proxy class owns the underlying C++ object and transfers ownership of the object when a function/constructor with an rvalue reference parameter is called.
</p>
<H4><a name="CPlusPlus11_rvalue_reference_outputs">7.2.1.2 Rvalue reference outputs</a></H4>
<p>
While rvalue reference parameter inputs are not uncommon in C++ and can be usefully utilised from target languages, this cannot be said for rvalue reference outputs.
Firstly, it is quite unusual in C++ to have functions that return an rvalue reference.
Secondly, these cases are nigh on impossible to use from a target language.
The main problem is these references are for C++ compiler temporaries used on the stack and the target languages use objects on the heap
and the concept of compiler temporary objects doesn't make sense from another language.
</p>
<p>
Using <tt>MyClass</tt> from earlier and this C++ code:
</p>
<div class="code"><pre>
void use(MyClass &amp;&amp;mc);
MyClass &amp;&amp; get1();
MyClass &amp; get2();
</pre></div>
<p>
SWIG wraps the <tt>get1</tt> and <tt>get2</tt> functions more or less identically.
The returned references are converted into pointers that are not owned by the target language.
It means that the following perfectly valid C++ has no equivalent in any of the target languages:
</p>
<div class="code"><pre>
use(get1());
use(std::move(get2()));
</pre></div>
<p>
An attempt to call the equivalent <tt>use(get1())</tt> from one of the target languages will result in the ownership failure mentioned in the previous section as the object being passed to the <tt>use</tt> function is not owned by the proxy class.
In order to own the object, it would need to be cloned for the object to move from the stack to the heap, for which an appropriate clone function would be required, but may not even be available.
Note that a move constructor or copy constructor may slice the object when inheritance is involved.
Alternatively, customising the input rvalue reference typemap, as mentioned in the previous section, could remove the ownership requirement.
Another alternative would be to modify the output rvalue reference typemap to always clone the rvalue reference object.
Fortunately you're highly unlikely to have to solve any of these issues!
</p>
<H4><a name="CPlusPlus11_move_only">7.2.1.3 Movable and move-only types by value</a></H4>
<p>
SWIG has traditionally relied on wrapped C++ types to be copy constructible or copy assignable, either via an explicit or implicit copy constructor and copy assignment operator.
Prior to C++11, a function could not return nor take a type by value that was not copyable.
In C++11 this is no longer the case. A type can also be movable if it has has a move constructor and a move assignment operator.
A move-only type is movable but not copyable; it has both the copy constructor and copy assignment operator deleted.
Movable types can appear in function signatures for passing 'by value' and in C++11 the object can then be moved rather than copied.
</p>
<p>
SWIG has support for both copyable and/or movable types.
Support for move semantics is quite seamless when returning by value from a function.
Support for move semantics is less so and may require some customisation when passing by value to a function.
First let's consider returning by value from a function.
</p>
<p>
The support for function return values is generically implemented in the "out" <tt>SWIGTYPE</tt> typemap which supports any type, including copyable, movable and move-only types.
The typemap code is very simple and written so that the compiler will call the move constructor if possible,
otherwise the copy constructor:
</p>
<div class="code"><pre>
%typemap(out) SWIGTYPE %{
$result = new $1_ltype($1);
%}
</pre></div>
<p>
The above typemap is for C# and when used to wrap a move-only type such as:
</p>
<div class="code"><pre>
struct MoveOnly {
int val;
MoveOnly(): val(0) {}
MoveOnly(const MoveOnly &amp;) = delete;
MoveOnly(MoveOnly &amp;&amp;) = default;
MoveOnly &amp; operator=(const MoveOnly &amp;) = delete;
MoveOnly &amp; operator=(MoveOnly &amp;&amp;) = default;
static MoveOnly create() { return MoveOnly(); }
static void take(MoveOnly mo);
};
</pre></div>
<p>
will generate wrapper code for the <tt>create</tt> factory method:
</p>
<div class="code"><pre>
SWIGEXPORT void * SWIGSTDCALL CSharp_MoveOnly_create() {
void * jresult ;
SwigValueWrapper&lt; MoveOnly &gt; result;
result = MoveOnly::create();
jresult = new MoveOnly(result);
return jresult;
}
</pre></div>
<p>
<tt>SwigValueWrapper</tt> is covered in <a href="SWIGPlus.html#SWIGPlus_nn19">Pass and return by value</a>.
Note that the generated code could be optimised further using the <a href="Typemaps.html#Typemaps_optimal">"optimal" attribute</a>
in the "out" typemap, so if the above typemap is customised as follows (note that this is C# specific):
</p>
<div class="code"><pre>
%typemap(out, optimal="1") MoveOnly %{
$result = new $1_ltype($1);
%}
</pre></div>
<p>
then the generated code will result in the object being optimally moved:
</p>
<div class="code"><pre>
SWIGEXPORT void * SWIGSTDCALL CSharp_MoveOnly_create() {
void * jresult ;
jresult = new MoveOnly(MoveOnly::create());
return jresult;
}
</pre></div>
<p>
Now let's consider passing by value.
We'll consider three cases; namely types that are:
</p>
<ol>
<li> Copyable and not movable - <tt>CopyOnly</tt>.</li>
<li> Copyable and movable - <tt>MovableCopyable</tt>.</li>
<li> Movable and not copyable - <tt>MoveOnly</tt>.</li>
</ol>
<p>
and for clarification, define these two additional types as follows:
</p>
<div class="code"><pre>
struct CopyOnly {
int val;
CopyOnly(): val(0) {}
CopyOnly(const CopyOnly &amp;) = default;
CopyOnly &amp; operator=(const CopyOnly &amp;) = default;
static CopyOnly create() { return CopyOnly(); }
static void take(CopyOnly co);
};
struct MovableCopyable {
int val;
MovableCopyable(): val(0) {}
MovableCopyable(const MovableCopyable &amp;) = default;
MovableCopyable(MovableCopyable &amp;&amp;) = default;
MovableCopyable &amp; operator=(const MovableCopyable &amp;) = default;
MovableCopyable &amp; operator=(MovableCopyable &amp;&amp;) = default;
static MovableCopyable create() { return MovableCopyable(); }
static void take(MovableCopyable mc);
};
</pre></div>
<p>
The generated code is shown below for <tt>CopyOnly::take</tt> (with additional comments for when constructors and assignment operators are called).
While the code shown is C# specific, the generated constructor and/or assignment operator calls are ultimately the same for all target languages.
</p>
<div class="code"><pre>
SWIGEXPORT void SWIGSTDCALL CSharp_CopyOnly_take(void * jarg1) {
CopyOnly arg1 ; // (a) Default constructor
CopyOnly *argp1 ;
argp1 = (CopyOnly *)jarg1;
if (!argp1) {
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentNullException, "Attempt to dereference null CopyOnly", 0);
return ;
}
arg1 = *argp1; // (b) Copy assignment
CopyOnly::take(SWIG_STD_MOVE(arg1)); // (c) Copy constructor
}
</pre></div>
<p>
Note that <tt>SWIG_STD_MOVE</tt> is a macro defined as shown below to use <tt>std::move</tt> which is only available from C++11 onwards:
</p>
<div class="code"><pre>
#if __cplusplus &gt;=201103L
# define SWIG_STD_MOVE(OBJ) std::move(OBJ)
#else
# define SWIG_STD_MOVE(OBJ) OBJ
#endif
</pre></div>
<p>
Also note: <i>(c) Copy constructor</i>.
Yes, when passing by value the copy constructor is called for all versions of C++, even C++11 and later even though std::move is specified.
It's a C++ language feature for types that don't have move semantics!
</p>
<p>
The generated code for <tt>MovableCopyable::take</tt> is the same as for <tt>CopyOnly::take</tt>, however, the C++ compiler will choose the move constructor this time where commented <i>(c) Move constructor</i>:
</p>
<div class="code"><pre>
SWIGEXPORT void SWIGSTDCALL CSharp_MovableCopyable_take(void * jarg1) {
MovableCopyable arg1 ; // (a) Default constructor
MovableCopyable *argp1 ;
argp1 = (MovableCopyable *)jarg1;
if (!argp1) {
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentNullException, "Attempt to dereference null MovableCopyable", 0);
return ;
}
arg1 = *argp1; // (b) Copy assignment
MovableCopyable::take(SWIG_STD_MOVE(arg1)); // (c) Move constructor
}
</pre></div>
<p>
There are two optimisation opportunities available.
</p>
<ol>
<li> Remove the default constructor call with the <tt>%feature("valuewrapper")</tt> covered in <a href="SWIGPlus.html#SWIGPlus_nn19">Pass and return by value</a> and replace it with <tt>SwigValueWrapper</tt>.
</li>
<li> Apply the SWIGTYPE MOVE typemaps which are designed specifically to implement full move semantics when passing parameters by value.
They replace the copy assignment with a call to <tt>SwigValueWrapper::reset</tt>, which works much like <tt>std::unique_ptr::reset</tt>.
These typemaps could alternatively have replaced the copy assignment with a move assignment, but this is not maximally optimal.
</li>
</ol>
<p>
Simply add the following before the <tt>MovableCopyable::take</tt> method is parsed:
</p>
<div class="code"><pre>
%valuewrapper MovableCopyable;
%include &lt;swigmove.i&gt;
%apply SWIGTYPE MOVE { MovableCopyable }
</pre></div>
<p>
will result in this optimal code where just one move constructor is invoked:
</p>
<div class="code"><pre>
SWIGEXPORT void SWIGSTDCALL CSharp_MovableCopyable_take(void * jarg1) {
SwigValueWrapper&lt; MovableCopyable &gt; arg1 ; // (a) No constructors invoked
MovableCopyable *argp1 ;
argp1 = (MovableCopyable *)jarg1;
if (!argp1) {
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentNullException, "Attempt to dereference null MovableCopyable", 0);
return ;
}
SwigValueWrapper&lt; MovableCopyable &gt;::reset(arg1, argp1); // (b) No constructor or assignment operator invoked
MovableCopyable::take(SWIG_STD_MOVE(arg1)); // (c) Move constructor
}
</pre></div>
<p>
Note that <tt>SwigValueWrapper</tt> will call the destructor for the pointer passed to it in the <tt>reset</tt> function.
This pointer is the underlying C++ object that the proxy class owns.
The details aren't shown, but the 'csin' typemap also generates C# code to ensure that the proxy class releases ownership of the object.
Please see the 'SWIGTYPE MOVE' typemaps in the swigmove.i file provided for each target language.
Therefore full move semantics are implemented; ownership is moved from the proxy class into the C++ layer and the net effect
is the same as using an <a href="#CPlusPlus11_rvalue_reference_inputs">rvalue reference parameter</a> discussed earlier.
</p>
<p>
Lastly, let's consider the <tt>MoveOnly::take</tt> function defined earlier.
By default the generated code fails to compile as <tt>MoveOnly</tt> does not have a copy assignment operator.
SWIG is not designed to select a different typemap automatically for move-only types and the user
must apply the SWIGTYPE MOVE typemaps to ensure that only move-only semantics are used.
However, SWIG is able to automatically use <tt>%feature("valuewrapper")</tt> for move-only
types so it is not necessary to explicitly use this feature.
So in this move-only case, simply add the following before <tt>MoveOnly::take</tt> is parsed, which results in the same optimal code shown above for <tt>MovableCopyable</tt>:
</p>
<div class="code"><pre>
%include &lt;swigmove.i&gt;
%apply SWIGTYPE MOVE { MoveOnly }
</pre></div>
<p>
<b>Compatibility note:</b>
SWIG-4.1.0 introduced support for taking advantage of types with move semantics and making it possible to easily use move only types.
</p>
<H3><a name="CPlusPlus11_generalized_constant_expressions">7.2.2 Generalized constant expressions</a></H3>
@ -144,14 +517,39 @@ When either of these is used from a target language, a runtime call is made to o
<H3><a name="CPlusPlus11_extern_template">7.2.3 Extern template</a></H3>
<p>SWIG correctly parses the keywords <tt>extern template</tt>.
<p>SWIG correctly parses <tt>extern template</tt> explicit instantiation declarations.
However, this template instantiation suppression in a translation unit has no relevance outside of the C++ compiler and so is not used by SWIG.
SWIG only uses <tt>%template</tt> for instantiating and wrapping templates.</p>
SWIG only uses <tt>%template</tt> for instantiating and wrapping templates.
Consider the class template below:
</p>
<div class="code"><pre>
template class std::vector&lt;int&gt;; // C++03 explicit instantiation in C++
extern template class std::vector&lt;int&gt;; // C++11 explicit instantiation suppression in C++
%template(VectorInt) std::vector&lt;int&gt;; // SWIG instantiation
// Class template
template class std::vector&lt;int&gt;; // C++03 template explicit instantiation definition in C++
extern template class std::vector&lt;int&gt;; // C++11 template explicit instantiation declaration (extern template)
%template(VectorInt) std::vector&lt;int&gt;; // SWIG template instantiation
</pre></div>
<p>
The above result in warnings:
</p>
<div class="shell">
<pre>
example.i:2: Warning 320: Explicit template instantiation ignored.
example.i:3: Warning 327: Extern template ignored.
</pre>
</div>
<p>
Similarly for the function template below:
</p>
<div class="code"><pre>
// Function template
template void Func&lt;int&gt;(); // C++03 template explicit instantiation definition in C++
extern template void Func&lt;int&gt;(); // C++11 template explicit instantiation declaration (extern template)
%template(FuncInt) Func&lt;int&gt;; // SWIG template instantiation
</pre></div>
<H3><a name="CPlusPlus11_initializer_lists">7.2.4 Initializer lists</a></H3>
@ -985,7 +1383,9 @@ Use the preprocessor to work around this for now:
<p>
Attributes such as those shown below, are not yet supported and will give a syntax error.
Attributes such as those shown below, are supported since SWIG 4.1.0 but are
currently crudely ignored by the parser's tokeniser so they have no effect on
SWIG's code generation.
</p>
<div class="code"><pre>
@ -1132,8 +1532,10 @@ While SWIG could provide wrappers for the new C++11 regular expressions classes,
<p>
SWIG provides special smart pointer handling for <tt>std::shared_ptr</tt> in the same way it has support for <tt>boost::shared_ptr</tt>.
Please see the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a> library section.
There is no special smart pointer handling available for <tt>std::weak_ptr</tt> and <tt>std::unique_ptr</tt> yet.
Please see the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a>
and <a href="Library.html#Library_std_unique_ptr">unique_ptr smart pointer</a> library sections.
There is no special smart pointer handling available for <tt>std::weak_ptr</tt>.
</p>
<H3><a name="CPlusPlus11_extensible_random_number_facility">7.3.6 Extensible random number facility</a></H3>

30
Doc/Manual/CPlusPlus20.html
View File

@ -13,6 +13,10 @@
<ul>
<li><a href="#CPlusPlus20_introduction">Introduction</a>
<li><a href="#CPlusPlus20_core_language_changes">Core language changes</a>
<ul>
<li><a href="#CPlusPlus20_spaceship_operator">Spaceship operator</a>
<li><a href="#CPlusPlus20_lambda_templates">Lambda templates</a>
</ul>
<li><a href="#CPlusPlus20_standard_library_changes">Standard library changes</a>
</ul>
</div>
@ -35,6 +39,32 @@ Work has only just begun on adding C++20 support.
<H2><a name="CPlusPlus20_core_language_changes">10.2 Core language changes</a></H2>
<H3><a name="CPlusPlus20_spaceship_operator">10.2.1 Spaceship operator</a></H3>
<p>
SWIG supports the spaceship operator <tt>&lt;=&gt;</tt> in constant
expressions. To simplify handling of the return value type, it is currently
treated as an integer rather than <tt>std::strong_ordering</tt>, etc.
In practice we think that should do the right thing in most cases.
</p>
<p>
SWIG also recognises <tt>operator&lt;=&gt;</tt> which can be wrapped
if renamed. There is not currently any default renaming for the operator
or any attempt to automatically map it to a three-way comparison operator
in any of the target languages.
</p>
<H3><a name="CPlusPlus20_lambda_templates">10.2.2 Lambda templates</a></H3>
<p>
SWIG should parse lambda templates, but like
<a href="CPlusPlus11.html#CPlusPlus11_lambda_functions_and_expressions">
non-templated lambdas</a> they aren't currently wrapped.
</p>
<H2><a name="CPlusPlus20_standard_library_changes">10.3 Standard library changes</a></H2>

6
Doc/Manual/CSharp.html
View File

@ -550,6 +550,12 @@ This special variable expands to the intermediary class name. For C# this is usu
unless the imclassname attribute is specified in the <a href="CSharp.html#CSharp_module_directive">%module directive</a>.
</p>
<p>
<b><tt>$imfuncname</tt></b><br>
This special variable expands to the name of the function in the intermediary class that will be used in $imcall.
Like, $imcall, this special variable is only expanded in the "csout", "csvarin" and "csvarout" typemaps.
</p>
<p>
The directory <tt>Examples/csharp</tt> has a number of simple examples.
Visual Studio .NET 2003 solution and project files are available for compiling with the Microsoft .NET C#

35
Doc/Manual/Contents.html
View File

@ -91,17 +91,16 @@
</ul>
<li><a href="Windows.html#Windows_other_compilers">Instructions for using the Examples with other compilers</a>
</ul>
<li><a href="Windows.html#Windows_cygwin_mingw">SWIG on Cygwin and MinGW</a>
<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 MSYS2</a>
<li><a href="Windows.html#Windows_msys2">Building swig.exe using MSYS2</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>
</ul>
<ul>
<li><a href="Windows.html#Windows_examples_cygwin">Running the examples on Windows using Cygwin</a>
</ul>
</ul>
<li><a href="Windows.html#Windows_interface_file">Microsoft extensions and other Windows quirks</a>
</ul>
</div>
@ -172,6 +171,7 @@
<li><a href="SWIG.html#SWIG_rename_ignore">Renaming and ignoring declarations</a>
<ul>
<li><a href="SWIG.html#SWIG_nn29">Simple renaming of specific identifiers</a>
<li><a href="SWIG.html#SWIG_ignore">Ignoring identifiers</a>
<li><a href="SWIG.html#SWIG_advanced_renaming">Advanced renaming support</a>
<li><a href="SWIG.html#SWIG_limiting_renaming">Limiting global renaming rules</a>
<li><a href="SWIG.html#SWIG_chosen_unignore">Ignoring everything then wrapping a few selected symbols</a>
@ -251,6 +251,9 @@
</ul>
<li><a href="SWIGPlus.html#SWIGPlus_nn28">Overloaded operators</a>
<li><a href="SWIGPlus.html#SWIGPlus_class_extension">Class extension</a>
<ul>
<li><a href="SWIGPlus.html#SWIGPlus_replacing_methods">Replacing class methods</a>
</ul>
<li><a href="SWIGPlus.html#SWIGPlus_nn30">Templates</a>
<ul>
<li><a href="SWIGPlus.html#SWIGPlus_template_directive">The %template directive</a>
@ -294,6 +297,11 @@
<li><a href="CPlusPlus11.html#CPlusPlus11_core_language_changes">Core language changes</a>
<ul>
<li><a href="CPlusPlus11.html#CPlusPlus11_rvalue_reference_and_move_semantics">Rvalue reference and move semantics</a>
<ul>
<li><a href="CPlusPlus11.html#CPlusPlus11_rvalue_reference_inputs">Rvalue reference inputs</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_rvalue_reference_outputs">Rvalue reference outputs</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_move_only">Movable and move-only types by value</a>
</ul>
<li><a href="CPlusPlus11.html#CPlusPlus11_generalized_constant_expressions">Generalized constant expressions</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_extern_template">Extern template</a>
<li><a href="CPlusPlus11.html#CPlusPlus11_initializer_lists">Initializer lists</a>
@ -380,6 +388,10 @@
<ul>
<li><a href="CPlusPlus20.html#CPlusPlus20_introduction">Introduction</a>
<li><a href="CPlusPlus20.html#CPlusPlus20_core_language_changes">Core language changes</a>
<ul>
<li><a href="CPlusPlus20.html#CPlusPlus20_spaceship_operator">Spaceship operator</a>
<li><a href="CPlusPlus20.html#CPlusPlus20_lambda_templates">Lambda templates</a>
</ul>
<li><a href="CPlusPlus20.html#CPlusPlus20_standard_library_changes">Standard library changes</a>
</ul>
</div>
@ -416,6 +428,7 @@
<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>
<ul>
<li><a href="Library.html#Library_argcargv">argcargv.i</a>
<li><a href="Library.html#Library_nn4">cpointer.i</a>
<li><a href="Library.html#Library_carrays">carrays.i</a>
<li><a href="Library.html#Library_nn6">cmalloc.i</a>
@ -441,11 +454,16 @@
<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_unique_ptr">unique_ptr smart pointer</a>
<li><a href="Library.html#Library_std_auto_ptr">auto_ptr smart pointer</a>
</ul>
<li><a href="Library.html#Library_nn16">Utility Libraries</a>
<ul>
<li><a href="Library.html#Library_nn17">exception.i</a>
<li><a href="Library.html#Library_attributes">attribute.i</a>
<ul>
<li><a href="Library.html#Library_attribute_templates">%attribute and C++ templates</a>
</ul>
</ul>
</ul>
</div>
@ -516,6 +534,7 @@
<ul>
<li><a href="Typemaps.html#Typemaps_special_macro_descriptor">$descriptor(type)</a>
<li><a href="Typemaps.html#Typemaps_special_macro_typemap">$typemap(method, typepattern)</a>
<li><a href="Typemaps.html#Typemaps_special_macro_typemap_attribute">$typemap(method:attribute, typepattern)</a>
</ul>
<li><a href="Typemaps.html#Typemaps_special_variable_attributes">Special variables and typemap attributes</a>
<li><a href="Typemaps.html#Typemaps_special_variables_and_macros">Special variables combined with special variable macros</a>
@ -870,6 +889,8 @@
<li><a href="Go.html#Go_class_inheritance">Go Class Inheritance</a>
</ul>
<li><a href="Go.html#Go_templates">Go Templates</a>
<li><a href="Go.html#Go_threads">Go and C/C++ Threads</a>
<li><a href="Go.html#Go_exceptions">Go and C++ Exceptions</a>
<li><a href="Go.html#Go_director_classes">Go Director Classes</a>
<ul>
<li><a href="Go.html#Go_director_example_cpp_code">Example C++ code</a>
@ -1455,6 +1476,7 @@
<li><a href="Python.html#Python_nn70">%feature("autodoc", "docstring")</a>
</ul>
<li><a href="Python.html#Python_nn71">%feature("docstring")</a>
<li><a href="Python.html#Python_doxygen_docstrings">Doxygen comments</a>
</ul>
<li><a href="Python.html#Python_nn72">Python Packages</a>
<ul>
@ -1474,7 +1496,10 @@
</ul>
<li><a href="Python.html#Python_python3support">Python 3 Support</a>
<ul>
<li><a href="Python.html#Python_nn74">Function annotation</a>
<li><a href="Python.html#Python_annotations">Python function annotations and variable annotations</a>
<ul>
<li><a href="Python.html#Python_annotations_c">C/C++ annotation types</a>
</ul>
<li><a href="Python.html#Python_nn75">Buffer interface</a>
<li><a href="Python.html#Python_nn76">Abstract base classes</a>
<li><a href="Python.html#Python_nn77">Byte string output conversion</a>

2
Doc/Manual/Customization.html
View File

@ -668,7 +668,7 @@ results. For example:
<div class="code">
<pre>
%typemap(newfree) char * "free($1);";
%typemap(newfree) char * "free($1);"
...
%newobject strdup;
...

8
Doc/Manual/D.html
View File

@ -267,12 +267,18 @@ SomeClass bar() {
</pre></div>
</dd>
<dt><tt>$imfuncname</tt></dt>
<dd><p>
This special variable expands to the name of the function in the intermediary class that will be used in $imcall.
Like, $imcall, this special variable is only expanded in the "dout" typemap.
</p></dd>
<dt><a name="D_importtype"></a><tt>$importtype(SomeDType)</tt></dt>
<dd>
<p>This macro is used in the <tt>dimports</tt> typemap if a dependency on another D type generated by SWIG is added by a custom typemap.</p>
<p>Consider the following code snippet:</p>
<div class="code"><pre>
%typemap(dinterfaces) SomeClass "AnInterface, AnotherInterface";
%typemap(dinterfaces) SomeClass "AnInterface, AnotherInterface"
</pre></div>
<p>This causes SWIG to add <tt>AnInterface</tt> and <tt>AnotherInterface</tt> to the base class list of <tt>SomeClass</tt>:</p>
<div class="targetlang"><pre>

4
Doc/Manual/Doxygen.html
View File

@ -181,7 +181,7 @@ or enum element comments:
<div class="code"><pre>
enum E_NUMBERS
{
EN_ZERO, ///&lt; The first enum item, gets zero as it's value
EN_ZERO, ///&lt; The first enum item, gets zero as its value
EN_ONE, ///&lt; The second, EN_ONE=1
EN_THREE
};
@ -1114,7 +1114,7 @@ name of the type with namespace scope delimiters (<tt>::</tt>) replaced with a d
change this, you can define your own typemaps for the custom types, e.g:
</p>
<div class="code"><pre>
%typemap(doctype) MyDate "datetime.date";
%typemap(doctype) MyDate "datetime.date"
</pre></div>
<p>

229
Doc/Manual/Extending.html
View File

@ -462,14 +462,14 @@ the stage being processed.
There are a number of other parse tree display options, for example, <tt>swig -debug-module &lt;n&gt;</tt> will
avoid displaying system parse information and only display the parse tree pertaining to the user's module at
stage <tt>n</tt> of processing.
Adding the <tt>-debug-quiet</tt> option is recommended as it removes some noise which is not usually needed,
that is, the display of many linked list pointers and symbol table pointers.
</p>
<div class="shell">
<pre>
$ swig -c++ -python -debug-module 4 example.i
+++ include ----------------------------------------
| name - "example.i"
$ swig -c++ -python -debug-module 1 -debug-quiet example.i
debug-module stage 1
+++ module ----------------------------------------
| name - "example"
|
@ -480,169 +480,202 @@ $ swig -c++ -python -debug-module 4 example.i
| name - "example.h"
+++ class ----------------------------------------
| abstract - "1"
| sym:name - "Shape"
| name - "Shape"
| abstracts - 0x7f4f15182930
| allows_typedef - "1"
| kind - "class"
| symtab - 0x40194140
| sym:symtab - 0x40191078
| name - "Shape"
| sym:name - "Shape"
+++ access ----------------------------------------
| kind - "public"
|
+++ constructor ----------------------------------------
| sym:name - "Shape"
| name - "Shape"
| decl - "f()."
| access - "public"
| code - "{\n nshapes++;\n }"
| sym:symtab - 0x40194140
| decl - "f()."
| feature:new - "1"
| ismember - "1"
| name - "Shape"
| sym:name - "Shape"
|
+++ destructor ----------------------------------------
| sym:name - "~Shape"
| access - "public"
| code - "{\n nshapes--;\n }"
| decl - "f()."
| ismember - "1"
| name - "~Shape"
| storage - "virtual"
| code - "{\n nshapes--;\n }"
| sym:symtab - 0x40194140
| sym:name - "~Shape"
|
+++ cdecl ----------------------------------------
| sym:name - "x"
| access - "public"
| decl - ""
| ismember - "1"
| kind - "variable"
| name - "x"
| decl - ""
| sym:name - "x"
| type - "double"
| sym:symtab - 0x40194140
|
+++ cdecl ----------------------------------------
| sym:name - "y"
| access - "public"
| decl - ""
| ismember - "1"
| kind - "variable"
| name - "y"
| decl - ""
| sym:name - "y"
| type - "double"
| sym:symtab - 0x40194140
|
+++ cdecl ----------------------------------------
| sym:name - "move"
| name - "move"
| access - "public"
| decl - "f(double,double)."
| parms - double, double
| ismember - "1"
| kind - "function"
| name - "move"
| parms - 'double dx,double dy'
| sym:name - "move"
| type - "void"
| sym:symtab - 0x40194140
|
+++ cdecl ----------------------------------------
| sym:name - "area"
| abstract - "1"
| access - "public"
| decl - "f()."
| ismember - "1"
| kind - "function"
| name - "area"
| decl - "f(void)."
| parms - void
| storage - "virtual"
| value - "0"
| sym:name - "area"
| type - "double"
| sym:symtab - 0x40194140
| value - "0"
| valuetype - "int"
|
+++ cdecl ----------------------------------------
| sym:name - "perimeter"
| abstract - "1"
| access - "public"
| decl - "f()."
| ismember - "1"
| kind - "function"
| name - "perimeter"
| decl - "f(void)."
| parms - void
| storage - "virtual"
| value - "0"
| sym:name - "perimeter"
| type - "double"
| sym:symtab - 0x40194140
| value - "0"
| valuetype - "int"
|
+++ cdecl ----------------------------------------
| sym:name - "nshapes"
| access - "public"
| decl - ""
| ismember - "1"
| kind - "variable"
| name - "nshapes"
| decl - ""
| storage - "static"
| sym:name - "nshapes"
| type - "int"
| sym:symtab - 0x40194140
|
+++ class ----------------------------------------
| sym:name - "Circle"
| name - "Circle"
| allows_typedef - "1"
| baselist - 0x7f4f15182ad0
| kind - "class"
| bases - 0x40194510
| symtab - 0x40194538
| sym:symtab - 0x40191078
| name - "Circle"
| privatebaselist - 0x7f4f15182b10
| protectedbaselist - 0x7f4f15182af0
| sym:name - "Circle"
+++ access ----------------------------------------
| kind - "private"
|
+++ cdecl ----------------------------------------
| access - "private"
| decl - ""
| ismember - "1"
| kind - "variable"
| name - "radius"
| decl - ""
| type - "double"
|
+++ access ----------------------------------------
| kind - "public"
|
+++ constructor ----------------------------------------
| sym:name - "Circle"
| name - "Circle"
| parms - double
| decl - "f(double)."
| access - "public"
| code - "{ }"
| sym:symtab - 0x40194538
| decl - "f(double)."
| feature:new - "1"
| ismember - "1"
| name - "Circle"
| parms - 'double r'
| sym:name - "Circle"
|
+++ cdecl ----------------------------------------
| sym:name - "area"
| access - "public"
| decl - "f()."
| ismember - "1"
| kind - "function"
| name - "area"
| decl - "f(void)."
| parms - void
| storage - "virtual"
| sym:name - "area"
| type - "double"
| sym:symtab - 0x40194538
|
+++ cdecl ----------------------------------------
| sym:name - "perimeter"
| access - "public"
| decl - "f()."
| ismember - "1"
| kind - "function"
| name - "perimeter"
| decl - "f(void)."
| parms - void
| storage - "virtual"
| sym:name - "perimeter"
| type - "double"
| sym:symtab - 0x40194538
|
+++ class ----------------------------------------
| sym:name - "Square"
| name - "Square"
| allows_typedef - "1"
| baselist - 0x7f4f15183830
| kind - "class"
| bases - 0x40194760
| symtab - 0x40194788
| sym:symtab - 0x40191078
| name - "Square"
| privatebaselist - 0x7f4f15183870
| protectedbaselist - 0x7f4f15183850
| sym:name - "Square"
+++ access ----------------------------------------
| kind - "private"
|
+++ cdecl ----------------------------------------
| name - "width"
| access - "private"
| decl - ""
| ismember - "1"
| kind - "variable"
| name - "width"
| type - "double"
|
+++ access ----------------------------------------
| kind - "public"
|
+++ constructor ----------------------------------------
| sym:name - "Square"
| name - "Square"
| parms - double
| decl - "f(double)."
| access - "public"
| code - "{ }"
| sym:symtab - 0x40194788
| decl - "f(double)."
| feature:new - "1"
| ismember - "1"
| name - "Square"
| parms - 'double w'
| sym:name - "Square"
|
+++ cdecl ----------------------------------------
| sym:name - "area"
| access - "public"
| decl - "f()."
| ismember - "1"
| kind - "function"
| name - "area"
| decl - "f(void)."
| parms - void
| storage - "virtual"
| sym:name - "area"
| type - "double"
| sym:symtab - 0x40194788
|
+++ cdecl ----------------------------------------
| sym:name - "perimeter"
| access - "public"
| decl - "f()."
| ismember - "1"
| kind - "function"
| name - "perimeter"
| decl - "f(void)."
| parms - void
| storage - "virtual"
| sym:name - "perimeter"
| type - "double"
| sym:symtab - 0x40194788
</pre>
</div>
@ -698,31 +731,28 @@ The parse tree can be viewed after the final stage of processing by running SWIG
<div class="shell">
<pre>
$ swig -debug-top 4 example.i
$ swig -debug-top 1 -debug-quiet example.i
...
+++ cdecl ----------------------------------------
| sym:name - "foo_i"
| name - "foo"
| decl - "f(int)."
| name - "foo"
| parms - int
| sym:name - "foo_i"
| type - "void"
| sym:symtab - 0x40165078
|
+++ cdecl ----------------------------------------
| sym:name - "foo_d"
| name - "foo"
| decl - "f(double)."
| name - "foo"
| parms - double
| sym:name - "foo_d"
| type - "void"
| sym:symtab - 0x40165078
|
+++ cdecl ----------------------------------------
| sym:name - "foo"
| name - "foo"
| decl - "f(p.Bar)."
| name - "foo"
| parms - Bar *
| sym:name - "foo"
| type - "void"
| sym:symtab - 0x40165078
</pre>
</div>
@ -787,19 +817,18 @@ public:
The behavior of <tt>%feature</tt> is very easy to describe--it simply
attaches a new attribute to any parse tree node that matches the
given prototype. When a feature is added, it shows up as an attribute in the <tt>feature:</tt> namespace.
You can see this when running with the <tt>-debug-top 4</tt> option. For example:
You can see this when running with the <tt>-debug-top 4 -debug-quiet</tt> option. For example:
</p>
<div class="shell">
<pre>
+++ cdecl ----------------------------------------
| sym:name - "getitem"
| name - "getitem"
| decl - "f(int).p."
| parms - int
| type - "Object"
| feature:except - "{\n try {\n $action\n } catc..."
| sym:symtab - 0x40168ac8
| name - "getitem"
| parms - int
| sym:name - "getitem"
| type - "Object"
|
</pre>
</div>
@ -1132,6 +1161,11 @@ DOH_REPLACE_FIRST - Replace first occurrence only.
Returns the number of replacements made (if any).
</p>
<p>
At most one of <tt>DOH_REPLACE_ANY</tt> and <tt>DOH_REPLACE_FIRST</tt> should be specified.
<tt>DOH_REPLACE_ANY</tt> is the default if neither is specified.
</p>
</div>
<H3><a name="Extending_nn16">40.5.2 Hashes</a></H3>
@ -2802,7 +2836,7 @@ int Python::top(Node *n) {
f_begin = NewFile(outfile, "w", SWIG_output_files());
if (!f_begin) {
FileErrorDisplay(outfile);
SWIG_exit(EXIT_FAILURE);
Exit(EXIT_FAILURE);
}
f_runtime = NewString("");
f_init = NewString("");
@ -2986,7 +3020,7 @@ virtual int functionWrapper(Node *n) {
/* create the wrapper object */
Wrapper *wrapper = NewWrapper();
/* create the functions wrappered name */
/* create the wrapper function's name */
String *wname = Swig_name_wrapper(iname);
/* deal with overloading */
@ -2995,7 +3029,7 @@ virtual int functionWrapper(Node *n) {
/* write the wrapper function definition */
Printv(wrapper-&gt;def, "RETURN_TYPE ", wname, "(ARGS) {", NIL);
/* if any additional local variable needed, add them now */
/* if any additional local variables are needed, add them now */
...
/* write the list of locals/arguments required */
@ -3588,7 +3622,7 @@ A target language is given the 'Supported' status when
<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.
All the newer C++ standard tests need to work and are grouped together, such as CPP11_TEST_CASES for C++11. These more 'modern' C++ standards are only tested though if the compiler is detected as supporting the given standard.
</li>
<li>
The test-suite must also include at least twenty wide-ranging runtime tests.
@ -3760,6 +3794,7 @@ There are various command line options which can aid debugging a SWIG interface
-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-quiet - Display less parse tree node debug info when using other -debug options
-debug-tags - Display information about the tags found in the interface
-debug-template - Display information for debugging templates
-debug-top &lt;n&gt; - Display entire parse tree at stages 1-4, &lt;n&gt; is a csv list of stages

69
Doc/Manual/Go.html
View File

@ -29,6 +29,8 @@
<li><a href="#Go_class_inheritance">Go Class Inheritance</a>
</ul>
<li><a href="#Go_templates">Go Templates</a>
<li><a href="#Go_threads">Go and C/C++ Threads</a>
<li><a href="#Go_exceptions">Go and C++ Exceptions</a>
<li><a href="#Go_director_classes">Go Director Classes</a>
<ul>
<li><a href="#Go_director_example_cpp_code">Example C++ code</a>
@ -176,10 +178,10 @@ swig -go -help
<td>-intgosize &lt;s&gt;</td>
<td>Set the size for the Go type <tt>int</tt>. This controls the size
that the C/C++ code expects to see. The &lt;s&gt; argument should
be 32 or 64. This option is currently required during the
be 32 or 64. This option was required during the
transition from Go 1.0 to Go 1.1, as the size of <tt>int</tt> on
64-bit x86 systems changes between those releases (from 32 bits to
64 bits). In the future the option may become optional, and SWIG
64-bit x86 systems changed between those releases (from 32 bits to
64 bits). It was made optional in SWIG 4.1.0 and if not specified SWIG
will assume that the size of <tt>int</tt> is the size of a C
pointer.</td>
</tr>
@ -494,10 +496,6 @@ The usage of Go finalizers is problematic with C++'s RAII idiom as it isn't
predictable when the finalizer will run and this might require a Close or Delete
method to be added the Go object that stores a C++ object to mitigate.
</li>
<li>
The Go finalizer function typically runs in a different OS thread which can be
problematic with C++ code that uses thread-local storage.
</li>
</ul>
<p>
@ -557,8 +555,37 @@ In order to use C++ templates in Go, you must tell SWIG to create
wrappers for a particular template instantiation. To do this, use
the <tt>%template</tt> directive.
<H3><a name="Go_threads">25.4.7 Go and C/C++ Threads</a></H3>
<H3><a name="Go_director_classes">25.4.7 Go Director Classes</a></H3>
<p>
C and C++ code can use operating system threads and thread local
storage. Go code uses goroutines, which are multiplexed onto
operating system threads. This multiplexing means that Go code can
change to run on a different thread at any time. C/C++ code, on the
other hand, may assume that it runs on a single thread; this is true
in particular if the C/C++ code uses thread local storage.
</p>
<p>
In order to use Go code with C/C++ code that expects to run on a
single thread, the Go code must call
the <a href="https://pkg.go.dev/runtime#LockOSThread"><code>runtime.LockOSThread</code></a>
function to lock the goroutine onto a single thread.
</p>
<H3><a name="Go_exceptions">25.4.8 Go and C++ Exceptions</a></H3>
<p>
C++ exceptions do not interoperate with Go code. Attempts to throw
C++ exceptions through a Go caller are unreliable: in many cases the
C++ exception handler will be unable to unwind the stack, and the
program will crash. The only safe way to handle C++ exceptions is to
catch them in C++ before returning to Go.
</p>
<H3><a name="Go_director_classes">25.4.9 Go Director Classes</a></H3>
<p>
@ -576,7 +603,7 @@ completely to avoid common pitfalls with directors in Go.
</p>
<H4><a name="Go_director_example_cpp_code">25.4.7.1 Example C++ code</a></H4>
<H4><a name="Go_director_example_cpp_code">25.4.9.1 Example C++ code</a></H4>
<p>
@ -648,7 +675,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
</p>
<H4><a name="Go_director_enable">25.4.7.2 Enable director feature</a></H4>
<H4><a name="Go_director_enable">25.4.9.2 Enable director feature</a></H4>
<p>
@ -683,7 +710,7 @@ documentation on directors.
</p>
<H4><a name="Go_director_ctor_dtor">25.4.7.3 Constructor and destructor</a></H4>
<H4><a name="Go_director_ctor_dtor">25.4.9.3 Constructor and destructor</a></H4>
<p>
@ -736,7 +763,7 @@ embedding</a>.
</p>
<H4><a name="Go_director_overriding">25.4.7.4 Override virtual methods</a></H4>
<H4><a name="Go_director_overriding">25.4.9.4 Override virtual methods</a></H4>
<p>
@ -804,7 +831,7 @@ the Go methods.
</p>
<H4><a name="Go_director_base_methods">25.4.7.5 Call base methods</a></H4>
<H4><a name="Go_director_base_methods">25.4.9.5 Call base methods</a></H4>
<p>
@ -841,7 +868,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
</p>
<H4><a name="Go_director_subclass">25.4.7.6 Subclass via embedding</a></H4>
<H4><a name="Go_director_subclass">25.4.9.6 Subclass via embedding</a></H4>
<p>
@ -909,7 +936,7 @@ class.
</p>
<H4><a name="Go_director_finalizer">25.4.7.7 Memory management with runtime.SetFinalizer</a></H4>
<H4><a name="Go_director_finalizer">25.4.9.7 Memory management with runtime.SetFinalizer</a></H4>
<p>
@ -974,7 +1001,7 @@ before using <tt>runtime.SetFinalizer</tt> to know all of its gotchas.
</p>
<H4><a name="Go_director_foobargo_class">25.4.7.8 Complete FooBarGo example class</a></H4>
<H4><a name="Go_director_foobargo_class">25.4.9.8 Complete FooBarGo example class</a></H4>
<p>
@ -1103,7 +1130,7 @@ SWIG/Examples/go/director/</a>.
</p>
<H3><a name="Go_primitive_type_mappings">25.4.8 Default Go primitive type mappings</a></H3>
<H3><a name="Go_primitive_type_mappings">25.4.10 Default Go primitive type mappings</a></H3>
<p>
@ -1210,7 +1237,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">25.4.9 Output arguments</a></H3>
<H3><a name="Go_output_arguments">25.4.11 Output arguments</a></H3>
<p>Because of limitations in the way output arguments are processed in swig,
@ -1263,7 +1290,7 @@ void f(char *output);
</pre>
</div>
<H3><a name="Go_adding_additional_code">25.4.10 Adding additional go code</a></H3>
<H3><a name="Go_adding_additional_code">25.4.12 Adding additional go code</a></H3>
<p>Often the APIs generated by swig are not very natural in go, especially if
@ -1358,7 +1385,7 @@ func bar() {
</pre>
</div>
<H3><a name="Go_typemaps">25.4.11 Go typemaps</a></H3>
<H3><a name="Go_typemaps">25.4.13 Go typemaps</a></H3>
<p>
@ -1397,7 +1424,7 @@ default as <a href="#Go_primitive_type_mappings">described above</a>.
<td>
An intermediate Go type used by the "goin", "goout", "godirectorin",
and "godirectorout" typemaps. If this typemap is not defined for a
C/C++ type, the gotype typemape will be used. This is useful when
C/C++ type, the gotype typemap will be used. This is useful when
gotype is best converted to C/C++ using Go code.
</td>
</tr>

17
Doc/Manual/Guile.html
View File

@ -52,15 +52,16 @@ This section details guile-specific support in SWIG.
<p>
SWIG works with Guile versions 1.8.x and 2.0.x. Support for version
1.6.x has been dropped. The last version of SWIG that still works with
Guile version 1.6.x is SWIG 2.0.9.
SWIG is known to work with Guile versions 2.0.x, 2.2.x and 3.0.x (these are
all tested via CI). SWIG probably still works with Guile 1.8.x but we're no
longer able to regularly test this either in CI or by hand. Support for Guile
1.6.x has been dropped (SWIG 2.0.9 was the last version of SWIG to support it).
<p>
Note that starting with guile 2.0, the guile sources can be compiled for
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.
<tt>GUILE_AUTO_COMPILE</tt> to 0 when using swig generated guile code.
<H2><a name="Guile_nn2">26.2 Meaning of "Module"</a></H2>
@ -303,10 +304,12 @@ experimental; the (hobbit4d link) conventions are not well understood.
Underscores are converted to dashes in identifiers. Guile support may
grow an option to inhibit this folding in the future, but no one has
complained so far.
</p>
<p>You can use the SWIG directives <code>%name</code> and
<code>%rename</code> to specify the Guile name of the wrapped
functions and variables (see CHANGES).
<p>You can use the <a href="SWIG.html#SWIG_rename_ignore">SWIG
directive <code>%rename</code></a> to specify the Guile
names of the wrapped functions and variables.
</p>
<H2><a name="Guile_nn11">26.6 Typemaps</a></H2>

44
Doc/Manual/Java.html
View File

@ -644,7 +644,7 @@ java::
<p>
To build the DLL and compile the java code, run NMAKE (you may need to run <tt>vcvars32</tt> first).
This is a pretty simplistic Makefile, but hopefully its enough to get you started.
This is a pretty simplistic Makefile, but hopefully it's enough to get you started.
Of course you may want to make changes for it to work for C++ by adding in the -c++ command line option for swig and replacing .c with .cxx.
</p>
@ -3434,9 +3434,11 @@ Consider the following C++ code:
namespace Space {
struct Base1 {
virtual void Method1();
virtual Base1();
};
struct Base2 {
virtual void Method2();
virtual Base2();
};
struct Derived : Base1, Base2 {
};
@ -3453,7 +3455,7 @@ SWIG generates a warning for the above code:
<div class="shell">
<pre>
example.i:10: Warning 813: Warning for Derived, base Base2 ignored.
example.i:12: Warning 813: Warning for Derived, base Base2 ignored.
Multiple inheritance is not supported in Java.
</pre>
</div>
@ -3506,7 +3508,7 @@ public class Base1SwigImpl implements Base1 {
</div>
<p>
In fact any class deriving from <tt>Base</tt> will now implement the interface instead of
In fact any class using <tt>Base</tt> as an immediate base class will now implement the interface instead of
deriving from it (or ignoring the base in the case of multiple base classes).
Hence the <tt>Derived</tt> proxy class will now implement both bases:
</p>
@ -3535,6 +3537,21 @@ public class Derived implements Base1, Base2 {
</pre>
</div>
<p>
The proxy class has methods added to it, from the implemented bases, so that
the underlying C++ implementation can be called.
In the example above, <tt>Method1</tt> and <tt>Method2</tt> have been added from the implemented bases.
If a method is ignored in the base, such as via <tt>%ignore</tt>, then that method
will be excluded from the interface and there will not be an additional method
added to the proxy class implementing that interface.
</p>
<p>
The Java interface only ever contains virtual and non-virtual instance methods from the wrapped C++ class.
Any static methods, enums or variables in the wrapped C++ class are not supported and are not added to the interface.
They are of course still available in the Java proxy class.
</p>
<p>
Wherever a class marked as an interface is used, such as the <tt>UseBases</tt> method in the example,
the interface name is used as the type in the Java layer:
@ -4201,7 +4218,7 @@ You can copy the code below into an interface file and run SWIG on it and examin
%}
// Expose C++ exception as a Java Exception by changing the Java base class and providing a getMessage()
%typemap(javabase) MyNS::MyException "java.lang.RuntimeException";
%typemap(javabase) MyNS::MyException "java.lang.RuntimeException"
%rename(getMessage) MyNS::MyException::whatsup;
%inline %{
@ -6439,6 +6456,12 @@ This special variable expands to the intermediary class name. Usually this is th
unless the jniclassname attribute is specified in the <a href="Java.html#Java_module_directive">%module directive</a>.
</p>
<p>
<b><tt>$imfuncname</tt></b><br>
This special variable expands to the name of the function in the intermediary class that will be used in $jnicall.
Like, $jnicall, this special variable is only expanded in the "javaout" typemap.
</p>
<p>
<b><tt>$javainterfacename</tt></b><br>
This special variable is only expanded when the <tt>interface</tt> feature is applied to a class.
@ -7042,7 +7065,7 @@ The corrected interface file looks like:
<pre>
// class Foo is handled in a different interface file:
%import "Foo.i"
%typemap("javapackage") Foo, Foo *, Foo &amp; "com.wombat.foo";
%typemap("javapackage") Foo, Foo *, Foo &amp; "com.wombat.foo"
%feature("director") Example;
%inline {
@ -7070,11 +7093,11 @@ Note the helper macros below, <code>OTHER_PACKAGE_SPEC</code> and <code>ANOTHER_
"package.for.most.classes";
%define OTHER_PACKAGE_SPEC(TYPE...)
%typemap("javapackage") TYPE, TYPE *, TYPE &amp; "package.for.other.classes";
%typemap("javapackage") TYPE, TYPE *, TYPE &amp; "package.for.other.classes"
%enddef
%define ANOTHER_PACKAGE_SPEC(TYPE...)
%typemap("javapackage") TYPE, TYPE *, TYPE &amp; "package.for.another.set";
%typemap("javapackage") TYPE, TYPE *, TYPE &amp; "package.for.another.set"
%enddef
OTHER_PACKAGE_SPEC(Package_2_class_one)
@ -7268,7 +7291,7 @@ The typemaps to use then are as follows:
<div class="code">
<pre>
%typemap(javabase) FileException "java.lang.Exception";
%typemap(javabase) FileException "java.lang.Exception"
%typemap(javacode) FileException %{
public String getMessage() {
return what();
@ -9062,6 +9085,11 @@ You may have to add in some "jtype", "jstype", "javain" and "javaout" typemaps w
Here the default typemaps work for <tt>int</tt> and <tt>char *</tt>.
</p>
<p>
Note that if you're wanting to effectively <b>replace</b> the JNI code generated for a C/C++ function then you'll need to use <tt>%ignore</tt> as well
to tell SWIG not to automatically generate a JNI wrapper for it.
</p>
<p>
In summary the <tt>%native</tt> directive is telling SWIG to generate the Java code to access the JNI C code, but not the JNI C function itself.
This directive is only really useful if you want to mix your own hand crafted JNI code and the SWIG generated code into one Java class or package.

20
Doc/Manual/Javascript.html
View File

@ -89,24 +89,10 @@ $ swig -javascript -jsc example.i</pre>
<pre>
$ swig -c++ -javascript -jsc example.i</pre>
</div>
<p>The V8 code that SWIG generates should work with most versions from 3.11.10.
However, the only early version that receives some testing is 3.14.5, which is
still shipped with Ubuntu for some reason. Other than that it's probably safer
to assume that versions earlier than 5.0 are no longer supported. Keep in mind
that these are V8 versions, not Node.js. To give some perspective, Node.js v6.0
<p>The V8 code that SWIG generates requires at least V8 5.0. Keep in mind
that this is theV8 version, not Node.js. To give some perspective, Node.js v6.0
uses V8 5.0, v12.0 - 7.4, v14.0 - 8.1...</p>
<p>The API headers for V8 &gt;= 4.3.10 define constants which SWIG can use to
determine the V8 version it is compiling for. For versions &lt; 4.3.10, you
need to specify the V8 version when running SWIG. This is specified as a hex
constant, but the constant is read as pairs of decimal digits, so for V8
3.25.30 use constant 0x032530. This scheme can't represent components &gt; 99,
but this constant is only useful for V8 &lt; 4.3.10, and no V8 versions from
that era had a component &gt; 99. For example:</p>
<div class="shell">
<pre>
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
</div>
<p>If you're targeting V8 &gt;= 4.3.10, you would just run swig like so:</p>
<p>To generate code for V8, you would run swig like so:</p>
<div class="shell">
<pre>
$ swig -c++ -javascript -v8 example.i</pre>

461
Doc/Manual/Library.html
View File

@ -14,6 +14,7 @@
<li><a href="#Library_nn2">The %include directive and library search path</a>
<li><a href="#Library_nn3">C arrays and pointers</a>
<ul>
<li><a href="#Library_argcargv">argcargv.i</a>
<li><a href="#Library_nn4">cpointer.i</a>
<li><a href="#Library_carrays">carrays.i</a>
<li><a href="#Library_nn6">cmalloc.i</a>
@ -39,11 +40,16 @@
<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_unique_ptr">unique_ptr smart pointer</a>
<li><a href="#Library_std_auto_ptr">auto_ptr smart pointer</a>
</ul>
<li><a href="#Library_nn16">Utility Libraries</a>
<ul>
<li><a href="#Library_nn17">exception.i</a>
<li><a href="#Library_attributes">attribute.i</a>
<ul>
<li><a href="#Library_attribute_templates">%attribute and C++ templates</a>
</ul>
</ul>
</ul>
</div>
@ -111,7 +117,48 @@ 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">12.2.1 cpointer.i</a></H3>
<H3><a name="Library_argcargv">12.2.1 argcargv.i</a></H3>
<p>
The argcargv.i library is a simple library providing multi-argument typemaps for handling C
argc argv command line argument C string arrays.
The <tt>argc</tt> parameter contains the argument count and <tt>argv</tt> contains the argument vector array.
</p>
<p>
This library provides the following multi-argument typemap:
</p>
<p>
<b><tt>(int ARGC, char **ARGV)</tt></b>
</p>
<p>
Apply this multi-argument typemap to your use case, for example:
</p>
<div class="code">
<pre>
%apply (int ARGC, char **ARGV) { (size_t argc, const char **argv) }
int mainApp(size_t argc, const char **argv);
</pre>
</div>
<p>
then from Ruby:
</p>
<div class="targetlang">
<pre>
$args = ["myarg1", "myarg2"]
mainApp(args);
</pre>
</div>
<H3><a name="Library_nn4">12.2.2 cpointer.i</a></H3>
<p>
@ -327,7 +374,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">12.2.2 carrays.i</a></H3>
<H3><a name="Library_carrays">12.2.3 carrays.i</a></H3>
<p>
@ -506,7 +553,7 @@ 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">12.2.3 cmalloc.i</a></H3>
<H3><a name="Library_nn6">12.2.4 cmalloc.i</a></H3>
<p>
@ -667,7 +714,7 @@ Now, in a script:
</pre>
</div>
<H3><a name="Library_nn7">12.2.4 cdata.i</a></H3>
<H3><a name="Library_nn7">12.2.5 cdata.i</a></H3>
<p>
@ -1994,38 +2041,41 @@ The SWIG code below shows the required ordering:
The languages that support shared_ptr also have support for using shared_ptr with directors.
</p>
<H3><a name="Library_std_auto_ptr">12.4.5 auto_ptr smart pointer</a></H3>
<H3><a name="Library_std_unique_ptr">12.4.5 unique_ptr smart pointer</a></H3>
<p>
While <tt>std::auto_ptr</tt> is deprecated in C++11, some existing code may
still be using it, so SWIG provides limited support for this class:
<tt>std_auto_ptr.i</tt> defines the typemaps which apply to the functions
returning objects of this type. Any other use of <tt>std_auto_ptr.i</tt> is not
directly supported.
The <tt>std_unique_ptr.i</tt> library file provides SWIG's unique_ptr support.
It defines typemaps and a macro, <tt>%unique_ptr(T)</tt>, to use for handling
<tt>std::unique_ptr&lt;T&gt;</tt> for a type <tt>T</tt>.
The type <tt>T</tt> must be non-primitive.
This macro should be used before any code declaring or using type <tt>T</tt>.
Ordering requirements for using this smart pointer macro are the same as the
equivalent <tt>%shared_ptr(T)</tt> macro covered in the previous section.
</p>
<p>
A typical example of use would be
Example usage of a <tt>std::unique_ptr</tt> being returned from a function is shown below.
</p>
<div class="code">
<pre>
%include &lt;std_auto_ptr.i&gt;
%include &lt;std_unique_ptr.i&gt;
%auto_ptr(Klass)
%unique_ptr(Klass)
%inline %{
#include &lt;memory&gt;
class Klass {
public:
// Factory function creating objects of this class:
static std::auto_ptr&lt;Klass&gt; Create(int value) {
return std::auto_ptr&lt;Klass&gt;(new Klass(value));
static std::unique_ptr&lt;Klass&gt; Create(int value) {
return std::unique_ptr&lt;Klass&gt;(new Klass(value));
}
int getValue() const { return m_value; }
private:
DerivedIntValue(int value) : m_value(value) {}
Klass(int value) : m_value(value) {}
int m_value;
};
%}
@ -2044,6 +2094,144 @@ int value = k.getValue();
</pre>
</div>
<p>
The implementation simply calls <tt>std::unique_ptr::release()</tt> to obtain
the underlying raw pointer. The pointer is then used to create a target language
proxy class in the same way that SWIG handles a C++ function returning a class by value.
The target language proxy class then owns the memory pointed to by the raw pointer
and memory handling is identical to normal SWIG proxy class handling of the underlying C++ memory.
Note that an object returned by value is first copied/moved from the stack onto the heap in order to obtain
a raw pointer on the heap, whereas the underlying raw pointer in <tt>std::unique_ptr</tt> already points to an object the heap.
</p>
<p>
Note that the implementation is quite different to the <tt>std::shared_ptr</tt> smart pointer,
where the proxy class manages the underlying C++ memory as a pointer to a shared_ptr instead of a plain raw pointer.
</p>
<p>
A possibly less common usage of this smart pointer is as a parameter to a function.
When used like this it indicates that memory usage of the object pointed to by the underlying pointer
is transferred to the function being called.
The code that SWIG generates assumes this happens.
First, it is assumed that a proxy class already owns the underlying C++ object and is used to pass the object to the C++ function being called.
Second, the ownership is transferred from the proxy class to the C++ function being called and
lifetime is then controlled by the function.
Finally, it is assumed the lifetime of the object may not last beyond returning from the C++ function
and hence the proxy class can no longer be used.
</p>
<p>
Consider expanding the example above with a function that takes a <tt>std::unique_ptr</tt> as follows:
</p>
<div class="code">
<pre>
void take(std::unique_ptr&lt;Klass&gt;);
</pre>
</div>
<p>
and use from C#:
</p>
<div class="targetlang">
<pre>
Klass k = Klass.Create(17); // create an instance of Klass any way you like
int value = k.getValue(); // ok
example.take(k); // memory ownership passes from C# layer to C++ layer
int v = k.getValue(); // don't do this - invalid use of k
</pre>
</div>
<p>
Attempts to use <tt>k</tt> after the ownership has been passed into the <tt>take</tt> function
should not be attempted.
The implementation sets the proxy class to an invalid state by setting the class's underlying
C++ pointer to null after the return from the <tt>take</tt> function.
Subsequent use of an invalid proxy class instance is very much dependent on the implementation
in the target language and ranges from a segfault to giving a nice error.
Consider implementing additional checks via the 'check' typemap.
</p>
<p>
Attempts to pass ownership from a proxy class to a <tt>std::unique</tt> parameter more than once will result
in a "Cannot release ownership as memory is not owned" exception. For example, if <tt>example.take(k)</tt> in the example above is called twice.
</p>
<p>
<b>Compatibility note:</b> Support for <tt>std::unique_ptr</tt> was added in SWIG-4.1.0.
</p>
<H3><a name="Library_std_auto_ptr">12.4.6 auto_ptr smart pointer</a></H3>
<p>
While <tt>std::auto_ptr</tt> is deprecated in C++11, some existing code may
still be using it. SWIG provides support for this class which is nearly identical
to <tt>std::unique_ptr</tt>.
</p>
<p>
The <tt>std_auto_ptr.i</tt> library file provides SWIG's auto_ptr support.
It defines typemaps and a macro, <tt>%auto_ptr(T)</tt>, to use for handling
<tt>std::auto_ptr&lt;T&gt;</tt> for a type <tt>T</tt>.
The type <tt>T</tt> must be non-primitive.
This macro should be used before any code declaring or using type <tt>T</tt>.
Ordering requirements for using this smart pointer macro are the same as the
equivalent <tt>%shared_ptr(T)</tt> and <tt>%unique_ptr</tt> macros covered in
the previous two sections.
</p>
<p>
Example usage of a <tt>std::auto_ptr</tt> being returned from a function is shown below.
</p>
<div class="code">
<pre>
%include &lt;std_auto_ptr.i&gt;
%auto_ptr(Klass)
%inline %{
#include &lt;memory&gt;
class Klass {
public:
// Factory function creating objects of this class:
static std::auto_ptr&lt;Klass&gt; Create(int value) {
return std::auto_ptr&lt;Klass&gt;(new Klass(value));
}
int getValue() const { return m_value; }
private:
Klass(int value) : m_value(value) {}
int m_value;
};
%}
</pre>
</div>
<p>
The returned objects can be used naturally from the target language, e.g. from
C#:
</p>
<div class="targetlang">
<pre>
Klass k = Klass.Create(17);
int value = k.getValue();
</pre>
</div>
<p>
The implementation simply calls <tt>std::auto_ptr::release()</tt> to obtain the underlying raw pointer.
That is, it works the same way covered in the previous section for <tt>std::unique_ptr</tt>.
</p>
<p>
Input parameters also work the same way as <tt>std::unique_ptr</tt> covered in the previous section.
</p>
<H2><a name="Library_nn16">12.5 Utility Libraries</a></H2>
@ -2108,5 +2296,244 @@ For example:
</div>
<H3><a name="Library_attributes">12.5.2 attribute.i</a></H3>
<p>
The attribute library contains a set of macros to convert a pair of set/get methods
into a "native" attribute/property.
</p>
<p>
Use <tt>%attribute</tt> when you have a pair of get/set methods to a
primitive type like:
</p>
<div class="code">
<pre>
%include "attribute.i"
%attribute(A, int, a, get_a, set_a);
struct A {
int get_a() const;
void set_a(int aa);
};
</pre>
</div>
<p>
and you want to provide that variable as an attribute in the target
language. This example only works for primitive types, not derived
types.
Now you can use the attributes like so (in Python):
</p>
<div class="targetlang">
<pre>
x = A()
x.a = 3 # calls A::set_a(3)
print(x.a) # calls A::get_a() const
</pre>
</div>
<p>
If you don't provide a 'set' method, a 'read-only' attribute
is generated, ie, like:
</p>
<div class="code">
<pre>
%attribute(A, int, c, get_c);
</pre>
</div>
<p>
Use <tt>%attributeref</tt> when you have const/non-const reference
access methods for primitive types or class/structs, like:
</p>
<div class="code">
<pre>
%attributeref(A, int, b);
struct A {
const int &amp; b() const;
int &amp; b();
};
%attributeref(B, int, c);
struct B {
int &amp; c();
};
</pre>
</div>
<p>
Use the attributes like so (in Python):
</p>
<div class="targetlang">
<pre>
x = A()
x.b = 3 # calls A::b()
print(x.b) # calls A::b() const
</pre>
</div>
<p>
You can also use
</p>
<div class="code">
<pre>
%attributeref(Class, AttributeType, AttributeName, AccessorMethod)
</pre>
</div>
<p>
if the internal C++ reference methods have a different name from the
attribute you want, so
</p>
<div class="code">
<pre>
%attributeref(B, int, d, c);
</pre>
</div>
<p>
is the same as the last example, but instead of the attribute 'c' being
called 'c', it is called 'd'.
</p>
<p>
Use <tt>%attribute2</tt> instead of <tt>%attribute</tt> to indicate
that reference-pointer translation is required.
Use <tt>%attribute2</tt> instead of <tt>%attribute</tt> in cases like
this:
</p>
<div class="code">
<pre>
%attribute2(MyClass, MyFoo, Foo, GetFoo, SetFoo);
%inline %{
struct MyFoo {
int x;
};
class MyClass {
MyFoo foo;
public:
MyFoo &amp; GetFoo() { return foo; }
void SetFoo(const MyFoo &amp;other) { foo = other; }
};
%}
</pre>
</div>
<p>
Here, the data type of the property is a wrapped type <tt>MyFoo</tt> and on
the C++ side it is passed by reference. The problem is that the SWIG
wrapper will pass around a pointer (MyFoo *) which is not compatible
with the reference type of the accessors (MyFoo &amp;). Therefore, if you
use <tt>%attribute</tt>, you'll get an error from your C/C++
compiler. <tt>%attribute2</tt> translates between a pointer and a
reference to eliminate the error. In case you're confused, let's make
it simple: just use <tt>%attribute</tt> at first, but if the C/C++
compiler gives an error while compiling the wrapper,
try <tt>%attribute2</tt> instead.
</p>
<p>
NOTE: remember that if the type contains commas, such as
<tt>std::pair&lt;int, int&gt;</tt>, you need to use the macro like:
</p>
<div class="code">
<pre>
%attributeref(A, %arg(std::pair&lt;int, int&gt;), pval);
</pre>
</div>
<p>
where <tt>%arg()</tt> 'normalizes' the type to be understood as a single
argument, otherwise the macro will get confused by the comma.
</p>
<p>
The <tt>%attributeval</tt> is the same as <tt>%attribute</tt>, but
should be used when the type is a class/struct (ie a non-primitive
type) and when the get and set methods return/pass by value. The
following is very similar to the above example, but note that the
access is by value rather than reference.
</p>
<div class="code">
<pre>
%attributeval(MyClassVal, MyFoo, ReadWriteFoo, GetFoo, SetFoo);
%attributeval(MyClassVal, MyFoo, ReadOnlyFoo, GetFoo);
%inline %{
class MyClassVal {
MyFoo foo;
public:
MyFoo GetFoo() { return foo; }
void SetFoo(MyFoo other) { foo = other; }
};
%}
</pre>
</div>
<p>
The <tt>%attributestring</tt> is the same as <tt>%attributeval</tt>,
but should be used for string class types, which are unusual as they
are a class on the C++ side, but normally an immutable/primitive type
in the target language. Example usage for <tt>std::string</tt>:
</p>
<div class="code">
<pre>
%include &lt;std_string.i&gt;
%attributestring(MyStringyClass, std::string, ReadWriteString, GetString, SetString);
%attributestring(MyStringyClass, std::string, ReadOnlyString, GetString);
%inline %{
class MyStringyClass {
std::string str;
public:
MyStringyClass(const std::string &amp;val) : str(val) {}
std::string GetString() { return str; }
void SetString(std::string other) { str = other; }
};
%}
</pre>
</div>
<p>
The <tt>%attributestring</tt> also works for class types that
have <tt>%naturalvar</tt> turned on and so is also useful for
shared_ptr which has <tt>%naturalvar</tt> turned on in
<tt>%shared_ptr</tt>.
</p>
<H4><a name="Library_attribute_templates">12.5.2.1 %attribute and C++ templates</a></H4>
<p>
<tt>%attribute</tt> and friends have to be used on fully specified classes. For example
</p>
<div class="code">
<pre>
%attributeref(A&lt;int&gt;, int, a);
%inline %{
template &lt;class T&gt; struct A {
T a() const;
void a(T &amp;);
};
%}
</pre>
</div>
<p>
Note the use of a template-id (i.e., <tt>A&lt;int&gt;</tt> not <tt>A&lt;T&gt;</tt> or just <tt>A</tt>).
This means that <tt>%attribute</tt> statements have to be repeated for any template-id that you want to use with <tt>%template</tt>.
</p>
</body>
</html>

2
Doc/Manual/Lisp.html
View File

@ -264,7 +264,7 @@ Let's edit the interface file such that the C type "div_t*" is changed
<div class="code"><pre>
%module test
%typemap(cin) div_t* ":my-pointer";
%typemap(cin) div_t* ":my-pointer"
%feature("intern_function", "1");
%feature("export");

8
Doc/Manual/Lua.html
View File

@ -1520,7 +1520,7 @@ function
nil
&gt;
</pre></div>
<p> This behaviour was changed. Now unless -squash-bases option is provided, Derived store a list of it's bases and if some symbol is not found in it's own service tables
<p> This behaviour was changed. Now unless -squash-bases option is provided, Derived stores a list of its bases and if some symbol is not found in its own service tables
then its bases are searched for it. Option -squash-bases will effectively return old behaviour.
</p>
@ -1638,7 +1638,7 @@ More details can be found in the <a href="Library.html#Library_carrays">carrays.
<div class="code"><pre>// using the C-array
%include &lt;carrays.i&gt;
// this declares a batch of function for manipulating C integer arrays
// this declares a batch of functions for manipulating C integer arrays
%array_functions(int, int)
extern void sort_int(int* arr, int len); // the function to wrap
@ -1997,10 +1997,10 @@ So when 'p:Print()' is called, the __index looks on the object metatable for a '
In theory, you can play with this usertable &amp; add new features, but remember that it is a shared table between all instances of one class, and you could very easily corrupt the functions in all the instances.
</p>
<p>
Note: Both the opaque structures (like the FILE*) and normal wrapped classes/structs use the same 'swig_lua_userdata' structure. Though the opaque structures has do not have a metatable attached, or any information on how to dispose of them when the interpreter has finished with them.
Note: Both the opaque structures (like the FILE*) and normal wrapped classes/structs use the same 'swig_lua_userdata' structure. Though the opaque structures do not have a metatable attached, or any information on how to dispose of them when the interpreter has finished with them.
</p>
<p>
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' &amp; '__call' to the class' metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming its an operator overload.
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' &amp; '__call' to the class' metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming it's an operator overload.
</p>
<H3><a name="Lua_nn38">29.7.3 Memory management</a></H3>

8
Doc/Manual/Modules.html
View File

@ -119,6 +119,10 @@ public:
// File: derived_module.i
%module derived_module
%{
#include "base.h"
%}
%import "base_module.i"
%inline %{
@ -156,6 +160,10 @@ The <tt>derived_module.i</tt> file shown above could be replaced with the follow
// File: derived_module.i
%module derived_module
%{
#include "base.h"
%}
%import(module="base_module") "base.h"
%inline %{

20
Doc/Manual/Ocaml.html
View File

@ -720,7 +720,6 @@ Here's a simple example using Trolltech's Qt Library:
class QApplication {
public:
QApplication( int argc, char **argv );
void setMainWidget( QWidget *widget );
void exec();
};
@ -736,16 +735,15 @@ public:
<div class="code"><pre>
bash-2.05a$ QTPATH=/your/qt/path
bash-2.05a$ for file in swig.mli swig.ml swigp4.ml ; do swig -ocaml -co $file ; done
bash-2.05a$ ocamlc -c swig.mli ; ocamlc -c swig.ml
bash-2.05a$ ocamlc -I `camlp4 -where` -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
bash-2.05a$ swig -ocaml -c++ -I$QTPATH/include qt.i
bash-2.05a$ mv qt_wrap.cxx qt_wrap.c
bash-2.05a$ ocamlc -c -ccopt -xc++ -ccopt -g -g -ccopt -I$QTPATH/include qt_wrap.c
bash-2.05a$ ocamlc -c qt.mli
bash-2.05a$ ocamlc -c qt.ml
bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
$ QTPATH=/your/qt/path
$ for file in swig.mli swig.ml swigp4.ml ; do swig -ocaml -co $file ; done
$ ocamlc -c swig.mli ; ocamlc -c swig.ml
$ ocamlc -I `camlp4 -where` -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
$ swig -ocaml -c++ -o qt_wrap.c qt.i
$ ocamlc -c -ccopt -xc++ -ccopt -g -g -ccopt -I$QTPATH/include qt_wrap.c
$ ocamlc -c qt.mli
$ ocamlc -c qt.ml
$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
camlp4o.cma swigp4.cmo qt_wrap.o qt.cmo -o qt_top -cclib \
-L$QTPATH/lib -cclib -lqt
</pre></div>

30
Doc/Manual/Octave.html
View File

@ -363,6 +363,10 @@ octave:2&gt; f=swigexample.fopen("not there", "r");
error: value on right hand side of assignment is undefined
error: evaluating assignment expression near line 2, column 2 </pre></div>
<p>
NULL C/C++ pointers are represented by the Octave null matrix, <tt>[]</tt>.
</p>
<H3><a name="Octave_nn13">30.3.6 Structures and C++ classes</a></H3>
@ -570,13 +574,13 @@ __mul__ a * b
__div__ a / b
__pow__ a ^ b
__ldiv__ a \ b
__lshift__ a << b
__rshift__ a >> b
__lt__ a < b
__le__ a <= b
__lshift__ a &lt;&lt; b
__rshift__ a &gt;&gt; b
__lt__ a &lt; b
__le__ a &lt;= b
__eq__ a == b
__ge__ a >= b
__gt__ a > b
__ge__ a &gt;= b
__gt__ a &gt; b
__ne__ a != b
__el_mul__ a .* b
__el_div__ a ./ b
@ -598,16 +602,16 @@ On the C++ side, the default mappings are as follows:
%rename(__mul__) *::operator*;
%rename(__div__) *::operator/;
%rename(__mod__) *::operator%;
%rename(__lshift__) *::operator<<;
%rename(__rshift__) *::operator>>;
%rename(__lshift__) *::operator&lt;&lt;;
%rename(__rshift__) *::operator&gt;&gt;;
%rename(__el_and__) *::operator&amp;&amp;;
%rename(__el_or__) *::operator||;
%rename(__xor__) *::operator^;
%rename(__invert__) *::operator~;
%rename(__lt__) *::operator<;
%rename(__le__) *::operator<=;
%rename(__gt__) *::operator>;
%rename(__ge__) *::operator>=;
%rename(__lt__) *::operator&lt;;
%rename(__le__) *::operator&lt;=;
%rename(__gt__) *::operator&gt;;
%rename(__ge__) *::operator&gt;=;
%rename(__eq__) *::operator==;
%rename(__ne__) *::operator!=;
%rename(__not__) *::operator!;
@ -634,7 +638,7 @@ You can use it to define special behavior, like for example defining Octave oper
%extend A {
string __str__() {
stringstream sout;
sout&lt;&lt;$self->value;
sout&lt;&lt;$self-&gt;value;
return sout.str();
}
}

32
Doc/Manual/Perl5.html
View File

@ -91,10 +91,10 @@
<p>
This chapter describes SWIG's support of Perl5. Although the Perl5
module is one of the earliest SWIG modules, it has continued to evolve
and has been improved greatly with the help of SWIG users. For the
best results, it is recommended that SWIG be used with Perl 5.8 or
later. We're no longer testing regularly with older versions, but
Perl 5.6 seems to mostly work, while older versions don't.
and has been improved greatly with the help of SWIG users. As of SWIG
4.1.0, the minimum version of Perl we aim to support is Perl 5.8.0.
We can no longer easily test with older versions, and they no longer
seem to be in active use.
</p>
<H2><a name="Perl5_nn2">31.1 Overview</a></H2>
@ -680,7 +680,6 @@ files(s) field".
installation under "Additional include directories".
<li>Define the symbols WIN32 and MSWIN32 under preprocessor options.
If using the ActiveWare port, also define the symbol PERL_OBJECT.
Note that all extensions to the ActiveWare port must be compiled with
the C++ compiler since Perl has been encapsulated in a C++ class.
@ -1065,7 +1064,7 @@ int *Foo_x_get(Foo *self) {
<p>
If you want to set an array member, you will need to supply a "memberin" typemap
described later in this chapter. As a special case, SWIG does generate
code to set array members of type <tt>char</tt> (allowing you to store a Python
code to set array members of type <tt>char</tt> (allowing you to store a Perl
string in the structure).
</p>
@ -1494,7 +1493,7 @@ as well as a special error code:
<div class="code">
<pre>
/* send message, return number of bytes sent, along with success code */
int send_message(char *text, int len, int *success);
int send_message(char *text, int *success);
</pre>
</div>
@ -1736,7 +1735,7 @@ See the chapter on "<a href="Customization.html#Customization">Customization fea
<div class="code">
<pre>
%except(python) {
%except(perl5) {
try {
$function
}
@ -2320,7 +2319,7 @@ typedef struct {
<p>
By default, SWIG doesn't know how to the handle the values structure
member it's an array, not a pointer. In this case, SWIG makes the array member
member because it's an array, not a pointer. In this case, SWIG makes the array member
read-only. Reading will simply return a pointer to the first item in the array.
To make the member writable, a "memberin" typemap can be used.
</p>
@ -2651,8 +2650,8 @@ constructors and destructors for the package and are always named
"new" and "DESTROY". The constructor always returns a tied hash
table. This hash table is used to access the member variables of a
structure in addition to being able to invoke member functions. The
<tt>%OWNER</tt> and <tt>%BLESSEDMEMBERS</tt> hash tables are used
internally and described shortly.
<tt>%OWNER</tt> and <tt>%BLESSEDMEMBERS</tt> hash tables are
implementation details used internally and described shortly.
</p>
<p>
@ -2740,8 +2739,15 @@ to a C function that remembers the object, and then destroy the
corresponding Perl object (this situation turns out to come up
frequently when constructing objects like linked lists and trees).
When C takes possession of an object, you can change Perl's ownership
by simply deleting the object from the <tt>%OWNER</tt> hash. This is
done using the <tt>DISOWN</tt> method.
by calling the <tt>DISOWN</tt> method (which will delete the object
from the internal <tt>%OWNER</tt> hash).
</p>
<p>
The <tt>%OWNER</tt> hash is an implementation detail, discussed here
only to help clarify the operation of <tt>ACQUIRE</tt> and <tt>DISOWN</tt>.
You should not access <tt>%OWNER</tt> directly - the details of how it
works (and possibly even its existence) may change in future SWIG versions.
</p>
<div class="targetlang"><pre>

107
Doc/Manual/Php.html
View File

@ -50,18 +50,19 @@
<p>
In this chapter, we discuss SWIG's support of PHP. SWIG currently supports
generating wrappers for PHP7 and PHP8. Support for PHP5 was removed in SWIG
4.0.0 and support for PHP4 was removed in SWIG 1.3.37.
In this chapter, we discuss SWIG's support of PHP. Currently any PHP7 or PHP8
release should work.
</p>
<p>
Currently any PHP7 or PHP8 release should work.
Support for PHP7 was added in SWIG 3.0.11 and for PHP8 in 4.1.0.
Support for PHP5 was removed in SWIG 4.0.0 and support for PHP4 was removed in
SWIG 1.3.37. There never was a PHP6 release.
</p>
<p>
In order to use this module, you will need to have a copy of the PHP
include files to compile the SWIG generated files. If you installed
include files to compile the SWIG generated C/C++ sources. If you installed
PHP from a binary package, you may need to install a "php-dev" or "php-devel"
package for these to be installed. You can find out where these files are
by running <tt>php-config --includes</tt>. To use the built PHP module you
@ -306,11 +307,10 @@ functions.
</p>
<p>
SWIG honors the <tt>%immutable</tt> modifier by not generating code
for the <tt>_set</tt> method. This provides read-only access to the
variable from the php script. Attempting to access the <tt>_set</tt>
method will result in a php fatal error because the function is
undefined.
SWIG honors the <tt>%immutable</tt> modifier by not generating a
<tt>_set</tt> method (so attempting to call it will give a PHP fatal
error). A <tt>_get</tt> method is still generated so this provides read-only
access to the variable from the PHP script.
</p>
<p>
@ -343,6 +343,80 @@ $c = bar(3.5); # Use default argument for 2nd parameter
</pre></div>
<p>
SWIG generates PHP type declarations for function parameters and return
types for PHP 8 and later (we don't try to support PHP 7's more limited type
declarations and the generated wrappers compiled for PHP 7 will not have any
type declarations).
</p>
<p>
You can control the generation of PHP type declarations using
the "php:type" %feature. This has three settings:
</p>
<ul>
<li> <p>If unset or set to "0" then no type declarations are generated, e.g.: <tt>%feature("php:type", "0");</tt>
</p>
</li>
<li> <p>If set to "1" then type declarations are generated for both parameters and return types, e.g.: <tt>%feature("php:type", "1");</tt>
</p></li>
<li> <p>The default setting is "compat", which is the same as "1" except no
return type declarations are generated for virtual methods for which
directors are enabled. This provides better compatibility for PHP
subclasses of wrapped virtual methods in existing SWIG-generated bindings, e.g.: <tt>%feature("php:type", "compat");</tt>
</p></li>
</ul>
<p>
If you have an existing PHP interface and are upgrading to SWIG &gt;= 4.1.0
then the default "compat" setting should work well.
</p>
<p>
If you're writing a new set of bindings and <b>only targeting PHP8 or newer</b>
then enabling type declarations everywhere probably makes sense. It will
only actually make a difference if you enable directors and are wrapping C++
classes with virtual methods, but doing it anyway means you won't forget to if
the code you are wrapping later evolves to have such classes and methods.
</p>
<p>
The type declaration information will make the generated source code and
compiler extension module larger, so you might want to turn off type
declarations if keeping these small is important to you. If you find you
need to turn off type declarations to fix a problem, please let us know
via our github issue tracker.
</p>
<p>
Note that being a SWIG feature this can be specified globally (like above) or
per class, per method, etc. See the <a
href="Customization.html#Customization_features">%feature directives</a>
section for full details of how to control at a fine-grained level.
</p>
<p>
The PHP type information is specified via a "phptype" attribute on "in" and
"out" typemaps, and these have been added for all the typemaps we supply for
PHP. We don't currently support this for "argout" templates, but probably
will in a future version.
</p>
<p>
If you have written custom SWIG typemaps for PHP and want to add PHP type
declarations, then the syntax is very like how you'd specify the type in
PHP code, e.g. <tt>%typemap(in, phptype="int|string|Foo")</tt> means the
typemap accepts a PHP int or string or an object of class Foo,
<tt>%typemap(in, phptype="?int")</tt> means a PHP int or NULL, etc.
As well as the standard PHP type declaration types, SWIG also understands the
special type "SWIGTYPE" as an entry in phptype, which means the PHP type
corresponding to the type that this typemap matched on - for a object this
will give you the PHP class for the object, and for a pointer to a non-class
type it will give you the name of the PHP class SWIG created for that
pointer type.
</p>
<!-- This isn't correct for 1.3.30 and needs rewriting to reflect reality
<p>
Because PHP is a dynamically typed language, the default typemaps
@ -426,6 +500,7 @@ taking the integer argument.
<H3><a name="Php_nn2_5">32.2.5 Pointers and References</a></H3>
<p>
Since SWIG 4.1.0, SWIG wraps C/C++ classes directly with PHP objects.
Pointers to other types are also wrapped as PHP objects - mostly this is an
@ -624,8 +699,7 @@ Member variables and methods are accessed using the <tt>-&gt;</tt> operator.
<p>
The <tt>-noproxy</tt> option flattens the object structure and
generates collections of named functions (these are the functions
which the PHP class wrappers call). The above example results
generates collections of named functions. The above example results
in the following PHP functions:
</p>
@ -742,7 +816,10 @@ class Ko {
};
</pre></div>
would be executed in PHP as,
<p>
would be executed in PHP as
</p>
<div class="code"><pre>
Ko::threats();
</pre></div>
@ -759,7 +836,7 @@ so:
</p>
<div class="code"><pre>
%typemap("phpinterfaces") MyIterator "Iterator";
%typemap("phpinterfaces") MyIterator "Iterator"
</pre></div>
<p>
@ -1158,7 +1235,7 @@ should suffice in most cases:
</div>
<p>
If you only need to support SWIG >= 4.1.0, you can just use the
If you only need to support SWIG &gt;= 4.1.0, you can just use the
<tt>($error != NULL)</tt> condition.
</p>

10
Doc/Manual/Preface.html
View File

@ -281,12 +281,12 @@ You must use <a href="http://www.gnu.org/software/make/">GNU make</a> to build a
</p>
<p>
<a href="http://www.pcre.org/">PCRE</a>
<a href="http://www.pcre.org/">PCRE2</a>
needs to be installed on your system to build SWIG, in particular
pcre-config must be available. If you have PCRE headers and libraries but not
pcre-config itself or, alternatively, wish to override the compiler or linker
flags returned by pcre-config, you may set PCRE_LIBS and PCRE_CFLAGS variables
to be used instead. And if you don't have PCRE at all, the configure script
pcre2-config must be available. If you have PCRE2 headers and libraries but not
pcre2-config itself or, alternatively, wish to override the compiler or linker
flags returned by pcre2-config, you may set PCRE2_LIBS and PCRE2_CFLAGS variables
to be used instead. And if you don't have PCRE2 at all, the configure script
will provide instructions for obtaining it.
</p>

26
Doc/Manual/Preprocessor.html
View File

@ -99,8 +99,23 @@ header files without generating any wrappers.
<p>
SWIG fully supports the use of <tt>#if</tt>, <tt>#ifdef</tt>,
<tt>#ifndef</tt>, <tt>#else</tt>, <tt>#endif</tt> to conditionally
include parts of an interface. The following symbols are predefined
by SWIG when it is parsing the interface:
include parts of an interface.
</p>
<p>
SWIG's preprocessor conditionals support the standard C/C++ preprocessor
integer expressions. As a SWIG-specific extension, string equality and
inequality tests are also supported, for example:
</p>
<div class="code">
<pre>
#if defined __cplusplus &amp;&amp; (#__VA_ARGS__ != "" || #TYPE == "void")
</pre>
</div>
<p>
The following symbols are predefined by SWIG when it is parsing the interface:
</p>
<div class="code"><pre>
@ -154,7 +169,6 @@ 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>
@ -175,15 +189,15 @@ is also used to try and detect constants. Therefore, if you have something like
<div class="code">
<pre>
#ifndef _FOO_H 1
#define _FOO_H 1
#ifndef FOO_H 1
#define FOO_H 1
...
#endif
</pre>
</div>
<p>
you may get some extra constants such as <tt>_FOO_H</tt> showing up in the scripting interface.
you may get some extra constants such as <tt>FOO_H</tt> showing up in the scripting interface.
</p>
<p>

224
Doc/Manual/Python.html
View File

@ -114,6 +114,7 @@
<li><a href="#Python_nn70">%feature("autodoc", "docstring")</a>
</ul>
<li><a href="#Python_nn71">%feature("docstring")</a>
<li><a href="#Python_doxygen_docstrings">Doxygen comments</a>
</ul>
<li><a href="#Python_nn72">Python Packages</a>
<ul>
@ -133,7 +134,10 @@
</ul>
<li><a href="#Python_python3support">Python 3 Support</a>
<ul>
<li><a href="#Python_nn74">Function annotation</a>
<li><a href="#Python_annotations">Python function annotations and variable annotations</a>
<ul>
<li><a href="#Python_annotations_c">C/C++ annotation types</a>
</ul>
<li><a href="#Python_nn75">Buffer interface</a>
<li><a href="#Python_nn76">Abstract base classes</a>
<li><a href="#Python_nn77">Byte string output conversion</a>
@ -150,15 +154,10 @@
<p>
<b>Caution: This chapter is under repair!</b>
</p>
<p>
This chapter describes SWIG's support of Python. SWIG is compatible
with all recent Python versions (Python 2.7 and Python &gt;= 3.2). If you
still need to generate bindings which work with older versions of Python,
you'll have to use SWIG 3.0.x.
with all recent Python versions (Python 2.7 and Python &gt;= 3.3). SWIG 4.0.x
supported Python 3.2. SWIG 3.0.x supported older Python 2.x and 3.x.
</p>
<p>
@ -954,6 +953,7 @@ swig -python -help
<tr><td>-doxygen </td><td>Convert C++ doxygen comments to pydoc comments in proxy classes</td></tr>
<tr><td>-extranative </td><td>Return extra native wrappers for C++ std containers wherever possible</td></tr>
<tr><td>-fastproxy </td><td>Use fast proxy mechanism for member methods</td></tr>
<tr><td>-flatstaticmethod </td><td>Generate additional flattened Python methods for C++ static methods</td></tr>
<tr><td>-globals &lt;name&gt; </td><td>Set &lt;name&gt; used to access C global variable (default: 'cvar')</td></tr>
<tr><td>-interface &lt;mod&gt;</td><td>Set low-level C/C++ module name to &lt;mod&gt; (default: module name prefixed by '_')</td></tr>
<tr><td>-keyword </td><td>Use keyword arguments</td></tr>
@ -963,7 +963,6 @@ swig -python -help
<tr><td>-nortti </td><td>Disable the use of the native C++ RTTI with directors</td></tr>
<tr><td>-nothreads </td><td>Disable thread support for the entire interface</td></tr>
<tr><td>-olddefs </td><td>Keep the old method definitions when using -fastproxy</td></tr>
<tr><td>-py3 </td><td>Generate code with Python 3 specific features and syntax</td></tr>
<tr><td>-relativeimport </td><td>Use relative Python imports</td></tr>
<tr><td>-threads </td><td>Add thread support for all the interface</td></tr>
<tr><td>-O </td><td>Enable the following optimization options: -fastdispatch -fastproxy -fvirtual</td></tr>
@ -1613,16 +1612,17 @@ In Python, the static member can be accessed in three different ways:
<div class="targetlang">
<pre>
&gt;&gt;&gt; example.Spam_foo() # Spam::foo()
&gt;&gt;&gt; s = example.Spam()
&gt;&gt;&gt; s.foo() # Spam::foo() via an instance
&gt;&gt;&gt; example.Spam.foo() # Spam::foo() using Python-2.2 and later
&gt;&gt;&gt; example.Spam.foo() # Spam::foo() using class method
&gt;&gt;&gt; example.Spam_foo() # Spam::foo() "flattened" name
</pre>
</div>
<p>
The first two methods of access are supported in all versions of Python. The
last technique is only available in Python-2.2 and later versions.
The last technique is only available when using the <tt>-flatstaticmethod</tt> option.
This option is not recommended, it is only available for backwards compatibility
as ancient versions of Python did not have Python class methods.
</p>
<p>
@ -2531,6 +2531,12 @@ import A
assert(issubclass(B.Derived, A.Base))
</pre></div>
</li>
<li><p><a href="#Python_annotations">Python annotations</a> are not supported.
</p>
</li>
</ul>
<H4><a name="Python_builtin_overloads">33.4.2.2 Operator overloads and slots -- use them!</a></H4>
@ -3989,7 +3995,7 @@ Also included in the table for comparison is using the <tt>-builtin</tt> option
<p>
Although the <tt>-fastproxy</tt> option results in faster code over the default, the generated proxy code is not as user-friendly
as docstring/doxygen comments and functions with default values are not visible in the generated Python proxy class.
as docstring/doxygen comments, <a href="#Python_annotations">Python annotations</a> and functions with default values are not visible in the generated Python proxy class.
The <tt>-olddefs</tt> option can rectify this.
</p>
@ -4166,7 +4172,7 @@ as well as a special error code:
<div class="code">
<pre>
/* send message, return number of bytes sent, along with success code */
int send_message(char *text, int len, int *success);
int send_message(char *text, int *success);
</pre>
</div>
@ -4954,7 +4960,6 @@ object to be used as a <tt>char **</tt> object.
if (PyString_Check(o)) {
$1[i] = PyString_AsString(PyList_GetItem($input, i));
} else {
free($1);
PyErr_SetString(PyExc_TypeError, "list must contain strings");
SWIG_fail;
}
@ -5053,7 +5058,6 @@ previous example:
if (PyString_Check(o)) {
$2[i] = PyString_AsString(PyList_GetItem($input, i));
} else {
free($2);
PyErr_SetString(PyExc_TypeError, "list must contain strings");
SWIG_fail;
}
@ -5895,6 +5899,28 @@ with more than one line.
</pre>
</div>
<H3><a name="Python_doxygen_docstrings">33.10.4 Doxygen comments</a></H3>
<p>
Please see the separate <a href="Doxygen.html#Doxygen">Doxygen</a> chapter for information
on making use of C++ Doxygen comments and translating them into Python docstring comments.
</p>
<p>
Note that when generating docstrings and Doxygen comments have also been turned on,
the <a href="#Python_nn71">docstring feature</a> will take precedence over a Doxygen comment.
If the <a href="#Python_nn67">autodoc feature</a> is also turned on, then it will be
used in conjunction with the docstring feature.
However, if there is no docstring feature present and there is a Doxygen comment, then the autodoc docstring will not be generated. The Doxygen comment alone will be used.
</p>
<p>
This way, if the autodoc feature is specified globally it will fill in any missing
Doxygen documentation comments.
Doxygen comments can be overridden by using the docstring feature.
</p>
<H2><a name="Python_nn72">33.11 Python Packages</a></H2>
@ -6735,13 +6761,11 @@ to do this (remember you are now the Python importer) or use dynamic linking.
<p>
SWIG is able to support Python 3.x. The wrapper code generated by
SWIG can be compiled with both Python 2.x or 3.x. Further more, by
passing the <tt>-py3</tt> command line option to SWIG, wrapper code
with some Python 3 specific features can be generated (see below
subsections for details of these features).
SWIG can be compiled with both Python 2.x or 3.x.
</p>
<p>
There is a list of known-to-be-broken features in Python 3:
The list of known-to-be-broken features around Python 3 are:
</p>
<ul>
<li>No more support for FILE* typemaps, because PyFile_AsFile has been dropped
@ -6755,37 +6779,120 @@ The following are Python 3 new features that are currently supported by
SWIG.
</p>
<H3><a name="Python_nn74">33.12.1 Function annotation</a></H3>
<H3><a name="Python_annotations">33.12.1 Python function annotations and variable annotations</a></H3>
<p>
The <tt>-py3</tt> option will enable function annotation support. When used
SWIG is able to generate proxy method definitions like this:
</p>
<div class="code"><pre>
def foo(self, bar : "int"=0) -&gt; "void" : ...
</pre></div>
<p>
Also, even if without passing SWIG the <tt>-py3</tt> option, the parameter list
still could be generated:
</p>
<div class="code"><pre>
def foo(self, bar=0): ...
</pre></div>
<p>
But for overloaded function or method, the parameter list would fallback to
<tt>*args</tt> or <tt>self, *args</tt>, and <tt>**kwargs</tt> may be append
depend on whether you enabled the keyword argument. This fallback is due to
all overloaded functions share the same function in SWIG generated proxy class.
</p>
<p>
For detailed usage of function annotation, see
Python 3 supports function annotations as defined in
<a href="https://www.python.org/dev/peps/pep-3107/">PEP 3107</a>.
Python 3.6 and later additionally support variable annotations as defined in
<a href="https://www.python.org/dev/peps/pep-526/">PEP 526</a>.
Note that currently there is no annotations support in SWIG for the <tt>-builtin</tt> nor
the <tt>-fastproxy</tt> option.
Annotations are added via the <tt>python:annotations</tt>
<a href="Customization.html#Customization_features">%feature directives</a>.
SWIG currently supports one type of function annotation.
</p>
<H4><a name="Python_annotations_c">33.12.1.1 C/C++ annotation types</a></H4>
<p>
The <tt>%feature("python:annotations", "c")</tt> directive generates annotations
containing C/C++ types. For example:
</p>
<div class="code"><pre>
%feature("python:annotations", "c") global_ints;
int *global_ints(int &amp;ri);
</pre></div>
<p>
The generated code then contains function annotations containing the C++ types:
</p>
<div class="targetlang"><pre>
def global_ints(ri: "int &amp;") -&gt; "int *":
return _example.global_ints(ri)
</pre></div>
<p>
There are some limitations with function annotations support, for example, overloaded functions use
<tt>*args</tt> or <tt>**kwargs</tt> when keyword arguments are enabled.
The parameter names and types are then not shown. For example, with input:
</p>
<div class="code"><pre>
int *global_overloaded(int &amp;ri);
int *global_overloaded();
</pre></div>
<p>
The generated Python function including annotations is shown below.
Only the return type is annotated.
</p>
<div class="targetlang"><pre>
def global_overloaded(*args) -&gt; "int *":
return _example.global_overloaded(*args)
</pre></div>
<p>
Below is an example demonstrating variable annotations.
</p>
<div class="code"><pre>
%feature("python:annotations", "c");
struct V {
float val;
};
</pre></div>
<p>
The generated code contains a variable annotation containing the C <tt>float</tt> type:
</p>
<div class="targetlang"><pre>
class V(object):
val: "float" = property(_example.V_val_get, _example.V_val_set)
...
</pre></div>
<p>
Variable annotations are only supported from Python 3.6. If you need to support earlier versions of Python, you'll need to turn variable annotations off via the <tt>python:annotations:novar</tt> feature flag.
It is quite easy to support function annotations but turn off variable annotations. The next example shows how to do this for all variables.
</p>
<div class="code"><pre>
%feature("python:annotations", "c"); // Turn on function annotations and variable annotations globally
%feature("python:annotations:novar"); // Turn off variable annotations globally
struct V {
float val;
void vv(float *v) const;
};
</pre></div>
<p>
The resulting code will work with versions older than Python 3.6 as the variable annotations are turned off:
</p>
<div class="targetlang"><pre>
class V(object):
val = property(_example.V_val_get, _example.V_val_set)
def vv(self, v: "float *") -&gt; "void":
return _example.V_vv(self, v)
...
</pre></div>
<p>
<b>Compatibility Note:</b> SWIG-4.1.0 changed the way that function annotations are generated.
Prior versions required the (now removed) <tt>-py3</tt> option to generate function annotation support
containing C/C++ types instead of supporting <tt>%feature("python:annotations", "c")</tt>.
Variable annotations were also added in SWIG-4.1.0.
</p>
<H3><a name="Python_nn75">33.12.2 Buffer interface</a></H3>
@ -6944,10 +7051,11 @@ modify the buffer.
<p>
By including <tt>pyabc.i</tt> and using the <tt>-py3</tt> command
line option when calling SWIG, the proxy classes of the STL containers
By including <tt>pyabc.i</tt> in your interface file,
the proxy classes of the STL containers
will automatically gain an appropriate abstract base class from the
<tt>collections.abc</tt> module. For
<tt>collections.abc</tt> module for Python 3.3 and later, otherwise from the
<tt>collections</tt> module. For
example, the following SWIG interface:
</p>
@ -6964,8 +7072,10 @@ namespace std {
<p>
will generate a Python proxy class <tt>Mapii</tt> inheriting from
<tt>collections.abc.MutableMap</tt> and a proxy class <tt>IntList</tt>
inheriting from <tt>collections.abc.MutableSequence</tt>.
<tt>collections.abc.MutableMap</tt> for Python 3.3 and later, or <tt>collections.MutableMap</tt>
for earlier versions and a proxy class <tt>IntList</tt>
inheriting from <tt>collections.abc.MutableSequence</tt> for Python 3.3 or later,
or <tt>collections.MutableSequence</tt> for earlier versions.
</p>
<p>
@ -6974,7 +7084,9 @@ used to define an abstract base class for your own C++ class:
</p>
<div class="code"><pre>
%pythonabc(MySet, collections.abc.MutableSet);
%pythonabc(MySet, collections.abc.MutableSet); # Python 3.3 and later
%pythonabc(MySet, collections.MutableSet); # Prior to Python 3.3
%pythonabc(MySet, "collections.abc.MutableSet if _swig_python_version_info &gt;= (3, 3) else collections.MutableSet"); # All Python versions
</pre></div>
<p>
@ -6988,6 +7100,8 @@ For details of abstract base class, please see
of the classes in the <tt>collections</tt> module in Python 3.7.
The <tt>collections.abc</tt> module was introduced in Python 3.3 and hence this feature
requires Python 3.3 or later.
SWIG-4.1.0 introduced the flexibility of using
either the <tt>collections.abc</tt> module for Python 3.3 and later or the <tt>collections</tt> module for earlier Python versions.
</p>
<H3><a name="Python_nn77">33.12.4 Byte string output conversion</a></H3>

2
Doc/Manual/Ruby.html
View File

@ -1707,7 +1707,7 @@ For example: </p>
<div class="code">
<pre>%rename("is_it_safe?") is_it_safe();
%typemap(out) int is_it_safe "$result = ($1 != 0) ? Qtrue : Qfalse;";
%typemap(out) int is_it_safe "$result = ($1 != 0) ? Qtrue : Qfalse;"
int is_it_safe();</pre>
</div>

182
Doc/Manual/SWIG.html
View File

@ -47,6 +47,7 @@
<li><a href="#SWIG_rename_ignore">Renaming and ignoring declarations</a>
<ul>
<li><a href="#SWIG_nn29">Simple renaming of specific identifiers</a>
<li><a href="#SWIG_ignore">Ignoring identifiers</a>
<li><a href="#SWIG_advanced_renaming">Advanced renaming support</a>
<li><a href="#SWIG_limiting_renaming">Limiting global renaming rules</a>
<li><a href="#SWIG_chosen_unignore">Ignoring everything then wrapping a few selected symbols</a>
@ -133,11 +134,11 @@ Supported Target Language Options
-ruby - Generate Ruby wrappers
-scilab - Generate Scilab wrappers
-tcl8 - Generate Tcl 8 wrappers
-xml - Generate XML wrappers
Experimental Target Language Options
-mzscheme - Generate MzScheme/Racket wrappers
-ocaml - Generate OCaml wrappers
-xml - Generate XML wrappers
General Options
-addextern - Add extra extern declarations
@ -154,6 +155,7 @@ General Options
-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-quiet - Display less parse tree node debug info when using other -debug options
-debug-tags - Display information about the tags found in the interface
-debug-template - Display information for debugging templates
-debug-top &lt;n&gt; - Display entire parse tree at stages 1-4, &lt;n&gt; is a csv list of stages
@ -208,7 +210,7 @@ General Options
-oh &lt;headfile&gt; - Set name of C++ output header file for directors to &lt;headfile&gt;
-outcurrentdir - Set default output dir to current dir instead of input file's path
-outdir &lt;dir&gt; - Set language specific files output directory to &lt;dir&gt;
-pcreversion - Display PCRE version information
-pcreversion - Display PCRE2 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
@ -1469,14 +1471,14 @@ SWIG generates the following code:
<pre>
/* C mode */
void foo_set(char *value) {
if (foo) free(foo);
free(foo);
foo = (char *) malloc(strlen(value)+1);
strcpy(foo, value);
}
/* C++ mode. When -c++ option is used */
void foo_set(char *value) {
if (foo) delete [] foo;
delete [] foo;
foo = new char[strlen(value)+1];
strcpy(foo, value);
}
@ -1841,6 +1843,25 @@ all to `output' by specifying :</p>
%rename(output) print; // Rename all `print' functions to `output'
</pre></div>
<p>
A new <tt>%rename</tt> for the same name will replace the current
<tt>%rename</tt> for all uses after it in the file, and setting the
new name to "" will remove the rename. So, for instance, if you
wanted to rename some things in one file and not in another, you could
do:
</p>
<div class="code">
<pre>
%rename(print1) print;
%include "header1.h" //Anything "print" in here will become "print1"
%rename(print2) print;
%include "header2.h" //Anything "print" in here will become "print2"
%rename("") print;
%include "header3.h" //Anything "print" in here will remain "print"
</pre>
</div>
<p>
SWIG does not normally perform any checks to see if the functions it wraps are
already defined in the target scripting language. However, if you are
@ -1857,6 +1878,9 @@ If you are using the <tt>%rename</tt> directive and C++, make sure you read the
for method overloading and default arguments.
</p>
<H4><a name="SWIG_ignore">5.4.7.2 Ignoring identifiers</a></H4>
<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:
@ -1896,7 +1920,7 @@ This directive is still supported, but it is deprecated and should probably be a
directive is more powerful and better supports wrapping of raw header file information.
</p>
<H4><a name="SWIG_advanced_renaming">5.4.7.2 Advanced renaming support</a></H4>
<H4><a name="SWIG_advanced_renaming">5.4.7.3 Advanced renaming support</a></H4>
<p>
@ -2022,8 +2046,8 @@ and a more descriptive one, but the two functions are otherwise equivalent:
<td>String after (Perl-like) regex substitution operation. This function
allows applying arbitrary regular expressions to the identifier names. The
<i>pattern</i> part is a regular expression in Perl syntax (as supported
by the <a href="http://www.pcre.org/">Perl Compatible Regular Expressions (PCRE)</a>)
library and the <i>subst</i> string
by the <a href="http://www.pcre.org/">Perl Compatible Regular Expressions</a>)
(PCRE2 library) and the <i>subst</i> string
can contain back-references of the form <tt>\N</tt> where <tt>N</tt> is a digit
from 0 to 9, or one of the following escape sequences: <tt>\l</tt>, <tt>\L</tt>,
<tt>\u</tt>, <tt>\U</tt> or <tt>\E</tt>. The back-references are replaced with the
@ -2041,23 +2065,10 @@ and a more descriptive one, but the two functions are otherwise equivalent:
<tt>%rename("regex:/(\\w+)_(.*)/\\u\\2/")</tt></td>
<td><tt>prefix_print</tt></td><td><tt>Print</tt></td>
</tr>
<tr>
<td><tt>command:cmd</tt></td>
<td>Output of an external command <tt>cmd</tt> with the string passed to
it as input. Notice that this function is extremely slow compared to all
the other ones as it involves spawning a separate process and using it for
many declarations is not recommended. The <i>cmd</i> is not enclosed in
square brackets but must be terminated with a triple <tt>'&lt;'</tt> sign,
e.g. <tt>%rename("command:tr&nbsp;-d&nbsp;aeiou &lt;&lt;&lt;")</tt>
(nonsensical example removing all vowels)</td>
<td><tt>Print</tt></td><td><tt>Prnt</tt></td>
</tr>
</table>
<p>
The most general function of all of the above ones (not counting
<tt>command</tt> which is even more powerful in principle but which should
generally be avoided because of performance considerations) is the
The most general function of all of the above ones is the
<tt>regex</tt> one. Here are some more examples of its use:
</p>
@ -2105,7 +2116,7 @@ are exactly equivalent and <tt>%rename</tt> can be used to selectively ignore
multiple declarations using the previously described matching possibilities.
</p>
<H4><a name="SWIG_limiting_renaming">5.4.7.3 Limiting global renaming rules</a></H4>
<H4><a name="SWIG_limiting_renaming">5.4.7.4 Limiting global renaming rules</a></H4>
<p>
@ -2137,11 +2148,15 @@ the match to class declarations only (in C++) and <tt>match="enumitem"</tt>
restricts it to the enum elements. SWIG also provides convenience macros for
such match expressions, for example
</p>
<div class="code">
<pre>
%rename("%(title)s", %$isenumitem) "";
// same as:
%rename("%(title)s", match="enumitem") "";
</pre>
</div>
<p>
will capitalize the names of all the enum elements but not change the case of
the other declarations. Similarly, <tt>%$isclass</tt>, <tt>%$isfunction</tt>,
@ -2151,6 +2166,56 @@ documentation is not exhaustive, see the "%rename predicates" section in
<tt>swig.swg</tt> for the full list of supported match expressions.
</p>
<p>
A logical not is also possible by using <tt>notmatch</tt>.
For example, <tt>notmatch="enumitem"</tt> will restrict the
match to all items that are not enum elements.
There is also a <tt>%$not</tt> macro which simply expands to "not".
Be careful using this as some of the other macros in <tt>swig.swg</tt>
are complex expressions and so it will only "notmatch" the first part
of the expression.
</p>
<div class="code">
<pre>
%rename("%(title)s", %$not %$isenumitem) "";
// same as:
%rename("%(title)s", notmatch="enumitem") "";
</pre>
</div>
<p>
For a comprehensive understanding of how the matching works, the internal
<a href="Extending.html#Extending_nn8">parse tree</a> needs to be examined using the
command line option: <tt>-debug-module 1 -debug-quiet</tt>.
A snippet of the resulting output might be:
</p>
<div class="shell">
<pre>
+++ destructor ----------------------------------------
| access - "public"
| decl - "f()."
| ismember - "1"
| name - "~Shape"
| storage - "virtual"
| sym:name - "~Shape"
</pre>
</div>
<p>
Here the node type is a "destructor" and in order to match all destructor nodes, use
<tt>match="destructor"</tt>. To match one of the listed attributes in the node,
such as when the storage is virtual, use <tt>match$storage="virtual"</tt>.
This will match all nodes that have a storage attribute set to "virtual".
To match only virtual destructors, combine them and use <tt>match="destructor", match$storage="virtual"</tt>.
</p>
<p>
While the vast majority of these internal parse tree nodes are unlikely to change from one version of
SWIG to the next, <b>use these matching rules at your own risk</b> as there are no guarantees that they will not change.
</p>
<p>
In addition to literally matching some string with <tt>match</tt> you can
also use <tt>regexmatch</tt> or <tt>notregexmatch</tt> to match a string
@ -2203,7 +2268,7 @@ wrap C++ overloaded functions and methods or C++ methods which use default argum
</p>
<H4><a name="SWIG_chosen_unignore">5.4.7.4 Ignoring everything then wrapping a few selected symbols</a></H4>
<H4><a name="SWIG_chosen_unignore">5.4.7.5 Ignoring everything then wrapping a few selected symbols</a></H4>
<p>
@ -2227,6 +2292,23 @@ the following approach could be taken:
%rename("%s") Star::shine; // named method
%include "myheader.h"
%rename("%s") ""; // Undo the %ignore
</pre>
</div>
<p>
If <tt>Star</tt> was in the <tt>Galaxy</tt> namespace, you would need
to unignore the namespace, too, and add the namespace to all the
renames:
</p>
<div class="code">
<pre>
%rename("%s") Galaxy;
%rename("%s") Galaxy::Star;
%rename("%s") Galaxy::Star::Star;
...
</pre>
</div>
@ -2241,6 +2323,7 @@ members of the class, so when the chosen class is unignored, all of its methods
%rename($ignore, %$isclass) ""; // Only ignore all classes
%rename("%s") Star; // Unignore 'Star'
%include "myheader.h"
%rename("%s", %$isclass) ""; // Stop ignoring all classes
</pre>
</div>
@ -2445,6 +2528,45 @@ This section describes the behavior of SWIG when processing ISO C structures and
handle C++ are described in the next section.
</p>
<p>
ISO C has a separate tag name space in which the names of structures,
unions and enumerated types are put, which is separate from the
name space for ordinary identifiers (function names, object names,
typedef names, enumeration constants). For example, this is valid
ISO C because <tt>Foo</tt> the struct tag and <tt>Foo</tt> the function
name are in different name spaces:
</p>
<div class="code"><pre>
struct Foo {
int bar;
};
int Foo(void) { return 42; }
</pre></div>
<p>
SWIG doesn't currently implement this separate tag name space and
for the above example you'll get:
</p>
<div class="code"><pre>
foo.i:5: Warning 302: Identifier 'Foo' redefined (ignored),
foo.i:1: Warning 302: previous definition of 'Foo'.
</pre></div>
<p>
In practice this rarely actually causes problems, particular because
SWIG has special handling for <tt>typedef</tt> so cases such as this
work:
</p>
<div class="code"><pre>
typedef struct Foo {
int bar;
} Foo;
</pre></div>
<p>
If SWIG encounters the definition of a structure or union, it
creates a set of accessor functions. Although SWIG does not need
@ -2456,8 +2578,7 @@ to an individual member. For example, the declaration :</p>
<div class="code"><pre>
struct Vector {
double x, y, z;
}
};
</pre></div>
<p>
@ -2594,7 +2715,6 @@ char *Foo_name_get(Foo *obj) {
}
char *Foo_name_set(Foo *obj, char *c) {
if (obj-&gt;name)
free(obj-&gt;name);
obj-&gt;name = (char *) malloc(strlen(c)+1);
strcpy(obj-&gt;name, c);
@ -2733,6 +2853,11 @@ void Foo_w_set(FOO *f, WORD value) {
</pre>
</div>
<p>
If you have accessor methods that you want to use as attributes in the
target language, you can make them appear as data members using
<a href="Library.html#Library_attributes">attributes.i</a>.
</p>
<p>
<b>Compatibility Note:</b> SWIG-1.3.11 and earlier releases transformed all non-primitive member datatypes
@ -2976,6 +3101,11 @@ typedef struct Vector {
</pre>
</div>
<p>
You'll also need to use these names if you want to directly call methods added
using <tt>%extend</tt> from other C/C++ code.
</p>
<p>
The name used for %extend should be the name of the struct and not the name of any typedef to the struct.
For example:

239
Doc/Manual/SWIGPlus.html
View File

@ -48,6 +48,9 @@
</ul>
<li><a href="#SWIGPlus_nn28">Overloaded operators</a>
<li><a href="#SWIGPlus_class_extension">Class extension</a>
<ul>
<li><a href="#SWIGPlus_replacing_methods">Replacing class methods</a>
</ul>
<li><a href="#SWIGPlus_nn30">Templates</a>
<ul>
<li><a href="#SWIGPlus_template_directive">The %template directive</a>
@ -581,7 +584,7 @@ automatically generate a wrapper for one.
<li>
If a C++ class does not declare an explicit copy constructor, SWIG will
automatically generate a wrapper for one if the <tt>%copyctor</tt> is used.
automatically generate a wrapper for one if <tt>%copyctor</tt> is used.
</li>
<li>
@ -1122,7 +1125,7 @@ customization features.
<p>
SWIG wraps class members that are public following the C++
conventions, i.e., by explicit public declaration or by the use of
the <tt>using</tt> directive. In general, anything specified in a
<tt>using</tt> declarations. In general, anything specified in a
private or protected section will be ignored, although the internal
code generator sometimes looks at the contents of the private and
protected sections so that it can properly generate code for default
@ -1349,16 +1352,19 @@ following:
<div class="code">
<pre>
Vector *wrap_cross_product(Vector *a, Vector *b) {
Vector x = *a;
Vector y = *b;
Vector r = cross_product(x, y);
Vector x;
Vector y;
Vector r;
x = *a;
y = *b;
r = cross_product(x, y);
return new Vector(r);
}</pre>
</div>
<p>
In order for the wrapper code to compile, <tt>Vector</tt> must define a copy constructor and a
default constructor.
In order for the wrapper code to compile, <tt>Vector</tt> must define a default constructor, copy assignment operator (and/or a move assignment operator for C++11 and later).
The <a href="CPlusPlus11.html#CPlusPlus11_move_only">Movable and move-only types</a> section should be read regarding C++11 move semantics and return by value.
</p>
<p>
@ -1371,9 +1377,12 @@ called the "Fulton Transform". This produces a wrapper that looks like this:
<div class="code">
<pre>
Vector cross_product(Vector *a, Vector *b) {
SwigValueWrapper&lt;Vector&gt; x = *a;
SwigValueWrapper&lt;Vector&gt; y = *b;
SwigValueWrapper&lt;Vector&gt; r = cross_product(x, y);
SwigValueWrapper&lt;Vector&gt; x;
SwigValueWrapper&lt;Vector&gt; y;
SwigValueWrapper&lt;Vector&gt; r;
x = *a;
y = *b;
r = cross_product(x, y);
return new Vector(r);
}
</pre>
@ -2080,7 +2089,6 @@ or for statically typed languages like Java:
<pre>
example.i:4: Warning 516: Overloaded method foo(long) ignored,
example.i:3: Warning 516: using foo(int) instead.
at example.i:3 used.
</pre>
</div>
@ -2327,8 +2335,8 @@ also apply to <tt>%ignore</tt>. For example:
<div class="code">
<pre>
%ignore foo(double); // Ignore all foo(double)
%ignore Spam::foo; // Ignore foo in class Spam
%ignore Spam::foo(double); // Ignore foo(double) in class Spam
%ignore Spam::foo; // Ignore foo in class Spam (and foo in any derived classes)
%ignore Spam::foo(double); // Ignore foo(double) in class Spam (and foo in any derived classes)
%ignore *::foo(double); // Ignore foo(double) in all classes
</pre>
</div>
@ -2383,6 +2391,53 @@ global scope (e.g., a renaming of <tt>Spam::foo</tt> takes precedence
over a renaming of <tt>foo(int)</tt>).</p>
</li>
<li><p>
Renaming a class member, using an unparameterized but qualified name, such as <tt>Spam::foo</tt>, also applies to members in all derived classes
that have members with the same name.
This can be used to simply rename a method, across an entire class hierarchy for all overloaded and non-overloaded methods.
This also applies to methods introduced via <tt>using</tt> declarations, see
<a href="#SWIGPlus_nn35">Using declarations and inheritance</a>.
For example:
</p>
<div class="code">
<pre>
%rename(foo_new) Spam::foo;
class Spam {
public:
virtual void foo(int); // Renamed to foo_new
};
class Bar : public Spam {
public:
virtual void foo(int); // Renamed to foo_new
void foo(bool, short, int); // Renamed to foo_new
};
class Grok : public Bar {
public:
virtual void foo(int); // Renamed to foo_new
void foo(bool, int); // Renamed to foo_new
void foo(const char *); // Renamed to foo_new
void foo(Bar *); // Renamed to foo_new
};
class Spok : public Grok {
public:
void foo(); // Renamed to foo_new
};
class Knock : public Spok {
public:
using Grok::foo; // Introduced methods renamed to foo_new
};
</pre>
</div>
</li>
<li><p>
The order in which <tt>%rename</tt> directives are defined does not matter
as long as they appear before the declarations to be renamed. Thus, there is no difference
@ -2944,6 +2999,59 @@ be used to extend a structure with more than just methods, a more suitable
directive name has been chosen.
</p>
<H3><a name="SWIGPlus_replacing_methods">6.17.1 Replacing class methods</a></H3>
<p>
Suppose there is a method in a class that you need to replace and keep the method name the same.
This can be achieved combining the <tt>%extend</tt> and <tt>%ignore</tt> directives covered earlier.
Here is an example to replace the <tt>MyClass::mymethod()</tt>:
<div class="code">
<pre>
%extend MyClass {
void mymethod() {
std::cout &lt;&lt; "swig mymethod" &lt;&lt; std::endl;
}
}
%ignore MyClass::mymethod;
%inline %{
class MyClass {
public:
void mymethod() {
std::cout &lt;&lt; "class mymethod" &lt;&lt; std::endl;
}
};
%}
</pre>
</div>
<p>
Or if your code organization makes more sense to put
the <tt>%extend</tt> after the class definition, you would need the following:
</p>
<div class="code">
<pre>
%rename("") MyClass::mymethod; // unignores the method
</pre>
</div>
<p>
before the <tt>%extend</tt> or SWIG will continue to ignore
<tt>mymethod()</tt>, even in an <tt>%extend</tt>.
</p>
<p>
Note that you can call the class method from the method
in <tt>%extend</tt>, just use <tt>self-&gt;mymethod()</tt> and it will call
the class method, not the one in <tt>%extend</tt>.
</p>
<H2><a name="SWIGPlus_nn30">6.18 Templates</a></H2>
@ -2955,22 +3063,24 @@ is expected in an interface file. For example:
<div class="code">
<pre>
void foo(vector&lt;int&gt; *a, int n);
void bar(list&lt;int, 100&gt; *x);
void bar(std::array&lt;int, 100&gt; *x);
</pre>
</div>
<p>
There are some restrictions on the use of non-type arguments. Simple literals
are supported, and so are some constant expressions. However, use of '&lt;'
and '&gt;' within a constant expressions currently is not supported by SWIG
('&lt;=' and '&gt;=' are though). For example:
are supported, and so are most constant expressions. However, there are some
limitations on the use of '&lt;' and '&gt;' in constant expressions (but note
that '&lt;=' and '&gt;=' are fully supported). For example:
</p>
<div class="code">
<pre>
void bar(list&lt;int, 100&gt; *x); // OK
void bar(list&lt;int, 2*50&gt; *x); // OK
void bar(list&lt;int, (2&gt;1 ? 100 : 50)&gt; *x) // Not supported
void bar(std::array&lt;int, 100&gt; *x); // OK
void bar(std::array&lt;int, 2*50&gt; *x); // OK
void bar(std::array&lt;int, (1&lt;2 ? 100 : 50)&gt; *x) // OK
void bar(std::array&lt;int, 1&lt;2 ? 100 : 50&gt; *x) // Not supported
void bar(std::array&lt;int, (2&gt;1 ? 100 : 50)&gt; *x) // Not supported
</pre>
</div>
@ -4017,23 +4127,23 @@ math::Complex c;
<p>
At this level, namespaces are relatively easy to manage. However, things start to get
very ugly when you throw in the other ways a namespace can be used. For example,
selective symbols can be exported from a namespace with <tt>using</tt>.
selective symbols can be exported from a namespace with a <tt>using</tt> declaration:
</p>
<div class="code">
<pre>
using math::Complex;
using math::Complex; // Using declaration
double magnitude(Complex *c); // Namespace prefix stripped
</pre>
</div>
<p>
Similarly, the contents of an entire namespace can be made available like this:
Similarly, the contents of an entire namespace can be made available via a <tt>using</tt> directive:
</p>
<div class="code">
<pre>
using namespace math;
using namespace math; // Using directive
double x = sin(1.0);
double magnitude(Complex *c);
</pre>
@ -4190,9 +4300,11 @@ Similarly, <tt>%ignore</tt> can be used to ignore declarations.
</p>
<p>
<tt>using</tt> declarations do not have any effect on the generated wrapper
code. They are ignored by SWIG language modules and they do not result in any
code. However, these declarations <em>are</em> used by the internal type
C++ <tt>using</tt> directives and <tt>using</tt> declarations
do not add any code to the generated wrapper code.
However, there is an exception in one context, see <a href="#SWIGPlus_nn35">Using declarations and inheritance</a>
for introducing members of a base class into a derived class definition.
C++ <tt>using</tt> declarations and directives <em>are</em> used by the internal type
system to track type-names. Therefore, if you have code like this:
</p>
@ -5116,7 +5228,7 @@ exit # 'a' is released, SWIG unref 'a' called in the destructor wra
<p>
<tt>using</tt> declarations are sometimes used to adjust access to members of
C++ <tt>using</tt> declarations are sometimes used to introduce members of
base classes. For example:
</p>
@ -5172,7 +5284,8 @@ you wrap this code in Python, the module works just like you would expect:
</div>
<p>
<tt>using</tt> declarations can also be used to change access when applicable. For example:
C++ <tt>using</tt> declarations can also be used to change access when applicable.
For example, protected methods in a base class can be made public in a derived class:
</p>
<div class="code">
@ -5205,15 +5318,15 @@ ignored in a base class, it will also be ignored by a <tt>using</tt> declaration
<p>
Because a <tt>using</tt> declaration does not provide fine-grained
control over the declarations that get imported, it may be difficult
control over the declarations that get imported, because a single <tt>using</tt> declaration
may introduce multiple methods, it may be difficult
to manage such declarations in applications that make heavy use of
SWIG customization features. If you can't get <tt>using</tt> to work
correctly, you can always change the interface to the following:
correctly, you can always modify the C++ code to handle SWIG differently such as:
</p>
<div class="code">
<pre>
class FooBar : public Foo, public Bar {
public:
#ifndef SWIG
@ -5229,13 +5342,36 @@ public:
</pre>
</div>
<p>
If the C++ code being wrapped cannot be changed, make judicious usage of <tt>%extend</tt> and <tt>%rename</tt>
to ignore and unignore declarations. The example below is effectively the same as above:
</p>
<div class="code">
<pre>
%extend FooBar {
int blah(int x) { return $self-&gt;Foo::blah(x); }
double blah(double x) { return $self-&gt;Bar::blah(x); }
}
%ignore FooBar::blah; // ignore all FooBar::blah below
%rename("") FooBar::blah(const char *x); // parameterized unignore
class FooBar : public Foo, public Bar {
public:
using Foo::blah;
using Bar::blah;
char *blah(const char *x);
};
</pre>
</div>
<p>
<b>Notes:</b>
</p>
<ul>
<li><p>If a derived class redefines a method defined in a base class, then a <tt>using</tt> declaration
won't cause a conflict. For example:</p>
<li><p>If a derived class introduces a method defined in a base class via a <tt>using</tt> declaration,
there won't be a conflict due to incorrect additional methods. For example:</p>
<div class="code">
<pre>
@ -5247,14 +5383,14 @@ public:
class Bar : public Foo {
public:
using Foo::blah; // Only imports blah(double);
using Foo::blah; // Only introduces blah(double);
int blah(int);
};
</pre>
</div>
<li><p>Resolving ambiguity in overloading may prevent declarations from being
imported by <tt>using</tt>. For example:
<li><p>Renaming methods may prevent methods from being
introduced into the derived class via <tt>using</tt> declarations. For example:
</p>
<div class="code">
@ -5268,11 +5404,38 @@ public:
class Bar : public Foo {
public:
using Foo::blah; // Only imports blah(int)
using Foo::blah; // Only introduces blah(int)
double blah(double x);
};
</pre>
</div>
<p>
The problem here is <tt>Foo::blah</tt> is renamed to <tt>blah_long</tt> in the target language, but
the <tt>using</tt> declaration in Bar is not renamed in the target language and thinks all introduced methods should simply
be called <tt>blah</tt>.
It is not clear what target language names should be used in Bar and so the conflicting names are effectively ignored
as they are not introduced into the derived class for the target language wrappers.
In such situations SWIG will emit a warning:
</p>
<div class="shell">
<pre>
example.i:15: Warning 526: Using declaration Foo::blah, with name 'blah', is not actually using
example.i:10: Warning 526: the method from Foo::blah(long), with name 'blah_long', as the names are different.
</pre>
</div>
<p>
<b>Compatibility Note:</b>
This warning message was introduced in SWIG-4.1.0.
Prior versions also effectively ignored the using declaration for the same reasons, but were silent about it.
</p>
<p>
If methods really need different names, please use of combinations of <tt>%rename</tt>, <tt>%ignore</tt> and <tt>%extend</tt> to achieve the desired outcome.
</p>
</ul>
<H2><a name="SWIGPlus_nested_classes">6.27 Nested classes</a></H2>

13
Doc/Manual/Scilab.html
View File

@ -304,11 +304,6 @@ The following table lists the Scilab specific command line options in addition t
<td>Generate the gateway XML with the given &lt;gateway_id&gt;</td>
</tr>
<tr>
<td><tt>-targetversion</tt></td>
<td>Generate for Scilab target (major) version</td>
</tr>
</table>
<p>
@ -343,10 +338,6 @@ In Scilab 5.x, identifier names are composed of 24 characters maximum (this limi
In these cases, the <a href="SWIG.html#SWIG_rename_ignore">%rename directive</a> can be used to choose a different Scilab name.
</p>
<p>
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>
@ -768,7 +759,7 @@ Pointers are supported by SWIG. A pointer can be returned from a wrapped C/C++ f
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.
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 accessed 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.
</p>
<p>
@ -776,7 +767,7 @@ Notes:
</p>
<ul>
<li>type tracking needs the SWIG runtime to be first initialized with the appropriate function (see the <a href="#Scilab_module_initialization">Module initialization</a> section).</li>
<li>for any reason, if a wrapped pointer type is unknown (or if the SWIG runtime is not initialized), SWIG maps it to a Scilab pointer. Also, a Scilab pointer is always accepted as a pointer argument of a wrapped function. The drawaback is that pointer type is lost.</li>
<li>for any reason, if a wrapped pointer type is unknown (or if the SWIG runtime is not initialized), SWIG maps it to a Scilab pointer. Also, a Scilab pointer is always accepted as a pointer argument of a wrapped function. The drawback is that pointer type is lost.</li>
</ul>
<p>

47
Doc/Manual/Tcl.html
View File

@ -79,9 +79,9 @@
</p>
<p>
This chapter discusses SWIG's support of Tcl. SWIG currently requires
Tcl 8.0 or a later release. Earlier releases of SWIG supported Tcl 7.x, but
this is no longer supported.
This chapter discusses SWIG's support of Tcl. Since SWIG 4.1.0, Tcl 8.4 or a
later release is required. Prior to that earlier Tcl 8.x releases were also
supported.
</p>
<H2><a name="Tcl_nn2">37.1 Preliminaries</a></H2>
@ -636,7 +636,7 @@ tcl:
<p>
To build the extension, run NMAKE (you may need to run vcvars32
first). This is a pretty minimal Makefile, but hopefully its enough
first). This is a pretty minimal Makefile, but hopefully it's enough
to get you started. With a little practice, you'll be making lots of
Tcl extensions.
</p>
@ -1227,7 +1227,15 @@ _108fea88_p_Bar
<p>
Finally, to destroy objects created from Tcl, you can either let the object
name go out of scope or you can explicitly delete the object. For example:
name go out of scope or you can explicitly delete the object as shown below.
Objects won't get automatically destroyed when the Tcl program exits, so if
it's important that the C++ destructor is called for a class you'll need to
make sure that you explicitly do this for objects of that class before program
exit.
</p>
<p>
For example:
</p>
<div class="code">
@ -2235,7 +2243,7 @@ as well as a special error code:
<div class="code">
<pre>
/* send message, return number of bytes sent, along with success code */
int send_message(char *text, int len, int *success);
int send_message(char *text, int *success);
</pre>
</div>
@ -2811,10 +2819,8 @@ used as a <tt>char **</tt> object.
// This gives SWIG some cleanup code that will get called after the function call
%typemap(freearg) char ** {
if ($1) {
free($1);
}
}
// Now a test functions
%inline %{
@ -3131,9 +3137,8 @@ For example:
<p>
Tcl 7.4 introduced the idea of an extension package. By default, SWIG
generates all of the code necessary to create a package. To set the package version,
simply use the <tt>-pkgversion</tt> option. For example:
SWIG generates all of the code necessary to create a Tcl extension package.
To set the package version use the <tt>-pkgversion</tt> option. For example:
</p>
<div class="code">
@ -3144,7 +3149,7 @@ simply use the <tt>-pkgversion</tt> option. For example:
<p>
After building the SWIG generated module, you need to execute
the "<tt>pkg_mkIndex</tt>" command inside tclsh. For example :
the <tt>pkg_mkIndex</tt> command inside tclsh. For example :
</p>
<div class="code"><pre>
@ -3424,7 +3429,7 @@ interesting things.
<p>
For background information about the Tcl Stubs feature, see
<a href="http://www.tcl.tk/doc/howto/stubs.html">http://www.tcl.tk/doc/howto/stubs.html</a>.
<a href="https://www.tcl.tk/doc/howto/stubs.html">https://www.tcl.tk/doc/howto/stubs.html</a>.
</p>
<p>
@ -3434,11 +3439,17 @@ feature if compiled with <tt>-DUSE_TCL_STUBS</tt>.
<p>
As of SWIG 1.3.40, the generated C/C++ wrapper will use the Tk Stubs
feature if compiled with <tt>-DUSE_TK_STUBS</tt>. Also, you can override
the minimum version to support which is passed to <tt>Tcl_InitStubs()</tt>
and <tt>Tk_InitStubs()</tt> with <tt>-DSWIG_TCL_STUBS_VERSION="8.3"</tt>
or the version being compiled with using
<tt>-DSWIG_TCL_STUBS_VERSION=TCL_VERSION</tt>.
feature if compiled with <tt>-DUSE_TK_STUBS</tt>.
</p>
<p>
By default SWIG sets the minimum Tcl version to support to the 8.4
as that's the minimum Tcl version we aim to support (since SWIG 4.1.0; before
this SWIG set it to 8.1, which was the first Tcl version with the stubs
mechanism). This minimum version is passed to <tt>Tcl_InitStubs()</tt> and
<tt>Tk_InitStubs()</tt>. You can override with a specific version using
<tt>-DSWIG_TCL_STUBS_VERSION="8.5"</tt> or set it to the Tcl version being
compiled with using <tt>-DSWIG_TCL_STUBS_VERSION=TCL_VERSION</tt>.
</p>
</body>

123
Doc/Manual/Typemaps.html
View File

@ -48,6 +48,7 @@
<ul>
<li><a href="#Typemaps_special_macro_descriptor">$descriptor(type)</a>
<li><a href="#Typemaps_special_macro_typemap">$typemap(method, typepattern)</a>
<li><a href="#Typemaps_special_macro_typemap_attribute">$typemap(method:attribute, typepattern)</a>
</ul>
<li><a href="#Typemaps_special_variable_attributes">Special variables and typemap attributes</a>
<li><a href="#Typemaps_special_variables_and_macros">Special variables combined with special variable macros</a>
@ -786,7 +787,7 @@ Here are some examples of valid typemap specifications:
%typemap(in) int {
$1 = PyInt_AsLong($input);
}
%typemap(in) int "$1 = PyInt_AsLong($input);";
%typemap(in) int "$1 = PyInt_AsLong($input);"
%typemap(in) int %{
$1 = PyInt_AsLong($input);
%}
@ -802,7 +803,7 @@ Here are some examples of valid typemap specifications:
}
/* Typemap with modifiers */
%typemap(in, doc="integer") int "$1 = scm_to_int($input);";
%typemap(in, doc="integer") int "$1 = scm_to_int($input);"
/* Typemap applied to patterns of multiple arguments */
%typemap(in) (char *str, int len),
@ -1060,9 +1061,11 @@ The matching rules can be observed in practice by using the debugging options al
<p>
Typemaps are matched using both a type and a name (typically the name of a argument). For a given
<tt>TYPE NAME</tt> pair, the following rules are applied, in order, to find a match. The first typemap found
is used.
Typemaps are matched using both a type and a name (typically the name of an
argument, but in the case of <tt>out</tt> typemaps, the name of a function,
qualified by the class name if it's a class method). For a given <tt>TYPE
NAME</tt> pair, the following rules are applied, in order, to find a match.
The first typemap found is used.
</p>
<ul>
@ -1353,13 +1356,13 @@ const reference are written like this:
<div class="code">
<pre>
%typemap(in) int "... convert to int ...";
%typemap(in) short "... convert to short ...";
%typemap(in) float "... convert to float ...";
%typemap(in) int "... convert to int ..."
%typemap(in) short "... convert to short ..."
%typemap(in) float "... convert to float ..."
...
%typemap(in) const int &amp; "... convert ...";
%typemap(in) const short &amp; "... convert ...";
%typemap(in) const float &amp; "... convert ...";
%typemap(in) const int &amp; "... convert ..."
%typemap(in) const short &amp; "... convert ..."
%typemap(in) const float &amp; "... convert ..."
...
</pre>
</div>
@ -1379,16 +1382,16 @@ Below is a list of the typical default types supplied by language modules, showi
<div class="code">
<pre>
%typemap(in) SWIGTYPE &amp; { ... default reference handling ... };
%typemap(in) SWIGTYPE * { ... default pointer handling ... };
%typemap(in) SWIGTYPE *const { ... default pointer const handling ... };
%typemap(in) SWIGTYPE *const&amp; { ... default pointer const reference handling ... };
%typemap(in) SWIGTYPE[ANY] { ... 1D fixed size arrays handling ... };
%typemap(in) SWIGTYPE [] { ... unknown sized array handling ... };
%typemap(in) enum SWIGTYPE { ... default handling for enum values ... };
%typemap(in) const enum SWIGTYPE &amp; { ... default handling for const enum reference values ... };
%typemap(in) SWIGTYPE (CLASS::*) { ... default pointer member handling ... };
%typemap(in) SWIGTYPE { ... simple default handling ... };
%typemap(in) SWIGTYPE &amp; { ... default reference handling ... }
%typemap(in) SWIGTYPE * { ... default pointer handling ... }
%typemap(in) SWIGTYPE *const { ... default pointer const handling ... }
%typemap(in) SWIGTYPE *const&amp; { ... default pointer const reference handling ... }
%typemap(in) SWIGTYPE[ANY] { ... 1D fixed size arrays handling ... }
%typemap(in) SWIGTYPE [] { ... unknown sized array handling ... }
%typemap(in) enum SWIGTYPE { ... default handling for enum values ... }
%typemap(in) const enum SWIGTYPE &amp; { ... default handling for const enum reference values ... }
%typemap(in) SWIGTYPE (CLASS::*) { ... default pointer member handling ... }
%typemap(in) SWIGTYPE { ... simple default handling ... }
</pre>
</div>
@ -1940,7 +1943,7 @@ Occasionally, typemap code will be specified using a few alternative forms. For
<div class="code">
<pre>
%typemap(in) int "$1 = PyInt_AsLong($input);";
%typemap(in) int "$1 = PyInt_AsLong($input);"
%typemap(in) int %{
$1 = PyInt_AsLong($input);
%}
@ -2455,6 +2458,41 @@ The result is the following expansion
</pre>
</div>
<H4><a name="Typemaps_special_macro_typemap_attribute">14.4.4.3 $typemap(method:attribute, typepattern)</a></H4>
<p>
An enhanced version of <tt>$typemap</tt> provides access to typemap attributes by
appending a colon and the attribute name after the method name. In the example below,
"cstype" is the typemap method and "out" is the typemap attribute.
</p>
<div class="code">
<pre>
%typemap(cstype, out="object") XClass "XClass"
%typemap(cscode) BarClass %{
$typemap(cstype:out, XClass) bar()
{
return null;
}
</pre>
</div>
<p>
which expands to
</p>
<div class="code">
<pre>
object bar()
{
return null;
}
</pre>
</div>
<p>
<b>Compatibility note: </b> Support for typemap attributes in <tt>$typemap</tt>
was introduced in SWIG-4.1.0.
</p>
<H3><a name="Typemaps_special_variable_attributes">14.4.5 Special variables and typemap attributes</a></H3>
@ -3103,7 +3141,7 @@ as shown. To work with heap allocated data, the following technique can be use
}
}
%typemap(freearg) float value[ANY] {
if ($1) free($1);
free($1);
}
</pre>
</div>
@ -3298,7 +3336,7 @@ The example above also shows a common approach of issuing a warning for an as ye
</p>
<p>
<b>Compatibility note: </b> In SWIG-1.1 different languages could be distinguished with the language name being put within the <tt>%typemap</tt> directive, for example, <br>
<b>Compatibility note: </b> In SWIG-1.1 different languages could be distinguished with the language name being put within the <tt>%typemap</tt> directive, but this was deprecated in SWIG 1.3.28 and support finally dropped completely in SWIG 4.1.0 so you'll need to update any remaining uses to use the approach above. For example, <br>
<tt>%typemap(ruby, in) int "$1 = NUM2INT($input);"</tt>.
</p>
@ -3326,7 +3364,7 @@ Consider running the following code through SWIG:
<div class="code">
<pre>
%typemap(out) SWIGTYPE %{
$result = new $1_ltype((const $1_ltype &amp;)$1);
$result = new $1_ltype($1);
%}
%inline %{
@ -3376,7 +3414,7 @@ If the typemap code is kept the same and just the "optimal" attribute specified
<div class="code">
<pre>
%typemap(out, optimal="1") SWIGTYPE %{
$result = new $1_ltype((const $1_ltype &amp;)$1);
$result = new $1_ltype($1);
%}
</pre>
</div>
@ -3403,7 +3441,7 @@ SWIGEXPORT void * SWIGSTDCALL CSharp_XX_create() {
void * jresult ;
XX result;
result = XX::create();
jresult = new XX((const XX &amp;)result);
jresult = new XX(result);
return jresult;
}
@ -3418,7 +3456,7 @@ With the "optimal" attribute, the code is:
<pre>
SWIGEXPORT void * SWIGSTDCALL CSharp_XX_create() {
void * jresult ;
jresult = new XX((const XX &amp;)XX::create());
jresult = new XX(XX::create());
return jresult;
}
</pre>
@ -3475,7 +3513,7 @@ It should be clear that the above code cannot be used as the argument to the cop
</p>
<p>
Secondly, if the typemaps uses <tt>$1</tt> more than once, then multiple calls to the wrapped function
Secondly, if the typemap uses <tt>$1</tt> more than once, then multiple calls to the wrapped function
will be made. Obviously that is not very optimal.
In fact SWIG attempts to detect this and will issue a warning something like:
</p>
@ -3556,7 +3594,7 @@ maps perform the conversion described for the above example:
}
%typemap(freearg) (int argc, char *argv[]) {
if ($2) free($2);
free($2);
}
/* Required for C++ method overloading */
@ -3835,7 +3873,7 @@ To eliminate this, define a fragment that includes the common marshalling code:
<p>
When the "in" or "varin" typemaps for MyClass are required, the
contents of the fragment called "AsMyClass" is added to the "header" section within the generated code, and then the
contents of the fragment called "AsMyClass" are added to the "header" section within the generated code, and then the
typemap code is emitted. Hence, the method <tt>AsMyClass</tt> will be
generated into the wrapper code before any typemap code that calls it.
</p>
@ -3983,9 +4021,24 @@ inclusion of the other fragments.
<li>
<p>
A typemap can also use more than one fragment, but since the
syntax is different, you need to specify the dependent fragments in a comma separated
list. Consider:
A typemap can also use more than one fragment:
</p>
<div class="code">
<pre>
%typemap("in", fragment="frag1", fragment="frag2", fragment="frag3") {...}
</pre>
</div>
<p>
<b>Compatibility note: </b> The ability to use multiple
<tt>fragment</tt> keys as shown above was introduced in SWIG-4.1.0.
</p>
<p>
Multiple fragments can alternatively be specified as a comma
separated list value in a single <tt>fragment</tt> key.
Note that no whitespace is allowed within this comma separated list.
The following is the equivalent to the above:
</p>
<div class="code">
@ -3995,7 +4048,7 @@ list. Consider:
</div>
<p>
which is equivalent to:
which in turn is functionally equivalent to:
</p>
<div class="code">

8
Doc/Manual/Varargs.html
View File

@ -512,7 +512,7 @@ like this:
<pre>
%typemap(in) (...)(char *vargs[10]) {
int i;
int argc;
Py_ssize_t argc;
for (i = 0; i &lt; 10; i++) vargs[i] = 0;
argc = PyTuple_Size(varargs);
if (argc &gt; 10) {
@ -523,6 +523,7 @@ like this:
PyObject *pyobj = PyTuple_GetItem(varargs, i);
char *str = 0;
%#if PY_VERSION_HEX&gt;=0x03000000
const char *strtmp = 0;
PyObject *pystr;
if (!PyUnicode_Check(pyobj)) {
PyErr_SetString(PyExc_ValueError, "Expected a string");
@ -532,7 +533,10 @@ like this:
if (!pystr) {
SWIG_fail;
}
str = strdup(PyBytes_AsString(pystr));
strtmp = PyBytes_AsString(pystr);
str = (char *)malloc(strlen(strtmp) + 1);
if (str)
strcpy(str, strtmp);
Py_DECREF(pystr);
%#else
if (!PyString_Check(pyobj)) {

2
Doc/Manual/Warnings.html
View File

@ -428,6 +428,7 @@ example.i(4) : Syntax error in input(1).
<li>324. Named nested template instantiations not supported. Processing as if no name was given to %template().
<li>325. Nested <em>kind</em> not currently supported (<em>name</em> ignored).
<li>326. Deprecated %extend name used - the <em>kind</em> name '<em>name</em>' should be used instead of the typedef name '<em>name</em>'.
<li>327. Extern template ignored.
<li>350. operator new ignored.
<li>351. operator delete ignored.
<li>352. operator+ ignored.
@ -536,6 +537,7 @@ example.i(4) : Syntax error in input(1).
<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.
<li>526. Using declaration <em>declaration</em>, with name '<em>name</em>', is not actually using the method from <em>declaration</em>, with name '<em>name</em>', as the names are different.
</ul>
<H3><a name="Warnings_doxygen">19.9.6 Doxygen comments (560-599)</a></H3>

117
Doc/Manual/Windows.html
View File

@ -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>
@ -29,17 +29,16 @@
</ul>
<li><a href="#Windows_other_compilers">Instructions for using the Examples with other compilers</a>
</ul>
<li><a href="#Windows_cygwin_mingw">SWIG on Cygwin and MinGW</a>
<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 MSYS2</a>
<li><a href="#Windows_msys2">Building swig.exe using MSYS2</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>
</ul>
<ul>
<li><a href="#Windows_examples_cygwin">Running the examples on Windows using Cygwin</a>
</ul>
</ul>
<li><a href="#Windows_interface_file">Microsoft extensions and other Windows quirks</a>
</ul>
</div>
@ -210,95 +209,97 @@ RUBY_LIB: D:\ruby\lib\mswin32-ruby16.lib<br>
If you do not have access to Visual C++ you will have to set up project files / Makefiles for your chosen compiler. There is a section in each of the language modules detailing what needs setting up using Visual C++ which may be of some guidance. Alternatively you may want to use Cygwin as described in the following section.
</p>
<H2><a name="Windows_cygwin_mingw">3.3 SWIG on Cygwin and MinGW</a></H2>
<H2><a name="Windows_swig_exe">3.3 Building swig.exe on Windows</a></H2>
<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 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>
<p>
If you want to replicate the build of swig.exe that comes with the download, follow the MinGW instructions below.
This is not necessary to use the supplied swig.exe.
This information is provided for those that want to modify the SWIG source code in a Windows environment.
The SWIG distribution provides a pre-built swig.exe and so it is not necessary for users to build the SWIG executable.
However, this section is provided for those that want to modify the SWIG source code in a Windows environment.
Normally this is not needed, so most people will want to ignore this section.
</p>
<H4><a name="Windows_cmake">3.3.1.1 Building swig.exe using CMake</a></H4>
<p>
There are various ways to build the SWIG executable including <a href="https://cmake.org/">CMake</a> which is able to generate project files for building with Visual Studio.
SWIG can also be compiled and run using <a href="https://www.msys2.org/">MSYS2</a>, <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a>, all of which provide a Unix like front end to Windows and comes free with the gcc C/C++ compiler.
</p>
<H3><a name="Windows_cmake">3.3.1 Building swig.exe using CMake</a></H3>
<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
SWIG can 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>.
For fully working build steps always check the Continuous Integration (CI) 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.
Install Nuget from <a href="https://www.nuget.org/downloads">https://www.nuget.org/downloads</a> (v6.0.0 is used in this example, and installed to <tt>C:\Tools</tt>). Nuget is the package manager
for .NET, but allows us to easily install <a href="https://cmake.org/">CMake</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>
Install <a href="https://www.nuget.org/packages/CMake-win64/">CMake-win64 Nuget package</a> 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
Install the <a href="https://www.nuget.org/packages/bison/">Bison Nuget package</a> using the following command: <pre>C:\Tools\nuget install Bison -Version 3.7.4 -OutputDirectory C:\Tools\bison</pre>
Alternatively download Bison from <a href="https://sourceforge.net/projects/winflexbison/files/">https://sourceforge.net/projects/winflexbison/files/</a> (Bison 3.7.4 is used in this example)
and save to a folder e.g. <tt>C:\Tools\Bison</tt>
</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>.
Alternatively, use <tt>WITH_PCRE</tt> option to disable PCRE support if you are sure not to need it.
Unfortunately, PCRE2 is not yet available on Nuget. Instead we will use CMake to build and install <a href="https://www.pcre.org/">PCRE2</a> to <tt>C:\Tools\pcre2</tt> using the following commands:
<div class="shell"><pre>
cd C:\
SET PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;%PATH%
git clone https://github.com/PhilipHazel/pcre2.git
cd pcre2
cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_INSTALL_PREFIX=C:/Tools/pcre2 -S . -B build
cmake --build build --config Release --target install
</pre></div>
Alternatively, set <tt>WITH_PCRE=OFF</tt> to disable PCRE2 support if you are sure you do not require it.
</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
In this example we are assuming the source code is available at <tt>C:\swig</tt>
</li>
</ol>
<li>
<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.
Now we have all the required dependencies we can build SWIG using the commands below. We are assuming Visual Studio 2019 is installed. For other versions of Visual Studio change <tt>"Visual Studio 16 2019 -A x64"</tt> to the relevant
<a href="https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#visual-studio-generators">Visual Studio Generator</a> and
architecture. 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 the <tt>C:/swig/install2/bin</tt> folder.
</p>
<div class="shell">
<pre>
<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 PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;C:\Tools\bison\Bison.3.7.4\bin;%PATH%
SET PCRE_ROOT=C:/Tools/pcre2
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
cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_INSTALL_PREFIX="%CD:\=/%/install2" -DCMAKE_C_FLAGS="/DPCRE2_STATIC" ^
-DCMAKE_CXX_FLAGS="/DPCRE2_STATIC" -DPCRE2_INCLUDE_DIR=%PCRE_ROOT%/include -DPCRE2_LIBRARY=%PCRE_ROOT%/lib/pcre2-8-static.lib -S . -B build
cmake --build build --config Release --target install
REM to test the exe
cd /Release
cd install2/bin
swig.exe -help
</pre>
</div>
</pre></div>
</li>
</ol>
<p>
In addition to Release builds you can create a Debug build using:
</p>
<div class="shell">
<pre>cmake --build . --config Debug</pre>
<pre>cmake --build 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:
A Visual Studio solution file should be generated named swig.sln. This can be opened and debugged by running the swig project and setting <tt>Properties &gt; Debugging &gt; Command Arguments</tt>. 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 MSYS2</a></H4>
<H3><a name="Windows_msys2">3.3.2 Building swig.exe using MSYS2</a></H3>
<p>
@ -311,7 +312,7 @@ Install the packages needed to build swig:<br>
<div class="shell">
<pre>
pacman -S git autoconf automake bison gcc make pcre-devel
pacman -S git autoconf automake bison gcc make pcre2-devel
</pre>
</div>
@ -350,7 +351,7 @@ make install
</pre>
</div>
<H4><a name="Windows_mingw_msys">3.3.1.3 Building swig.exe using MinGW and MSYS</a></H4>
<H3><a name="Windows_mingw_msys">3.3.3 Building swig.exe using MinGW and MSYS</a></H3>
<p>
@ -445,10 +446,10 @@ the autotools will fail miserably on those.
</li>
<li>
The PCRE third party library needs to be built next.
Download the latest PCRE source tarball, such as <tt>pcre-8.10.tar.bz2</tt>, from
<a href=http://www.pcre.org>PCRE</a> and place in the <tt>/usr/src/swig</tt> directory.
Build PCRE as a static library using the Tools/pcre-build.sh script as follows:
The PCRE2 third party library needs to be built next.
Download the latest PCRE2 source tarball, such as <tt>pcre2-10.39.tar.bz2</tt>, from
<a href=http://www.pcre.org>www.pcre.org</a> and place in the <tt>/usr/src/swig</tt> directory.
Build PCRE2 as a static library using the Tools/pcre-build.sh script as follows:
<div class="shell"><pre>
cd /usr/src/swig
@ -468,7 +469,7 @@ make
</ol>
<H4><a name="Windows_cygwin">3.3.1.4 Building swig.exe using Cygwin</a></H4>
<H3><a name="Windows_cygwin">3.3.4 Building swig.exe using Cygwin</a></H3>
<p>
@ -480,7 +481,7 @@ These files are generated using the <tt>autogen.sh</tt> script and will only nee
</p>
<H3><a name="Windows_examples_cygwin">3.3.2 Running the examples on Windows using Cygwin</a></H3>
<H4><a name="Windows_examples_cygwin">3.3.4.1 Running the examples on Windows using Cygwin</a></H4>
<p>

10
Doc/Manual/makechap.py
View File

@ -11,10 +11,8 @@
# then change the heading link name to something that does not look like an
# autogenerated link name.
###############################################################################
import sys
import re
import string
###############################################################################
# Functions
@ -58,11 +56,11 @@ def getheadingtext(m, s):
###############################################################################
if len(sys.argv) != 3:
print "usage: makechap.py filename num"
print("usage: makechap.py filename num")
sys.exit(1)
filename = sys.argv[1]
filenamebase = string.split(filename,".")[0]
filenamebase = filename.split(".")[0]
num = int(sys.argv[2])
section = 0
@ -223,6 +221,6 @@ open(filename,"w").write(data)
# Print the TOC data to stdout correcting the anchor links for external referencing
index = index.replace("<li><a href=\"#","<li><a href=\"%s#" % filename)
print """<h3><a href="%s#%s">%d %s</a></h3>\n""" % (filename,filenamebase,num,name)
print index
print("""<h3><a href="%s#%s">%d %s</a></h3>\n""" % (filename,filenamebase,num,name))
print(index)

12
Doc/Manual/maketoc.py
View File

@ -5,7 +5,7 @@ import os
chs = open("chapters").readlines()
f = open("Contents.html","w")
print >>f, """
f.write("""
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
@ -17,7 +17,8 @@ print >>f, """
<H1><a name="Contents"></a>SWIG Users Manual</H1>
<p>
"""
""")
f.close()
@ -25,15 +26,16 @@ num = 1
for c in chs:
c = c.strip()
print "Processing %s" % c
print("Processing " + c)
if c:
os.system("python makechap.py %s %d >> Contents.html" % (c,num))
num += 1
f = open("Contents.html","a")
print >>f, """
f.write("""
</BODY>
</HTML>
"""
""")

53
Examples/Makefile.in
View File

@ -46,8 +46,8 @@ TARGET =
CC = @CC@
CXX = @CXX@
CPPFLAGS = $(SRCDIR_INCLUDE)
CFLAGS = @PLATCFLAGS@
CXXFLAGS = @BOOST_CPPFLAGS@ @PLATCXXFLAGS@
CFLAGS = @PLATCFLAGS@ $(EXTRA_CFLAGS)
CXXFLAGS = @BOOST_CPPFLAGS@ @PLATCXXFLAGS@ $(EXTRA_CXXFLAGS)
LDFLAGS =
prefix = @prefix@
exec_prefix= @exec_prefix@
@ -191,7 +191,7 @@ tcl: $(SRCDIR_SRCS)
$(TCLLDSHARED) $(CFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(TCL_DLNK) $(LIBS) -o $(LIBPREFIX)$(TARGET)$(TCL_SO) $(TCL_LINK)
# -----------------------------------------------------------
# Build a Tcl7.5 dynamic loadable module for C++
# Build a Tcl dynamic loadable module for C++
# -----------------------------------------------------------
tcl_cpp: $(SRCDIR_SRCS)
@ -309,7 +309,7 @@ perl5_clean:
PYTHON_FLAGS =
# Make sure these locate your Python installation
ifeq (,$(PY3))
ifneq (,$(PY2))
PYTHON_INCLUDE= $(DEFS) @PYINCLUDE@
PYTHON_LIB = @PYLIB@
PYTHON = @PYTHON@ $(PYTHON_FLAGS)
@ -320,7 +320,7 @@ else
endif
# Extra Python specific linking options
ifeq (,$(PY3))
ifneq (,$(PY2))
PYTHON_DLNK = @PYTHONDYNAMICLINKING@
PYTHON_LINK = @PYLINK@
else
@ -329,13 +329,6 @@ else
endif
PYTHON_SO = @PYTHON_SO@
# SWIG option for Python3
ifeq (,$(PY3))
SWIGOPTPY3 =
else
SWIGOPTPY3 = -py3
endif
PYCODESTYLE = @PYCODESTYLE@
PYCODESTYLE_FLAGS = --ignore=E252,E30,E402,E501,E731,W291,W391
@ -344,7 +337,7 @@ PYCODESTYLE_FLAGS = --ignore=E252,E30,E402,E501,E731,W291,W391
# ----------------------------------------------------------------
python: $(SRCDIR_SRCS)
$(SWIG) -python $(SWIGOPTPY3) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(SWIG) -python $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(CC) -c $(CCSHARED) $(CPPFLAGS) $(CFLAGS) $(ISRCS) $(SRCDIR_SRCS) $(INCLUDES) $(PYTHON_INCLUDE)
$(LDSHARED) $(CFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(PYTHON_DLNK) $(LIBS) -o $(LIBPREFIX)_$(TARGET)$(PYTHON_SO)
@ -353,7 +346,7 @@ python: $(SRCDIR_SRCS)
# -----------------------------------------------------------------
python_cpp: $(SRCDIR_SRCS)
$(SWIG) -python $(SWIGOPTPY3) -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(SWIG) -python -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES) $(PYTHON_INCLUDE)
$(CXXSHARED) $(CXXFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(PYTHON_DLNK) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)_$(TARGET)$(PYTHON_SO)
@ -369,12 +362,12 @@ TKINTER =
PYTHON_LIBOPTS = $(PYTHON_LINK) @LIBS@ $(TKINTER) $(SYSLIBS)
python_static: $(SRCDIR_SRCS)
$(SWIG) -python $(SWIGOPTPY3) -lembed.i $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(SWIG) -python -lembed.i $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) @LINKFORSHARED@ $(ISRCS) $(SRCDIR_SRCS) $(INCLUDES) \
$(PYTHON_INCLUDE) $(LIBS) -L$(PYTHON_LIB) $(PYTHON_LIBOPTS) -o $(TARGET)
python_static_cpp: $(SRCDIR_SRCS)
$(SWIG) -python $(SWIGOPTPY3) -c++ -lembed.i $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(SWIG) -python -c++ -lembed.i $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES) \
$(PYTHON_INCLUDE) $(LIBS) -L$(PYTHON_LIB) $(PYTHON_LIBOPTS) -o $(TARGET)
@ -744,9 +737,9 @@ ifeq (node, $(ENGINE))
endif
ifeq (jsc, $(ENGINE))
@if [ "@JSCOREVERSION@" != "" ]; then \
echo "@JSCOREVERSION@"; \
echo "JavaScriptCore: @JSCOREVERSION@"; \
else \
echo "Unknown JavascriptCore version."; \
echo "Unknown JavaScriptCore version."; \
fi
endif
ifeq (v8, $(ENGINE))
@ -1078,7 +1071,7 @@ php_cpp: $(SRCDIR_SRCS)
# -----------------------------------------------------------------
php_run:
$(RUNTOOL) $(PHP) -n -d extension_dir=. -d extension=$(PHP_EXTENSION) -d display_errors=stderr -r 'set_error_handler(function($$n,$$s,$$f,$$l){if($$f!==Null){print$$f;if($$l!==Null)print":$$l";print": ";}print"$$s\n";exit(1);});include($$argv[1]);' $(PHP_SCRIPT) $(RUNPIPE)
$(RUNTOOL) $(PHP) -n -d extension_dir=. -d extension=$(PHP_EXTENSION) -d display_errors=stderr -r 'set_error_handler(function($$n,$$s,$$f,$$l){if($$f!==Null){print$$f;if($$l!==Null)print":$$l";print": ";}print"$$s\n";exit(1);});if(strlen($$argv[1]))include($$argv[1]);' '$(PHP_SCRIPT)' $(RUNPIPE)
# -----------------------------------------------------------------
# Version display
@ -1423,6 +1416,7 @@ c_clean:
SCILAB = @SCILAB@
SCILAB_INC= @SCILABINCLUDE@
SCILAB_OPT = @SCILABOPT@
SCILAB_VERSION = @SCILAB_VERSION@
SCILAB_LIBPREFIX = lib
# ----------------------------------------------------------------
@ -1455,7 +1449,7 @@ scilab_run:
# -----------------------------------------------------------------
scilab_version:
echo `$(SCILAB) -version | head -1`
echo `$(SCILAB) -nwni -version | head -1`
# -----------------------------------------------------------------
# Cleaning the scilab examples
@ -1537,6 +1531,10 @@ go: $(SRCDIR_SRCS) $(GOPATHPARENTDIR)/go.mod
CGO_LDFLAGS="$(LDFLAGS) -lm"; \
export CGO_LDFLAGS; \
(cd $(GOPATHDIR)/ && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o $(GOPACKAGE)); \
stat=$$?; \
if test $$stat != 0; then \
exit $$stat; \
fi; \
if $(GOGCC); then \
cp $(GOPATHDIR)/$(GOPACKAGE) $(GOPATHDIR)/$(GOPACKAGE:.a=.gox); \
fi; \
@ -1545,6 +1543,10 @@ go: $(SRCDIR_SRCS) $(GOPATHPARENTDIR)/go.mod
mkdir gopath/$(GOMOD)/src/swigtests/$(INTERFACE:.i=) 2>/dev/null || true; \
cp $(GOPATHDIR)/* gopath/$(GOMOD)/src/swigtests/$(INTERFACE:.i=)/; \
(cd gopath/$(GOMOD)/src/runme && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o runme $(RUNME).go); \
stat=$$?; \
if test $$stat != 0; then \
exit $$stat; \
fi; \
cp gopath/$(GOMOD)/src/runme/runme $(RUNME); \
fi
@ -1588,6 +1590,10 @@ go_cpp: $(SRCDIR_SRCS) $(GOPATHPARENTDIR)/go.mod
CGO_LDFLAGS="$(LDFLAGS) -lm"; \
export CGO_LDFLAGS; \
(cd $(GOPATHDIR) && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o $(GOPACKAGE)); \
stat=$$?; \
if test $$stat != 0; then \
exit $$stat; \
fi; \
if $(GOGCC); then \
cp $(GOPATHDIR)/$(GOPACKAGE) $(GOPATHDIR)/$(GOPACKAGE:.a=.gox); \
fi; \
@ -1596,6 +1602,10 @@ go_cpp: $(SRCDIR_SRCS) $(GOPATHPARENTDIR)/go.mod
mkdir gopath/$(GOMOD)/src/swigtests/$(INTERFACE:.i=) 2>/dev/null || true; \
cp $(GOPATHDIR)/* gopath/$(GOMOD)/src/swigtests/$(INTERFACE:.i=)/; \
(cd gopath/$(GOMOD)/src/runme && $(COMPILETOOL) $(GO) build `if $(GOGCC); then echo -compiler=gccgo; fi` -o runme $(RUNME).go); \
stat=$$?; \
if test $$stat != 0; then \
exit $$stat; \
fi; \
cp gopath/$(GOMOD)/src/runme/runme $(RUNME); \
fi
@ -1682,8 +1692,7 @@ d_run:
# -----------------------------------------------------------------
d_version:
# Needs improvement!
echo D version guess - $(D_VERSION)
($(DCOMPILER) --version 2> /dev/null || $(DCOMPILER)) | head -n 3
# -----------------------------------------------------------------
# Clean the D examples

1
Examples/go/check.list
View File

@ -12,3 +12,4 @@ reference
simple
template
variables
goin

18
Examples/go/goin/Makefile Normal file
View File

@ -0,0 +1,18 @@
TOP = ../..
SWIGEXE = $(TOP)/../swig
SWIG_LIB_DIR = $(TOP)/../$(TOP_BUILDDIR_TO_TOP_SRCDIR)Lib
CXXSRCS =
TARGET = example
INTERFACE = example.i
SWIGOPT =
check: build
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
build:
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' CXXSRCS='$(CXXSRCS)' \
SWIG_LIB_DIR='$(SWIG_LIB_DIR)' SWIGEXE='$(SWIGEXE)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_cpp
clean:
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' INTERFACE='$(INTERFACE)' go_clean

106
Examples/go/goin/example.i Normal file
View File

@ -0,0 +1,106 @@
%module(directors="1") example
%inline %{
// Helper functions for converting string arrays
#include <stdlib.h>
void *alloc_ptr_array(unsigned int len)
{
return calloc(len, sizeof(void *));
}
void set_ptr_array(void *ain, unsigned int pos, void *val)
{
void **a = (void **) ain;
a[pos] = val;
}
void *get_ptr_array(void *ain, unsigned int pos)
{
void **a = (void **) ain;
return a[pos];
}
void free_ptr_array(void *ain)
{
void **a = (void **) ain;
unsigned int i;
if (!a)
return;
for (i = 0; a[i]; i++) {
free(a[i]);
}
free(a);
}
char *uintptr_to_string(void *in)
{
return (char *) in;
}
void *string_to_uintptr(char *in)
{
return strdup(in);
}
%}
// These typemaps convert between an array of strings in Go and a
// const char** that is NULL terminated in C++.
%typemap(gotype) (const char * const *) "[]string"
%typemap(imtype) (const char * const *) "uintptr"
%typemap(goin) (const char * const *) {
if $input == nil || len($input) == 0 {
$result = 0
} else {
$result = Alloc_ptr_array(uint(len($input) + 1))
defer func() {
Free_ptr_array($result)
}()
var i uint
for i = 0; i < uint(len($input)); i++ {
Set_ptr_array($result, i, String_to_uintptr($input[i]))
}
}
}
%typemap(in) (const char * const *) {
$1 = (char **) $input;
}
%typemap(godirectorin) (const char * const *) {
if ($input == 0) {
$result = nil
} else {
var i uint
for i = 0; ; i++ {
var v uintptr = Get_ptr_array($input, i)
if v == 0 {
break
}
}
if i == 0 {
$result = nil
} else {
$result = make([]string, i)
for i = 0; ; i++ {
var v uintptr = Get_ptr_array($input, i)
if v == 0 {
break
}
$result[i] = Uintptr_to_string(v)
}
}
}
}
%feature("director") callbacks;
%inline %{
class callbacks {
public:
virtual bool call1(int v, const char * const *strarray);
virtual ~callbacks() {}
};
bool check1(callbacks *c, int v, const char * const *strarray) {
return c->call1(v, strarray);
}
bool callbacks::call1(int v, const char * const *strarray) {
return false;
}
%}

26
Examples/go/goin/index.html Normal file
View File

@ -0,0 +1,26 @@
<html>
<head>
<title>SWIG:Examples:go:going</title>
</head>
<body bgcolor="#ffffff">
<tt>SWIG/Examples/go/goin/</tt>
<hr>
<H2>Example of using goin and godirectorin</H2>
<p>
This example converts between a Go []string and a "const char * const *"
in C/C++. It does this for a director and for a normal call.
<p>
<ul>
<li><a href="example.i">example.i</a>. SWIG interface file.
<li><a href="runme.go">runme.go</a>. Sample Go program.
</ul>
<hr>
</body>
</html>

38
Examples/go/goin/runme.go Normal file
View File

@ -0,0 +1,38 @@
package main
import (
"fmt"
"swigtests/example"
)
type mycallbacks struct {
example.Callbacks
}
var tststrs = []string{ "A", "BCD", "EFGH" }
var tstint int = 5
func (v *mycallbacks) Call1(val int, strarray []string) bool {
var rv bool = true
for i, s := range strarray {
fmt.Printf("%d: %s\n", i, s)
if s != tststrs[i] {
fmt.Printf(" ***Mismatch, expected %s\n", tststrs[i])
rv = false
}
}
if val != tstint {
rv = false
}
return rv
}
func main() {
cbs := &mycallbacks{}
cbs.Callbacks = example.NewDirectorCallbacks(cbs)
worked := example.Check1(cbs, tstint, tststrs)
if !worked {
panic("Data mismatch")
}
}

1
Examples/go/index.html
View File

@ -24,6 +24,7 @@ certain C declarations are turned into constants.
<li><a href="callback/index.html">callback</a>. C++ callbacks using directors.
<li><a href="extend/index.html">extend</a>. Polymorphism using directors.
<li><a href="director/index.html">director</a>. Example how to utilize the director feature.
<li><a href="goin/index.html">director</a>. Example how to use goin and godirectorin.
</ul>
<h2>Compilation Issues</h2>

2
Examples/guile/multimap/example.i
View File

@ -78,7 +78,7 @@ extern int count(char *bytes, int len, char c);
%typemap(argout) (char *str, int len) {
SWIG_APPEND_VALUE(scm_from_locale_stringn($1,$2));
if ($1) SWIG_free($1);
SWIG_free($1);
}
extern void capitalize(char *str, int len);

4
Examples/javascript/nspace/example.h
View File

@ -1,5 +1,5 @@
#ifndef _example_guardian_
#define _example_guardian_
#ifndef EXAMPLE_H
#define EXAMPLE_H
int module_function() { return 7; }
int module_variable = 9;

4
Examples/lua/arrays/example.i
View File

@ -9,12 +9,12 @@ See the lua code for how they are called
%include <carrays.i> // array helpers
// this declares a batch of function for manipulating C integer arrays
// this declares a batch of functions for manipulating C integer arrays
%array_functions(int,int)
// this adds some lua code directly into the module
// warning: you need the example. prefix if you want it added into the module
// admittedly this code is a bit tedious, but its a one off effort
// admittedly this code is a bit tedious, but it's a one off effort
%luacode {
function example.sort_int2(t)
-- local len=table.maxn(t) -- the len - maxn deprecated in 5.3

2
Examples/lua/constants/runme.lua
View File

@ -30,6 +30,6 @@ function checkfail(fn)
end
-- these should fail
-- example.EXTERN is a nil value, so concatentatin will make it fail
-- example.EXTERN is a nil value, so concatenation will make it fail
checkfail(function() print("EXTERN = "..example.EXTERN) end)
checkfail(function() print("FOO = "..example.FOO) end)

2
Examples/lua/embed/embed.c
View File

@ -23,7 +23,7 @@ We will be using the luaL_dostring()/lua_dostring() function to call into lua
#define lua_open luaL_newstate
#endif
/* the SWIG wrappered library */
/* the SWIG wrapped library */
extern int luaopen_example(lua_State*L);
/* a really simple way of calling lua from C

10
Examples/lua/embed2/embed2.c
View File

@ -41,7 +41,7 @@ extern int luaopen_example(lua_State*L);
/* This is an example of how to call the Lua function
int add(int,int)
its very tedious, but gives you an idea of the issues involved.
it's very tedious, but gives you an idea of the issues involved.
(look below for a better idea)
*/
int call_add(lua_State *L,int a,int b,int* res) {
@ -75,7 +75,7 @@ int call_add(lua_State *L,int a,int b,int* res) {
return 1;
}
/* This is a variargs call function for calling from C into Lua.
/* This is a varargs call function for calling from C into Lua.
Original Code from Programming in Lua (PIL) by Roberto Ierusalimschy
ISBN 85-903798-1-7
http://www.lua.org/pil/25.3.html
@ -186,7 +186,7 @@ int main(int argc,char* argv[]) {
luaopen_base(L);
luaopen_string(L);
luaopen_math(L);
printf("[C] now loading the SWIG wrappered library\n");
printf("[C] now loading the SWIG wrapped library\n");
luaopen_example(L);
printf("[C] all looks ok\n");
printf("\n");
@ -226,8 +226,8 @@ int main(int argc,char* argv[]) {
printf("\n");
printf("[C] Note: no protection if you mess up the va-args, this is C\n");
printf("\n");
printf("[C] Finally we will call the wrappered gcd function gdc(6,9):\n");
printf("[C] This will pass the values to Lua, then call the wrappered function\n");
printf("[C] Finally we will call the wrapped gcd function gdc(6,9):\n");
printf("[C] This will pass the values to Lua, then call the wrapped function\n");
printf(" Which will get the values from Lua, call the C code \n");
printf(" and return the value to Lua and eventually back to C\n");
printf("[C] Certainly not the best way to do it :-)\n");

4
Examples/lua/embed3/embed3.cpp
View File

@ -61,7 +61,7 @@ bool push_pointer(lua_State*L, void* ptr, const char* type_name, int owned = 0)
/* This is an example of how to call the Lua function
void onEvent(Event e)
its very tedious, but gives you an idea of the issues involed.
it's very tedious, but gives you an idea of the issues involved.
*/
int call_onEvent(lua_State *L, Event e) {
int top;
@ -105,7 +105,7 @@ int main(int argc, char* argv[]) {
/* this code will pass a pointer into lua, but C++ still owns the object
this is a little tedious, to do, but let's do it
we need to pass the pointer (obviously), the type name
and a flag which states if Lua should delete the pointer once its finished with it
and a flag which states if Lua should delete the pointer once it's finished with it
The type name is a class name string which is registered with SWIG
(normally, just look in the wrapper file to get this)
in this case we don't want Lua to delete the pointer so the ownership flag is 0

4
Examples/lua/nspace/example.h
View File

@ -1,5 +1,5 @@
#ifndef _example_guardian_
#define _example_guardian_
#ifndef EXAMPLE_H
#define EXAMPLE_H
int module_function() { return 7; }
int module_variable = 9;

12
Examples/octave/module_load/runme.m
View File

@ -19,7 +19,8 @@ clear all
# load module in a function globally before base context
clear all;
function testme_1
assert(exist("swigexample") == 3);
% exist("swigexample") returns 1 (variable) in octave >= 4.4 < 6 but 3 (.oct file) in octave >= 6
assert(exist("swigexample"));
swigexample;
assert(isglobal("swigexample"));
assert(cvar.ivar == ifunc);
@ -32,7 +33,8 @@ assert(isglobal("swigexample"));
assert(cvar.ivar == ifunc);
clear all
function testme_2
assert(exist("swigexample") == 3);
% exist("swigexample") returns 1 (variable) in octave >= 4.4 < 6 but 3 (.oct file) in octave >= 6
assert(exist("swigexample"));
swigexample;
assert(isglobal("swigexample"));
assert(cvar.ivar == ifunc);
@ -52,7 +54,8 @@ swigexample;
assert(isglobal("swigexample"));
assert(cvar.ivar == ifunc);
function testme_3
assert(exist("swigexample") == 3);
% exist("swigexample") returns 1 (variable) in octave >= 4.4 < 6 but 3 (.oct file) in octave >= 6
assert(exist("swigexample"));
swigexample;
assert(isglobal("swigexample"));
assert(cvar.ivar == ifunc);
@ -65,7 +68,8 @@ swigexample;
assert(isglobal("swigexample"));
assert(cvar.ivar == ifunc);
function testme_4
assert(exist("swigexample") == 3);
% exist("swigexample") returns 1 (variable) in octave >= 4.4 < 6 but 3 (.oct file) in octave >= 6
assert(exist("swigexample"));
swigexample;
assert(isglobal("swigexample"));
assert(cvar.ivar == ifunc);

6
Examples/octave/operator/@swig_ref/horzcat.m Normal file
View File

@ -0,0 +1,6 @@
% test octaves concatenation operator
function ret=horzcat(a, b)
% return the concatenation of two ComplexVal values as a cell array.
% (not really useful but it tests the concatenation of swig_ref objects)
ret={a, b};
end

8
Examples/octave/operator/runme.m
View File

@ -3,6 +3,9 @@ if exist("crash_dumps_octave_core", "builtin")
crash_dumps_octave_core(0);
endif
scriptDir = fileparts(mfilename('fullpath'));
addpath(scriptDir);
# Operator overloading example
swigexample
@ -42,3 +45,8 @@ if swig_octave_prereq(3,8,0)
printf("conj(a) = %s\n", disp(conj(a)));
printf("exp(a) = %s\n", disp(exp(a)));
endif
# concatenation operator, note: calls @swig_ref/horzcat.m
# g = [a, b, c];
# printf("g = %s\n",disp(g));
# Above temporarily removed as broken in octave-7.2.0, see https://github.com/swig/swig/issues/2353

2
Examples/perl5/multimap/example.i
View File

@ -15,7 +15,7 @@ extern int squareCubed (int n, int *OUTPUT);
extern int gcd(int x, int y);
%typemap(arginit) (int argc, char *argv[]) "$2 = 0;";
%typemap(arginit) (int argc, char *argv[]) "$2 = 0;"
%typemap(in) (int argc, char *argv[]) {
AV *tempav;

1
Examples/php/disown/example.cxx
View File

@ -39,7 +39,6 @@ double Square::perimeter(void) {
}
ShapeContainer::~ShapeContainer() {
iterator i=shapes.begin();
for( iterator i = shapes.begin(); i != shapes.end(); ++i ) {
delete *i;
}

8
Examples/python/import/runme.py
View File

@ -84,14 +84,14 @@ x.B()
print("\nTesting some dynamic casts\n")
x = d.toBase()
y = foo.Foo_fromBase(x)
y = foo.Foo.fromBase(x)
print(" Spam -> Base -> Foo : {} swig".format("bad" if y else "good"))
y = bar.Bar_fromBase(x)
y = bar.Bar.fromBase(x)
print(" Spam -> Base -> Bar : {} swig".format("good" if y else "bad"))
y = spam.Spam_fromBase(x)
y = spam.Spam.fromBase(x)
print(" Spam -> Base -> Spam : {} swig".format("good" if y else "bad"))
y = spam.Spam_fromBase(b)
y = spam.Spam.fromBase(b)
print(" Foo -> Spam : {} swig".format("bad" if y else "good"))

2
Examples/python/import_packages/from_init1/Makefile
View File

@ -1,7 +1,7 @@
TOP = ../../..
LIBS =
ifeq (,$(PY3))
ifneq (,$(PY2))
PKG1DIR = "py2"
else
PKG1DIR = "py3"

2
Examples/python/import_packages/from_init1/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))

2
Examples/python/import_packages/from_init2/Makefile
View File

@ -1,7 +1,7 @@
TOP = ../../..
LIBS =
ifeq (,$(PY3))
ifneq (,$(PY2))
PKG1DIR = "py2"
else
PKG1DIR = "py3"

2
Examples/python/import_packages/from_init2/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))

2
Examples/python/import_packages/from_init3/Makefile
View File

@ -1,7 +1,7 @@
TOP = ../../..
LIBS =
ifeq (,$(PY3))
ifneq (,$(PY2))
PKG1DIR = "py2"
else
PKG1DIR = "py3"

2
Examples/python/import_packages/from_init3/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))

8
Examples/python/import_packages/module_is_init/runme.py
View File

@ -5,14 +5,6 @@ import sys
testname = os.path.basename(os.path.dirname(os.path.abspath(__file__)))
print("Testing " + testname + " - module renamed as __init__.py")
if sys.version_info >= (3, 0, 0) and sys.version_info < (3, 3, 0):
print(" Not importing as Python version is >= 3.0 and < 3.3")
# Package detection does not work in these versions.
# Can be fixed by using this in the interface file:
# %module(moduleimport="from . import $module") foo # without -builtin
# %module(moduleimport="from .$module import *") foo # with -builtin
sys.exit(0)
import pkg1
print(" Finished importing pkg1")

2
Examples/python/import_packages/namespace_pkg/nonpkg.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print(" Finished running: " + commandline)

2
Examples/python/import_packages/namespace_pkg/normal.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print(" Finished running: " + commandline)

2
Examples/python/import_packages/namespace_pkg/nstest.py
View File

@ -6,7 +6,7 @@ import zipfile
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print(" Finished running: " + commandline)

2
Examples/python/import_packages/namespace_pkg/split.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print(" Finished running: " + commandline)

2
Examples/python/import_packages/namespace_pkg/zipsplit.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print(" Finished running: " + commandline)

2
Examples/python/import_packages/relativeimport1/Makefile
View File

@ -1,7 +1,7 @@
TOP = ../../..
LIBS =
ifeq (,$(PY3))
ifneq (,$(PY2))
PKG1DIR = "py2"
else
PKG1DIR = "py3"

2
Examples/python/import_packages/relativeimport1/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))

2
Examples/python/import_packages/relativeimport2/Makefile
View File

@ -1,7 +1,7 @@
TOP = ../../..
LIBS =
ifeq (,$(PY3))
ifneq (,$(PY2))
PKG1DIR = "py2"
else
PKG1DIR = "py3"

2
Examples/python/import_packages/relativeimport2/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))

2
Examples/python/import_packages/relativeimport3/Makefile
View File

@ -1,7 +1,7 @@
TOP = ../../..
LIBS =
ifeq (,$(PY3))
ifneq (,$(PY2))
PKG1DIR = "py2"
else
PKG1DIR = "py3"

2
Examples/python/import_packages/relativeimport3/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))

2
Examples/python/import_packages/same_modnames1/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))

2
Examples/python/import_packages/same_modnames2/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))

4
Examples/python/import_packages/split_modules/vanilla/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))
@ -15,7 +15,7 @@ import pkg1.foo
print(" Finished importing pkg1.foo")
if not(pkg1.foo.count() == 3):
if not pkg1.foo.count() == 3:
raise RuntimeError("test failed")
commandline = sys.executable + " -m pkg1.foo"

4
Examples/python/import_packages/split_modules/vanilla_split/runme.py
View File

@ -4,7 +4,7 @@ import sys
def run_except_on_windows(commandline, env=None):
if os.name != "nt" and sys.platform != "cygwin":
# Strange failures on windows/cygin/mingw
# Strange failures on windows/cygwin/mingw
subprocess.check_call(commandline, env=env, shell=True)
print((" Finished running: " + commandline))
@ -15,7 +15,7 @@ import pkg1.foo
print(" Finished importing pkg1.foo")
if not(pkg1.foo.count() == 3):
if not pkg1.foo.count() == 3:
raise RuntimeError("test failed")
commandline = sys.executable + " -m pkg1.foo"

8
Examples/python/import_template/runme.py
View File

@ -84,14 +84,14 @@ x.B()
print("\nTesting some dynamic casts\n")
x = d.toBase()
y = foo.intFoo_fromBase(x)
y = foo.intFoo.fromBase(x)
print(" Spam -> Base -> Foo : {} swig".format("bad" if y else "good"))
y = bar.intBar_fromBase(x)
y = bar.intBar.fromBase(x)
print(" Spam -> Base -> Bar : {} swig".format("good" if y else "bad"))
y = spam.intSpam_fromBase(x)
y = spam.intSpam.fromBase(x)
print(" Spam -> Base -> Spam : {} swig".format("good" if y else "bad"))
y = spam.intSpam_fromBase(b)
y = spam.intSpam.fromBase(b)
print(" Foo -> Spam : {} swig".format("bad" if y else "good"))

2
Examples/python/index.html
View File

@ -88,7 +88,7 @@ to look at the <a href="http://www.python.org/sigs/distutils-sig/">distutils</a>
<h2>Compatibility</h2>
For Python 3, set the environment variable <tt>PY3=1</tt>.
For Python 2, set the environment variable <tt>PY2=1</tt>.
<p>
Your mileage may vary. If you experience a problem, please let us know by

8
Examples/python/multimap/example.i
View File

@ -39,12 +39,14 @@ extern int gcd(int x, int y);
%#if PY_VERSION_HEX >= 0x03000000
{
PyObject *utf8str = PyUnicode_AsUTF8String(s);
const char *cstr;
const char *strtmp = 0;
if (!utf8str) {
SWIG_fail;
}
cstr = PyBytes_AsString(utf8str);
$2[i] = strdup(cstr);
strtmp = PyBytes_AsString(utf8str);
$2[i] = (char *)malloc(strlen(strtmp) + 1);
if ($2[i])
strcpy($2[i], strtmp);
Py_DECREF(utf8str);
}
%#else

4
Examples/python/variables/runme.py
View File

@ -2,6 +2,8 @@
import example
print("Variables = " + str(example.cvar))
# Try to set the values of some global variables
example.cvar.ivar = 42
@ -22,7 +24,7 @@ example.cvar.name = "Bill"
# Now print out the values of the variables
print("Variables (values printed from Python)")
print("\nVariables (values printed from Python)")
print("ivar = %s" % example.cvar.ivar)
print("svar = %s" % example.cvar.svar)

2
Examples/ruby/exceptproxy/example.i
View File

@ -16,7 +16,7 @@
/* The EmptyError doesn't appear in a throw declaration, and hence
we need to tell SWIG that the dequeue method throws it. This can
now be done via the %catchs feature. */
now be done via the %catches feature. */
%catches(FullError) *::enqueue;
%catches(EmptyError) *::dequeue();

6
Examples/ruby/free_function/example.h
View File

@ -1,5 +1,5 @@
#ifndef _EXAMPLE_H_
#define _EXAMPLE_H_
#ifndef EXAMPLE_H
#define EXAMPLE_H
#include <vector>
#include <string>
@ -46,4 +46,4 @@ public:
Animal* get_animal(size_t i) const;
};
#endif /*_EXAMPLE_H_*/
#endif /* EXAMPLE_H */

6
Examples/ruby/mark_function/example.h
View File

@ -1,5 +1,5 @@
#ifndef _EXAMPLE_H_
#define _EXAMPLE_H_
#ifndef EXAMPLE_H
#define EXAMPLE_H
#include <vector>
#include <string>
@ -46,4 +46,4 @@ public:
Animal* get_animal(size_t i) const;
};
#endif /*_EXAMPLE_H_*/
#endif /* EXAMPLE_H */

2
Examples/tcl/multimap/example.i
View File

@ -14,7 +14,7 @@ extern int squareCubed (int n, int *OUTPUT);
extern int gcd(int x, int y);
%typemap(arginit) (int argc, char *argv[]) "$2 = 0;";
%typemap(arginit) (int argc, char *argv[]) "$2 = 0;"
%typemap(in) (int argc, char *argv[]) {
Tcl_Obj **listobjv = 0;

20
Examples/test-suite/abstract_basecast.i Normal file
View File

@ -0,0 +1,20 @@
%module abstract_basecast
%inline %{
class BaseClass {
public:
virtual ~BaseClass() { }
virtual void g() = 0;
};
class DerivedClass : public BaseClass {
public:
virtual void g() { }
BaseClass& f() {
return *this;
}
};
%}

8
Examples/test-suite/abstract_signature.i
View File

@ -7,8 +7,8 @@
class abstract_foo
{
public:
abstract_foo() { };
virtual ~abstract_foo() { };
abstract_foo() { }
virtual ~abstract_foo() { }
virtual int meth(int meth_param) = 0;
};
@ -16,9 +16,9 @@ public:
class abstract_bar : public abstract_foo
{
public:
abstract_bar() { };
abstract_bar() { }
virtual ~abstract_bar() { };
virtual ~abstract_bar() { }
virtual int meth(int meth_param) = 0;
int meth(int meth_param_1, int meth_param_2) { return 0; }
};

2
Examples/test-suite/aggregate.i
View File

@ -6,7 +6,7 @@
To support contracts, you need to add a macro to the runtime.
For Python, it looks like this:
#define SWIG_contract_assert(expr, msg) if (!(expr)) { PyErr_SetString(PyExc_RuntimeError, (char *) msg #expr ); goto fail; } else
#define SWIG_contract_assert(expr, msg) do { if (!(expr)) { PyErr_SetString(PyExc_RuntimeError, (char *) msg #expr ); goto fail; } } while (0)
Note: It is used like this:
SWIG_contract_assert(x == 1, "Some kind of error message");

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