Merged trunk up to revision 12551
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/branches/szager-python-builtin@12552 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Stefan Zager
commit
93499e12af
160 changed files with 3204 additions and 1238 deletions
|
|
@ -900,6 +900,7 @@
|
|||
<li><a href="Java.html#Java_simple_pointers">Simple pointers</a>
|
||||
<li><a href="Java.html#Java_c_arrays">Wrapping C arrays with Java arrays</a>
|
||||
<li><a href="Java.html#Java_unbounded_c_arrays">Unbounded C Arrays</a>
|
||||
<li><a href="Java.html#Java_binary_char">Binary data vs Strings</a>
|
||||
<li><a href="Java.html#Java_heap_allocations">Overriding new and delete to allocate from Java heap</a>
|
||||
</ul>
|
||||
<li><a href="Java.html#Java_typemaps">Java typemaps</a>
|
||||
|
|
@ -1063,12 +1064,14 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Mzscheme.html#Mzscheme">27 SWIG and MzScheme</a></h3>
|
||||
<h3><a href="Mzscheme.html#Mzscheme">27 SWIG and MzScheme/Racket</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Mzscheme.html#MzScheme_nn2">Creating native MzScheme structures</a>
|
||||
<li><a href="Mzscheme.html#MzScheme_nn2">Creating native structures</a>
|
||||
<li><a href="Mzscheme.html#MzScheme_simple">Simple example</a>
|
||||
<li><a href="Mzscheme.html#MzScheme_external_docs">External documentation</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
|
|||
|
|
@ -28,6 +28,7 @@
|
|||
<li><a href="#D_directors">D Directors</a>
|
||||
<li><a href="#D_other_features">Other features</a>
|
||||
<ul>
|
||||
<li><a href="#D_nspace">Extended namespace support (<tt>nspace</tt>)</a></li>
|
||||
<li><a href="#D_native_pointer_support">Native pointer support</a>
|
||||
<li><a href="#D_operator_overloading">Operator overloading</a>
|
||||
<li><a href="#D_test_suite">Running the test-suite</a>
|
||||
|
|
@ -187,6 +188,12 @@
|
|||
<p>There are two other variants available, <tt>$&dclassname</tt> and <tt>$*dclassname</tt>. The former adds a level of indirection, while the latter removes one. For instance, when wrapping <tt>Foo **</tt>, <tt>$*dclassname</tt> would be replaced by the proxy class name corresponding to <tt>Foo *</tt>.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>$dclazzname</tt> (C#: <tt>$csclazzname</tt>)</dt>
|
||||
<dd>
|
||||
<p>This special variable expands the fully qualified C++ class into the package name, if used by the <a href="SWIGPlus.html#SWIGPlus_nspace"><tt>nspace</tt> feature</a>, and the proxy class name, mangled for use as a function name. For example, <tt>Namespace1::Namespace2::Klass</tt> is expanded into <tt>Namespace1_Namespace2_Klass_</tt>.</p>
|
||||
<p>This special variable might be useful for calling certain functions in the wrapper layer (e.g. upcast wrappers) which are mangled like this.</p>
|
||||
</dd>
|
||||
|
||||
<dt><tt>$null</tt></dt>
|
||||
<dd><p>In code inserted into the generated C/C++ wrapper functions, this variable is replaced by either <tt>0</tt> or nothing at all, depending on whether the function has a return value or not. It can be used to bail out early e.g. in case of errors (<tt>return $null;</tt>).</p></dd>
|
||||
|
||||
|
|
@ -249,7 +256,7 @@ SomeClass bar() {
|
|||
<p>This macro is only valid inside the <tt><a href="D.html#D_class_code_typemaps">dconstructor</a></tt> typemap and contains the value of the <tt>dconstructor</tt> typemap attribute if the currently wrapped class has directors enabled.</p>
|
||||
<p>This is how the default <tt>dconstructor</tt> typemap looks like (you usually do not want to specify a custom one):</p>
|
||||
<div class="code"><pre>
|
||||
%typemap(dconstructor, excode=SWIGEXCODE,
|
||||
%typemap(dconstructor, excode=SWIGEXCODE,
|
||||
directorconnect="\n swigDirectorConnect();") SWIGTYPE {
|
||||
this($imcall, true);$excode$directorconnect
|
||||
}
|
||||
|
|
@ -331,7 +338,7 @@ struct A {
|
|||
<dd><p>Additional code to be emitted to the imports section of the intermediary D module (the <a href="D.html#D_importtype">$importtype</a> macro can be used here). You probably want to use this in conjunction with the <tt>imdmodulecode</tt> pragma.</p></dd>
|
||||
|
||||
<dt><tt>%pragma(d) proxydmodulecode</tt></dt>
|
||||
<dd><p>Just like <tt>proxydmodulecode</tt>, the argument is copied to the proxy D module (if SWIG is in <a href="D.html#D_splitproxy">split proxy mode</a>, it is emitted to the main proxy D module only).</p></dd>
|
||||
<dd><p>Just like <tt>proxydmodulecode</tt>, the argument is copied to the proxy D module (if SWIG is in <a href="D.html#D_splitproxy">split proxy mode</a> and/or the <tt>nspace</tt> feature is used, it is emitted to the main proxy D module only).</p></dd>
|
||||
|
||||
<dt><tt>%pragma(d) globalproxyimports</tt></dt>
|
||||
<dd>
|
||||
|
|
@ -379,10 +386,13 @@ struct A {
|
|||
<H2><a name="D_other_features"></a>20.8 Other features</H2>
|
||||
|
||||
|
||||
<p>The <a href="SWIGPlus.html#SWIGPlus_nspace"><tt>nspace</tt></a> feature of SWIG is not yet supported for D - all class modules are written to the same package, regardless of which C++ namespace they are in.</p>
|
||||
<H3><a name="D_nspace"></a>20.8.1 Extended namespace support (<tt>nspace</tt>)</H3>
|
||||
|
||||
|
||||
<H3><a name="D_native_pointer_support"></a>20.8.1 Native pointer support</H3>
|
||||
<p>By default, SWIG flattens all C++ namespaces into a single target language namespace, but as for Java and C#, the <a href="SWIGPlus.html#SWIGPlus_nspace"><tt>nspace</tt></a> feature is supported for D. If it is active, C++ namespaces are mapped to D packages/modules. Note, however, that like for the other languages, <em>free</em> variables and functions are not supported yet; currently, they are all allows written to the main proxy D module.</p>
|
||||
|
||||
|
||||
<H3><a name="D_native_pointer_support"></a>20.8.2 Native pointer support</H3>
|
||||
|
||||
|
||||
<p>Contrary to many of the scripting languages supported by SWIG, D fully supports C-style pointers. The D module thus includes a custom mechanism to wrap C pointers directly as D pointers where applicable, that is, if the type that is pointed to is represented the same in C and D (on the bit-level), dubbed a »primtive type« below.</p>
|
||||
|
|
@ -394,7 +404,7 @@ struct A {
|
|||
<p>To determine if a type should be considered primitive, the <tt>cprimitive</tt> attribute on its <tt>dtype</tt> attribute is used. For example, the <tt>dtype</tt> typemap for <tt>float</tt> has <tt>cprimitive="1"</tt>, so the code from the <tt>nativepointer</tt> attribute is taken into account e.g. for <tt>float **</tt> or the function pointer <tt>float (*)(float *)</tt>.</p>
|
||||
|
||||
|
||||
<H3><a name="D_operator_overloading"></a>20.8.2 Operator overloading</H3>
|
||||
<H3><a name="D_operator_overloading"></a>20.8.3 Operator overloading</H3>
|
||||
|
||||
|
||||
<p>The D module comes with basic operator overloading support for both D1 and D2. There are, however, a few limitations arising from conceptual differences between C++ and D:</p>
|
||||
|
|
@ -406,7 +416,7 @@ struct A {
|
|||
<p>There are also some cases where the operators can be translated to D, but the differences in the implementation details are big enough that a rather involved scheme would be required for automatic wrapping them, which has not been implemented yet. This affects, for example, the array subscript operator, <tt>[]</tt>, in combination with assignments - while <tt>operator []</tt> in C++ simply returns a reference which is then written to, D resorts to a separate <tt>opIndexAssign</tt> method -, or implicit casting (which was introduced in D2 via <tt>alias this</tt>). Despite the lack of automatic support, manually handling these cases should be perfectly possible.</p>
|
||||
|
||||
|
||||
<H3><a name="D_test_suite"></a>20.8.3 Running the test-suite</H3>
|
||||
<H3><a name="D_test_suite"></a>20.8.4 Running the test-suite</H3>
|
||||
|
||||
|
||||
<p>As with any other language, the SWIG test-suite can be built for D using the <tt>*-d-test-suite</tt> targets of the top-level Makefile. By default, D1 is targeted, to build it with D2, use the optional <tt>D_VERSION</tt> variable, e.g. <tt>make check-d-test-suite D_VERSION=2</tt>.</p>
|
||||
|
|
|
|||
|
|
@ -101,6 +101,7 @@
|
|||
<li><a href="#Java_simple_pointers">Simple pointers</a>
|
||||
<li><a href="#Java_c_arrays">Wrapping C arrays with Java arrays</a>
|
||||
<li><a href="#Java_unbounded_c_arrays">Unbounded C Arrays</a>
|
||||
<li><a href="#Java_binary_char">Binary data vs Strings</a>
|
||||
<li><a href="#Java_heap_allocations">Overriding new and delete to allocate from Java heap</a>
|
||||
</ul>
|
||||
<li><a href="#Java_typemaps">Java typemaps</a>
|
||||
|
|
@ -4401,7 +4402,8 @@ well suited for applications in which you need to create buffers,
|
|||
package binary data, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_binary_char"></a>Binary data vs Strings</H3>
|
||||
<H3><a name="Java_binary_char"></a>23.8.5 Binary data vs Strings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
By default SWIG handles <tt>char *</tt> as a string but there is a handy multi-argument typemap available as mentioned in <a href="Library.html#Library_nn10">Passing binary data</a>.
|
||||
|
|
@ -4444,7 +4446,7 @@ len: 5 data: 68 69 0 6a 6b
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Java_heap_allocations"></a>23.8.5 Overriding new and delete to allocate from Java heap</H3>
|
||||
<H3><a name="Java_heap_allocations"></a>23.8.6 Overriding new and delete to allocate from Java heap</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -2,17 +2,19 @@
|
|||
<!-- Hand-written HTML -->
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG and MzScheme</title>
|
||||
<title>SWIG and MzScheme/Racket</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Mzscheme"></a>27 SWIG and MzScheme</H1>
|
||||
<H1><a name="Mzscheme"></a>27 SWIG and MzScheme/Racket</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#MzScheme_nn2">Creating native MzScheme structures</a>
|
||||
<li><a href="#MzScheme_nn2">Creating native structures</a>
|
||||
<li><a href="#MzScheme_simple">Simple example</a>
|
||||
<li><a href="#MzScheme_external_docs">External documentation</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -20,9 +22,9 @@
|
|||
|
||||
|
||||
<p>
|
||||
This section contains information on SWIG's support of MzScheme.
|
||||
This section contains information on SWIG's support of Racket, formally known as MzScheme.
|
||||
|
||||
<H2><a name="MzScheme_nn2"></a>27.1 Creating native MzScheme structures</H2>
|
||||
<H2><a name="MzScheme_nn2"></a>27.1 Creating native structures</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -63,8 +65,116 @@ Then in scheme, you can use regular struct access procedures like
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="MzScheme_simple"></a>27.2 Simple example</H2>
|
||||
|
||||
|
||||
<p>
|
||||
That's pretty much it. It works with nested structs as well.
|
||||
A few examples are available in the Examples/mzscheme directory.
|
||||
The code and log of a session using SWIG below should help getting started.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
C header file:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
// example.h
|
||||
int fact(int n);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
C source code:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
// File: example.c
|
||||
#include "example.h"
|
||||
|
||||
int fact(int n) {
|
||||
if (n < 0) { /* This should probably return an error, but this is simpler */
|
||||
return 0;
|
||||
}
|
||||
if (n == 0) {
|
||||
return 1;
|
||||
}
|
||||
else {
|
||||
/* testing for overflow would be a good idea here */
|
||||
return n * fact(n-1);
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
SWIG interface file:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File: example.i */
|
||||
%module example
|
||||
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
|
||||
int fact(int n);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The session below using the above files is on an OS X machine, but the points to be made are more general. On OS X, libtool is the tool which creates libraries, which are named .dylib, rather than .so on other unixes, or .dll on Windows.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
% swig -mzscheme -declaremodule example.i
|
||||
% gcc -c -m32 -o example.o example.c # force 32-bit object file (mzscheme is 32-bit only)
|
||||
% libtool -dynamic -o libexample.dylib example.o # make it into a library
|
||||
% ls # what've we got so far?
|
||||
example.c example.o
|
||||
example.h example_wrap.c
|
||||
example.i libexample.dylib*
|
||||
% mzc --cgc --cc example_wrap.c # compile the wrapping code
|
||||
% LDFLAGS="-L. -lexample" mzc --ld example_wrap.dylib example_wrap.o # ...and link it
|
||||
% mzscheme -e '(path->string (build-path "compiled" "native" (system-library-subpath)))'
|
||||
"compiled/native/i386-macosx/3m"
|
||||
% mkdir -p compiled/native/i386-macosx/3m # move the extension library to a magic place
|
||||
% mv example_wrap.dylib compiled/native/i386-macosx/3m/example_ss.dylib
|
||||
% mzscheme
|
||||
Welcome to MzScheme v4.2.4 [3m], Copyright (c) 2004-2010 PLT Scheme Inc.
|
||||
> (require "example.ss")
|
||||
> (fact 5)
|
||||
120
|
||||
> ^D
|
||||
% echo 'It works!'
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<p>
|
||||
Some points of interest:
|
||||
</p>
|
||||
<ul>
|
||||
<li> This is on a 64-bit machine, so we have to include the -m32 option when building the object file
|
||||
<li> If you want to declare a scheme module (and you probably do), it's important that you include the -declaremodule option to swig (if you miss this out, it'll appear to work, but fail later).
|
||||
<li> Use mzc to compile and then link the wrapped code. You'll probably need to adjust the link flags to refer to the library you're wrapping (you can either do this with an LDFLAGS declaration, as here, or with multiple ++ldf options to mzc).
|
||||
<li> Create the directory with path (build-path "compiled" "native" (system-library-subpath)) and move the freshly-generated .dylib to there, changing its name to module-name_ss.dylib. After that, you can REQUIRE the new module with (require "module-name.ss").
|
||||
<li> The above requests mzc to create an extension using the CGC garbage-collector. The alternative -- the 3m collector -- has generally better performance, but work is still required for SWIG to emit code which is compatible with it.
|
||||
</ul>
|
||||
|
||||
<H2><a name="MzScheme_external_docs"></a>27.3 External documentation</H2>
|
||||
|
||||
|
||||
<p>
|
||||
See the <a href="http://docs.racket-lang.org/inside/index.html">C API</a> for more description of using the mechanism for adding extensions. The main documentation is <a href="http://docs.racket-lang.org/">here</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Tip: mzc's --vv option is very useful for debugging the inevitable library problems you'll encounter.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -2236,7 +2236,8 @@ rest to lower case.
|
|||
And now, a final note about function pointer support. Although SWIG
|
||||
does not normally allow callback functions to be written in the target language, this
|
||||
can be accomplished with the use of typemaps and other advanced SWIG features.
|
||||
This is described in a later chapter.
|
||||
See the <a href="Typemaps.html#Typemaps">Typemaps chapter</a> for more about typemaps
|
||||
and individual target language chapters for more on callbacks and the 'director' feature.
|
||||
</p>
|
||||
|
||||
<H2><a name="SWIG_nn31"></a>5.5 Structures and unions</H2>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Sections"></a>SWIG-2.0 Documentation</H1>
|
||||
|
||||
Last update : SWIG-2.0.2 (in progress)
|
||||
Last update : SWIG-2.0.3 (in progress)
|
||||
|
||||
<H2>Sections</H2>
|
||||
|
||||
|
|
|
|||
|
|
@ -381,8 +381,12 @@ example.i(4) : Syntax error in input.
|
|||
|
||||
|
||||
<ul>
|
||||
<li>201. Unable to find 'filename'.
|
||||
<li>202. Could not evaluate 'expr'.
|
||||
<li>201. Unable to find <em>filename</em>.
|
||||
<li>202. Could not evaluate expression <em>expr</em>.
|
||||
<li>203. Both includeall and importall are defined: using includeall.
|
||||
<li>204. CPP #warning, "<em>warning</em>".
|
||||
<li>205. CPP #error, "<em>error</em>".
|
||||
<li>206. Unexpected tokens after #<em>directive</em> directive.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn12"></a>14.9.3 C/C++ Parser (300-399)</H3>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue