Huge update to the Allegrocl module. Better C support. C++ support
added. Documentation! Makes use of typemaps for better interface tuning. Improved type support. Wrapping of foreign pointers in CLOS objects; hopefully a step toward being able to extend C++ classes from Lisp. git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@7828 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Ahmon Dancy
parent
285590d616
commit
4098a01b68
22 changed files with 3703 additions and 882 deletions
|
|
@ -1,6 +1,36 @@
|
|||
Version 1.3.28 (unreleased)
|
||||
===========================
|
||||
|
||||
11/09/2005: dancy
|
||||
|
||||
[Allegrocl]
|
||||
Add C++ support to the Allegrocl module. Further
|
||||
enhances the C support as well. Some of the
|
||||
features:
|
||||
|
||||
- MUCH better generation of foreign types based on
|
||||
the C/C++ types for use in defining the FFI on
|
||||
the lisp side. We don't pass everything as a (* :void)
|
||||
any longer.
|
||||
|
||||
- Uses typemaps for better control of type conversions
|
||||
and code generation in the generated lisp and c++ wrapper
|
||||
code.
|
||||
|
||||
- CLOS wrapping of pointers returned from foreign space
|
||||
makes it easier to differentiate pointers in user code.
|
||||
The wrapping objects can be passed directly to FF calls.
|
||||
|
||||
- Defun wrapping of FF calls, allowing for more lispy
|
||||
interface. Conversion, GCing, of lisp objects to
|
||||
foreign objects can be done in the wrapping defun via
|
||||
the use of typemaps.
|
||||
|
||||
- overload dispatching implemented on the lisp side
|
||||
using generic functions.
|
||||
|
||||
- Templates and synonymous types supported.
|
||||
|
||||
11/07/2005: mmatus
|
||||
|
||||
[Python] Adding proper support for multi-inheritance in
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="CSharp"></a>16 SWIG and C#</H1>
|
||||
<H1><a name="CSharp"></a>18 SWIG and C#</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -29,7 +29,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="csharp_introduction"></a>16.1 Introduction</H2>
|
||||
<H2><a name="csharp_introduction"></a>18.1 Introduction</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -49,7 +49,7 @@ The <a href="http://msdn.microsoft.com">Microsoft Developer Network (MSDN)</a> h
|
|||
Monodoc, available from the Mono project, has a very useful section titled <a href="http://www.mono-project.com/Interop_with_Native_Libraries">Interop with native libraries</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="csharp_differences_java"></a>16.2 Differences to the Java module</H2>
|
||||
<H2><a name="csharp_differences_java"></a>18.2 Differences to the Java module</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -334,7 +334,7 @@ Windows users can also get the examples working using a
|
|||
<a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> environment for automatic configuration of the example makefiles.
|
||||
Any one of the three C# compilers (Portable.NET, Mono or Microsoft) can be detected from within a Cygwin or Mingw environment if installed in your path.
|
||||
|
||||
<H2><a name="csharp_exceptions"></a>16.3 C# Exceptions</H2>
|
||||
<H2><a name="csharp_exceptions"></a>18.3 C# Exceptions</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -430,7 +430,7 @@ set so should only be used when a C# exception is not created.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="csharp_exception_example_check_typemap"></a>16.3.1 C# exception example using "check" typemap</H3>
|
||||
<H3><a name="csharp_exception_example_check_typemap"></a>18.3.1 C# exception example using "check" typemap</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -612,7 +612,7 @@ method and C# code does not handle pending exceptions via the canthrow attribute
|
|||
Actually it will issue this warning for any function beginning with <tt>SWIG_CSharpSetPendingException</tt>.
|
||||
</P>
|
||||
|
||||
<H3><a name="csharp_exception_example_percent_exception"></a>16.3.2 C# exception example using %exception</H3>
|
||||
<H3><a name="csharp_exception_example_percent_exception"></a>18.3.2 C# exception example using %exception</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -677,7 +677,7 @@ The managed code generated does check for the pending exception as mentioned ear
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="csharp_exception_example_exception_specifications"></a>16.3.3 C# exception example using exception specifications</H3>
|
||||
<H3><a name="csharp_exception_example_exception_specifications"></a>18.3.3 C# exception example using exception specifications</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -734,7 +734,7 @@ SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
|
|||
Multiple catch handlers are generated should there be more than one exception specifications declared.
|
||||
</p>
|
||||
|
||||
<H3><a name="csharp_custom_application_exception"></a>16.3.4 Custom C# ApplicationException example</H3>
|
||||
<H3><a name="csharp_custom_application_exception"></a>18.3.4 Custom C# ApplicationException example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -868,7 +868,7 @@ try {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="csharp_typemap_examples"></a>16.4 C# Typemap examples</H2>
|
||||
<H2><a name="csharp_typemap_examples"></a>18.4 C# Typemap examples</H2>
|
||||
|
||||
|
||||
This section includes a few examples of typemaps. For more examples, you
|
||||
|
|
@ -876,7 +876,7 @@ might look at the files "<tt>csharp.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
|
||||
|
||||
<H3><a name="csharp_memory_management_member_variables"></a>16.4.1 Memory management when returning references to member variables</H3>
|
||||
<H3><a name="csharp_memory_management_member_variables"></a>18.4.1 Memory management when returning references to member variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1000,7 +1000,7 @@ public class Bike : IDisposable {
|
|||
Note the <tt>addReference</tt> call.
|
||||
</p>
|
||||
|
||||
<H3><a name="csharp_memory_management_objects"></a>16.4.2 Memory management for objects passed to the C++ layer</H3>
|
||||
<H3><a name="csharp_memory_management_objects"></a>18.4.2 Memory management for objects passed to the C++ layer</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Chicken"></a>17 SWIG and Chicken</H1>
|
||||
<H1><a name="Chicken"></a>19 SWIG and Chicken</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -69,7 +69,7 @@
|
|||
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn2"></a>17.1 Preliminaries</H2>
|
||||
<H2><a name="Chicken_nn2"></a>19.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -87,7 +87,7 @@
|
|||
CHICKEN.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn3"></a>17.1.1 Running SWIG in C mode</H3>
|
||||
<H3><a name="Chicken_nn3"></a>19.1.1 Running SWIG in C mode</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -120,7 +120,7 @@
|
|||
object files and linked into your project.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn4"></a>17.1.2 Running SWIG in C++ mode</H3>
|
||||
<H3><a name="Chicken_nn4"></a>19.1.2 Running SWIG in C++ mode</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -149,10 +149,10 @@
|
|||
object files and linked into your project.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn5"></a>17.2 Code Generation</H2>
|
||||
<H2><a name="Chicken_nn5"></a>19.2 Code Generation</H2>
|
||||
|
||||
|
||||
<H3><a name="Chicken_nn6"></a>17.2.1 Naming Conventions</H3>
|
||||
<H3><a name="Chicken_nn6"></a>19.2.1 Naming Conventions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -168,7 +168,7 @@
|
|||
<tt>%rename</tt> SWIG directive in the SWIG interface file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn7"></a>17.2.2 Modules</H3>
|
||||
<H3><a name="Chicken_nn7"></a>19.2.2 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -190,7 +190,7 @@
|
|||
(uses <i>modulename</i>))</code> CHICKEN Scheme form.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn8"></a>17.2.3 Constants and Variables</H3>
|
||||
<H3><a name="Chicken_nn8"></a>19.2.3 Constants and Variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -217,7 +217,7 @@
|
|||
use <tt>(my-variable)</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn9"></a>17.2.4 Functions</H3>
|
||||
<H3><a name="Chicken_nn9"></a>19.2.4 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -236,7 +236,7 @@
|
|||
parameters). The return values can then be accessed with <code>(call-with-values)</code>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn10"></a>17.2.5 Exceptions</H3>
|
||||
<H3><a name="Chicken_nn10"></a>19.2.5 Exceptions</H3>
|
||||
|
||||
|
||||
<p>The SWIG chicken module has support for exceptions thrown from
|
||||
|
|
@ -278,7 +278,7 @@
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H2><a name="Chicken_nn11"></a>17.3 TinyCLOS</H2>
|
||||
<H2><a name="Chicken_nn11"></a>19.3 TinyCLOS</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -321,7 +321,7 @@
|
|||
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn12"></a>17.4 Linkage</H2>
|
||||
<H2><a name="Chicken_nn12"></a>19.4 Linkage</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -342,7 +342,7 @@
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Chicken_nn13"></a>17.4.1 Static binary or shared library linked at compile time</H3>
|
||||
<H3><a name="Chicken_nn13"></a>19.4.1 Static binary or shared library linked at compile time</H3>
|
||||
|
||||
|
||||
<p>We can easily use csc to build a static binary.</p>
|
||||
|
|
@ -383,7 +383,7 @@ in which case the test script does not need to be linked with example.so. The t
|
|||
be run with <tt>csi</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn14"></a>17.4.2 Building chicken extension libraries</H3>
|
||||
<H3><a name="Chicken_nn14"></a>19.4.2 Building chicken extension libraries</H3>
|
||||
|
||||
|
||||
<p>Building a shared library like in the above section only works if the library
|
||||
|
|
@ -441,7 +441,7 @@ distributed and used by anyone, even if SWIG is not installed.</p>
|
|||
<p>See the <tt>Examples/chicken/egg</tt> directory in the SWIG source for an example that builds
|
||||
two eggs, one using the first method and one using the second method.</p>
|
||||
|
||||
<H3><a name="Chicken_nn15"></a>17.4.3 Linking multiple SWIG modules with TinyCLOS</H3>
|
||||
<H3><a name="Chicken_nn15"></a>19.4.3 Linking multiple SWIG modules with TinyCLOS</H3>
|
||||
|
||||
|
||||
<p>Linking together multiple modules that share type information using the <code>%import</code>
|
||||
|
|
@ -465,7 +465,7 @@ with <code>(declare (uses ...))</code>.
|
|||
To create an extension library or an egg, just create a <tt>module_load.scm</tt> file that <code>(declare (uses ...))</code>
|
||||
all the modules.</p>
|
||||
|
||||
<H2><a name="Chicken_nn16"></a>17.5 Typemaps</H2>
|
||||
<H2><a name="Chicken_nn16"></a>19.5 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -474,7 +474,7 @@ all the modules.</p>
|
|||
<code>Lib/chicken/chicken.swg</code>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn17"></a>17.6 Pointers</H2>
|
||||
<H2><a name="Chicken_nn17"></a>19.6 Pointers</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -507,7 +507,7 @@ all the modules.</p>
|
|||
type. flags is either zero or SWIG_POINTER_DISOWN (see below).
|
||||
</p>
|
||||
|
||||
<H3><a name="collection"></a>17.6.1 Garbage collection</H3>
|
||||
<H3><a name="collection"></a>19.6.1 Garbage collection</H3>
|
||||
|
||||
|
||||
<p>If the owner flag passed to <code>SWIG_NewPointerObj</code> is 1, <code>NewPointerObj</code> will add a
|
||||
|
|
@ -538,7 +538,7 @@ all the modules.</p>
|
|||
must be called manually.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn18"></a>17.7 Unsupported features and known problems</H2>
|
||||
<H2><a name="Chicken_nn18"></a>19.7 Unsupported features and known problems</H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -485,7 +485,107 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CSharp.html#CSharp">16 SWIG and C#</a></h3>
|
||||
<h3><a href="Lisp.html#Lisp">16 SWIG and Common Lisp</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Lisp.html#Lisp_nn2">Allegro Common Lisp</a>
|
||||
<li><a href="Lisp.html#Lisp_nn3">CLISP</a>
|
||||
<ul>
|
||||
<li><a href="Lisp.html#Lisp_nn4">Additional Commandline Options </a>
|
||||
<li><a href="Lisp.html#Lisp_nn5">Details on CLISP bindings</a>
|
||||
</ul>
|
||||
<li><a href="Lisp.html#Lisp_nn6">UFFI </a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Allegrocl.html#Allegrocl">17 SWIG and Allegro Common Lisp</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn2">Basics</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn3">Running Swig</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn4">Command Line Options</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn5">Inserting user code into generated files</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn6">Wrapping Overview</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn7">Function Wrapping</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn8">Foreign Wrappers</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn9">FFI Wrappers</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn10">Non-overloaded Defuns</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn11">Overloaded Defuns</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn12">What about constant and variable access?</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn13">Object Wrapping</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn14">Wrapping Details</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn15">Namespaces</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn16">Constants</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn17">Variables</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn18">Enumerations</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn19">Arrays</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn20">Classes and Structs and Unions (oh my!)</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn21">CLOS wrapping of</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn22">CLOS Inheritance</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn23">Member fields and functions</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn24">Why not directly access C++ classes using foreign types?</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn25">Templates</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn26">Generating wrapper code for templates</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn27">Implicit Template instantiation</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn28">Typedef, Templates, and Synonym Types</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn29">Choosing a primary type</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn30">Function overloading/Parameter defaulting</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn31">Operator wrapping and Operator overloading</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn32">Varargs</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn33">C++ Exceptions</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn34">Pass by value, pass by reference</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn35">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn36">Code Generation in the C++ Wrapper</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn37">IN Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn38">OUT Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn39">CTYPE Typemap</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn40">Code generation in Lisp wrappers</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn41">LIN Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn42">LOUT Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn43">FFITYPE Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn44">LISPTYPE Typemap</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn45">LISPCLASS Typemap</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn46">Modifying SWIG behavior using typemaps</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn47">Identifier Converter functions</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn48">Creating symbols in the lisp environment</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn49">Existing identifier-converter functions</a>
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn50">identifier-convert-null</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn51">identifier-convert-lispify</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn52">Default identifier to symbol conversions</a>
|
||||
</ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn53">Defining your own identifier-converter</a>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn54">Instructing SWIG to use a particular identifier-converter</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CSharp.html#CSharp">18 SWIG and C#</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -499,11 +599,16 @@
|
|||
<li><a href="CSharp.html#csharp_exception_example_exception_specifications">C# exception example using exception specifications</a>
|
||||
<li><a href="CSharp.html#csharp_custom_application_exception">Custom C# ApplicationException example</a>
|
||||
</ul>
|
||||
<li><a href="CSharp.html#csharp_typemap_examples">C# Typemap examples</a>
|
||||
<ul>
|
||||
<li><a href="CSharp.html#csharp_memory_management_member_variables">Memory management when returning references to member variables</a>
|
||||
<li><a href="CSharp.html#csharp_memory_management_objects">Memory management for objects passed to the C++ layer</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Chicken.html#Chicken">17 SWIG and Chicken</a></h3>
|
||||
<h3><a href="Chicken.html#Chicken">19 SWIG and Chicken</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -538,7 +643,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Guile.html#Guile">18 SWIG and Guile</a></h3>
|
||||
<h3><a href="Guile.html#Guile">20 SWIG and Guile</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -573,7 +678,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Java.html#Java">19 SWIG and Java</a></h3>
|
||||
<h3><a href="Java.html#Java">21 SWIG and Java</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -691,6 +796,8 @@
|
|||
<li><a href="Java.html#adding_equals_method">Adding an equals method to the Java classes</a>
|
||||
<li><a href="Java.html#void_pointers">Void pointers and a common Java base class</a>
|
||||
<li><a href="Java.html#struct_pointer_pointer">Struct pointer to pointer</a>
|
||||
<li><a href="Java.html#java_memory_management_member_variables">Memory management when returning references to member variables</a>
|
||||
<li><a href="Java.html#java_memory_management_objects">Memory management for objects passed to the C++ layer</a>
|
||||
</ul>
|
||||
<li><a href="Java.html#java_directors_faq">Living with Java Directors</a>
|
||||
<li><a href="Java.html#odds_ends">Odds and ends</a>
|
||||
|
|
@ -705,7 +812,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Modula3.html#Modula3">20 SWIG and Modula-3</a></h3>
|
||||
<h3><a href="Modula3.html#Modula3">22 SWIG and Modula-3</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -746,7 +853,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Mzscheme.html#Mzscheme">21 SWIG and MzScheme</a></h3>
|
||||
<h3><a href="Mzscheme.html#Mzscheme">23 SWIG and MzScheme</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -756,7 +863,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ocaml.html#Ocaml">22 SWIG and Ocaml</a></h3>
|
||||
<h3><a href="Ocaml.html#Ocaml">24 SWIG and Ocaml</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -807,7 +914,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Perl5.html#Perl5">23 SWIG and Perl5</a></h3>
|
||||
<h3><a href="Perl5.html#Perl5">25 SWIG and Perl5</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -873,7 +980,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Php.html#Php">24 SWIG and PHP4</a></h3>
|
||||
<h3><a href="Php.html#Php">26 SWIG and PHP4</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -904,7 +1011,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Pike.html#Pike">25 SWIG and Pike</a></h3>
|
||||
<h3><a href="Pike.html#Pike">27 SWIG and Pike</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -928,7 +1035,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Python.html#Python">26 SWIG and Python</a></h3>
|
||||
<h3><a href="Python.html#Python">28 SWIG and Python</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1029,7 +1136,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ruby.html#Ruby">27 SWIG and Ruby</a></h3>
|
||||
<h3><a href="Ruby.html#Ruby">29 SWIG and Ruby</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1111,7 +1218,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Tcl.html#Tcl">28 SWIG and Tcl</a></h3>
|
||||
<h3><a href="Tcl.html#Tcl">30 SWIG and Tcl</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1176,7 +1283,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Lua.html#Lua">29 SWIG and Lua</a></h3>
|
||||
<h3><a href="Lua.html#Lua">31 SWIG and Lua</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1215,7 +1322,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Extending.html#Extending">30 Extending SWIG</a></h3>
|
||||
<h3><a href="Extending.html#Extending">32 Extending SWIG</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Extending"></a>30 Extending SWIG</H1>
|
||||
<H1><a name="Extending"></a>32 Extending SWIG</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -75,7 +75,7 @@
|
|||
<b>Caution: This chapter is being rewritten! (11/25/01)</b>
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn2"></a>30.1 Introduction</H2>
|
||||
<H2><a name="Extending_nn2"></a>32.1 Introduction</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -91,7 +91,7 @@ Also, this chapter is not meant to be a hand-holding tutorial. As a starting po
|
|||
you should probably look at one of SWIG's existing modules.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn3"></a>30.2 Prerequisites</H2>
|
||||
<H2><a name="Extending_nn3"></a>32.2 Prerequisites</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -121,7 +121,7 @@ obvious, but almost all SWIG directives as well as the low-level generation of
|
|||
wrapper code are driven by C++ datatypes.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn4"></a>30.3 The Big Picture</H2>
|
||||
<H2><a name="Extending_nn4"></a>32.3 The Big Picture</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -158,7 +158,7 @@ role in making the system work. For example, both typemaps and declaration anno
|
|||
based on pattern matching and interact heavily with the underlying type system.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn5"></a>30.4 Execution Model</H2>
|
||||
<H2><a name="Extending_nn5"></a>32.4 Execution Model</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -203,7 +203,7 @@ stage of compilation.
|
|||
The next few sections briefly describe some of these stages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn6"></a>30.4.1 Preprocessing</H3>
|
||||
<H3><a name="Extending_nn6"></a>32.4.1 Preprocessing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -283,7 +283,7 @@ been expanded as well as everything else that goes into the low-level
|
|||
construction of the wrapper code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn7"></a>30.4.2 Parsing</H3>
|
||||
<H3><a name="Extending_nn7"></a>32.4.2 Parsing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -384,7 +384,7 @@ returning a <tt>foo</tt> and taking types <tt>a</tt> and <tt>b</tt> as
|
|||
arguments).
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn8"></a>30.4.3 Parse Trees</H3>
|
||||
<H3><a name="Extending_nn8"></a>32.4.3 Parse Trees</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -636,7 +636,7 @@ $ swig -c++ -python -dump_tree example.i
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn9"></a>30.4.4 Attribute namespaces</H3>
|
||||
<H3><a name="Extending_nn9"></a>32.4.4 Attribute namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -655,7 +655,7 @@ that matches the name of the target language. For example, <tt>python:foo</tt>
|
|||
<tt>perl:foo</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn10"></a>30.4.5 Symbol Tables</H3>
|
||||
<H3><a name="Extending_nn10"></a>32.4.5 Symbol Tables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -743,7 +743,7 @@ example.i:5. Previous declaration is foo_i(int )
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn11"></a>30.4.6 The %feature directive</H3>
|
||||
<H3><a name="Extending_nn11"></a>32.4.6 The %feature directive</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -799,7 +799,7 @@ For example, the exception code above is simply
|
|||
stored without any modifications.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn12"></a>30.4.7 Code Generation</H3>
|
||||
<H3><a name="Extending_nn12"></a>32.4.7 Code Generation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -921,7 +921,7 @@ public :
|
|||
The role of these functions is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn13"></a>30.4.8 SWIG and XML</H3>
|
||||
<H3><a name="Extending_nn13"></a>32.4.8 SWIG and XML</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -934,7 +934,7 @@ internal data structures, it may be useful keep XML in the back of
|
|||
your mind as a model.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn14"></a>30.5 Primitive Data Structures</H2>
|
||||
<H2><a name="Extending_nn14"></a>32.5 Primitive Data Structures</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -980,7 +980,7 @@ typedef Hash Typetab;
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn15"></a>30.5.1 Strings</H3>
|
||||
<H3><a name="Extending_nn15"></a>32.5.1 Strings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1121,7 +1121,7 @@ Returns the number of replacements made (if any).
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn16"></a>30.5.2 Hashes</H3>
|
||||
<H3><a name="Extending_nn16"></a>32.5.2 Hashes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1198,7 +1198,7 @@ Returns the list of hash table keys.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn17"></a>30.5.3 Lists</H3>
|
||||
<H3><a name="Extending_nn17"></a>32.5.3 Lists</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1287,7 +1287,7 @@ If <tt>t</tt> is not a standard object, it is assumed to be a <tt>char *</tt>
|
|||
and is used to create a String object.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn18"></a>30.5.4 Common operations</H3>
|
||||
<H3><a name="Extending_nn18"></a>32.5.4 Common operations</H3>
|
||||
|
||||
|
||||
The following operations are applicable to all datatypes.
|
||||
|
|
@ -1342,7 +1342,7 @@ objects and report errors.
|
|||
Gets the line number associated with <tt>x</tt>.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn19"></a>30.5.5 Iterating over Lists and Hashes</H3>
|
||||
<H3><a name="Extending_nn19"></a>32.5.5 Iterating over Lists and Hashes</H3>
|
||||
|
||||
|
||||
To iterate over the elements of a list or a hash table, the following functions are used:
|
||||
|
|
@ -1387,7 +1387,7 @@ for (j = First(j); j.item; j= Next(j)) {
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn20"></a>30.5.6 I/O</H3>
|
||||
<H3><a name="Extending_nn20"></a>32.5.6 I/O</H3>
|
||||
|
||||
|
||||
Special I/O functions are used for all internal I/O. These operations
|
||||
|
|
@ -1523,7 +1523,7 @@ Similarly, the preprocessor and parser all operate on string-files.
|
|||
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn21"></a>30.6 Navigating and manipulating parse trees</H2>
|
||||
<H2><a name="Extending_nn21"></a>32.6 Navigating and manipulating parse trees</H2>
|
||||
|
||||
|
||||
Parse trees are built as collections of hash tables. Each node is a hash table in which
|
||||
|
|
@ -1657,7 +1657,7 @@ Deletes a node from the parse tree. Deletion reconnects siblings and properly u
|
|||
the parent so that sibling nodes are unaffected.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn22"></a>30.7 Working with attributes</H2>
|
||||
<H2><a name="Extending_nn22"></a>32.7 Working with attributes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1774,7 +1774,7 @@ the attribute is optional. <tt>Swig_restore()</tt> must always be called after
|
|||
function.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn23"></a>30.8 Type system</H2>
|
||||
<H2><a name="Extending_nn23"></a>32.8 Type system</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1783,7 +1783,7 @@ pointers, references, and pointers to members. A detailed discussion of
|
|||
type theory is impossible here. However, let's cover the highlights.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn24"></a>30.8.1 String encoding of types</H3>
|
||||
<H3><a name="Extending_nn24"></a>32.8.1 String encoding of types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1884,7 +1884,7 @@ make the final type, the two parts are just joined together using
|
|||
string concatenation.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn25"></a>30.8.2 Type construction</H3>
|
||||
<H3><a name="Extending_nn25"></a>32.8.2 Type construction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2053,7 +2053,7 @@ Returns the prefix of a type. For example, if <tt>ty</tt> is
|
|||
<tt>ty</tt> is unmodified.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn26"></a>30.8.3 Type tests</H3>
|
||||
<H3><a name="Extending_nn26"></a>32.8.3 Type tests</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2140,7 +2140,7 @@ Checks if <tt>ty</tt> is a varargs type.
|
|||
Checks if <tt>ty</tt> is a templatized type.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn27"></a>30.8.4 Typedef and inheritance</H3>
|
||||
<H3><a name="Extending_nn27"></a>32.8.4 Typedef and inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2242,7 +2242,7 @@ Fully reduces <tt>ty</tt> according to typedef rules. Resulting datatype
|
|||
will consist only of primitive typenames.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn28"></a>30.8.5 Lvalues</H3>
|
||||
<H3><a name="Extending_nn28"></a>32.8.5 Lvalues</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2279,7 +2279,7 @@ Literal y; // type = 'Literal', ltype='p.char'
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn29"></a>30.8.6 Output functions</H3>
|
||||
<H3><a name="Extending_nn29"></a>32.8.6 Output functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2341,7 +2341,7 @@ SWIG, but is most commonly associated with type-descriptor objects
|
|||
that appear in wrappers (e.g., <tt>SWIGTYPE_p_double</tt>).
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn30"></a>30.9 Parameters</H2>
|
||||
<H2><a name="Extending_nn30"></a>32.9 Parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2440,7 +2440,7 @@ included. Used to emit prototypes.
|
|||
Returns the number of required (non-optional) arguments in <tt>p</tt>.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn31"></a>30.10 Writing a Language Module</H2>
|
||||
<H2><a name="Extending_nn31"></a>32.10 Writing a Language Module</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2451,7 +2451,7 @@ describes the creation of a minimal Python module. You should be able to extra
|
|||
this to other languages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn32"></a>30.10.1 Execution model</H3>
|
||||
<H3><a name="Extending_nn32"></a>32.10.1 Execution model</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2461,7 +2461,7 @@ the parsing of command line options, all aspects of code generation are controll
|
|||
different methods of the <tt>Language</tt> that must be defined by your module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn33"></a>30.10.2 Starting out</H3>
|
||||
<H3><a name="Extending_nn33"></a>32.10.2 Starting out</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2574,7 +2574,7 @@ that activates your module. For example, <tt>swig -python foo.i</tt>. The
|
|||
messages from your new module should appear.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn34"></a>30.10.3 Command line options</H3>
|
||||
<H3><a name="Extending_nn34"></a>32.10.3 Command line options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2633,7 +2633,7 @@ to mark the option as valid. If you forget to do this, SWIG will terminate wit
|
|||
unrecognized command line option error.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn35"></a>30.10.4 Configuration and preprocessing</H3>
|
||||
<H3><a name="Extending_nn35"></a>32.10.4 Configuration and preprocessing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2682,7 +2682,7 @@ an implementation file <tt>python.cxx</tt> and a configuration file
|
|||
<tt>python.swg</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn36"></a>30.10.5 Entry point to code generation</H3>
|
||||
<H3><a name="Extending_nn36"></a>32.10.5 Entry point to code generation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2740,13 +2740,13 @@ int Python::top(Node *n) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn37"></a>30.10.6 Module I/O and wrapper skeleton</H3>
|
||||
<H3><a name="Extending_nn37"></a>32.10.6 Module I/O and wrapper skeleton</H3>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn38"></a>30.10.7 Low-level code generators</H3>
|
||||
<H3><a name="Extending_nn38"></a>32.10.7 Low-level code generators</H3>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn39"></a>30.10.8 Configuration files</H3>
|
||||
<H3><a name="Extending_nn39"></a>32.10.8 Configuration files</H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to ttn -->
|
||||
|
|
@ -2901,7 +2901,7 @@ to handle some of these configuration tasks, but that point is now
|
|||
long past. If you are interested in working on that, feel free to
|
||||
raise the issue in the context of a next-generation clean-slate SWIG.
|
||||
|
||||
<H3><a name="Extending_nn40"></a>30.10.9 Runtime support</H3>
|
||||
<H3><a name="Extending_nn40"></a>32.10.9 Runtime support</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2910,7 +2910,7 @@ Discuss the kinds of functions typically needed for SWIG runtime support (e.g.
|
|||
the SWIG files that implement those functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn41"></a>30.10.10 Standard library files</H3>
|
||||
<H3><a name="Extending_nn41"></a>32.10.10 Standard library files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2924,7 +2924,7 @@ Discuss the standard library files that most language modules provide, e.g.
|
|||
<li> stl.i </li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Extending_nn42"></a>30.10.11 Examples and test cases</H3>
|
||||
<H3><a name="Extending_nn42"></a>32.10.11 Examples and test cases</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2951,7 +2951,7 @@ during this process, see the section on <a href="#n37a">configuration
|
|||
files</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn43"></a>30.10.12 Documentation</H3>
|
||||
<H3><a name="Extending_nn43"></a>32.10.12 Documentation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2983,13 +2983,13 @@ Some topics that you'll want to be sure to address include:
|
|||
if available.
|
||||
</ul>
|
||||
|
||||
<H2><a name="Extending_nn44"></a>30.11 Typemaps</H2>
|
||||
<H2><a name="Extending_nn44"></a>32.11 Typemaps</H2>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn45"></a>30.11.1 Proxy classes</H3>
|
||||
<H3><a name="Extending_nn45"></a>32.11.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<H2><a name="Extending_nn46"></a>30.12 Guide to parse tree nodes</H2>
|
||||
<H2><a name="Extending_nn46"></a>32.12 Guide to parse tree nodes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Guile"></a>18 SWIG and Guile</H1>
|
||||
<H1><a name="Guile"></a>20 SWIG and Guile</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -47,7 +47,7 @@
|
|||
<p>
|
||||
This section details guile-specific support in SWIG.
|
||||
|
||||
<H2><a name="Guile_nn2"></a>18.1 Meaning of "Module"</H2>
|
||||
<H2><a name="Guile_nn2"></a>20.1 Meaning of "Module"</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -55,7 +55,7 @@ There are three different concepts of "module" involved, defined
|
|||
separately for SWIG, Guile, and Libtool. To avoid horrible confusion,
|
||||
we explicitly prefix the context, e.g., "guile-module".
|
||||
|
||||
<H2><a name="Guile_nn3"></a>18.2 Using the SCM or GH Guile API</H2>
|
||||
<H2><a name="Guile_nn3"></a>20.2 Using the SCM or GH Guile API</H2>
|
||||
|
||||
|
||||
<p>The guile module can currently export wrapper files that use the guile GH interface or the
|
||||
|
|
@ -103,7 +103,7 @@ for the specific API. Currently only the guile language module has created a ma
|
|||
but there is no reason other languages (like mzscheme or chicken) couldn't also use this.
|
||||
If that happens, there is A LOT less code duplication in the standard typemaps.</p>
|
||||
|
||||
<H2><a name="Guile_nn4"></a>18.3 Linkage</H2>
|
||||
<H2><a name="Guile_nn4"></a>20.3 Linkage</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -111,7 +111,7 @@ Guile support is complicated by a lack of user community cohesiveness,
|
|||
which manifests in multiple shared-library usage conventions. A set of
|
||||
policies implementing a usage convention is called a <b>linkage</b>.
|
||||
|
||||
<H3><a name="Guile_nn5"></a>18.3.1 Simple Linkage</H3>
|
||||
<H3><a name="Guile_nn5"></a>20.3.1 Simple Linkage</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -206,7 +206,7 @@ placed between the <code>define-module</code> form and the
|
|||
<code>SWIG_init</code> via a preprocessor define to avoid symbol
|
||||
clashes. For this case, however, passive linkage is available.
|
||||
|
||||
<H3><a name="Guile_nn6"></a>18.3.2 Passive Linkage</H3>
|
||||
<H3><a name="Guile_nn6"></a>20.3.2 Passive Linkage</H3>
|
||||
|
||||
|
||||
<p>Passive linkage is just like simple linkage, but it generates an
|
||||
|
|
@ -216,7 +216,7 @@ package name (see below).
|
|||
<p>You should use passive linkage rather than simple linkage when you
|
||||
are using multiple modules.
|
||||
|
||||
<H3><a name="Guile_nn7"></a>18.3.3 Native Guile Module Linkage</H3>
|
||||
<H3><a name="Guile_nn7"></a>20.3.3 Native Guile Module Linkage</H3>
|
||||
|
||||
|
||||
<p>SWIG can also generate wrapper code that does all the Guile module
|
||||
|
|
@ -257,7 +257,7 @@ Newer Guile versions have a shorthand procedure for this:
|
|||
</div>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Guile_nn8"></a>18.3.4 Old Auto-Loading Guile Module Linkage</H3>
|
||||
<H3><a name="Guile_nn8"></a>20.3.4 Old Auto-Loading Guile Module Linkage</H3>
|
||||
|
||||
|
||||
<p>Guile used to support an autoloading facility for object-code
|
||||
|
|
@ -283,7 +283,7 @@ option, SWIG generates an exported module initialization function with
|
|||
an appropriate name.
|
||||
|
||||
|
||||
<H3><a name="Guile_nn9"></a>18.3.5 Hobbit4D Linkage</H3>
|
||||
<H3><a name="Guile_nn9"></a>20.3.5 Hobbit4D Linkage</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -308,7 +308,7 @@ my/lib/libfoo.so.X.Y.Z and friends. This scheme is still very
|
|||
experimental; the (hobbit4d link) conventions are not well understood.
|
||||
</p>
|
||||
|
||||
<H2><a name="Guile_nn10"></a>18.4 Underscore Folding</H2>
|
||||
<H2><a name="Guile_nn10"></a>20.4 Underscore Folding</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -320,7 +320,7 @@ complained so far.
|
|||
<code>%rename</code> to specify the Guile name of the wrapped
|
||||
functions and variables (see CHANGES).
|
||||
|
||||
<H2><a name="Guile_nn11"></a>18.5 Typemaps</H2>
|
||||
<H2><a name="Guile_nn11"></a>20.5 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -405,7 +405,7 @@ In <code><var>body</var></code>, the first result of
|
|||
See also the "multivalue" example.
|
||||
</p>
|
||||
|
||||
<H2><a name="Guile_nn12"></a>18.6 Representation of pointers as smobs</H2>
|
||||
<H2><a name="Guile_nn12"></a>20.6 Representation of pointers as smobs</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -426,7 +426,7 @@ representing the expected pointer type. See also
|
|||
If the Scheme object passed was not a SWIG smob representing a compatible
|
||||
pointer, a <code>wrong-type-arg</code> exception is raised.
|
||||
|
||||
<H3><a name="Guile_nn13"></a>18.6.1 GH Smobs</H3>
|
||||
<H3><a name="Guile_nn13"></a>20.6.1 GH Smobs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -455,7 +455,7 @@ that created them, so the first module we check will most likely be correct.
|
|||
Once we have a swig_type_info structure, we loop through the linked list of
|
||||
casts, using pointer comparisons.</p>
|
||||
|
||||
<H3><a name="Guile_nn14"></a>18.6.2 SCM Smobs</H3>
|
||||
<H3><a name="Guile_nn14"></a>20.6.2 SCM Smobs</H3>
|
||||
|
||||
|
||||
<p>The SCM interface (using the "-scm" argument to swig) uses swigrun.swg.
|
||||
|
|
@ -470,7 +470,7 @@ in the smob tag. If a generated GOOPS module has been loaded, smobs will be wra
|
|||
GOOPS class.</p>
|
||||
|
||||
|
||||
<H3><a name="Guile_nn15"></a>18.6.3 Garbage Collection</H3>
|
||||
<H3><a name="Guile_nn15"></a>20.6.3 Garbage Collection</H3>
|
||||
|
||||
|
||||
<p>Garbage collection is a feature of the new SCM interface, and it is automatically included
|
||||
|
|
@ -484,7 +484,7 @@ is exactly like described in <a href="Customization.html#ownership">
|
|||
Object ownership and %newobject</a> in the SWIG manual. All typemaps use an $owner var, and
|
||||
the guile module replaces $owner with 0 or 1 depending on feature:new.</p>
|
||||
|
||||
<H2><a name="Guile_nn16"></a>18.7 Exception Handling</H2>
|
||||
<H2><a name="Guile_nn16"></a>20.7 Exception Handling</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -510,7 +510,7 @@ mapping:
|
|||
The default when not specified here is to use "swig-error".
|
||||
See Lib/exception.i for details.
|
||||
|
||||
<H2><a name="Guile_nn17"></a>18.8 Procedure documentation</H2>
|
||||
<H2><a name="Guile_nn17"></a>20.8 Procedure documentation</H2>
|
||||
|
||||
|
||||
<p>If invoked with the command-line option <code>-procdoc
|
||||
|
|
@ -546,7 +546,7 @@ like this:
|
|||
typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
|
||||
details.
|
||||
|
||||
<H2><a name="Guile_nn18"></a>18.9 Procedures with setters</H2>
|
||||
<H2><a name="Guile_nn18"></a>20.9 Procedures with setters</H2>
|
||||
|
||||
|
||||
<p>For global variables, SWIG creates a single wrapper procedure
|
||||
|
|
@ -574,7 +574,7 @@ struct members, the procedures <code>(<var>struct</var>-<var>member</var>-get
|
|||
pointer)</code> and <code>(<var>struct-member</var>-set pointer
|
||||
value)</code> are <em>not</em> generated.
|
||||
|
||||
<H2><a name="Guile_nn19"></a>18.10 GOOPS Proxy Classes</H2>
|
||||
<H2><a name="Guile_nn19"></a>20.10 GOOPS Proxy Classes</H2>
|
||||
|
||||
|
||||
<p>SWIG can also generate classes and generic functions for use with
|
||||
|
|
@ -723,7 +723,7 @@ Notice that <Foo> is used before it is defined. The fix is to just put th
|
|||
<code>%import "foo.h"</code> before the <code>%inline</code> block.
|
||||
</p>
|
||||
|
||||
<H3><a name="Guile_nn20"></a>18.10.1 Naming Issues</H3>
|
||||
<H3><a name="Guile_nn20"></a>20.10.1 Naming Issues</H3>
|
||||
|
||||
|
||||
<p>As you can see in the example above, there are potential naming conflicts. The default exported
|
||||
|
|
@ -762,7 +762,7 @@ guile-modules. For example,</p>
|
|||
|
||||
<p>TODO: Renaming class name prefixes?</p>
|
||||
|
||||
<H3><a name="Guile_nn21"></a>18.10.2 Linking</H3>
|
||||
<H3><a name="Guile_nn21"></a>20.10.2 Linking</H3>
|
||||
|
||||
|
||||
<p>The guile-modules generated above all need to be linked together. GOOPS support requires
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Java"></a>19 SWIG and Java</H1>
|
||||
<H1><a name="Java"></a>21 SWIG and Java</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -146,7 +146,7 @@ It covers most SWIG features, but certain low-level details are covered in less
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="java_overview"></a>19.1 Overview</H2>
|
||||
<H2><a name="java_overview"></a>21.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -181,7 +181,7 @@ Various customisation tips and techniques using SWIG directives are covered.
|
|||
The latter sections cover the advanced techniques of using typemaps for complete control of the wrapping process.
|
||||
</p>
|
||||
|
||||
<H2><a name="java_preliminaries"></a>19.2 Preliminaries</H2>
|
||||
<H2><a name="java_preliminaries"></a>21.2 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -197,7 +197,7 @@ Run <tt>make -k check</tt> from the SWIG root directory after installing SWIG on
|
|||
The Java module requires your system to support shared libraries and dynamic loading.
|
||||
This is the commonly used method to load JNI code so your system will more than likely support this.</p>
|
||||
|
||||
<H3><a name="running_swig"></a>19.2.1 Running SWIG</H3>
|
||||
<H3><a name="running_swig"></a>21.2.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -244,7 +244,7 @@ To change this, you can use the <tt>-o</tt> option.
|
|||
It is also possible to change the <a href="SWIG.html#output">output directory </a> that the Java files are generated into using <tt>-outdir</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="java_commandline"></a>19.2.2 Additional Commandline Options</H3>
|
||||
<H3><a name="java_commandline"></a>21.2.2 Additional Commandline Options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -276,7 +276,7 @@ swig -java -help
|
|||
Their use will become clearer by the time you have finished reading this section on SWIG and Java.
|
||||
</p>
|
||||
|
||||
<H3><a name="getting_right_headers"></a>19.2.3 Getting the right header files</H3>
|
||||
<H3><a name="getting_right_headers"></a>21.2.3 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -291,7 +291,7 @@ They are usually in directories like this:</p>
|
|||
<p>
|
||||
The exact location may vary on your machine, but the above locations are typical. </p>
|
||||
|
||||
<H3><a name="compiling_dynamic"></a>19.2.4 Compiling a dynamic module</H3>
|
||||
<H3><a name="compiling_dynamic"></a>21.2.4 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -319,7 +319,7 @@ The name of the shared library output file is important.
|
|||
If the name of your SWIG module is "<tt>example</tt>", the name of the corresponding shared library file should be "<tt>libexample.so</tt>" (or equivalent depending on your machine, see <a href="#dynamic_linking_problems">Dynamic linking problems</a> for more information).
|
||||
The name of the module is specified using the <tt>%module</tt> directive or<tt> -module</tt> command line option.</p>
|
||||
|
||||
<H3><a name="using_module"></a>19.2.5 Using your module</H3>
|
||||
<H3><a name="using_module"></a>21.2.5 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -354,7 +354,7 @@ $
|
|||
If it doesn't work have a look at the following section which discusses problems loading the shared library.
|
||||
</p>
|
||||
|
||||
<H3><a name="dynamic_linking_problems"></a>19.2.6 Dynamic linking problems</H3>
|
||||
<H3><a name="dynamic_linking_problems"></a>21.2.6 Dynamic linking problems</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -428,7 +428,7 @@ The following section also contains some C++ specific linking problems and solut
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="compilation_problems_cpp"></a>19.2.7 Compilation problems and compiling with C++</H3>
|
||||
<H3><a name="compilation_problems_cpp"></a>21.2.7 Compilation problems and compiling with C++</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -481,7 +481,7 @@ Finally make sure the version of JDK header files matches the version of Java th
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="building_windows"></a>19.2.8 Building on Windows</H3>
|
||||
<H3><a name="building_windows"></a>21.2.8 Building on Windows</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -490,7 +490,7 @@ You will want to produce a DLL that can be loaded by the Java Virtual Machine.
|
|||
This section covers the process of using SWIG with Microsoft Visual C++ 6 although the procedure may be similar with other compilers.
|
||||
In order for everything to work, you will need to have a JDK installed on your machine in order to read the JNI header files.</p>
|
||||
|
||||
<H4><a name="visual_studio"></a>19.2.8.1 Running SWIG from Visual Studio</H4>
|
||||
<H4><a name="visual_studio"></a>21.2.8.1 Running SWIG from Visual Studio</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -529,7 +529,7 @@ To run the native code in the DLL (example.dll), make sure that it is in your pa
|
|||
If the library fails to load have a look at <a href="#dynamic_linking_problems">Dynamic linking problems</a>.
|
||||
</p>
|
||||
|
||||
<H4><a name="nmake"></a>19.2.8.2 Using NMAKE</H4>
|
||||
<H4><a name="nmake"></a>21.2.8.2 Using NMAKE</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -588,7 +588,7 @@ Of course you may want to make changes for it to work for C++ by adding in the -
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="java_basic_tour"></a>19.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="java_basic_tour"></a>21.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -598,7 +598,7 @@ variables are wrapped with JavaBean type getters and setters and so forth.
|
|||
This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="module_packages_classes"></a>19.3.1 Modules, packages and generated Java classes</H3>
|
||||
<H3><a name="module_packages_classes"></a>21.3.1 Modules, packages and generated Java classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -632,7 +632,7 @@ swig -java -package com.bloggs.swig -outdir com/bloggs/swig example.i
|
|||
|
||||
SWIG won't create the directory, so make sure it exists beforehand.
|
||||
|
||||
<H3><a name="functions"></a>19.3.2 Functions</H3>
|
||||
<H3><a name="functions"></a>21.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -666,7 +666,7 @@ System.out.println(example.fact(4));
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="global_variables"></a>19.3.3 Global variables</H3>
|
||||
<H3><a name="global_variables"></a>21.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -753,7 +753,7 @@ extern char *path; // Read-only (due to %immutable)
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="constants"></a>19.3.4 Constants</H3>
|
||||
<H3><a name="constants"></a>21.3.4 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -885,7 +885,7 @@ Or if you decide this practice isn't so bad and your own class implements <tt>ex
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="enumerations"></a>19.3.5 Enumerations</H3>
|
||||
<H3><a name="enumerations"></a>21.3.5 Enumerations</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -899,7 +899,7 @@ The final two approaches use simple integers for each enum item.
|
|||
Before looking at the various approaches for wrapping named C/C++ enums, anonymous enums are considered.
|
||||
</p>
|
||||
|
||||
<H4><a name="anonymous_enums"></a>19.3.5.1 Anonymous enums</H4>
|
||||
<H4><a name="anonymous_enums"></a>21.3.5.1 Anonymous enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -960,7 +960,7 @@ As in the case of constants, you can access them through either the module class
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="typesafe_enums"></a>19.3.5.2 Typesafe enums</H4>
|
||||
<H4><a name="typesafe_enums"></a>21.3.5.2 Typesafe enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1051,7 +1051,7 @@ When upgrading to J2SDK 1.5 or later, proper Java enums could be used instead, w
|
|||
The following section details proper Java enum generation.
|
||||
</p>
|
||||
|
||||
<H4><a name="proper_enums"></a>19.3.5.3 Proper Java enums</H4>
|
||||
<H4><a name="proper_enums"></a>21.3.5.3 Proper Java enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1103,7 +1103,7 @@ The additional support methods need not be generated if none of the enum items h
|
|||
<a href="#simpler_enum_classes">Simpler Java enums for enums without initializers</a> section.
|
||||
</p>
|
||||
|
||||
<H4><a name="typeunsafe_enums"></a>19.3.5.4 Type unsafe enums</H4>
|
||||
<H4><a name="typeunsafe_enums"></a>21.3.5.4 Type unsafe enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1150,7 +1150,7 @@ Note that unlike typesafe enums, this approach requires users to mostly use diff
|
|||
Thus the upgrade path to proper enums provided in J2SDK 1.5 is more painful.
|
||||
</p>
|
||||
|
||||
<H4><a name="simple_enums"></a>19.3.5.5 Simple enums</H4>
|
||||
<H4><a name="simple_enums"></a>21.3.5.5 Simple enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1169,7 +1169,7 @@ SWIG-1.3.21 and earlier versions wrapped all enums using this approach.
|
|||
The type unsafe approach is preferable to this one and this simple approach is only included for backwards compatibility with these earlier versions of SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="pointers"></a>19.3.6 Pointers</H3>
|
||||
<H3><a name="pointers"></a>21.3.6 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1257,7 +1257,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
|
|||
a NULL pointer if the conversion can't be performed.
|
||||
</p>
|
||||
|
||||
<H3><a name="structures"></a>19.3.7 Structures</H3>
|
||||
<H3><a name="structures"></a>21.3.7 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1425,7 +1425,7 @@ x.setA(3); // Modify x.a - this is the same as b.f.a
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="classes"></a>19.3.8 C++ classes</H3>
|
||||
<H3><a name="classes"></a>21.3.8 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1488,7 +1488,7 @@ int bar = Spam.getBar();
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="inheritance"></a>19.3.9 C++ inheritance</H3>
|
||||
<H3><a name="inheritance"></a>21.3.9 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1549,7 +1549,7 @@ Note that Java does not support multiple inheritance so any multiple inheritance
|
|||
A warning is given when multiple inheritance is detected and only the first base class is used.
|
||||
</p>
|
||||
|
||||
<H3><a name="pointers_refs_arrays"></a>19.3.10 Pointers, references, arrays and pass by value</H3>
|
||||
<H3><a name="pointers_refs_arrays"></a>21.3.10 Pointers, references, arrays and pass by value</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1604,7 +1604,7 @@ to hold the result and a pointer is returned (Java will release this memory
|
|||
when the returned object's finalizer is run by the garbage collector).
|
||||
</p>
|
||||
|
||||
<H4><a name="null_pointers"></a>19.3.10.1 Null pointers</H4>
|
||||
<H4><a name="null_pointers"></a>21.3.10.1 Null pointers</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1628,7 +1628,7 @@ For <tt>spam1</tt> and <tt>spam4</tt> above the Java <tt>null</tt> gets translat
|
|||
The converse also occurs, that is, NULL pointers are translated into <tt>null</tt> Java objects when returned from a C/C++ function.
|
||||
</p>
|
||||
|
||||
<H3><a name="overloaded_functions"></a>19.3.11 C++ overloaded functions</H3>
|
||||
<H3><a name="overloaded_functions"></a>21.3.11 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1743,7 +1743,7 @@ void spam(short); // Ignored
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="java_default_arguments"></a>19.3.12 C++ default arguments</H3>
|
||||
<H3><a name="java_default_arguments"></a>21.3.12 C++ default arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1786,7 +1786,7 @@ Further details on default arguments and how to restore this approach are given
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="namespaces"></a>19.3.13 C++ namespaces</H3>
|
||||
<H3><a name="namespaces"></a>21.3.13 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1846,7 +1846,7 @@ symbols separate, consider wrapping them as separate SWIG modules.
|
|||
Each SWIG module can be placed into a separate package.
|
||||
</p>
|
||||
|
||||
<H3><a name="templates"></a>19.3.14 C++ templates</H3>
|
||||
<H3><a name="templates"></a>21.3.14 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1895,7 +1895,7 @@ Obviously, there is more to template wrapping than shown in this example.
|
|||
More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a> chapter.
|
||||
</p>
|
||||
|
||||
<H3><a name="smart_pointers"></a>19.3.15 C++ Smart Pointers</H3>
|
||||
<H3><a name="smart_pointers"></a>21.3.15 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1979,7 +1979,7 @@ Foo f = p.__deref__(); // Returns underlying Foo *
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="further_details"></a>19.4 Further details on the generated Java classes</H2>
|
||||
<H2><a name="further_details"></a>21.4 Further details on the generated Java classes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1994,7 +1994,7 @@ Finally enum classes are covered.
|
|||
First, the crucial intermediary JNI class is considered.
|
||||
</p>
|
||||
|
||||
<H3><a name="imclass"></a>19.4.1 The intermediary JNI class</H3>
|
||||
<H3><a name="imclass"></a>21.4.1 The intermediary JNI class</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2107,7 +2107,7 @@ If <tt>name</tt> is the same as <tt>modulename</tt> then the module class name g
|
|||
from <tt>modulename</tt> to <tt>modulenameModule</tt>.
|
||||
</p>
|
||||
|
||||
<H4><a name="imclass_pragmas"></a>19.4.1.1 The intermediary JNI class pragmas</H4>
|
||||
<H4><a name="imclass_pragmas"></a>21.4.1.1 The intermediary JNI class pragmas</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2186,7 +2186,7 @@ For example, let's change the intermediary JNI class access to public.
|
|||
All the methods in the intermediary JNI class will then be callable outside of the package as the method modifiers are public by default.
|
||||
</p>
|
||||
|
||||
<H3><a name="java_module_class"></a>19.4.2 The Java module class</H3>
|
||||
<H3><a name="java_module_class"></a>21.4.2 The Java module class</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2217,7 +2217,7 @@ example.egg(new Foo());
|
|||
The primary reason for having the module class wrapping the calls in the intermediary JNI class is to implement static type checking. In this case only a <tt>Foo</tt> can be passed to the <tt>egg</tt> function, whereas any <tt>long</tt> can be passed to the <tt>egg</tt> function in the intermediary JNI class.
|
||||
</p>
|
||||
|
||||
<H4><a name="module_class_pragmas"></a>19.4.2.1 The Java module class pragmas</H4>
|
||||
<H4><a name="module_class_pragmas"></a>21.4.2.1 The Java module class pragmas</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2268,7 +2268,7 @@ See <a href="#imclass_pragmas">The intermediary JNI class pragmas</a> section fo
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="java_proxy_classes"></a>19.4.3 Java proxy classes</H3>
|
||||
<H3><a name="java_proxy_classes"></a>21.4.3 Java proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2342,7 +2342,7 @@ int y = f.spam(5, new Foo());
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="memory_management"></a>19.4.3.1 Memory management</H4>
|
||||
<H4><a name="memory_management"></a>21.4.3.1 Memory management</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2504,7 +2504,7 @@ and
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="inheritance_mirroring"></a>19.4.3.2 Inheritance</H4>
|
||||
<H4><a name="inheritance_mirroring"></a>21.4.3.2 Inheritance</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2618,7 +2618,7 @@ However, true cross language polymorphism can be achieved using the <a href="#ja
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="proxy_classes_gc"></a>19.4.3.3 Proxy classes and garbage collection</H4>
|
||||
<H4><a name="proxy_classes_gc"></a>21.4.3.3 Proxy classes and garbage collection</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2695,7 +2695,7 @@ The section on <a href="#java_typemaps">Java typemaps</a> details how to specify
|
|||
</li>
|
||||
</ol>
|
||||
|
||||
<H3><a name="type_wrapper_classes"></a>19.4.4 Type wrapper classes</H3>
|
||||
<H3><a name="type_wrapper_classes"></a>21.4.4 Type wrapper classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2782,7 +2782,7 @@ public static void spam(SWIGTYPE_p_int x, SWIGTYPE_p_int y, int z) { ... }
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="enum_classes"></a>19.4.5 Enum classes</H3>
|
||||
<H3><a name="enum_classes"></a>21.4.5 Enum classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2791,7 +2791,7 @@ The <a href="#enumerations">Enumerations</a> section discussed these but omitted
|
|||
The following sub-sections detail the various types of enum classes that can be generated.
|
||||
</p>
|
||||
|
||||
<H4><a name="typesafe_enums_classes"></a>19.4.5.1 Typesafe enum classes</H4>
|
||||
<H4><a name="typesafe_enums_classes"></a>21.4.5.1 Typesafe enum classes</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2867,7 +2867,7 @@ The <tt>swigValue</tt> method is used for marshalling in the other direction.
|
|||
The <tt>toString</tt> method is overridden so that the enum name is available.
|
||||
</p>
|
||||
|
||||
<H4><a name="proper_enums_classes"></a>19.4.5.2 Proper Java enum classes</H4>
|
||||
<H4><a name="proper_enums_classes"></a>21.4.5.2 Proper Java enum classes</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2939,7 +2939,7 @@ These needn't be generated if the enum being wrapped does not have any initializ
|
|||
<a href="#simpler_enum_classes">Simpler Java enums for enums without initializers</a> section describes how typemaps can be used to achieve this.
|
||||
</p>
|
||||
|
||||
<H4><a name="typeunsafe_enums_classes"></a>19.4.5.3 Type unsafe enum classes</H4>
|
||||
<H4><a name="typeunsafe_enums_classes"></a>21.4.5.3 Type unsafe enum classes</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2969,7 +2969,7 @@ public final class Beverage {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="java_directors"></a>19.5 Cross language polymorphism using directors (experimental)</H2>
|
||||
<H2><a name="java_directors"></a>21.5 Cross language polymorphism using directors (experimental)</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2991,7 +2991,7 @@ The upshot is that C++ classes can be extended in Java and from C++ these extens
|
|||
Neither C++ code nor Java code needs to know where a particular method is implemented: the combination of proxy classes, director classes, and C wrapper functions transparently takes care of all the cross-language method routing.
|
||||
</p>
|
||||
|
||||
<H3><a name="java_enabling_directors"></a>19.5.1 Enabling directors</H3>
|
||||
<H3><a name="java_enabling_directors"></a>21.5.1 Enabling directors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3062,7 +3062,7 @@ public:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="java_directors_classes"></a>19.5.2 Director classes</H3>
|
||||
<H3><a name="java_directors_classes"></a>21.5.2 Director classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3089,7 +3089,7 @@ If the correct implementation is in Java, the Java API is used to call the metho
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="java_directors_overhead"></a>19.5.3 Overhead and code bloat</H3>
|
||||
<H3><a name="java_directors_overhead"></a>21.5.3 Overhead and code bloat</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3107,7 +3107,7 @@ This situation can be optimized by selectively enabling director methods (using
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="java_directors_example"></a>19.5.4 Simple directors example</H3>
|
||||
<H3><a name="java_directors_example"></a>21.5.4 Simple directors example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3172,7 +3172,7 @@ directorDerived::upcall_method() invoked.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="common_customization"></a>19.6 Common customization features</H2>
|
||||
<H2><a name="common_customization"></a>21.6 Common customization features</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3184,7 +3184,7 @@ be awkward. This section describes some common SWIG features that are used
|
|||
to improve the interface to existing C/C++ code.
|
||||
</p>
|
||||
|
||||
<H3><a name="helper_functions"></a>19.6.1 C/C++ helper functions</H3>
|
||||
<H3><a name="helper_functions"></a>21.6.1 C/C++ helper functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3250,7 +3250,7 @@ hard to implement. It is possible to improve on this using Java code, typemaps,
|
|||
customization features as covered in later sections, but sometimes helper functions are a quick and easy solution to difficult cases.
|
||||
</p>
|
||||
|
||||
<H3><a name="class_extension"></a>19.6.2 Class extension with %extend</H3>
|
||||
<H3><a name="class_extension"></a>21.6.2 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3313,7 +3313,7 @@ Vector(2,3,4)
|
|||
in any way---the extensions only show up in the Java interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="exception_handling"></a>19.6.3 Exception handling with %exception and %javaexception</H3>
|
||||
<H3><a name="exception_handling"></a>21.6.3 Exception handling with %exception and %javaexception</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3470,7 +3470,7 @@ to raise exceptions. See the <a href="Library.html#Library">SWIG Library</a> ch
|
|||
The typemap example <a href="#exception_typemap">Handling C++ exception specifications as Java exceptions</a> provides further exception handling capabilities.
|
||||
</p>
|
||||
|
||||
<H3><a name="method_access"></a>19.6.4 Method access with %javamethodmodifiers</H3>
|
||||
<H3><a name="method_access"></a>21.6.4 Method access with %javamethodmodifiers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3496,7 +3496,7 @@ protected static void protect_me() {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="tips_techniques"></a>19.7 Tips and techniques</H2>
|
||||
<H2><a name="tips_techniques"></a>21.7 Tips and techniques</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3506,7 +3506,7 @@ strings and arrays. This chapter discusses the common techniques for
|
|||
solving these problems.
|
||||
</p>
|
||||
|
||||
<H3><a name="input_output_parameters"></a>19.7.1 Input and output parameters using primitive pointers and references</H3>
|
||||
<H3><a name="input_output_parameters"></a>21.7.1 Input and output parameters using primitive pointers and references</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3680,7 +3680,7 @@ void foo(Bar *OUTPUT);
|
|||
will not have the intended effect since <tt>typemaps.i</tt> does not define an OUTPUT rule for <tt>Bar</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="simple_pointers"></a>19.7.2 Simple pointers</H3>
|
||||
<H3><a name="simple_pointers"></a>21.7.2 Simple pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3746,7 +3746,7 @@ System.out.println("3 + 4 = " + result);
|
|||
See the <a href="Library.html#Library">SWIG Library</a> chapter for further details.
|
||||
</p>
|
||||
|
||||
<H3><a name="c_arrays"></a>19.7.3 Wrapping C arrays with Java arrays</H3>
|
||||
<H3><a name="c_arrays"></a>21.7.3 Wrapping C arrays with Java arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3813,7 +3813,7 @@ Please be aware that the typemaps in this library are not efficient as all the e
|
|||
There is an alternative approach using the SWIG array library and this is covered in the next section.
|
||||
</p>
|
||||
|
||||
<H3><a name="unbounded_c_arrays"></a>19.7.4 Unbounded C Arrays</H3>
|
||||
<H3><a name="unbounded_c_arrays"></a>21.7.4 Unbounded C Arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3958,7 +3958,7 @@ well suited for applications in which you need to create buffers,
|
|||
package binary data, etc.
|
||||
</p>
|
||||
|
||||
<H2><a name="java_typemaps"></a>19.8 Java typemaps</H2>
|
||||
<H2><a name="java_typemaps"></a>21.8 Java typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3979,7 +3979,7 @@ Before proceeding, it should be stressed that typemaps are not a required
|
|||
part of using SWIG---the default wrapping behavior is enough in most cases.
|
||||
Typemaps are only used if you want to change some aspect of the generated code.
|
||||
|
||||
<H3><a name="default_primitive_type_mappings"></a>19.8.1 Default primitive type mappings</H3>
|
||||
<H3><a name="default_primitive_type_mappings"></a>21.8.1 Default primitive type mappings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4130,7 +4130,7 @@ There is no perfect mapping between Java and C as Java doesn't support all the u
|
|||
However, the mappings allow the full range of values for each C type from Java.
|
||||
</p>
|
||||
|
||||
<H3><a name="jvm64"></a>19.8.2 Sixty four bit JVMs</H3>
|
||||
<H3><a name="jvm64"></a>21.8.2 Sixty four bit JVMs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4143,7 +4143,7 @@ Unfortunately it won't of course hold true for JNI code.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="what_is_typemap"></a>19.8.3 What is a typemap?</H3>
|
||||
<H3><a name="what_is_typemap"></a>21.8.3 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4266,7 +4266,7 @@ int c = example.count('e',"Hello World");
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="typemaps_c_to_java_types"></a>19.8.4 Typemaps for mapping C/C++ types to Java types</H3>
|
||||
<H3><a name="typemaps_c_to_java_types"></a>21.8.4 Typemaps for mapping C/C++ types to Java types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4456,7 +4456,7 @@ These are listed below:
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="typemap_attributes"></a>19.8.5 Java typemap attributes</H3>
|
||||
<H3><a name="typemap_attributes"></a>21.8.5 Java typemap attributes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4486,7 +4486,7 @@ the union of the exception classes is added to the throws clause ensuring there
|
|||
See the <a href="#nan_exception_typemap">NaN exception example</a> for further usage.
|
||||
</p>
|
||||
|
||||
<H3><a name="special_variables"></a>19.8.6 Java special variables</H3>
|
||||
<H3><a name="special_variables"></a>21.8.6 Java special variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4621,7 +4621,7 @@ This special variable expands to the module name, as specified by <tt>%module</t
|
|||
Useful for constructing the intermediary classname, which is just <tt>$moduleJNI</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="typemaps_for_c_and_c++"></a>19.8.7 Typemaps for both C and C++ compilation</H3>
|
||||
<H3><a name="typemaps_for_c_and_c++"></a>21.8.7 Typemaps for both C and C++ compilation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4658,7 +4658,7 @@ If you do not intend your code to be targeting both C and C++ then your typemaps
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="java_code_typemaps"></a>19.8.8 Java code typemaps</H3>
|
||||
<H3><a name="java_code_typemaps"></a>21.8.8 Java code typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4848,7 +4848,7 @@ For the typemap to be used in all type wrapper classes, all the different types
|
|||
Again this is the same that is in "<tt>java.swg</tt>", barring the method modifier for <tt>getCPtr</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="java_directors_typemaps"></a>19.8.9 Director specific typemaps</H3>
|
||||
<H3><a name="java_directors_typemaps"></a>21.8.9 Director specific typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5038,7 +5038,7 @@ The basic strategy here is to provide a default package typemap for the majority
|
|||
|
||||
</div>
|
||||
|
||||
<H2><a name="typemap_examples"></a>19.9 Typemap Examples</H2>
|
||||
<H2><a name="typemap_examples"></a>21.9 Typemap Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5048,7 +5048,7 @@ the SWIG library.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="simpler_enum_classes"></a>19.9.1 Simpler Java enums for enums without initializers</H3>
|
||||
<H3><a name="simpler_enum_classes"></a>21.9.1 Simpler Java enums for enums without initializers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5127,7 +5127,7 @@ This would be done by using the original versions of these typemaps in "enums.sw
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="exception_typemap"></a>19.9.2 Handling C++ exception specifications as Java exceptions</H3>
|
||||
<H3><a name="exception_typemap"></a>21.9.2 Handling C++ exception specifications as Java exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5252,7 +5252,7 @@ We could alternatively have used <tt>%rename</tt> to rename <tt>what()</tt> into
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="nan_exception_typemap"></a>19.9.3 NaN Exception - exception handling for a particular type</H3>
|
||||
<H3><a name="nan_exception_typemap"></a>21.9.3 NaN Exception - exception handling for a particular type</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5370,7 +5370,7 @@ If we were a martyr to the JNI cause, we could replace the succinct code within
|
|||
If we had, we would have put it in the "in" typemap which, like all JNI and Java typemaps, also supports the 'throws' attribute.
|
||||
</p>
|
||||
|
||||
<H3><a name="converting_java_string_arrays"></a>19.9.4 Converting Java String arrays to char ** </H3>
|
||||
<H3><a name="converting_java_string_arrays"></a>21.9.4 Converting Java String arrays to char ** </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5514,7 +5514,7 @@ Lastly the "jni", "jtype" and "jstype" typemaps are also required to specify
|
|||
what Java types to use.
|
||||
</p>
|
||||
|
||||
<H3><a name="expanding_java_object"></a>19.9.5 Expanding a Java object to multiple arguments</H3>
|
||||
<H3><a name="expanding_java_object"></a>21.9.5 Expanding a Java object to multiple arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5596,7 +5596,7 @@ example.foo(new String[]{"red", "green", "blue", "white"});
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="using_typemaps_return_arguments"></a>19.9.6 Using typemaps to return arguments</H3>
|
||||
<H3><a name="using_typemaps_return_arguments"></a>21.9.6 Using typemaps to return arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5714,7 +5714,7 @@ $ java main
|
|||
1 12.0 340.0
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="adding_downcasts"></a>19.9.7 Adding Java downcasts to polymorphic return types</H3>
|
||||
<H3><a name="adding_downcasts"></a>21.9.7 Adding Java downcasts to polymorphic return types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5920,7 +5920,7 @@ SWIG usually generates code which constructs the proxy classes using Java code a
|
|||
Note that the JNI code above uses a number of string lookups to call a constructor, whereas this would not occur using byte compiled Java code.
|
||||
</p>
|
||||
|
||||
<H3><a name="adding_equals_method"></a>19.9.8 Adding an equals method to the Java classes</H3>
|
||||
<H3><a name="adding_equals_method"></a>21.9.8 Adding an equals method to the Java classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5959,7 +5959,7 @@ System.out.println("foo1? " + foo1.equals(foo2));
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="void_pointers"></a>19.9.9 Void pointers and a common Java base class</H3>
|
||||
<H3><a name="void_pointers"></a>21.9.9 Void pointers and a common Java base class</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6018,7 +6018,7 @@ This example contains some useful functionality which you may want in your code.
|
|||
<li> It also has a function which effectively implements a cast from the type of the proxy/type wrapper class to a void pointer. This is necessary for passing a proxy class or a type wrapper class to a function that takes a void pointer.
|
||||
</ul>
|
||||
|
||||
<H3><a name="struct_pointer_pointer"></a>19.9.10 Struct pointer to pointer</H3>
|
||||
<H3><a name="struct_pointer_pointer"></a>21.9.10 Struct pointer to pointer</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6190,7 +6190,7 @@ The C functional interface has been completely morphed into an object-oriented i
|
|||
the Butler class would behave much like any pure Java class and feel more natural to Java users.
|
||||
</p>
|
||||
|
||||
<H3><a name="java_memory_management_member_variables"></a>19.9.11 Memory management when returning references to member variables</H3>
|
||||
<H3><a name="java_memory_management_member_variables"></a>21.9.11 Memory management when returning references to member variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6313,7 +6313,7 @@ public class Bike {
|
|||
Note the <tt>addReference</tt> call.
|
||||
</p>
|
||||
|
||||
<H3><a name="java_memory_management_objects"></a>19.9.12 Memory management for objects passed to the C++ layer</H3>
|
||||
<H3><a name="java_memory_management_objects"></a>21.9.12 Memory management for objects passed to the C++ layer</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6430,7 +6430,7 @@ The 'javacode' typemap simply adds in the specified code into the Java proxy cla
|
|||
|
||||
|
||||
|
||||
<H2><a name="java_directors_faq"></a>19.10 Living with Java Directors</H2>
|
||||
<H2><a name="java_directors_faq"></a>21.10 Living with Java Directors</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6611,10 +6611,10 @@ public abstract class UserVisibleFoo extends Foo {
|
|||
</li>
|
||||
</ol>
|
||||
|
||||
<H2><a name="odds_ends"></a>19.11 Odds and ends</H2>
|
||||
<H2><a name="odds_ends"></a>21.11 Odds and ends</H2>
|
||||
|
||||
|
||||
<H3><a name="javadoc_comments"></a>19.11.1 JavaDoc comments</H3>
|
||||
<H3><a name="javadoc_comments"></a>21.11.1 JavaDoc comments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6670,7 +6670,7 @@ public class Barmy {
|
|||
|
||||
|
||||
|
||||
<H3><a name="functional_interface"></a>19.11.2 Functional interface without proxy classes</H3>
|
||||
<H3><a name="functional_interface"></a>21.11.2 Functional interface without proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6731,7 +6731,7 @@ All destructors have to be called manually for example the <tt>delete_Foo(foo)</
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="using_own_jni_functions"></a>19.11.3 Using your own JNI functions</H3>
|
||||
<H3><a name="using_own_jni_functions"></a>21.11.3 Using your own JNI functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6781,7 +6781,7 @@ This directive is only really useful if you want to mix your own hand crafted JN
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="performance"></a>19.11.4 Performance concerns and hints</H3>
|
||||
<H3><a name="performance"></a>21.11.4 Performance concerns and hints</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6803,7 +6803,7 @@ This method normally calls the C++ destructor or <tt>free()</tt> for C code.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="java_examples"></a>19.12 Examples</H2>
|
||||
<H2><a name="java_examples"></a>21.12 Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,17 +6,23 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Lisp_nn1"></a>30 SWIG and Common Lisp</H1>
|
||||
<H1><a name="Lisp_nn1"></a>16 SWIG and Common Lisp</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Lisp.html#Lisp_nn2">Allegro Common Lisp</a>
|
||||
<li><a href="Lisp.html#Lisp_nn3">CLISP</a>
|
||||
<li><a href="Lisp.html#Lisp_nn4">UFFI</a>
|
||||
<li><a href="#Lisp_nn2">Allegro Common Lisp</a>
|
||||
<li><a href="#Lisp_nn3">CLISP</a>
|
||||
<ul>
|
||||
<li><a href="#Lisp_nn4">Additional Commandline Options </a>
|
||||
<li><a href="#Lisp_nn5">Details on CLISP bindings</a>
|
||||
</ul>
|
||||
<li><a href="#Lisp_nn6">UFFI </a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
|
||||
|
||||
<p>
|
||||
Common Lisp is a high-level, all-purpose, object-oriented,
|
||||
dynamic, functional programming language with long history.
|
||||
|
|
@ -27,10 +33,19 @@
|
|||
interfaces. SWIG currently supports only the Allegro Common
|
||||
Lisp, CLisp and UFFI foreign function interfaces.
|
||||
</p>
|
||||
<H2><a name="Lisp_nn2"></a>30.1 Allegro Common Lisp</H2>
|
||||
<H2><a name="Lisp_nn2"></a>16.1 Allegro Common Lisp</H2>
|
||||
|
||||
|
||||
<p>
|
||||
Allegro Common Lisp support in SWIG has been updated to include
|
||||
support for both C and C++. You can read about the interface
|
||||
<a href="Allegrocl.html#Allegrocl_nn1">here</a>
|
||||
</p>
|
||||
<H2><a name="Lisp_nn3"></a>30.2 CLISP</H2>
|
||||
|
||||
|
||||
<H2><a name="Lisp_nn3"></a>16.2 CLISP</H2>
|
||||
|
||||
|
||||
<p>
|
||||
<a href="http://clisp.cons.org">CLISP</a> is a feature-loaded
|
||||
implementation of common lisp which is portable across most of the
|
||||
|
|
@ -56,7 +71,8 @@ swig -clispcl -module <i>module-name</i> <i>file-name</i>
|
|||
interface file for the CLISP module. The CLISP module tries to
|
||||
produce code which is both human readable and easily modifyable.
|
||||
</p>
|
||||
<H3><a name="Lisp_nn4"></a>30.2.1 Additional Commandline Options </H3>
|
||||
<H3><a name="Lisp_nn4"></a>16.2.1 Additional Commandline Options </H3>
|
||||
|
||||
|
||||
<p>
|
||||
The following table list the additional commandline options available for the CLISP module. They can also be seen by using:
|
||||
|
|
@ -88,7 +104,8 @@ and global variables will be created otherwise only definitions for<br/>
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lisp_nn5"></a>30.2.2 Details on CLISP bindings</H3>
|
||||
<H3><a name="Lisp_nn5"></a>16.2.2 Details on CLISP bindings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
As mentioned earlier the CLISP bindings generated by SWIG may need
|
||||
|
|
@ -211,7 +228,9 @@ struct bar {
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lisp_nn6"></a>30.3 UFFI </H2>
|
||||
<H2><a name="Lisp_nn6"></a>16.3 UFFI </H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Lua_nn1"></a>29 SWIG and Lua</H1>
|
||||
<H1><a name="Lua_nn1"></a>31 SWIG and Lua</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -49,7 +49,7 @@
|
|||
<p>
|
||||
Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in clean C (that is, in the common subset of ANSI C and C++). Its also a <em>really</em> tiny language, less than 6000 lines of code, which compiles to <100 kilobytes of binary code. It can be found at <a href="http://www.lua.org">http://www.lua.org</a>
|
||||
</p>
|
||||
<H2><a name="Lua_nn2"></a>29.1 Preliminaries</H2>
|
||||
<H2><a name="Lua_nn2"></a>31.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -58,7 +58,7 @@ The current SWIG implementation is designed to work with Lua 5.0. It should work
|
|||
<p>
|
||||
Note: Lua 5.1 (alpha) has just (as of September 05) been released. The current version of SWIG will produce wrappers which are compatible with Lua 5.1, though the dynamic loading mechanism has changed (see below). The configure script and makefiles should work correctly with with Lua 5.1, though some small tweaks may be needed.
|
||||
</p>
|
||||
<H2><a name="Lua_nn3"></a>29.2 Running SWIG</H2>
|
||||
<H2><a name="Lua_nn3"></a>31.2 Running SWIG</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -90,7 +90,7 @@ This creates a C/C++ source file <tt>example_wrap.c</tt> or <tt>example_wrap.cxx
|
|||
<p>
|
||||
The name of the wrapper file is derived from the name of the input file. For example, if the input file is <tt>example.i</tt>, the name of the wrapper file is <tt>example_wrap.c</tt>. To change this, you can use the -o option. The wrappered module will export one function <tt>"int Example_Init(LuaState* L)"</tt> which must be called to register the module with the Lua interpreter. The name "Example_Init" depends upon the name of the module. Note: SWIG will automatically capitalise the module name, so <tt>"module example;"</tt> becomes <tt>"Example_Init"</tt>.
|
||||
</p>
|
||||
<H3><a name="Lua_nn4"></a>29.2.1 Compiling and Linking and Interpreter</H3>
|
||||
<H3><a name="Lua_nn4"></a>31.2.1 Compiling and Linking and Interpreter</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -137,7 +137,7 @@ $ gcc -c example.c -o example.o
|
|||
$ gcc -I/usr/include/lua -L/usr/lib/lua min.o example_wrap.o example.o -o my_lua
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn5"></a>29.2.2 Compiling a dynamic module</H3>
|
||||
<H3><a name="Lua_nn5"></a>31.2.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -173,7 +173,7 @@ The wrappers produced by SWIG can be compiled and linked with Lua 5.1. The loadi
|
|||
require("example")
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn6"></a>29.2.3 Using your module</H3>
|
||||
<H3><a name="Lua_nn6"></a>31.2.3 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -191,19 +191,19 @@ $ ./my_lua
|
|||
>
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_nn7"></a>29.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Lua_nn7"></a>31.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
By default, SWIG tries to build a very natural Lua interface to your C/C++ code. This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
<H3><a name="Lua_nn8"></a>29.3.1 Modules</H3>
|
||||
<H3><a name="Lua_nn8"></a>31.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The SWIG module directive specifies the name of the Lua module. If you specify `module example', then everything is wrapped into a Lua table 'example' containing all the functions and variables. When choosing a module name, make sure you don't use the same name as a built-in Lua command or standard module name.
|
||||
</p>
|
||||
<H3><a name="Lua_nn9"></a>29.3.2 Functions</H3>
|
||||
<H3><a name="Lua_nn9"></a>31.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -241,7 +241,7 @@ It is also possible to rename the module with an assignment.
|
|||
24
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn10"></a>29.3.3 Global variables</H3>
|
||||
<H3><a name="Lua_nn10"></a>31.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -296,7 +296,7 @@ nil
|
|||
3.142
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn11"></a>29.3.4 Constants and enums</H3>
|
||||
<H3><a name="Lua_nn11"></a>31.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -319,7 +319,7 @@ example.SUNDAY=0
|
|||
<p>
|
||||
Constants are not guaranteed to remain constant in Lua. The name of the constant could be accidentally reassigned to refer to some other object. Unfortunately, there is no easy way for SWIG to generate code that prevents this. You will just have to be careful.
|
||||
</p>
|
||||
<H3><a name="Lua_nn12"></a>29.3.5 Pointers</H3>
|
||||
<H3><a name="Lua_nn12"></a>31.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -357,7 +357,7 @@ Lua enforces the integrity of its userdata, so it is virtually impossible to cor
|
|||
nil
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn13"></a>29.3.6 Structures</H3>
|
||||
<H3><a name="Lua_nn13"></a>31.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -443,7 +443,7 @@ Because the pointer points inside the structure, you can modify the contents and
|
|||
> x.a = 3 -- Modifies the same structure
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn14"></a>29.3.7 C++ classes</H3>
|
||||
<H3><a name="Lua_nn14"></a>31.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -503,7 +503,7 @@ It is not (currently) possible to access static members of an instance:
|
|||
-- does NOT work
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn15"></a>29.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Lua_nn15"></a>31.3.8 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -528,7 +528,7 @@ then the function <tt>spam()</tt> accepts a Foo pointer or a pointer to any clas
|
|||
<p>
|
||||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
<H3><a name="Lua_nn16"></a>29.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Lua_nn16"></a>31.3.9 Pointers, references, values, and arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -559,7 +559,7 @@ Foo spam7();
|
|||
<p>
|
||||
then all three functions will return a pointer to some Foo object. Since the third function (spam7) returns a value, newly allocated memory is used to hold the result and a pointer is returned (Lua will release this memory when the return value is garbage collected). The other two are pointers which are assumed to be managed by the C code and so will not be garbage collected.
|
||||
</p>
|
||||
<H3><a name="Lua_nn17"></a>29.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Lua_nn17"></a>31.3.10 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -645,7 +645,7 @@ Please refer to the "SWIG and C++" chapter for more information about overloadin
|
|||
<p>
|
||||
Dealing with the Lua coercion mechanism, the priority is roughly (integers, floats, strings, userdata). But it is better to rename the functions rather than rely upon the ordering.
|
||||
</p>
|
||||
<H3><a name="Lua_nn18"></a>29.3.11 C++ operators</H3>
|
||||
<H3><a name="Lua_nn18"></a>31.3.11 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -760,7 +760,7 @@ It is also possible to overload the operator<tt>[]</tt>, but currently this cann
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn19"></a>29.3.12 Class extension with %extend</H3>
|
||||
<H3><a name="Lua_nn19"></a>31.3.12 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -815,7 +815,7 @@ true
|
|||
<p>
|
||||
Extend works with both C and C++ code, on classes and structs. It does not modify the underlying object in any way---the extensions only show up in the Lua interface. The only item to take note of is the code has to use the 'self' instead of 'this', and that you cannot access protected/private members of the code (as you are not officially part of the class).
|
||||
</p>
|
||||
<H3><a name="Lua_nn20"></a>29.3.13 C++ templates</H3>
|
||||
<H3><a name="Lua_nn20"></a>31.3.13 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -850,7 +850,7 @@ In Lua:
|
|||
<p>
|
||||
Obviously, there is more to template wrapping than shown in this example. More details can be found in the SWIG and C++ chapter. Some more complicated examples will appear later.
|
||||
</p>
|
||||
<H3><a name="Lua_nn21"></a>29.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Lua_nn21"></a>31.3.14 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -902,7 +902,7 @@ If you ever need to access the underlying pointer returned by <tt>operator->(
|
|||
> f = p:__deref__() -- Returns underlying Foo *
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_nn22"></a>29.4 Details on the Lua binding</H2>
|
||||
<H2><a name="Lua_nn22"></a>31.4 Details on the Lua binding</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -913,7 +913,7 @@ If you ever need to access the underlying pointer returned by <tt>operator->(
|
|||
</i>
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn23"></a>29.4.1 Binding global data into the module.</H3>
|
||||
<H3><a name="Lua_nn23"></a>31.4.1 Binding global data into the module.</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -972,7 +972,7 @@ end
|
|||
<p>
|
||||
That way when you call '<tt>a=example.Foo</tt>', the interpreter looks at the table 'example' sees that there is no field 'Foo' and calls __index. This will in turn check in '.get' table and find the existence of 'Foo' and then return the value of the C function call 'Foo_get()'. Similarly for the code '<tt>example.Foo=10</tt>', the interpreter will check the table, then call the __newindex which will then check the '.set' table and call the C function 'Foo_set(10)'.
|
||||
</p>
|
||||
<H3><a name="Lua_nn24"></a>29.4.2 Userdata and Metatables</H3>
|
||||
<H3><a name="Lua_nn24"></a>31.4.2 Userdata and Metatables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1052,7 +1052,7 @@ Note: Both the opaque structures (like the FILE*) and normal wrappered classes/s
|
|||
<p>
|
||||
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' & '__call' to the classes metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming its an operator overload.
|
||||
</p>
|
||||
<H3><a name="Lua_nn25"></a>29.4.3 Memory management</H3>
|
||||
<H3><a name="Lua_nn25"></a>31.4.3 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Modula3"></a>20 SWIG and Modula-3</H1>
|
||||
<H1><a name="Modula3"></a>22 SWIG and Modula-3</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -57,7 +57,7 @@ especially
|
|||
<a href="Typemaps.html">typemaps</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="modula3_overview"></a>20.1 Overview</H2>
|
||||
<H2><a name="modula3_overview"></a>22.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -90,7 +90,7 @@ So the introduction got a bit longer than it should ... ;-)
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="whyscripting"></a>20.1.1 Why not scripting ?</H3>
|
||||
<H3><a name="whyscripting"></a>22.1.1 Why not scripting ?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -126,7 +126,7 @@ are not advantages of the language itself
|
|||
but can be provided by function libraries.
|
||||
</p>
|
||||
|
||||
<H3><a name="whymodula3"></a>20.1.2 Why Modula-3 ?</H3>
|
||||
<H3><a name="whymodula3"></a>22.1.2 Why Modula-3 ?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -166,7 +166,7 @@ it's statically typed, too.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="whycpp"></a>20.1.3 Why C / C++ ?</H3>
|
||||
<H3><a name="whycpp"></a>22.1.3 Why C / C++ ?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -179,7 +179,7 @@ Even more fortunately even non-C libraries may provide C header files.
|
|||
This is where SWIG becomes helpful.
|
||||
</p>
|
||||
|
||||
<H3><a name="whyswig"></a>20.1.4 Why SWIG ?</H3>
|
||||
<H3><a name="whyswig"></a>22.1.4 Why SWIG ?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -252,10 +252,10 @@ integrate Modula-3 code into a C / C++ project.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="conception"></a>20.2 Conception</H2>
|
||||
<H2><a name="conception"></a>22.2 Conception</H2>
|
||||
|
||||
|
||||
<H3><a name="cinterface"></a>20.2.1 Interfaces to C libraries</H3>
|
||||
<H3><a name="cinterface"></a>22.2.1 Interfaces to C libraries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -404,7 +404,7 @@ and the principal type must be renamed (<tt>%typemap</tt>).
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="cppinterface"></a>20.2.2 Interfaces to C++ libraries</H3>
|
||||
<H3><a name="cppinterface"></a>22.2.2 Interfaces to C++ libraries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -505,10 +505,10 @@ There is no C++ library I wrote a SWIG interface for,
|
|||
so I'm not sure if this is possible or sensible, yet.
|
||||
</p>
|
||||
|
||||
<H2><a name="preliminaries"></a>20.3 Preliminaries</H2>
|
||||
<H2><a name="preliminaries"></a>22.3 Preliminaries</H2>
|
||||
|
||||
|
||||
<H3><a name="compilers"></a>20.3.1 Compilers</H3>
|
||||
<H3><a name="compilers"></a>22.3.1 Compilers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -522,7 +522,7 @@ For testing examples I use Critical Mass cm3.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="commandline"></a>20.3.2 Additional Commandline Options</H3>
|
||||
<H3><a name="commandline"></a>22.3.2 Additional Commandline Options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -599,10 +599,10 @@ Instead generate templates for some basic typemaps.
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H2><a name="modula3_typemaps"></a>20.4 Modula-3 typemaps</H2>
|
||||
<H2><a name="modula3_typemaps"></a>22.4 Modula-3 typemaps</H2>
|
||||
|
||||
|
||||
<H3><a name="inoutparam"></a>20.4.1 Inputs and outputs</H3>
|
||||
<H3><a name="inoutparam"></a>22.4.1 Inputs and outputs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -818,7 +818,7 @@ consist of the following parts:
|
|||
</table>
|
||||
|
||||
|
||||
<H3><a name="ordinals"></a>20.4.2 Subranges, Enumerations, Sets</H3>
|
||||
<H3><a name="ordinals"></a>22.4.2 Subranges, Enumerations, Sets</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -870,7 +870,7 @@ that I'd like to automate.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="class"></a>20.4.3 Objects</H3>
|
||||
<H3><a name="class"></a>22.4.3 Objects</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -883,7 +883,7 @@ is not really useful, yet.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="imports"></a>20.4.4 Imports</H3>
|
||||
<H3><a name="imports"></a>22.4.4 Imports</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -918,7 +918,7 @@ IMPORT M3toC;
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="exceptions"></a>20.4.5 Exceptions</H3>
|
||||
<H3><a name="exceptions"></a>22.4.5 Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -942,7 +942,7 @@ you should declare
|
|||
<tt>%typemap("m3wrapinconv:throws") blah * %{OSError.E%}</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="typemap_example"></a>20.4.6 Example</H3>
|
||||
<H3><a name="typemap_example"></a>22.4.6 Example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -989,10 +989,10 @@ where almost everything is generated by a typemap:
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H2><a name="hints"></a>20.5 More hints to the generator</H2>
|
||||
<H2><a name="hints"></a>22.5 More hints to the generator</H2>
|
||||
|
||||
|
||||
<H3><a name="features"></a>20.5.1 Features</H3>
|
||||
<H3><a name="features"></a>22.5.1 Features</H3>
|
||||
|
||||
|
||||
<table border summary="Modula-3 features">
|
||||
|
|
@ -1029,7 +1029,7 @@ where almost everything is generated by a typemap:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="pragmas"></a>20.5.2 Pragmas</H3>
|
||||
<H3><a name="pragmas"></a>22.5.2 Pragmas</H3>
|
||||
|
||||
|
||||
<table border summary="Modula-3 pragmas">
|
||||
|
|
@ -1052,7 +1052,7 @@ where almost everything is generated by a typemap:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H2><a name="remarks"></a>20.6 Remarks</H2>
|
||||
<H2><a name="remarks"></a>22.6 Remarks</H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="MzScheme"></a>21 SWIG and MzScheme</H1>
|
||||
<H1><a name="MzScheme"></a>23 SWIG and MzScheme</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -22,7 +22,7 @@
|
|||
<p>
|
||||
This section contains information on SWIG's support of MzScheme.
|
||||
|
||||
<H2><a name="MzScheme_nn2"></a>21.1 Creating native MzScheme structures</H2>
|
||||
<H2><a name="MzScheme_nn2"></a>23.1 Creating native MzScheme structures</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
<body bgcolor="#ffffff">
|
||||
<a name="n1"></a>
|
||||
<H1><a name="Ocaml"></a>22 SWIG and Ocaml</H1>
|
||||
<H1><a name="Ocaml"></a>24 SWIG and Ocaml</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -80,7 +80,7 @@ If you're not familiar with the Objective Caml language, you can visit
|
|||
<a href="http://www.ocaml.org/">The Ocaml Website</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn2"></a>22.1 Preliminaries</H2>
|
||||
<H2><a name="Ocaml_nn2"></a>24.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -99,7 +99,7 @@ file Examples/Makefile illustrate how to compile and link SWIG modules that
|
|||
will be loaded dynamically. This has only been tested on Linux so far.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn3"></a>22.1.1 Running SWIG</H3>
|
||||
<H3><a name="Ocaml_nn3"></a>24.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,7 +122,7 @@ you will compile the file <tt>example_wrap.c</tt> with <tt>ocamlc</tt> or
|
|||
the resulting .ml and .mli files as well, and do the final link with -custom
|
||||
(not needed for native link). </p>
|
||||
|
||||
<H3><a name="Ocaml_nn4"></a>22.1.2 Compiling the code</H3>
|
||||
<H3><a name="Ocaml_nn4"></a>24.1.2 Compiling the code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -158,7 +158,7 @@ the user more freedom with respect to custom typing.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ocaml_nn5"></a>22.1.3 The camlp4 module</H3>
|
||||
<H3><a name="Ocaml_nn5"></a>24.1.3 The camlp4 module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -234,7 +234,7 @@ let b = C_string (getenv "PATH")
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn6"></a>22.1.4 Using your module</H3>
|
||||
<H3><a name="Ocaml_nn6"></a>24.1.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -248,7 +248,7 @@ When linking any ocaml bytecode with your module, use the -custom
|
|||
option is not needed when you build native code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn7"></a>22.1.5 Compilation problems and compiling with C++</H3>
|
||||
<H3><a name="Ocaml_nn7"></a>24.1.5 Compilation problems and compiling with C++</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -259,7 +259,7 @@ liberal with pointer types may not compile under the C++ compiler.
|
|||
Most code meant to be compiled as C++ will not have problems.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn8"></a>22.2 The low-level Ocaml/C interface</H2>
|
||||
<H2><a name="Ocaml_nn8"></a>24.2 The low-level Ocaml/C interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -360,7 +360,7 @@ is that you must append them to the return list with swig_result = caml_list_a
|
|||
signature for a function that uses value in this way.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn9"></a>22.2.1 The generated module</H3>
|
||||
<H3><a name="Ocaml_nn9"></a>24.2.1 The generated module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -394,7 +394,7 @@ it describes the output SWIG will generate for class definitions.
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn10"></a>22.2.2 Enums</H3>
|
||||
<H3><a name="Ocaml_nn10"></a>24.2.2 Enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -457,7 +457,7 @@ val x : Enum_test.c_obj = C_enum `a
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ocaml_nn11"></a>22.2.2.1 Enum typing in Ocaml</H4>
|
||||
<H4><a name="Ocaml_nn11"></a>24.2.2.1 Enum typing in Ocaml</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -470,10 +470,10 @@ functions imported from different modules. You must convert values to master
|
|||
values using the swig_val function before sharing them with another module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn12"></a>22.2.3 Arrays</H3>
|
||||
<H3><a name="Ocaml_nn12"></a>24.2.3 Arrays</H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn13"></a>22.2.3.1 Simple types of bounded arrays</H4>
|
||||
<H4><a name="Ocaml_nn13"></a>24.2.3.1 Simple types of bounded arrays</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -494,7 +494,7 @@ arrays of simple types with known bounds in your code, but this only works
|
|||
for arrays whose bounds are completely specified.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn14"></a>22.2.3.2 Complex and unbounded arrays</H4>
|
||||
<H4><a name="Ocaml_nn14"></a>24.2.3.2 Complex and unbounded arrays</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -507,7 +507,7 @@ SWIG can't predict which of these methods will be used in the array,
|
|||
so you have to specify it for yourself in the form of a typemap.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn15"></a>22.2.3.3 Using an object</H4>
|
||||
<H4><a name="Ocaml_nn15"></a>24.2.3.3 Using an object</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -521,7 +521,7 @@ Consider writing an object when the ending condition of your array is complex,
|
|||
such as using a required centinel, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn16"></a>22.2.3.4 Example typemap for a function taking float * and int</H4>
|
||||
<H4><a name="Ocaml_nn16"></a>24.2.3.4 Example typemap for a function taking float * and int</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -572,7 +572,7 @@ void printfloats( float *tab, int len );
|
|||
</pre></td></tr></table>
|
||||
|
||||
|
||||
<H3><a name="Ocaml_nn17"></a>22.2.4 C++ Classes</H3>
|
||||
<H3><a name="Ocaml_nn17"></a>24.2.4 C++ Classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -615,7 +615,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the
|
|||
returned value for the same object.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn18"></a>22.2.4.1 STL vector and string Example</H4>
|
||||
<H4><a name="Ocaml_nn18"></a>24.2.4.1 STL vector and string Example</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -695,7 +695,7 @@ baz
|
|||
#
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn19"></a>22.2.4.2 C++ Class Example</H4>
|
||||
<H4><a name="Ocaml_nn19"></a>24.2.4.2 C++ Class Example</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -725,7 +725,7 @@ public:
|
|||
};
|
||||
</pre></td></tr></table>
|
||||
|
||||
<H4><a name="Ocaml_nn20"></a>22.2.4.3 Compiling the example</H4>
|
||||
<H4><a name="Ocaml_nn20"></a>24.2.4.3 Compiling the example</H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -743,7 +743,7 @@ bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
|
|||
-L$QTPATH/lib -cclib -lqt
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn21"></a>22.2.4.4 Sample Session</H4>
|
||||
<H4><a name="Ocaml_nn21"></a>24.2.4.4 Sample Session</H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -770,10 +770,10 @@ Assuming you have a working installation of QT, you will see a window
|
|||
containing the string "hi" in a button.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn22"></a>22.2.5 Director Classes</H3>
|
||||
<H3><a name="Ocaml_nn22"></a>24.2.5 Director Classes</H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn23"></a>22.2.5.1 Director Introduction</H4>
|
||||
<H4><a name="Ocaml_nn23"></a>24.2.5.1 Director Introduction</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -800,7 +800,7 @@ class foo {
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn24"></a>22.2.5.2 Overriding Methods in Ocaml</H4>
|
||||
<H4><a name="Ocaml_nn24"></a>24.2.5.2 Overriding Methods in Ocaml</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -828,7 +828,7 @@ In this example, I'll examine the objective caml code involved in providing
|
|||
an overloaded class. This example is contained in Examples/ocaml/shapes.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn25"></a>22.2.5.3 Director Usage Example</H4>
|
||||
<H4><a name="Ocaml_nn25"></a>24.2.5.3 Director Usage Example</H4>
|
||||
|
||||
|
||||
<table border="1" bgcolor="#dddddd" summary="Director usage example">
|
||||
|
|
@ -887,7 +887,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the
|
|||
program in C++.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn26"></a>22.2.5.4 Creating director objects</H4>
|
||||
<H4><a name="Ocaml_nn26"></a>24.2.5.4 Creating director objects</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -928,7 +928,7 @@ object from causing a core dump, as long as the object is destroyed
|
|||
properly.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn27"></a>22.2.5.5 Typemaps for directors, <tt>directorin, directorout, directorargout</tt></H4>
|
||||
<H4><a name="Ocaml_nn27"></a>24.2.5.5 Typemaps for directors, <tt>directorin, directorout, directorargout</tt></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -939,7 +939,7 @@ well as a function return value in the same way you provide function arguments,
|
|||
and to receive arguments the same way you normally receive function returns.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn28"></a>22.2.5.6 <tt>directorin</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn28"></a>24.2.5.6 <tt>directorin</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -950,7 +950,7 @@ code receives when you are called. In general, a simple <tt>directorin</tt> typ
|
|||
can use the same body as a simple <tt>out</tt> typemap.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn29"></a>22.2.5.7 <tt>directorout</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn29"></a>24.2.5.7 <tt>directorout</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -961,7 +961,7 @@ for the same type, except when there are special requirements for object
|
|||
ownership, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn30"></a>22.2.5.8 <tt>directorargout</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn30"></a>24.2.5.8 <tt>directorargout</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -978,7 +978,7 @@ In the event that you don't specify all of the necessary values, integral
|
|||
values will read zero, and struct or object returns have undefined results.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn31"></a>22.2.6 Exceptions</H3>
|
||||
<H3><a name="Ocaml_nn31"></a>24.2.6 Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Perl5"></a>23 SWIG and Perl5</H1>
|
||||
<H1><a name="Perl5"></a>25 SWIG and Perl5</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -86,7 +86,7 @@ later. Earlier versions are problematic and SWIG generated extensions
|
|||
may not compile or run correctly.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn2"></a>23.1 Overview</H2>
|
||||
<H2><a name="Perl5_nn2"></a>25.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -107,7 +107,7 @@ described. Advanced customization features, typemaps, and other
|
|||
options are found near the end of the chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn3"></a>23.2 Preliminaries</H2>
|
||||
<H2><a name="Perl5_nn3"></a>25.2 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -132,7 +132,7 @@ To build the module, you will need to compile the file
|
|||
<tt>example_wrap.c</tt> and link it with the rest of your program.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn4"></a>23.2.1 Getting the right header files</H3>
|
||||
<H3><a name="Perl5_nn4"></a>25.2.1 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -164,7 +164,7 @@ loaded, an easy way to find out is to run Perl itself.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn5"></a>23.2.2 Compiling a dynamic module</H3>
|
||||
<H3><a name="Perl5_nn5"></a>25.2.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -197,7 +197,7 @@ the target should be named `<tt>example.so</tt>',
|
|||
`<tt>example.sl</tt>', or the appropriate dynamic module name on your system.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn6"></a>23.2.3 Building a dynamic module with MakeMaker</H3>
|
||||
<H3><a name="Perl5_nn6"></a>25.2.3 Building a dynamic module with MakeMaker</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -231,7 +231,7 @@ the preferred approach to compilation. More information about MakeMaker can be
|
|||
found in "Programming Perl, 2nd ed." by Larry Wall, Tom Christiansen,
|
||||
and Randal Schwartz.</p>
|
||||
|
||||
<H3><a name="Perl5_nn7"></a>23.2.4 Building a static version of Perl</H3>
|
||||
<H3><a name="Perl5_nn7"></a>25.2.4 Building a static version of Perl</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -300,7 +300,7 @@ added to it. Depending on your machine, you may need to link with
|
|||
additional libraries such as <tt>-lsocket, -lnsl, -ldl</tt>, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn8"></a>23.2.5 Using the module</H3>
|
||||
<H3><a name="Perl5_nn8"></a>25.2.5 Using the module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -455,7 +455,7 @@ system configuration (this requires root access and you will need to
|
|||
read the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn9"></a>23.2.6 Compilation problems and compiling with C++</H3>
|
||||
<H3><a name="Perl5_nn9"></a>25.2.6 Compilation problems and compiling with C++</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -598,7 +598,7 @@ have to find the macro that conflicts and add an #undef into the .i file. Pleas
|
|||
any conflicting macros you find to <a href="http://www.swig.org/mail.html">swig mailing list</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn10"></a>23.2.7 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Perl5_nn10"></a>25.2.7 Compiling for 64-bit platforms</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -625,7 +625,7 @@ also introduce problems on platforms that support more than one
|
|||
linking standard (e.g., -o32 and -n32 on Irix).
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn11"></a>23.3 Building Perl Extensions under Windows</H2>
|
||||
<H2><a name="Perl5_nn11"></a>25.3 Building Perl Extensions under Windows</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -636,7 +636,7 @@ section assumes you are using SWIG with Microsoft Visual C++
|
|||
although the procedure may be similar with other compilers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn12"></a>23.3.1 Running SWIG from Developer Studio</H3>
|
||||
<H3><a name="Perl5_nn12"></a>25.3.1 Running SWIG from Developer Studio</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -699,7 +699,7 @@ print "$a\n";
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn13"></a>23.3.2 Using other compilers</H3>
|
||||
<H3><a name="Perl5_nn13"></a>25.3.2 Using other compilers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -707,7 +707,7 @@ SWIG is known to work with Cygwin and may work with other compilers on Windows.
|
|||
For general hints and suggestions refer to the <a href="Windows.html#Windows">Windows</a> chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn14"></a>23.4 The low-level interface</H2>
|
||||
<H2><a name="Perl5_nn14"></a>25.4 The low-level interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -717,7 +717,7 @@ can be used to control your application. However, it is also used to
|
|||
construct more user-friendly proxy classes as described in the next section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn15"></a>23.4.1 Functions</H3>
|
||||
<H3><a name="Perl5_nn15"></a>25.4.1 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -740,7 +740,7 @@ use example;
|
|||
$a = &example::fact(2);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn16"></a>23.4.2 Global variables</H3>
|
||||
<H3><a name="Perl5_nn16"></a>25.4.2 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -810,7 +810,7 @@ extern char *path; // Declared later in the input
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn17"></a>23.4.3 Constants</H3>
|
||||
<H3><a name="Perl5_nn17"></a>25.4.3 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -837,7 +837,7 @@ $example::FOO = 2; # Error
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn18"></a>23.4.4 Pointers</H3>
|
||||
<H3><a name="Perl5_nn18"></a>25.4.4 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -946,7 +946,7 @@ as XS and <tt>xsubpp</tt>. Given the advancement of the SWIG typesystem and the
|
|||
SWIG and XS, this is no longer supported.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn19"></a>23.4.5 Structures</H3>
|
||||
<H3><a name="Perl5_nn19"></a>25.4.5 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1080,7 +1080,7 @@ void Bar_f_set(Bar *b, Foo *val) {
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn20"></a>23.4.6 C++ classes</H3>
|
||||
<H3><a name="Perl5_nn20"></a>25.4.6 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1145,7 +1145,7 @@ provides direct access to C++ objects. A higher level interface using Perl prox
|
|||
can be built using these low-level accessors. This is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn21"></a>23.4.7 C++ classes and type-checking</H3>
|
||||
<H3><a name="Perl5_nn21"></a>25.4.7 C++ classes and type-checking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1181,7 +1181,7 @@ If necesssary, the type-checker also adjusts the value of the pointer (as is nec
|
|||
multiple inheritance is used).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn22"></a>23.4.8 C++ overloaded functions</H3>
|
||||
<H3><a name="Perl5_nn22"></a>25.4.8 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1225,7 +1225,7 @@ example::Spam_foo_d($s,3.14);
|
|||
Please refer to the "SWIG Basics" chapter for more information.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn23"></a>23.4.9 Operators</H3>
|
||||
<H3><a name="Perl5_nn23"></a>25.4.9 Operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1258,7 +1258,7 @@ $c = example::add_complex($a,$b);
|
|||
Some preliminary work on mapping C++ operators into Perl operators has been completed. This is covered later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn24"></a>23.4.10 Modules and packages</H3>
|
||||
<H3><a name="Perl5_nn24"></a>25.4.10 Modules and packages</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1325,7 +1325,7 @@ print Foo::fact(4),"\n"; # Call a function in package FooBar
|
|||
</pre></div>
|
||||
-->
|
||||
|
||||
<H2><a name="Perl5_nn25"></a>23.5 Input and output parameters</H2>
|
||||
<H2><a name="Perl5_nn25"></a>25.5 Input and output parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1544,7 +1544,7 @@ print "$c\n";
|
|||
<b>Note:</b> The <tt>REFERENCE</tt> feature is only currently supported for numeric types (integers and floating point).
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn26"></a>23.6 Exception handling </H2>
|
||||
<H2><a name="Perl5_nn26"></a>25.6 Exception handling </H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1709,7 +1709,7 @@ This is still supported, but it is deprecated. The newer <tt>%exception</tt> di
|
|||
functionality, but it has additional capabilities that make it more powerful.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn27"></a>23.7 Remapping datatypes with typemaps</H2>
|
||||
<H2><a name="Perl5_nn27"></a>25.7 Remapping datatypes with typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1726,7 +1726,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Perl interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn28"></a>23.7.1 A simple typemap example</H3>
|
||||
<H3><a name="Perl5_nn28"></a>25.7.1 A simple typemap example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1830,7 +1830,7 @@ example::count("e","Hello World");
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn29"></a>23.7.2 Perl5 typemaps</H3>
|
||||
<H3><a name="Perl5_nn29"></a>25.7.2 Perl5 typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1935,7 +1935,7 @@ Return of C++ member data (all languages).
|
|||
Check value of input parameter.
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn30"></a>23.7.3 Typemap variables</H3>
|
||||
<H3><a name="Perl5_nn30"></a>25.7.3 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2006,7 +2006,7 @@ properly assigned.
|
|||
The Perl name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn31"></a>23.7.4 Useful functions</H3>
|
||||
<H3><a name="Perl5_nn31"></a>25.7.4 Useful functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2075,7 +2075,7 @@ int sv_isa(SV *, char *0;
|
|||
</div>
|
||||
|
||||
|
||||
<H2><a name="Perl5_nn32"></a>23.8 Typemap Examples</H2>
|
||||
<H2><a name="Perl5_nn32"></a>25.8 Typemap Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2084,7 +2084,7 @@ might look at the files "<tt>perl5.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn33"></a>23.8.1 Converting a Perl5 array to a char ** </H3>
|
||||
<H3><a name="Perl5_nn33"></a>25.8.1 Converting a Perl5 array to a char ** </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2176,7 +2176,7 @@ print @$b,"\n"; # Print it out
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn34"></a>23.8.2 Return values </H3>
|
||||
<H3><a name="Perl5_nn34"></a>25.8.2 Return values </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2205,7 +2205,7 @@ can be done using the <tt>EXTEND()</tt> macro as in :
|
|||
}
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn35"></a>23.8.3 Returning values from arguments</H3>
|
||||
<H3><a name="Perl5_nn35"></a>25.8.3 Returning values from arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2259,7 +2259,7 @@ print "multout(7,13) = @r\n";
|
|||
($x,$y) = multout(7,13);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn36"></a>23.8.4 Accessing array structure members</H3>
|
||||
<H3><a name="Perl5_nn36"></a>25.8.4 Accessing array structure members</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2322,7 +2322,7 @@ the "in" typemap in the previous section would be used to convert an
|
|||
to copy the converted array into a C data structure.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn37"></a>23.8.5 Turning Perl references into C pointers</H3>
|
||||
<H3><a name="Perl5_nn37"></a>25.8.5 Turning Perl references into C pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2387,7 +2387,7 @@ print "$c\n";
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn38"></a>23.8.6 Pointer handling</H3>
|
||||
<H3><a name="Perl5_nn38"></a>25.8.6 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2466,7 +2466,7 @@ For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Perl5_nn39"></a>23.9 Proxy classes</H2>
|
||||
<H2><a name="Perl5_nn39"></a>25.9 Proxy classes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2482,7 +2482,7 @@ to the underlying code. This section describes the implementation
|
|||
details of the proxy interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn40"></a>23.9.1 Preliminaries</H3>
|
||||
<H3><a name="Perl5_nn40"></a>25.9.1 Preliminaries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2504,7 +2504,7 @@ SWIG creates a collection of high-level Perl wrappers. In your scripts, you wil
|
|||
high level wrappers. The wrappers, in turn, interact with the low-level procedural module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn41"></a>23.9.2 Structure and class wrappers</H3>
|
||||
<H3><a name="Perl5_nn41"></a>25.9.2 Structure and class wrappers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2630,7 +2630,7 @@ $v->DESTROY();
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn42"></a>23.9.3 Object Ownership</H3>
|
||||
<H3><a name="Perl5_nn42"></a>25.9.3 Object Ownership</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2717,7 +2717,7 @@ counting, garbage collection, or advanced features one might find in
|
|||
sophisticated languages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn43"></a>23.9.4 Nested Objects</H3>
|
||||
<H3><a name="Perl5_nn43"></a>25.9.4 Nested Objects</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2770,7 +2770,7 @@ $p->{f}->{x} = 0.0;
|
|||
%${$p->{v}} = ( x=>0, y=>0, z=>0);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn44"></a>23.9.5 Proxy Functions</H3>
|
||||
<H3><a name="Perl5_nn44"></a>25.9.5 Proxy Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2804,7 +2804,7 @@ This function replaces the original function, but operates in an
|
|||
identical manner.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn45"></a>23.9.6 Inheritance</H3>
|
||||
<H3><a name="Perl5_nn45"></a>25.9.6 Inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2880,7 +2880,7 @@ particular, inheritance of data members is extremely tricky (and I'm
|
|||
not even sure if it really works).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn46"></a>23.9.7 Modifying the proxy methods</H3>
|
||||
<H3><a name="Perl5_nn46"></a>25.9.7 Modifying the proxy methods</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Php"></a>24 SWIG and PHP4</H1>
|
||||
<H1><a name="Php"></a>26 SWIG and PHP4</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -66,7 +66,7 @@ extension into php directly (without having the overhead of loading it into
|
|||
each script), you will need the complete PHP source tree available.
|
||||
</p>
|
||||
|
||||
<H2><a name="Php_nn1"></a>24.1 Generating PHP4 Extensions</H2>
|
||||
<H2><a name="Php_nn1"></a>26.1 Generating PHP4 Extensions</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -104,7 +104,7 @@ script. The first choice is the default, however it can be changed by passing
|
|||
the '-phpfull' command line switch to select the second build method.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn1_1"></a>24.1.1 Building a loadable extension</H3>
|
||||
<H3><a name="Php_nn1_1"></a>26.1.1 Building a loadable extension</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -194,7 +194,7 @@ additional optional arguments:
|
|||
<li><tt>-dlname "<name>"</tt> Changes the name of the generated shared object.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Php_nn1_2"></a>24.1.2 Building extensions into PHP</H3>
|
||||
<H3><a name="Php_nn1_2"></a>26.1.2 Building extensions into PHP</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -252,7 +252,7 @@ which contains your new module. You can test it with a php script which
|
|||
does not have the 'dl' command as used above.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn1_3"></a>24.1.3 Using PHP4 Extensions</H3>
|
||||
<H3><a name="Php_nn1_3"></a>26.1.3 Using PHP4 Extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -275,7 +275,7 @@ attempts to do the <tt>dl()</tt> call for you:
|
|||
|
||||
|
||||
|
||||
<H2><a name="Php_nn2"></a>24.2 Basic PHP4 interface</H2>
|
||||
<H2><a name="Php_nn2"></a>26.2 Basic PHP4 interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -285,7 +285,7 @@ possible for names of symbols in one extension module to clash with
|
|||
other symbols unless care is taken to <tt>%rename</tt> them.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_1"></a>24.2.1 Constants</H3>
|
||||
<H3><a name="Php_nn2_1"></a>26.2.1 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -410,7 +410,7 @@ both point to the same value, without the case test taking place. (
|
|||
Apologies, this paragraph needs rewriting to make some sense. )
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_2"></a>24.2.2 Global Variables</H3>
|
||||
<H3><a name="Php_nn2_2"></a>26.2.2 Global Variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -459,7 +459,7 @@ undefined.
|
|||
At this time SWIG does not support custom accessor methods.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_3"></a>24.2.3 Functions</H3>
|
||||
<H3><a name="Php_nn2_3"></a>26.2.3 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -510,7 +510,7 @@ print $s; # The value of $s was not changed.
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Php_nn2_4"></a>24.2.4 Overloading</H3>
|
||||
<H3><a name="Php_nn2_4"></a>26.2.4 Overloading</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -564,7 +564,7 @@ Cause less confusion and <tt>doit("2");</tt> will invoke the function
|
|||
taking the integer argument.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_5"></a>24.2.5 Pointers and References</H3>
|
||||
<H3><a name="Php_nn2_5"></a>26.2.5 Pointers and References</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -696,7 +696,7 @@ PHP in a number of ways: by using <tt>unset</tt> on an existing
|
|||
variable, or assigning <tt>NULL</tt> to a variable.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_6"></a>24.2.6 Structures and C++ classes</H3>
|
||||
<H3><a name="Php_nn2_6"></a>26.2.6 Structures and C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -755,7 +755,7 @@ Would be used in the following way:
|
|||
Member variables and methods are accessed using the <tt>-></tt> operator.
|
||||
</p>
|
||||
|
||||
<H4><a name="Php_nn2_6_1"></a>24.2.6.1 Using <tt>-noproxy</tt></H4>
|
||||
<H4><a name="Php_nn2_6_1"></a>26.2.6.1 Using <tt>-noproxy</tt></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -780,7 +780,7 @@ Complex_im_set($obj,$d);
|
|||
Complex_im_get($obj);
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Php_nn2_6_2"></a>24.2.6.2 Constructors and Destructors</H4>
|
||||
<H4><a name="Php_nn2_6_2"></a>26.2.6.2 Constructors and Destructors</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -821,7 +821,7 @@ the programmer can either reassign the variable or call
|
|||
<tt>unset($v)</tt>
|
||||
</p>
|
||||
|
||||
<H4><a name="Php_nn2_6_3"></a>24.2.6.3 Static Member Variables</H4>
|
||||
<H4><a name="Php_nn2_6_3"></a>26.2.6.3 Static Member Variables</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -861,7 +861,7 @@ Ko::threats(10);
|
|||
echo "There has now been " . Ko::threats() . " threats\n";
|
||||
|
||||
</pre></div>
|
||||
<H4><a name="Php_nn2_6_4"></a>24.2.6.4 Static Member Functions</H4>
|
||||
<H4><a name="Php_nn2_6_4"></a>26.2.6.4 Static Member Functions</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -883,7 +883,7 @@ Ko::threats();
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Php_nn2_7"></a>24.2.7 PHP4 Pragmas, Startup and Shutdown code</H3>
|
||||
<H3><a name="Php_nn2_7"></a>26.2.7 PHP4 Pragmas, Startup and Shutdown code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Pike"></a>25 SWIG and Pike</H1>
|
||||
<H1><a name="Pike"></a>27 SWIG and Pike</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -46,10 +46,10 @@ least, make sure you read the "<a href="SWIG.html#SWIG">SWIG Basics</a>"
|
|||
chapter.<br>
|
||||
</p>
|
||||
|
||||
<H2><a name="Pike_nn2"></a>25.1 Preliminaries</H2>
|
||||
<H2><a name="Pike_nn2"></a>27.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<H3><a name="Pike_nn3"></a>25.1.1 Running SWIG</H3>
|
||||
<H3><a name="Pike_nn3"></a>27.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -94,7 +94,7 @@ can use the <tt>-o</tt> option:
|
|||
<div class="code">
|
||||
<pre>$ <b>swig -pike -o pseudonym.c example.i</b><br></pre>
|
||||
</div>
|
||||
<H3><a name="Pike_nn4"></a>25.1.2 Getting the right header files</H3>
|
||||
<H3><a name="Pike_nn4"></a>27.1.2 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -114,7 +114,7 @@ You're looking for files with the names <tt>global.h</tt>, <tt>program.h</tt>
|
|||
and so on.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn5"></a>25.1.3 Using your module</H3>
|
||||
<H3><a name="Pike_nn5"></a>27.1.3 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -129,10 +129,10 @@ Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
|
|||
(1) Result: 24
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Pike_nn6"></a>25.2 Basic C/C++ Mapping</H2>
|
||||
<H2><a name="Pike_nn6"></a>27.2 Basic C/C++ Mapping</H2>
|
||||
|
||||
|
||||
<H3><a name="Pike_nn7"></a>25.2.1 Modules</H3>
|
||||
<H3><a name="Pike_nn7"></a>27.2.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -143,7 +143,7 @@ concerned), SWIG's <tt>%module</tt> directive doesn't really have any
|
|||
significance.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn8"></a>25.2.2 Functions</H3>
|
||||
<H3><a name="Pike_nn8"></a>27.2.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -168,7 +168,7 @@ exactly as you'd expect it to:
|
|||
(1) Result: 24
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Pike_nn9"></a>25.2.3 Global variables</H3>
|
||||
<H3><a name="Pike_nn9"></a>27.2.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -197,7 +197,7 @@ will result in two functions, <tt>Foo_get()</tt> and <tt>Foo_set()</tt>:
|
|||
(3) Result: 3.141590
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Pike_nn10"></a>25.2.4 Constants and enumerated types</H3>
|
||||
<H3><a name="Pike_nn10"></a>27.2.4 Constants and enumerated types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -205,7 +205,7 @@ Enumerated types in C/C++ declarations are wrapped as Pike constants,
|
|||
not as Pike enums.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn11"></a>25.2.5 Constructors and Destructors</H3>
|
||||
<H3><a name="Pike_nn11"></a>27.2.5 Constructors and Destructors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -213,7 +213,7 @@ Constructors are wrapped as <tt>create()</tt> methods, and destructors are
|
|||
wrapped as <tt>destroy()</tt> methods, for Pike classes.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn12"></a>25.2.6 Static Members</H3>
|
||||
<H3><a name="Pike_nn12"></a>27.2.6 Static Members</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Python"></a>26 SWIG and Python</H1>
|
||||
<H1><a name="Python"></a>28 SWIG and Python</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -126,7 +126,7 @@ very least, make sure you read the "<a href="SWIG.html#SWIG">SWIG
|
|||
Basics</a>" chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn2"></a>26.1 Overview</H2>
|
||||
<H2><a name="Python_nn2"></a>28.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -153,10 +153,10 @@ described followed by a discussion of low-level implementation
|
|||
details.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn3"></a>26.2 Preliminaries</H2>
|
||||
<H2><a name="Python_nn3"></a>28.2 Preliminaries</H2>
|
||||
|
||||
|
||||
<H3><a name="Python_nn4"></a>26.2.1 Running SWIG</H3>
|
||||
<H3><a name="Python_nn4"></a>28.2.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -205,7 +205,7 @@ from the module name specified with <tt>%module</tt>. If the module name is <tt
|
|||
a file <tt>example.py</tt> is created.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn5"></a>26.2.2 Getting the right header files</H3>
|
||||
<H3><a name="Python_nn5"></a>28.2.2 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -236,7 +236,7 @@ Type "copyright", "credits" or "license" for more information.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn6"></a>26.2.3 Compiling a dynamic module</H3>
|
||||
<H3><a name="Python_nn6"></a>28.2.3 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -282,10 +282,10 @@ module actually consists of two files; <tt>socket.py</tt> and
|
|||
<tt>_socket.so</tt>. Many other built-in Python modules follow a similar convention.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn7"></a>26.2.4 Using distutils</H3>
|
||||
<H3><a name="Python_nn7"></a>28.2.4 Using distutils</H3>
|
||||
|
||||
|
||||
<H3><a name="Python_nn8"></a>26.2.5 Static linking</H3>
|
||||
<H3><a name="Python_nn8"></a>28.2.5 Static linking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -364,7 +364,7 @@ If using static linking, you might want to rely on a different approach
|
|||
(perhaps using distutils).
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn9"></a>26.2.6 Using your module</H3>
|
||||
<H3><a name="Python_nn9"></a>28.2.6 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -521,7 +521,7 @@ system configuration (this requires root access and you will need to
|
|||
read the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn10"></a>26.2.7 Compilation of C++ extensions</H3>
|
||||
<H3><a name="Python_nn10"></a>28.2.7 Compilation of C++ extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -618,7 +618,7 @@ erratic program behavior. If working with lots of software components, you
|
|||
might want to investigate using a more formal standard such as COM.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn11"></a>26.2.8 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Python_nn11"></a>28.2.8 Compiling for 64-bit platforms</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -655,7 +655,7 @@ and -m64 allow you to choose the desired binary format for your python
|
|||
extension.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn12"></a>26.2.9 Building Python Extensions under Windows</H3>
|
||||
<H3><a name="Python_nn12"></a>28.2.9 Building Python Extensions under Windows</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -744,7 +744,7 @@ you may want to consult the <a href="http://swig.cs.uchicago.edu/cgi-bin/wiki.pl
|
|||
SWIG Wiki</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn13"></a>26.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Python_nn13"></a>28.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -753,7 +753,7 @@ to your C/C++ code. Functions are wrapped as functions, classes are wrapped as
|
|||
This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn14"></a>26.3.1 Modules</H3>
|
||||
<H3><a name="Python_nn14"></a>28.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -766,7 +766,7 @@ module name, make sure you don't use the same name as a built-in
|
|||
Python command or standard module name.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn15"></a>26.3.2 Functions</H3>
|
||||
<H3><a name="Python_nn15"></a>28.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -790,7 +790,7 @@ like you think it does:
|
|||
>>>
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Python_nn16"></a>26.3.3 Global variables</H3>
|
||||
<H3><a name="Python_nn16"></a>28.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -928,7 +928,7 @@ that starts with a leading underscore. SWIG does not create <tt>cvar</tt>
|
|||
if there are no global variables in a module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn17"></a>26.3.4 Constants and enums</H3>
|
||||
<H3><a name="Python_nn17"></a>28.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -968,7 +968,7 @@ other object. Unfortunately, there is no easy way for SWIG to
|
|||
generate code that prevents this. You will just have to be careful.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn18"></a>26.3.5 Pointers</H3>
|
||||
<H3><a name="Python_nn18"></a>28.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1109,7 +1109,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
|
|||
<tt>None</tt> if the conversion can't be performed.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn19"></a>26.3.6 Structures</H3>
|
||||
<H3><a name="Python_nn19"></a>28.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1298,7 +1298,7 @@ everything works just like you would expect. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn20"></a>26.3.7 C++ classes</H3>
|
||||
<H3><a name="Python_nn20"></a>28.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1387,7 +1387,7 @@ they are accessed through <tt>cvar</tt> like this:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn21"></a>26.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Python_nn21"></a>28.3.8 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1442,7 +1442,7 @@ then the function <tt>spam()</tt> accepts <tt>Foo *</tt> or a pointer to any cla
|
|||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn22"></a>26.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Python_nn22"></a>28.3.9 Pointers, references, values, and arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1503,7 +1503,7 @@ treated as a returning value, and it will follow the same
|
|||
allocation/deallocation process.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn23"></a>26.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Python_nn23"></a>28.3.10 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1626,7 +1626,7 @@ first declaration takes precedence.
|
|||
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn24"></a>26.3.11 C++ operators</H3>
|
||||
<H3><a name="Python_nn24"></a>28.3.11 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1715,7 +1715,7 @@ Also, be aware that certain operators don't map cleanly to Python. For instance
|
|||
overloaded assignment operators don't map to Python semantics and will be ignored.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn25"></a>26.3.12 C++ namespaces</H3>
|
||||
<H3><a name="Python_nn25"></a>28.3.12 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1782,7 +1782,7 @@ utilizes thousands of small deeply nested namespaces each with
|
|||
identical symbol names, well, then you get what you deserve.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn26"></a>26.3.13 C++ templates</H3>
|
||||
<H3><a name="Python_nn26"></a>28.3.13 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1835,7 +1835,7 @@ More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</
|
|||
examples will appear later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn27"></a>26.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Python_nn27"></a>28.3.14 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1920,7 +1920,7 @@ simply use the <tt>__deref__()</tt> method. For example:
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn27a"></a>26.3.15 C++ Reference Counted Objects (ref/unref)</H3>
|
||||
<H3><a name="Python_nn27a"></a>28.3.15 C++ Reference Counted Objects (ref/unref)</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2062,7 +2062,7 @@ python releases the shadow instance.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn28"></a>26.4 Further details on the Python class interface</H2>
|
||||
<H2><a name="Python_nn28"></a>28.4 Further details on the Python class interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2075,7 +2075,7 @@ of low-level details were omitted. This section provides a brief overview
|
|||
of how the proxy classes work.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn29"></a>26.4.1 Proxy classes</H3>
|
||||
<H3><a name="Python_nn29"></a>28.4.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2164,7 +2164,7 @@ you can attach new Python methods to the class and you can even inherit from it
|
|||
by Python built-in types until Python 2.2).
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn30"></a>26.4.2 Memory management</H3>
|
||||
<H3><a name="Python_nn30"></a>28.4.2 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2351,7 +2351,7 @@ It is also possible to deal with situations like this using
|
|||
typemaps--an advanced topic discussed later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn31"></a>26.4.3 Python 2.2 and classic classes</H3>
|
||||
<H3><a name="Python_nn31"></a>28.4.3 Python 2.2 and classic classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2388,7 +2388,7 @@ class itself. In Python-2.1 and earlier, they have to be accessed as a global
|
|||
function or through an instance (see the earlier section).
|
||||
</p>
|
||||
|
||||
<H2><a name="directors"></a>26.5 Cross language polymorphism</H2>
|
||||
<H2><a name="directors"></a>28.5 Cross language polymorphism</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2422,7 +2422,7 @@ proxy classes, director classes, and C wrapper functions takes care of
|
|||
all the cross-language method routing transparently.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn33"></a>26.5.1 Enabling directors</H3>
|
||||
<H3><a name="Python_nn33"></a>28.5.1 Enabling directors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2515,7 +2515,7 @@ class MyFoo(mymodule.Foo):
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn34"></a>26.5.2 Director classes</H3>
|
||||
<H3><a name="Python_nn34"></a>28.5.2 Director classes</H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -2597,7 +2597,7 @@ so there is no need for the extra overhead involved with routing the
|
|||
calls through Python.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn35"></a>26.5.3 Ownership and object destruction</H3>
|
||||
<H3><a name="Python_nn35"></a>28.5.3 Ownership and object destruction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2664,7 +2664,7 @@ deleting all the Foo pointers it contains at some point. Note that no hard
|
|||
references to the Foo objects remain in Python.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn36"></a>26.5.4 Exception unrolling</H3>
|
||||
<H3><a name="Python_nn36"></a>28.5.4 Exception unrolling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2723,7 +2723,7 @@ Swig::DirectorMethodException is thrown, Python will register the
|
|||
exception as soon as the C wrapper function returns.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn37"></a>26.5.5 Overhead and code bloat</H3>
|
||||
<H3><a name="Python_nn37"></a>28.5.5 Overhead and code bloat</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2757,7 +2757,7 @@ directive) for only those methods that are likely to be extended in
|
|||
Python.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn38"></a>26.5.6 Typemaps</H3>
|
||||
<H3><a name="Python_nn38"></a>28.5.6 Typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2771,7 +2771,7 @@ need to be supported.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn39"></a>26.5.7 Miscellaneous</H3>
|
||||
<H3><a name="Python_nn39"></a>28.5.7 Miscellaneous</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2818,7 +2818,7 @@ methods that return const references.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn40"></a>26.6 Common customization features</H2>
|
||||
<H2><a name="Python_nn40"></a>28.6 Common customization features</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2831,7 +2831,7 @@ This section describes some common SWIG features that are used to
|
|||
improve your the interface to an extension module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn41"></a>26.6.1 C/C++ helper functions</H3>
|
||||
<H3><a name="Python_nn41"></a>28.6.1 C/C++ helper functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2912,7 +2912,7 @@ hard to implement. It is possible to clean this up using Python code, typemaps,
|
|||
customization features as covered in later sections.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn42"></a>26.6.2 Adding additional Python code</H3>
|
||||
<H3><a name="Python_nn42"></a>28.6.2 Adding additional Python code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2966,7 +2966,7 @@ what can be done without having to rely on any of the more advanced
|
|||
customization features.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn43"></a>26.6.3 Class extension with %extend</H3>
|
||||
<H3><a name="Python_nn43"></a>28.6.3 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3055,7 +3055,7 @@ Vector(12,14,16)
|
|||
in any way---the extensions only show up in the Python interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn44"></a>26.6.4 Exception handling with %exception</H3>
|
||||
<H3><a name="Python_nn44"></a>28.6.4 Exception handling with %exception</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3181,7 +3181,7 @@ The language-independent <tt>exception.i</tt> library file can also be used
|
|||
to raise exceptions. See the <a href="Library.html#Library">SWIG Library</a> chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn45"></a>26.7 Tips and techniques</H2>
|
||||
<H2><a name="Python_nn45"></a>28.7 Tips and techniques</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3191,7 +3191,7 @@ strings, binary data, and arrays. This chapter discusses the common techniques
|
|||
solving these problems.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn46"></a>26.7.1 Input and output parameters</H3>
|
||||
<H3><a name="Python_nn46"></a>28.7.1 Input and output parameters</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3404,7 +3404,7 @@ void foo(Bar *OUTPUT);
|
|||
may not have the intended effect since <tt>typemaps.i</tt> does not define an OUTPUT rule for <tt>Bar</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn47"></a>26.7.2 Simple pointers</H3>
|
||||
<H3><a name="Python_nn47"></a>28.7.2 Simple pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3473,7 +3473,7 @@ If you replace <tt>%pointer_functions()</tt> by <tt>%pointer_class(type,name)</t
|
|||
See the <a href="Library.html#Library">SWIG Library</a> chapter for further details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn48"></a>26.7.3 Unbounded C Arrays</H3>
|
||||
<H3><a name="Python_nn48"></a>28.7.3 Unbounded C Arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3535,7 +3535,7 @@ well suited for applications in which you need to create buffers,
|
|||
package binary data, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn49"></a>26.7.4 String handling</H3>
|
||||
<H3><a name="Python_nn49"></a>28.7.4 String handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3604,16 +3604,16 @@ If you need to return binary data, you might use the
|
|||
also be used to extra binary data from arbitrary pointers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn50"></a>26.7.5 Arrays</H3>
|
||||
<H3><a name="Python_nn50"></a>28.7.5 Arrays</H3>
|
||||
|
||||
|
||||
<H3><a name="Python_nn51"></a>26.7.6 String arrays</H3>
|
||||
<H3><a name="Python_nn51"></a>28.7.6 String arrays</H3>
|
||||
|
||||
|
||||
<H3><a name="Python_nn52"></a>26.7.7 STL wrappers</H3>
|
||||
<H3><a name="Python_nn52"></a>28.7.7 STL wrappers</H3>
|
||||
|
||||
|
||||
<H2><a name="Python_nn53"></a>26.8 Typemaps</H2>
|
||||
<H2><a name="Python_nn53"></a>28.8 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3630,7 +3630,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Python interface or if you want to elevate your guru status.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn54"></a>26.8.1 What is a typemap?</H3>
|
||||
<H3><a name="Python_nn54"></a>28.8.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3746,7 +3746,7 @@ parameter is omitted):
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn55"></a>26.8.2 Python typemaps</H3>
|
||||
<H3><a name="Python_nn55"></a>28.8.2 Python typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3787,7 +3787,7 @@ a look at the SWIG library version 1.3.20 or so.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn56"></a>26.8.3 Typemap variables</H3>
|
||||
<H3><a name="Python_nn56"></a>28.8.3 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3858,7 +3858,7 @@ properly assigned.
|
|||
The Python name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn57"></a>26.8.4 Useful Python Functions</H3>
|
||||
<H3><a name="Python_nn57"></a>28.8.4 Useful Python Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3972,7 +3972,7 @@ write me
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Python_nn58"></a>26.9 Typemap Examples</H2>
|
||||
<H2><a name="Python_nn58"></a>28.9 Typemap Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3981,7 +3981,7 @@ might look at the files "<tt>python.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn59"></a>26.9.1 Converting Python list to a char ** </H3>
|
||||
<H3><a name="Python_nn59"></a>28.9.1 Converting Python list to a char ** </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4061,7 +4061,7 @@ memory allocation is used to allocate memory for the array, the
|
|||
the C function.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn60"></a>26.9.2 Expanding a Python object into multiple arguments</H3>
|
||||
<H3><a name="Python_nn60"></a>28.9.2 Expanding a Python object into multiple arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4140,7 +4140,7 @@ to supply the argument count. This is automatically set by the typemap code. F
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn61"></a>26.9.3 Using typemaps to return arguments</H3>
|
||||
<H3><a name="Python_nn61"></a>28.9.3 Using typemaps to return arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4229,7 +4229,7 @@ function can now be used as follows:
|
|||
>>>
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Python_nn62"></a>26.9.4 Mapping Python tuples into small arrays</H3>
|
||||
<H3><a name="Python_nn62"></a>28.9.4 Mapping Python tuples into small arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4278,7 +4278,7 @@ array, such an approach would not be recommended for huge arrays, but
|
|||
for small structures, this approach works fine.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn63"></a>26.9.5 Mapping sequences to C arrays</H3>
|
||||
<H3><a name="Python_nn63"></a>28.9.5 Mapping sequences to C arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4363,7 +4363,7 @@ static int convert_darray(PyObject *input, double *ptr, int size) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn64"></a>26.9.6 Pointer handling</H3>
|
||||
<H3><a name="Python_nn64"></a>28.9.6 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4458,7 +4458,7 @@ class object (if applicable).
|
|||
|
||||
|
||||
|
||||
<H2><a name="Python_nn65"></a>26.10 Docstring Features</H2>
|
||||
<H2><a name="Python_nn65"></a>28.10 Docstring Features</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4486,7 +4486,7 @@ of your users much simpler.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn66"></a>26.10.1 Module docstring</H3>
|
||||
<H3><a name="Python_nn66"></a>28.10.1 Module docstring</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4520,7 +4520,7 @@ layout of controls on a panel, etc. to be loaded from an XML file."
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn67"></a>26.10.2 %feature("autodoc")</H3>
|
||||
<H3><a name="Python_nn67"></a>28.10.2 %feature("autodoc")</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4547,7 +4547,7 @@ names, default values if any, and return type if any. There are also
|
|||
three options for autodoc controlled by the value given to the
|
||||
feature, described below.
|
||||
|
||||
<H4><a name="Python_nn68"></a>26.10.2.1 %feature("autodoc", "0")</H4>
|
||||
<H4><a name="Python_nn68"></a>28.10.2.1 %feature("autodoc", "0")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4576,7 +4576,7 @@ def function_name(*args, **kwargs):
|
|||
</div>
|
||||
|
||||
|
||||
<H4><a name="Python_nn69"></a>26.10.2.2 %feature("autodoc", "1")</H4>
|
||||
<H4><a name="Python_nn69"></a>28.10.2.2 %feature("autodoc", "1")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4601,7 +4601,7 @@ def function_name(*args, **kwargs):
|
|||
|
||||
|
||||
|
||||
<H4><a name="Python_nn70"></a>26.10.2.3 %feature("autodoc", "docstring")</H4>
|
||||
<H4><a name="Python_nn70"></a>28.10.2.3 %feature("autodoc", "docstring")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4620,7 +4620,7 @@ void GetPosition(int* OUTPUT, int* OUTPUT);
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn71"></a>26.10.3 %feature("docstring")</H3>
|
||||
<H3><a name="Python_nn71"></a>28.10.3 %feature("docstring")</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4652,7 +4652,7 @@ with more than one line.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Python_nn72"></a>26.11 Python Packages</H2>
|
||||
<H2><a name="Python_nn72"></a>28.11 Python Packages</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body style="background-color: rgb(255, 255, 255);">
|
||||
<H1><a name="Ruby"></a>27 SWIG and Ruby</H1>
|
||||
<H1><a name="Ruby"></a>29 SWIG and Ruby</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -223,7 +223,7 @@
|
|||
</ul>
|
||||
</div> <!-- INDEX -->
|
||||
<p>This chapter describes SWIG's support of Ruby.</p>
|
||||
<H2><a name="Ruby_nn2"></a>27.1 Preliminaries</H2>
|
||||
<H2><a name="Ruby_nn2"></a>29.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -237,7 +237,7 @@
|
|||
Basics</a>" chapter. It is also assumed that the reader has a basic
|
||||
understanding of Ruby.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn3"></a>27.1.1 Running SWIG</H3>
|
||||
<H3><a name="Ruby_nn3"></a>29.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -259,7 +259,7 @@
|
|||
extension module. To finish building the module, you need to compile this file
|
||||
and link it with the rest of your program.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn4"></a>27.1.2 Getting the right header files</H3>
|
||||
<H3><a name="Ruby_nn4"></a>29.1.2 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -280,7 +280,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
/usr/local/lib/ruby/site_ruby /usr/local/lib/ruby/1.6 /usr/local/lib/ruby/1.6/i686-linux .
|
||||
</pre>
|
||||
</div>
|
||||
<H3><a name="Ruby_nn5"></a>27.1.3 Compiling a dynamic module</H3>
|
||||
<H3><a name="Ruby_nn5"></a>29.1.3 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -332,7 +332,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<p>
|
||||
<a name="n6"></a>
|
||||
</p>
|
||||
<H3><a name="Ruby_nn6"></a>27.1.4 Using your module</H3>
|
||||
<H3><a name="Ruby_nn6"></a>29.1.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -356,7 +356,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
will result in an extension module using the feature name "example" and Ruby
|
||||
module name "Example".
|
||||
</p>
|
||||
<H3><a name="Ruby_nn7"></a>27.1.5 Static linking</H3>
|
||||
<H3><a name="Ruby_nn7"></a>29.1.5 Static linking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -372,7 +372,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
to the list of extensions in the file, and finally rebuilding Ruby.
|
||||
</p>
|
||||
<p><a name="n8"></a></p>
|
||||
<H3><a name="Ruby_nn8"></a>27.1.6 Compilation of C++ extensions</H3>
|
||||
<H3><a name="Ruby_nn8"></a>29.1.6 Compilation of C++ extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -396,7 +396,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>require 'mkmf'<br>$libs = append_library($libs, "supc++")<br>create_makefile('example')<br></pre>
|
||||
</div>
|
||||
<H2><a name="Ruby_nn9"></a>27.2 Building Ruby Extensions under Windows 95/NT</H2>
|
||||
<H2><a name="Ruby_nn9"></a>29.2 Building Ruby Extensions under Windows 95/NT</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -419,7 +419,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
will need the Ruby header files.
|
||||
</p>
|
||||
<p><a name="n10"></a></p>
|
||||
<H3><a name="Ruby_nn10"></a>27.2.1 Running SWIG from Developer Studio</H3>
|
||||
<H3><a name="Ruby_nn10"></a>29.2.1 Running SWIG from Developer Studio</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -487,14 +487,14 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>C:\swigtest> <b>ruby run.rb</b><br>Foo = 3.0<br></pre>
|
||||
</div>
|
||||
<H2><a name="Ruby_nn11"></a>27.3 The Ruby-to-C/C++ Mapping</H2>
|
||||
<H2><a name="Ruby_nn11"></a>29.3 The Ruby-to-C/C++ Mapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
This section describes the basics of how SWIG maps C or C++ declarations in
|
||||
your SWIG interface files to Ruby constructs.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn12"></a>27.3.1 Modules</H3>
|
||||
<H3><a name="Ruby_nn12"></a>29.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -561,7 +561,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
global module, take care that the names of your constants, classes and methods
|
||||
don't conflict with any of Ruby's built-in names.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn13"></a>27.3.2 Functions</H3>
|
||||
<H3><a name="Ruby_nn13"></a>29.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -584,7 +584,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>$ <b>irb</b><br>irb(main):001:0> <b>require 'example'</b><br>true<br>irb(main):002:0> <b>Example.fact(4)</b><br>24<br></pre>
|
||||
</div>
|
||||
<H3><a name="Ruby_nn14"></a>27.3.3 Variable Linking</H3>
|
||||
<H3><a name="Ruby_nn14"></a>29.3.3 Variable Linking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -621,7 +621,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
The <tt>%immutable</tt> directive stays in effect until it is explicitly
|
||||
disabled using <tt>%mutable</tt>.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn15"></a>27.3.4 Constants</H3>
|
||||
<H3><a name="Ruby_nn15"></a>29.3.4 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -638,7 +638,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>$ <b>irb</b><br>irb(main):001:0> <b>require 'Example'</b><br>true<br>irb(main):002:0> <b>Example::PI</b><br>3.14159<br></pre>
|
||||
</div>
|
||||
<H3><a name="Ruby_nn16"></a>27.3.5 Pointers</H3>
|
||||
<H3><a name="Ruby_nn16"></a>29.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -659,7 +659,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<p>
|
||||
A <tt>NULL</tt> pointer is always represented by the Ruby <tt>nil</tt> object.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn17"></a>27.3.6 Structures</H3>
|
||||
<H3><a name="Ruby_nn17"></a>29.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -724,7 +724,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>Foo *Bar_f_get(Bar *b) {<br> return &b->f;<br>}<br><br>void Bar_f_set(Bar *b, Foo *val) {<br> b->f = *val;<br>}<br></pre>
|
||||
</div>
|
||||
<H3><a name="Ruby_nn18"></a>27.3.7 C++ classes</H3>
|
||||
<H3><a name="Ruby_nn18"></a>29.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -758,7 +758,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>require 'Example'<br><br>l = Example::List.new<br><br>l.insert("Ale")<br>l.insert("Stout")<br>l.insert("Lager")<br>Example.print(l)<br>l.length()<br>----- produces the following output <br>Lager<br>Stout<br>Ale<br>3<br></pre>
|
||||
</div>
|
||||
<H3><a name="Ruby_nn19"></a>27.3.8 C++ Inheritance</H3>
|
||||
<H3><a name="Ruby_nn19"></a>29.3.8 C++ Inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -851,7 +851,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
will otherwise behave as though they inherit from both <tt>Base1</tt> and <tt>Base2</tt>
|
||||
(i.e. they exhibit <a href="http://c2.com/cgi/wiki?DuckTyping">"Duck Typing"</a>).
|
||||
</p>
|
||||
<H3><a name="Ruby_nn20"></a>27.3.9 C++ Overloaded Functions</H3>
|
||||
<H3><a name="Ruby_nn20"></a>29.3.9 C++ Overloaded Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -913,7 +913,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<p>Please refer to the <a href="SWIGPlus.html#SWIGPlus">"SWIG and C++"</a> chapter
|
||||
for more information about overloading. <a name="n21"></a>
|
||||
</p>
|
||||
<H3><a name="Ruby_nn21"></a>27.3.10 C++ Operators</H3>
|
||||
<H3><a name="Ruby_nn21"></a>29.3.10 C++ Operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -943,7 +943,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
More details about wrapping C++ operators into Ruby operators is discussed in
|
||||
the <a href="#ruby_operator_overloading">section on operator overloading</a>.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn22"></a>27.3.11 C++ namespaces</H3>
|
||||
<H3><a name="Ruby_nn22"></a>29.3.11 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -973,7 +973,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
namespaces each with identical symbol names, well, then you get what you
|
||||
deserve.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn23"></a>27.3.12 C++ templates</H3>
|
||||
<H3><a name="Ruby_nn23"></a>29.3.12 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1014,7 +1014,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
examples. More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG
|
||||
and C++</a> chapter.
|
||||
</p>
|
||||
<H3><a name="ruby_cpp_smart_pointers"></a>27.3.13 C++ Smart Pointers</H3>
|
||||
<H3><a name="ruby_cpp_smart_pointers"></a>29.3.13 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1052,7 +1052,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>irb(main):004:0> <b>f = p.__deref__()</b> # Returns underlying Foo *<br></pre>
|
||||
</div>
|
||||
<H3><a name="Ruby_nn25"></a>27.3.14 Cross-Language Polymorphism</H3>
|
||||
<H3><a name="Ruby_nn25"></a>29.3.14 Cross-Language Polymorphism</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1062,7 +1062,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
this section just notes the differences that you need to be aware of when using
|
||||
this feature with Ruby.
|
||||
</p>
|
||||
<H4><a name="Ruby_nn26"></a>27.3.14.1 Exception Unrolling</H4>
|
||||
<H4><a name="Ruby_nn26"></a>29.3.14.1 Exception Unrolling</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1083,7 +1083,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
Ruby exception is raised, it will be caught here and a C++ exception is raised
|
||||
in its place.
|
||||
</p>
|
||||
<H2><a name="Ruby_nn27"></a>27.4 Input and output parameters</H2>
|
||||
<H2><a name="Ruby_nn27"></a>29.4 Input and output parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1209,7 +1209,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
the standard Ruby exception classes, consult a Ruby reference such as <a href="http://www.rubycentral.com/book">
|
||||
<em>Programming Ruby</em></a>.
|
||||
</p>
|
||||
<H2><a name="Ruby_nn29"></a>27.5 Typemaps</H2>
|
||||
<H2><a name="Ruby_nn29"></a>29.5 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1222,7 +1222,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
of using SWIG---the default wrapping behavior is enough in most cases. Typemaps
|
||||
are only used if you want to change some aspect of the primitive C-Ruby
|
||||
interface.</p>
|
||||
<H3><a name="Ruby_nn30"></a>27.5.1 What is a typemap?</H3>
|
||||
<H3><a name="Ruby_nn30"></a>29.5.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1289,7 +1289,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>puts Example.count('o','Hello World')<br>2<br></pre>
|
||||
</div>
|
||||
<H3><a name="Ruby_nn31"></a>27.5.2 Ruby typemaps</H3>
|
||||
<H3><a name="Ruby_nn31"></a>29.5.2 Ruby typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1346,7 +1346,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
Examples of these typemaps appears in the <a href="#ruby_typemap_examples">section
|
||||
on typemap examples</a>
|
||||
</p>
|
||||
<H3><a name="Ruby_nn32"></a>27.5.3 Typemap variables</H3>
|
||||
<H3><a name="Ruby_nn32"></a>29.5.3 Typemap variables</H3>
|
||||
|
||||
|
||||
Within a typemap, a number of special variables prefaced with a <tt>$</tt> may
|
||||
|
|
@ -1382,7 +1382,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<p><tt>$symname</tt></p>
|
||||
<div class="indent">The Ruby name of the wrapper function being created.
|
||||
</div>
|
||||
<H3><a name="Ruby_nn33"></a>27.5.4 Useful Functions</H3>
|
||||
<H3><a name="Ruby_nn33"></a>29.5.4 Useful Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1392,19 +1392,19 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
by David Thomas and Andrew Hunt.)
|
||||
</p>
|
||||
<p><a name="n34"></a></p>
|
||||
<H4><a name="Ruby_nn34"></a>27.5.4.1 C Datatypes to Ruby Objects</H4>
|
||||
<H4><a name="Ruby_nn34"></a>29.5.4.1 C Datatypes to Ruby Objects</H4>
|
||||
|
||||
|
||||
<div class="code">
|
||||
<pre>INT2NUM(long or int) - int to Fixnum or Bignum<br>INT2FIX(long or int) - int to Fixnum (faster than INT2NUM)<br>CHR2FIX(char) - char to Fixnum<br>rb_str_new2(char*) - char* to String<br>rb_float_new(double) - double to Float<br></pre>
|
||||
</div>
|
||||
<H4><a name="Ruby_nn35"></a>27.5.4.2 Ruby Objects to C Datatypes</H4>
|
||||
<H4><a name="Ruby_nn35"></a>29.5.4.2 Ruby Objects to C Datatypes</H4>
|
||||
|
||||
|
||||
<div class="code">
|
||||
<pre> int NUM2INT(Numeric)<br> int FIX2INT(Numeric)<br> unsigned int NUM2UINT(Numeric)<br> unsigned int FIX2UINT(Numeric)<br> long NUM2LONG(Numeric)<br> long FIX2LONG(Numeric)<br>unsigned long FIX2ULONG(Numeric)<br> char NUM2CHR(Numeric or String)<br> char * STR2CSTR(String)<br> char * rb_str2cstr(String, int*length)<br> double NUM2DBL(Numeric)<br><br></pre>
|
||||
</div>
|
||||
<H4><a name="Ruby_nn36"></a>27.5.4.3 Macros for VALUE</H4>
|
||||
<H4><a name="Ruby_nn36"></a>29.5.4.3 Macros for VALUE</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1419,7 +1419,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="indent">capacity of the Ruby array</div>
|
||||
<p><tt>RARRAY(arr)->ptr</tt></p>
|
||||
<div class="indent">pointer to array storage</div>
|
||||
<H4><a name="Ruby_nn37"></a>27.5.4.4 Exceptions</H4>
|
||||
<H4><a name="Ruby_nn37"></a>29.5.4.4 Exceptions</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1486,7 +1486,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
with the <tt>-w</tt> flag. The given format string <i>fmt</i> and remaining
|
||||
arguments are interpreted as with <tt>printf()</tt>.
|
||||
</div>
|
||||
<H4><a name="Ruby_nn38"></a>27.5.4.5 Iterators</H4>
|
||||
<H4><a name="Ruby_nn38"></a>29.5.4.5 Iterators</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1525,14 +1525,14 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="indent">
|
||||
Equivalent to Ruby's <tt>throw</tt>.
|
||||
</div>
|
||||
<H3><a name="ruby_typemap_examples"></a>27.5.5 Typemap Examples</H3>
|
||||
<H3><a name="ruby_typemap_examples"></a>29.5.5 Typemap Examples</H3>
|
||||
|
||||
|
||||
<p>
|
||||
This section includes a few examples of typemaps. For more examples, you might
|
||||
look at the examples in the <tt>Example/ruby</tt> directory.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn40"></a>27.5.6 Converting a Ruby array to a char **</H3>
|
||||
<H3><a name="Ruby_nn40"></a>29.5.6 Converting a Ruby array to a char **</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1556,7 +1556,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
allocation is used to allocate memory for the array, the "freearg" typemap is
|
||||
used to later release this memory after the execution of the C function.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn41"></a>27.5.7 Collecting arguments in a hash</H3>
|
||||
<H3><a name="Ruby_nn41"></a>29.5.7 Collecting arguments in a hash</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1669,7 +1669,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
the extension, can be found in the <tt>Examples/ruby/hashargs</tt> directory of
|
||||
the SWIG distribution.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn42"></a>27.5.8 Pointer handling</H3>
|
||||
<H3><a name="Ruby_nn42"></a>29.5.8 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1716,7 +1716,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="indent">
|
||||
<pre>%typemap(in) Foo * {<br> SWIG_ConvertPtr($input, (void **) &$1, $1_descriptor, 1);<br>}<br></pre>
|
||||
</div>
|
||||
<H4><a name="Ruby_nn43"></a>27.5.8.1 Ruby Datatype Wrapping</H4>
|
||||
<H4><a name="Ruby_nn43"></a>29.5.8.1 Ruby Datatype Wrapping</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1737,7 +1737,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="indent">Retrieves the original C pointer of type <i>c-type</i> from the
|
||||
data object <i>obj</i> and assigns that pointer to <i>ptr</i>.
|
||||
</div>
|
||||
<H2><a name="ruby_operator_overloading"></a>27.6 Operator overloading</H2>
|
||||
<H2><a name="ruby_operator_overloading"></a>29.6 Operator overloading</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1752,7 +1752,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
defining an equivalence operator, there is no separate method for handling <i>inequality</i>
|
||||
since Ruby parses the expression <i>a != b</i> as <i>!(a == b)</i>.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn45"></a>27.6.1 Example: STL Vector to Ruby Array</H3>
|
||||
<H3><a name="Ruby_nn45"></a>29.6.1 Example: STL Vector to Ruby Array</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1789,10 +1789,10 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>%define VECTOR_TO_RUBY_ARRAY(vectorclassname, classname)<br>%typemap(ruby, out) vectorclassname &, const vectorclassname & {<br> VALUE arr = rb_ary_new2($1->size()); <br> vectorclassname::iterator i = $1->begin(), iend = $1->end();<br> for ( ; i!=iend; i++ )<br> rb_ary_push(arr, Data_Wrap_Struct(c ## classname.klass, 0, 0, &(*i)));<br> $result = arr;<br>}<br>%typemap(ruby, out) vectorclassname, const vectorclassname {<br> VALUE arr = rb_ary_new2($1.size()); <br> vectorclassname::iterator i = $1.begin(), iend = $1.end();<br> for ( ; i!=iend; i++ )<br> rb_ary_push(arr, Data_Wrap_Struct(c ## classname.klass, 0, 0, &(*i)));<br> $result = arr;<br>}<br>%enddef<br></pre>
|
||||
</div>
|
||||
<H2><a name="Ruby_nn46"></a>27.7 Advanced Topics</H2>
|
||||
<H2><a name="Ruby_nn46"></a>29.7 Advanced Topics</H2>
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn47"></a>27.7.1 Creating Multi-Module Packages</H3>
|
||||
<H3><a name="Ruby_nn47"></a>29.7.1 Creating Multi-Module Packages</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1863,7 +1863,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<div class="code">
|
||||
<pre>$ <b>irb</b><br>irb(main):001:0> <b>require 'shape'</b><br>true<br>irb(main):002:0> <b>require 'circle'</b><br>true<br>irb(main):003:0> <b>c = Circle::Circle.new(5, 5, 20)</b><br>#<Circle::Circle:0xa097208><br>irb(main):004:0> <b>c.kind_of? Shape::Shape</b><br>true<br>irb(main):005:0> <b>c.getX()</b><br>5.0<br></pre>
|
||||
</div>
|
||||
<H3><a name="Ruby_nn48"></a>27.7.2 Defining Aliases</H3>
|
||||
<H3><a name="Ruby_nn48"></a>29.7.2 Defining Aliases</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1902,7 +1902,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
mechanism and so the same name matching rules used for other kinds of features
|
||||
apply (see the chapter on <a href="Customization.html#Customization">"Customization
|
||||
Features"</a>) for more details).</p>
|
||||
<H3><a name="Ruby_nn49"></a>27.7.3 Predicate Methods</H3>
|
||||
<H3><a name="Ruby_nn49"></a>29.7.3 Predicate Methods</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1939,7 +1939,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
of features apply (see the chapter on <a href="Customization.html#Customization">"Customization
|
||||
Features"</a>) for more details).
|
||||
</p>
|
||||
<H3><a name="Ruby_nn50"></a>27.7.4 Specifying Mixin Modules</H3>
|
||||
<H3><a name="Ruby_nn50"></a>29.7.4 Specifying Mixin Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1980,7 +1980,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
apply (see the chapter on <a href="Customization.html#Customization">"Customization
|
||||
Features"</a>) for more details).
|
||||
</p>
|
||||
<H2><a name="Ruby_nn51"></a>27.8 Memory Management</H2>
|
||||
<H2><a name="Ruby_nn51"></a>29.8 Memory Management</H2>
|
||||
|
||||
|
||||
<p>One of the most common issues in generating SWIG bindings for Ruby is proper
|
||||
|
|
@ -2024,7 +2024,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
allocated in creating the underlying C struct or C++ struct, then a "free"
|
||||
function must be defined that deallocates this memory.
|
||||
</p>
|
||||
<H3><a name="Ruby_nn53"></a>27.8.1 Object Ownership</H3>
|
||||
<H3><a name="Ruby_nn53"></a>29.8.1 Object Ownership</H3>
|
||||
|
||||
|
||||
<p>As described above, memory management depends on clearly defining who is
|
||||
|
|
@ -2099,7 +2099,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
<p>
|
||||
This code can be seen in swig/examples/ruby/tracking.</p>
|
||||
<br>
|
||||
<H3><a name="Ruby_nn54"></a>27.8.2 Object Tracking</H3>
|
||||
<H3><a name="Ruby_nn54"></a>29.8.2 Object Tracking</H3>
|
||||
|
||||
|
||||
<p>The remaining parts of this section will use the class library shown below to
|
||||
|
|
@ -2168,7 +2168,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
implement your own free functions (see below) you may also have to call the<tt>SWIG_RubyRemoveTracking</tt>
|
||||
and <tt>RubyUnlinkObjects</tt> methods.</p>
|
||||
|
||||
<H3><a name="Ruby_nn55"></a>27.8.3 Mark Functions</H3>
|
||||
<H3><a name="Ruby_nn55"></a>29.8.3 Mark Functions</H3>
|
||||
|
||||
|
||||
<p>With a bit more testing, we see that our class library still has problems. For
|
||||
|
|
@ -2210,7 +2210,7 @@ $ <b>ruby -e 'puts $:.join("\n")'</b><br>/usr/local/lib/ruby/site_ruby/1.6 /usr/
|
|||
</div>
|
||||
<br>
|
||||
<p>This code can be seen in swig/examples/ruby/mark_function.</p>
|
||||
<H3><a name="Ruby_nn56"></a>27.8.4 Free Functions</H3>
|
||||
<H3><a name="Ruby_nn56"></a>29.8.4 Free Functions</H3>
|
||||
|
||||
|
||||
<p>By default, SWIG creates a "free" function that is called when a Ruby object is
|
||||
|
|
|
|||
|
|
@ -41,6 +41,7 @@ to help!).
|
|||
|
||||
<ul>
|
||||
<li><a href="Lisp.html#Lisp_nn1">Common Lisp support</a></li>
|
||||
<li><a href="Allegrocl.html#Allegrocl_nn1">Allegro CL support</a></li>
|
||||
<li><a href="CSharp.html#CSharp">C# support</a></li>
|
||||
<li><a href="Chicken.html#Chicken">Chicken support</a></li>
|
||||
<li><a href="Guile.html#Guile">Guile support</a></li>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Tcl"></a>28 SWIG and Tcl</H1>
|
||||
<H1><a name="Tcl"></a>30 SWIG and Tcl</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -82,7 +82,7 @@ Tcl 8.0 or a later release. Earlier releases of SWIG supported Tcl 7.x, but
|
|||
this is no longer supported.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn2"></a>28.1 Preliminaries</H2>
|
||||
<H2><a name="Tcl_nn2"></a>30.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -108,7 +108,7 @@ build a Tcl extension module. To finish building the module, you
|
|||
need to compile this file and link it with the rest of your program.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn3"></a>28.1.1 Getting the right header files</H3>
|
||||
<H3><a name="Tcl_nn3"></a>30.1.1 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -126,7 +126,7 @@ this is the case, you should probably make a symbolic link so that <tt>tcl.h</tt
|
|||
header file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn4"></a>28.1.2 Compiling a dynamic module</H3>
|
||||
<H3><a name="Tcl_nn4"></a>30.1.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -161,7 +161,7 @@ The name of the module is specified using the <tt>%module</tt> directive or the
|
|||
<tt> -module</tt> command line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn5"></a>28.1.3 Static linking</H3>
|
||||
<H3><a name="Tcl_nn5"></a>30.1.3 Static linking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -227,7 +227,7 @@ minimal in most situations (and quite frankly not worth the extra
|
|||
hassle in the opinion of this author).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn6"></a>28.1.4 Using your module</H3>
|
||||
<H3><a name="Tcl_nn6"></a>30.1.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -355,7 +355,7 @@ to the default system configuration (this requires root access and you will need
|
|||
the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn7"></a>28.1.5 Compilation of C++ extensions</H3>
|
||||
<H3><a name="Tcl_nn7"></a>30.1.5 Compilation of C++ extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -438,7 +438,7 @@ erratic program behavior. If working with lots of software components, you
|
|||
might want to investigate using a more formal standard such as COM.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn8"></a>28.1.6 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Tcl_nn8"></a>30.1.6 Compiling for 64-bit platforms</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -465,7 +465,7 @@ also introduce problems on platforms that support more than one
|
|||
linking standard (e.g., -o32 and -n32 on Irix).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn9"></a>28.1.7 Setting a package prefix</H3>
|
||||
<H3><a name="Tcl_nn9"></a>30.1.7 Setting a package prefix</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -484,7 +484,7 @@ option will append the prefix to the name when creating a command and
|
|||
call it "<tt>Foo_bar</tt>".
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn10"></a>28.1.8 Using namespaces</H3>
|
||||
<H3><a name="Tcl_nn10"></a>30.1.8 Using namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -506,7 +506,7 @@ When the<tt> -namespace</tt> option is used, objects in the module
|
|||
are always accessed with the namespace name such as <tt>Foo::bar</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn11"></a>28.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
|
||||
<H2><a name="Tcl_nn11"></a>30.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -517,7 +517,7 @@ covers the process of using SWIG with Microsoft Visual C++.
|
|||
although the procedure may be similar with other compilers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn12"></a>28.2.1 Running SWIG from Developer Studio</H3>
|
||||
<H3><a name="Tcl_nn12"></a>30.2.1 Running SWIG from Developer Studio</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -575,7 +575,7 @@ MSDOS > tclsh80
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn13"></a>28.2.2 Using NMAKE</H3>
|
||||
<H3><a name="Tcl_nn13"></a>30.2.2 Using NMAKE</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -638,7 +638,7 @@ to get you started. With a little practice, you'll be making lots of
|
|||
Tcl extensions.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn14"></a>28.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Tcl_nn14"></a>30.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -649,7 +649,7 @@ classes. This section briefly covers the essential aspects of this
|
|||
wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn15"></a>28.3.1 Modules</H3>
|
||||
<H3><a name="Tcl_nn15"></a>30.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -683,7 +683,7 @@ To fix this, supply an extra argument to <tt>load</tt> like this:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn16"></a>28.3.2 Functions</H3>
|
||||
<H3><a name="Tcl_nn16"></a>30.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -708,7 +708,7 @@ like you think it does:
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn17"></a>28.3.3 Global variables</H3>
|
||||
<H3><a name="Tcl_nn17"></a>30.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -788,7 +788,7 @@ extern char *path; // Read-only (due to %immutable)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn18"></a>28.3.4 Constants and enums</H3>
|
||||
<H3><a name="Tcl_nn18"></a>30.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -872,7 +872,7 @@ When an identifier name is given, it is used to perform an implicit hash-table l
|
|||
conversion. This allows the <tt>global</tt> statement to be ommitted.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn19"></a>28.3.5 Pointers</H3>
|
||||
<H3><a name="Tcl_nn19"></a>30.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -968,7 +968,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
|
|||
<tt>None</tt> if the conversion can't be performed.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn20"></a>28.3.6 Structures</H3>
|
||||
<H3><a name="Tcl_nn20"></a>30.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1250,7 +1250,7 @@ Note: Tcl only destroys the underlying object if it has ownership. See the
|
|||
memory management section that appears shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn21"></a>28.3.7 C++ classes</H3>
|
||||
<H3><a name="Tcl_nn21"></a>30.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1317,7 +1317,7 @@ In Tcl, the static member is accessed as follows:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn22"></a>28.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Tcl_nn22"></a>30.3.8 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1366,7 +1366,7 @@ For instance:
|
|||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn23"></a>28.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Tcl_nn23"></a>30.3.9 Pointers, references, values, and arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1420,7 +1420,7 @@ to hold the result and a pointer is returned (Tcl will release this memory
|
|||
when the return value is garbage collected).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn24"></a>28.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Tcl_nn24"></a>30.3.10 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1543,7 +1543,7 @@ first declaration takes precedence.
|
|||
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn25"></a>28.3.11 C++ operators</H3>
|
||||
<H3><a name="Tcl_nn25"></a>30.3.11 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1645,7 +1645,7 @@ There are ways to make this operator appear as part of the class using the <tt>%
|
|||
Keep reading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn26"></a>28.3.12 C++ namespaces</H3>
|
||||
<H3><a name="Tcl_nn26"></a>30.3.12 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1709,7 +1709,7 @@ utilizes thousands of small deeply nested namespaces each with
|
|||
identical symbol names, well, then you get what you deserve.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn27"></a>28.3.13 C++ templates</H3>
|
||||
<H3><a name="Tcl_nn27"></a>30.3.13 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1761,7 +1761,7 @@ More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</
|
|||
examples will appear later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn28"></a>28.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Tcl_nn28"></a>30.3.14 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1845,7 +1845,7 @@ simply use the <tt>__deref__()</tt> method. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn29"></a>28.4 Further details on the Tcl class interface</H2>
|
||||
<H2><a name="Tcl_nn29"></a>30.4 Further details on the Tcl class interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1858,7 +1858,7 @@ of low-level details were omitted. This section provides a brief overview
|
|||
of how the proxy classes work.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn30"></a>28.4.1 Proxy classes</H3>
|
||||
<H3><a name="Tcl_nn30"></a>30.4.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1923,7 +1923,7 @@ function. This allows objects to be encapsulated objects that look a lot like
|
|||
as shown in the last section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn31"></a>28.4.2 Memory management</H3>
|
||||
<H3><a name="Tcl_nn31"></a>30.4.2 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2111,7 +2111,7 @@ typemaps--an advanced topic discussed later.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Tcl_nn32"></a>28.5 Input and output parameters</H2>
|
||||
<H2><a name="Tcl_nn32"></a>30.5 Input and output parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2299,7 +2299,7 @@ set c [lindex $dim 1]
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn33"></a>28.6 Exception handling </H2>
|
||||
<H2><a name="Tcl_nn33"></a>30.6 Exception handling </H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2433,7 +2433,7 @@ Since SWIG's exception handling is user-definable, you are not limited to C++ ex
|
|||
See the chapter on "<a href="Customization.html#Customization">Customization Features</a>" for more examples.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn34"></a>28.7 Typemaps</H2>
|
||||
<H2><a name="Tcl_nn34"></a>30.7 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2450,7 +2450,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Tcl interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn35"></a>28.7.1 What is a typemap?</H3>
|
||||
<H3><a name="Tcl_nn35"></a>30.7.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2567,7 +2567,7 @@ parameter is ommitted):
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn36"></a>28.7.2 Tcl typemaps</H3>
|
||||
<H3><a name="Tcl_nn36"></a>30.7.2 Tcl typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2705,7 +2705,7 @@ Initialize an argument to a value before any conversions occur.
|
|||
Examples of these methods will appear shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn37"></a>28.7.3 Typemap variables</H3>
|
||||
<H3><a name="Tcl_nn37"></a>30.7.3 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2776,7 +2776,7 @@ properly assigned.
|
|||
The Tcl name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn38"></a>28.7.4 Converting a Tcl list to a char ** </H3>
|
||||
<H3><a name="Tcl_nn38"></a>30.7.4 Converting a Tcl list to a char ** </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2838,7 +2838,7 @@ argv[2] = Larry
|
|||
3
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn39"></a>28.7.5 Returning values in arguments</H3>
|
||||
<H3><a name="Tcl_nn39"></a>30.7.5 Returning values in arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2880,7 +2880,7 @@ result, a Tcl function using these typemaps will work like this :
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn40"></a>28.7.6 Useful functions</H3>
|
||||
<H3><a name="Tcl_nn40"></a>30.7.6 Useful functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2957,7 +2957,7 @@ int Tcl_IsShared(Tcl_Obj *obj);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn41"></a>28.7.7 Standard typemaps</H3>
|
||||
<H3><a name="Tcl_nn41"></a>30.7.7 Standard typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3041,7 +3041,7 @@ work)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn42"></a>28.7.8 Pointer handling</H3>
|
||||
<H3><a name="Tcl_nn42"></a>30.7.8 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3117,7 +3117,7 @@ For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn43"></a>28.8 Turning a SWIG module into a Tcl Package.</H2>
|
||||
<H2><a name="Tcl_nn43"></a>30.8 Turning a SWIG module into a Tcl Package.</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3189,7 +3189,7 @@ As a final note, most SWIG examples do not yet use the
|
|||
to use the <tt>load</tt> command instead.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn44"></a>28.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
|
||||
<H2><a name="Tcl_nn44"></a>30.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3288,7 +3288,7 @@ danger of blowing something up (although it is easily accomplished
|
|||
with an out of bounds array access).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn45"></a>28.9.1 Proxy classes</H3>
|
||||
<H3><a name="Tcl_nn45"></a>30.9.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -13,6 +13,8 @@ Contract.html
|
|||
Varargs.html
|
||||
Warnings.html
|
||||
Modules.html
|
||||
Lisp.html
|
||||
Allegrocl.html
|
||||
CSharp.html
|
||||
Chicken.html
|
||||
Guile.html
|
||||
|
|
|
|||
|
|
@ -3,44 +3,275 @@
|
|||
|
||||
#define SWIG_ALLEGRO_CL
|
||||
|
||||
/* Typespecs for basic types. */
|
||||
#define %ffargs(...) %feature("ffargs", "1", ##__VA_ARGS__)
|
||||
%ffargs(strings_convert="t");
|
||||
|
||||
%typemap(ffitype) char ":char";
|
||||
/* typemaps for argument and result type conversions. */
|
||||
%typemap(lin) SWIGTYPE "(let (($out $in))\n $body)";
|
||||
|
||||
%typemap(lout) bool, char, unsigned char, signed char,
|
||||
short, signed short, unsigned short,
|
||||
int, signed int, unsigned int,
|
||||
long, signed long, unsigned long,
|
||||
float, double, long double, char *, void *, void,
|
||||
enum SWIGTYPE "$body";
|
||||
%typemap(lout) SWIGTYPE[ANY], SWIGTYPE *,
|
||||
SWIGTYPE & "(make-instance '$lclass :foreign-address $body)";
|
||||
%typemap(lout) SWIGTYPE "(let* ((address $body)\n (ACL_result (make-instance '$lclass :foreign-address address)))\n (unless (zerop address)\n (excl:schedule-finalization ACL_result #'$ldestructor))\n ACL_result)";
|
||||
|
||||
%typemap(lisptype) bool "boolean";
|
||||
%typemap(lisptype) char "character";
|
||||
%typemap(ffitype) unsigned char ":unsigned-char";
|
||||
%typemap(lisptype) unsigned char "integer";
|
||||
%typemap(ffitype) signed char ":char";
|
||||
%typemap(lisptype) signed char "integer";
|
||||
%typemap(ffitype) short ":short";
|
||||
%typemap(ffitype) signed short ":short";
|
||||
|
||||
%typemap(ffitype) bool ":int";
|
||||
%typemap(ffitype) char ":char";
|
||||
%typemap(ffitype) unsigned char ":unsigned-char";
|
||||
%typemap(ffitype) signed char ":char";
|
||||
%typemap(ffitype) short, signed short ":short";
|
||||
%typemap(ffitype) unsigned short ":unsigned-short";
|
||||
%typemap(ffitype) int ":int";
|
||||
%typemap(ffitype) signed int ":int";
|
||||
%typemap(ffitype) int, signed int ":int";
|
||||
%typemap(ffitype) unsigned int ":unsigned-int";
|
||||
%typemap(ffitype) long ":long";
|
||||
%typemap(ffitype) signed long ":long";
|
||||
%typemap(ffitype) long, signed long ":long";
|
||||
%typemap(ffitype) unsigned long ":unsigned-long";
|
||||
%typemap(ffitype) float ":float";
|
||||
%typemap(ffitype) double ":double";
|
||||
%typemap(ffitype) char * "(* :char)";
|
||||
%typemap(ffitype) void * "(* :void)";
|
||||
%typemap(ffitype) void ":void";
|
||||
%typemap(ffitype) enum SWIGTYPE ":int";
|
||||
%typemap(ffitype) SWIGTYPE & "(* :void)";
|
||||
|
||||
%wrapper %{
|
||||
%typemap(ctype) bool "int";
|
||||
%typemap(ctype) char, unsigned char, signed char,
|
||||
short, signed short, unsigned short,
|
||||
int, signed int, unsigned int,
|
||||
long, signed long, unsigned long,
|
||||
float, double, long double, char *, void *, void,
|
||||
enum SWIGTYPE, SWIGTYPE *,
|
||||
SWIGTYPE[ANY], SWIGTYPE & "$1_ltype";
|
||||
%typemap(ctype) SWIGTYPE "$&1_type";
|
||||
|
||||
%typemap(in) bool "$1 = (bool)$input;";
|
||||
%typemap(in) char, unsigned char, signed char,
|
||||
short, signed short, unsigned short,
|
||||
int, signed int, unsigned int,
|
||||
long, signed long, unsigned long,
|
||||
float, double, long double, char *, void *, void,
|
||||
enum SWIGTYPE, SWIGTYPE *,
|
||||
SWIGTYPE[ANY], SWIGTYPE & "$1 = $input;";
|
||||
%typemap(in) SWIGTYPE "$1 = *$input;";
|
||||
|
||||
/* We don't need to do any actual C-side typechecking, but need to
|
||||
use the precedence values to choose which overloaded function
|
||||
interfaces to generate when conflicts arise. */
|
||||
|
||||
/* predefined precedence values
|
||||
|
||||
Symbolic Name Precedence Value
|
||||
------------------------------ ------------------
|
||||
SWIG_TYPECHECK_POINTER 0
|
||||
SWIG_TYPECHECK_VOIDPTR 10
|
||||
SWIG_TYPECHECK_BOOL 15
|
||||
SWIG_TYPECHECK_UINT8 20
|
||||
SWIG_TYPECHECK_INT8 25
|
||||
SWIG_TYPECHECK_UINT16 30
|
||||
SWIG_TYPECHECK_INT16 35
|
||||
SWIG_TYPECHECK_UINT32 40
|
||||
SWIG_TYPECHECK_INT32 45
|
||||
SWIG_TYPECHECK_UINT64 50
|
||||
SWIG_TYPECHECK_INT64 55
|
||||
SWIG_TYPECHECK_UINT128 60
|
||||
SWIG_TYPECHECK_INT128 65
|
||||
SWIG_TYPECHECK_INTEGER 70
|
||||
SWIG_TYPECHECK_FLOAT 80
|
||||
SWIG_TYPECHECK_DOUBLE 90
|
||||
SWIG_TYPECHECK_COMPLEX 100
|
||||
SWIG_TYPECHECK_UNICHAR 110
|
||||
SWIG_TYPECHECK_UNISTRING 120
|
||||
SWIG_TYPECHECK_CHAR 130
|
||||
SWIG_TYPECHECK_STRING 140
|
||||
SWIG_TYPECHECK_BOOL_ARRAY 1015
|
||||
SWIG_TYPECHECK_INT8_ARRAY 1025
|
||||
SWIG_TYPECHECK_INT16_ARRAY 1035
|
||||
SWIG_TYPECHECK_INT32_ARRAY 1045
|
||||
SWIG_TYPECHECK_INT64_ARRAY 1055
|
||||
SWIG_TYPECHECK_INT128_ARRAY 1065
|
||||
SWIG_TYPECHECK_FLOAT_ARRAY 1080
|
||||
SWIG_TYPECHECK_DOUBLE_ARRAY 1090
|
||||
SWIG_TYPECHECK_CHAR_ARRAY 1130
|
||||
SWIG_TYPECHECK_STRING_ARRAY 1140
|
||||
*/
|
||||
|
||||
%typecheck(SWIG_TYPECHECK_BOOL) bool { $1 = 1; };
|
||||
%typecheck(SWIG_TYPECHECK_CHAR) char { $1 = 1; };
|
||||
%typecheck(SWIG_TYPECHECK_FLOAT) float { $1 = 1; };
|
||||
%typecheck(SWIG_TYPECHECK_DOUBLE) double { $1 = 1; };
|
||||
%typecheck(SWIG_TYPECHECK_STRING) char * { $1 = 1; };
|
||||
%typecheck(SWIG_TYPECHECK_INTEGER)
|
||||
unsigned char, signed char,
|
||||
short, signed short, unsigned short,
|
||||
int, signed int, unsigned int,
|
||||
long, signed long, unsigned long,
|
||||
enum SWIGTYPE { $1 = 1; };
|
||||
%typecheck(SWIG_TYPECHECK_POINTER) SWIGTYPE *, SWIGTYPE &,
|
||||
SWIGTYPE[ANY], SWIGTYPE { $1 = 1; };
|
||||
|
||||
/* This maps C/C++ types to Lisp classes for overload dispatch */
|
||||
|
||||
%typemap(lispclass) bool "t";
|
||||
%typemap(lispclass) char "character";
|
||||
%typemap(lispclass) unsigned char, signed char,
|
||||
short, signed short, unsigned short,
|
||||
int, signed int, unsigned int,
|
||||
long, signed long, unsigned long,
|
||||
enum SWIGTYPE "integer";
|
||||
%typemap(lispclass) float "single-float";
|
||||
%typemap(lispclass) double "double-float";
|
||||
%typemap(lispclass) char * "string";
|
||||
|
||||
%typemap(out) bool "$result = (int)$1;";
|
||||
%typemap(out) char, unsigned char, signed char,
|
||||
short, signed short, unsigned short,
|
||||
int, signed int, unsigned int,
|
||||
long, signed long, unsigned long,
|
||||
float, double, long double, char *, void *, void,
|
||||
enum SWIGTYPE, SWIGTYPE *,
|
||||
SWIGTYPE[ANY], SWIGTYPE & "$result = $1;";
|
||||
%typemap(out) SWIGTYPE "$result = new $1_type($1);";
|
||||
|
||||
//////////////////////////////////////////////////////////////
|
||||
// UCS-2 string conversion
|
||||
|
||||
// should this be SWIG_TYPECHECK_CHAR?
|
||||
%typecheck(SWIG_TYPECHECK_UNICHAR) wchar_t { $1 = 1; };
|
||||
|
||||
%typemap(in) wchar_t "$1 = $input;";
|
||||
%typemap(lin) wchar_t "(let (($out (char-code $in)))\n $body)";
|
||||
%typemap(lin) wchar_t* "(excl:with-native-string ($out $in
|
||||
:external-format #+little-endian :fat-le #-little-endian :fat)\n
|
||||
$body)"
|
||||
|
||||
%typemap(out) wchar_t "$result = $1;";
|
||||
%typemap(lout) wchar_t "(code-char $body)";
|
||||
%typemap(lout) wchar_t* "(excl:native-to-string $body
|
||||
:external-format #+little-endian :fat-le #-little-endian :fat)";
|
||||
|
||||
%typemap(ffitype) wchar_t ":unsigned-short";
|
||||
%typemap(lisptype) wchar_t "";
|
||||
%typemap(ctype) wchar_t "wchar_t";
|
||||
%typemap(lispclass) wchar_t "character";
|
||||
%typemap(lispclass) wchar_t* "string";
|
||||
//////////////////////////////////////////////////////////////
|
||||
|
||||
/* name conversion for overloaded operators. */
|
||||
#ifdef __cplusplus
|
||||
%rename(__add__) *::operator+;
|
||||
%rename(__pos__) *::operator+();
|
||||
%rename(__pos__) *::operator+() const;
|
||||
|
||||
%rename(__sub__) *::operator-;
|
||||
%rename(__neg__) *::operator-() const;
|
||||
%rename(__neg__) *::operator-();
|
||||
|
||||
%rename(__mul__) *::operator*;
|
||||
%rename(__deref__) *::operator*();
|
||||
%rename(__deref__) *::operator*() const;
|
||||
|
||||
%rename(__div__) *::operator/;
|
||||
%rename(__mod__) *::operator%;
|
||||
%rename(__logxor__) *::operator^;
|
||||
%rename(__logand__) *::operator&;
|
||||
%rename(__logior__) *::operator|;
|
||||
%rename(__lognot__) *::operator~();
|
||||
%rename(__lognot__) *::operator~() const;
|
||||
|
||||
%rename(__not__) *::operator!();
|
||||
%rename(__not__) *::operator!() const;
|
||||
|
||||
%rename(__assign__) *::operator=;
|
||||
|
||||
%rename(__add_assign__) *::operator+=;
|
||||
%rename(__sub_assign__) *::operator-=;
|
||||
%rename(__mul_assign__) *::operator*=;
|
||||
%rename(__div_assign__) *::operator/=;
|
||||
%rename(__mod_assign__) *::operator%=;
|
||||
%rename(__logxor_assign__) *::operator^=;
|
||||
%rename(__logand_assign__) *::operator&=;
|
||||
%rename(__logior_assign__) *::operator|=;
|
||||
|
||||
%rename(__lshift__) *::operator<<;
|
||||
%rename(__lshift_assign__) *::operator<<=;
|
||||
%rename(__rshift__) *::operator>>;
|
||||
%rename(__rshift_assign__) *::operator>>=;
|
||||
|
||||
%rename(__eq__) *::operator==;
|
||||
%rename(__ne__) *::operator!=;
|
||||
%rename(__lt__) *::operator<;
|
||||
%rename(__gt__) *::operator>;
|
||||
%rename(__lte__) *::operator<=;
|
||||
%rename(__gte__) *::operator>=;
|
||||
|
||||
%rename(__and__) *::operator&&;
|
||||
%rename(__or__) *::operator||;
|
||||
|
||||
%rename(__preincr__) *::operator++();
|
||||
%rename(__postincr__) *::operator++(int);
|
||||
%rename(__predecr__) *::operator--();
|
||||
%rename(__postdecr__) *::operator--(int);
|
||||
|
||||
%rename(__comma__) *::operator,();
|
||||
%rename(__comma__) *::operator,() const;
|
||||
|
||||
%rename(__member_ref__) *::operator->;
|
||||
%rename(__member_func_ref__) *::operator->*;
|
||||
|
||||
%rename(__funcall__) *::operator();
|
||||
%rename(__aref__) *::operator[];
|
||||
#endif
|
||||
|
||||
%insert("lisphead") %{
|
||||
;; $Id$
|
||||
|
||||
(eval-when (compile eval)
|
||||
|
||||
;;; You can define your own identifier converter if you want.
|
||||
;;; Use the -identifier-converter command line argument to
|
||||
;;; specify its name.
|
||||
|
||||
(defun identifier-convert-null (id &key type)
|
||||
(declare (ignore type))
|
||||
(read-from-string id))
|
||||
;;; specify its name.
|
||||
|
||||
(defun identifier-convert-lispify (cname &key type)
|
||||
(eval-when (:compile-toplevel :load-toplevel :execute)
|
||||
(defparameter *swig-export-list* nil))
|
||||
|
||||
(defun read-symbol-from-string (string)
|
||||
(multiple-value-bind (result position)
|
||||
(read-from-string string nil "eof" :preserve-whitespace t)
|
||||
(if (and (symbolp result) (eql position (length string)))
|
||||
result
|
||||
(intern string))))
|
||||
|
||||
(defun full-name (id type arity class)
|
||||
(case type
|
||||
(:getter (format nil "~@[~A_~]~A" class id))
|
||||
(:constructor (format nil "new_~A~@[~A~]" id arity))
|
||||
(:destructor (format nil "delete_~A" id))
|
||||
(:type (format nil "ff_~A" id))
|
||||
(:ff-operator (format nil "ffi_~A" id))
|
||||
(otherwise (format nil "~@[~A_~]~A~@[~A~]"
|
||||
class id arity))))
|
||||
|
||||
(defun identifier-convert-null (id &key type class arity)
|
||||
(if (eq type :setter)
|
||||
`(setf ,(identifier-convert-null
|
||||
id :type :getter :class class :arity arity))
|
||||
(read-symbol-from-string (full-name id type arity class))))
|
||||
|
||||
(defun identifier-convert-lispify (cname &key type class arity)
|
||||
(assert (stringp cname))
|
||||
(when (eq type :setter)
|
||||
(return-from identifier-convert-lispify
|
||||
`(setf ,(identifier-convert-lispify
|
||||
cname :type :getter :class class :arity arity))))
|
||||
(setq cname (full-name cname type arity class))
|
||||
(if (eq type :constant)
|
||||
(setf cname (format nil "*~A*" cname)))
|
||||
(setf cname (replace-regexp cname "_" "-"))
|
||||
|
|
@ -54,7 +285,7 @@
|
|||
|
||||
(when (or (and (eq lastcase :upper) (eq newcase :lower))
|
||||
(and (eq lastcase :lower) (eq newcase :upper)))
|
||||
;; case change... add a dash
|
||||
;; case change... add a dash
|
||||
(push #\- res)
|
||||
(setf newcase :other))
|
||||
|
||||
|
|
@ -65,26 +296,191 @@
|
|||
else
|
||||
(push char res)
|
||||
(setf lastcase :other)))
|
||||
(read-from-string (coerce (nreverse res) 'string))))
|
||||
(read-symbol-from-string (coerce (nreverse res) 'string))))
|
||||
|
||||
(defun id-convert-and-export (name &rest kwargs)
|
||||
(multiple-value-bind (symbol package)
|
||||
(apply *swig-identifier-converter* name kwargs)
|
||||
(let ((args (list (if (consp symbol) (cadr symbol) symbol)
|
||||
(or package *package*))))
|
||||
(apply #'export args)
|
||||
(pushnew args swig::*swig-export-list*))
|
||||
symbol))
|
||||
|
||||
(defmacro swig-insert-id (name namespace &key (type :type) class)
|
||||
`(let ((*package* (find-package ,(package-name-for-namespace namespace))))
|
||||
(id-convert-and-export ,name :type ,type :class ,class)))
|
||||
|
||||
(defmacro swig-defconstant (string value)
|
||||
(let ((symbol (funcall *swig-identifier-converter* string :type :constant)))
|
||||
(let ((symbol (id-convert-and-export string :type :constant)))
|
||||
`(eval-when (compile load eval)
|
||||
(defconstant ,symbol ,value)
|
||||
(export (quote ,symbol)))))
|
||||
(defconstant ,symbol ,value))))
|
||||
|
||||
(defmacro swig-defun (name &rest rest)
|
||||
(let ((symbol (funcall *swig-identifier-converter* name :type :operator)))
|
||||
(defun maybe-reorder-args (funcname arglist)
|
||||
;; in the foreign setter function the new value will be the last argument
|
||||
;; in Lisp it needs to be the first
|
||||
(if (consp funcname)
|
||||
(append (last arglist) (butlast arglist))
|
||||
arglist))
|
||||
|
||||
(defun maybe-return-value (funcname arglist)
|
||||
;; setf functions should return the new value
|
||||
(when (consp funcname)
|
||||
`(,(if (consp (car arglist))
|
||||
(caar arglist)
|
||||
(car arglist)))))
|
||||
|
||||
(defun swig-anyvarargs-p (arglist)
|
||||
(member :SWIG__varargs_ arglist))
|
||||
|
||||
(defmacro swig-defun ((name &optional (mangled-name name)
|
||||
&key (type :operator) class arity)
|
||||
ffargs kwargs
|
||||
&body body)
|
||||
(let* ((symbol (id-convert-and-export name :type type
|
||||
:arity arity :class class))
|
||||
(mangle (if* (eq name mangled-name)
|
||||
then (id-convert-and-export
|
||||
(cond ((eq type :setter) (format nil "~A-set" name))
|
||||
((eq type :getter) (format nil "~A-get" name))
|
||||
(t name))
|
||||
:type :ff-operator :arity arity :class class)
|
||||
else (intern mangled-name)))
|
||||
(defun-args (maybe-reorder-args
|
||||
symbol
|
||||
(mapcar #'car (and (not (equal ffargs '(:void)))
|
||||
ffargs))
|
||||
))
|
||||
)
|
||||
(when (swig-anyvarargs-p ffargs)
|
||||
(setq ffargs '()))
|
||||
`(eval-when (compile load eval)
|
||||
(excl::compiler-let ((*record-xref-info* nil))
|
||||
(ff:def-foreign-call (,symbol ,name) ,@rest)
|
||||
(export (quote ,symbol))))))
|
||||
(ff:def-foreign-call (,mangle ,mangled-name) ,ffargs ,@kwargs))
|
||||
(macrolet ((swig-ff-call (&rest args)
|
||||
(cons ',mangle args)))
|
||||
(defun ,symbol ,defun-args
|
||||
,@body
|
||||
,@(maybe-return-value symbol defun-args))))))
|
||||
|
||||
(defmacro swig-def-foreign-type (name &rest rest)
|
||||
(let ((symbol (funcall *swig-identifier-converter* name :type :type)))
|
||||
(defmacro swig-defmethod ((name &optional (mangled-name name)
|
||||
&key (type :operator) class arity)
|
||||
ffargs kwargs
|
||||
&body body)
|
||||
(let* ((symbol (id-convert-and-export name :type type
|
||||
:arity arity :class class))
|
||||
(mangle (intern mangled-name))
|
||||
(defmethod-args (maybe-reorder-args
|
||||
symbol
|
||||
(unless (equal ffargs '(:void))
|
||||
(loop for (name dispatch) in ffargs
|
||||
collect `(,name ,dispatch)))))
|
||||
(ffargs (if (equal ffargs '(:void))
|
||||
ffargs
|
||||
(loop for (name nil . ffi) in ffargs
|
||||
collect `(,name ,@ffi)))))
|
||||
`(eval-when (compile load eval)
|
||||
(excl::compiler-let ((*record-xref-info* nil))
|
||||
(ff:def-foreign-call (,mangle ,mangled-name) ,ffargs ,@kwargs))
|
||||
(macrolet ((swig-ff-call (&rest args)
|
||||
(cons ',mangle args)))
|
||||
(defmethod ,symbol ,defmethod-args
|
||||
,@body
|
||||
,@(maybe-return-value symbol defmethod-args))))))
|
||||
|
||||
(defmacro swig-dispatcher ((name &key (type :operator) class arities))
|
||||
(let ((symbol (id-convert-and-export name
|
||||
:type type :class class)))
|
||||
`(eval-when (compile load eval)
|
||||
(defun ,symbol (&rest args)
|
||||
(case (length args)
|
||||
,@(loop for arity in arities
|
||||
for symbol-n = (id-convert-and-export name
|
||||
:type type :class class :arity arity)
|
||||
collect `(,arity (apply #',symbol-n args)))
|
||||
(t (error "No applicable wrapper-methods for foreign call ~a with args ~a of classes ~a" ',symbol args (mapcar #'(lambda (x) (class-name (class-of x))) args)))
|
||||
)))))
|
||||
|
||||
(defmacro swig-def-foreign-stub (name)
|
||||
(let ((lsymbol (id-convert-and-export name :type :class))
|
||||
(symbol (id-convert-and-export name :type :type)))
|
||||
`(eval-when (compile load eval)
|
||||
(ff:def-foreign-type ,symbol (:class ))
|
||||
(defclass ,lsymbol (ff:foreign-pointer) ()))))
|
||||
|
||||
(defmacro swig-def-foreign-class (name supers &rest rest)
|
||||
(let ((lsymbol (id-convert-and-export name :type :class))
|
||||
(symbol (id-convert-and-export name :type :type)))
|
||||
`(eval-when (compile load eval)
|
||||
(ff:def-foreign-type ,symbol ,@rest)
|
||||
(export (quote ,symbol)))))
|
||||
(defclass ,lsymbol ,supers
|
||||
((foreign-type :initform ',symbol :initarg :foreign-type
|
||||
:accessor foreign-pointer-type))))))
|
||||
|
||||
(defmacro swig-def-foreign-type (name &rest rest)
|
||||
(let ((symbol (id-convert-and-export name :type :type)))
|
||||
`(eval-when (compile load eval)
|
||||
(ff:def-foreign-type ,symbol ,@rest))))
|
||||
|
||||
(defmacro swig-def-synonym-type (synonym of ff-synonym)
|
||||
`(eval-when (compile load eval)
|
||||
(setf (find-class ',synonym) (find-class ',of))
|
||||
(ff:def-foreign-type ,ff-synonym (:struct ))))
|
||||
|
||||
(defun package-name-for-namespace (namespace)
|
||||
(list-to-delimited-string
|
||||
(cons *swig-module-name*
|
||||
(mapcar #'(lambda (name)
|
||||
(string
|
||||
(funcall *swig-identifier-converter*
|
||||
name
|
||||
:type :namespace)))
|
||||
namespace))
|
||||
"."))
|
||||
|
||||
(defmacro swig-defpackage (namespace)
|
||||
(let* ((parent-namespaces (maplist #'reverse (cdr (reverse namespace))))
|
||||
(parent-strings (mapcar #'package-name-for-namespace
|
||||
parent-namespaces))
|
||||
(string (package-name-for-namespace namespace)))
|
||||
`(eval-when (compile load eval)
|
||||
(defpackage ,string
|
||||
(:use :common-lisp :ff :swig :excl
|
||||
,@parent-strings ,*swig-module-name*)))))
|
||||
|
||||
(defmacro swig-in-package (namespace)
|
||||
`(eval-when (compile load eval)
|
||||
(in-package ,(package-name-for-namespace namespace))))
|
||||
|
||||
(defmacro swig-defvar (name mangled-name &key type)
|
||||
(let ((symbol (id-convert-and-export name :type type)))
|
||||
`(eval-when (compile load eval)
|
||||
(ff:def-foreign-variable (,symbol ,mangled-name)))))
|
||||
|
||||
) ;; eval-when
|
||||
|
||||
(eval-when (compile eval)
|
||||
(flet ((starts-with-p (str prefix)
|
||||
(and (>= (length str) (length prefix))
|
||||
(string= str prefix :end1 (length prefix)))))
|
||||
(export (loop for sym being each present-symbol of *package*
|
||||
when (or (starts-with-p (symbol-name sym) (symbol-name :swig-))
|
||||
(starts-with-p (symbol-name sym) (symbol-name :identifier-convert-)))
|
||||
collect sym))))
|
||||
|
||||
(in-package #.*swig-module-name*)
|
||||
%}
|
||||
|
||||
|
||||
|
||||
%{
|
||||
|
||||
#ifdef __cplusplus
|
||||
# define EXTERN extern "C"
|
||||
#else
|
||||
# define EXTERN extern
|
||||
#endif
|
||||
|
||||
#define EXPORT EXTERN SWIGEXPORT
|
||||
|
||||
%}
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue