jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Another merge with master.

Browse source 
Change Doxygen error codes to start at 740 instead of at 720 as the latter was
taken by Scilab in the meanwhile.

Resolve conflicts in autodoc_runme.py once again.
This commit is contained in:
Vadim Zeitlin 2015-02-16 23:46:39 +01:00
commit 300ccce46c
419 changed files with 18675 additions and 1315 deletions
Download patch file Download diff file Expand all files Collapse all files

74
Doc/Manual/Contents.html
View file

@ -841,6 +841,7 @@
<div class="sectiontoc">
<ul>
<li><a href="Go.html#Go_overview">Overview</a>
<li><a href="Go.html#Go_examples">Examples</a>
<li><a href="Go.html#Go_running_swig">Running SWIG with Go</a>
<ul>
<li><a href="Go.html#Go_commandline">Additional Commandline Options</a>
@ -1726,7 +1727,76 @@
</div>
<!-- INDEX -->
<h3><a href="Tcl.html#Tcl">39 SWIG and Tcl</a></h3>
<h3><a href="Scilab.html#Scilab">39 SWIG and Scilab</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Scilab.html#Scilab_preliminaries">Preliminaries</a>
<li><a href="Scilab.html#Scilab_running_swig">Running SWIG</a>
<ul>
<li><a href="Scilab.html#Scilab_running_swig_generating_module">Generating the module</a>
<li><a href="Scilab.html#Scilab_running_swig_building_module">Building the module</a>
<li><a href="Scilab.html#Scilab_running_swig_loading_module">Loading the module</a>
<li><a href="Scilab.html#Scilab_running_swig_using_module">Using the module</a>
<li><a href="Scilab.html#Scilab_running_swig_options">Scilab command line options</a>
</ul>
<li><a href="Scilab.html#Scilab_wrapping">A basic tour of C/C++ wrapping</a>
<ul>
<li><a href="Scilab.html#Scilab_wrapping_overview">Overview</a>
<li><a href="Scilab.html#Scilab_wrapping_identifiers">Identifiers</a>
<li><a href="Scilab.html#Scilab_wrapping_functions">Functions</a>
<ul>
<li><a href="Scilab.html#Scilab_nn13">Argument passing</a>
<li><a href="Scilab.html#Scilab_nn14">Multiple output arguments</a>
</ul>
<li><a href="Scilab.html#Scilab_wrapping_global_variables">Global variables</a>
<li><a href="Scilab.html#Scilab_wrapping_constants_and_enums">Constants and enumerations</a>
<ul>
<li><a href="Scilab.html#Scilab_wrapping_constants">Constants</a>
<li><a href="Scilab.html#Scilab_wrapping_enums">Enumerations</a>
</ul>
<li><a href="Scilab.html#Scilab_wrapping_pointers">Pointers</a>
<ul>
<li><a href="Scilab.html#Scilab_wrapping_pointers_pointer_adresses">Utility functions</a>
<li><a href="Scilab.html#Scilab_wrapping_pointers_null_pointers">Null pointers</a>
</ul>
<li><a href="Scilab.html#Scilab_wrapping_structs">Structures</a>
<li><a href="Scilab.html#Scilab_wrapping_cpp_classes">C++ Classes</a>
<li><a href="Scilab.html#Scilab_wrapping_cpp_inheritance">C++ inheritance</a>
<li><a href="Scilab.html#Scilab_wrapping_pointers_references_values_arrays">Pointers, references, values, and arrays</a>
<li><a href="Scilab.html#Scilab_wrapping_cpp_templates">C++ templates</a>
<li><a href="Scilab.html#Scilab_wrapping_cpp_operators">C++ operators</a>
<li><a href="Scilab.html#Scilab_wrapping_cpp_namespaces">C++ namespaces</a>
<li><a href="Scilab.html#Scilab_wrapping_cpp_exceptions">C++ exceptions</a>
<li><a href="Scilab.html#Scilab_wrapping_cpp_stl">C++ STL</a>
</ul>
<li><a href="Scilab.html#Scilab_typemaps">Type mappings and libraries</a>
<ul>
<li><a href="Scilab.html#Scilab_typemaps_primitive_types">Default primitive type mappings</a>
<li><a href="Scilab.html#Scilab_typemaps_non-primitive_types">Default type mappings for non-primitive types</a>
<li><a href="Scilab.html#Scilab_typemaps_arrays">Arrays</a>
<li><a href="Scilab.html#Scilab_typemaps_pointer-to-pointers">Pointer-to-pointers</a>
<li><a href="Scilab.html#Scilab_typemaps_matrices">Matrices</a>
<li><a href="Scilab.html#Scilab_typemaps_stl">STL</a>
</ul>
<li><a href="Scilab.html#Scilab_module_initialization">Module initialization</a>
<li><a href="Scilab.html#Scilab_building_modes">Building modes</a>
<ul>
<li><a href="Scilab.html#Scilab_building_modes_nobuilder_mode">No-builder mode</a>
<li><a href="Scilab.html#Scilab_building_modes_builder_mode">Builder mode</a>
</ul>
<li><a href="Scilab.html#Scilab_generated_scripts">Generated scripts</a>
<ul>
<li><a href="Scilab.html#Scilab_generated_scripts_builder_script">Builder script</a>
<li><a href="Scilab.html#Scilab_generated_scripts_loader_script">Loader script</a>
</ul>
<li><a href="Scilab.html#Scilab_other_resources">Other resources</a>
</ul>
</div>
<!-- INDEX -->
<h3><a href="Tcl.html#Tcl">40 SWIG and Tcl</a></h3>
<!-- INDEX -->
<div class="sectiontoc">
@ -1792,7 +1862,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">

100
Doc/Manual/Extending.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Extending"></a>40 Extending SWIG to support new languages</H1>
<H1><a name="Extending"></a>41 Extending SWIG to support new languages</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -75,7 +75,7 @@
<H2><a name="Extending_nn2"></a>40.1 Introduction</H2>
<H2><a name="Extending_nn2"></a>41.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>40.2 Prerequisites</H2>
<H2><a name="Extending_nn3"></a>41.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>40.3 The Big Picture</H2>
<H2><a name="Extending_nn4"></a>41.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>40.4 Execution Model</H2>
<H2><a name="Extending_nn5"></a>41.4 Execution Model</H2>
<p>
@ -203,7 +203,7 @@ latter stage of compilation.
The next few sections briefly describe some of these stages.
</p>
<H3><a name="Extending_nn6"></a>40.4.1 Preprocessing</H3>
<H3><a name="Extending_nn6"></a>41.4.1 Preprocessing</H3>
<p>
@ -284,7 +284,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>40.4.2 Parsing</H3>
<H3><a name="Extending_nn7"></a>41.4.2 Parsing</H3>
<p>
@ -385,7 +385,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>40.4.3 Parse Trees</H3>
<H3><a name="Extending_nn8"></a>41.4.3 Parse Trees</H3>
<p>
@ -640,7 +640,7 @@ $ swig -c++ -python -debug-module 4 example.i
</pre>
</div>
<H3><a name="Extending_nn9"></a>40.4.4 Attribute namespaces</H3>
<H3><a name="Extending_nn9"></a>41.4.4 Attribute namespaces</H3>
<p>
@ -659,7 +659,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>40.4.5 Symbol Tables</H3>
<H3><a name="Extending_nn10"></a>41.4.5 Symbol Tables</H3>
<p>
@ -750,7 +750,7 @@ example.i:5. Previous declaration is foo_i(int )
</pre>
</div>
<H3><a name="Extending_nn11"></a>40.4.6 The %feature directive</H3>
<H3><a name="Extending_nn11"></a>41.4.6 The %feature directive</H3>
<p>
@ -806,7 +806,7 @@ For example, the exception code above is simply
stored without any modifications.
</p>
<H3><a name="Extending_nn12"></a>40.4.7 Code Generation</H3>
<H3><a name="Extending_nn12"></a>41.4.7 Code Generation</H3>
<p>
@ -928,7 +928,7 @@ public :
The role of these functions is described shortly.
</p>
<H3><a name="Extending_nn13"></a>40.4.8 SWIG and XML</H3>
<H3><a name="Extending_nn13"></a>41.4.8 SWIG and XML</H3>
<p>
@ -941,7 +941,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"></a>40.5 Primitive Data Structures</H2>
<H2><a name="Extending_nn14"></a>41.5 Primitive Data Structures</H2>
<p>
@ -987,7 +987,7 @@ typedef Hash Typetab;
</pre>
</div>
<H3><a name="Extending_nn15"></a>40.5.1 Strings</H3>
<H3><a name="Extending_nn15"></a>41.5.1 Strings</H3>
<p>
@ -1128,7 +1128,7 @@ Returns the number of replacements made (if any).
</div>
<H3><a name="Extending_nn16"></a>40.5.2 Hashes</H3>
<H3><a name="Extending_nn16"></a>41.5.2 Hashes</H3>
<p>
@ -1205,7 +1205,7 @@ Returns the list of hash table keys.
</div>
<H3><a name="Extending_nn17"></a>40.5.3 Lists</H3>
<H3><a name="Extending_nn17"></a>41.5.3 Lists</H3>
<p>
@ -1294,7 +1294,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>40.5.4 Common operations</H3>
<H3><a name="Extending_nn18"></a>41.5.4 Common operations</H3>
The following operations are applicable to all datatypes.
@ -1349,7 +1349,7 @@ objects and report errors.
Gets the line number associated with <tt>x</tt>.
</div>
<H3><a name="Extending_nn19"></a>40.5.5 Iterating over Lists and Hashes</H3>
<H3><a name="Extending_nn19"></a>41.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:
@ -1394,7 +1394,7 @@ for (j = First(j); j.item; j= Next(j)) {
</div>
<H3><a name="Extending_nn20"></a>40.5.6 I/O</H3>
<H3><a name="Extending_nn20"></a>41.5.6 I/O</H3>
Special I/O functions are used for all internal I/O. These operations
@ -1528,7 +1528,7 @@ Printf(f, "%s\n", s);
Similarly, the preprocessor and parser all operate on string-files.
</p>
<H2><a name="Extending_nn21"></a>40.6 Navigating and manipulating parse trees</H2>
<H2><a name="Extending_nn21"></a>41.6 Navigating and manipulating parse trees</H2>
Parse trees are built as collections of hash tables. Each node is a hash table in which
@ -1662,7 +1662,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>40.7 Working with attributes</H2>
<H2><a name="Extending_nn22"></a>41.7 Working with attributes</H2>
<p>
@ -1779,7 +1779,7 @@ the attribute is optional. <tt>Swig_restore()</tt> must always be called after
function.
</div>
<H2><a name="Extending_nn23"></a>40.8 Type system</H2>
<H2><a name="Extending_nn23"></a>41.8 Type system</H2>
<p>
@ -1788,7 +1788,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>40.8.1 String encoding of types</H3>
<H3><a name="Extending_nn24"></a>41.8.1 String encoding of types</H3>
<p>
@ -1889,7 +1889,7 @@ make the final type, the two parts are just joined together using
string concatenation.
</p>
<H3><a name="Extending_nn25"></a>40.8.2 Type construction</H3>
<H3><a name="Extending_nn25"></a>41.8.2 Type construction</H3>
<p>
@ -2058,7 +2058,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>40.8.3 Type tests</H3>
<H3><a name="Extending_nn26"></a>41.8.3 Type tests</H3>
<p>
@ -2145,7 +2145,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>40.8.4 Typedef and inheritance</H3>
<H3><a name="Extending_nn27"></a>41.8.4 Typedef and inheritance</H3>
<p>
@ -2247,7 +2247,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>40.8.5 Lvalues</H3>
<H3><a name="Extending_nn28"></a>41.8.5 Lvalues</H3>
<p>
@ -2284,7 +2284,7 @@ Literal y; // type = 'Literal', ltype='p.char'
</pre>
</div>
<H3><a name="Extending_nn29"></a>40.8.6 Output functions</H3>
<H3><a name="Extending_nn29"></a>41.8.6 Output functions</H3>
<p>
@ -2346,7 +2346,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>40.9 Parameters</H2>
<H2><a name="Extending_nn30"></a>41.9 Parameters</H2>
<p>
@ -2445,7 +2445,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>40.10 Writing a Language Module</H2>
<H2><a name="Extending_nn31"></a>41.10 Writing a Language Module</H2>
<p>
@ -2460,7 +2460,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>40.10.1 Execution model</H3>
<H3><a name="Extending_nn32"></a>41.10.1 Execution model</H3>
<p>
@ -2470,7 +2470,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"></a>40.10.2 Starting out</H3>
<H3><a name="Extending_starting_out"></a>41.10.2 Starting out</H3>
<p>
@ -2578,7 +2578,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>40.10.3 Command line options</H3>
<H3><a name="Extending_nn34"></a>41.10.3 Command line options</H3>
<p>
@ -2637,7 +2637,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>40.10.4 Configuration and preprocessing</H3>
<H3><a name="Extending_nn35"></a>41.10.4 Configuration and preprocessing</H3>
<p>
@ -2686,7 +2686,7 @@ an implementation file <tt>python.cxx</tt> and a configuration file
<tt>python.swg</tt>.
</p>
<H3><a name="Extending_nn36"></a>40.10.5 Entry point to code generation</H3>
<H3><a name="Extending_nn36"></a>41.10.5 Entry point to code generation</H3>
<p>
@ -2744,7 +2744,7 @@ int Python::top(Node *n) {
</pre>
</div>
<H3><a name="Extending_nn37"></a>40.10.6 Module I/O and wrapper skeleton</H3>
<H3><a name="Extending_nn37"></a>41.10.6 Module I/O and wrapper skeleton</H3>
<!-- please report bugs in this section to mgossage -->
@ -2892,7 +2892,7 @@ functionWrapper : void Shape_y_set(Shape *self,double y)
</pre>
</div>
<H3><a name="Extending_nn38"></a>40.10.7 Low-level code generators</H3>
<H3><a name="Extending_nn38"></a>41.10.7 Low-level code generators</H3>
<!-- please report bugs in this section to mgossage -->
@ -3046,7 +3046,7 @@ but without the typemaps, there is still work to do.
</p>
<H3><a name="Extending_configuration_files"></a>40.10.8 Configuration files</H3>
<H3><a name="Extending_configuration_files"></a>41.10.8 Configuration files</H3>
<!-- please report bugs in this section to ttn -->
@ -3190,7 +3190,7 @@ politely displays the ignoring language message.
</dl>
<H3><a name="Extending_nn40"></a>40.10.9 Runtime support</H3>
<H3><a name="Extending_nn40"></a>41.10.9 Runtime support</H3>
<p>
@ -3199,7 +3199,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>40.10.10 Standard library files</H3>
<H3><a name="Extending_nn41"></a>41.10.10 Standard library files</H3>
<p>
@ -3218,7 +3218,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"></a>40.10.11 User examples</H3>
<H3><a name="Extending_nn42"></a>41.10.11 User examples</H3>
<p>
@ -3247,7 +3247,7 @@ during this process, see the section on <a href="#Extending_configuration_files"
files</a>.
</p>
<H3><a name="Extending_test_suite"></a>40.10.12 Test driven development and the test-suite</H3>
<H3><a name="Extending_test_suite"></a>41.10.12 Test driven development and the test-suite</H3>
<p>
@ -3306,7 +3306,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"></a>40.10.12.1 Running the test-suite</H4>
<H4><a name="Extending_running_test_suite"></a>41.10.12.1 Running the test-suite</H4>
<p>
@ -3498,7 +3498,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"></a>40.10.13 Documentation</H3>
<H3><a name="Extending_nn43"></a>41.10.13 Documentation</H3>
<p>
@ -3530,7 +3530,7 @@ Some topics that you'll want to be sure to address include:
if available.
</ul>
<H3><a name="Extending_prerequisites"></a>40.10.14 Prerequisites for adding a new language module to the SWIG distribution</H3>
<H3><a name="Extending_prerequisites"></a>41.10.14 Prerequisites for adding a new language module to the SWIG distribution</H3>
<p>
@ -3587,7 +3587,7 @@ should be added should there be an area not already covered by
the existing tests.
</p>
<H3><a name="Extending_coding_style_guidelines"></a>40.10.15 Coding style guidelines</H3>
<H3><a name="Extending_coding_style_guidelines"></a>41.10.15 Coding style guidelines</H3>
<p>
@ -3611,7 +3611,7 @@ The generated C/C++ code should also follow this style as close as possible. How
should be avoided as unlike the SWIG developers, users will never have consistent tab settings.
</p>
<H2><a name="Extending_debugging_options"></a>40.11 Debugging Options</H2>
<H2><a name="Extending_debugging_options"></a>41.11 Debugging Options</H2>
<p>
@ -3638,7 +3638,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"></a>40.12 Guide to parse tree nodes</H2>
<H2><a name="Extending_nn46"></a>41.12 Guide to parse tree nodes</H2>
<p>
@ -4046,7 +4046,7 @@ extern "X" { ... } declaration.
</pre>
</div>
<H2><a name="Extending_further_info"></a>40.13 Further Development Information</H2>
<H2><a name="Extending_further_info"></a>41.13 Further Development Information</H2>
<p>

77
Doc/Manual/Go.html
View file

@ -10,6 +10,7 @@
<div class="sectiontoc">
<ul>
<li><a href="#Go_overview">Overview</a>
<li><a href="#Go_examples">Examples</a>
<li><a href="#Go_running_swig">Running SWIG with Go</a>
<ul>
<li><a href="#Go_commandline">Additional Commandline Options</a>
@ -69,7 +70,22 @@ checking and runtime library are not used with Go. This should be
borne in mind when reading the rest of the SWIG documentation.
</p>
<H2><a name="Go_running_swig"></a>23.2 Running SWIG with Go</H2>
<H2><a name="Go_examples"></a>23.2 Examples</H2>
<p>
Working examples can be found here:
</p>
<ul>
<li><a href="https://golang.org/misc/swig">Examples from the Go source tree</a>
<li><a href="https://github.com/swig/swig/tree/master/Examples/go">Examples from the SWIG source tree</a>
</ul>
<p>
The examples in the 2nd link are shipped with the SWIG distribution under the Examples/go directory.
</p>
<H2><a name="Go_running_swig"></a>23.3 Running SWIG with Go</H2>
<p>
@ -78,7 +94,7 @@ default SWIG will generate code for the gc compilers. To generate
code for gccgo, you should also use the <tt>-gccgo</tt> option.
</p>
<H3><a name="Go_commandline"></a>23.2.1 Additional Commandline Options</H3>
<H3><a name="Go_commandline"></a>23.3.1 Additional Commandline Options</H3>
<p>
@ -152,7 +168,7 @@ swig -go -help
</table>
<H3><a name="Go_outputs"></a>23.2.2 Go Output Files</H3>
<H3><a name="Go_outputs"></a>23.3.2 Go Output Files</H3>
<p> When generating Go code, SWIG will generate the following
@ -228,7 +244,7 @@ this:
% go tool 6l main.6
</pre></div>
<H2><a name="Go_basic_tour"></a>23.3 A tour of basic C/C++ wrapping</H2>
<H2><a name="Go_basic_tour"></a>23.4 A tour of basic C/C++ wrapping</H2>
<p>
@ -238,7 +254,7 @@ modifications have to occur. This section briefly covers the
essential aspects of this wrapping.
</p>
<H3><a name="Go_package"></a>23.3.1 Go Package Name</H3>
<H3><a name="Go_package"></a>23.4.1 Go Package Name</H3>
<p>
@ -248,7 +264,7 @@ directive. You may override this by using SWIG's <tt>-package</tt>
command line option.
</p>
<H3><a name="Go_names"></a>23.3.2 Go Names</H3>
<H3><a name="Go_names"></a>23.4.2 Go Names</H3>
<p>
@ -280,7 +296,7 @@ followed by that name, and the destructor will be
named <tt>Delete</tt> followed by that name.
</p>
<H3><a name="Go_constants"></a>23.3.3 Go Constants</H3>
<H3><a name="Go_constants"></a>23.4.3 Go Constants</H3>
<p>
@ -288,7 +304,7 @@ C/C++ constants created via <tt>#define</tt> or the <tt>%constant</tt>
directive become Go constants, declared with a <tt>const</tt>
declaration.
<H3><a name="Go_enumerations"></a>23.3.4 Go Enumerations</H3>
<H3><a name="Go_enumerations"></a>23.4.4 Go Enumerations</H3>
<p>
@ -298,7 +314,7 @@ usual). The values of the enumeration will become variables in Go;
code should avoid modifying those variables.
</p>
<H3><a name="Go_classes"></a>23.3.5 Go Classes</H3>
<H3><a name="Go_classes"></a>23.4.5 Go Classes</H3>
<p>
@ -376,21 +392,24 @@ returns a go interface. If the returned pointer can be null, you can check
for this by calling the Swigcptr() method.
</p>
<H4><a name="Go_class_memory"></a>23.3.5.1 Go Class Memory Management</H4>
<H4><a name="Go_class_memory"></a>23.4.5.1 Go Class Memory Management</H4>
<p>
Calling <tt>NewClassName</tt> for some C++ class <tt>ClassName</tt>
will allocate memory using the C++ memory allocator. This memory will
not be automatically freed by Go's garbage collector. When you are
done with the C++ object you must free it using <tt>DeleteClassName</tt>.
not be automatically freed by Go's garbage collector as the object ownership is
not tracked. When you are done with the C++ object you must free it manually
using <tt>DeleteClassName</tt>.
</p>
<p>
A common technique is to store the C++ object into a Go object, and
use the Go function <tt>runtime.SetFinalizer</tt> to free the C++
object when the Go object is freed. For example, if the SWIG package
is imported as "wrap":
use the Go function <tt>runtime.SetFinalizer</tt> to free the C++ object when
the Go object is freed. It is strongly recommended to read the
<a href="https://golang.org/pkg/runtime/#SetFinalizer">runtime.SetFinalizer</a>
documentation before using this technique to understand its limitations.
For example, if the SWIG package is imported as "wrap":
</p>
<div class="code">
<pre>
@ -409,7 +428,7 @@ func NewGoClassName() *GoClassName {
</pre>
</div>
<H4><a name="Go_class_inheritance"></a>23.3.5.2 Go Class Inheritance</H4>
<H4><a name="Go_class_inheritance"></a>23.4.5.2 Go Class Inheritance</H4>
<p>
@ -421,7 +440,7 @@ Doing the reverse will require an explicit type assertion, which will
be checked dynamically.
</p>
<H3><a name="Go_templates"></a>23.3.6 Go Templates</H3>
<H3><a name="Go_templates"></a>23.4.6 Go Templates</H3>
<p>
@ -429,7 +448,7 @@ In order to use C++ templates in Go, you must tell SWIG to create
wrappers for a particular template instantation. To do this, use
the <tt>%template</tt> directive.
<H3><a name="Go_director_classes"></a>23.3.7 Go Director Classes</H3>
<H3><a name="Go_director_classes"></a>23.4.7 Go Director Classes</H3>
<p>
@ -472,7 +491,7 @@ method defined in Go. The Go code may of course call other methods on
itself, and those methods may be defined either in Go or in C++.
</p>
<H3><a name="Go_primitive_type_mappings"></a>23.3.8 Default Go primitive type mappings</H3>
<H3><a name="Go_primitive_type_mappings"></a>23.4.8 Default Go primitive type mappings</H3>
<p>
@ -579,7 +598,7 @@ that typemap, or add new values, to control how C/C++ types are mapped
into Go types.
</p>
<H3><a name="Go_output_arguments"></a>23.3.9 Output arguments</H3>
<H3><a name="Go_output_arguments"></a>23.4.9 Output arguments</H3>
<p>Because of limitations in the way output arguments are processed in swig,
@ -632,7 +651,7 @@ void f(char *output);
</pre>
</div>
<H3><a name="Go_adding_additional_code"></a>23.3.10 Adding additional go code</H3>
<H3><a name="Go_adding_additional_code"></a>23.4.10 Adding additional go code</H3>
<p>Often the APIs generated by swig are not very natural in go, especially if
@ -727,7 +746,7 @@ func bar() {
</pre>
</div>
<H3><a name="Go_typemaps"></a>23.3.11 Go typemaps</H3>
<H3><a name="Go_typemaps"></a>23.4.11 Go typemaps</H3>
<p>
@ -776,7 +795,8 @@ gotype is best converted to C/C++ using Go code.
<td>
Go code to convert from gotype to imtype when calling a C/C++
function. SWIG will then internally convert imtype to a C/C++ type
and pass it down. If this is not defined no conversion is done.
and pass it down. If this is not defined, or is the empty string, no
conversion is done.
</td>
</tr>
@ -803,7 +823,8 @@ to the desired type.
<td>goout</td>
<td>
Go code to convert a value returned from a C/C++ function from imtype
to gotype. If this is not defined no conversion is done.
to gotype. If this is not defined, or is the empty string, no
conversion is done.
</td>
</tr>
@ -824,7 +845,7 @@ be done.
Go code to adjust an argument value when returning from a function.
This is called after the real C/C++ function has run. The value will
be in imtype. This is only useful for a pointer type of some sort.
If this is not defined nothing will be done.
If this is not defined, or is the empty string, nothing will be done.
</td>
</tr>
@ -842,7 +863,8 @@ to the desired type.
<td>godirectorin</td>
<td>
Go code to convert a value used to call a director method from imtype
to gotype. If this is not defined no conversion is done.
to gotype. If this is not defined, or is the empty string, no
conversion is done.
</td>
</tr>
@ -850,7 +872,8 @@ to gotype. If this is not defined no conversion is done.
<td>godirectorout</td>
<td>
Go code to convert a value returned from a director method from gotype
to imtype. If this is not defined no conversion is done.
to imtype. If this is not defined, or is the empty string, no
conversion is done.
</td>
</tr>

3
Doc/Manual/Introduction.html
View file

@ -334,8 +334,7 @@ major features include:
</ul>
<p>
Currently, the only major C++ feature not supported is nested classes--a limitation
that should be removed in a future release, but has some workarounds for the moment.
Most of C++11 is also supported. Details are in the <a href="CPlusPlus11.html">C++11</a> section.
</p>
<p>

2
Doc/Manual/Php.html
View file

@ -142,6 +142,7 @@ least work for Linux though):
<H3><a name="Php_nn1_3"></a>34.1.2 Using PHP Extensions</H3>
<p>
To test the extension from a PHP script, you first need to tell PHP to
load it. To do this, add a line like this to the <tt>[PHP]</tt> section of
@ -773,6 +774,7 @@ Ko::threats();
<H4><a name="Php_nn2_6_5"></a>34.2.6.5 Specifying Implemented Interfaces</H4>
<p>
PHP supports the concept of abstract interfaces which a class can implement.
Since SWIG 3.0.3, you can tell SWIG that a wrapped class (for example

3
Doc/Manual/Preprocessor.html
View file

@ -120,7 +120,7 @@ SWIG_JAVASCRIPT_JSC Defined when using Javascript for JavascriptCore
SWIG_JAVASCRIPT_V8 Defined when using Javascript for v8 or node.js
SWIGLUA Defined when using Lua
SWIGMODULA3 Defined when using Modula-3
SWIGMZSCHEME Defined when using Mzscheme
SWIGMZSCHEME Defined when using Mzscheme
SWIGOCAML Defined when using Ocaml
SWIGOCTAVE Defined when using Octave
SWIGPERL Defined when using Perl
@ -129,6 +129,7 @@ SWIGPIKE Defined when using Pike
SWIGPYTHON Defined when using Python
SWIGR Defined when using R
SWIGRUBY Defined when using Ruby
SWIGSCILAB Defined when using Scilab
SWIGSEXP Defined when using S-expressions
SWIGTCL Defined when using Tcl
SWIGXML Defined when using XML

52
Doc/Manual/Python.html
View file

@ -2169,15 +2169,15 @@ for Python 2.2):
import _example
class Foo(object):
def __init__(self):
self.this = _example.new_Foo()
self.thisown = 1
def __del__(self):
if self.thisown:
_example.delete_Foo(self.this)
def spam(self,arg1):
return _example.Foo_spam(self.this,arg1)
x = property(_example.Foo_x_get, _example.Foo_x_set)
def __init__(self):
self.this = _example.new_Foo()
self.thisown = 1
def __del__(self):
if self.thisown:
_example.delete_Foo(self.this)
def spam(self,arg1):
return _example.Foo_spam(self.this,arg1)
x = property(_example.Foo_x_get, _example.Foo_x_set)
</pre>
</div>
@ -2219,9 +2219,9 @@ like in a proxy class:
<div class="targetlang">
<pre>
class Foo(object):
def __init__(self):
self.this = _example.new_Foo()
self.thisown = 1
def __init__(self):
self.this = _example.new_Foo()
self.thisown = 1
</pre>
</div>
@ -2313,11 +2313,11 @@ private:
<div class="targetlang">
<pre>
class MyPyException (Exception) :
def __init__(self, msg, *args) :
class MyPyException(Exception):
def __init__(self, msg, *args):
Exception.__init__(self, *args)
self.myexc = MyException(msg)
def what (self) :
def what(self):
return self.myexc.what()
</pre>
</div>
@ -2841,6 +2841,7 @@ the methods one() and two() (but not three()):
class Foo {
public:
Foo(int foo);
virtual ~Foo();
virtual void one();
virtual void two();
};
@ -2861,11 +2862,12 @@ then at the python side you can define
import mymodule
class MyFoo(mymodule.Foo):
def __init__(self, foo):
mymodule.Foo(self, foo)
def __init__(self, foo):
mymodule.Foo.__init__(self, foo)
# super().__init__(foo) # Alternative construction for Python3
def one(self):
print "one from python"
def one(self):
print "one from python"
</pre>
</div>
@ -3368,6 +3370,18 @@ print("Loading", "Whizz", "Bang", sep=' ... ')
</pre>
</div>
<p>When using <tt>%pythoncode</tt> and <tt>%pythonbegin</tt> you generally
want to make sure that the block is delimited by <tt>%{</tt> and <tt>%}</tt>.
If you delimit it with <tt>{</tt> and <tt>}</tt> then any lines with a
leading <tt>#</tt> will be handled by SWIG as preprocessor directives, when
you probably meant them as Python comments. Prior to SWIG 3.0.3, invalid
preprocessor directives were silently ignored, so generally using the wrong
delimiters resulted in such comments not appearing in the generated output
(though a comment starting with a valid preprocessor directive could cause
problems, for example: <tt># error handling</tt>). SWIG 3.0.3 and later report
an error for invalid preprocessor directives, so you may have to update
existing interface files to delimit blocks of Python code correctly.</p>
<p>Sometimes you may want to replace or modify the wrapper function
that SWIG creates in the proxy <tt>.py</tt> file. The Python module
in SWIG provides some features that enable you to do this. First, to

26
Doc/Manual/Ruby.html
View file

@ -147,7 +147,7 @@
<H2><a name="Ruby_nn2"></a>38.1 Preliminaries</H2>
<p> SWIG 1.3 is known to work with Ruby versions 1.6 and later.
<p> SWIG 3.0 is known to work with Ruby versions 1.8 and later.
Given the choice, you should use the latest stable version of Ruby. You
should also determine if your system supports shared libraries and
dynamic loading. SWIG will work with or without dynamic loading, but
@ -191,7 +191,7 @@ header file. This file is usually contained in a directory such as </p>
<div class="code shell diagram">
<pre>/usr/lib/ruby/1.8/x86_64-linux-gnu/ruby.h
/usr/local/lib/ruby/1.6/i686-linux/ruby.h
/usr/include/ruby-2.1.0/ruby.h
</pre>
</div>
@ -201,8 +201,14 @@ installed, you can run Ruby to find out. For example: </p>
<div class="code shell">
<pre>$ ruby -e 'puts $:.join("\n")'
/usr/local/lib/ruby/site_ruby/1.6 /usr/local/lib/ruby/site_ruby/1.6/i686-linux
/usr/local/lib/ruby/site_ruby /usr/local/lib/ruby/1.6 /usr/local/lib/ruby/1.6/i686-linux .
/usr/local/lib/site_ruby/2.1.0
/usr/local/lib/x86_64-linux-gnu/site_ruby
/usr/local/lib/site_ruby
/usr/lib/ruby/vendor_ruby/2.1.0
/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.1.0
/usr/lib/ruby/vendor_ruby
/usr/lib/ruby/2.1.0
/usr/lib/x86_64-linux-gnu/ruby/2.1.0
</pre>
</div>
@ -260,7 +266,7 @@ operating system would look something like this: </p>
<div class="code shell">
<pre>$ swig -ruby example.i
$ gcc -O2 -fPIC -c example.c
$ gcc -O2 -fPIC -c example_wrap.c -I/usr/local/lib/ruby/1.6/i686-linux
$ gcc -O2 -fPIC -c example_wrap.c -I/usr/include/ruby-2.1.0
$ gcc -shared example.o example_wrap.o -o example.so
</pre>
</div>
@ -334,7 +340,7 @@ using the C++ compiler. For example: </p>
<pre>
$ swig -c++ -ruby example.i
$ g++ -fPIC -c example.cxx
$ g++ -fPIC -c example_wrap.cxx -I/usr/local/lib/ruby/1.6/i686-linux
$ g++ -fPIC -c example_wrap.cxx -I/usr/include/ruby-2.1.0
$ g++ -shared example.o example_wrap.o -o example.so
</pre>
</div>
@ -2823,7 +2829,7 @@ not support optional arguments, such as Java and C#, effectively ignore
the value specified by this typemap as all arguments must be given.</p>
<p> Once a default typemap has been applied to an argument, all
arguments that follow must have default values. See the <a href="http://www.swig.org/Doc1.3/SWIGDocumentation.html#SWIG_default_args">
arguments that follow must have default values. See the <a href="SWIG.html#SWIG_default_args">
Default/optional arguments</a> section for further information on
default argument wrapping.</p>
@ -3017,7 +3023,7 @@ catch(char const *_e) {
<p> Note that if your methods do not have an exception
specification yet they do throw exceptions, SWIG cannot know how to
deal with them. For a neat way to handle these, see the <a href="http://www.swig.org/Doc1.3/SWIGDocumentation.html#exception">Exception
deal with them. For a neat way to handle these, see the <a href="Customization.html#Customization_exception">Exception
handling with %exception</a> section.</p>
<H4><a name="Ruby_directorin_typemap"></a>38.7.6.14 directorin typemap</H4>
@ -4466,7 +4472,7 @@ and then type <tt>make</tt> to build the shared library: </p>
<pre>$ <b>ruby extconf.rb</b>
creating Makefile
$ <b>make</b>
g++ -fPIC -g -O2 -I. -I/usr/local/lib/ruby/1.7/i686-linux \
g++ -fPIC -g -O2 -I. -I/usr/include/ruby-2.1.0 \
-I. -c shape_wrap.cxx
gcc -shared -L/usr/local/lib -o shape.so shape_wrap.o -L. \
-lruby -lruby -lc</pre>
@ -5351,7 +5357,7 @@ used for callbacks, for example. </p>
<p>To solve the problem, SWIG can now generate code with director
functions containing the optional macros SWIG_INIT_STACK and
SWIG_RELEASE_STACK. These macros will try to force Ruby to
reinitiliaze the beginning of the stack the first time a
reinitialize the beginning of the stack the first time a
director
function is called. This will lead Ruby to measure and not
collect any VALUE objects defined from that point on. </p>

3
Doc/Manual/SWIG.html
View file

@ -138,6 +138,7 @@ can be obtained by typing <tt>swig -help</tt> or <tt>swig
-xml Generate XML wrappers
-c++ Enable C++ parsing
-cppext <em>ext</em> Change file extension of C++ generated files to <em>ext</em> (default is cxx, except for PHP which uses cpp)
-D<em>symbol</em> Define a preprocessor symbol
-Fstandard Display error/warning messages in commonly used format
-Fmicrosoft Display error/warning messages in Microsoft format
@ -146,7 +147,7 @@ can be obtained by typing <tt>swig -help</tt> or <tt>swig
-l<em>file</em> Include a SWIG library file.
-module <em>name</em> Set the name of the SWIG module
-o <em>outfile</em> Name of output file
-outcurrentdir Set default output dir to current dir instead of input file's path
-outcurrentdir Set default output dir to current dir instead of input file's path
-outdir <em>dir</em> Set language specific files output directory
-pcreversion Display PCRE version information
-swiglib Show location of SWIG library

60
Doc/Manual/SWIGPlus.html
View file

@ -3614,18 +3614,52 @@ and the second will take two integer arguments.
</p>
<p>
Needless to say, SWIG's template support provides plenty of
opportunities to break the universe. That said, an important final
point is that <b>SWIG does not perform extensive error checking of
templates!</b> Specifically, SWIG does not perform type checking nor
does it check to see if the actual contents of the template
declaration make any sense. Since the C++ compiler will hopefully
check this when it compiles the resulting wrapper file, there is no
practical reason for SWIG to duplicate this functionality (besides,
none of the SWIG developers are masochistic enough to want to
implement this right now).
Needless to say, SWIG's template support provides plenty of opportunities to
break the universe. That said, an important final point is that <b>SWIG does
not perform extensive error checking of templates!</b> Specifically, SWIG does
not perform type checking nor does it check to see if the actual contents of the
template declaration make any sense. Since the C++ compiler checks this when it
compiles the resulting wrapper file, there is no practical reason for SWIG to
duplicate this functionality.
</p>
<a name="SWIGPlus_template_nested_class_example"></a>
<p>
As SWIG's template support does not perform type checking <tt>%template</tt>
can be used as early as after a template declaration. You can, and rarely have
to, use <tt>%template</tt> before the template parameters have been declared.
For example:
</p>
<div class="code">
<pre>
template &lt;class T&gt; class OuterTemplateClass {};
// The nested class OuterClass::InnerClass inherits from the template class
// OuterTemplateClass&lt;OuterClass::InnerStruct&gt; and thus the template needs
// to be expanded with %template before the OuterClass declaration.
%template(OuterTemplateClass_OuterClass__InnerStruct)
OuterTemplateClass&lt;OuterClass::InnerStruct&gt;
// Don't forget to use %feature("flatnested") for OuterClass::InnerStruct and
// OuterClass::InnerClass if the target language doesn't support nested classes.
class OuterClass {
public:
// Forward declarations:
struct InnerStruct;
class InnerClass;
};
struct OuterClass::InnerStruct {};
// Expanding the template at this point with %template is too late as the
// OuterClass::InnerClass declaration is processed inside OuterClass.
class OuterClass::InnerClass : public OuterTemplateClass&lt;InnerStruct&gt; {};
</pre>
</div>
<p>
<b>Compatibility Note</b>: The first implementation of template support relied heavily on
macro expansion in the preprocessor. Templates have been more tightly integrated into
@ -5000,6 +5034,12 @@ class Bar {
</pre>
</div>
<p>
If a nested class, within an outer class, has to be used as a template parameter within the outer class, then the template will
have to be instantiated with <tt>%template</tt> before the beginning of the outer class.
An example can be found in the
<a href="#SWIGPlus_template_nested_class_example">Templates</a> section.
</p>
<p>
<b>Compatibility Note:</b>

2051
Doc/Manual/Scilab.html Normal file
View file

File diff suppressed because it is too large Load diff

3
Doc/Manual/Sections.html
View file

@ -6,7 +6,7 @@
<body bgcolor="#ffffff">
<H1><a name="Sections"></a>SWIG-3.0 Documentation</H1>
Last update : SWIG-3.0.3 (in progress)
Last update : SWIG-3.0.6 (in progress)
<H2>Sections</H2>
@ -55,6 +55,7 @@ Last update : SWIG-3.0.3 (in progress)
<li><a href="Python.html#Python">Python support</a></li>
<li><a href="R.html#R">R support</a></li>
<li><a href="Ruby.html#Ruby">Ruby support</a></li>
<li><a href="Scilab.html#Scilab">Scilab support</a></li>
<li><a href="Tcl.html#Tcl">Tcl support</a></li>
</ul>

92
Doc/Manual/Tcl.html
View file

@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Tcl"></a>39 SWIG and Tcl</H1>
<H1><a name="Tcl"></a>40 SWIG and Tcl</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -83,7 +83,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>39.1 Preliminaries</H2>
<H2><a name="Tcl_nn2"></a>40.1 Preliminaries</H2>
<p>
@ -109,7 +109,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>39.1.1 Getting the right header files</H3>
<H3><a name="Tcl_nn3"></a>40.1.1 Getting the right header files</H3>
<p>
@ -127,7 +127,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>39.1.2 Compiling a dynamic module</H3>
<H3><a name="Tcl_nn4"></a>40.1.2 Compiling a dynamic module</H3>
<p>
@ -163,7 +163,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>39.1.3 Static linking</H3>
<H3><a name="Tcl_nn5"></a>40.1.3 Static linking</H3>
<p>
@ -229,7 +229,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>39.1.4 Using your module</H3>
<H3><a name="Tcl_nn6"></a>40.1.4 Using your module</H3>
<p>
@ -357,7 +357,7 @@ to the default system configuration (this requires root access and you will need
the man pages).
</p>
<H3><a name="Tcl_nn7"></a>39.1.5 Compilation of C++ extensions</H3>
<H3><a name="Tcl_nn7"></a>40.1.5 Compilation of C++ extensions</H3>
<p>
@ -440,7 +440,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>39.1.6 Compiling for 64-bit platforms</H3>
<H3><a name="Tcl_nn8"></a>40.1.6 Compiling for 64-bit platforms</H3>
<p>
@ -467,7 +467,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>39.1.7 Setting a package prefix</H3>
<H3><a name="Tcl_nn9"></a>40.1.7 Setting a package prefix</H3>
<p>
@ -486,7 +486,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>39.1.8 Using namespaces</H3>
<H3><a name="Tcl_nn10"></a>40.1.8 Using namespaces</H3>
<p>
@ -508,7 +508,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>39.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
<H2><a name="Tcl_nn11"></a>40.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
<p>
@ -519,7 +519,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>39.2.1 Running SWIG from Developer Studio</H3>
<H3><a name="Tcl_nn12"></a>40.2.1 Running SWIG from Developer Studio</H3>
<p>
@ -577,7 +577,7 @@ MSDOS &gt; tclsh80
%
</pre></div>
<H3><a name="Tcl_nn13"></a>39.2.2 Using NMAKE</H3>
<H3><a name="Tcl_nn13"></a>40.2.2 Using NMAKE</H3>
<p>
@ -640,7 +640,7 @@ to get you started. With a little practice, you'll be making lots of
Tcl extensions.
</p>
<H2><a name="Tcl_nn14"></a>39.3 A tour of basic C/C++ wrapping</H2>
<H2><a name="Tcl_nn14"></a>40.3 A tour of basic C/C++ wrapping</H2>
<p>
@ -651,7 +651,7 @@ classes. This section briefly covers the essential aspects of this
wrapping.
</p>
<H3><a name="Tcl_nn15"></a>39.3.1 Modules</H3>
<H3><a name="Tcl_nn15"></a>40.3.1 Modules</H3>
<p>
@ -685,7 +685,7 @@ To fix this, supply an extra argument to <tt>load</tt> like this:
</pre>
</div>
<H3><a name="Tcl_nn16"></a>39.3.2 Functions</H3>
<H3><a name="Tcl_nn16"></a>40.3.2 Functions</H3>
<p>
@ -710,7 +710,7 @@ like you think it does:
%
</pre></div>
<H3><a name="Tcl_nn17"></a>39.3.3 Global variables</H3>
<H3><a name="Tcl_nn17"></a>40.3.3 Global variables</H3>
<p>
@ -790,7 +790,7 @@ extern char *path; // Read-only (due to %immutable)
</pre>
</div>
<H3><a name="Tcl_nn18"></a>39.3.4 Constants and enums</H3>
<H3><a name="Tcl_nn18"></a>40.3.4 Constants and enums</H3>
<p>
@ -874,7 +874,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 omitted.
</p>
<H3><a name="Tcl_nn19"></a>39.3.5 Pointers</H3>
<H3><a name="Tcl_nn19"></a>40.3.5 Pointers</H3>
<p>
@ -970,7 +970,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>39.3.6 Structures</H3>
<H3><a name="Tcl_nn20"></a>40.3.6 Structures</H3>
<p>
@ -1252,7 +1252,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>39.3.7 C++ classes</H3>
<H3><a name="Tcl_nn21"></a>40.3.7 C++ classes</H3>
<p>
@ -1319,7 +1319,7 @@ In Tcl, the static member is accessed as follows:
</pre>
</div>
<H3><a name="Tcl_nn22"></a>39.3.8 C++ inheritance</H3>
<H3><a name="Tcl_nn22"></a>40.3.8 C++ inheritance</H3>
<p>
@ -1368,7 +1368,7 @@ For instance:
It is safe to use multiple inheritance with SWIG.
</p>
<H3><a name="Tcl_nn23"></a>39.3.9 Pointers, references, values, and arrays</H3>
<H3><a name="Tcl_nn23"></a>40.3.9 Pointers, references, values, and arrays</H3>
<p>
@ -1422,7 +1422,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>39.3.10 C++ overloaded functions</H3>
<H3><a name="Tcl_nn24"></a>40.3.10 C++ overloaded functions</H3>
<p>
@ -1545,7 +1545,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>39.3.11 C++ operators</H3>
<H3><a name="Tcl_nn25"></a>40.3.11 C++ operators</H3>
<p>
@ -1647,7 +1647,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>39.3.12 C++ namespaces</H3>
<H3><a name="Tcl_nn26"></a>40.3.12 C++ namespaces</H3>
<p>
@ -1711,7 +1711,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>39.3.13 C++ templates</H3>
<H3><a name="Tcl_nn27"></a>40.3.13 C++ templates</H3>
<p>
@ -1763,7 +1763,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>39.3.14 C++ Smart Pointers</H3>
<H3><a name="Tcl_nn28"></a>40.3.14 C++ Smart Pointers</H3>
<p>
@ -1847,7 +1847,7 @@ simply use the <tt>__deref__()</tt> method. For example:
</pre>
</div>
<H2><a name="Tcl_nn29"></a>39.4 Further details on the Tcl class interface</H2>
<H2><a name="Tcl_nn29"></a>40.4 Further details on the Tcl class interface</H2>
<p>
@ -1860,7 +1860,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>39.4.1 Proxy classes</H3>
<H3><a name="Tcl_nn30"></a>40.4.1 Proxy classes</H3>
<p>
@ -1925,7 +1925,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>39.4.2 Memory management</H3>
<H3><a name="Tcl_nn31"></a>40.4.2 Memory management</H3>
<p>
@ -2113,7 +2113,7 @@ typemaps--an advanced topic discussed later.
</p>
<H2><a name="Tcl_nn32"></a>39.5 Input and output parameters</H2>
<H2><a name="Tcl_nn32"></a>40.5 Input and output parameters</H2>
<p>
@ -2301,7 +2301,7 @@ set c [lindex $dim 1]
</pre>
</div>
<H2><a name="Tcl_nn33"></a>39.6 Exception handling </H2>
<H2><a name="Tcl_nn33"></a>40.6 Exception handling </H2>
<p>
@ -2435,7 +2435,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>39.7 Typemaps</H2>
<H2><a name="Tcl_nn34"></a>40.7 Typemaps</H2>
<p>
@ -2452,7 +2452,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>39.7.1 What is a typemap?</H3>
<H3><a name="Tcl_nn35"></a>40.7.1 What is a typemap?</H3>
<p>
@ -2569,7 +2569,7 @@ parameter is omitted):
</pre>
</div>
<H3><a name="Tcl_nn36"></a>39.7.2 Tcl typemaps</H3>
<H3><a name="Tcl_nn36"></a>40.7.2 Tcl typemaps</H3>
<p>
@ -2707,7 +2707,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>39.7.3 Typemap variables</H3>
<H3><a name="Tcl_nn37"></a>40.7.3 Typemap variables</H3>
<p>
@ -2778,7 +2778,7 @@ properly assigned.
The Tcl name of the wrapper function being created.
</div>
<H3><a name="Tcl_nn38"></a>39.7.4 Converting a Tcl list to a char ** </H3>
<H3><a name="Tcl_nn38"></a>40.7.4 Converting a Tcl list to a char ** </H3>
<p>
@ -2840,7 +2840,7 @@ argv[2] = Larry
3
</pre></div>
<H3><a name="Tcl_nn39"></a>39.7.5 Returning values in arguments</H3>
<H3><a name="Tcl_nn39"></a>40.7.5 Returning values in arguments</H3>
<p>
@ -2882,7 +2882,7 @@ result, a Tcl function using these typemaps will work like this :
%
</pre></div>
<H3><a name="Tcl_nn40"></a>39.7.6 Useful functions</H3>
<H3><a name="Tcl_nn40"></a>40.7.6 Useful functions</H3>
<p>
@ -2958,7 +2958,7 @@ int Tcl_IsShared(Tcl_Obj *obj);
</pre>
</div>
<H3><a name="Tcl_nn41"></a>39.7.7 Standard typemaps</H3>
<H3><a name="Tcl_nn41"></a>40.7.7 Standard typemaps</H3>
<p>
@ -3043,7 +3043,7 @@ work)
</pre>
</div>
<H3><a name="Tcl_nn42"></a>39.7.8 Pointer handling</H3>
<H3><a name="Tcl_nn42"></a>40.7.8 Pointer handling</H3>
<p>
@ -3119,7 +3119,7 @@ For example:
</pre>
</div>
<H2><a name="Tcl_nn43"></a>39.8 Turning a SWIG module into a Tcl Package.</H2>
<H2><a name="Tcl_nn43"></a>40.8 Turning a SWIG module into a Tcl Package.</H2>
<p>
@ -3191,7 +3191,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>39.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
<H2><a name="Tcl_nn44"></a>40.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
<p>
@ -3290,7 +3290,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>39.9.1 Proxy classes</H3>
<H3><a name="Tcl_nn45"></a>40.9.1 Proxy classes</H3>
<p>
@ -3411,7 +3411,7 @@ short, but clever Tcl script can be combined with SWIG to do many
interesting things.
</p>
<H2><a name="Tcl_nn46"></a>39.10 Tcl/Tk Stubs</H2>
<H2><a name="Tcl_nn46"></a>40.10 Tcl/Tk Stubs</H2>
<p>

4
Doc/Manual/Warnings.html
View file

@ -349,9 +349,9 @@ These can be overridden using command line options, for example:
<div class="shell"><pre>
$ swig -python -Fstandard example.i
example.i:4: Syntax error in input.
example.i:4: Syntax error in input(1).
$ swig -python -Fmicrosoft example.i
example.i(4) : Syntax error in input.
example.i(4) : Syntax error in input(1).
</pre></div>
<H2><a name="Warnings_nn9"></a>15.9 Warning number reference</H2>

1
Doc/Manual/chapters
View file

@ -36,6 +36,7 @@ Pike.html
Python.html
R.html
Ruby.html
Scilab.html
Tcl.html
Extending.html
Doxygen.html