mirror of https://github.com/swig/swig
C chapter added, HTML corrections
Added C to experimental target languages section Usual html fixes and heading updates after running make
This commit is contained in:
William S Fulton
parent
395be435a8
commit
a9784d98ec
|
|
@ -5,30 +5,47 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="C"></a>36 SWIG and C as the target language</H1>
|
||||
<H1><a name="C">38 SWIG and C as the target language</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#C_overview">Overview</a>
|
||||
<ul>
|
||||
<li><a href="#C_shortcomings">Known C++ Shortcomings in Generated C API</a>
|
||||
</ul>
|
||||
<li><a href="#C_preliminaries">Preliminaries</a>
|
||||
<ul>
|
||||
<li><a href="#C_running_swig">Running SWIG</a>
|
||||
<li><a href="#C_commandline">Command line options</a>
|
||||
<li><a href="#C_dynamic">Compiling dynamic module</a>
|
||||
<li><a href="#C_using_module">Using generated module</a>
|
||||
<li><a href="#C_dynamic">Compiling a dynamic module</a>
|
||||
<li><a href="#C_using_module">Using the generated module</a>
|
||||
</ul>
|
||||
<li><a href="#C_basic_c_wrapping">Basic C wrapping</a>
|
||||
<ul>
|
||||
<li><a href="#C_functions">Functions</a>
|
||||
<li><a href="#C_variables">Variables</a>
|
||||
<li><a href="#C_enums">Enums</a>
|
||||
</ul>
|
||||
<li><a href="#C_basic_cpp_wrapping">Basic C++ wrapping</a>
|
||||
<ul>
|
||||
<li><a href="#C_enums">Enums</a>
|
||||
<li><a href="#C_classes">Classes</a>
|
||||
</ul>
|
||||
<li><a href="#C_developer">Backend Developer Documentation</a>
|
||||
<li><a href="#C_typemaps">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="#C_typemaps_walkthrough">C Typemaps, a Code Generation Walkthrough</a>
|
||||
<ul>
|
||||
<li><a href="#C_walkthrough_interface">The Interface</a>
|
||||
<li><a href="#C_walkthrough_wrapper">The Wrapper</a>
|
||||
<li><a href="#C_walkthrough_proxy">The Proxy</a>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><a href="#C_exceptions">Exception handling</a>
|
||||
<li><a href="#C_cxx_wrappers">C++ wrappers</a>
|
||||
<li><a href="#C_cxx_wrappers">C++ Wrappers</a>
|
||||
<ul>
|
||||
<li><a href="#C_additional_possibilities">Additional customization possibilities</a>
|
||||
<li><a href="#C_exception_handling">Exception handling</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -44,7 +61,7 @@ This chapter describes SWIG's support for creating ISO C wrappers. This module h
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="C_overview"></a>36.1 Overview</H2>
|
||||
<H2><a name="C_overview">38.1 Overview</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -62,17 +79,19 @@ With wrapper interfaces generated by SWIG, it is easy to use the functionality o
|
|||
Flattening C++ language constructs into a set of C-style functions obviously comes with many limitations and inconveniences, but this module is actually also capable of generating C++ wrappers defined completely inline using the C functions, thus wrapping the original C++ library API in another, similar C++ API. Contrary to the natural initial reaction, this is far from being completely pointless, as wrapping C++ API in this way avoids all problems due to C++ ABI issues, e.g. it is now possible to use the original C++ API using a different C++ compiler, or a different version of the same compiler, or even the same compiler, but with different compilation options affecting the ABI. The C++ wrapper API is not identical to the original one, but strives to be as close to it as possible.
|
||||
</p>
|
||||
|
||||
<H3>Known C++ Shortcomings in Generated C API:</H3>
|
||||
<H3><a name="C_shortcomings">38.1.1 Known C++ Shortcomings in Generated C API</a></H3>
|
||||
|
||||
|
||||
<ul>
|
||||
<li>Enums with a context like class or namespace are broken</li>
|
||||
<li>Global variables are not supported</li>
|
||||
<li>Qualifiers are stripped</li>
|
||||
<li>Vararg functions are not supported.</li>
|
||||
</ul>
|
||||
<H2><a name="C_preliminaries"></a>36.2 Preliminaries</H2>
|
||||
<H2><a name="C_preliminaries">38.2 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<H3><a name="C_running_swig"></a>36.2.1 Running SWIG</H3>
|
||||
<H3><a name="C_running_swig">38.2.1 Running SWIG</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -107,7 +126,7 @@ $ swig -c++ -c example.i
|
|||
|
||||
<p>
|
||||
Note that <tt>-c</tt> is the option specifying the <b>target</b> language and <tt>-c++</tt> controls what the <b>input</b> language is.
|
||||
<p>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This will generate an <tt>example_wrap.c</tt> file or, in the latter case, <tt>example_wrap.cxx</tt> file, along with <tt>example_wrap.h</tt> (the same extension is used in both C and C++ cases for the last one). The names of the files are derived from the name of the input file by default, but can be changed using the <tt>-o</tt> and <tt>-oh</tt> options common to all language modules.
|
||||
|
|
@ -117,7 +136,7 @@ This will generate an <tt>example_wrap.c</tt> file or, in the latter case, <tt>e
|
|||
The <tt>xxx_wrap.c</tt> file contains the wrapper functions, which perform the main functionality of SWIG: each of the wrappers translates the input arguments from C to C++, makes calls to the original functions and marshals C++ output back to C data. The <tt>xxx_wrap.h</tt> header file contains the declarations of these functions as well as global variables.
|
||||
</p>
|
||||
|
||||
<H3><a name="C_commandline"></a>36.2.2 Command line options</H3>
|
||||
<H3><a name="C_commandline">38.2.2 Command line options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -150,7 +169,7 @@ $ swig -c -help
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="C_dynamic"></a>36.2.3 Compiling a dynamic module</H3>
|
||||
<H3><a name="C_dynamic">38.2.3 Compiling a dynamic module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -177,7 +196,7 @@ $ g++ -shared example_wrap.o -o libexample.so
|
|||
Now the shared library module is ready to use. Note that the name of the generated module is important: is should be prefixed with <tt>lib</tt> on Unix, and have the specific extension, like <tt>.dll</tt> for Windows or <tt>.so</tt> for Unix systems.
|
||||
</p>
|
||||
|
||||
<H3><a name="C_using_module"></a>36.2.4 Using the generated module</H3>
|
||||
<H3><a name="C_using_module">38.2.4 Using the generated module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -192,7 +211,7 @@ $ gcc runme.c -L. -lexample -o runme
|
|||
This will compile the application code (<tt>runme.c</tt>) and link it against the generated shared module. Following the <tt>-L</tt> option is the path to the directory containing the shared module. The output executable is ready to use. The last thing to do is to supply to the operating system the information of location of our module. This is system dependant, for instance Unix systems look for shared modules in certain directories, like <tt>/usr/lib</tt>, and additionally we can set the environment variable <tt>LD_LIBRARY_PATH</tt> (Unix) or <tt>PATH</tt> (Windows) for other directories.
|
||||
</p>
|
||||
|
||||
<H2><a name="C_basic_c_wrapping"></a>36.3 Basic C wrapping</H2>
|
||||
<H2><a name="C_basic_c_wrapping">38.3 Basic C wrapping</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -209,7 +228,7 @@ It is also possible to output arbitrary additional code into the generated heade
|
|||
%}
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="C_functions"></a>36.3.1 Functions</H3>
|
||||
<H3><a name="C_functions">38.3.1 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -273,7 +292,7 @@ int _wrap_gcd(int arg1, int arg2) {
|
|||
This time calling <tt>gcd</tt> with negative value argument will trigger an error message. This can save you time writing all the constraint checking code by hand.
|
||||
</p>
|
||||
|
||||
<H3><a name="C_variables"></a>36.3.2 Variables</H3>
|
||||
<H3><a name="C_variables">38.3.2 Variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -311,7 +330,7 @@ ms.x = 123;
|
|||
ms.d = 123.123;
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="C_basic_cpp_wrapping"></a>36.4 Basic C++ wrapping</H2>
|
||||
<H2><a name="C_basic_cpp_wrapping">38.4 Basic C++ wrapping</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -320,6 +339,7 @@ The main reason of having the C module in SWIG is to be able to access C++ from
|
|||
|
||||
<p>
|
||||
By default, SWIG attempts to build a natural C interface to your C/C++ code.
|
||||
</p>
|
||||
<table BORDER summary="Generated C representation of C++">
|
||||
<tr>
|
||||
<th>C++ Type</th>
|
||||
|
|
@ -343,10 +363,13 @@ By default, SWIG attempts to build a natural C interface to your C/C++ code.
|
|||
</pre></div></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<p>
|
||||
This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="C_enums"></a>36.3.3 Enums</H3>
|
||||
<H3><a name="C_enums">38.4.1 Enums</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
C enums and unscoped C++ enums are simply copied to the generated code and both the enum itself and its elements keep the same name as in the original code unless <tt>-namespace</tt> option is used or <tt>nspace</tt> feature is enabled, in which case the prefix corresponding to the specified namespace is used.
|
||||
|
|
@ -356,7 +379,7 @@ For scoped C++11 enums, the enum name itself is used as an additional prefix.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="C_classes"></a>36.4.1 Classes</H3>
|
||||
<H3><a name="C_classes">38.4.2 Classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -434,9 +457,11 @@ radius: 1.500000
|
|||
area: 7.068583
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="C_developer"></a>Backend Developer Documentation</H2>
|
||||
<H2><a name="C_developer">38.5 Backend Developer Documentation</a></H2>
|
||||
|
||||
|
||||
<H2><a name="C_typemaps">38.6 Typemaps</a></H2>
|
||||
|
||||
<H2><a name="C_typemaps"></a>Typemaps</H2>
|
||||
|
||||
<table BORDER summary="C Backend Typemaps">
|
||||
<tr>
|
||||
|
|
@ -504,7 +529,8 @@ SwigObj* MyClass_do(SwigObj *carg1) {
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H3>C Typemaps, a Code Generation Walkthrough</H3>
|
||||
<H3><a name="C_typemaps_walkthrough">38.6.1 C Typemaps, a Code Generation Walkthrough</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
To get a better idea of which typemap is used for which generated code, have a look at the following 'walk through'.
|
||||
|
|
@ -514,7 +540,9 @@ To get a better idea of which typemap is used for which generated code, have a l
|
|||
Let's assume we have the following C++ interface file, we'd like to generate code for:
|
||||
</p>
|
||||
|
||||
<H4>The Interface</H4>
|
||||
<H4><a name="C_walkthrough_interface">38.6.1.1 The Interface</a></H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
%module example
|
||||
|
||||
|
|
@ -550,7 +578,8 @@ SomeIntTemplateClass * SomeIntTemplateClass_new();
|
|||
void SomeIntTemplateClass_delete(SomeIntTemplateClass * carg1);
|
||||
</pre></div>
|
||||
|
||||
<H4>The Wrapper</H4>
|
||||
<H4><a name="C_walkthrough_wrapper">38.6.1.2 The Wrapper</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
We'll examine the generation of the wrapper function first.
|
||||
|
|
@ -693,7 +722,8 @@ replaced with either <tt>0</tt> or nothing, depending on whether the function
|
|||
has a non-void return value or not.
|
||||
</p>
|
||||
|
||||
<H4>The Proxy</H4>
|
||||
<H4><a name="C_walkthrough_proxy">38.6.1.3 The Proxy</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
Compared to the wrapper code generation, the header code is very simple.
|
||||
|
|
@ -719,13 +749,15 @@ SomeIntTemplateClass * SomeIntTemplateClass_new();
|
|||
void SomeIntTemplateClass_delete(SomeIntTemplateClass * carg1);
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="C_exceptions"></a>36.5 Exception handling</H2>
|
||||
<H2><a name="C_exceptions">38.7 Exception handling</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
Any call to a C++ function may throw an exception, which cannot be caught by C code. Instead, the special <tt>SWIG_CException_get_pending()</tt> function must be called to check for this. If it returns a non-null pointer, <tt>SWIG_CException_msg_get()</tt> can be called to retrieve the error message associated with the exception. Finally, <tt>SWIG_CException_reset_pending()</tt> must be called to free the exception object and reset the current pending exception. Note that exception handling is much simpler when using C++, rather than C, wrappers, see sections 36.6.2.
|
||||
</p>
|
||||
|
||||
<H2><a name="C_cxx_wrappers"></a>36.6 C++ Wrappers</H2>
|
||||
<H2><a name="C_cxx_wrappers">38.8 C++ Wrappers</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
When <tt>-c++</tt> command line option is used (and <tt>-nocxx</tt> one is not), the header file generated by SWIG will also contain the declarations of C++ wrapper functions and classes mirroring the original API. All C++ wrappers are fully inline, i.e. don't need to be compiled separately, and are always defined inside the namespace (or nested namespaces) specified by <tt>-namespace</tt> command-line option or the namespace with the same name as the SWIG module name if this option is not specified.
|
||||
|
|
@ -748,7 +780,8 @@ Other ones are due to things that could be supported but haven't been implemente
|
|||
<li>Only enums using <tt>int</tt> (or smaller type) as underlying type are supported.</li>
|
||||
</ul>
|
||||
|
||||
<H3>36.6.1 Additional customization possibilities</H3>
|
||||
<H3><a name="C_additional_possibilities">38.8.1 Additional customization possibilities</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
Generated C++ code can be customized by inserting custom code in the following sections:
|
||||
|
|
@ -767,7 +800,8 @@ The following features are taken into account when generating C++ wrappers:
|
|||
<li><tt>cxxignore</tt> May be set to skip generation of C++ wrappers for the given function or class, while still generating C wrappers for them.</li>
|
||||
</ul>
|
||||
|
||||
<H3>36.6.2 Exception handling</H3>
|
||||
<H3><a name="C_exception_handling">38.8.2 Exception handling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
Exception handling in C++ is more natural, as the exceptions are re-thrown when using C++ wrappers and so can be caught, as objects of the special <tt>SWIG_CException</tt> type, using the usual <tt>try/catch</tt> statement. The objects of <tt>SWIG_CException</tt> class have <tt>code()</tt> and <tt>msg()</tt> methods, with the latter returning the error message associated with the exception.
|
||||
|
|
|
|||
|
|
@ -466,6 +466,10 @@
|
|||
<li><a href="Library.html#Library_nn11">Using %newobject to release memory</a>
|
||||
<li><a href="Library.html#Library_nn12">cstring.i</a>
|
||||
</ul>
|
||||
<li><a href="Library.html#Library_c_standard_library">C standard library</a>
|
||||
<ul>
|
||||
<li><a href="Library.html#Library_complex">Complex floating types</a>
|
||||
</ul>
|
||||
<li><a href="Library.html#Library_stl_cpp_library">STL/C++ library</a>
|
||||
<ul>
|
||||
<li><a href="Library.html#Library_std_string">std::string</a>
|
||||
|
|
@ -713,6 +717,13 @@
|
|||
<li><a href="Doxygen.html#Doxygen_python_unsupported_tags">Unsupported tags</a>
|
||||
<li><a href="Doxygen.html#Doxygen_python_further_details">Further details</a>
|
||||
</ul>
|
||||
<li><a href="Doxygen.html#Doxygen_to_csharpXml">Doxygen to XML Csharp documentation</a>
|
||||
<ul>
|
||||
<li><a href="Doxygen.html#Doxygen_csharp_basic_example">Basic example</a>
|
||||
<li><a href="Doxygen.html#Doxygen_csharp_tags">CSharp tags</a>
|
||||
<li><a href="Doxygen.html#Doxygen_csharp_unsupported_tags">Unsupported tags</a>
|
||||
<li><a href="Doxygen.html#Doxygen_csharp_further_details">Further details</a>
|
||||
</ul>
|
||||
<li><a href="Doxygen.html#Doxygen_troubleshooting">Troubleshooting</a>
|
||||
<ul>
|
||||
<li><a href="Doxygen.html#troubleshooting_ifndef">Problem with conditional compilation</a>
|
||||
|
|
@ -1862,7 +1873,53 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Mzscheme.html#Mzscheme">38 SWIG and MzScheme/Racket</a></h3>
|
||||
<h3><a href="C.html#C">38 SWIG and C as the target language</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="C.html#C_overview">Overview</a>
|
||||
<ul>
|
||||
<li><a href="C.html#C_shortcomings">Known C++ Shortcomings in Generated C API</a>
|
||||
</ul>
|
||||
<li><a href="C.html#C_preliminaries">Preliminaries</a>
|
||||
<ul>
|
||||
<li><a href="C.html#C_running_swig">Running SWIG</a>
|
||||
<li><a href="C.html#C_commandline">Command line options</a>
|
||||
<li><a href="C.html#C_dynamic">Compiling a dynamic module</a>
|
||||
<li><a href="C.html#C_using_module">Using the generated module</a>
|
||||
</ul>
|
||||
<li><a href="C.html#C_basic_c_wrapping">Basic C wrapping</a>
|
||||
<ul>
|
||||
<li><a href="C.html#C_functions">Functions</a>
|
||||
<li><a href="C.html#C_variables">Variables</a>
|
||||
</ul>
|
||||
<li><a href="C.html#C_basic_cpp_wrapping">Basic C++ wrapping</a>
|
||||
<ul>
|
||||
<li><a href="C.html#C_enums">Enums</a>
|
||||
<li><a href="C.html#C_classes">Classes</a>
|
||||
</ul>
|
||||
<li><a href="C.html#C_developer">Backend Developer Documentation</a>
|
||||
<li><a href="C.html#C_typemaps">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="C.html#C_typemaps_walkthrough">C Typemaps, a Code Generation Walkthrough</a>
|
||||
<ul>
|
||||
<li><a href="C.html#C_walkthrough_interface">The Interface</a>
|
||||
<li><a href="C.html#C_walkthrough_wrapper">The Wrapper</a>
|
||||
<li><a href="C.html#C_walkthrough_proxy">The Proxy</a>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><a href="C.html#C_exceptions">Exception handling</a>
|
||||
<li><a href="C.html#C_cxx_wrappers">C++ Wrappers</a>
|
||||
<ul>
|
||||
<li><a href="C.html#C_additional_possibilities">Additional customization possibilities</a>
|
||||
<li><a href="C.html#C_exception_handling">Exception handling</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Mzscheme.html#Mzscheme">39 SWIG and MzScheme/Racket</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1874,7 +1931,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ocaml.html#Ocaml">39 SWIG and OCaml</a></h3>
|
||||
<h3><a href="Ocaml.html#Ocaml">40 SWIG and OCaml</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1929,7 +1986,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Extending.html#Extending">40 Extending SWIG to support new languages</a></h3>
|
||||
<h3><a href="Extending.html#Extending">41 Extending SWIG to support new languages</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
|
|||
|
|
@ -37,10 +37,10 @@
|
|||
<li><a href="#Doxygen_python_unsupported_tags">Unsupported tags</a>
|
||||
<li><a href="#Doxygen_python_further_details">Further details</a>
|
||||
</ul>
|
||||
<li><a href="#Doxygen_to_csharpXml">Doxygen to CSharp XML</a>
|
||||
<li><a href="#Doxygen_to_csharpXml">Doxygen to XML Csharp documentation</a>
|
||||
<ul>
|
||||
<li><a href="#Doxygen_csharp_basic_example">Basic example</a>
|
||||
<li><a href="#Doxygen_csharp_tags">CSharp XML tags</a>
|
||||
<li><a href="#Doxygen_csharp_tags">CSharp tags</a>
|
||||
<li><a href="#Doxygen_csharp_unsupported_tags">Unsupported tags</a>
|
||||
<li><a href="#Doxygen_csharp_further_details">Further details</a>
|
||||
</ul>
|
||||
|
|
@ -2119,7 +2119,6 @@ comment, the whole comment block is ignored:
|
|||
<H3><a name="Doxygen_csharp_further_details">18.5.4 Further details</a></H3>
|
||||
|
||||
|
||||
|
||||
<H2><a name="Doxygen_troubleshooting">18.6 Troubleshooting</a></H2>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Extending">40 Extending SWIG to support new languages</a></H1>
|
||||
<H1><a name="Extending">41 Extending SWIG to support new languages</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -81,7 +81,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="Extending_nn2">40.1 Introduction</a></H2>
|
||||
<H2><a name="Extending_nn2">41.1 Introduction</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -97,7 +97,7 @@ Also, this chapter is not meant to be a hand-holding tutorial. As a starting po
|
|||
you should probably look at one of SWIG's existing modules.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn3">40.2 Prerequisites</a></H2>
|
||||
<H2><a name="Extending_nn3">41.2 Prerequisites</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -127,7 +127,7 @@ obvious, but almost all SWIG directives as well as the low-level generation of
|
|||
wrapper code are driven by C++ datatypes.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn4">40.3 The Big Picture</a></H2>
|
||||
<H2><a name="Extending_nn4">41.3 The Big Picture</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -164,7 +164,7 @@ role in making the system work. For example, both typemaps and declaration anno
|
|||
based on pattern matching and interact heavily with the underlying type system.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn5">40.4 Execution Model</a></H2>
|
||||
<H2><a name="Extending_nn5">41.4 Execution Model</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -209,7 +209,7 @@ latter stage of compilation.
|
|||
The next few sections briefly describe some of these stages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn6">40.4.1 Preprocessing</a></H3>
|
||||
<H3><a name="Extending_nn6">41.4.1 Preprocessing</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -290,7 +290,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">40.4.2 Parsing</a></H3>
|
||||
<H3><a name="Extending_nn7">41.4.2 Parsing</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -391,7 +391,7 @@ returning a <tt>foo</tt> and taking types <tt>a</tt> and <tt>b</tt> as
|
|||
arguments).
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn8">40.4.3 Parse Trees</a></H3>
|
||||
<H3><a name="Extending_nn8">41.4.3 Parse Trees</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -679,7 +679,7 @@ debug-module stage 1
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn9">40.4.4 Attribute namespaces</a></H3>
|
||||
<H3><a name="Extending_nn9">41.4.4 Attribute namespaces</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -698,7 +698,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">40.4.5 Symbol Tables</a></H3>
|
||||
<H3><a name="Extending_nn10">41.4.5 Symbol Tables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -786,7 +786,7 @@ example.i:5. Previous declaration is foo_i(int )
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn11">40.4.6 The %feature directive</a></H3>
|
||||
<H3><a name="Extending_nn11">41.4.6 The %feature directive</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -841,7 +841,7 @@ For example, the exception code above is simply
|
|||
stored without any modifications.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn12">40.4.7 Code Generation</a></H3>
|
||||
<H3><a name="Extending_nn12">41.4.7 Code Generation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -963,7 +963,7 @@ public :
|
|||
The role of these functions is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn13">40.4.8 SWIG and XML</a></H3>
|
||||
<H3><a name="Extending_nn13">41.4.8 SWIG and XML</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -976,7 +976,7 @@ internal data structures, it may be useful to keep XML in the back of
|
|||
your mind as a model.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn14">40.5 Primitive Data Structures</a></H2>
|
||||
<H2><a name="Extending_nn14">41.5 Primitive Data Structures</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1022,7 +1022,7 @@ typedef Hash Typetab;
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn15">40.5.1 Strings</a></H3>
|
||||
<H3><a name="Extending_nn15">41.5.1 Strings</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1168,7 +1168,7 @@ At most one of <tt>DOH_REPLACE_ANY</tt> and <tt>DOH_REPLACE_FIRST</tt> should be
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn16">40.5.2 Hashes</a></H3>
|
||||
<H3><a name="Extending_nn16">41.5.2 Hashes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1253,7 +1253,7 @@ Returns the list of sorted hash table keys.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn17">40.5.3 Lists</a></H3>
|
||||
<H3><a name="Extending_nn17">41.5.3 Lists</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1342,7 +1342,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">40.5.4 Common operations</a></H3>
|
||||
<H3><a name="Extending_nn18">41.5.4 Common operations</a></H3>
|
||||
|
||||
|
||||
The following operations are applicable to all datatypes.
|
||||
|
|
@ -1397,7 +1397,7 @@ objects and report errors.
|
|||
Gets the line number associated with <tt>x</tt>.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn19">40.5.5 Iterating over Lists and Hashes</a></H3>
|
||||
<H3><a name="Extending_nn19">41.5.5 Iterating over Lists and Hashes</a></H3>
|
||||
|
||||
|
||||
To iterate over the elements of a list or a hash table, the following functions are used:
|
||||
|
|
@ -1442,7 +1442,7 @@ for (j = First(j); j.item; j= Next(j)) {
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn20">40.5.6 I/O</a></H3>
|
||||
<H3><a name="Extending_nn20">41.5.6 I/O</a></H3>
|
||||
|
||||
|
||||
Special I/O functions are used for all internal I/O. These operations
|
||||
|
|
@ -1576,7 +1576,7 @@ Printf(f, "%s\n", s);
|
|||
Similarly, the preprocessor and parser all operate on string-files.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn21">40.6 Navigating and manipulating parse trees</a></H2>
|
||||
<H2><a name="Extending_nn21">41.6 Navigating and manipulating parse trees</a></H2>
|
||||
|
||||
|
||||
Parse trees are built as collections of hash tables. Each node is a hash table in which
|
||||
|
|
@ -1710,7 +1710,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">40.7 Working with attributes</a></H2>
|
||||
<H2><a name="Extending_nn22">41.7 Working with attributes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1827,7 +1827,7 @@ the attribute is optional. <tt>Swig_restore()</tt> must always be called after
|
|||
function.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn23">40.8 Type system</a></H2>
|
||||
<H2><a name="Extending_nn23">41.8 Type system</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1836,7 +1836,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">40.8.1 String encoding of types</a></H3>
|
||||
<H3><a name="Extending_nn24">41.8.1 String encoding of types</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1937,7 +1937,7 @@ make the final type, the two parts are just joined together using
|
|||
string concatenation.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn25">40.8.2 Type construction</a></H3>
|
||||
<H3><a name="Extending_nn25">41.8.2 Type construction</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2106,7 +2106,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">40.8.3 Type tests</a></H3>
|
||||
<H3><a name="Extending_nn26">41.8.3 Type tests</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2193,7 +2193,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">40.8.4 Typedef and inheritance</a></H3>
|
||||
<H3><a name="Extending_nn27">41.8.4 Typedef and inheritance</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2295,7 +2295,7 @@ Fully reduces <tt>ty</tt> according to typedef rules. Resulting datatype
|
|||
will consist only of primitive typenames.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn28">40.8.5 Lvalues</a></H3>
|
||||
<H3><a name="Extending_nn28">41.8.5 Lvalues</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2332,7 +2332,7 @@ Literal y; // type = 'Literal', ltype='p.char'
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn29">40.8.6 Output functions</a></H3>
|
||||
<H3><a name="Extending_nn29">41.8.6 Output functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2394,7 +2394,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">40.9 Parameters</a></H2>
|
||||
<H2><a name="Extending_nn30">41.9 Parameters</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2493,7 +2493,7 @@ included. Used to emit prototypes.
|
|||
Returns the number of required (non-optional) arguments in <tt>p</tt>.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn31">40.10 Writing a Language Module</a></H2>
|
||||
<H2><a name="Extending_nn31">41.10 Writing a Language Module</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2508,7 +2508,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">40.10.1 Execution model</a></H3>
|
||||
<H3><a name="Extending_nn32">41.10.1 Execution model</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2518,7 +2518,7 @@ the parsing of command line options, all aspects of code generation are controll
|
|||
different methods of the <tt>Language</tt> that must be defined by your module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_starting_out">40.10.2 Starting out</a></H3>
|
||||
<H3><a name="Extending_starting_out">41.10.2 Starting out</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2626,7 +2626,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">40.10.3 Command line options</a></H3>
|
||||
<H3><a name="Extending_nn34">41.10.3 Command line options</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2685,7 +2685,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">40.10.4 Configuration and preprocessing</a></H3>
|
||||
<H3><a name="Extending_nn35">41.10.4 Configuration and preprocessing</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2734,7 +2734,7 @@ an implementation file <tt>python.cxx</tt> and a configuration file
|
|||
<tt>python.swg</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn36">40.10.5 Entry point to code generation</a></H3>
|
||||
<H3><a name="Extending_nn36">41.10.5 Entry point to code generation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2792,7 +2792,7 @@ int Python::top(Node *n) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn37">40.10.6 Module I/O and wrapper skeleton</a></H3>
|
||||
<H3><a name="Extending_nn37">41.10.6 Module I/O and wrapper skeleton</a></H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to mgossage -->
|
||||
|
|
@ -2940,7 +2940,7 @@ functionWrapper : void Shape_y_set(Shape *self, double y)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn38">40.10.7 Low-level code generators</a></H3>
|
||||
<H3><a name="Extending_nn38">41.10.7 Low-level code generators</a></H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to mgossage -->
|
||||
|
|
@ -3094,7 +3094,7 @@ but without the typemaps, there is still work to do.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Extending_configuration_files">40.10.8 Configuration files</a></H3>
|
||||
<H3><a name="Extending_configuration_files">41.10.8 Configuration files</a></H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to ttn -->
|
||||
|
|
@ -3238,7 +3238,7 @@ politely displays the ignoring language message.
|
|||
</dl>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn40">40.10.9 Runtime support</a></H3>
|
||||
<H3><a name="Extending_nn40">41.10.9 Runtime support</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3247,7 +3247,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">40.10.10 Standard library files</a></H3>
|
||||
<H3><a name="Extending_nn41">41.10.10 Standard library files</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3266,7 +3266,7 @@ The following are the minimum that are usually supported:
|
|||
Please copy these and modify for any new language.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn42">40.10.11 User examples</a></H3>
|
||||
<H3><a name="Extending_nn42">41.10.11 User examples</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3295,7 +3295,7 @@ during this process, see the section on <a href="#Extending_configuration_files"
|
|||
files</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_test_suite">40.10.12 Test driven development and the test-suite</a></H3>
|
||||
<H3><a name="Extending_test_suite">41.10.12 Test driven development and the test-suite</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3354,7 +3354,7 @@ It is therefore essential that the runtime tests are written in a manner that di
|
|||
but error/exception out with an error message on stderr on failure.
|
||||
</p>
|
||||
|
||||
<H4><a name="Extending_running_test_suite">40.10.12.1 Running the test-suite</a></H4>
|
||||
<H4><a name="Extending_running_test_suite">41.10.12.1 Running the test-suite</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3548,7 +3548,7 @@ It can be run in the same way as the other language test-suites, replacing [lang
|
|||
The test cases used and the way it works is described in <tt>Examples/test-suite/errors/Makefile.in</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn43">40.10.13 Documentation</a></H3>
|
||||
<H3><a name="Extending_nn43">41.10.13 Documentation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3580,7 +3580,7 @@ Some topics that you'll want to be sure to address include:
|
|||
if available.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Extending_coding_style_guidelines">40.10.14 Coding style guidelines</a></H3>
|
||||
<H3><a name="Extending_coding_style_guidelines">41.10.14 Coding style guidelines</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3605,7 +3605,7 @@ should be avoided as unlike the SWIG developers, users will never have consisten
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Extending_language_status">40.10.15 Target language status</a></H3>
|
||||
<H3><a name="Extending_language_status">41.10.15 Target language status</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3614,7 +3614,7 @@ the <a href="Introduction.html#Introduction_target_languages">Target language in
|
|||
This section provides more details on how this status is given.
|
||||
</p>
|
||||
|
||||
<H4><a name="Extending_supported_status">40.10.15.1 Supported status</a></H4>
|
||||
<H4><a name="Extending_supported_status">41.10.15.1 Supported status</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3661,7 +3661,7 @@ A target language is given the 'Supported' status when
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H4><a name="Extending_experimental_status">40.10.15.2 Experimental status</a></H4>
|
||||
<H4><a name="Extending_experimental_status">41.10.15.2 Experimental status</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3726,7 +3726,7 @@ Some minimum requirements and notes about languages with the 'Experimental' stat
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Extending_prerequisites">40.10.16 Prerequisites for adding a new language module to the SWIG distribution</a></H3>
|
||||
<H3><a name="Extending_prerequisites">41.10.16 Prerequisites for adding a new language module to the SWIG distribution</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3790,7 +3790,7 @@ the existing tests.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Extending_debugging_options">40.11 Debugging Options</a></H2>
|
||||
<H2><a name="Extending_debugging_options">41.11 Debugging Options</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3818,7 +3818,7 @@ There are various command line options which can aid debugging a SWIG interface
|
|||
The complete list of command line options for SWIG are available by running <tt>swig -help</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn46">40.12 Guide to parse tree nodes</a></H2>
|
||||
<H2><a name="Extending_nn46">41.12 Guide to parse tree nodes</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4226,7 +4226,7 @@ extern "X" { ... } declaration.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_further_info">40.13 Further Development Information</a></H2>
|
||||
<H2><a name="Extending_further_info">41.13 Further Development Information</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -4701,23 +4701,21 @@ This requires fixing with one of two solutions:
|
|||
|
||||
|
||||
<ol>
|
||||
<p>
|
||||
<li>Change the access modifier to public for the derived class by adding the following before SWIG parses the <tt>DerivedClass</tt>:</li>
|
||||
</p>
|
||||
<li><p>Change the access modifier to public for the derived class by adding the following before SWIG parses the <tt>DerivedClass:</tt></p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%feature("java:methodmodifiers") DerivedClass::baseMethod2 "public"
|
||||
</pre>
|
||||
</div>
|
||||
</li>
|
||||
|
||||
<p>
|
||||
<li>Simply ignore the method in the derived class altogether as it cannot be used as a <tt>protected</tt> method in Java as the C++ design intended:</li>
|
||||
</p>
|
||||
<li><p>Simply ignore the method in the derived class altogether as it cannot be used as a <tt>protected</tt> method in Java as the C++ design intended:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%ignore DerivedClass::baseMethod2;
|
||||
</pre>
|
||||
</div>
|
||||
</li>
|
||||
|
||||
</ol>
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@
|
|||
</ul>
|
||||
<li><a href="#Library_c_standard_library">C standard library</a>
|
||||
<ul>
|
||||
<li><a href="#Library_complex">Complex numbers</a>
|
||||
<li><a href="#Library_complex">Complex floating types</a>
|
||||
</ul>
|
||||
<li><a href="#Library_stl_cpp_library">STL/C++ library</a>
|
||||
<ul>
|
||||
|
|
@ -1442,8 +1442,10 @@ structure or class instead.
|
|||
|
||||
<H2><a name="Library_c_standard_library">12.4 C standard library</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Library_complex">12.4.1 Complex floating types</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG has some support for complex floating types. By default the keyword
|
||||
<tt>_Complex</tt> is understood by the parser but <tt>complex</tt> is not
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Mzscheme">38 SWIG and MzScheme/Racket</a></H1>
|
||||
<H1><a name="Mzscheme">39 SWIG and MzScheme/Racket</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -25,7 +25,7 @@
|
|||
This section contains information on SWIG's support of Racket, formally known as MzScheme. SWIG works with Racket versions < 8 (Racket 8 switched to be based on a different scheme interpreter and SWIG hasn't been updated for this change).
|
||||
</p>
|
||||
|
||||
<H2><a name="MzScheme_nn2">38.1 Creating native structures</a></H2>
|
||||
<H2><a name="MzScheme_nn2">39.1 Creating native structures</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -66,7 +66,7 @@ Then in scheme, you can use regular struct access procedures like
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="MzScheme_simple">38.2 Simple example</a></H2>
|
||||
<H2><a name="MzScheme_simple">39.2 Simple example</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -167,7 +167,7 @@ Some points of interest:
|
|||
<li> The above requests mzc to create an extension using the CGC garbage-collector. The alternative -- the 3m collector -- has generally better performance, but work is still required for SWIG to emit code which is compatible with it.
|
||||
</ul>
|
||||
|
||||
<H2><a name="MzScheme_external_docs">38.3 External documentation</a></H2>
|
||||
<H2><a name="MzScheme_external_docs">39.3 External documentation</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Ocaml">39 SWIG and OCaml</a></H1>
|
||||
<H1><a name="Ocaml">40 SWIG and OCaml</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -86,7 +86,7 @@ If you're not familiar with the Objective Caml language, you can visit
|
|||
<a href="https://ocaml.org/">The Ocaml Website</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn2">39.1 Preliminaries</a></H2>
|
||||
<H2><a name="Ocaml_nn2">40.1 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -105,7 +105,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">39.1.1 Running SWIG</a></H3>
|
||||
<H3><a name="Ocaml_nn3">40.1.1 Running SWIG</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -128,7 +128,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">39.1.2 Compiling the code</a></H3>
|
||||
<H3><a name="Ocaml_nn4">40.1.2 Compiling the code</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -165,7 +165,7 @@ in C++ mode, you must:</p>
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ocaml_nn5">39.1.3 The camlp4 module</a></H3>
|
||||
<H3><a name="Ocaml_nn5">40.1.3 The camlp4 module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -241,7 +241,7 @@ let b = C_string (getenv "PATH")
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn6">39.1.4 Using your module</a></H3>
|
||||
<H3><a name="Ocaml_nn6">40.1.4 Using your module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -255,7 +255,7 @@ option to build your functions into the primitive list. This
|
|||
option is not needed when you build native code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn7">39.1.5 Compilation problems and compiling with C++</a></H3>
|
||||
<H3><a name="Ocaml_nn7">40.1.5 Compilation problems and compiling with C++</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -275,7 +275,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">39.2 The low-level Ocaml/C interface</a></H2>
|
||||
<H2><a name="Ocaml_nn8">40.2 The low-level Ocaml/C interface</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -375,7 +375,7 @@ value items pass through directly, but you must make your own type
|
|||
signature for a function that uses value in this way.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn9">39.2.1 The generated module</a></H3>
|
||||
<H3><a name="Ocaml_nn9">40.2.1 The generated module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -409,7 +409,7 @@ it describes the output SWIG will generate for class definitions.
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn10">39.2.2 Enums</a></H3>
|
||||
<H3><a name="Ocaml_nn10">40.2.2 Enums</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -472,7 +472,7 @@ val x : Enum_test.c_obj = C_enum `a
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ocaml_nn11">39.2.2.1 Enum typing in Ocaml</a></H4>
|
||||
<H4><a name="Ocaml_nn11">40.2.2.1 Enum typing in Ocaml</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -485,10 +485,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">39.2.3 Arrays</a></H3>
|
||||
<H3><a name="Ocaml_nn12">40.2.3 Arrays</a></H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn13">39.2.3.1 Simple types of bounded arrays</a></H4>
|
||||
<H4><a name="Ocaml_nn13">40.2.3.1 Simple types of bounded arrays</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -509,7 +509,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">39.2.3.2 Complex and unbounded arrays</a></H4>
|
||||
<H4><a name="Ocaml_nn14">40.2.3.2 Complex and unbounded arrays</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -522,7 +522,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">39.2.3.3 Using an object</a></H4>
|
||||
<H4><a name="Ocaml_nn15">40.2.3.3 Using an object</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -536,7 +536,7 @@ Consider writing an object when the ending condition of your array is complex,
|
|||
such as using a required sentinel, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn16">39.2.3.4 Example typemap for a function taking float * and int</a></H4>
|
||||
<H4><a name="Ocaml_nn16">40.2.3.4 Example typemap for a function taking float * and int</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -587,7 +587,7 @@ void printfloats( float *tab, int len );
|
|||
</pre></td></tr></table>
|
||||
|
||||
|
||||
<H3><a name="Ocaml_nn17">39.2.4 C++ Classes</a></H3>
|
||||
<H3><a name="Ocaml_nn17">40.2.4 C++ Classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -630,7 +630,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the
|
|||
returned value for the same object.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn18">39.2.4.1 STL vector and string Example</a></H4>
|
||||
<H4><a name="Ocaml_nn18">40.2.4.1 STL vector and string Example</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -710,7 +710,7 @@ baz
|
|||
#
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn19">39.2.4.2 C++ Class Example</a></H4>
|
||||
<H4><a name="Ocaml_nn19">40.2.4.2 C++ Class Example</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -739,7 +739,7 @@ public:
|
|||
};
|
||||
</pre></td></tr></table>
|
||||
|
||||
<H4><a name="Ocaml_nn20">39.2.4.3 Compiling the example</a></H4>
|
||||
<H4><a name="Ocaml_nn20">40.2.4.3 Compiling the example</a></H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -756,7 +756,7 @@ $ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
|
|||
-L$QTPATH/lib -cclib -lqt
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn21">39.2.4.4 Sample Session</a></H4>
|
||||
<H4><a name="Ocaml_nn21">40.2.4.4 Sample Session</a></H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -783,10 +783,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">39.2.5 Director Classes</a></H3>
|
||||
<H3><a name="Ocaml_nn22">40.2.5 Director Classes</a></H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn23">39.2.5.1 Director Introduction</a></H4>
|
||||
<H4><a name="Ocaml_nn23">40.2.5.1 Director Introduction</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -813,7 +813,7 @@ class foo {
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn24">39.2.5.2 Overriding Methods in Ocaml</a></H4>
|
||||
<H4><a name="Ocaml_nn24">40.2.5.2 Overriding Methods in Ocaml</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -841,7 +841,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">39.2.5.3 Director Usage Example</a></H4>
|
||||
<H4><a name="Ocaml_nn25">40.2.5.3 Director Usage Example</a></H4>
|
||||
|
||||
|
||||
<table border="1" bgcolor="#dddddd" summary="Director usage example">
|
||||
|
|
@ -902,7 +902,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the
|
|||
program in C++.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn26">39.2.5.4 Creating director objects</a></H4>
|
||||
<H4><a name="Ocaml_nn26">40.2.5.4 Creating director objects</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -943,7 +943,7 @@ object from causing a core dump, as long as the object is destroyed
|
|||
properly.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn27">39.2.5.5 Typemaps for directors, directorin, directorout, directorargout</a></H4>
|
||||
<H4><a name="Ocaml_nn27">40.2.5.5 Typemaps for directors, directorin, directorout, directorargout</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -954,7 +954,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">39.2.5.6 directorin typemap</a></H4>
|
||||
<H4><a name="Ocaml_nn28">40.2.5.6 directorin typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -965,7 +965,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">39.2.5.7 directorout typemap</a></H4>
|
||||
<H4><a name="Ocaml_nn29">40.2.5.7 directorout typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -976,7 +976,7 @@ for the same type, except when there are special requirements for object
|
|||
ownership, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn30">39.2.5.8 directorargout typemap</a></H4>
|
||||
<H4><a name="Ocaml_nn30">40.2.5.8 directorargout typemap</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -993,7 +993,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">39.2.6 Exceptions</a></H3>
|
||||
<H3><a name="Ocaml_nn31">40.2.6 Exceptions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1081,7 +1081,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="Ocaml_nn32">39.3 Documentation Features</a></H2>
|
||||
<H2><a name="Ocaml_nn32">40.3 Documentation Features</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1090,7 +1090,7 @@ comments (colloquially referred to as "docstrings") that can be read by
|
|||
<a href="https://caml.inria.fr/pub/docs/manual-ocaml/ocamldoc.html">OCamldoc</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn33">39.3.1 Module docstring</a></H3>
|
||||
<H3><a name="Ocaml_nn33">40.3.1 Module docstring</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -62,6 +62,7 @@ Last update : SWIG-4.3.0 (in progress)
|
|||
<H3><a name="Sections_experimental_language_modules">Experimental Language Modules Documentation</a></H3>
|
||||
|
||||
<ul>
|
||||
<li><a href="C.html#C">C target language support</a></li>
|
||||
<li><a href="Mzscheme.html#Mzscheme">MzScheme/Racket support</a></li>
|
||||
<li><a href="Ocaml.html#Ocaml">OCaml support</a></li>
|
||||
</ul>
|
||||
|
|
|
|||
|
|
@ -373,7 +373,6 @@ example.i(4) : Syntax error in input(1).
|
|||
|
||||
<p>None currently.</p>
|
||||
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn11">19.9.2 Preprocessor (200-299)</a></H3>
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,6 @@ Warnings.html
|
|||
Modules.html
|
||||
CCache.html
|
||||
Android.html
|
||||
C.html
|
||||
CSharp.html
|
||||
D.html
|
||||
Go.html
|
||||
|
|
@ -36,6 +35,7 @@ R.html
|
|||
Ruby.html
|
||||
Scilab.html
|
||||
Tcl.html
|
||||
C.html
|
||||
Mzscheme.html
|
||||
Ocaml.html
|
||||
Extending.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue