Merge branch 'master' into doxygen
Merge with ~3.0.1 sources from master.
This commit is contained in:
Vadim Zeitlin
commit
1ebd2334b8
1593 changed files with 53108 additions and 29452 deletions
2
.gitattributes
vendored
Normal file
2
.gitattributes
vendored
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
.gitattributes export-ignore
|
||||
.gitignore export-ignore
|
||||
130
.gitignore
vendored
Normal file
130
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,130 @@
|
|||
# Compiled Source
|
||||
*.o
|
||||
*.class
|
||||
|
||||
# Editor files and various other junk
|
||||
.*.sw?
|
||||
*.bak
|
||||
|
||||
# Local PCRE
|
||||
pcre
|
||||
*.gz
|
||||
|
||||
# C/C++ object files, based on:
|
||||
# https://github.com/github/gitignore/blob/master/C.gitignore
|
||||
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
|
||||
*.slo
|
||||
*.lo
|
||||
|
||||
# C/C++ dynamic libraries, based on:
|
||||
# https://github.com/github/gitignore/blob/master/C.gitignore
|
||||
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
|
||||
*.dll
|
||||
*.so
|
||||
*.so.*
|
||||
*.dylib
|
||||
|
||||
# C/C++ static libraries, based on:
|
||||
# https://github.com/github/gitignore/blob/master/C.gitignore
|
||||
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
|
||||
*.lib
|
||||
*.lai
|
||||
*.la
|
||||
*.a
|
||||
|
||||
# C/C++ executables, based on:
|
||||
# https://github.com/github/gitignore/blob/master/C.gitignore
|
||||
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
|
||||
*.exe
|
||||
*.out
|
||||
*.app
|
||||
|
||||
# Generated by autogen.sh
|
||||
CCache/autom4te.cache/
|
||||
CCache/config.h.in
|
||||
CCache/configure
|
||||
Source/Include/swigconfig.h.in
|
||||
Source/Include/swigconfig.h.in~
|
||||
Source/Makefile.in
|
||||
Tools/config/compile
|
||||
Tools/config/config.guess
|
||||
Tools/config/config.sub
|
||||
Tools/config/depcomp
|
||||
Tools/config/install-sh
|
||||
Tools/config/missing
|
||||
Tools/config/ylwrap
|
||||
aclocal.m4
|
||||
autom4te.cache/
|
||||
configure
|
||||
|
||||
# Generated by ./configure
|
||||
CCache/Makefile
|
||||
CCache/ccache_swig_config.h
|
||||
CCache/config.h
|
||||
CCache/config.log
|
||||
CCache/config.status
|
||||
Examples/Makefile
|
||||
Examples/guile/Makefile
|
||||
Examples/test-suite/*/Makefile
|
||||
Examples/xml/Makefile
|
||||
/Makefile
|
||||
Source/Include/stamp-h1
|
||||
Source/Include/swigconfig.h
|
||||
Source/Makefile
|
||||
.deps
|
||||
config.log
|
||||
config.status
|
||||
preinst-swig
|
||||
swig.spec
|
||||
|
||||
# Build Artifacts
|
||||
.dirstamp
|
||||
CCache/ccache-swig
|
||||
CCache/ccache-swig.1
|
||||
Lib/swigwarn.swg
|
||||
Source/CParse/parser.c
|
||||
Source/CParse/parser.h
|
||||
Source/eswig
|
||||
swig
|
||||
|
||||
# Generated documentation
|
||||
Doc/Manual/CCache.html
|
||||
Doc/Manual/SWIGDocumentation.html
|
||||
Doc/Manual/SWIGDocumentation.pdf
|
||||
Doc/Manual/*.book
|
||||
|
||||
# Test Suite Generated Files
|
||||
Examples/test-suite/allegrocl/*/
|
||||
Examples/test-suite/cffi/*/
|
||||
Examples/test-suite/chicken/*/
|
||||
Examples/test-suite/clisp/*/
|
||||
Examples/test-suite/csharp/*/
|
||||
Examples/test-suite/d/*/
|
||||
Examples/test-suite/go/*/
|
||||
Examples/test-suite/guile/*/
|
||||
Examples/test-suite/java/*/
|
||||
Examples/test-suite/lua/*/
|
||||
Examples/test-suite/mzscheme/*/
|
||||
Examples/test-suite/ocaml/*/
|
||||
Examples/test-suite/octave/*/
|
||||
Examples/test-suite/perl5/*/
|
||||
Examples/test-suite/php/*/
|
||||
Examples/test-suite/pike/*/
|
||||
Examples/test-suite/python/*/
|
||||
Examples/test-suite/r/*/
|
||||
Examples/test-suite/ruby/*/
|
||||
Examples/test-suite/tcl/*/
|
||||
Examples/test-suite/uffi/*/
|
||||
|
||||
# Python generated files, based on:
|
||||
# https://github.com/github/gitignore/blob/master/Python.gitignore
|
||||
*.py[cod]
|
||||
*/__pycache__/
|
||||
/__pycache__/
|
||||
|
||||
# C# generated files
|
||||
*_runme.exe.mdb
|
||||
*_runme.exe
|
||||
|
||||
# Scratch directories
|
||||
Examples/scratch
|
||||
32
.project
32
.project
|
|
@ -1,32 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<projectDescription>
|
||||
<name>SWIG</name>
|
||||
<comment></comment>
|
||||
<projects>
|
||||
</projects>
|
||||
<buildSpec>
|
||||
<buildCommand>
|
||||
<name>org.eclipse.cdt.autotools.core.genmakebuilderV2</name>
|
||||
<arguments>
|
||||
</arguments>
|
||||
</buildCommand>
|
||||
<buildCommand>
|
||||
<name>org.eclipse.cdt.managedbuilder.core.genmakebuilder</name>
|
||||
<arguments>
|
||||
</arguments>
|
||||
</buildCommand>
|
||||
<buildCommand>
|
||||
<name>org.eclipse.cdt.managedbuilder.core.ScannerConfigBuilder</name>
|
||||
<triggers>full,incremental,</triggers>
|
||||
<arguments>
|
||||
</arguments>
|
||||
</buildCommand>
|
||||
</buildSpec>
|
||||
<natures>
|
||||
<nature>org.eclipse.cdt.core.cnature</nature>
|
||||
<nature>org.eclipse.cdt.core.ccnature</nature>
|
||||
<nature>org.eclipse.cdt.managedbuilder.core.managedBuildNature</nature>
|
||||
<nature>org.eclipse.cdt.managedbuilder.core.ScannerConfigNature</nature>
|
||||
<nature>org.eclipse.cdt.autotools.core.autotoolsNatureV2</nature>
|
||||
</natures>
|
||||
</projectDescription>
|
||||
69
.travis.yml
69
.travis.yml
|
|
@ -1,8 +1,73 @@
|
|||
language: cpp
|
||||
compiler:
|
||||
- gcc
|
||||
- clang
|
||||
script: ./autogen.sh && ./configure && make -s
|
||||
- gcc
|
||||
env:
|
||||
- SWIGLANG=
|
||||
matrix:
|
||||
include:
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=csharp
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=go
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=guile
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=java
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=lua
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=octave SWIGJOBS=-j4
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=perl5
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=php
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=python VER=2.4
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=python VER=2.5
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=python VER=2.6
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=python # 2.7
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=python PY3=3 # 3.2
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=python PY3=3 VER=3.3
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=python PY3=3 VER=3.4
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=ruby
|
||||
- compiler: gcc
|
||||
env: SWIGLANG=tcl
|
||||
allow_failures:
|
||||
# None
|
||||
before_install:
|
||||
- date -u
|
||||
- lsb_release -a
|
||||
- uname -a
|
||||
- sudo apt-get -qq update
|
||||
- time sudo apt-get -qq install libboost-dev
|
||||
- if test -z "$SWIGLANG"; then sudo apt-get -qq install yodl; fi
|
||||
- if test "$SWIGLANG" = "csharp"; then sudo apt-get -qq install mono-devel; fi
|
||||
- if test "$SWIGLANG" = "go"; then go env | sed -e 's/^/export /' > goenvsetup && source goenvsetup && rm -f goenvsetup; fi # Until configure.ac is fixed
|
||||
- if test "$SWIGLANG" = "guile"; then sudo apt-get -qq install guile-2.0-dev; fi
|
||||
- if test "$SWIGLANG" = "lua"; then sudo apt-get -qq install lua5.1 liblua5.1-dev; fi
|
||||
- if test "$SWIGLANG" = "octave"; then sudo apt-get -qq install octave3.2 octave3.2-headers; fi
|
||||
- if test "$SWIGLANG" = "php"; then sudo apt-get install php5-cli php5-dev; fi
|
||||
- if test "$SWIGLANG" = "python" -a "$PY3" -a -z "$VER"; then sudo apt-get install -qq python3-dev; fi
|
||||
- if test "$SWIGLANG" = "python" -a "$VER"; then sudo add-apt-repository -y ppa:fkrull/deadsnakes && sudo apt-get -qq update && sudo apt-get -qq install python${VER}-dev && export CONFIGOPTS="--with-python${PY3}=python${VER}"; fi
|
||||
- if test "$SWIGLANG" = "tcl"; then sudo apt-get -qq install tcl8.4-dev; fi
|
||||
script:
|
||||
- ./autogen.sh && ./configure $CONFIGOPTS
|
||||
- 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
|
||||
- if test -z "$SWIGLANG"; then sudo make -s install && swig -version && ccache-swig -V; fi
|
||||
- if test -n "$SWIGLANG"; then make -s check-$SWIGLANG-version; fi
|
||||
- if test -n "$SWIGLANG"; then make -k $SWIGJOBS check-$SWIGLANG-examples; fi
|
||||
- if test -n "$SWIGLANG"; then make -k $SWIGJOBS check-$SWIGLANG-test-suite; fi
|
||||
branches:
|
||||
only:
|
||||
- master
|
||||
|
|
|
|||
22
ANNOUNCE
22
ANNOUNCE
|
|
@ -1,31 +1,31 @@
|
|||
*** ANNOUNCE: SWIG 2.0.6 (30 April 2012) ***
|
||||
*** ANNOUNCE: SWIG 3.0.1 (in progress) ***
|
||||
|
||||
http://www.swig.org
|
||||
|
||||
We're pleased to announce SWIG-2.0.6, the latest SWIG release.
|
||||
We're pleased to announce SWIG-3.0.1, the latest SWIG release.
|
||||
|
||||
What is SWIG?
|
||||
=============
|
||||
|
||||
SWIG is a software development tool that reads C/C++ header files and
|
||||
generates the wrapper code needed to make C and C++ code accessible
|
||||
from other languages including Perl, Python, Tcl, Ruby, PHP, Java,
|
||||
Scheme (Guile, MzScheme, CHICKEN), D, Ocaml, Lua, Pike, C#, Modula-3,
|
||||
Octave, R, Common Lisp (CLISP, Allegro CL, CFFI, UFFI). SWIG can also
|
||||
export its parse tree in the form of XML and Lisp s-expressions. Major
|
||||
applications of SWIG include generation of scripting language extension
|
||||
modules, rapid prototyping, testing, and user interface development for
|
||||
large C/C++ systems.
|
||||
from other programming languages including Perl, Python, Tcl, Ruby,
|
||||
PHP, C#, Go, Java, Lua, Scheme (Guile, MzScheme, CHICKEN), D, Ocaml,
|
||||
Pike, Modula-3, Octave, R, Common Lisp (CLISP, Allegro CL, CFFI, UFFI).
|
||||
SWIG can also export its parse tree in the form of XML and Lisp
|
||||
s-expressions. Major applications of SWIG include generation of
|
||||
scripting language extension modules, rapid prototyping, testing,
|
||||
and user interface development for large C/C++ systems.
|
||||
|
||||
Availability
|
||||
============
|
||||
The release is available for download on Sourceforge at
|
||||
|
||||
http://prdownloads.sourceforge.net/swig/swig-2.0.6.tar.gz
|
||||
http://prdownloads.sourceforge.net/swig/swig-3.0.1.tar.gz
|
||||
|
||||
A Windows version is also available at
|
||||
|
||||
http://prdownloads.sourceforge.net/swig/swigwin-2.0.6.zip
|
||||
http://prdownloads.sourceforge.net/swig/swigwin-3.0.1.zip
|
||||
|
||||
Please report problems with this release to the swig-devel mailing list,
|
||||
details at http://www.swig.org/mail.html.
|
||||
|
|
|
|||
|
|
@ -712,12 +712,13 @@ static void from_cache(int first)
|
|||
passfail = retrieve_from_cache(hashname, output_file, hardlink);
|
||||
}
|
||||
|
||||
free(stderr_file);
|
||||
if (passfail == -1) {
|
||||
close(fd_stderr);
|
||||
unlink(stderr_file);
|
||||
free(stderr_file);
|
||||
return;
|
||||
}
|
||||
free(stderr_file);
|
||||
}
|
||||
|
||||
/* get rid of the intermediate preprocessor file */
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ int asprintf(char **ptr, const char *format, ...);
|
|||
int snprintf(char *,size_t ,const char *, ...);
|
||||
#endif
|
||||
|
||||
void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize);
|
||||
void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize, size_t minfiles);
|
||||
void cleanup_all(const char *dir);
|
||||
void wipe_all(const char *dir);
|
||||
|
||||
|
|
@ -200,6 +200,8 @@ typedef int (*COMPAR_FN_T)(const void *, const void *);
|
|||
|
||||
/* mkstemp() on some versions of cygwin don't handle binary files, so
|
||||
override */
|
||||
/* Seems okay in Cygwin 1.7.0
|
||||
#ifdef __CYGWIN__
|
||||
#undef HAVE_MKSTEMP
|
||||
#endif
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -75,21 +75,40 @@ static void traverse_fn(const char *fname, struct stat *st)
|
|||
|
||||
/* sort the files we've found and delete the oldest ones until we are
|
||||
below the thresholds */
|
||||
static void sort_and_clean(void)
|
||||
static void sort_and_clean(size_t minfiles)
|
||||
{
|
||||
unsigned i;
|
||||
size_t adjusted_minfiles = minfiles;
|
||||
|
||||
if (num_files > 1) {
|
||||
/* sort in ascending data order */
|
||||
qsort(files, num_files, sizeof(struct files *),
|
||||
(COMPAR_FN_T)files_compare);
|
||||
}
|
||||
/* ensure newly cached files (minfiles) are kept - instead of matching
|
||||
the filenames of those newly cached, a faster and simpler approach
|
||||
assumes these are the most recent in the cache and if any other
|
||||
cached files have an identical time stamp, they will also be kept -
|
||||
this approach would not be needed if the cleanup was done at exit. */
|
||||
if (minfiles != 0 && minfiles < num_files) {
|
||||
unsigned minfiles_index = num_files - minfiles;
|
||||
time_t minfiles_time = files[minfiles_index]->mtime;
|
||||
for (i=1; i<=minfiles_index; i++) {
|
||||
if (files[minfiles_index-i]->mtime == minfiles_time)
|
||||
adjusted_minfiles++;
|
||||
else
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
/* delete enough files to bring us below the threshold */
|
||||
for (i=0;i<num_files; i++) {
|
||||
if ((size_threshold==0 || total_size < size_threshold) &&
|
||||
(files_threshold==0 || (num_files-i) < files_threshold)) break;
|
||||
|
||||
if (adjusted_minfiles != 0 && num_files-i <= adjusted_minfiles)
|
||||
break;
|
||||
|
||||
if (unlink(files[i]->fname) != 0 && errno != ENOENT) {
|
||||
fprintf(stderr, "unlink %s - %s\n",
|
||||
files[i]->fname, strerror(errno));
|
||||
|
|
@ -103,7 +122,7 @@ static void sort_and_clean(void)
|
|||
}
|
||||
|
||||
/* cleanup in one cache subdir */
|
||||
void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize)
|
||||
void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize, size_t minfiles)
|
||||
{
|
||||
unsigned i;
|
||||
|
||||
|
|
@ -117,7 +136,7 @@ void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize)
|
|||
traverse(dir, traverse_fn);
|
||||
|
||||
/* clean the cache */
|
||||
sort_and_clean();
|
||||
sort_and_clean(minfiles);
|
||||
|
||||
stats_set_sizes(dir, total_files, total_size);
|
||||
|
||||
|
|
@ -151,7 +170,8 @@ void cleanup_all(const char *dir)
|
|||
|
||||
cleanup_dir(dname,
|
||||
counters[STATS_MAXFILES],
|
||||
counters[STATS_MAXSIZE]);
|
||||
counters[STATS_MAXSIZE],
|
||||
0);
|
||||
free(dname);
|
||||
free(sfile);
|
||||
}
|
||||
|
|
|
|||
87
CCache/configure.ac
Normal file
87
CCache/configure.ac
Normal file
|
|
@ -0,0 +1,87 @@
|
|||
dnl Process this file with autoconf to produce a configure script.
|
||||
|
||||
AC_INIT([ccache-swig], [0.0]) # Get version from SWIG in ccache_swig_config.h.in
|
||||
AC_PREREQ(2.52)
|
||||
AC_CONFIG_SRCDIR([ccache.h])
|
||||
|
||||
AC_MSG_NOTICE([Configuring ccache])
|
||||
|
||||
AC_CONFIG_HEADER(config.h)
|
||||
|
||||
dnl Checks for programs.
|
||||
AC_PROG_CC
|
||||
AC_PROG_CPP
|
||||
AC_PROG_INSTALL
|
||||
AC_ARG_PROGRAM # for program_transform_name
|
||||
|
||||
AC_DEFINE([_GNU_SOURCE], 1,
|
||||
[Define _GNU_SOURCE so that we get all necessary prototypes])
|
||||
|
||||
# If GCC, turn on warnings.
|
||||
if test "x$GCC" = "xyes"
|
||||
then
|
||||
CFLAGS="$CFLAGS -Wall -W"
|
||||
else
|
||||
CFLAGS="$CFLAGS -O"
|
||||
fi
|
||||
|
||||
AC_HEADER_DIRENT
|
||||
AC_HEADER_TIME
|
||||
AC_HEADER_SYS_WAIT
|
||||
|
||||
AC_CHECK_HEADERS(ctype.h strings.h stdlib.h string.h pwd.h sys/time.h)
|
||||
|
||||
AC_CHECK_FUNCS(realpath snprintf vsnprintf vasprintf asprintf mkstemp)
|
||||
AC_CHECK_FUNCS(gethostname getpwuid)
|
||||
AC_CHECK_FUNCS(utimes)
|
||||
|
||||
AC_CACHE_CHECK([for compar_fn_t in stdlib.h],ccache_cv_COMPAR_FN_T, [
|
||||
AC_TRY_COMPILE(
|
||||
[#include <stdlib.h>],
|
||||
[
|
||||
void test_fn(void) { qsort(NULL, 0, 0, (__compar_fn_t)NULL); }
|
||||
],
|
||||
ccache_cv_COMPAR_FN_T=yes,ccache_cv_COMPAR_FN_T=no)])
|
||||
if test x"$ccache_cv_COMPAR_FN_T" = x"yes"; then
|
||||
AC_DEFINE(HAVE_COMPAR_FN_T, 1, [ ])
|
||||
fi
|
||||
|
||||
dnl Note: This could be replaced by AC_FUNC_SNPRINTF() in the autoconf macro archive
|
||||
AC_CACHE_CHECK([for C99 vsnprintf],ccache_cv_HAVE_C99_VSNPRINTF,[
|
||||
AC_TRY_RUN([
|
||||
#include <sys/types.h>
|
||||
#include <stdarg.h>
|
||||
void foo(const char *format, ...) {
|
||||
va_list ap;
|
||||
int len;
|
||||
char buf[5];
|
||||
|
||||
va_start(ap, format);
|
||||
len = vsnprintf(0, 0, format, ap);
|
||||
va_end(ap);
|
||||
if (len != 5) exit(1);
|
||||
|
||||
if (snprintf(buf, 3, "hello") != 5 || strcmp(buf, "he") != 0) exit(1);
|
||||
|
||||
exit(0);
|
||||
}
|
||||
main() { foo("hello"); }
|
||||
],
|
||||
ccache_cv_HAVE_C99_VSNPRINTF=yes,ccache_cv_HAVE_C99_VSNPRINTF=no,ccache_cv_HAVE_C99_VSNPRINTF=cross)])
|
||||
if test x"$ccache_cv_HAVE_C99_VSNPRINTF" = x"yes"; then
|
||||
AC_DEFINE(HAVE_C99_VSNPRINTF, 1, [ ])
|
||||
fi
|
||||
|
||||
dnl Check for zlib.
|
||||
dnl Note: This could be replaced by CHECK_ZLIB() in the autoconf macro archive
|
||||
AC_ARG_ENABLE([zlib],
|
||||
AS_HELP_STRING([--enable-zlib], [enable zlib support for ccache compression]),,
|
||||
[enable_zlib=yes])
|
||||
|
||||
if test x"$enable_zlib" = x"yes"; then
|
||||
AC_CHECK_HEADER(zlib.h, AC_CHECK_LIB(z, gzdopen, [LIBS="-lz $LIBS"
|
||||
AC_DEFINE([ENABLE_ZLIB], 1, [Define to 1 if you would like to have zlib compression for ccache.]) ] ))
|
||||
fi
|
||||
|
||||
AC_CONFIG_FILES([Makefile])
|
||||
AC_OUTPUT
|
||||
|
|
@ -168,7 +168,8 @@ static void stats_update_size(enum stats stat, size_t size, size_t numfiles)
|
|||
|
||||
if (need_cleanup) {
|
||||
char *p = dirname(stats_file);
|
||||
cleanup_dir(p, counters[STATS_MAXFILES], counters[STATS_MAXSIZE]);
|
||||
cleanup_dir(p, counters[STATS_MAXFILES], counters[STATS_MAXSIZE],
|
||||
numfiles);
|
||||
free(p);
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ basetests() {
|
|||
testname="non-regular"
|
||||
mkdir testd
|
||||
$CCACHE_COMPILE -o testd -c test1.c > /dev/null 2>&1
|
||||
rmdir testd
|
||||
rm -rf testd
|
||||
checkstat 'output to a non-regular file' 1
|
||||
|
||||
testname="no-input"
|
||||
|
|
@ -315,7 +315,7 @@ swigtests() {
|
|||
testname="non-regular"
|
||||
mkdir testd
|
||||
$CCACHE_COMPILE -o testd -java testswig1.i > /dev/null 2>&1
|
||||
rmdir testd
|
||||
rm -rf testd
|
||||
checkstat 'output to a non-regular file' 1
|
||||
|
||||
testname="no-input"
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ void copy_fd(int fd_in, int fd_out)
|
|||
|
||||
#ifndef HAVE_MKSTEMP
|
||||
/* cheap and nasty mkstemp replacement */
|
||||
static int mkstemp(char *template)
|
||||
int mkstemp(char *template)
|
||||
{
|
||||
mktemp(template);
|
||||
return open(template, O_RDWR | O_CREAT | O_EXCL | O_BINARY, 0600);
|
||||
|
|
|
|||
|
|
@ -2,16 +2,40 @@ Below are the changes for the current release.
|
|||
See the CHANGES file for changes in older releases.
|
||||
See the RELEASENOTES file for a summary of changes in each release.
|
||||
|
||||
Version 2.0.6 (30 April 2012)
|
||||
=============================
|
||||
Version 3.0.1 (in progress)
|
||||
===========================
|
||||
|
||||
2012-04-25: wsfulton
|
||||
[Lua] Fix uninitialised variable in SWIGTYPE **OUTPUT typemaps as reported by Jim Anderson.
|
||||
2014-04-08: wsfulton
|
||||
SF Bug #1366 - Remove duplicate declarations of strtoimax and strtoumax in inttypes.i
|
||||
|
||||
2012-04-28: wsfulton
|
||||
[Python] Fix compilation errors when wrapping STL containers on Mac OSX and possibly other systems.
|
||||
2014-04-08: wsfulton
|
||||
[Java C#] Enums which have been ignored via %ignore and are subsequently
|
||||
used are handled slightly differently. Type wrapper classes are now generated
|
||||
which are effectively a wrapper of an empty enum. Previously in Java uncompilable
|
||||
code was generated and in C# an int was used.
|
||||
|
||||
2012-04-28: wsfulton
|
||||
[Java] Patch 3521811 from Leo Davis - char **STRING_ARRAY typemaps fixed to handle
|
||||
null pointers.
|
||||
2014-04-04: wsfulton
|
||||
Fix regression in 3.0.0 where legal code following an operator<< definition might
|
||||
give a syntax error. SF Bug #1365.
|
||||
|
||||
2014-04-03: olly
|
||||
[PHP] Fix wrapping director constructors with default parameters
|
||||
with a ZTS-enabled build of PHP.
|
||||
|
||||
2014-04-02: olly
|
||||
[PHP] Pass the ZTS context we already have to avoid needing to
|
||||
call TSRMLS_FETCH, which is relatively expensive.
|
||||
|
||||
2014-04-02: olly
|
||||
[PHP] Pass ZTS context through to t_output_helper() so it works
|
||||
with a ZTS-enabled build of PHP. Reported by Pierre Labastie in
|
||||
github PR#155.
|
||||
|
||||
2014-03-28: wsfulton
|
||||
[Java C# D Go] Fixes for C enums used in an API and the definition of the enum
|
||||
has not been parsed. For D, this fixes a segfault in SWIG. The other languages
|
||||
now produce code that compiles, although the definition of the enum is needed
|
||||
in order to use the enum properly from the target language.
|
||||
|
||||
2014-03-23: v-for-vandal
|
||||
[Lua] Fix for usage of snprintf in Lua runtime which Visual Studio does not have.
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ Past contributors include:
|
|||
James Michael DuPont, Clark McGrew, Dustin Mitchell, Ian Cooke, Catalin Dumitrescu, Baran
|
||||
Kovuk, Oleg Tolmatcev, Tal Shalif, Lluis Padro, Chris Seatory, Igor Bely, Robin Dunn,
|
||||
Edward Zimmermann, David Ascher, Dominique Dumont, Pier Giorgio Esposito, Hasan Baran Kovuk,
|
||||
Klaus Wiederänders
|
||||
Klaus Wiederänders, Richard Beare, Hans Oesterholt.
|
||||
(See CHANGES and CHANGES.current and the bug tracker for a more complete list).
|
||||
|
||||
Past students:
|
||||
|
|
|
|||
788
Doc/Devel/cpp11.html
Normal file
788
Doc/Devel/cpp11.html
Normal file
|
|
@ -0,0 +1,788 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
|
||||
<TITLE></TITLE>
|
||||
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.0 (Unix)">
|
||||
<META NAME="CREATED" CONTENT="20090712;16061100">
|
||||
<META NAME="CHANGED" CONTENT="20090817;17311900">
|
||||
<META NAME="Podatek 1" CONTENT="">
|
||||
<META NAME="Podatek 2" CONTENT="">
|
||||
<META NAME="Podatek 3" CONTENT="">
|
||||
<META NAME="Podatek 4" CONTENT="">
|
||||
<STYLE TYPE="text/css">
|
||||
<!--
|
||||
@page { margin: 2cm }
|
||||
H1 { margin-bottom: 0.21cm }
|
||||
H1.western { font-family: "Liberation Serif", serif }
|
||||
H1.cjk { font-family: "DejaVu Sans" }
|
||||
H1.ctl { font-family: "DejaVu Sans" }
|
||||
P { margin-bottom: 0.21cm }
|
||||
H2 { margin-bottom: 0.21cm }
|
||||
A:link { so-language: zxx }
|
||||
-->
|
||||
</STYLE>
|
||||
</HEAD>
|
||||
<BODY LANG="en-US" DIR="LTR">
|
||||
<H1 CLASS="western"><U>C++0x/C++11 support for SWIG</U></H1>
|
||||
<H1 CLASS="western">Summary</H1>
|
||||
<P>This is a technical overview of the C++0x/C++11 support for the Swig.
|
||||
This area of Swig is a work in progress. Initial C++0x/C++11 support for
|
||||
Swig was written during the Google Summer of Code 2009 period by
|
||||
Matevž Jekovec.</P>
|
||||
<H1 CLASS="western">SVN branch</H1>
|
||||
<P>branches/gsoc2009-matevz</P>
|
||||
<H1 CLASS="western">New C++11 features status</H1>
|
||||
<P>Wikipedia article: <A HREF="http://en.wikipedia.org/wiki/C++0x">http://en.wikipedia.org/wiki/C%2B%2B0x</A>
|
||||
</P>
|
||||
<H2>Rvalue reference and move semantics [done]</H2>
|
||||
<P>The Rvalues are used in practice to speed up the move operations
|
||||
on different containers.</P>
|
||||
<P>In the following example, we want to swap the given elements:</P>
|
||||
<PRE>template <class T> swap(T& a, T& b) {
|
||||
T tmp(a); // now we have two copies of a
|
||||
a = b; // now we have two copies of b
|
||||
b = tmp; // now we have two copies of tmp (aka a)
|
||||
}</PRE><P>
|
||||
This can now be solved using the new function std::move():</P>
|
||||
<PRE>template <class T> swap(T& a, T& b) {
|
||||
T tmp(std::move(a));
|
||||
a = std::move(b);
|
||||
b = std::move(tmp);
|
||||
}</PRE><P STYLE="margin-bottom: 0cm">
|
||||
For the move function to take effect, user needs to reimplement the
|
||||
move constructor (taking ClassType&& as an argument) and
|
||||
operator=(ClassType&&):</P>
|
||||
<PRE>class MyClass {
|
||||
MyClass(MyClass&& p) : ptr(p.ptr) {p.ptr = 0;}
|
||||
MyClass& operator=(MyClass&& p) {
|
||||
std::swap(ptr, p.ptr);
|
||||
return *this;
|
||||
}
|
||||
};</PRE><P>
|
||||
In practice, the Rvalues are used for temporaries (when passing the
|
||||
result of one function as an argument to another).</P>
|
||||
<P>Done: Added type&& to Swig parser. Added testcase
|
||||
cpp11_rvalue_reference.i. Operator && is treated the same as
|
||||
operator &. R11450</P>
|
||||
<P STYLE="margin-bottom: 0cm">Article:
|
||||
<A HREF="http://www.artima.com/cppsource/rvalue.html">http://www.artima.com/cppsource/rvalue.html</A></P>
|
||||
<H2>Generalized constant expressions [done]</H2>
|
||||
<P>In C++11 you can define functions as constant expressions.
|
||||
Functions need to return constant value in form "return expr",
|
||||
where expr is a constant expression.
|
||||
</P>
|
||||
<P>A keyword "constexpr" is introduced for this. eg.:
|
||||
constexpr int getNumber() { return 5; } const int MY_CONSTANT =
|
||||
getNumber();
|
||||
</P>
|
||||
<P>Constants are treated as normal variables in interpreted languages
|
||||
because they are not compiled into the executable. Java "final"
|
||||
constants are defined runtime as well. C++ constants need to be
|
||||
declared in the header file and defined in the implementation file,
|
||||
so swig doesn't need to know about the constant values when parsing
|
||||
the header file.
|
||||
</P>
|
||||
<P>Done: Added the “constexpr “ keyword to Swig. Added testcase
|
||||
cpp11_constexpr. R11322</P>
|
||||
<P>Problem: No compilers were known to support constexpr yet, so the
|
||||
testcase was temporarily commented out in common.mk.
|
||||
</P>
|
||||
<H2>Extern template [done]</H2>
|
||||
<P>Extern template forces the GCC compiler to not instantiate the
|
||||
template in the translation unit at that time. It's a feature
|
||||
specifically aimed at compilers to speed up the compilation process.
|
||||
</P>
|
||||
<P>Done: Added support for 'extern template class
|
||||
std::vector<MyClass>;'. Added testcase cpp11_template_explicit.
|
||||
R11385 , R11386</P>
|
||||
<H2>Initializer lists [done]</H2>
|
||||
<P>Initializer list is a new type in standard library:
|
||||
std::initializer_list<T>. New symbols {} are introduced for the
|
||||
initializer lists.
|
||||
</P>
|
||||
<P>One can now use:
|
||||
</P>
|
||||
<PRE> class A {
|
||||
public:
|
||||
A( std::initializer_list<int> );
|
||||
};
|
||||
A a1 = {1,2,3,4};</PRE><P>
|
||||
Languages like Java, C# and Python already support direct creation of
|
||||
lists natively.</P>
|
||||
<P>Problem: initializer_list cannot be treated as an ordinary list.
|
||||
The constructor containing initializer_list can only be accessed by
|
||||
assigning the value using the {} brackets. I also don't think there
|
||||
is a simple way to convert an ordinary list or a vector to the
|
||||
initializer_list.</P>
|
||||
<P>Done: Ignored the constructor having initializer_list as its
|
||||
argument. Show warning to the user. Added testcase
|
||||
cpp11_initializer_list. R11450</P>
|
||||
<P>Article:
|
||||
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1919.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1919.pdf</A></P>
|
||||
<H2>Uniform initialization [done]</H2>
|
||||
<P>The new C++11 standard will allow the following:</P>
|
||||
<PRE>struct IdString {
|
||||
std::string name;
|
||||
int identifier;
|
||||
};
|
||||
|
||||
IdString GetString() {
|
||||
return {"SomeName", 4}; //Note the lack of explicit type.
|
||||
}</PRE><P>
|
||||
The feature works exactly as it did now for POD types only (eg. int
|
||||
a[] = {1,2,3};). The following declarations are the same in the new
|
||||
C++11:</P>
|
||||
<PRE>IdString str1 = {„SomeName“, 4};
|
||||
IdString str2{„SomeName“, 4};</PRE><P>
|
||||
The new way of using uniform initialization allows the following:</P>
|
||||
<PRE>struct BasicStruct {
|
||||
int x;
|
||||
double y;
|
||||
};
|
||||
|
||||
struct AltStruct {
|
||||
AltStruct(int x, double y) : x_{x}, y_{y} {}
|
||||
|
||||
private:
|
||||
int x_;
|
||||
double y_;
|
||||
};
|
||||
|
||||
BasicStruct var1{5, 3.2}; // only fills the struct components
|
||||
AltStruct var2{2, 4.3}; // calls the constructor</PRE><P>
|
||||
The new syntax is specific to C++. Java, C# and scripting languages
|
||||
do not support this behaviour, but always need constructors. They
|
||||
support {} brackets for declaration of arrays as C does + they add
|
||||
support for creation of arrays on-the-fly (what C++11 introduced with
|
||||
this feature and more).</P>
|
||||
<P>Done: Added syntax for {} member initialization in class
|
||||
constructor. Added testcase cpp11_uniform_initialization. R11413</P>
|
||||
<H2>Type inference [partially done]</H2>
|
||||
<P>A new keyword 'auto' is introduced in C++11:</P>
|
||||
<PRE>auto a1 = 100;
|
||||
auto a2 = myFunc();</PRE><P>
|
||||
The type of a1 and a2 is automatically determined according to the
|
||||
initialization value during the semantic phase of the compiler.</P>
|
||||
<P>Another macro 'decltype()' is introduced. The macro takes the
|
||||
concrete object as an argument and returns its type. User could use
|
||||
this as:</P>
|
||||
<PRE>int i = 100;
|
||||
decltype(i) j = 200; // decltype(i) = int</PRE><P STYLE="margin-bottom: 0cm">
|
||||
Calling operators are allowed as well:</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">decltype(i+j) k = 300;</PRE><P>
|
||||
Done: Added support for decltype() syntax. Test cases for normal
|
||||
decltype members and alternate function members work fine. Currently
|
||||
only syntax in form decltype(variable name) work. No support for
|
||||
custom expresions eg. decltype(i+j) yet. R11525</P>
|
||||
<P>TODO: William proposed to support the hidden variables as well
|
||||
(ones not parsed by Swig and added to symbol table). This also allows
|
||||
Swig to parse custom expressions like decltype(i+j). The idea is to
|
||||
introduce a new SwigType for this.</P>
|
||||
<H2>Range-based for-loop [ignored]</H2>
|
||||
<P>This feature is always present inside the implementation block
|
||||
only.
|
||||
</P>
|
||||
<H2>Lambda functions and expressions [done]</H2>
|
||||
<P>C++11 introduces lambda functions defined as:</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">[](int x, int y) -> int { return x + y; }</PRE><P>
|
||||
If the lambda function contains a single return statement only or the
|
||||
function doesn't return any type, the return type '->' can be
|
||||
omitted. Lambda functions are function objects.</P>
|
||||
<P>The following example prints the number of items stored in a list:</P>
|
||||
<PRE>std::vector<int> someList;
|
||||
int total = 0;
|
||||
std::for_each( someList.begin(), someList.end(), [&total](int x) {total += x} );
|
||||
std::cout << total;</PRE><P>
|
||||
Parameters inside the [] are the visible parameters of the lambda
|
||||
functions. These can be & (references), = (copies), variable name
|
||||
(variable copy), &variable name (variable reference) or this
|
||||
(copy of the current object).</P>
|
||||
<P>Lambda functions can be stored using:</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">auto myLambdaFunc = [this]() { this->SomePrivateMemberFunction() };</PRE><P>
|
||||
Proposal: Lambda functions are most commonly used inside the function
|
||||
block to quickly define how the sort, find and similar functions
|
||||
should work (the other way would be overriding a class – the Java
|
||||
style). The latest GCC does not support lambda functions yet so it is
|
||||
difficult to test the feature once implemented. I would implement the
|
||||
syntax support for this feature, but produce no wrapper code. Lambda
|
||||
functions still work inside the function block though.</P>
|
||||
<P>Article:
|
||||
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf</A></P>
|
||||
<P>Done: Added syntax support for the lambda functions. Added
|
||||
testcase cpp11_lambda_functions.i. R11491, R11492</P>
|
||||
<H2>Alternate function syntax [done]</H2>
|
||||
<P>The problem with decltype() is that the parameters need to be
|
||||
defined before the decltype. The following syntax is not valid,
|
||||
because lhs and rhs hasn't been defined at the time of decltype:</P>
|
||||
<PRE>template< typename LHS, typename RHS>
|
||||
decltype(lhs+rhs) AddingFunc(const LHS &lhs, const RHS &rhs) {return lhs + rhs;} //Not legal C++11</PRE><P>
|
||||
The solution C++11 offers is the combination of the 'auto' keyword
|
||||
before and '-> rettype' after the function declaration:</P>
|
||||
<PRE>template< typename LHS, typename RHS>
|
||||
auto AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) {return lhs + rhs;}</PRE><P>
|
||||
The new syntax only makes the job for the C++ compilers easier when
|
||||
parsing such functions. The new syntax can be used for ordinary
|
||||
functions as well:</P>
|
||||
<PRE>struct SomeStruct {
|
||||
auto FuncName(int x, int y) -> int;
|
||||
};
|
||||
|
||||
auto SomeStruct::FuncName(int x, int y) -> int {
|
||||
return x + y;
|
||||
}</PRE><P>
|
||||
Done: Added support for the 'auto' return type. Added support for the
|
||||
'-> type' after the funtion declaration. Added testcases
|
||||
cpp11_alternate_function_syntax.i and
|
||||
cpp11_alternate_function_syntax_runme.py. R11414</P>
|
||||
<H2>Concepts, Axioms [ignored]</H2>
|
||||
<P>In C++ there is a common problem when you use a template in the
|
||||
class which doesn't support all the operations the functions in the
|
||||
class actually do on the type. Compiler errors are usually very long
|
||||
and unreadable. C++11 adds support for the "concepts". The
|
||||
idea is to define what operations and attributes should the template
|
||||
have. In contrast to class inheritance and polimorphism, all lookups
|
||||
are done in compile-time.
|
||||
</P>
|
||||
<P>Basic syntax (note LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=LessThanComparable">?</A>
|
||||
instead of "class" or "typename"):
|
||||
</P>
|
||||
<PRE> template<LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=LessThanComparable">?</A> T>
|
||||
const T& min(const T &x, const T &y) {
|
||||
return y < x ? y : x;
|
||||
}</PRE><P>
|
||||
Extended syntax (requires conditions are separated with &&,
|
||||
|| or !):
|
||||
</P>
|
||||
<PRE> template< typename T> requires LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=LessThanComparable">?</A><T>
|
||||
const T& min(const T &x, const T &y) {
|
||||
return y < x ? y : x;
|
||||
}</PRE><P>
|
||||
Definition of the concepts:
|
||||
</P>
|
||||
<PRE> concept LessThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=LessThanComparable">?</A>< typename T > {
|
||||
bool operator<(T,T);
|
||||
requires GreaterThanComparable<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=GreaterThanComparable">?</A><T>;
|
||||
typename value_type;
|
||||
typename reference;
|
||||
};</PRE><P>
|
||||
Concept maps allow usage of a specific type:
|
||||
</P>
|
||||
<PRE> template< typename T>
|
||||
concept_map InputIterator<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=InputIterator">?</A><T*> {
|
||||
typedef T value_type ;
|
||||
typedef T& reference ;
|
||||
typedef T* pointer ;
|
||||
typedef std::ptrdiff_t difference_type ;
|
||||
};</PRE><P>
|
||||
Concept maps can act as mini-types, with function definitions and
|
||||
other constructs commonly associated with classes:
|
||||
</P>
|
||||
<PRE> concept Stack< typename X> {
|
||||
typename value_type;
|
||||
void push(X&, const value_type&);
|
||||
void pop(X&);
|
||||
value_type top(const X&);
|
||||
bool empty(const X&);
|
||||
};
|
||||
template< typename T>
|
||||
concept_map Stack<std::vector<T> > {
|
||||
typedef T value_type;
|
||||
void push(std::vector<T>& v, const T& x) { v.push_back(x); }
|
||||
void pop(std::vector<T>& v) { v.pop_back(); }
|
||||
T top(const std::vector<T>& v) { return v.back(); }
|
||||
bool empty(const std::vector<T>& v) { return v.empty(); }
|
||||
};</PRE><P>
|
||||
Axioms are a facility pertaining to concepts supplied by C++11 to
|
||||
express the semantic properties of concepts. For example, the concept
|
||||
Semigroup can be defined with an axiom Associativity as:
|
||||
</P>
|
||||
<PRE> concept Semigroup< typename Op, typename T> : CopyConstructible<A HREF="http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=CopyConstructible">?</A><T> {
|
||||
T operator()(Op, T, T);
|
||||
axiom Associativity(Op op, T x, T y, T z) {
|
||||
op(x, op(y, z)) == op(op(x, y), z);
|
||||
}
|
||||
};</PRE><P>
|
||||
Axioms are more like hints to the compiler to speed-up the process of
|
||||
compilation.
|
||||
</P>
|
||||
<P>Ignored: Concepts and axioms were removed from the C++11 standard.
|
||||
</P>
|
||||
<H2>Object construction improvement [done]</H2>
|
||||
<P>This feature allows classes constructors to call other
|
||||
constructors with different arguments (similar to Java and C#
|
||||
behaviour).
|
||||
</P>
|
||||
<P>The syntax is as follows:
|
||||
</P>
|
||||
<PRE> class SomeType {
|
||||
int number;
|
||||
public:
|
||||
SomeType(int newNumber) : number(newNumber) {}
|
||||
SomeType() : SomeType(42) {}
|
||||
};</PRE><P>
|
||||
Also when using the inheritance, the feature introduces inheritance
|
||||
of all superclass constructors without being defined separately in
|
||||
the inherited class:
|
||||
</P>
|
||||
<PRE> class BaseClass {
|
||||
public:
|
||||
BaseClass(int iValue);
|
||||
};
|
||||
class DerivedClass: public BaseClass {
|
||||
public:
|
||||
using BaseClass::BaseClass; // Adds DerivedClass(int) constructor
|
||||
};</PRE><P>
|
||||
Swig already correctly parses and produces the correct wrapper for
|
||||
the “using” keyword.</P>
|
||||
<P>Done: Added testcase cpp11_constructors.i which covers both
|
||||
constructor delegation and constructor inheritance. R11532</P>
|
||||
<P>Problem: Constructor delegation and constructor inheritance is not
|
||||
supported by any compiler yet, so it's impossible to try and test
|
||||
this feature.</P>
|
||||
<H2>Null pointer constant [done]</H2>
|
||||
<P>nullptr is part of the standard library.
|
||||
</P>
|
||||
<P>It's defined as typedef decltype(nullptr) nullptr_t;
|
||||
</P>
|
||||
<P>nullptr_t is defined in <cstddef>.
|
||||
</P>
|
||||
<P>As far as the C++ is compatible with 0 as the pointer value, swig
|
||||
values will work for the C++. And the other way around, nullptr
|
||||
behaves as the ordinary pointer (false, if empty, true, if not
|
||||
empty), so it's ok for swig to compare it.</P>
|
||||
<P>Done: Written a testcase cpp11_null_pointer_constant.i and
|
||||
cpp11_null_pointer_constant_runme.py to prove the nullptr
|
||||
functionality. R11484</P>
|
||||
<H2>Strongly typed enumerations [partially done]</H2>
|
||||
<P>C++11 introduces a new syntax for strongly typed enum declaration:
|
||||
</P>
|
||||
<PRE> enum class Enumeration {
|
||||
Val1,
|
||||
Val2,
|
||||
Val3 = 100,
|
||||
Val4 /* = 101 */
|
||||
};</PRE><P>
|
||||
Typing if (Val4 == 101) will result in compilation error.
|
||||
</P>
|
||||
<P>The enum itself can now be explicitely of type int, long, unsigned
|
||||
int etc.:
|
||||
</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm"> enum class Enum2 : unsigned int {Val1, Val2};</PRE><P>
|
||||
And it can be forward declared as well:
|
||||
</P>
|
||||
<PRE> enum Enum1; //Illegal in C++ and C++11; no size is explicitly specified.
|
||||
enum Enum2 : unsigned int; //Legal in C++11.
|
||||
enum class Enum3; //Legal in C++11, because enum class declarations have a default type of "int".
|
||||
enum class Enum4: unsigned int; //Legal C++11.
|
||||
enum Enum2 : unsigned short; //Illegal in C++11, because Enum2 was previously declared with a different type.</PRE><P>
|
||||
Done: Added syntax 'enum class Name' and forward declarators 'enum
|
||||
Name : inherited type' or 'enum class Name : inherited type' in
|
||||
R11449.</P>
|
||||
<P>TODO: Add semantic support for enum elements not clashing with
|
||||
enum elements in other enum classes. See cpp11_strongly_typed_enums.i
|
||||
warnings.</P>
|
||||
<P>Problem: Swig currently doesn't support nested classes. This
|
||||
feature should be implemented using a new nested class when using
|
||||
“enum class” with a single anonymous “enum {elements}”
|
||||
element inside. For example:</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">class A { enum class EA { a,b,c,d }; };</PRE><P>
|
||||
should be mapped to</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">class A { class EA { enum {a,b,c,d}; }; };</PRE><H2>
|
||||
Angle bracket [done]</H2>
|
||||
<P>Support for right angled brackets was implemented using the
|
||||
following article as a base:
|
||||
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html</A>
|
||||
</P>
|
||||
<P>Done: Added support for angle brackets. Used the preferred
|
||||
"Approach 1". Added a testcase named
|
||||
cpp11_template_double_brackets. R11245</P>
|
||||
<H2>Explicit conversion operators [done]</H2>
|
||||
<P>This is used when converting one type to another (eg. if
|
||||
(myObject) {}, where myObject is your custom class converted to
|
||||
bool).
|
||||
</P>
|
||||
<P>Requires both operator and function overloading which is not
|
||||
supported in any target language (eg. python, php).
|
||||
</P>
|
||||
<P>Done: Swig already supports the keyword "explicit" for
|
||||
function types as well. Added test case
|
||||
cpp11_explicit_conversion_operators. R11323</P>
|
||||
<H2>Template typedefs [partially done]</H2>
|
||||
<P>The new C++11 will allow creation of wrapper around the template.
|
||||
For example, if we want to do this:</P>
|
||||
<PRE>template< typename first, typename second, int third>
|
||||
class SomeType;
|
||||
|
||||
template< typename second>
|
||||
typedef SomeType<OtherType, second, 5> TypedefName; //Illegal in C++</PRE><P>
|
||||
This is still illegal! But we can now use the new syntax for
|
||||
achieving the same effect:</P>
|
||||
<PRE>template< typename first, typename second, int third>
|
||||
class SomeType;
|
||||
|
||||
template< typename second>
|
||||
using TypedefName = SomeType<OtherType, second, 5>;</PRE><P>
|
||||
Here we created a new wrapper TypedefName taking one template
|
||||
argument <second> which creates a type SomeType<OtherType,
|
||||
second, 5>. OtherType and 5 are predefined here and hidden from
|
||||
the user – the user only uses TypedefName type.</P>
|
||||
<P>The same goes for the following example:</P>
|
||||
<PRE>typedef void (*PFD)(double); // Old style
|
||||
using PF = void (*)(double); // New introduced syntax</PRE><P>
|
||||
Swig supports parsing typedefs for templates as well for example:</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">typedef List<int> intList;</PRE><P>
|
||||
Done: Expanded support for the new 'using' syntax and template
|
||||
aliasing. Added testcase cpp11_template_typedefs. R11533</P>
|
||||
<P>TODO: Make Swig aware of the newly defined typedef. The TYPEDEF
|
||||
keyword is part of the storage_class rule and type+declarator (see
|
||||
c_decl rule) is the right part of the definition – for example void
|
||||
(*PFD)(double) cannot be transformed to void *(double) easily. To
|
||||
fully support the new 'using' form, we'll probably have to change the
|
||||
type, type_right rules and declarator, direct_declarator,
|
||||
notso_direct_declarator etc., which is PITA.</P>
|
||||
<H2>Unrestricted unions [done]</H2>
|
||||
<P>C++ currently offers usage of unions for types with trivial
|
||||
constructors only. The new C++11 standard allows usage of types with
|
||||
non-trivial constructors as well:</P>
|
||||
<PRE> struct point {
|
||||
point() {}
|
||||
point(int x, int y): x_(x), y_(y) {}
|
||||
int x_, y_;
|
||||
};
|
||||
union P {
|
||||
int z;
|
||||
double w;
|
||||
point p; // Illegal in C++; point has a non-trivial constructor. However, this is legal in C++11.
|
||||
} p1;</PRE><P>
|
||||
Swig already parses the given syntax.</P>
|
||||
<P>Done: Added testcase cpp11_unrestricted_unions. R11435, R11447</P>
|
||||
<P>Problem: GCC doesn't support unrestricted unions yet so there is
|
||||
no way to actually test, if it works.</P>
|
||||
<H2>Variadic templates [partially done]</H2>
|
||||
<P>The new C++11 offers the following syntax:</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">template<typename... Values> class tuple;</PRE><P>
|
||||
This can be used for example:</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">class tuple<int, std::vector<int>, std::map<std::string, std::vector<int>>> someInstanceName;</PRE><P>
|
||||
The ... is used in two cases. One is in the template header where it
|
||||
marks on the left the keywords 'typename' or 'class' and a type name
|
||||
on the right. The second case is usually in the function block to
|
||||
decompose typename on the left of the ... . For example:</P>
|
||||
<PRE>void printf(const char *s) {
|
||||
while (*s) {
|
||||
if (*s == '%' && *(++s) != '%')
|
||||
throw std::runtime_error("invalid format string: missing arguments");
|
||||
std::cout << *s++;
|
||||
}
|
||||
}
|
||||
|
||||
template<typename T, typename... Args>
|
||||
void printf(const char* s, T value, Args... args) { // recursive action – split previous args to value + args
|
||||
while (*s) {
|
||||
if (*s == '%' && *(++s) != '%') {
|
||||
std::cout << value;
|
||||
printf(*s ? ++s : s, args...); // call even when *s == 0 to detect extra arguments
|
||||
return;
|
||||
}
|
||||
std::cout << *s++;
|
||||
}
|
||||
throw std::logic_error("extra arguments provided to printf");
|
||||
}</PRE><P>
|
||||
The tricky part is that variadic templates can unpack actually
|
||||
anywhere – including the class inheritance :(</P>
|
||||
<PRE>template <typename... BaseClasses> class ClassName : public BaseClasses... {
|
||||
public:
|
||||
|
||||
ClassName (BaseClasses&&... baseClasses) : BaseClasses(baseClasses)... {}
|
||||
}</PRE><P>
|
||||
A new extension to sizeof is also introduced with this feature. The
|
||||
... after sizeof returns number of arguments:</P>
|
||||
<PRE>template<typename ...Args> struct SomeStruct {
|
||||
static const int size = sizeof...(Args);
|
||||
}
|
||||
// SomeStruct<Type1, Type2>::size is 2 and SomeStruct<>::size is 0</PRE><P>
|
||||
Done: Added syntax support for 'typename' or 'class' + ... + id.
|
||||
Added testcase cpp11_variadic_templates. R11458</P>
|
||||
<P>Done: Added syntax support for BaseClass + ..., type + ... + id in
|
||||
parameters and baseclass + ... for intializers after constructor.
|
||||
Extended Swig syntax to support sizeof...(Args). R11467</P>
|
||||
<P>Done: Fixed %template to support variadic number of templates.</P>
|
||||
<P>TODO: Only (if present) first variadically defined argument is
|
||||
currently used in %template directive. The next ones are ignored.</P>
|
||||
<H2>New string literals [partially done]</H2>
|
||||
<P>Beside the implementation, the new C++11 Unicode and custom
|
||||
delimeter constants can occur in templates in the header file.
|
||||
</P>
|
||||
<P>Done: Added symbols 'u', 'u8' and 'U' to mark the beginning of the
|
||||
UTF string. Also added test case cpp11_raw_string_literals. R11327</P>
|
||||
<P>Done: Added R"DELIMITER[, ]DELIMITER" for a custom
|
||||
delimiter for the beginning/end of the string. R11328</P>
|
||||
<P>TODO: Fix the Swig's C++ preprocessor bug when parsing an odd
|
||||
number of “ inside the string brackets. See
|
||||
Source/Preprocessor/cpp.c.</P>
|
||||
<H2>User-defined literals [partially done]</H2>
|
||||
<P>C++ has different suffix literals. eg. 12.5f marks the number 12.5
|
||||
as float.
|
||||
</P>
|
||||
<P>C++11 allows user to define his own suffix for the strings always
|
||||
starting with the underscore (_). eg. int a = "hello"_mySuffix;
|
||||
</P>
|
||||
<P>The syntax is similar to other operator overloading functions:
|
||||
</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm"> OutputType operator "" _mySuffix(const char * string_values);</PRE><P>
|
||||
The null terminated const char* is the string between the "".
|
||||
The _mySuffix is the name of the suffix operator. And the OutputType
|
||||
is the outputType the operator returns.
|
||||
</P>
|
||||
<P>Other forms are:
|
||||
</P>
|
||||
<PRE> OutputType operator "" _mySuffix(const char * string_values, size_t num_chars);
|
||||
OutputType operator "" _mySuffix(const wchar_t * string_values, size_t num_chars);
|
||||
OutputType operator "" _mySuffix(const char16_t * string_values, size_t num_chars);
|
||||
OutputType operator "" _mySuffix(const char32_t * string_values, size_t num_chars);
|
||||
OutputType operator "" _mySuffix(int value); /* cooked version - ie. atoi() of string */</PRE><P>
|
||||
Another possibility is to use variadic templates:
|
||||
</P>
|
||||
<PRE> template<char...> OutputType operator "" _mySuffix();
|
||||
OutputType someVariable = "1234"_mySuffix;</PRE><P>
|
||||
This instantiates the literal processing function as
|
||||
operator""_Suffix<'1', '2', '3', '4'>. In this form,
|
||||
there is no terminating null character to the string. The main
|
||||
purpose to doing this is to use C++11's constexpr keyword and the
|
||||
compiler to allow the literal to be transformed entirely at compile
|
||||
time, assuming OutputType is a constexpr-constructable and copyable
|
||||
type, and the literal processing function is a constexpr function.</P>
|
||||
<P>Article:
|
||||
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf</A></P>
|
||||
<P>Done: Added syntax support for userdefined literals. Added
|
||||
testcase cpp11_userdefined_literals.i. R11494</P>
|
||||
<P>TODO: %rename doesn't parse operator”” yet.</P>
|
||||
<H2>Thread-local storage [done]
|
||||
</H2>
|
||||
<P>New C++11 introduces keyword "thread_local" which marks
|
||||
the following variable dynamically located depending on the current
|
||||
thread when using the address-of (&) operator.
|
||||
</P>
|
||||
<P>Syntax:
|
||||
</P>
|
||||
<PRE> struct A {
|
||||
thread_local int val;
|
||||
};</PRE><P>
|
||||
Done: Add "thread_local" keyword to Swig. Added testcase
|
||||
cpp11_thread_local. R11393</P>
|
||||
<H2>Defaulting/deleting of standard functions on C++ objects [done]</H2>
|
||||
<P>C++ automatically creates default constructor with empty
|
||||
parameters, copy constructor, operator= and destructor for any class.
|
||||
Sometimes user wants to explicitly remove one of them or enable them
|
||||
(eg. default constructor with empty parameters doesn't work any more,
|
||||
if any other constructor is defined).
|
||||
</P>
|
||||
<P>Words "default" and "delete" are introduced.
|
||||
The syntax is similar to declaration of pure virtual function:
|
||||
</P>
|
||||
<PRE> struct NonCopyable {
|
||||
NonCopyable & operator=(const NonCopyable&) = delete; /* Removes operator= */
|
||||
NonCopyable(const NonCopyable&) = delete; /* Removed copy constructor */
|
||||
NonCopyable() = default; /* Explicitly allows the empty constructor */
|
||||
void *operator new(std::size_t) = delete; /* Removes new NonCopyable */
|
||||
};</PRE><P>
|
||||
User has the ability by using keyword delete to disallow calling of
|
||||
the standard functions brought by C++ itself.
|
||||
</P>
|
||||
<PRE> struct A1 {
|
||||
void f(int i);
|
||||
void f(double i) = delete; /* Don't cast double to int. Compiler returns an error */
|
||||
};
|
||||
struct A2 {
|
||||
void f(int i);
|
||||
template<class T> void f(T) = delete; /* Only accept int */
|
||||
};</PRE><P>
|
||||
Ignored: Swig already parses the keywords "= delete" and "=
|
||||
default". These keywords are used for built-in functions (copy
|
||||
constructor, operator= etc.), which are ignored by Swig anyway.</P>
|
||||
<P>Done: Added testcase cpp11_default_delete. R11535</P>
|
||||
<H2>Type long long int [done]</H2>
|
||||
<P>Type long long int is an integer type that has at least 64 useful
|
||||
bits. C99 added it to its standard, but the C++ didn't adopt it until
|
||||
C++11. Most C++ compilers supported it though.
|
||||
</P>
|
||||
<P>Done: Swig already parses the C code including the long long type.
|
||||
</P>
|
||||
<H2>Static assertions [done]</H2>
|
||||
<P>static_assert() can be used at class scope as well eg.:
|
||||
</P>
|
||||
<PRE> template <typename T>
|
||||
struct Check {
|
||||
static_assert(sizeof(int) <= sizeof(T), "not big enough");
|
||||
};</PRE><P>
|
||||
Done: Added syntax support for "static_assert()". Added
|
||||
test case cpp11_static_assert. R11369</P>
|
||||
<H2>Allow sizeof to work on members of classes without an explicit
|
||||
object [done]</H2>
|
||||
<P>C++11 allows calls of sizeof to concrete objects as well:
|
||||
</P>
|
||||
<PRE> struct A { int member; };
|
||||
sizeof(A::member); //Does not work with C++03. Okay with C++11</PRE><P>
|
||||
This kind of syntax is already supported by Swig.</P>
|
||||
<P>Done: Added testcase cpp11_sizeof_objects. R11538
|
||||
</P>
|
||||
<H2>Threading facilities [ignored]</H2>
|
||||
<P>C++11 will add the following classes to the standard library:
|
||||
</P>
|
||||
<PRE> * std::thread
|
||||
* std::mutex, std::recursive_mutex
|
||||
* std::condition_variable, std::condition_variable_any
|
||||
* std::lock_guard, std::unique_lock
|
||||
* std::packaged_task</PRE><P>
|
||||
Ignored: No changes to the language itself is made.
|
||||
</P>
|
||||
<H2>Tuple types [TODO]</H2>
|
||||
<P>Tuple is array of various types. C++11 introduced this feature
|
||||
using variadic templates. Tuple is defined as:</P>
|
||||
<PRE STYLE="margin-bottom: 0.5cm">template <class ...Types> class tuple;</PRE><P>
|
||||
Constructor is automatically generated filling the tuple elements.
|
||||
get<X> function is introduced to get the Xth element in the
|
||||
tuple.</P>
|
||||
<PRE>typedef tuple< int, double, long &, const char * > test_tuple ;
|
||||
long lengthy = 12 ;
|
||||
test_tuple proof( 18, 6.5, lengthy, "Ciao!" ) ;
|
||||
lengthy = get<0>(proof) ; // Assign to 'lengthy' the value 18.
|
||||
get<3>(proof) = " Beautiful!" ; // Modify the tuple’s fourth element.</PRE><P>
|
||||
Tuples can be copied to each other, if all the elements are copiable:</P>
|
||||
<PRE>typedef tuple< int , double, string > tuple_1 t1 ;
|
||||
typedef tuple< char, short , const char * > tuple_2 t2( 'X', 2, "Hola!" ) ;
|
||||
t1 = t2 ; // Ok, first two elements can be converted,
|
||||
// the third one can be constructed from a 'const char *'.</PRE><P>
|
||||
TODO: Implement wrappers for the tuplet<> class.</P>
|
||||
<H2>Hash tables [TODO]</H2>
|
||||
<P>C++11 introduces the "unordered" version of existing
|
||||
types, which in practice work faster than the linear types:
|
||||
</P>
|
||||
<PRE> - unordered set
|
||||
- unordered multiset
|
||||
- unordered map
|
||||
- unordered multimap</PRE><P>
|
||||
Swig should use the "unordered" types exactly the same as
|
||||
the original linear types.</P>
|
||||
<P>Problem: Unordered types do not contain exactly same members as
|
||||
ordered ones (eg. _Hashtable_iterator does not offer operator--() and
|
||||
constructor with compare function which is required). So simply
|
||||
aliasing unordered classes to ordered ones doesn't work.</P>
|
||||
<P>TODO: Implement wrappers for unordered_ types. Initial work is
|
||||
already done in Lib/std/unordered_*.i files.</P>
|
||||
<H2>Regular expressions [ignored]</H2>
|
||||
<P>Two new classes are introduced in C++11: basic_regex and
|
||||
match_results. Both are defined in regex header file.
|
||||
</P>
|
||||
<P>Ignored: The new feature extends the standardy library only. No
|
||||
changes to Swig needed.
|
||||
</P>
|
||||
<H2>General-purpose smart pointers [done]</H2>
|
||||
<P>This feature deprecates auto_ptr and adds shared_ptr, weak_ptr and
|
||||
unique_ptr to the standard library.
|
||||
</P>
|
||||
<P>This feature only adds the smart pointers to the standard library
|
||||
and doesn't effect the C++ syntax.</P>
|
||||
<P>Done: Added test case which uses all three smart pointers in the
|
||||
class. R11394</P>
|
||||
<P>Problem: GCC standard library doesn't contain the new smart
|
||||
pointers yet.
|
||||
</P>
|
||||
<H2>Extensible random number facility [ignored]</H2>
|
||||
<P>This feature standardize the pseudo random number algorithm
|
||||
(currently, the random number generator was dependent on the
|
||||
platform/compiler). It adds functions linear_congruential,
|
||||
subtract_with_carry and mersenne_twister and symbols
|
||||
uniform_int_distribution, bernoulli_distribution,
|
||||
geometric_distribution, poisson_distribution, binomial_distribution,
|
||||
uniform_real_distribution, exponential_distribution,
|
||||
normal_distribution and gamma_distribution to the standard library.
|
||||
</P>
|
||||
<P>Ignored: The new feature extends the standardy library only. No
|
||||
changes to Swig needed.
|
||||
</P>
|
||||
<H2>Wrapper reference [ignored]</H2>
|
||||
<P>This feature adds ref and cref classes to the standard library
|
||||
(#include <utility>) usually used in tempalte functions.
|
||||
</P>
|
||||
<P>Ignored: The new feature extends the standardy library only. No
|
||||
changes to Swig needed.
|
||||
</P>
|
||||
<H2>Polymorphous wrappers for function objects [done]</H2>
|
||||
<P>Two features are introduced:
|
||||
</P>
|
||||
<UL>
|
||||
<LI><P>The function template wrapper:
|
||||
</P>
|
||||
</UL>
|
||||
<PRE STYLE="margin-bottom: 0.5cm"> function<int ( int, int )> pF;</PRE>
|
||||
<UL>
|
||||
<LI><P>and the function object:
|
||||
</P>
|
||||
</UL>
|
||||
<PRE> struct Test {
|
||||
bool operator()( short x, short y );
|
||||
};</PRE><P>
|
||||
Swig already supports the two.</P>
|
||||
<P>Done: Added a runtime testcase for function objects
|
||||
cpp11_function_objects. R11419.</P>
|
||||
<H2>Type traits for metaprogramming [ignored]</H2>
|
||||
<P>C++11 adds a new header file <type_traits> which includes
|
||||
helper functions to determine the template type while initializing
|
||||
the object at compile time.
|
||||
</P>
|
||||
<P>Swig already supports the following code:
|
||||
</P>
|
||||
<PRE> template< int B, int N >
|
||||
struct Pow {
|
||||
// recursive call and recombination.
|
||||
enum{ value = B*Pow< B, N-1 >::value };
|
||||
};
|
||||
template< int B > struct Pow< B, 0 > // <EM>N == 0</EM> condition of termination.
|
||||
{
|
||||
enum{ value = 1 };
|
||||
};
|
||||
int quartic_of_three = Pow< 3, 4 >::value ;</PRE><P>
|
||||
Functions is_convertible, is_integral, is_integral_const etc. are
|
||||
part of the new header:
|
||||
</P>
|
||||
<PRE>// First way of operating.
|
||||
template< bool B > struct algorithm {
|
||||
template< class T1, class T2 > int do_it( T1 &, T2 & ) { /*...*/ }
|
||||
};
|
||||
// Second way of operating.
|
||||
template<> struct algorithm<true> {
|
||||
template< class T1, class T2 > int do_it( T1, T2 ) { /*...*/ }
|
||||
};
|
||||
// Instantiating 'elaborate' will automatically instantiate the correct way to operate.
|
||||
template< class T1, class T2 > int elaborate( T1 A, T2 B ) {
|
||||
// Use the second way only if 'T1' is an integer and if 'T2' is
|
||||
// in floating point, otherwise use the first way.
|
||||
return algorithm< is_integral<T1>::value && is_floating_point<T2>::value >::do_it( A, B );
|
||||
}</PRE><P>
|
||||
Swig correctly parses the syntax for template<bool>,
|
||||
template<class T> and template<>.
|
||||
</P>
|
||||
<P>Ignored: Swig requires explicitly defined template class
|
||||
(%template directive) to export it to the target language.</P>
|
||||
<H2>Uniform method for computing return type of function objects
|
||||
[partially done]</H2>
|
||||
<P>The template function is introduced: std::result_of() which
|
||||
depends on decltype:
|
||||
</P>
|
||||
<PRE>template< class Obj >
|
||||
class calculus_ver2 {
|
||||
public:
|
||||
template< class Arg >
|
||||
typename std::result_of<Obj(Arg)>::type operator()( Arg& a ) const {
|
||||
return member(a);
|
||||
}
|
||||
private:
|
||||
Obj member;
|
||||
};</PRE><P>
|
||||
Swig correctly parses the result_of class.</P>
|
||||
<P>TODO: The return type (the result_of::type member) is not
|
||||
calculated by Swig. This needs a much more complex semantic parser.</P>
|
||||
<P>Done: Added testcase cpp11_result_of. R11534</P>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -25,7 +25,7 @@
|
|||
<li><a name="i8" href="#8">8. Naming Conventions</a>
|
||||
<li><a name="i9" href="#9">9. Visibility</a>
|
||||
<li><a name="i10" href="#10">10. Miscellaneous Coding Guidelines</a>
|
||||
<li><a name="i11" href="#11">11. SVN Tagging Conventions</a>
|
||||
<li><a name="i11" href="#11">11. Git Tagging Conventions</a>
|
||||
</ul>
|
||||
|
||||
<a name="1" href="#i1">
|
||||
|
|
@ -119,8 +119,8 @@ are case-insensitive on Windows so this convention will prevent you from inadver
|
|||
creating two files that differ in case-only.
|
||||
|
||||
<p>
|
||||
Each file should include a short abstract, license information and
|
||||
a SVN revision tag like this:
|
||||
Each file should include a short abstract and license information
|
||||
like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
|
|
@ -137,8 +137,6 @@ a SVN revision tag like this:
|
|||
* This file defines ...
|
||||
* ----------------------------------------------------------------------------- */
|
||||
|
||||
static char cvs[] = "$Id$";
|
||||
|
||||
#include "swig.h"
|
||||
|
||||
/* Declarations */
|
||||
|
|
@ -159,12 +157,6 @@ static int avariable;
|
|||
</pre>
|
||||
</blockquote>
|
||||
|
||||
The SVN revision tag should be placed into a static string as shown
|
||||
above mangled with the name of the file.
|
||||
This adds the revision information to the SWIG executable and
|
||||
makes it possible to extract version information from a raw binary
|
||||
(sometimes useful in debugging).
|
||||
|
||||
<p>
|
||||
As a general rule, files start to get unmanageable once they exceed
|
||||
about 2000 lines. Files larger than this should be broken up into
|
||||
|
|
@ -379,10 +371,10 @@ making your changes.
|
|||
These are largely covered in the main documentation in the Extending.html file.
|
||||
|
||||
<a name="11" href="#i11">
|
||||
<h2>11. SVN Tagging Conventions</h2>
|
||||
<h2>11. Git Tagging Conventions</h2>
|
||||
</a>
|
||||
|
||||
Use <tt>svn tag</tt> to declare some set of file revisions as related in some
|
||||
Use <tt>git tag</tt> to declare some set of file revisions as related in some
|
||||
symbolic way. This eases reference, retrieval and manipulation of these files
|
||||
later. At the moment (2001/01/16 14:02:53), the conventions are very simple;
|
||||
let's hope they stay that way!
|
||||
|
|
@ -390,10 +382,10 @@ let's hope they stay that way!
|
|||
<p>
|
||||
There are two types of tags, internal (aka personal) and external.
|
||||
Internal tags are used by SWIG developers primarily, whereas external
|
||||
tags are used when communicating with people w/ anonymous svn access.
|
||||
tags are used when communicating with people w/ anonymous git access.
|
||||
<ul>
|
||||
<li> Internal tags should start with the developer name and a hyphen.
|
||||
<li> External tags should start with "v-".
|
||||
<li> External tags should start with "rel-".
|
||||
</ul>
|
||||
|
||||
That's all there is to it. Some example tags:
|
||||
|
|
@ -402,10 +394,8 @@ That's all there is to it. Some example tags:
|
|||
<li> ttn-pre-xml-patch
|
||||
<li> ttn-post-xml-patch
|
||||
<li> ttn-going-on-vacation-so-dutifully-tagging-now
|
||||
<li> v-1-3-a37-fixes-bug-2432
|
||||
<li> v-1-3-a37-fixes-bug-2433
|
||||
<li> v-1-3-a37-fixes-bug-2432-again
|
||||
<li> v-1-3-a37-release
|
||||
<li> rel-1.3.40
|
||||
<li> rel-2.0.9
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
|
|
|||
|
|
@ -42,6 +42,7 @@
|
|||
<li><a name="i7" href="#7">7. Debugging SWIG</a>
|
||||
<ul>
|
||||
<li><a name="i7.1" href="#7.1">7.1 Debugging DOH Types The Hard Way</a>
|
||||
<li><a name="i7.2" href="#7.2">7.2 Debugging DOH memory allocation problems</a>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
|
|
@ -346,7 +347,7 @@ Delete(a); /* Destroy a */
|
|||
|
||||
All objects are referenced counted and given a reference count of 1 when initially created. The
|
||||
<tt>Delete()</tt> function only destroys an object when the reference count reaches zero. When
|
||||
an object is placed in a list or hash table, it's reference count is automatically increased. For example:
|
||||
an object is placed in a list or hash table, its reference count is automatically increased. For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
|
|
@ -843,7 +844,7 @@ Returns a type object corresponding to the type string produced by the Swig_cloc
|
|||
<li><tt>char *Swig_clocal_deref(DataType *t, char *name)</tt><br>
|
||||
This function is the inverse of the <tt>clocal()</tt> function. Given a type and a name,
|
||||
it produces a string containing the code needed to cast/convert the type produced by
|
||||
<tt>Swig_clocal()</tt> back into it's original type.
|
||||
<tt>Swig_clocal()</tt> back into its original type.
|
||||
|
||||
<p>
|
||||
<li><tt>char *Swig_clocal_assign(DataType *t, char *name)</tt><br>
|
||||
|
|
@ -1179,6 +1180,34 @@ Either <br>
|
|||
|
||||
</ul>
|
||||
|
||||
<a name="7.2" href="#i7.2">
|
||||
<h3>7.2 Debugging DOH memory allocation problems</h3>
|
||||
</a>
|
||||
|
||||
<p>
|
||||
The DOH objects are reference counted and use pools for memory allocation.
|
||||
The implementation is in <tt>memory.c</tt>. When there are memory corruption problems,
|
||||
various memory allocator tools are normally used to diagnose problems. These can be used
|
||||
on SWIG and can be very useful. However, they won't necessarily find use of stale DOH objects,
|
||||
that is, DOH objects
|
||||
that are used after they have been deleted. This is because the DOH memory allocator
|
||||
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...
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
swig: DOH/memory.c:91: DohCheck: Assertion `!DOH_object_already_deleted' failed.
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
This can be memory intensive as previously used memory in the pool is not re-used so is
|
||||
only recommended for diagnosing memory corruption problems.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
Copyright (C) 1999-2010 SWIG Development Team.
|
||||
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ this function merely records that those attributes did not exist in the original
|
|||
<blockquote>
|
||||
This function is similar to <tt>Swig_save()</tt> except that adds additional attribute checking. There are different interpretations
|
||||
of the attribute names. A name of "attr" merely requests that the function check for the presence of an attribute. If the attribute is missing, SWIG will exit with a failed assertion. An attribute name of "?attr" specifies that the attribute "attr" is optional and
|
||||
that it's old value must be saved (if any). An attribute name of "*attr" specifies that the attribute is required and that
|
||||
that its old value must be saved (if any). An attribute name of "*attr" specifies that the attribute is required and that
|
||||
its value must be saved. The saving of attributes is performed in the same manner as with <tt>Swig_save()</tt>. Here is an example:
|
||||
|
||||
<pre>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Allegrocl"></a>17 SWIG and Allegro Common Lisp</H1>
|
||||
<H1><a name="Allegrocl"></a>18 SWIG and Allegro Common Lisp</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -135,10 +135,10 @@ be unhappy to see some enterprising folk use this work to add
|
|||
to it.
|
||||
</p>
|
||||
|
||||
<H2><a name="Allegrocl_nn2"></a>17.1 Basics</H2>
|
||||
<H2><a name="Allegrocl_nn2"></a>18.1 Basics</H2>
|
||||
|
||||
|
||||
<H3><a name="Allegrocl_nn3"></a>17.1.1 Running SWIG</H3>
|
||||
<H3><a name="Allegrocl_nn3"></a>18.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -360,7 +360,7 @@ need to link in the Allegro shared library. The library you create from
|
|||
the C++ wrapper will be what you then load into Allegro CL.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn4"></a>17.1.2 Command Line Options</H3>
|
||||
<H3><a name="Allegrocl_nn4"></a>18.1.2 Command Line Options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -396,7 +396,7 @@ See <a href="#Allegrocl_nn47">Section 17.5 Identifier converter
|
|||
functions</a> for more details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn5"></a>17.1.3 Inserting user code into generated files</H3>
|
||||
<H3><a name="Allegrocl_nn5"></a>18.1.3 Inserting user code into generated files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -436,7 +436,7 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Allegrocl_nn6"></a>17.2 Wrapping Overview</H2>
|
||||
<H2><a name="Allegrocl_nn6"></a>18.2 Wrapping Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -446,7 +446,7 @@ New users to SWIG are encouraged to read
|
|||
interested in generating an interface to C++.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn7"></a>17.2.1 Function Wrapping</H3>
|
||||
<H3><a name="Allegrocl_nn7"></a>18.2.1 Function Wrapping</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -499,7 +499,7 @@ interested in generating an interface to C++.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn8"></a>17.2.2 Foreign Wrappers</H3>
|
||||
<H3><a name="Allegrocl_nn8"></a>18.2.2 Foreign Wrappers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -512,7 +512,7 @@ interested in generating an interface to C++.
|
|||
typemap.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn9"></a>17.2.3 FFI Wrappers</H3>
|
||||
<H3><a name="Allegrocl_nn9"></a>18.2.3 FFI Wrappers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -593,7 +593,7 @@ char *xxx();
|
|||
ff:def-foreign-call's.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn10"></a>17.2.4 Non-overloaded Defuns</H3>
|
||||
<H3><a name="Allegrocl_nn10"></a>18.2.4 Non-overloaded Defuns</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -606,7 +606,7 @@ char *xxx();
|
|||
this function can be manipulated via the <tt>lout</tt> typemap.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn11"></a>17.2.5 Overloaded Defuns</H3>
|
||||
<H3><a name="Allegrocl_nn11"></a>18.2.5 Overloaded Defuns</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -622,7 +622,7 @@ char *xxx();
|
|||
can be manipulated via the <tt>lout</tt> typemap.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn12"></a>17.2.6 What about constant and variable access?</H3>
|
||||
<H3><a name="Allegrocl_nn12"></a>18.2.6 What about constant and variable access?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -635,7 +635,7 @@ char *xxx();
|
|||
into the foreign module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn13"></a>17.2.7 Object Wrapping</H3>
|
||||
<H3><a name="Allegrocl_nn13"></a>18.2.7 Object Wrapping</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -657,7 +657,7 @@ char *xxx();
|
|||
foreign function interface.
|
||||
</p>
|
||||
|
||||
<H2><a name="Allegrocl_nn14"></a>17.3 Wrapping Details</H2>
|
||||
<H2><a name="Allegrocl_nn14"></a>18.3 Wrapping Details</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -665,7 +665,7 @@ char *xxx();
|
|||
translated into lisp.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn15"></a>17.3.1 Namespaces</H3>
|
||||
<H3><a name="Allegrocl_nn15"></a>18.3.1 Namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -742,13 +742,13 @@ namespace car {
|
|||
function such as <tt>(car '(1 2 3)</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn16"></a>17.3.2 Constants</H3>
|
||||
<H3><a name="Allegrocl_nn16"></a>18.3.2 Constants</H3>
|
||||
|
||||
|
||||
|
||||
<p>
|
||||
Constants, as declared by the preprocessor #define macro or SWIG
|
||||
<tt>%constant</tt> directive, are included in SWIGs parse tree
|
||||
<tt>%constant</tt> directive, are included in SWIG's parse tree
|
||||
when it can be determined that they are, or could be reduced to,
|
||||
a literal value. Such values are translated into defconstant
|
||||
forms in the generated lisp wrapper when the -nocwrap command-line
|
||||
|
|
@ -803,7 +803,7 @@ namespace car {
|
|||
not use the <tt>-nocwrap</tt> command-line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn17"></a>17.3.3 Variables</H3>
|
||||
<H3><a name="Allegrocl_nn17"></a>18.3.3 Variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -881,13 +881,13 @@ globalvar> (globalvar.nnn::glob_float)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn18"></a>17.3.4 Enumerations</H3>
|
||||
<H3><a name="Allegrocl_nn18"></a>18.3.4 Enumerations</H3>
|
||||
|
||||
|
||||
<p>
|
||||
In C, an enumeration value is an integer value, while in C++ an
|
||||
enumeration value is implicitly convertible to an integer value,
|
||||
but can also be distinguished by it's enum type. For each enum
|
||||
but can also be distinguished by its enum type. For each enum
|
||||
declaration a def-foreign-type is generated, assigning the enum
|
||||
a default type of :int. Users may adjust the foreign type of
|
||||
enums via SWIG <tt>typemaps</tt>.
|
||||
|
|
@ -901,7 +901,7 @@ globalvar> (globalvar.nnn::glob_float)
|
|||
of it not being necessary to probe into foreign space to retrieve enum
|
||||
values. When generating a .cxx wrapper file, a more general solution is
|
||||
employed. A wrapper variable is created in the module_wrap.cxx file, and
|
||||
a ff:def-foreign-variable call is generated to retrieve it's value into lisp.
|
||||
a ff:def-foreign-variable call is generated to retrieve its value into lisp.
|
||||
</p>
|
||||
|
||||
<p>For example, the following header file
|
||||
|
|
@ -957,7 +957,7 @@ EXPORT const int ACL_ENUM___FOO3__SWIG_0 = FOO3;
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn19"></a>17.3.5 Arrays</H3>
|
||||
<H3><a name="Allegrocl_nn19"></a>18.3.5 Arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1105,10 +1105,10 @@ namespace BAR {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn20"></a>17.3.6 Classes and Structs and Unions (oh my!)</H3>
|
||||
<H3><a name="Allegrocl_nn20"></a>18.3.6 Classes and Structs and Unions (oh my!)</H3>
|
||||
|
||||
|
||||
<H4><a name="Allegrocl_nn21"></a>17.3.6.1 CLOS wrapping of</H4>
|
||||
<H4><a name="Allegrocl_nn21"></a>18.3.6.1 CLOS wrapping of</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1118,12 +1118,12 @@ namespace BAR {
|
|||
function that returns an object (or pointer/reference) of C/C++
|
||||
type <tt>X</tt>, the wrapping defun (or defmethod) on the Lisp
|
||||
side will automatically wrap the pointer returned in an instance
|
||||
of the apropriate class. This makes it much easier to write and
|
||||
of the appropriate class. This makes it much easier to write and
|
||||
debug code than if pointers were passed around as a jumble of
|
||||
integer values.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn22"></a>17.3.6.2 CLOS Inheritance</H4>
|
||||
<H4><a name="Allegrocl_nn22"></a>18.3.6.2 CLOS Inheritance</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1131,12 +1131,12 @@ namespace BAR {
|
|||
inheritance of the classes in foreign code, with the
|
||||
ff:foreign-pointer class at its root. ff:foreign-pointer is a thin
|
||||
wrapper for pointers that is made available by the foreign function
|
||||
interface. It's key benefit is that it may be passed as an argument
|
||||
interface. Its key benefit is that it may be passed as an argument
|
||||
to any ff:def-foreign-call that is expecting a pointer as the
|
||||
parameter.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn23"></a>17.3.6.3 Member fields and functions</H4>
|
||||
<H4><a name="Allegrocl_nn23"></a>18.3.6.3 Member fields and functions</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1152,7 +1152,7 @@ namespace BAR {
|
|||
the interface does nothing for <tt>friend</tt> directives,
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn24"></a>17.3.6.4 Why not directly access C++ classes using foreign types?</H4>
|
||||
<H4><a name="Allegrocl_nn24"></a>18.3.6.4 Why not directly access C++ classes using foreign types?</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1170,11 +1170,11 @@ namespace BAR {
|
|||
use the more robust wrapper functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn25"></a>17.3.7 Templates</H3>
|
||||
<H3><a name="Allegrocl_nn25"></a>18.3.7 Templates</H3>
|
||||
|
||||
|
||||
|
||||
<H4><a name="Allegrocl_nn26"></a>17.3.7.1 Generating wrapper code for templates</H4>
|
||||
<H4><a name="Allegrocl_nn26"></a>18.3.7.1 Generating wrapper code for templates</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1187,7 +1187,7 @@ namespace BAR {
|
|||
directive.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn27"></a>17.3.7.2 Implicit Template instantiation</H4>
|
||||
<H4><a name="Allegrocl_nn27"></a>18.3.7.2 Implicit Template instantiation</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1197,7 +1197,7 @@ namespace BAR {
|
|||
class schema.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn28"></a>17.3.8 Typedef, Templates, and Synonym Types</H3>
|
||||
<H3><a name="Allegrocl_nn28"></a>18.3.8 Typedef, Templates, and Synonym Types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1277,7 +1277,7 @@ synonym>
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn29"></a>17.3.8.1 Choosing a primary type</H4>
|
||||
<H4><a name="Allegrocl_nn29"></a>18.3.8.1 Choosing a primary type</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1298,7 +1298,7 @@ synonym>
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Allegrocl_nn30"></a>17.3.9 Function overloading/Parameter defaulting</H3>
|
||||
<H3><a name="Allegrocl_nn30"></a>18.3.9 Function overloading/Parameter defaulting</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1461,7 +1461,7 @@ overload>
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn31"></a>17.3.10 Operator wrapping and Operator overloading</H3>
|
||||
<H3><a name="Allegrocl_nn31"></a>18.3.10 Operator wrapping and Operator overloading</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1607,28 +1607,28 @@ opoverload>
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn32"></a>17.3.11 Varargs</H3>
|
||||
<H3><a name="Allegrocl_nn32"></a>18.3.11 Varargs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Variable length argument lists are not supported, by default. If
|
||||
such a function is encountered, a warning will generated to
|
||||
stderr. Varargs are supported via the SWIG <tt>%vararg</tt>
|
||||
stderr. Varargs are supported via the SWIG <tt>%varargs</tt>
|
||||
directive. This directive allows you to specify a (finite)
|
||||
argument list which will be inserted into the wrapper in place
|
||||
of the variable length argument indicator. As an example,
|
||||
consider the function <tt>printf()</tt>. It's declaration would
|
||||
consider the function <tt>printf()</tt>. Its declaration would
|
||||
appear as follows:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
See the following section
|
||||
on <a href="Varargs.html#Varargs">Variable Length arguments</a>
|
||||
provides examples on how <tt>%vararg</tt> can be used, along
|
||||
provides examples on how <tt>%varargs</tt> can be used, along
|
||||
with other ways such functions can be wrapped.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn33"></a>17.3.12 C++ Exceptions</H3>
|
||||
<H3><a name="Allegrocl_nn33"></a>18.3.12 C++ Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1640,7 +1640,7 @@ opoverload>
|
|||
implemented.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn34"></a>17.3.13 Pass by value, pass by reference</H3>
|
||||
<H3><a name="Allegrocl_nn34"></a>18.3.13 Pass by value, pass by reference</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1652,7 +1652,7 @@ opoverload>
|
|||
newly defined types.
|
||||
</p>
|
||||
|
||||
<H2><a name="Allegrocl_nn35"></a>17.4 Typemaps</H2>
|
||||
<H2><a name="Allegrocl_nn35"></a>18.4 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1663,7 +1663,7 @@ opoverload>
|
|||
on <a href="Typemaps.html#Typemaps">Typemaps</a> for more information.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn36"></a>17.4.1 Code Generation in the C++ Wrapper</H3>
|
||||
<H3><a name="Allegrocl_nn36"></a>18.4.1 Code Generation in the C++ Wrapper</H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -1693,7 +1693,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn37"></a>17.4.1.1 IN Typemap</H4>
|
||||
<H4><a name="Allegrocl_nn37"></a>18.4.1.1 IN Typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1728,14 +1728,14 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn38"></a>17.4.1.2 OUT Typemap</H4>
|
||||
<H4><a name="Allegrocl_nn38"></a>18.4.1.2 OUT Typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
The <tt>out</tt> typemap is used to generate code to form the
|
||||
return value of the wrapper from the return value of the wrapped
|
||||
function. This code is placed in the <convert and bind result to lresult>
|
||||
section of the above code diagram. It's default mapping is as follows:
|
||||
section of the above code diagram. Its default mapping is as follows:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -1752,13 +1752,13 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn39"></a>17.4.1.3 CTYPE Typemap</H4>
|
||||
<H4><a name="Allegrocl_nn39"></a>18.4.1.3 CTYPE Typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
This typemap is not used for code generation, but purely for the
|
||||
transformation of types in the parameter list of the wrapper function.
|
||||
It's primary use is to handle by-value to by-reference conversion in the
|
||||
Its primary use is to handle by-value to by-reference conversion in the
|
||||
wrappers parameter list. Its default settings are:
|
||||
</p>
|
||||
|
||||
|
|
@ -1784,7 +1784,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
these <a href="Typemaps.html#Typemaps_nn25">common typemaps</a> here.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn40"></a>17.4.2 Code generation in Lisp wrappers</H3>
|
||||
<H3><a name="Allegrocl_nn40"></a>18.4.2 Code generation in Lisp wrappers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1803,7 +1803,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
<a href="#Allegrocl_nn15">16.3.1 Namespaces</a> for details.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn41"></a>17.4.2.1 LIN Typemap</H4>
|
||||
<H4><a name="Allegrocl_nn41"></a>18.4.2.1 LIN Typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1846,7 +1846,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn42"></a>17.4.2.2 LOUT Typemap</H4>
|
||||
<H4><a name="Allegrocl_nn42"></a>18.4.2.2 LOUT Typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1889,7 +1889,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn43"></a>17.4.2.3 FFITYPE Typemap</H4>
|
||||
<H4><a name="Allegrocl_nn43"></a>18.4.2.3 FFITYPE Typemap</H4>
|
||||
|
||||
|
||||
|
||||
|
|
@ -1939,7 +1939,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn44"></a>17.4.2.4 LISPTYPE Typemap</H4>
|
||||
<H4><a name="Allegrocl_nn44"></a>18.4.2.4 LISPTYPE Typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1959,7 +1959,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Allegrocl_nn45"></a>17.4.2.5 LISPCLASS Typemap</H4>
|
||||
<H4><a name="Allegrocl_nn45"></a>18.4.2.5 LISPCLASS Typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1983,7 +1983,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Allegrocl_nn46"></a>17.4.3 Modifying SWIG behavior using typemaps</H3>
|
||||
<H3><a name="Allegrocl_nn46"></a>18.4.3 Modifying SWIG behavior using typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2017,10 +2017,10 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Allegrocl_nn47"></a>17.5 Identifier Converter functions</H2>
|
||||
<H2><a name="Allegrocl_nn47"></a>18.5 Identifier Converter functions</H2>
|
||||
|
||||
|
||||
<H3><a name="Allegrocl_nn48"></a>17.5.1 Creating symbols in the lisp environment</H3>
|
||||
<H3><a name="Allegrocl_nn48"></a>18.5.1 Creating symbols in the lisp environment</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2041,11 +2041,11 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
of arguments.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn49"></a>17.5.2 Existing identifier-converter functions</H3>
|
||||
<H3><a name="Allegrocl_nn49"></a>18.5.2 Existing identifier-converter functions</H3>
|
||||
|
||||
|
||||
<p>Two basic identifier routines have been defined.
|
||||
<H4><a name="Allegrocl_nn50"></a>17.5.2.1 identifier-convert-null</H4>
|
||||
<H4><a name="Allegrocl_nn50"></a>18.5.2.1 identifier-convert-null</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2054,7 +2054,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
strings, from which a symbol will be created.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn51"></a>17.5.2.2 identifier-convert-lispify</H4>
|
||||
<H4><a name="Allegrocl_nn51"></a>18.5.2.2 identifier-convert-lispify</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2063,7 +2063,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
same symbol transformations.
|
||||
</p>
|
||||
|
||||
<H4><a name="Allegrocl_nn52"></a>17.5.2.3 Default identifier to symbol conversions</H4>
|
||||
<H4><a name="Allegrocl_nn52"></a>18.5.2.3 Default identifier to symbol conversions</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2072,7 +2072,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
default naming conventions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn53"></a>17.5.3 Defining your own identifier-converter</H3>
|
||||
<H3><a name="Allegrocl_nn53"></a>18.5.3 Defining your own identifier-converter</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2093,7 +2093,7 @@ foreign environment.
|
|||
|
||||
<p>
|
||||
The :type keyword argument provides more information on the type of
|
||||
identifier. It's value is a symbol. This allows the
|
||||
identifier. Its value is a symbol. This allows the
|
||||
identifier-converter to apply different heuristics when mapping
|
||||
different types of identifiers to symbols. SWIG will generate calls
|
||||
to your identifier-converter using the following types.
|
||||
|
|
@ -2123,12 +2123,12 @@ scope in the specified class.
|
|||
|
||||
<p>
|
||||
The :arity keyword argument only appears in swig:swig-defmethod forms
|
||||
generated for overloaded functions. It's value is an integer
|
||||
generated for overloaded functions. Its value is an integer
|
||||
indicating the number of arguments passed to the routine indicated by
|
||||
this identifier.
|
||||
</p>
|
||||
|
||||
<H3><a name="Allegrocl_nn54"></a>17.5.4 Instructing SWIG to use a particular identifier-converter</H3>
|
||||
<H3><a name="Allegrocl_nn54"></a>18.5.4 Instructing SWIG to use a particular identifier-converter</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue