From 8288ac15a030b851c18dee2cf5e4e5769f0bc024 Mon Sep 17 00:00:00 2001 From: William S Fulton Date: Tue, 22 Dec 2015 07:54:57 +0000 Subject: [PATCH] Correct links in html documentation using new version of makechap.py Corrects position of heading text within A and H1, H2, ... elements. --- Doc/Manual/Allegrocl.html | 108 ++++++++--------- Doc/Manual/Android.html | 16 +-- Doc/Manual/Arguments.html | 22 ++-- Doc/Manual/CCache.html | 36 +++--- Doc/Manual/CPlusPlus11.html | 84 ++++++------- Doc/Manual/CSharp.html | 58 ++++----- Doc/Manual/Chicken.html | 40 +++---- Doc/Manual/Contract.html | 10 +- Doc/Manual/Customization.html | 32 ++--- Doc/Manual/D.html | 44 +++---- Doc/Manual/Extending.html | 100 ++++++++-------- Doc/Manual/Go.html | 56 ++++----- Doc/Manual/Guile.html | 42 +++---- Doc/Manual/Introduction.html | 28 ++--- Doc/Manual/Java.html | 214 +++++++++++++++++----------------- Doc/Manual/Javascript.html | 44 +++---- Doc/Manual/Library.html | 40 +++---- Doc/Manual/Lisp.html | 22 ++-- Doc/Manual/Lua.html | 88 +++++++------- Doc/Manual/Modula3.html | 40 +++---- Doc/Manual/Modules.html | 16 +-- Doc/Manual/Mzscheme.html | 8 +- Doc/Manual/Ocaml.html | 62 +++++----- Doc/Manual/Octave.html | 52 ++++----- Doc/Manual/Perl5.html | 108 ++++++++--------- Doc/Manual/Php.html | 50 ++++---- Doc/Manual/Pike.html | 24 ++-- Doc/Manual/Preface.html | 36 +++--- Doc/Manual/Preprocessor.html | 26 ++--- Doc/Manual/Python.html | 174 +++++++++++++-------------- Doc/Manual/R.html | 16 +-- Doc/Manual/Ruby.html | 200 +++++++++++++++---------------- Doc/Manual/SWIG.html | 108 ++++++++--------- Doc/Manual/SWIGPlus.html | 90 +++++++------- Doc/Manual/Scilab.html | 90 +++++++------- Doc/Manual/Scripting.html | 24 ++-- Doc/Manual/Tcl.html | 92 +++++++-------- Doc/Manual/Typemaps.html | 128 ++++++++++---------- Doc/Manual/Varargs.html | 20 ++-- Doc/Manual/Warnings.html | 36 +++--- Doc/Manual/Windows.html | 40 +++---- 41 files changed, 1262 insertions(+), 1262 deletions(-) diff --git a/Doc/Manual/Allegrocl.html b/Doc/Manual/Allegrocl.html index 8295bad1c..e76d67e4c 100644 --- a/Doc/Manual/Allegrocl.html +++ b/Doc/Manual/Allegrocl.html @@ -8,7 +8,7 @@ -

18 SWIG and Allegro Common Lisp

+

18 SWIG and Allegro Common Lisp

-

18.2.2 Foreign Wrappers

+

18.2.2 Foreign Wrappers

@@ -512,7 +512,7 @@ interested in generating an interface to C++. typemap.

-

18.2.3 FFI Wrappers

+

18.2.3 FFI Wrappers

@@ -593,7 +593,7 @@ char *xxx(); ff:def-foreign-call's.

-

18.2.4 Non-overloaded Defuns

+

18.2.4 Non-overloaded Defuns

@@ -606,7 +606,7 @@ char *xxx(); this function can be manipulated via the lout typemap.

-

18.2.5 Overloaded Defuns

+

18.2.5 Overloaded Defuns

@@ -622,7 +622,7 @@ char *xxx(); can be manipulated via the lout typemap.

-

18.2.6 What about constant and variable access?

+

18.2.6 What about constant and variable access?

@@ -635,7 +635,7 @@ char *xxx(); into the foreign module.

-

18.2.7 Object Wrapping

+

18.2.7 Object Wrapping

@@ -657,7 +657,7 @@ char *xxx(); foreign function interface.

-

18.3 Wrapping Details

+

18.3 Wrapping Details

@@ -665,7 +665,7 @@ char *xxx(); translated into lisp.

-

18.3.1 Namespaces

+

18.3.1 Namespaces

@@ -742,7 +742,7 @@ namespace car { function such as (car '(1 2 3).

-

18.3.2 Constants

+

18.3.2 Constants

@@ -803,7 +803,7 @@ namespace car { not use the -nocwrap command-line option.

-

18.3.3 Variables

+

18.3.3 Variables

@@ -881,7 +881,7 @@ globalvar> (globalvar.nnn::glob_float) -

18.3.4 Enumerations

+

18.3.4 Enumerations

@@ -957,7 +957,7 @@ EXPORT const int ACL_ENUM___FOO3__SWIG_0 = FOO3; -

18.3.5 Arrays

+

18.3.5 Arrays

@@ -1105,10 +1105,10 @@ namespace BAR { -

18.3.6 Classes and Structs and Unions (oh my!)

+

18.3.6 Classes and Structs and Unions (oh my!)

-

18.3.6.1 CLOS wrapping of

+

18.3.6.1 CLOS wrapping of

@@ -1123,7 +1123,7 @@ namespace BAR { integer values.

-

18.3.6.2 CLOS Inheritance

+

18.3.6.2 CLOS Inheritance

@@ -1136,7 +1136,7 @@ namespace BAR { parameter.

-

18.3.6.3 Member fields and functions

+

18.3.6.3 Member fields and functions

@@ -1152,7 +1152,7 @@ namespace BAR { the interface does nothing for friend directives,

-

18.3.6.4 Why not directly access C++ classes using foreign types?

+

18.3.6.4 Why not directly access C++ classes using foreign types?

@@ -1170,11 +1170,11 @@ namespace BAR { use the more robust wrapper functions.

-

18.3.7 Templates

+

18.3.7 Templates

-

18.3.7.1 Generating wrapper code for templates

+

18.3.7.1 Generating wrapper code for templates

@@ -1187,7 +1187,7 @@ namespace BAR { directive.

-

18.3.7.2 Implicit Template instantiation

+

18.3.7.2 Implicit Template instantiation

@@ -1197,7 +1197,7 @@ namespace BAR { class schema.

-

18.3.8 Typedef, Templates, and Synonym Types

+

18.3.8 Typedef, Templates, and Synonym Types

@@ -1277,7 +1277,7 @@ synonym> -

18.3.8.1 Choosing a primary type

+

18.3.8.1 Choosing a primary type

@@ -1298,7 +1298,7 @@ synonym> -

18.3.9 Function overloading/Parameter defaulting

+

18.3.9 Function overloading/Parameter defaulting

@@ -1461,7 +1461,7 @@ overload> -

18.3.10 Operator wrapping and Operator overloading

+

18.3.10 Operator wrapping and Operator overloading

@@ -1607,7 +1607,7 @@ opoverload> -

18.3.11 Varargs

+

18.3.11 Varargs

@@ -1628,7 +1628,7 @@ opoverload> with other ways such functions can be wrapped.

-

18.3.12 C++ Exceptions

+

18.3.12 C++ Exceptions

@@ -1640,7 +1640,7 @@ opoverload> implemented.

-

18.3.13 Pass by value, pass by reference

+

18.3.13 Pass by value, pass by reference

@@ -1652,7 +1652,7 @@ opoverload> newly defined types.

-

18.4 Typemaps

+

18.4 Typemaps

@@ -1663,7 +1663,7 @@ opoverload> on Typemaps for more information.

-

18.4.1 Code Generation in the C++ Wrapper

+

18.4.1 Code Generation in the C++ Wrapper

@@ -1693,7 +1693,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.4.1.1 IN Typemap

+

18.4.1.1 IN Typemap

@@ -1728,7 +1728,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.4.1.2 OUT Typemap

+

18.4.1.2 OUT Typemap

@@ -1752,7 +1752,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.4.1.3 CTYPE Typemap

+

18.4.1.3 CTYPE Typemap

@@ -1784,7 +1784,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) these common typemaps here.

-

18.4.2 Code generation in Lisp wrappers

+

18.4.2 Code generation in Lisp wrappers

@@ -1803,7 +1803,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) 16.3.1 Namespaces for details.

-

18.4.2.1 LIN Typemap

+

18.4.2.1 LIN Typemap

@@ -1846,7 +1846,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.4.2.2 LOUT Typemap

+

18.4.2.2 LOUT Typemap

@@ -1889,7 +1889,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.4.2.3 FFITYPE Typemap

+

18.4.2.3 FFITYPE Typemap

@@ -1939,7 +1939,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.4.2.4 LISPTYPE Typemap

+

18.4.2.4 LISPTYPE Typemap

@@ -1959,7 +1959,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.4.2.5 LISPCLASS Typemap

+

18.4.2.5 LISPCLASS Typemap

@@ -1983,7 +1983,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.4.3 Modifying SWIG behavior using typemaps

+

18.4.3 Modifying SWIG behavior using typemaps

@@ -2017,10 +2017,10 @@ return-val wrapper-name(parm0, parm1, ..., parmN) -

18.5 Identifier Converter functions

+

18.5 Identifier Converter functions

-

18.5.1 Creating symbols in the lisp environment

+

18.5.1 Creating symbols in the lisp environment

@@ -2041,11 +2041,11 @@ return-val wrapper-name(parm0, parm1, ..., parmN) of arguments.

-

18.5.2 Existing identifier-converter functions

+

18.5.2 Existing identifier-converter functions

Two basic identifier routines have been defined. -

18.5.2.1 identifier-convert-null

+

18.5.2.1 identifier-convert-null

@@ -2054,7 +2054,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) strings, from which a symbol will be created.

-

18.5.2.2 identifier-convert-lispify

+

18.5.2.2 identifier-convert-lispify

@@ -2063,7 +2063,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) same symbol transformations.

-

18.5.2.3 Default identifier to symbol conversions

+

18.5.2.3 Default identifier to symbol conversions

@@ -2072,7 +2072,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN) default naming conventions.

-

18.5.3 Defining your own identifier-converter

+

18.5.3 Defining your own identifier-converter

@@ -2128,7 +2128,7 @@ indicating the number of arguments passed to the routine indicated by this identifier.

-

18.5.4 Instructing SWIG to use a particular identifier-converter

+

18.5.4 Instructing SWIG to use a particular identifier-converter

diff --git a/Doc/Manual/Android.html b/Doc/Manual/Android.html index c90da21b4..2973f1de1 100644 --- a/Doc/Manual/Android.html +++ b/Doc/Manual/Android.html @@ -5,7 +5,7 @@ -

19 SWIG and Android

+

19 SWIG and Android

-

10.1.3 Output parameters

+

10.1.3 Output parameters

@@ -314,7 +314,7 @@ iresult, dresult = foo(3.5, 2) -

10.1.4 Input/Output parameters

+

10.1.4 Input/Output parameters

@@ -379,7 +379,7 @@ rather than directly overwriting the value of the original input object. SWIG. Backwards compatibility is preserved, but deprecated.

-

10.1.5 Using different names

+

10.1.5 Using different names

@@ -413,7 +413,7 @@ Typemap declarations are lexically scoped so a typemap takes effect from the poi file or a matching %clear declaration.

-

10.2 Applying constraints to input values

+

10.2 Applying constraints to input values

@@ -423,7 +423,7 @@ insure that a value is positive, or that a pointer is non-NULL. This can be accomplished including the constraints.i library file.

-

10.2.1 Simple constraint example

+

10.2.1 Simple constraint example

@@ -449,7 +449,7 @@ the arguments violate the constraint condition, a scripting language exception will be raised. As a result, it is possible to catch bad values, prevent mysterious program crashes and so on.

-

10.2.2 Constraint methods

+

10.2.2 Constraint methods

@@ -465,7 +465,7 @@ NONNULL Non-NULL pointer (pointers only). -

10.2.3 Applying constraints to new datatypes

+

10.2.3 Applying constraints to new datatypes

diff --git a/Doc/Manual/CCache.html b/Doc/Manual/CCache.html index 0ee94c172..88922a8ea 100644 --- a/Doc/Manual/CCache.html +++ b/Doc/Manual/CCache.html @@ -6,7 +6,7 @@ -

17 Using SWIG with ccache - ccache-swig(1) manpage

+

17 Using SWIG with ccache - ccache-swig(1) manpage

-

17.14 HISTORY

+

17.14 HISTORY

@@ -422,7 +422,7 @@ I wrote ccache because I wanted to get a bit more speed out of a compiler cache and I wanted to remove some of the limitations of the shell-script version.

-

17.15 DIFFERENCES FROM COMPILERCACHE

+

17.15 DIFFERENCES FROM COMPILERCACHE

@@ -440,7 +440,7 @@ are:

  • ccache avoids a double call to cpp on a cache miss

    -

    17.16 CREDITS

    +

    17.16 CREDITS

    @@ -452,7 +452,7 @@ Thanks to the following people for their contributions to ccache

  • Paul Russell for many suggestions and the debian packaging

    -

    17.17 AUTHOR

    +

    17.17 AUTHOR

    diff --git a/Doc/Manual/CPlusPlus11.html b/Doc/Manual/CPlusPlus11.html index b7e1d638c..021ad418d 100644 --- a/Doc/Manual/CPlusPlus11.html +++ b/Doc/Manual/CPlusPlus11.html @@ -6,7 +6,7 @@ -

    7 SWIG and C++11

    +

    7 SWIG and C++11

      @@ -61,7 +61,7 @@ -

      7.1 Introduction

      +

      7.1 Introduction

      This chapter gives you a brief overview about the SWIG @@ -76,10 +76,10 @@ users are welcome to help by adapting the existing container interface files and as a patch for inclusion in future versions of SWIG.

      -

      7.2 Core language changes

      +

      7.2 Core language changes

      -

      7.2.1 Rvalue reference and move semantics

      +

      7.2.1 Rvalue reference and move semantics

      @@ -121,7 +121,7 @@ example.i:18: Warning 503: Can't wrap 'operator =' unless renamed to a valid ide

    -

    7.2.2 Generalized constant expressions

    +

    7.2.2 Generalized constant expressions

    SWIG parses and identifies the keyword constexpr, but cannot fully utilise it. @@ -138,7 +138,7 @@ constexpr int YYY = XXX() + 100; When either of these is used from a target language, a runtime call is made to obtain the underlying constant.

    -

    7.2.3 Extern template

    +

    7.2.3 Extern template

    SWIG correctly parses the keywords extern template. @@ -151,7 +151,7 @@ extern template class std::vector<int>; // C++11 explicit instantiation su %template(VectorInt) std::vector<int>; // SWIG instantiation

    • -

    7.2.4 Initializer lists

    +

    7.2.4 Initializer lists

    @@ -283,7 +283,7 @@ Note that the default typemap for std::initializer_list does nothing bu and hence any user supplied typemaps will override it and suppress the warning.

    -

    7.2.5 Uniform initialization

    +

    7.2.5 Uniform initialization

    The curly brackets {} for member initialization are fully @@ -316,7 +316,7 @@ AltStruct var2{2, 4.3}; // calls the constructor 142.15 -

    7.2.6 Type inference

    +

    7.2.6 Type inference

    SWIG supports decltype() with some limitations. Single @@ -333,13 +333,13 @@ int i; int j; decltype(i+j) k; // syntax error -

    7.2.7 Range-based for-loop

    +

    7.2.7 Range-based for-loop

    This feature is part of the implementation block only. SWIG ignores it.

    -

    7.2.8 Lambda functions and expressions

    +

    7.2.8 Lambda functions and expressions

    SWIG correctly parses most of the Lambda functions syntax. For example:

    @@ -365,7 +365,7 @@ auto six = [](int x, int y) { return x+y; }(4, 2); Better support should be available in a later release.

    -

    7.2.9 Alternate function syntax

    +

    7.2.9 Alternate function syntax

    SWIG fully supports the new definition of functions. For example:

    @@ -400,7 +400,7 @@ auto SomeStruct::FuncName(int x, int y) -> int { auto square(float a, float b) -> decltype(a); -

    7.2.10 Object construction improvement

    +

    7.2.10 Object construction improvement

    @@ -463,7 +463,7 @@ public: }; -

    7.2.11 Explicit overrides and final

    +

    7.2.11 Explicit overrides and final

    @@ -487,12 +487,12 @@ struct DerivedStruct : BaseStruct { -

    7.2.12 Null pointer constant

    +

    7.2.12 Null pointer constant

    The nullptr constant is mostly unimportant in wrappers. In the few places it has an effect, it is treated like NULL.

    -

    7.2.13 Strongly typed enumerations

    +

    7.2.13 Strongly typed enumerations

    SWIG supports strongly typed enumerations and parses the new enum class syntax and forward declarator for the enums, such as:

    @@ -548,7 +548,7 @@ The equivalent in Java is: System.out.println(Color.RainbowColors.Red.swigValue() + " " + Color.WarmColors.Red.swigValue() + " " + Color.PrimeColors.Red.swigValue()); -

    7.2.14 Double angle brackets

    +

    7.2.14 Double angle brackets

    SWIG correctly parses the symbols >> as closing the @@ -559,7 +559,7 @@ shift operator >> otherwise.

    std::vector<std::vector<int>> myIntTable; -

    7.2.15 Explicit conversion operators

    +

    7.2.15 Explicit conversion operators

    SWIG correctly parses the keyword explicit for operators in addition to constructors now. @@ -602,7 +602,7 @@ Conversion operators either with or without explicit need renaming to a them available as a normal proxy method.

    -

    7.2.16 Alias templates

    +

    7.2.16 Alias templates

    @@ -656,7 +656,7 @@ example.i:17: Warning 341: The 'using' keyword in type aliasing is not fully sup typedef void (*PFD)(double); // The old style -

    7.2.17 Unrestricted unions

    +

    7.2.17 Unrestricted unions

    SWIG fully supports any type inside a union even if it does not @@ -682,7 +682,7 @@ union P { } p1; -

    7.2.18 Variadic templates

    +

    7.2.18 Variadic templates

    SWIG supports the variadic templates syntax (inside the <> @@ -717,7 +717,7 @@ const int SIZE = sizeof...(ClassName<int, int>); In the above example SIZE is of course wrapped as a constant.

    -

    7.2.19 New string literals

    +

    7.2.19 New string literals

    SWIG supports wide string and Unicode string constants and raw string literals.

    @@ -747,7 +747,7 @@ Note: There is a bug currently where SWIG's preprocessor incorrectly parses an o inside raw string literals.

    -

    7.2.20 User-defined literals

    +

    7.2.20 User-defined literals

    @@ -814,7 +814,7 @@ OutputType var2 = 1234_suffix; OutputType var3 = 3.1416_suffix; -

    7.2.21 Thread-local storage

    +

    7.2.21 Thread-local storage

    SWIG correctly parses the thread_local keyword. For example, variables @@ -834,7 +834,7 @@ A variable will be thread local if accessed from different threads from the targ same way that it will be thread local if accessed from C++ code.

    -

    7.2.22 Explicitly defaulted functions and deleted functions

    +

    7.2.22 Explicitly defaulted functions and deleted functions

    SWIG handles explicitly defaulted functions, that is, = default added to a function declaration. Deleted definitions, which are also called deleted functions, have = delete added to the function declaration. @@ -872,12 +872,12 @@ This is a C++ compile time check and SWIG does not make any attempt to detect if so in this case it is entirely possible to pass an int instead of a double to f from Java, Python etc.

    -

    7.2.23 Type long long int

    +

    7.2.23 Type long long int

    SWIG correctly parses and uses the new long long type already introduced in C99 some time ago.

    -

    7.2.24 Static assertions

    +

    7.2.24 Static assertions

    @@ -892,7 +892,7 @@ struct Check { }; -

    7.2.25 Allow sizeof to work on members of classes without an explicit object

    +

    7.2.25 Allow sizeof to work on members of classes without an explicit object

    @@ -913,7 +913,7 @@ const int SIZE = sizeof(A::member); // does not work with C++03. Okay with C++11 8 -

    7.2.26 Exception specifications and noexcept

    +

    7.2.26 Exception specifications and noexcept

    @@ -929,7 +929,7 @@ int noex2(int) noexcept(true); int noex3(int, bool) noexcept(false); -

    7.2.27 Control and query object alignment

    +

    7.2.27 Control and query object alignment

    @@ -961,7 +961,7 @@ Use the preprocessor to work around this for now: -

    7.2.28 Attributes

    +

    7.2.28 Attributes

    @@ -974,10 +974,10 @@ int [[attr1]] i [[attr2, attr3]]; [[noreturn, nothrow]] void f [[noreturn]] (); -

    7.3 Standard library changes

    +

    7.3 Standard library changes

    -

    7.3.1 Threading facilities

    +

    7.3.1 Threading facilities

    SWIG does not currently wrap or use any of the new threading @@ -985,7 +985,7 @@ classes introduced (thread, mutex, locks, condition variables, task). The main r SWIG target languages offer their own threading facilities so there is limited use for them.

    -

    7.3.2 Tuple types

    +

    7.3.2 Tuple types

    @@ -993,7 +993,7 @@ SWIG does not provide library files for the new tuple types yet. Variadic template support requires further work to provide substantial tuple wrappers.

    -

    7.3.3 Hash tables

    +

    7.3.3 Hash tables

    @@ -1001,14 +1001,14 @@ The new hash tables in the STL are unordered_set, unordered_multise These are not available in SWIG, but in principle should be easily implemented by adapting the current STL containers.

    -

    7.3.4 Regular expressions

    +

    7.3.4 Regular expressions

    While SWIG could provide wrappers for the new C++11 regular expressions classes, there is little need as the target languages have their own regular expression facilities.

    -

    7.3.5 General-purpose smart pointers

    +

    7.3.5 General-purpose smart pointers

    @@ -1017,12 +1017,12 @@ Please see the shared_ptr smart po There is no special smart pointer handling available for std::weak_ptr and std::unique_ptr yet.

    -

    7.3.6 Extensible random number facility

    +

    7.3.6 Extensible random number facility

    This feature extends and standardizes the standard library only and does not effect the C++ language nor SWIG.

    -

    7.3.7 Wrapper reference

    +

    7.3.7 Wrapper reference

    @@ -1033,7 +1033,7 @@ Users would need to write their own typemaps if wrapper references are being use

    -

    7.3.8 Polymorphous wrappers for function objects

    +

    7.3.8 Polymorphous wrappers for function objects

    @@ -1064,7 +1064,7 @@ t = Test() b = t(1,2) # invoke C++ function object -

    7.3.9 Type traits for metaprogramming

    +

    7.3.9 Type traits for metaprogramming

    The type_traits functions to support C++ metaprogramming is useful at compile time and is aimed specifically at C++ development:

    @@ -1114,7 +1114,7 @@ Then the appropriate algorithm can be called for the subset of types given by th 2 -

    7.3.10 Uniform method for computing return type of function objects

    +

    7.3.10 Uniform method for computing return type of function objects

    diff --git a/Doc/Manual/CSharp.html b/Doc/Manual/CSharp.html index 76590d1cc..e6829aabc 100644 --- a/Doc/Manual/CSharp.html +++ b/Doc/Manual/CSharp.html @@ -5,7 +5,7 @@ -

    20 SWIG and C#

    +

    20 SWIG and C#

      @@ -53,7 +53,7 @@ -

      20.1 Introduction

      +

      20.1 Introduction

      @@ -73,7 +73,7 @@ The Microsoft Developer Network (MSDN) h Monodoc, available from the Mono project, has a very useful section titled Interop with native libraries.

      -

      20.1.1 SWIG 2 Compatibility

      +

      20.1.1 SWIG 2 Compatibility

      @@ -81,7 +81,7 @@ In order to minimize name collisions between names generated based on input to S

      -

      20.1.2 Additional command line options

      +

      20.1.2 Additional command line options

      @@ -133,7 +133,7 @@ Note that the file extension (.cs) will not be automatically added and needs to Due to possible compiler limits it is not advisable to use -outfile for large projects.

      -

      20.2 Differences to the Java module

      +

      20.2 Differences to the Java module

      @@ -546,7 +546,7 @@ Windows users can also get the examples working using a Cygwin or MinGW environment for automatic configuration of the example makefiles. Any one of the three C# compilers (Portable.NET, Mono or Microsoft) can be detected from within a Cygwin or Mingw environment if installed in your path. -

      20.3 Void pointers

      +

      20.3 Void pointers

      @@ -564,7 +564,7 @@ void * f(void *v);

    -

    20.4 C# Arrays

    +

    20.4 C# Arrays

    @@ -576,7 +576,7 @@ with one of the following three approaches; namely the SWIG C arrays library, P/ pinned arrays.

    -

    20.4.1 The SWIG C arrays library

    +

    20.4.1 The SWIG C arrays library

    @@ -613,7 +613,7 @@ example.print_array(c.cast()); // Pass to C -

    20.4.2 Managed arrays using P/Invoke default array marshalling

    +

    20.4.2 Managed arrays using P/Invoke default array marshalling

    @@ -740,7 +740,7 @@ and intermediary class method -

    20.4.3 Managed arrays using pinning

    +

    20.4.3 Managed arrays using pinning

    @@ -835,7 +835,7 @@ public static extern void myArrayCopy(global::System.IntPtr jarg1, global::Syste -

    20.5 C# Exceptions

    +

    20.5 C# Exceptions

    @@ -932,7 +932,7 @@ set so should only be used when a C# exception is not created.

    -

    20.5.1 C# exception example using "check" typemap

    +

    20.5.1 C# exception example using "check" typemap

    @@ -1114,7 +1114,7 @@ method and C# code does not handle pending exceptions via the canthrow attribute Actually it will issue this warning for any function beginning with SWIG_CSharpSetPendingException.

    -

    20.5.2 C# exception example using %exception

    +

    20.5.2 C# exception example using %exception

    @@ -1180,7 +1180,7 @@ The managed code generated does check for the pending exception as mentioned ear -

    20.5.3 C# exception example using exception specifications

    +

    20.5.3 C# exception example using exception specifications

    @@ -1237,7 +1237,7 @@ SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) { Multiple catch handlers are generated should there be more than one exception specifications declared.

    -

    20.5.4 Custom C# ApplicationException example

    +

    20.5.4 Custom C# ApplicationException example

    @@ -1371,7 +1371,7 @@ try { -

    20.6 C# Directors

    +

    20.6 C# Directors

    @@ -1384,7 +1384,7 @@ The following sections provide information on the C# director implementation and However, the Java directors section should also be read in order to gain more insight into directors.

    -

    20.6.1 Directors example

    +

    20.6.1 Directors example

    @@ -1505,7 +1505,7 @@ CSharpDerived - UIntMethod(123) -

    20.6.2 Directors implementation

    +

    20.6.2 Directors implementation

    @@ -1688,7 +1688,7 @@ void SwigDirector_Base::BaseBoolMethod(Base const &b, bool flag) { -

    20.6.3 Director caveats

    +

    20.6.3 Director caveats

    @@ -1736,7 +1736,7 @@ However, a call from C# to CSharpDefaults.DefaultMethod() will of cours should pass the call on to CSharpDefaults.DefaultMethod(int)using the C++ default value, as shown above.

    -

    20.7 Multiple modules

    +

    20.7 Multiple modules

    @@ -1771,7 +1771,7 @@ the [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrows if you don't want users to easily stumble upon these so called 'internal workings' of the wrappers.

    -

    20.8 C# Typemap examples

    +

    20.8 C# Typemap examples

    This section includes a few examples of typemaps. For more examples, you @@ -1779,7 +1779,7 @@ might look at the files "csharp.swg" and "typemaps.i" in the SWIG library. -

    20.8.1 Memory management when returning references to member variables

    +

    20.8.1 Memory management when returning references to member variables

    @@ -1903,7 +1903,7 @@ public class Bike : global::System.IDisposable { Note the addReference call.

    -

    20.8.2 Memory management for objects passed to the C++ layer

    +

    20.8.2 Memory management for objects passed to the C++ layer

    @@ -2022,7 +2022,7 @@ The 'cscode' typemap simply adds in the specified code into the C# proxy class. -

    20.8.3 Date marshalling using the csin typemap and associated attributes

    +

    20.8.3 Date marshalling using the csin typemap and associated attributes

    @@ -2308,7 +2308,7 @@ public class example { -

    20.8.4 A date example demonstrating marshalling of C# properties

    +

    20.8.4 A date example demonstrating marshalling of C# properties

    @@ -2408,7 +2408,7 @@ Some points to note:

  • The 'csin' typemap has 'pre', 'post' and 'cshin' attributes, and these are all ignored in the property set. The code in these attributes must instead be replicated within the 'csvarin' typemap. The line creating the temp$csinput variable is such an example; it is identical to what is in the 'pre' attribute. -

    20.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors

    +

    20.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors

    @@ -2470,7 +2470,7 @@ Pay special attention to the memory management issues, using these attributes.

    -

    20.8.6 Turning wrapped classes into partial classes

    +

    20.8.6 Turning wrapped classes into partial classes

    @@ -2570,7 +2570,7 @@ demonstrating that the class contains methods calling both unmanaged code - The following example is an alternative approach to adding managed code to the generated proxy class.

    -

    20.8.7 Extending proxy classes with additional C# code

    +

    20.8.7 Extending proxy classes with additional C# code

    @@ -2609,7 +2609,7 @@ public class ExtendMe : global::System.IDisposable { -

    20.8.8 Underlying type for enums

    +

    20.8.8 Underlying type for enums

    diff --git a/Doc/Manual/Chicken.html b/Doc/Manual/Chicken.html index 82861c31c..88cff55a9 100644 --- a/Doc/Manual/Chicken.html +++ b/Doc/Manual/Chicken.html @@ -8,7 +8,7 @@ -

    21 SWIG and Chicken

    +

    21 SWIG and Chicken

      @@ -72,7 +72,7 @@

      -

      21.1 Preliminaries

      +

      21.1 Preliminaries

      @@ -89,7 +89,7 @@ directory for the basic steps to run SWIG CHICKEN.

      -

      21.1.1 Running SWIG in C mode

      +

      21.1.1 Running SWIG in C mode

      @@ -122,7 +122,7 @@ object files and linked into your project.

      -

      21.1.2 Running SWIG in C++ mode

      +

      21.1.2 Running SWIG in C++ mode

      @@ -151,10 +151,10 @@ object files and linked into your project.

      -

      21.2 Code Generation

      +

      21.2 Code Generation

      -

      21.2.1 Naming Conventions

      +

      21.2.1 Naming Conventions

      @@ -170,7 +170,7 @@ %rename SWIG directive in the SWIG interface file.

      -

      21.2.2 Modules

      +

      21.2.2 Modules

      @@ -192,7 +192,7 @@ (uses modulename)) CHICKEN Scheme form.

      -

      21.2.3 Constants and Variables

      +

      21.2.3 Constants and Variables

      @@ -229,7 +229,7 @@ for info on how to apply the %feature.

      -

      21.2.4 Functions

      +

      21.2.4 Functions

      @@ -248,7 +248,7 @@ parameters). The return values can then be accessed with (call-with-values).

      -

      21.2.5 Exceptions

      +

      21.2.5 Exceptions

      The SWIG chicken module has support for exceptions thrown from @@ -290,7 +290,7 @@

    -

    21.3 TinyCLOS

    +

    21.3 TinyCLOS

    @@ -333,7 +333,7 @@

    -

    21.4 Linkage

    +

    21.4 Linkage

    @@ -354,7 +354,7 @@

    -

    21.4.1 Static binary or shared library linked at compile time

    +

    21.4.1 Static binary or shared library linked at compile time

    We can easily use csc to build a static binary.

    @@ -395,7 +395,7 @@ in which case the test script does not need to be linked with example.so. The t be run with csi.

    -

    21.4.2 Building chicken extension libraries

    +

    21.4.2 Building chicken extension libraries

    Building a shared library like in the above section only works if the library @@ -453,7 +453,7 @@ distributed and used by anyone, even if SWIG is not installed.

    See the Examples/chicken/egg directory in the SWIG source for an example that builds two eggs, one using the first method and one using the second method.

    -

    21.4.3 Linking multiple SWIG modules with TinyCLOS

    +

    21.4.3 Linking multiple SWIG modules with TinyCLOS

    Linking together multiple modules that share type information using the %import @@ -477,7 +477,7 @@ with (declare (uses ...)). To create an extension library or an egg, just create a module_load.scm file that (declare (uses ...)) all the modules.

    -

    21.5 Typemaps

    +

    21.5 Typemaps

    @@ -486,7 +486,7 @@ all the modules.

    Lib/chicken/chicken.swg.

    -

    21.6 Pointers

    +

    21.6 Pointers

    @@ -519,7 +519,7 @@ all the modules.

    type. flags is either zero or SWIG_POINTER_DISOWN (see below).

    -

    21.6.1 Garbage collection

    +

    21.6.1 Garbage collection

    If the owner flag passed to SWIG_NewPointerObj is 1, NewPointerObj will add a @@ -550,7 +550,7 @@ all the modules.

    must be called manually.

    -

    21.7 Unsupported features and known problems

    +

    21.7 Unsupported features and known problems

    -

    21.7.1 TinyCLOS problems with Chicken version <= 1.92

    +

    21.7.1 TinyCLOS problems with Chicken version <= 1.92

    In Chicken versions equal to or below 1.92, TinyCLOS has a limitation such that generic methods do not properly work on methods diff --git a/Doc/Manual/Contract.html b/Doc/Manual/Contract.html index 35bc874ef..660daf9fc 100644 --- a/Doc/Manual/Contract.html +++ b/Doc/Manual/Contract.html @@ -6,7 +6,7 @@ -

    13 Contracts

    +

    13 Contracts

      @@ -38,7 +38,7 @@ When one of the rules is violated by a script, a runtime exception is generated rather than having the program continue to execute.

      -

      13.1 The %contract directive

      +

      13.1 The %contract directive

      @@ -94,7 +94,7 @@ RuntimeError: Contract violation: require: (arg1>=0)

    -

    13.2 %contract and classes

    +

    13.2 %contract and classes

    @@ -173,7 +173,7 @@ specified for the derived class all must hold. In the above example, this means that both the arguments to Spam::bar must be positive.

    -

    13.3 Constant aggregation and %aggregate_check

    +

    13.3 Constant aggregation and %aggregate_check

    @@ -262,7 +262,7 @@ Regrettably, there is no automatic way to perform similar checks with enums valu release.

    -

    13.4 Notes

    +

    13.4 Notes

    diff --git a/Doc/Manual/Customization.html b/Doc/Manual/Customization.html index 8e26a7e8a..9ab0a6269 100644 --- a/Doc/Manual/Customization.html +++ b/Doc/Manual/Customization.html @@ -6,7 +6,7 @@ -

    12 Customization Features

    +

    12 Customization Features

      @@ -45,7 +45,7 @@ of exception handling is presented. Then, a more general-purpose customization mechanism known as "features" is described.

      -

      12.1 Exception handling with %exception

      +

      12.1 Exception handling with %exception

      @@ -100,7 +100,7 @@ for exception handling. That directive is deprecated--%exception provides the same functionality, but is substantially more flexible.

      -

      12.1.1 Handling exceptions in C code

      +

      12.1.1 Handling exceptions in C code

      @@ -166,7 +166,7 @@ Each target language has its own approach to creating a runtime error/exception and for Perl it is the croak method shown above.

      -

      12.1.2 Exception handling with longjmp()

      +

      12.1.2 Exception handling with longjmp()

      @@ -240,7 +240,7 @@ Note: This implementation is only intended to illustrate the general idea. To m modify it to handle nested try declarations.

      -

      12.1.3 Handling C++ exceptions

      +

      12.1.3 Handling C++ exceptions

      @@ -275,7 +275,7 @@ class OutOfMemory {};

    -

    12.1.4 Exception handlers for variables

    +

    12.1.4 Exception handlers for variables

    @@ -300,7 +300,7 @@ The %allowexception feature works like any other feature and so can be -

    12.1.5 Defining different exception handlers

    +

    12.1.5 Defining different exception handlers

    @@ -437,7 +437,7 @@ declarations. However, it never really worked that well and the new %exception directive is much better.

    -

    12.1.6 Special variables for %exception

    +

    12.1.6 Special variables for %exception

    @@ -540,7 +540,7 @@ Below shows the expansions for the 1st of the overloaded something wrap -

    12.1.7 Using The SWIG exception library

    +

    12.1.7 Using The SWIG exception library

    @@ -595,7 +595,7 @@ SWIG_NullReferenceError The SWIG_exception() function can also be used in typemaps.

    -

    12.2 Object ownership and %newobject

    +

    12.2 Object ownership and %newobject

    @@ -752,7 +752,7 @@ char *strdup(const char *s); The results might not be what you expect.

    -

    12.3 Features and the %feature directive

    +

    12.3 Features and the %feature directive

    @@ -834,7 +834,7 @@ The following are all equivalent: The syntax in the first variation will generate the { } delimiters used whereas the other variations will not.

    -

    12.3.1 Feature attributes

    +

    12.3.1 Feature attributes

    @@ -875,7 +875,7 @@ In the following example, MyExceptionClass is the name of the Java clas Further details can be obtained from the Java exception handling section.

    -

    12.3.2 Feature flags

    +

    12.3.2 Feature flags

    @@ -973,7 +973,7 @@ in the swig.swg Library file. The following shows the alternative synta The concept of clearing features is discussed next.

    -

    12.3.3 Clearing features

    +

    12.3.3 Clearing features

    @@ -1066,7 +1066,7 @@ The three macros below show this for the "except" feature: -

    12.3.4 Features and default arguments

    +

    12.3.4 Features and default arguments

    @@ -1141,7 +1141,7 @@ specifying or not specifying default arguments in a feature is not applicable as in SWIG-1.3.23 when the approach to wrapping methods with default arguments was changed.

    -

    12.3.5 Feature example

    +

    12.3.5 Feature example

    diff --git a/Doc/Manual/D.html b/Doc/Manual/D.html index 984b81bb8..8007ccbb6 100644 --- a/Doc/Manual/D.html +++ b/Doc/Manual/D.html @@ -6,7 +6,7 @@ -

    22 SWIG and D

    +

    22 SWIG and D

      @@ -41,7 +41,7 @@ -

      22.1 Introduction

      +

      22.1 Introduction

      From the D Programming Language web site: D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. [...] The D language is statically typed and compiles directly to machine code. As such, it is not very surprising that D is able to directly interface with C libraries. Why would a SWIG module for D be needed then in the first place?

      @@ -53,7 +53,7 @@

      To help addressing these issues, the SWIG C# module has been forked to support D. Is has evolved quite a lot since then, but there are still many similarities, so if you do not find what you are looking for on this page, it might be worth having a look at the chapter on C# (and also on Java, since the C# module was in turn forked from it).

      -

      22.2 Command line invocation

      +

      22.2 Command line invocation

      To activate the D module, pass the -d option to SWIG at the command line. The same standard command line switches as with any other language module are available, plus the following D specific ones:

      @@ -83,10 +83,10 @@ -

      22.3 Typemaps

      +

      22.3 Typemaps

      -

      22.3.1 C# <-> D name comparison

      +

      22.3.1 C# <-> D name comparison

      If you already know the SWIG C# module, you might find the following name comparison table useful:

      @@ -112,7 +112,7 @@
    -

    22.3.2 ctype, imtype, dtype

    +

    22.3.2 ctype, imtype, dtype

    Mapping of types between the C/C++ library, the C/C++ library wrapper exposing the C functions, the D wrapper module importing these functions and the D proxy code.

    @@ -120,7 +120,7 @@

    The ctype typemap is used to determine the types to use in the C wrapper functions. The types from the imtype typemap are used in the extern(C) declarations of these functions in the intermediary D module. The dtype typemap contains the D types used in the D proxy module/class.

    -

    22.3.3 in, out, directorin, directorout

    +

    22.3.3 in, out, directorin, directorout

    Used for converting between the types for C/C++ and D when generating the code for the wrapper functions (on the C++ side).

    @@ -130,7 +130,7 @@

    The directorin typemap is used to convert parameters to the type used in the D director callback function, its return value is processed by directorout (see below).

    -

    22.3.4 din, dout, ddirectorin, ddirectorout

    +

    22.3.4 din, dout, ddirectorin, ddirectorout

    Typemaps for code generation in D proxy and type wrapper classes.

    @@ -157,13 +157,13 @@ dtype DClass.method(dtype a) -

    22.3.5 typecheck typemaps

    +

    22.3.5 typecheck typemaps

    Because, unlike many scripting languages supported by SWIG, D does not need any dynamic dispatch helper to access an overloaded function, the purpose of these is merely to issue a warning for overloaded C++ functions that cannot be overloaded in D (as more than one C++ type maps to a single D type).

    -

    22.3.6 Code injection typemaps

    +

    22.3.6 Code injection typemaps

    These typemaps are used for generating the skeleton of proxy classes for C++ types.

    @@ -175,7 +175,7 @@

    dconstructor, ddestructor, ddispose and ddispose_derived are used to generate the class constructor, destructor and dispose() method, respectively. The auxiliary code for handling the pointer to the C++ object is stored in dbody and dbody_derived. You can override them for specific types.

    -

    22.3.7 Special variable macros

    +

    22.3.7 Special variable macros

    The standard SWIG special variables are available for use within typemaps as described in the Typemaps documentation, for example $1, $input, $result etc.

    @@ -295,7 +295,7 @@ $importtype(AnotherInterface) -

    22.4 %features

    +

    22.4 %features

    The D module defines a number of directives which modify the SWIG features set globally or for a specific declaration:

    @@ -325,7 +325,7 @@ struct A { -

    22.5 Pragmas

    +

    22.5 Pragmas

    There are a few SWIG pragmas specific to the D module, which you can use to influence the D code SWIG generates:

    @@ -364,7 +364,7 @@ struct A { -

    22.6 D Exceptions

    +

    22.6 D Exceptions

    Out of the box, C++ exceptions are fundamentally incompatible to their equivalent in the D world and cannot simply be propagated to a calling D method. There is, however, an easy way to solve this problem: Just catch the exception in the C/C++ wrapper layer, pass the contents to D, and make the wrapper code rethrow the exception in the D world.

    @@ -374,7 +374,7 @@ struct A {

    As this feature is implemented in exactly the same way it is for C#, please see the C# documentation for a more detailed explanation.

    -

    22.7 D Directors

    +

    22.7 D Directors

    When the directors feature is activated, SWIG generates extra code on both the C++ and the D side to enable cross-language polymorphism. Essentially, this means that if you subclass a proxy class in D, C++ code can access any overridden virtual methods just as if you created a derived class in C++.

    @@ -383,16 +383,16 @@ struct A {

    -

    22.8 Other features

    +

    22.8 Other features

    -

    22.8.1 Extended namespace support (nspace)

    +

    22.8.1 Extended namespace support (nspace)

    By default, SWIG flattens all C++ namespaces into a single target language namespace, but as for Java and C#, the nspace feature is supported for D. If it is active, C++ namespaces are mapped to D packages/modules. Note, however, that like for the other languages, free variables and functions are not supported yet; currently, they are all allows written to the main proxy D module.

    -

    22.8.2 Native pointer support

    +

    22.8.2 Native pointer support

    Contrary to many of the scripting languages supported by SWIG, D fully supports C-style pointers. The D module thus includes a custom mechanism to wrap C pointers directly as D pointers where applicable, that is, if the type that is pointed to is represented the same in C and D (on the bit-level), dubbed a primitive type below.

    @@ -404,7 +404,7 @@ struct A {

    To determine if a type should be considered primitive, the cprimitive attribute on its dtype attribute is used. For example, the dtype typemap for float has cprimitive="1", so the code from the nativepointer attribute is taken into account e.g. for float ** or the function pointer float (*)(float *).

    -

    22.8.3 Operator overloading

    +

    22.8.3 Operator overloading

    The D module comes with basic operator overloading support for both D1 and D2. There are, however, a few limitations arising from conceptual differences between C++ and D:

    @@ -416,7 +416,7 @@ struct A {

    There are also some cases where the operators can be translated to D, but the differences in the implementation details are big enough that a rather involved scheme would be required for automatic wrapping them, which has not been implemented yet. This affects, for example, the array subscript operator, [], in combination with assignments - while operator [] in C++ simply returns a reference which is then written to, D resorts to a separate opIndexAssign method -, or implicit casting (which was introduced in D2 via alias this). Despite the lack of automatic support, manually handling these cases should be perfectly possible.

    -

    22.8.4 Running the test-suite

    +

    22.8.4 Running the test-suite

    As with any other language, the SWIG test-suite can be built for D using the *-d-test-suite targets of the top-level Makefile. By default, D1 is targeted, to build it with D2, use the optional D_VERSION variable, e.g. make check-d-test-suite D_VERSION=2.

    @@ -424,14 +424,14 @@ struct A {

    Note: If you want to use GDC on Linux or another platform which requires you to link libdl for dynamically loading the shared library, you might have to add -ldl manually to the d_compile target in Examples/Makefile, because GDC does not currently honor the pragma(lib,...) statement.

    -

    22.9 D Typemap examples

    +

    22.9 D Typemap examples

    There are no D-specific typemap examples yet. However, with the above name comparison table, you should be able to get an idea what can be done by looking at the corresponding C# section.

    -

    22.10 Work in progress and planned features

    +

    22.10 Work in progress and planned features

    There are a couple of features which are not implemented yet, but would be very useful and might be added in the near future:

    diff --git a/Doc/Manual/Extending.html b/Doc/Manual/Extending.html index 59c63403d..7519dca94 100644 --- a/Doc/Manual/Extending.html +++ b/Doc/Manual/Extending.html @@ -6,7 +6,7 @@ -

    41 Extending SWIG to support new languages

    +

    41 Extending SWIG to support new languages

      @@ -75,7 +75,7 @@ -

      41.1 Introduction

      +

      41.1 Introduction

      @@ -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.

      -

      41.2 Prerequisites

      +

      41.2 Prerequisites

      @@ -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.

      -

      41.3 The Big Picture

      +

      41.3 The Big Picture

      @@ -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.

      -

      41.4 Execution Model

      +

      41.4 Execution Model

      @@ -203,7 +203,7 @@ latter stage of compilation. The next few sections briefly describe some of these stages.

      -

      41.4.1 Preprocessing

      +

      41.4.1 Preprocessing

      @@ -284,7 +284,7 @@ been expanded as well as everything else that goes into the low-level construction of the wrapper code.

      -

      41.4.2 Parsing

      +

      41.4.2 Parsing

      @@ -385,7 +385,7 @@ returning a foo and taking types a and b as arguments).

      -

      41.4.3 Parse Trees

      +

      41.4.3 Parse Trees

      @@ -640,7 +640,7 @@ $ swig -c++ -python -debug-module 4 example.i

    -

    41.4.4 Attribute namespaces

    +

    41.4.4 Attribute namespaces

    @@ -659,7 +659,7 @@ that matches the name of the target language. For example, python:foo perl:foo.

    -

    41.4.5 Symbol Tables

    +

    41.4.5 Symbol Tables

    @@ -750,7 +750,7 @@ example.i:5. Previous declaration is foo_i(int ) -

    41.4.6 The %feature directive

    +

    41.4.6 The %feature directive

    @@ -806,7 +806,7 @@ For example, the exception code above is simply stored without any modifications.

    -

    41.4.7 Code Generation

    +

    41.4.7 Code Generation

    @@ -928,7 +928,7 @@ public : The role of these functions is described shortly.

    -

    41.4.8 SWIG and XML

    +

    41.4.8 SWIG and XML

    @@ -941,7 +941,7 @@ internal data structures, it may be useful to keep XML in the back of your mind as a model.

    -

    41.5 Primitive Data Structures

    +

    41.5 Primitive Data Structures

    @@ -987,7 +987,7 @@ typedef Hash Typetab; -

    41.5.1 Strings

    +

    41.5.1 Strings

    @@ -1128,7 +1128,7 @@ Returns the number of replacements made (if any). -

    41.5.2 Hashes

    +

    41.5.2 Hashes

    @@ -1205,7 +1205,7 @@ Returns the list of hash table keys. -

    41.5.3 Lists

    +

    41.5.3 Lists

    @@ -1294,7 +1294,7 @@ If t is not a standard object, it is assumed to be a char * and is used to create a String object. -

    41.5.4 Common operations

    +

    41.5.4 Common operations

    The following operations are applicable to all datatypes. @@ -1349,7 +1349,7 @@ objects and report errors. Gets the line number associated with x. -

    41.5.5 Iterating over Lists and Hashes

    +

    41.5.5 Iterating over Lists and Hashes

    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)) { -

    41.5.6 I/O

    +

    41.5.6 I/O

    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.

    -

    41.6 Navigating and manipulating parse trees

    +

    41.6 Navigating and manipulating parse trees

    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. -

    41.7 Working with attributes

    +

    41.7 Working with attributes

    @@ -1779,7 +1779,7 @@ the attribute is optional. Swig_restore() must always be called after function. -

    41.8 Type system

    +

    41.8 Type system

    @@ -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.

    -

    41.8.1 String encoding of types

    +

    41.8.1 String encoding of types

    @@ -1889,7 +1889,7 @@ make the final type, the two parts are just joined together using string concatenation.

    -

    41.8.2 Type construction

    +

    41.8.2 Type construction

    @@ -2058,7 +2058,7 @@ Returns the prefix of a type. For example, if ty is ty is unmodified. -

    41.8.3 Type tests

    +

    41.8.3 Type tests

    @@ -2145,7 +2145,7 @@ Checks if ty is a varargs type. Checks if ty is a templatized type. -

    41.8.4 Typedef and inheritance

    +

    41.8.4 Typedef and inheritance

    @@ -2247,7 +2247,7 @@ Fully reduces ty according to typedef rules. Resulting datatype will consist only of primitive typenames. -

    41.8.5 Lvalues

    +

    41.8.5 Lvalues

    @@ -2284,7 +2284,7 @@ Literal y; // type = 'Literal', ltype='p.char' -

    41.8.6 Output functions

    +

    41.8.6 Output functions

    @@ -2346,7 +2346,7 @@ SWIG, but is most commonly associated with type-descriptor objects that appear in wrappers (e.g., SWIGTYPE_p_double). -

    41.9 Parameters

    +

    41.9 Parameters

    @@ -2445,7 +2445,7 @@ included. Used to emit prototypes. Returns the number of required (non-optional) arguments in p. -

    41.10 Writing a Language Module

    +

    41.10 Writing a Language Module

    @@ -2460,7 +2460,7 @@ describes the creation of a minimal Python module. You should be able to extra this to other languages.

    -

    41.10.1 Execution model

    +

    41.10.1 Execution model

    @@ -2470,7 +2470,7 @@ the parsing of command line options, all aspects of code generation are controll different methods of the Language that must be defined by your module.

    -

    41.10.2 Starting out

    +

    41.10.2 Starting out

    @@ -2578,7 +2578,7 @@ that activates your module. For example, swig -python foo.i. The messages from your new module should appear.

    -

    41.10.3 Command line options

    +

    41.10.3 Command line options

    @@ -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.

    -

    41.10.4 Configuration and preprocessing

    +

    41.10.4 Configuration and preprocessing

    @@ -2686,7 +2686,7 @@ an implementation file python.cxx and a configuration file python.swg.

    -

    41.10.5 Entry point to code generation

    +

    41.10.5 Entry point to code generation

    @@ -2744,7 +2744,7 @@ int Python::top(Node *n) { -

    41.10.6 Module I/O and wrapper skeleton

    +

    41.10.6 Module I/O and wrapper skeleton

    @@ -2892,7 +2892,7 @@ functionWrapper : void Shape_y_set(Shape *self,double y) -

    41.10.7 Low-level code generators

    +

    41.10.7 Low-level code generators

    @@ -3046,7 +3046,7 @@ but without the typemaps, there is still work to do.

    -

    41.10.8 Configuration files

    +

    41.10.8 Configuration files

    @@ -3190,7 +3190,7 @@ politely displays the ignoring language message. -

    41.10.9 Runtime support

    +

    41.10.9 Runtime support

    @@ -3199,7 +3199,7 @@ Discuss the kinds of functions typically needed for SWIG runtime support (e.g. the SWIG files that implement those functions.

    -

    41.10.10 Standard library files

    +

    41.10.10 Standard library files

    @@ -3218,7 +3218,7 @@ The following are the minimum that are usually supported: Please copy these and modify for any new language.

    -

    41.10.11 User examples

    +

    41.10.11 User examples

    @@ -3247,7 +3247,7 @@ during this process, see the section on .

    -

    41.10.12 Test driven development and the test-suite

    +

    41.10.12 Test driven development and the test-suite

    @@ -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.

    -

    41.10.12.1 Running the test-suite

    +

    41.10.12.1 Running the test-suite

    @@ -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 Examples/test-suite/errors/Makefile.in.

    -

    41.10.13 Documentation

    +

    41.10.13 Documentation

    @@ -3530,7 +3530,7 @@ Some topics that you'll want to be sure to address include: if available. -

    41.10.14 Prerequisites for adding a new language module to the SWIG distribution

    +

    41.10.14 Prerequisites for adding a new language module to the SWIG distribution

    @@ -3587,7 +3587,7 @@ should be added should there be an area not already covered by the existing tests.

    -

    41.10.15 Coding style guidelines

    +

    41.10.15 Coding style guidelines

    @@ -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.

    -

    41.11 Debugging Options

    +

    41.11 Debugging Options

    @@ -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 swig -help.

    -

    41.12 Guide to parse tree nodes

    +

    41.12 Guide to parse tree nodes

    @@ -4046,7 +4046,7 @@ extern "X" { ... } declaration. -

    41.13 Further Development Information

    +

    41.13 Further Development Information

    diff --git a/Doc/Manual/Go.html b/Doc/Manual/Go.html index f60e4d3f5..2fff4edf5 100644 --- a/Doc/Manual/Go.html +++ b/Doc/Manual/Go.html @@ -5,7 +5,7 @@ -

    23 SWIG and Go

    +

    23 SWIG and Go

      @@ -56,7 +56,7 @@ the Go programming language see golang.org.

      -

      23.1 Overview

      +

      23.1 Overview

      @@ -85,7 +85,7 @@ type-safe as well. In case of type issues the build will fail and hence SWIG's are not used.

      -

      23.2 Examples

      +

      23.2 Examples

      @@ -100,7 +100,7 @@ SWIG interface file extension for backwards compatibility with Go 1.

      -

      23.3 Running SWIG with Go

      +

      23.3 Running SWIG with Go

      @@ -180,7 +180,7 @@ sequence for this approach would look like this:

    -

    23.3.1 Go-specific Commandline Options

    +

    23.3.1 Go-specific Commandline Options

    @@ -263,7 +263,7 @@ swig -go -help -

    23.3.2 Generated Wrapper Files

    +

    23.3.2 Generated Wrapper Files

    There are two different approaches to generating wrapper files, @@ -307,7 +307,7 @@ combined with the compiled MODULE.go using go tool pack. -

    23.4 A tour of basic C/C++ wrapping

    +

    23.4 A tour of basic C/C++ wrapping

    @@ -317,7 +317,7 @@ modifications have to occur. This section briefly covers the essential aspects of this wrapping.

    -

    23.4.1 Go Package Name

    +

    23.4.1 Go Package Name

    @@ -327,7 +327,7 @@ directive. You may override this by using SWIG's -package command line option.

    -

    23.4.2 Go Names

    +

    23.4.2 Go Names

    @@ -359,7 +359,7 @@ followed by that name, and the destructor will be named Delete followed by that name.

    -

    23.4.3 Go Constants

    +

    23.4.3 Go Constants

    @@ -367,7 +367,7 @@ C/C++ constants created via #define or the %constant directive become Go constants, declared with a const declaration. -

    23.4.4 Go Enumerations

    +

    23.4.4 Go Enumerations

    @@ -377,7 +377,7 @@ usual). The values of the enumeration will become variables in Go; code should avoid modifying those variables.

    -

    23.4.5 Go Classes

    +

    23.4.5 Go Classes

    @@ -455,7 +455,7 @@ returns a go interface. If the returned pointer can be null, you can check for this by calling the Swigcptr() method.

    -

    23.4.5.1 Go Class Memory Management

    +

    23.4.5.1 Go Class Memory Management

    @@ -577,7 +577,7 @@ func (o *GoClassName) Close() { -

    23.4.5.2 Go Class Inheritance

    +

    23.4.5.2 Go Class Inheritance

    @@ -589,7 +589,7 @@ Doing the reverse will require an explicit type assertion, which will be checked dynamically.

    -

    23.4.6 Go Templates

    +

    23.4.6 Go Templates

    @@ -598,7 +598,7 @@ wrappers for a particular template instantation. To do this, use the %template directive. -

    23.4.7 Go Director Classes

    +

    23.4.7 Go Director Classes

    @@ -616,7 +616,7 @@ completely to avoid common pitfalls with directors in Go.

    -

    23.4.7.1 Example C++ code

    +

    23.4.7.1 Example C++ code

    @@ -688,7 +688,7 @@ be found in the end of the guide.

    -

    23.4.7.2 Enable director feature

    +

    23.4.7.2 Enable director feature

    @@ -723,7 +723,7 @@ documentation on directors.

    -

    23.4.7.3 Constructor and destructor

    +

    23.4.7.3 Constructor and destructor

    @@ -776,7 +776,7 @@ embedding.

    -

    23.4.7.4 Override virtual methods

    +

    23.4.7.4 Override virtual methods

    @@ -842,7 +842,7 @@ the Go methods.

    -

    23.4.7.5 Call base methods

    +

    23.4.7.5 Call base methods

    @@ -879,7 +879,7 @@ be found in the end of the guide.

    -

    23.4.7.6 Subclass via embedding

    +

    23.4.7.6 Subclass via embedding

    @@ -947,7 +947,7 @@ class.

    -

    23.4.7.7 Memory management with runtime.SetFinalizer

    +

    23.4.7.7 Memory management with runtime.SetFinalizer

    @@ -1012,7 +1012,7 @@ before using runtime.SetFinalizer to know all of its gotchas.

    -

    23.4.7.8 Complete FooBarGo example class

    +

    23.4.7.8 Complete FooBarGo example class

    @@ -1141,7 +1141,7 @@ SWIG/Examples/go/director/.

    -

    23.4.8 Default Go primitive type mappings

    +

    23.4.8 Default Go primitive type mappings

    @@ -1248,7 +1248,7 @@ that typemap, or add new values, to control how C/C++ types are mapped into Go types.

    -

    23.4.9 Output arguments

    +

    23.4.9 Output arguments

    Because of limitations in the way output arguments are processed in swig, @@ -1301,7 +1301,7 @@ void f(char *output); -

    23.4.10 Adding additional go code

    +

    23.4.10 Adding additional go code

    Often the APIs generated by swig are not very natural in go, especially if @@ -1396,7 +1396,7 @@ func bar() { -

    23.4.11 Go typemaps

    +

    23.4.11 Go typemaps

    diff --git a/Doc/Manual/Guile.html b/Doc/Manual/Guile.html index 4c1126c7f..b424df6e2 100644 --- a/Doc/Manual/Guile.html +++ b/Doc/Manual/Guile.html @@ -8,7 +8,7 @@ -

    24 SWIG and Guile

    +

    24 SWIG and Guile

      @@ -47,7 +47,7 @@

      This section details guile-specific support in SWIG. -

      24.1 Supported Guile Versions

      +

      24.1 Supported Guile Versions

      @@ -61,7 +61,7 @@ improved performance. This is currently not tested with swig so your mileage may vary. To be safe set environment variable GUILE_AUTO_COMPILE to 0 when using swig generated guile code. -

      24.2 Meaning of "Module"

      +

      24.2 Meaning of "Module"

      @@ -69,7 +69,7 @@ There are three different concepts of "module" involved, defined separately for SWIG, Guile, and Libtool. To avoid horrible confusion, we explicitly prefix the context, e.g., "guile-module". -

      24.3 Old GH Guile API

      +

      24.3 Old GH Guile API

      Guile 1.8 and older could be interfaced using two different api's, the SCM @@ -80,7 +80,7 @@ or the GH API. The GH interface to guile is deprecated. Read more about why in version of SWIG that can still generate guile GH wrapper code is 2.0.9. Please use that version if you really need the GH wrapper code. -

      24.4 Linkage

      +

      24.4 Linkage

      @@ -88,7 +88,7 @@ Guile support is complicated by a lack of user community cohesiveness, which manifests in multiple shared-library usage conventions. A set of policies implementing a usage convention is called a linkage. -

      24.4.1 Simple Linkage

      +

      24.4.1 Simple Linkage

      @@ -193,7 +193,7 @@ placed between the define-module form and the SWIG_init via a preprocessor define to avoid symbol clashes. For this case, however, passive linkage is available. -

      24.4.2 Passive Linkage

      +

      24.4.2 Passive Linkage

      Passive linkage is just like simple linkage, but it generates an @@ -203,7 +203,7 @@ package name (see below).

      You should use passive linkage rather than simple linkage when you are using multiple modules. -

      24.4.3 Native Guile Module Linkage

      +

      24.4.3 Native Guile Module Linkage

      SWIG can also generate wrapper code that does all the Guile module @@ -244,7 +244,7 @@ Newer Guile versions have a shorthand procedure for this:

    -

    24.4.4 Old Auto-Loading Guile Module Linkage

    +

    24.4.4 Old Auto-Loading Guile Module Linkage

    Guile used to support an autoloading facility for object-code @@ -270,7 +270,7 @@ option, SWIG generates an exported module initialization function with an appropriate name. -

    24.4.5 Hobbit4D Linkage

    +

    24.4.5 Hobbit4D Linkage

    @@ -295,7 +295,7 @@ my/lib/libfoo.so.X.Y.Z and friends. This scheme is still very experimental; the (hobbit4d link) conventions are not well understood.

    -

    24.5 Underscore Folding

    +

    24.5 Underscore Folding

    @@ -307,7 +307,7 @@ complained so far. %rename to specify the Guile name of the wrapped functions and variables (see CHANGES). -

    24.6 Typemaps

    +

    24.6 Typemaps

    @@ -399,7 +399,7 @@ constant will appear as a scheme variable. See Features and the %feature directive for info on how to apply the %feature.

    -

    24.7 Representation of pointers as smobs

    +

    24.7 Representation of pointers as smobs

    @@ -420,7 +420,7 @@ representing the expected pointer type. See also If the Scheme object passed was not a SWIG smob representing a compatible pointer, a wrong-type-arg exception is raised. -

    24.7.1 Smobs

    +

    24.7.1 Smobs

    @@ -439,7 +439,7 @@ structure describing this type. If a generated GOOPS module has been loaded, sm the corresponding GOOPS class.

    -

    24.7.2 Garbage Collection

    +

    24.7.2 Garbage Collection

    Garbage collection is a feature of Guile since version 1.6. As SWIG now requires Guile > 1.8, @@ -453,7 +453,7 @@ is exactly like described in 24.8 Exception Handling +

    24.8 Exception Handling

    @@ -479,7 +479,7 @@ mapping: The default when not specified here is to use "swig-error". See Lib/exception.i for details. -

    24.9 Procedure documentation

    +

    24.9 Procedure documentation

    If invoked with the command-line option -procdoc @@ -514,7 +514,7 @@ like this: typemap argument doc. See Lib/guile/typemaps.i for details. -

    24.10 Procedures with setters

    +

    24.10 Procedures with setters

    For global variables, SWIG creates a single wrapper procedure @@ -542,7 +542,7 @@ struct members, the procedures (struct-member-get pointer) and (struct-member-set pointer value) are not generated. -

    24.11 GOOPS Proxy Classes

    +

    24.11 GOOPS Proxy Classes

    SWIG can also generate classes and generic functions for use with @@ -688,7 +688,7 @@ Notice that <Foo> is used before it is defined. The fix is to just put th %import "foo.h" before the %inline block.

    -

    24.11.1 Naming Issues

    +

    24.11.1 Naming Issues

    As you can see in the example above, there are potential naming conflicts. The default exported @@ -725,7 +725,7 @@ guile-modules. For example,

    (use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:))) -

    24.11.2 Linking

    +

    24.11.2 Linking

    The guile-modules generated above all need to be linked together. GOOPS support requires diff --git a/Doc/Manual/Introduction.html b/Doc/Manual/Introduction.html index dc68bff43..db35d8425 100644 --- a/Doc/Manual/Introduction.html +++ b/Doc/Manual/Introduction.html @@ -6,7 +6,7 @@ -

    2 Introduction

    +

    2 Introduction

      @@ -31,7 +31,7 @@ -

      2.1 What is SWIG?

      +

      2.1 What is SWIG?

      @@ -71,7 +71,7 @@ small; especially the research and development work that is commonly found in scientific and engineering projects. However, nowadays SWIG is known to be used in many large open source and commercial projects. -

      2.2 Why use SWIG?

      +

      2.2 Why use SWIG?

      @@ -143,7 +143,7 @@ it provides a wide variety of customization features that let you change almost every aspect of the language bindings. This is the main reason why SWIG has such a large user manual ;-). -

      2.3 A SWIG example

      +

      2.3 A SWIG example

      @@ -174,7 +174,7 @@ variable My_variable from Tcl. You start by making a SWIG interface file as shown below (by convention, these files carry a .i suffix) : -

      2.3.1 SWIG interface file

      +

      2.3.1 SWIG interface file

      @@ -199,7 +199,7 @@ module that will be created by SWIG.  The %{ %} block
 provides a location for inserting additional code, such as C header
 files or additional C declarations, into the generated C wrapper code.
 
-
      2.3.2 The swig command
      
+
      2.3.2 The swig command
      
 
 
 
      
@@ -233,7 +233,7 @@ and variables declared in the SWIG interface.  A look at the file
 example_wrap.c reveals a hideous mess.  However, you 
 almost never need to worry about it.
 
-
      2.3.3 Building a Perl5 module
      
+
      2.3.3 Building a Perl5 module
      
 
 
 
      
@@ -259,7 +259,7 @@ unix >
      -

      2.3.4 Building a Python module

      +

      2.3.4 Building a Python module

      @@ -283,7 +283,7 @@ Type "copyright", "credits" or "license" for more information. 7.5

    -

    2.3.5 Shortcuts

    +

    2.3.5 Shortcuts

    @@ -309,7 +309,7 @@ print $example::My_variable + 4.5, "\n"; 7.5 -

    2.4 Supported C/C++ language features

    +

    2.4 Supported C/C++ language features

    @@ -348,7 +348,7 @@ wrapping simple C++ code. In fact, SWIG is able to handle C++ code that stresses the very limits of many C++ compilers. -

    2.5 Non-intrusive interface building

    +

    2.5 Non-intrusive interface building

    @@ -360,7 +360,7 @@ interface and reuse the code in other applications. It is also possible to support different types of interfaces depending on the application.

    -

    2.6 Incorporating SWIG into a build system

    +

    2.6 Incorporating SWIG into a build system

    @@ -418,7 +418,7 @@ which will invoke SWIG and compile the generated C++ files into _example.so (UNI For other target languages on Windows a dll, instead of a .pyd file, is usually generated.

    -

    2.7 Hands off code generation

    +

    2.7 Hands off code generation

    @@ -431,7 +431,7 @@ it allows others to forget about the low-level implementation details.

    -

    2.8 SWIG and freedom

    +

    2.8 SWIG and freedom

    diff --git a/Doc/Manual/Java.html b/Doc/Manual/Java.html index b953eb518..9b18c4aa9 100644 --- a/Doc/Manual/Java.html +++ b/Doc/Manual/Java.html @@ -5,7 +5,7 @@ -

    25 SWIG and Java

    +

    25 SWIG and Java

      @@ -161,7 +161,7 @@ It covers most SWIG features, but certain low-level details are covered in less

      -

      25.1 Overview

      +

      25.1 Overview

      @@ -196,7 +196,7 @@ Various customisation tips and techniques using SWIG directives are covered. The latter sections cover the advanced techniques of using typemaps for complete control of the wrapping process.

      -

      25.2 Preliminaries

      +

      25.2 Preliminaries

      @@ -216,7 +216,7 @@ This is the commonly used method to load JNI code so your system will more than Android uses Java JNI and also works with SWIG. Please read the Android chapter in conjunction with this one if you are targeting Android.

      -

      25.2.1 Running SWIG

      +

      25.2.1 Running SWIG

      @@ -275,7 +275,7 @@ The following sections have further practical examples and details on how you mi compiling and using the generated files.

      -

      25.2.2 Additional Commandline Options

      +

      25.2.2 Additional Commandline Options

      @@ -312,7 +312,7 @@ swig -java -help Their use will become clearer by the time you have finished reading this section on SWIG and Java.

      -

      25.2.3 Getting the right header files

      +

      25.2.3 Getting the right header files

      @@ -327,7 +327,7 @@ They are usually in directories like this:

      The exact location may vary on your machine, but the above locations are typical.

      -

      25.2.4 Compiling a dynamic module

      +

      25.2.4 Compiling a dynamic module

      @@ -362,7 +362,7 @@ The name of the shared library output file is important. If the name of your SWIG module is "example", the name of the corresponding shared library file should be "libexample.so" (or equivalent depending on your machine, see Dynamic linking problems for more information). The name of the module is specified using the %module directive or -module command line option.

      -

      25.2.5 Using your module

      +

      25.2.5 Using your module

      @@ -397,7 +397,7 @@ $ If it doesn't work have a look at the following section which discusses problems loading the shared library.

      -

      25.2.6 Dynamic linking problems

      +

      25.2.6 Dynamic linking problems

      @@ -484,7 +484,7 @@ The following section also contains some C++ specific linking problems and solut

      -

      25.2.7 Compilation problems and compiling with C++

      +

      25.2.7 Compilation problems and compiling with C++

      @@ -536,7 +536,7 @@ Finally make sure the version of JDK header files matches the version of Java th

      -

      25.2.8 Building on Windows

      +

      25.2.8 Building on Windows

      @@ -545,7 +545,7 @@ You will want to produce a DLL that can be loaded by the Java Virtual Machine. This section covers the process of using SWIG with Microsoft Visual C++ 6 although the procedure may be similar with other compilers. In order for everything to work, you will need to have a JDK installed on your machine in order to read the JNI header files.

      -

      25.2.8.1 Running SWIG from Visual Studio

      +

      25.2.8.1 Running SWIG from Visual Studio

      @@ -584,7 +584,7 @@ To run the native code in the DLL (example.dll), make sure that it is in your pa If the library fails to load have a look at Dynamic linking problems.

      -

      25.2.8.2 Using NMAKE

      +

      25.2.8.2 Using NMAKE

      @@ -643,7 +643,7 @@ Of course you may want to make changes for it to work for C++ by adding in the -

      -

      25.3 A tour of basic C/C++ wrapping

      +

      25.3 A tour of basic C/C++ wrapping

      @@ -653,7 +653,7 @@ variables are wrapped with JavaBean type getters and setters and so forth. This section briefly covers the essential aspects of this wrapping.

      -

      25.3.1 Modules, packages and generated Java classes

      +

      25.3.1 Modules, packages and generated Java classes

      @@ -689,7 +689,7 @@ swig -java -package com.bloggs.swig -outdir com/bloggs/swig example.i SWIG won't create the directory, so make sure it exists beforehand.

      -

      25.3.2 Functions

      +

      25.3.2 Functions

      @@ -723,7 +723,7 @@ System.out.println(example.fact(4));

    -

    25.3.3 Global variables

    +

    25.3.3 Global variables

    @@ -810,7 +810,7 @@ extern char *path; // Read-only (due to %immutable) -

    25.3.4 Constants

    +

    25.3.4 Constants

    @@ -950,7 +950,7 @@ Or if you decide this practice isn't so bad and your own class implements ex

    -

    25.3.5 Enumerations

    +

    25.3.5 Enumerations

    @@ -964,7 +964,7 @@ The final two approaches use simple integers for each enum item. Before looking at the various approaches for wrapping named C/C++ enums, anonymous enums are considered.

    -

    25.3.5.1 Anonymous enums

    +

    25.3.5.1 Anonymous enums

    @@ -1027,7 +1027,7 @@ As in the case of constants, you can access them through either the module class

    -

    25.3.5.2 Typesafe enums

    +

    25.3.5.2 Typesafe enums

    @@ -1121,7 +1121,7 @@ When upgrading to JDK 1.5 or later, proper Java enums could be used instead, wit The following section details proper Java enum generation.

    -

    25.3.5.3 Proper Java enums

    +

    25.3.5.3 Proper Java enums

    @@ -1174,7 +1174,7 @@ The additional support methods need not be generated if none of the enum items h Simpler Java enums for enums without initializers section.

    -

    25.3.5.4 Type unsafe enums

    +

    25.3.5.4 Type unsafe enums

    @@ -1222,7 +1222,7 @@ Note that unlike typesafe enums, this approach requires users to mostly use diff Thus the upgrade path to proper enums provided in JDK 1.5 is more painful.

    -

    25.3.5.5 Simple enums

    +

    25.3.5.5 Simple enums

    @@ -1241,7 +1241,7 @@ SWIG-1.3.21 and earlier versions wrapped all enums using this approach. The type unsafe approach is preferable to this one and this simple approach is only included for backwards compatibility with these earlier versions of SWIG.

    -

    25.3.6 Pointers

    +

    25.3.6 Pointers

    @@ -1329,7 +1329,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return a NULL pointer if the conversion can't be performed.

    -

    25.3.7 Structures

    +

    25.3.7 Structures

    @@ -1497,7 +1497,7 @@ x.setA(3); // Modify x.a - this is the same as b.f.a -

    25.3.8 C++ classes

    +

    25.3.8 C++ classes

    @@ -1560,7 +1560,7 @@ int bar = Spam.getBar(); -

    25.3.9 C++ inheritance

    +

    25.3.9 C++ inheritance

    @@ -1621,7 +1621,7 @@ Note that Java does not support multiple inheritance so any multiple inheritance A warning is given when multiple inheritance is detected and only the first base class is used.

    -

    25.3.10 Pointers, references, arrays and pass by value

    +

    25.3.10 Pointers, references, arrays and pass by value

    @@ -1676,7 +1676,7 @@ to hold the result and a pointer is returned (Java will release this memory when the returned object's finalizer is run by the garbage collector).

    -

    25.3.10.1 Null pointers

    +

    25.3.10.1 Null pointers

    @@ -1700,7 +1700,7 @@ For spam1 and spam4 above the Java null gets translat The converse also occurs, that is, NULL pointers are translated into null Java objects when returned from a C/C++ function.

    -

    25.3.11 C++ overloaded functions

    +

    25.3.11 C++ overloaded functions

    @@ -1815,7 +1815,7 @@ void spam(unsigned short); // Ignored -

    25.3.12 C++ default arguments

    +

    25.3.12 C++ default arguments

    @@ -1858,7 +1858,7 @@ Further details on default arguments and how to restore this approach are given

    -

    25.3.13 C++ namespaces

    +

    25.3.13 C++ namespaces

    @@ -1948,7 +1948,7 @@ If the resulting use of the nspace feature and hence packages results in a proxy you will need to open up the visibility for the pointer constructor and getCPtr method from the default 'protected' to 'public' with the SWIG_JAVABODY_PROXY macro. See Java code typemaps.

    -

    25.3.14 C++ templates

    +

    25.3.14 C++ templates

    @@ -1997,10 +1997,10 @@ Obviously, there is more to template wrapping than shown in this example. More details can be found in the SWIG and C++ chapter.

    -

    25.3.15 C++ Smart Pointers

    +

    25.3.15 C++ Smart Pointers

    -

    25.3.15.1 The shared_ptr Smart Pointer

    +

    25.3.15.1 The shared_ptr Smart Pointer

    @@ -2011,7 +2011,7 @@ in the shared_ptr smart pointer -

    25.3.15.2 Generic Smart Pointers

    +

    25.3.15.2 Generic Smart Pointers

    @@ -2095,7 +2095,7 @@ Foo f = p.__deref__(); // Returns underlying Foo * -

    25.4 Further details on the generated Java classes

    +

    25.4 Further details on the generated Java classes

    @@ -2110,7 +2110,7 @@ Finally enum classes are covered. First, the crucial intermediary JNI class is considered.

    -

    25.4.1 The intermediary JNI class

    +

    25.4.1 The intermediary JNI class

    @@ -2230,7 +2230,7 @@ If name is the same as modulename then the module class name g from modulename to modulenameModule.

    -

    25.4.1.1 The intermediary JNI class pragmas

    +

    25.4.1.1 The intermediary JNI class pragmas

    @@ -2312,7 +2312,7 @@ For example, let's change the intermediary JNI class access to just the default All the methods in the intermediary JNI class will then not be callable outside of the package as the method modifiers have been changed from public access to default access. This is useful if you want to prevent users calling these low level functions.

    -

    25.4.2 The Java module class

    +

    25.4.2 The Java module class

    @@ -2343,7 +2343,7 @@ example.egg(new Foo()); The primary reason for having the module class wrapping the calls in the intermediary JNI class is to implement static type checking. In this case only a Foo can be passed to the egg function, whereas any long can be passed to the egg function in the intermediary JNI class.

    -

    25.4.2.1 The Java module class pragmas

    +

    25.4.2.1 The Java module class pragmas

    @@ -2394,7 +2394,7 @@ See The intermediary JNI class pragmas secti

    -

    25.4.3 Java proxy classes

    +

    25.4.3 Java proxy classes

    @@ -2470,7 +2470,7 @@ int y = f.spam(5, new Foo()); -

    25.4.3.1 Memory management

    +

    25.4.3.1 Memory management

    @@ -2632,7 +2632,7 @@ and

    -

    25.4.3.2 Inheritance

    +

    25.4.3.2 Inheritance

    @@ -2748,7 +2748,7 @@ However, true cross language polymorphism can be achieved using the 25.4.3.3 Proxy classes and garbage collection +

    25.4.3.3 Proxy classes and garbage collection

    @@ -2831,7 +2831,7 @@ The section on Java typemaps details how to specify See the How to Handle Java Finalization's Memory-Retention Issues article for alternative approaches to managing memory by avoiding finalizers altogether.

    -

    25.4.3.4 The premature garbage collection prevention parameter for proxy class marshalling

    +

    25.4.3.4 The premature garbage collection prevention parameter for proxy class marshalling

    @@ -2953,7 +2953,7 @@ For example: Compatibility note: The generation of this additional parameter did not occur in versions prior to SWIG-1.3.30.

    -

    25.4.3.5 Single threaded applications and thread safety

    +

    25.4.3.5 Single threaded applications and thread safety

    @@ -3041,7 +3041,7 @@ for (int i=0; i<100000; i++) { -

    25.4.4 Type wrapper classes

    +

    25.4.4 Type wrapper classes

    @@ -3128,7 +3128,7 @@ public static void spam(SWIGTYPE_p_int x, SWIGTYPE_p_int y, int z) { ... } -

    25.4.5 Enum classes

    +

    25.4.5 Enum classes

    @@ -3137,7 +3137,7 @@ The Enumerations section discussed these but om The following sub-sections detail the various types of enum classes that can be generated.

    -

    25.4.5.1 Typesafe enum classes

    +

    25.4.5.1 Typesafe enum classes

    @@ -3221,7 +3221,7 @@ The swigValue method is used for marshalling in the other direction. The toString method is overridden so that the enum name is available.

    -

    25.4.5.2 Proper Java enum classes

    +

    25.4.5.2 Proper Java enum classes

    @@ -3299,7 +3299,7 @@ These needn't be generated if the enum being wrapped does not have any initializ Simpler Java enums for enums without initializers section describes how typemaps can be used to achieve this.

    -

    25.4.5.3 Type unsafe enum classes

    +

    25.4.5.3 Type unsafe enum classes

    @@ -3330,7 +3330,7 @@ public final class Beverage { -

    25.5 Cross language polymorphism using directors

    +

    25.5 Cross language polymorphism using directors

    @@ -3352,7 +3352,7 @@ The upshot is that C++ classes can be extended in Java and from C++ these extens Neither C++ code nor Java code needs to know where a particular method is implemented: the combination of proxy classes, director classes, and C wrapper functions transparently takes care of all the cross-language method routing.

    -

    25.5.1 Enabling directors

    +

    25.5.1 Enabling directors

    @@ -3420,7 +3420,7 @@ public: -

    25.5.2 Director classes

    +

    25.5.2 Director classes

    @@ -3447,7 +3447,7 @@ If the correct implementation is in Java, the Java API is used to call the metho

    -

    25.5.3 Overhead and code bloat

    +

    25.5.3 Overhead and code bloat

    @@ -3465,7 +3465,7 @@ This situation can be optimized by selectively enabling director methods (using

    -

    25.5.4 Simple directors example

    +

    25.5.4 Simple directors example

    @@ -3530,7 +3530,7 @@ DirectorDerived::upcall_method() invoked. -

    25.5.5 Director threading issues

    +

    25.5.5 Director threading issues

    @@ -3550,7 +3550,7 @@ Macros can be defined on the commandline when compiling your C++ code, or altern -

    25.5.6 Director performance tuning

    +

    25.5.6 Director performance tuning

    @@ -3571,7 +3571,7 @@ However, if all director methods are expected to usually be overridden by Java s The disadvantage is that invocation of director methods from C++ when Java doesn't actually override the method will require an additional call up into Java and back to C++. As such, this option is only useful when overrides are extremely common and instantiation is frequent enough that its performance is critical.

    -

    25.5.7 Java exceptions from directors

    +

    25.5.7 Java exceptions from directors

    @@ -3879,7 +3879,7 @@ See the Exception handling with %exception an section for more on converting C++ exceptions to Java exceptions.

    -

    25.6 Accessing protected members

    +

    25.6 Accessing protected members

    @@ -3975,7 +3975,7 @@ class MyProtectedBase extends ProtectedBase -

    25.7 Common customization features

    +

    25.7 Common customization features

    @@ -3987,7 +3987,7 @@ be awkward. This section describes some common SWIG features that are used to improve the interface to existing C/C++ code.

    -

    25.7.1 C/C++ helper functions

    +

    25.7.1 C/C++ helper functions

    @@ -4053,7 +4053,7 @@ hard to implement. It is possible to improve on this using Java code, typemaps, customization features as covered in later sections, but sometimes helper functions are a quick and easy solution to difficult cases.

    -

    25.7.2 Class extension with %extend

    +

    25.7.2 Class extension with %extend

    @@ -4116,7 +4116,7 @@ Vector(2,3,4) in any way---the extensions only show up in the Java interface.

    -

    25.7.3 Exception handling with %exception and %javaexception

    +

    25.7.3 Exception handling with %exception and %javaexception

    @@ -4275,7 +4275,7 @@ to raise exceptions. See the SWIG Library ch The typemap example Handling C++ exception specifications as Java exceptions provides further exception handling capabilities.

    -

    25.7.4 Method access with %javamethodmodifiers

    +

    25.7.4 Method access with %javamethodmodifiers

    @@ -4301,7 +4301,7 @@ protected static void protect_me() { -

    25.8 Tips and techniques

    +

    25.8 Tips and techniques

    @@ -4311,7 +4311,7 @@ strings and arrays. This chapter discusses the common techniques for solving these problems.

    -

    25.8.1 Input and output parameters using primitive pointers and references

    +

    25.8.1 Input and output parameters using primitive pointers and references

    @@ -4485,7 +4485,7 @@ void foo(Bar *OUTPUT); will not have the intended effect since typemaps.i does not define an OUTPUT rule for Bar.

    -

    25.8.2 Simple pointers

    +

    25.8.2 Simple pointers

    @@ -4551,7 +4551,7 @@ System.out.println("3 + 4 = " + result); See the SWIG Library chapter for further details.

    -

    25.8.3 Wrapping C arrays with Java arrays

    +

    25.8.3 Wrapping C arrays with Java arrays

    @@ -4618,7 +4618,7 @@ Please be aware that the typemaps in this library are not efficient as all the e There is an alternative approach using the SWIG array library and this is covered in the next section.

    -

    25.8.4 Unbounded C Arrays

    +

    25.8.4 Unbounded C Arrays

    @@ -4763,7 +4763,7 @@ well suited for applications in which you need to create buffers, package binary data, etc.

    -

    25.8.5 Binary data vs Strings

    +

    25.8.5 Binary data vs Strings

    @@ -4807,7 +4807,7 @@ len: 5 data: 68 69 0 6a 6b -

    25.8.6 Overriding new and delete to allocate from Java heap

    +

    25.8.6 Overriding new and delete to allocate from Java heap

    @@ -4924,7 +4924,7 @@ model and use these functions in place of malloc and free in your own code.

    -

    25.9 Java typemaps

    +

    25.9 Java typemaps

    @@ -4945,7 +4945,7 @@ Before proceeding, it should be stressed that typemaps are not a required part of using SWIG---the default wrapping behavior is enough in most cases. Typemaps are only used if you want to change some aspect of the generated code. -

    25.9.1 Default primitive type mappings

    +

    25.9.1 Default primitive type mappings

    @@ -5097,7 +5097,7 @@ However, the mappings allow the full range of values for each C type from Java.

    -

    25.9.2 Default typemaps for non-primitive types

    +

    25.9.2 Default typemaps for non-primitive types

    @@ -5112,7 +5112,7 @@ So in summary, the C/C++ pointer to non-primitive types is cast into the 64 bit The Java type is either the proxy class or type wrapper class.

    -

    25.9.3 Sixty four bit JVMs

    +

    25.9.3 Sixty four bit JVMs

    @@ -5125,7 +5125,7 @@ Unfortunately it won't of course hold true for JNI code.

    -

    25.9.4 What is a typemap?

    +

    25.9.4 What is a typemap?

    @@ -5248,7 +5248,7 @@ int c = example.count('e',"Hello World"); -

    25.9.5 Typemaps for mapping C/C++ types to Java types

    +

    25.9.5 Typemaps for mapping C/C++ types to Java types

    @@ -5517,7 +5517,7 @@ These are listed below: -

    25.9.6 Java typemap attributes

    +

    25.9.6 Java typemap attributes

    @@ -5563,7 +5563,7 @@ The "javain" typemap has the optional 'pre', 'post' and 'pgcppname' attributes. Note that when the 'pre' or 'post' attributes are specified and the associated type is used in a constructor, a constructor helper function is generated. This is necessary as the Java proxy constructor wrapper makes a call to a support constructor using a this call. In Java the this call must be the first statement in the constructor body. The constructor body thus calls the helper function and the helper function instead makes the JNI call, ensuring the 'pre' code is called before the JNI call is made. There is a Date marshalling example showing 'pre', 'post' and 'pgcppname' attributes in action.

    -

    25.9.7 Java special variables

    +

    25.9.7 Java special variables

    @@ -5714,7 +5714,7 @@ This special variable expands to the intermediary class name. Usually this is th unless the jniclassname attribute is specified in the %module directive.

    -

    25.9.8 Typemaps for both C and C++ compilation

    +

    25.9.8 Typemaps for both C and C++ compilation

    @@ -5751,7 +5751,7 @@ If you do not intend your code to be targeting both C and C++ then your typemaps

    -

    25.9.9 Java code typemaps

    +

    25.9.9 Java code typemaps

    @@ -5989,7 +5989,7 @@ to make the method and constructor public: -

    25.9.10 Director specific typemaps

    +

    25.9.10 Director specific typemaps

    @@ -6253,7 +6253,7 @@ The basic strategy here is to provide a default package typemap for the majority -

    25.10 Typemap Examples

    +

    25.10 Typemap Examples

    @@ -6263,7 +6263,7 @@ the SWIG library.

    -

    25.10.1 Simpler Java enums for enums without initializers

    +

    25.10.1 Simpler Java enums for enums without initializers

    @@ -6342,7 +6342,7 @@ This would be done by using the original versions of these typemaps in "enums.sw

    -

    25.10.2 Handling C++ exception specifications as Java exceptions

    +

    25.10.2 Handling C++ exception specifications as Java exceptions

    @@ -6467,7 +6467,7 @@ We could alternatively have used %rename to rename what() into

    -

    25.10.3 NaN Exception - exception handling for a particular type

    +

    25.10.3 NaN Exception - exception handling for a particular type

    @@ -6622,7 +6622,7 @@ If we were a martyr to the JNI cause, we could replace the succinct code within If we had, we would have put it in the "in" typemap which, like all JNI and Java typemaps, also supports the 'throws' attribute.

    -

    25.10.4 Converting Java String arrays to char **

    +

    25.10.4 Converting Java String arrays to char **

    @@ -6766,7 +6766,7 @@ Lastly the "jni", "jtype" and "jstype" typemaps are also required to specify what Java types to use.

    -

    25.10.5 Expanding a Java object to multiple arguments

    +

    25.10.5 Expanding a Java object to multiple arguments

    @@ -6848,7 +6848,7 @@ example.foo(new String[]{"red", "green", "blue", "white"}); -

    25.10.6 Using typemaps to return arguments

    +

    25.10.6 Using typemaps to return arguments

    @@ -6966,7 +6966,7 @@ $ java runme 1 12.0 340.0 -

    25.10.7 Adding Java downcasts to polymorphic return types

    +

    25.10.7 Adding Java downcasts to polymorphic return types

    @@ -7172,7 +7172,7 @@ SWIG usually generates code which constructs the proxy classes using Java code a Note that the JNI code above uses a number of string lookups to call a constructor, whereas this would not occur using byte compiled Java code.

    -

    25.10.8 Adding an equals method to the Java classes

    +

    25.10.8 Adding an equals method to the Java classes

    @@ -7216,7 +7216,7 @@ System.out.println("foo1? " + foo1.equals(foo2)); -

    25.10.9 Void pointers and a common Java base class

    +

    25.10.9 Void pointers and a common Java base class

    @@ -7275,7 +7275,7 @@ This example contains some useful functionality which you may want in your code.

  • It also has a function which effectively implements a cast from the type of the proxy/type wrapper class to a void pointer. This is necessary for passing a proxy class or a type wrapper class to a function that takes a void pointer. -

    25.10.10 Struct pointer to pointer

    +

    25.10.10 Struct pointer to pointer

    @@ -7455,7 +7455,7 @@ The C functional interface has been completely morphed into an object-oriented i the Butler class would behave much like any pure Java class and feel more natural to Java users.

    -

    25.10.11 Memory management when returning references to member variables

    +

    25.10.11 Memory management when returning references to member variables

    @@ -7578,7 +7578,7 @@ public class Bike { Note the addReference call.

    -

    25.10.12 Memory management for objects passed to the C++ layer

    +

    25.10.12 Memory management for objects passed to the C++ layer

    @@ -7694,7 +7694,7 @@ The 'javacode' typemap simply adds in the specified code into the Java proxy cla -

    25.10.13 Date marshalling using the javain typemap and associated attributes

    +

    25.10.13 Date marshalling using the javain typemap and associated attributes

    @@ -7871,7 +7871,7 @@ A few things to note: -

    25.11 Living with Java Directors

    +

    25.11 Living with Java Directors

    @@ -8052,10 +8052,10 @@ public abstract class UserVisibleFoo extends Foo {

    • -

    25.12 Odds and ends

    +

    25.12 Odds and ends

    -

    25.12.1 JavaDoc comments

    +

    25.12.1 JavaDoc comments

    @@ -8111,7 +8111,7 @@ public class Barmy { -

    25.12.2 Functional interface without proxy classes

    +

    25.12.2 Functional interface without proxy classes

    @@ -8172,7 +8172,7 @@ All destructors have to be called manually for example the delete_Foo(foo) -

    25.12.3 Using your own JNI functions

    +

    25.12.3 Using your own JNI functions

    @@ -8222,7 +8222,7 @@ This directive is only really useful if you want to mix your own hand crafted JN

    -

    25.12.4 Performance concerns and hints

    +

    25.12.4 Performance concerns and hints

    @@ -8243,7 +8243,7 @@ However, you will have to be careful about memory management and make sure that This method normally calls the C++ destructor or free() for C code.

    -

    25.12.5 Debugging

    +

    25.12.5 Debugging

    @@ -8265,7 +8265,7 @@ The -verbose:jni and -verbose:gc are also useful options for monitoring code beh

    -

    25.13 Java Examples

    +

    25.13 Java Examples

    diff --git a/Doc/Manual/Javascript.html b/Doc/Manual/Javascript.html index 69e6665ea..a3b6cf0c5 100644 --- a/Doc/Manual/Javascript.html +++ b/Doc/Manual/Javascript.html @@ -6,7 +6,7 @@ -

    26 SWIG and Javascript

    +

    26 SWIG and Javascript

      @@ -51,7 +51,7 @@

      This chapter describes SWIG's support of Javascript. It does not cover SWIG basics, but only information that is specific to this module.

      -

      26.1 Overview

      +

      26.1 Overview

      Javascript is a prototype-based scripting language that is dynamic, weakly typed and has first-class functions. Its arguably the most popular language for web development. @@ -62,10 +62,10 @@ Javascript has gone beyond being a browser-based scripting language and with node-webkit there is a platform which uses Google's Chromium as Web-Browser widget and node.js for javascript extensions.

      -

      26.2 Preliminaries

      +

      26.2 Preliminaries

      -

      26.2.1 Running SWIG

      +

      26.2.1 Running SWIG

      Suppose that you defined a SWIG module such as the following:

      @@ -109,7 +109,7 @@ void example_initialize(v8::Handle<v8::Object> exports) Note: be aware that v8 has a C++ API, and thus, the generated modules must be compiled as C++.

      -

      26.2.2 Running Tests and Examples

      +

      26.2.2 Running Tests and Examples

      The configuration for tests and examples currently supports Linux and Mac only and not MinGW (Windows) yet.

      @@ -141,7 +141,7 @@ $ make check-javascript-test-suite ENGINE=jsc $ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8
    -

    26.2.3 Known Issues

    +

    26.2.3 Known Issues

    At the moment, the Javascript generators pass all tests syntactically, i.e., the generated source code compiles. However, there are still remaining runtime issues.

    @@ -158,12 +158,12 @@ $ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8

    The primary development environment has been Linux (Ubuntu 12.04). Windows and Mac OS X have been tested sporadically. Therefore, the generators might have more issues on those platforms. Please report back any problem you observe to help us improving this module quickly.

    -

    26.3 Integration

    +

    26.3 Integration

    This chapter gives a short introduction how to use a native Javascript extension: as a node.js module, and as an extension for an embedded Webkit.

    -

    26.3.1 Creating node.js Extensions

    +

    26.3.1 Creating node.js Extensions

    To install node.js you can download an installer from their web-site for Mac OS X and Windows. For Linux you can either build the source yourself and run sudo checkinstall or keep to the (probably stone-age) packaged version. For Ubuntu there is a PPA available.

    @@ -209,7 +209,7 @@ require("./build/Release/example")

    A more detailed explanation is given in the Examples section.

    -

    26.3.1.1 Troubleshooting

    +

    26.3.1.1 Troubleshooting

      @@ -221,12 +221,12 @@ require("./build/Release/example") $ sudo apt-get remove gyp -

      26.3.2 Embedded Webkit

      +

      26.3.2 Embedded Webkit

      Webkit is pre-installed on Mac OS X and available as a library for GTK.

      -

      26.3.2.1 Mac OS X

      +

      26.3.2.1 Mac OS X

      There is general information about programming with WebKit on Apple Developer Documentation. Details about Cocoa programming are not covered here.

      @@ -274,7 +274,7 @@ extern bool example_initialize(JSGlobalContextRef context, JSObjectRef* exports) @end -

      26.3.2.2 GTK

      +

      26.3.2.2 GTK

      There is general information about programming GTK at GTK documentation and in the GTK tutorial, and for Webkit there is a Webkit GTK+ API Reference.

      @@ -319,7 +319,7 @@ int main(int argc, char* argv[]) } -

      26.3.3 Creating Applications with node-webkit

      +

      26.3.3 Creating Applications with node-webkit

      To get started with node-webkit there is a very informative set of wiki pages.

      @@ -410,12 +410,12 @@ open new windows, and many more things. }; -

      26.4 Examples

      +

      26.4 Examples

      Some basic examples are shown here in more detail.

      -

      26.4.1 Simple

      +

      26.4.1 Simple

      The common example simple looks like this:

      @@ -465,7 +465,7 @@ example.Foo = 3.1415926;

      Note: ECMAScript 5, the currently implemented Javascript standard, does not have modules. node.js and other implementations provide this mechanism defined by the CommonJS group. For browsers this is provided by Browserify, for instance.

      -

      26.4.2 Class

      +

      26.4.2 Class

      The common example class defines three classes, Shape, Circle, and Square:

      @@ -595,12 +595,12 @@ at emitKey (readline.js:1095:12) Note: In ECMAScript 5 there is no concept for classes. Instead each function can be used as a constructor function which is executed by the 'new' operator. Furthermore, during construction the key property prototype of the constructor function is used to attach a prototype instance to the created object. A prototype is essentially an object itself that is the first-class delegate of a class used whenever the access to a property of an object fails. The very same prototype instance is shared among all instances of one type. Prototypal inheritance is explained in more detail on in Inheritance and the prototype chain, for instance.

      -

      26.5 Implementation

      +

      26.5 Implementation

      The Javascript Module implementation has taken a very different approach compared to other language modules in order to support different Javascript interpreters.

      -

      26.5.1 Source Code

      +

      26.5.1 Source Code

      The Javascript module is implemented in Source/Modules/javascript.cxx. It dispatches the code generation to a JSEmitter instance, V8Emitter or JSCEmitter. Additionally there are some helpers: Template, for templated code generation, and JSEmitterState, which is used to manage state information during AST traversal. This rough map shall make it easier to find a way through this huge source file:

      @@ -701,7 +701,7 @@ Template::Template(const String *code_) { ... } ... -

      26.5.2 Code Templates

      +

      26.5.2 Code Templates

      All generated code is created on the basis of code templates. The templates for JavascriptCore can be found in Lib/javascript/jsc/javascriptcode.swg, for v8 in Lib/javascript/v8/javascriptcode.swg.

      @@ -740,7 +740,7 @@ t_register.replace("$jsparent", state.clazz(NAME_MANGLED))

      Template creates a copy of that string and Template::replace uses Swig's Replaceall to replace variables in the template. Template::trim can be used to eliminate leading and trailing whitespaces. Template::print is used to write the final template string to a Swig DOH (based on Printv). All methods allow chaining.

      -

      26.5.3 Emitter

      +

      26.5.3 Emitter

      The Javascript module delegates code generation to a JSEmitter instance. The following extract shows the essential interface:

      @@ -859,7 +859,7 @@ int JAVASCRIPT::classHandler(Node *n) {

      In enterClass the emitter stores state information that is necessary when processing class members. In exitClass the wrapper code for the whole class is generated.

      -

      26.5.4 Emitter states

      +

      26.5.4 Emitter states

      For storing information during the AST traversal the emitter provides a JSEmitterState with different slots to store data representing the scopes global, class, function, and variable.

      @@ -903,7 +903,7 @@ state.clazz(NAME, Getattr(n, "sym:name"));

      State information can be retrieved using state.clazz(NAME) or with Getattr on state.clazz() which actually returns a Hash instance.

      -

      26.5.5 Handling Exceptions in JavascriptCore

      +

      26.5.5 Handling Exceptions in JavascriptCore

      Applications with an embedded JavascriptCore should be able to present detailed exception messages that occur in the Javascript engine. Below is an example derived from code provided by Brian Barnes on how these exception details can be extracted.

      diff --git a/Doc/Manual/Library.html b/Doc/Manual/Library.html index fb12e3ce8..203ea6d46 100644 --- a/Doc/Manual/Library.html +++ b/Doc/Manual/Library.html @@ -6,7 +6,7 @@ -

      9 SWIG library

      +

      9 SWIG library

        @@ -59,7 +59,7 @@ Alternative libraries provide similar functionality. Please read this chapter carefully if you used the old libraries.

        -

        9.1 The %include directive and library search path

        +

        9.1 The %include directive and library search path

        @@ -91,7 +91,7 @@ Set the environment variable to hold an alternative library directory. The directories that are searched are displayed when using -verbose commandline option.

        -

        9.2 C Arrays and Pointers

        +

        9.2 C Arrays and Pointers

        @@ -103,7 +103,7 @@ pointers as class-like objects. Since these functions provide direct access to memory, their use is potentially unsafe and you should exercise caution.

        -

        9.2.1 cpointer.i

        +

        9.2.1 cpointer.i

        @@ -319,7 +319,7 @@ In this example, the function int_to_uint() would be used to cast type Note: When working with simple pointers, typemaps can often be used to provide more seamless operation.

        -

        9.2.2 carrays.i

        +

        9.2.2 carrays.i

        @@ -497,7 +497,7 @@ you should consider using a special array object rather than a bare pointer. used with types of char or char *.

        -

        9.2.3 cmalloc.i

        +

        9.2.3 cmalloc.i

        @@ -658,7 +658,7 @@ Now, in a script:

      -

      9.2.4 cdata.i

      +

      9.2.4 cdata.i

      @@ -760,7 +760,7 @@ char *cdata_name(type* ptr, int nitems) Clearly they are unsafe.

      -

      9.3 C String Handling

      +

      9.3 C String Handling

      @@ -780,7 +780,7 @@ morality. The modules in this section provide basic functionality for manipulating raw C strings.

      -

      9.3.1 Default string handling

      +

      9.3.1 Default string handling

      @@ -821,7 +821,7 @@ interpreter and lead to a crash). Furthermore, the default behavior does not work well with binary data. Instead, strings are assumed to be NULL-terminated.

      -

      9.3.2 Passing binary data

      +

      9.3.2 Passing binary data

      @@ -863,7 +863,7 @@ In the wrapper function, the passed string will be expanded to a pointer and len The (char *STRING, int LENGTH) multi-argument typemap is also available in addition to (char *STRING, size_t LENGTH).

      -

      9.3.3 Using %newobject to release memory

      +

      9.3.3 Using %newobject to release memory

      @@ -904,7 +904,7 @@ however, you may need to provide your own "newfree" typemap for other types. See Object ownership and %newobject for more details.

      -

      9.3.4 cstring.i

      +

      9.3.4 cstring.i

      @@ -1364,7 +1364,7 @@ structure or class instead.

    -

    9.4 STL/C++ Library

    +

    9.4 STL/C++ Library

    @@ -1403,7 +1403,7 @@ Please look for the library files in the appropriate language library directory.

    -

    9.4.1 std::string

    +

    9.4.1 std::string

    @@ -1487,7 +1487,7 @@ void foo(string s, const String &t); // std_string typemaps still applie -

    9.4.2 std::vector

    +

    9.4.2 std::vector

    @@ -1666,7 +1666,7 @@ if you want to make their head explode. details and the public API exposed to the interpreter vary.

    -

    9.4.3 STL exceptions

    +

    9.4.3 STL exceptions

    @@ -1716,7 +1716,7 @@ The %exception directive can be used by placing the following code befo Any thrown STL exceptions will then be gracefully handled instead of causing a crash.

    -

    9.4.4 shared_ptr smart pointer

    +

    9.4.4 shared_ptr smart pointer

    @@ -1907,7 +1907,7 @@ Please help to improve this support by providing patches with improvements.

    -

    9.4.5 auto_ptr smart pointer

    +

    9.4.5 auto_ptr smart pointer

    @@ -1956,10 +1956,10 @@ int value = k.getValue(); -

    9.5 Utility Libraries

    +

    9.5 Utility Libraries

    -

    9.5.1 exception.i

    +

    9.5.1 exception.i

    diff --git a/Doc/Manual/Lisp.html b/Doc/Manual/Lisp.html index d2bf316a4..ccb424e50 100644 --- a/Doc/Manual/Lisp.html +++ b/Doc/Manual/Lisp.html @@ -6,7 +6,7 @@ -

    27 SWIG and Common Lisp

    +

    27 SWIG and Common Lisp

      @@ -41,7 +41,7 @@ Lisp, Common Foreign Function Interface(CFFI), CLisp and UFFI foreign function interfaces.

      -

      27.1 Allegro Common Lisp

      +

      27.1 Allegro Common Lisp

      @@ -50,7 +50,7 @@ here

      -

      27.2 Common Foreign Function Interface(CFFI)

      +

      27.2 Common Foreign Function Interface(CFFI)

      @@ -77,7 +77,7 @@ swig -cffi -module module-name file-name files and the various things which you can do with them.

      -

      27.2.1 Additional Commandline Options

      +

      27.2.1 Additional Commandline Options

      @@ -118,7 +118,7 @@ swig -cffi -help -

      27.2.2 Generating CFFI bindings

      +

      27.2.2 Generating CFFI bindings

      As we mentioned earlier the ideal way to use SWIG is to use interface @@ -395,7 +395,7 @@ The feature intern_function ensures that all C names are
    -

    27.2.3 Generating CFFI bindings for C++ code

    +

    27.2.3 Generating CFFI bindings for C++ code

    This feature to SWIG (for CFFI) is very new and still far from @@ -571,7 +571,7 @@ If you have any questions, suggestions, patches, etc., related to CFFI module feel free to contact us on the SWIG mailing list, and also please add a "[CFFI]" tag in the subject line. -

    27.2.4 Inserting user code into generated files

    +

    27.2.4 Inserting user code into generated files

    @@ -611,7 +611,7 @@ Note that the block %{ ... %} is effectively a shortcut for

    -

    27.3 CLISP

    +

    27.3 CLISP

    @@ -641,7 +641,7 @@ swig -clisp -module module-name file-name interface file for the CLISP module. The CLISP module tries to produce code which is both human readable and easily modifyable.

    -

    27.3.1 Additional Commandline Options

    +

    27.3.1 Additional Commandline Options

    @@ -674,7 +674,7 @@ and global variables will be created otherwise only definitions for
    -

    27.3.2 Details on CLISP bindings

    +

    27.3.2 Details on CLISP bindings

    @@ -798,7 +798,7 @@ struct bar { -

    27.4 UFFI

    +

    27.4 UFFI

    diff --git a/Doc/Manual/Lua.html b/Doc/Manual/Lua.html index 2e1515c43..1b6b87e51 100644 --- a/Doc/Manual/Lua.html +++ b/Doc/Manual/Lua.html @@ -6,7 +6,7 @@ -

    28 SWIG and Lua

    +

    28 SWIG and Lua

      @@ -82,14 +82,14 @@ Lua is an extension programming language designed to support general procedural eLua stands for Embedded Lua (can be thought of as a flavor of Lua) and offers the full implementation of the Lua programming language to the embedded world, extending it with specific features for efficient and portable software embedded development. eLua runs on smaller devices like microcontrollers and provides the full features of the regular Lua desktop version. More information on eLua can be found here: http://www.eluaproject.net

      -

      28.1 Preliminaries

      +

      28.1 Preliminaries

      The current SWIG implementation is designed to work with Lua 5.0.x, 5.1.x and 5.2.x. It should work with later versions of Lua, but certainly not with Lua 4.0 due to substantial API changes. It is possible to either static link or dynamic link a Lua module into the interpreter (normally Lua static links its libraries, as dynamic linking is not available on all platforms). SWIG also has support for eLua starting from eLua 0.8. Due to substantial changes between SWIG 2.x and SWIG 3.0 and unavailability of testing platform, eLua status was downgraded to 'experimental'.

      -

      28.2 Running SWIG

      +

      28.2 Running SWIG

      @@ -137,7 +137,7 @@ $ swig -lua -eluac example.i The -elua option puts all the C function wrappers and variable get/set wrappers in rotables. It also generates a metatable which will control the access to these variables from eLua. It also offers a significant amount of module size compression. On the other hand, the -eluac option puts all the wrappers in a single rotable. With this option, no matter how huge the module, it will consume no additional microcontroller SRAM (crass compression). There is a catch though: Metatables are not generated with -eluac. To access any value from eLua, one must directly call the wrapper function associated with that value.

      -

      28.2.1 Additional command line options

      +

      28.2.1 Additional command line options

      @@ -178,7 +178,7 @@ swig -lua -help -

      28.2.2 Compiling and Linking and Interpreter

      +

      28.2.2 Compiling and Linking and Interpreter

      @@ -249,7 +249,7 @@ LUALIB_API int ( luaopen_mod )(lua_State *L ); More information on building and configuring eLua can be found here: http://www.eluaproject.net/doc/v0.8/en_building.html

      -

      28.2.3 Compiling a dynamic module

      +

      28.2.3 Compiling a dynamic module

      @@ -317,7 +317,7 @@ Is quite obvious (Go back and consult the Lua documents on how to enable loadlib -

      28.2.4 Using your module

      +

      28.2.4 Using your module

      @@ -335,19 +335,19 @@ $ ./my_lua >

    -

    28.3 A tour of basic C/C++ wrapping

    +

    28.3 A tour of basic C/C++ wrapping

    By default, SWIG tries to build a very natural Lua interface to your C/C++ code. This section briefly covers the essential aspects of this wrapping.

    -

    28.3.1 Modules

    +

    28.3.1 Modules

    The SWIG module directive specifies the name of the Lua module. If you specify `module example', then everything is wrapped into a Lua table 'example' containing all the functions and variables. When choosing a module name, make sure you don't use the same name as a built-in Lua command or standard module name.

    -

    28.3.2 Functions

    +

    28.3.2 Functions

    @@ -388,7 +388,7 @@ It is also possible to rename the module with an assignment. 24 -

    28.3.3 Global variables

    +

    28.3.3 Global variables

    @@ -476,7 +476,7 @@ If you have used the -eluac option for your eLua module, you will have In general, functions of the form "variable_get()" and "variable_set()" are automatically generated by SWIG for use with -eluac.

    -

    28.3.4 Constants and enums

    +

    28.3.4 Constants and enums

    @@ -511,7 +511,7 @@ If you're using eLua and have used -elua or -eluac to generate Hello World -

    28.3.4.1 Constants/enums and classes/structures

    +

    28.3.4.1 Constants/enums and classes/structures

    @@ -567,7 +567,7 @@ If the -no-old-metatable-bindings option is used, then these old-style It is worth mentioning, that example.Test.TEST1 and example.Test_TEST1 are different entities and changing one does not change the other. Given the fact that these are constantes and they are not supposed to be changed, it is up to you to avoid such issues.

    -

    28.3.5 Pointers

    +

    28.3.5 Pointers

    @@ -605,7 +605,7 @@ Lua enforces the integrity of its userdata, so it is virtually impossible to cor nil -

    28.3.6 Structures

    +

    28.3.6 Structures

    @@ -709,7 +709,7 @@ For eLua with the -eluac option, structure manipulation has to be perfo In general, functions of the form "new_struct()", "struct_member_get()", "struct_member_set()" and "free_struct()" are automatically generated by SWIG for each structure defined in C. (Please note: This doesn't apply for modules generated with the -elua option)

    -

    28.3.7 C++ classes

    +

    28.3.7 C++ classes

    @@ -784,7 +784,7 @@ Both style names are generated by default now. However, if the -no-old-metatable-bindings option is used, then the backward compatible names are not generated in addition to ordinary ones.

    -

    28.3.8 C++ inheritance

    +

    28.3.8 C++ inheritance

    @@ -809,7 +809,7 @@ then the function spam() accepts a Foo pointer or a pointer to any clas

    It is safe to use multiple inheritance with SWIG.

    -

    28.3.9 Pointers, references, values, and arrays

    +

    28.3.9 Pointers, references, values, and arrays

    @@ -840,7 +840,7 @@ Foo spam7();

    then all three functions will return a pointer to some Foo object. Since the third function (spam7) returns a value, newly allocated memory is used to hold the result and a pointer is returned (Lua will release this memory when the return value is garbage collected). The other two are pointers which are assumed to be managed by the C code and so will not be garbage collected.

    -

    28.3.10 C++ overloaded functions

    +

    28.3.10 C++ overloaded functions

    @@ -926,7 +926,7 @@ Please refer to the "SWIG and C++" chapter for more information about overloadin

    Dealing with the Lua coercion mechanism, the priority is roughly (integers, floats, strings, userdata). But it is better to rename the functions rather than rely upon the ordering.

    -

    28.3.11 C++ operators

    +

    28.3.11 C++ operators

    @@ -1060,7 +1060,7 @@ operators and pseudo-operators):

    No other lua metafunction is inherited. For example, __gc is not inherited and must be redefined in every class. __tostring is subject to a special handling. If absent in class and in class bases, a default one will be provided by SWIG.

    -

    28.3.12 Class extension with %extend

    +

    28.3.12 Class extension with %extend

    @@ -1116,7 +1116,7 @@ true Extend works with both C and C++ code, on classes and structs. It does not modify the underlying object in any way---the extensions only show up in the Lua interface. The only item to take note of is the code has to use the '$self' instead of 'this', and that you cannot access protected/private members of the code (as you are not officially part of the class).

    -

    28.3.13 Using %newobject to release memory

    +

    28.3.13 Using %newobject to release memory

    If you have a function that allocates memory like this,

    @@ -1140,7 +1140,7 @@ char *foo();

    This will release the allocated memory.

    -

    28.3.14 C++ templates

    +

    28.3.14 C++ templates

    @@ -1175,7 +1175,7 @@ In Lua:

    Obviously, there is more to template wrapping than shown in this example. More details can be found in the SWIG and C++ chapter. Some more complicated examples will appear later.

    -

    28.3.15 C++ Smart Pointers

    +

    28.3.15 C++ Smart Pointers

    @@ -1227,7 +1227,7 @@ If you ever need to access the underlying pointer returned by operator->( > f = p:__deref__() -- Returns underlying Foo * -

    28.3.16 C++ Exceptions

    +

    28.3.16 C++ Exceptions

    @@ -1370,7 +1370,7 @@ and the "Exception handling add exception specification to functions or globally (respectively).

    -

    28.3.17 Namespaces

    +

    28.3.17 Namespaces

    @@ -1421,7 +1421,7 @@ Now, from Lua usage is as follows: 19 > -

    28.3.17.1 Compatibility Note

    +

    28.3.17.1 Compatibility Note

    @@ -1437,7 +1437,7 @@ If SWIG is running in a backwards compatible way, i.e. without the -no-old-m -

    28.3.17.2 Names

    +

    28.3.17.2 Names

    If SWIG is launched without -no-old-metatable-bindings option, then it enters backward-compatible mode. While in this mode, it tries @@ -1481,7 +1481,7 @@ surrounding scope without any prefixing. Pretending that Test2 is a struct, not > -

    28.3.17.3 Inheritance

    +

    28.3.17.3 Inheritance

    The internal organization of inheritance has changed. @@ -1522,12 +1522,12 @@ function > -

    28.4 Typemaps

    +

    28.4 Typemaps

    This section explains what typemaps are and how to use them. The default wrapping behaviour of SWIG is enough in most cases. However sometimes SWIG may need a little additional assistance to know which typemap to apply to provide the best wrapping. This section will be explaining how to use typemaps to best effect

    -

    28.4.1 What is a typemap?

    +

    28.4.1 What is a typemap?

    A typemap is nothing more than a code generation rule that is attached to a specific C datatype. For example, to convert integers from Lua to C, you might define a typemap like this:

    @@ -1555,7 +1555,7 @@ Received an integer : 6 720 -

    28.4.2 Using typemaps

    +

    28.4.2 Using typemaps

    There are many ready written typemaps built into SWIG for all common types (int, float, short, long, char*, enum and more), which SWIG uses automatically, with no effort required on your part.

    @@ -1608,7 +1608,7 @@ void swap(int *sx, int *sy);

    Note: C++ references must be handled exactly the same way. However SWIG will automatically wrap a const int& as an input parameter (since that it obviously input).

    -

    28.4.3 Typemaps and arrays

    +

    28.4.3 Typemaps and arrays

    Arrays present a challenge for SWIG, because like pointers SWIG does not know whether these are input or output values, nor @@ -1672,7 +1672,7 @@ and Lua tables to be 1..N, (the indexing follows the norm for the language). In

    Note: SWIG also can support arrays of pointers in a similar manner.

    -

    28.4.4 Typemaps and pointer-pointer functions

    +

    28.4.4 Typemaps and pointer-pointer functions

    Several C++ libraries use a pointer-pointer functions to create its objects. These functions require a pointer to a pointer which is then filled with the pointer to the new object. Microsoft's COM and DirectX as well as many other libraries have this kind of function. An example is given below:

    @@ -1706,7 +1706,7 @@ int Create_Math(iMath** pptr); // its creator (assume it mallocs) ptr=nil -- the iMath* will be GC'ed as normal -

    28.5 Writing typemaps

    +

    28.5 Writing typemaps

    This section describes how you can modify SWIG's default wrapping behavior for various C/C++ datatypes using the %typemap directive. This is an advanced topic that assumes familiarity with the Lua C API as well as the material in the "Typemaps" chapter.

    @@ -1715,7 +1715,7 @@ ptr=nil -- the iMath* will be GC'ed as normal

    Before proceeding, you should read the previous section on using typemaps, and look at the existing typemaps found in luatypemaps.swg and typemaps.i. These are both well documented and fairly easy to read. You should not attempt to write your own typemaps until you have read and can understand both of these files (they may well also give you an idea to base your work on).

    -

    28.5.1 Typemaps you can write

    +

    28.5.1 Typemaps you can write

    There are many different types of typemap that can be written, the full list can be found in the "Typemaps" chapter. However the following are the most commonly used ones.

    @@ -1728,7 +1728,7 @@ ptr=nil -- the iMath* will be GC'ed as normal (the syntax for the typecheck is different from the typemap, see typemaps for details). -

    28.5.2 SWIG's Lua-C API

    +

    28.5.2 SWIG's Lua-C API

    This section explains the SWIG specific Lua-C API. It does not cover the main Lua-C api, as this is well documented and not worth covering.

    @@ -1777,7 +1777,7 @@ This macro, when called within the context of a SWIG wrapped function, will disp
    Similar to SWIG_fail_arg, except that it will display the swig_type_info information instead.
    -

    28.6 Customization of your Bindings

    +

    28.6 Customization of your Bindings

    @@ -1786,7 +1786,7 @@ This section covers adding of some small extra bits to your module to add the la -

    28.6.1 Writing your own custom wrappers

    +

    28.6.1 Writing your own custom wrappers

    @@ -1805,7 +1805,7 @@ int native_function(lua_State*L) // my native code The %native directive in the above example, tells SWIG that there is a function int native_function(lua_State*L); which is to be added into the module under the name 'my_func'. SWIG will not add any wrapper for this function, beyond adding it into the function table. How you write your code is entirely up to you.

    -

    28.6.2 Adding additional Lua code

    +

    28.6.2 Adding additional Lua code

    @@ -1843,7 +1843,7 @@ Good uses for this feature is adding of new code, or writing helper functions to See Examples/lua/arrays for an example of this code.

    -

    28.7 Details on the Lua binding

    +

    28.7 Details on the Lua binding

    @@ -1854,7 +1854,7 @@ See Examples/lua/arrays for an example of this code.

    -

    28.7.1 Binding global data into the module.

    +

    28.7.1 Binding global data into the module.

    @@ -1914,7 +1914,7 @@ end

    That way when you call 'a=example.Foo', the interpreter looks at the table 'example' sees that there is no field 'Foo' and calls __index. This will in turn check in '.get' table and find the existence of 'Foo' and then return the value of the C function call 'Foo_get()'. Similarly for the code 'example.Foo=10', the interpreter will check the table, then call the __newindex which will then check the '.set' table and call the C function 'Foo_set(10)'.

    -

    28.7.2 Userdata and Metatables

    +

    28.7.2 Userdata and Metatables

    @@ -1994,7 +1994,7 @@ Note: Both the opaque structures (like the FILE*) and normal wrapped classes/str

    Note: Operator overloads are basically done in the same way, by adding functions such as '__add' & '__call' to the class' metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming its an operator overload.

    -

    28.7.3 Memory management

    +

    28.7.3 Memory management

    diff --git a/Doc/Manual/Modula3.html b/Doc/Manual/Modula3.html index ffbf6132d..ed6e596e7 100644 --- a/Doc/Manual/Modula3.html +++ b/Doc/Manual/Modula3.html @@ -5,7 +5,7 @@ -

    29 SWIG and Modula-3

    +

    29 SWIG and Modula-3

    -

    29.4.5 Exceptions

    +

    29.4.5 Exceptions

    @@ -816,7 +816,7 @@ you should declare %typemap("m3wrapinconv:throws") blah * %{OSError.E%}.

    -

    29.4.6 Example

    +

    29.4.6 Example

    @@ -863,10 +863,10 @@ where almost everything is generated by a typemap: -

    29.5 More hints to the generator

    +

    29.5 More hints to the generator

    -

    29.5.1 Features

    +

    29.5.1 Features

    @@ -903,7 +903,7 @@ where almost everything is generated by a typemap:
    -

    29.5.2 Pragmas

    +

    29.5.2 Pragmas

    @@ -926,7 +926,7 @@ where almost everything is generated by a typemap:
    -

    29.6 Remarks

    +

    29.6 Remarks

      diff --git a/Doc/Manual/Modules.html b/Doc/Manual/Modules.html index 4846aedc1..d12383a1d 100644 --- a/Doc/Manual/Modules.html +++ b/Doc/Manual/Modules.html @@ -6,7 +6,7 @@ -

      16 Working with Modules

      +

      16 Working with Modules

        @@ -23,7 +23,7 @@ -

        16.1 Modules Introduction

        +

        16.1 Modules Introduction

        @@ -77,7 +77,7 @@ where you want to create a collection of modules. Each module in the collection is created via separate invocations of SWIG.

        -

        16.2 Basics

        +

        16.2 Basics

        @@ -176,7 +176,7 @@ in parallel from multiple threads as SWIG provides no locking - for more on that issue, read on.

        -

        16.3 The SWIG runtime code

        +

        16.3 The SWIG runtime code

        @@ -242,7 +242,7 @@ can peacefully coexist. So the type structures are separated by the is empty. Only modules compiled with the same pair will share type information.

        -

        16.4 External access to the runtime

        +

        16.4 External access to the runtime

        As described in The run-time type checker, @@ -281,7 +281,7 @@ SWIG_TYPE_TABLE to be the same as the module whose types you are trying to access.

        -

        16.5 A word of caution about static libraries

        +

        16.5 A word of caution about static libraries

        @@ -292,7 +292,7 @@ into it. This is very often NOT what you want and it can lead to unexpect behavior. When working with dynamically loadable modules, you should try to work exclusively with shared libraries.

        -

        16.6 References

        +

        16.6 References

        @@ -300,7 +300,7 @@ Due to the complexity of working with shared libraries and multiple modules, it an outside reference. John Levine's "Linkers and Loaders" is highly recommended.

        -

        16.7 Reducing the wrapper file size

        +

        16.7 Reducing the wrapper file size

        diff --git a/Doc/Manual/Mzscheme.html b/Doc/Manual/Mzscheme.html index fadda5fc9..358942a35 100644 --- a/Doc/Manual/Mzscheme.html +++ b/Doc/Manual/Mzscheme.html @@ -8,7 +8,7 @@ -

        30 SWIG and MzScheme/Racket

        +

        30 SWIG and MzScheme/Racket

          @@ -24,7 +24,7 @@

          This section contains information on SWIG's support of Racket, formally known as MzScheme. -

          30.1 Creating native structures

          +

          30.1 Creating native structures

          @@ -65,7 +65,7 @@ Then in scheme, you can use regular struct access procedures like

        -

        30.2 Simple example

        +

        30.2 Simple example

        @@ -166,7 +166,7 @@ Some points of interest:

      • 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.
      -

      30.3 External documentation

      +

      30.3 External documentation

      diff --git a/Doc/Manual/Ocaml.html b/Doc/Manual/Ocaml.html index b927a7d8f..789bbae53 100644 --- a/Doc/Manual/Ocaml.html +++ b/Doc/Manual/Ocaml.html @@ -6,7 +6,7 @@ -

      31 SWIG and Ocaml

      +

      31 SWIG and Ocaml

        @@ -83,7 +83,7 @@ If you're not familiar with the Objective Caml language, you can visit The Ocaml Website.

        -

        31.1 Preliminaries

        +

        31.1 Preliminaries

        @@ -101,7 +101,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.

        -

        31.1.1 Running SWIG

        +

        31.1.1 Running SWIG

        @@ -124,7 +124,7 @@ you will compile the file example_wrap.c with ocamlc or the resulting .ml and .mli files as well, and do the final link with -custom (not needed for native link).

        -

        31.1.2 Compiling the code

        +

        31.1.2 Compiling the code

        @@ -161,7 +161,7 @@ in C++ mode, you must:

      -

      31.1.3 The camlp4 module

      +

      31.1.3 The camlp4 module

      @@ -237,7 +237,7 @@ let b = C_string (getenv "PATH") -

      31.1.4 Using your module

      +

      31.1.4 Using your module

      @@ -251,7 +251,7 @@ option to build your functions into the primitive list. This option is not needed when you build native code.

      -

      31.1.5 Compilation problems and compiling with C++

      +

      31.1.5 Compilation problems and compiling with C++

      @@ -262,7 +262,7 @@ liberal with pointer types may not compile under the C++ compiler. Most code meant to be compiled as C++ will not have problems.

      -

      31.2 The low-level Ocaml/C interface

      +

      31.2 The low-level Ocaml/C interface

      @@ -362,7 +362,7 @@ value items pass through directly, but you must make your own type signature for a function that uses value in this way.

      -

      31.2.1 The generated module

      +

      31.2.1 The generated module

      @@ -396,7 +396,7 @@ it describes the output SWIG will generate for class definitions. -

      31.2.2 Enums

      +

      31.2.2 Enums

      @@ -459,7 +459,7 @@ val x : Enum_test.c_obj = C_enum `a

      -

      31.2.2.1 Enum typing in Ocaml

      +

      31.2.2.1 Enum typing in Ocaml

      @@ -472,10 +472,10 @@ functions imported from different modules. You must convert values to master values using the swig_val function before sharing them with another module.

      -

      31.2.3 Arrays

      +

      31.2.3 Arrays

      -

      31.2.3.1 Simple types of bounded arrays

      +

      31.2.3.1 Simple types of bounded arrays

      @@ -496,7 +496,7 @@ arrays of simple types with known bounds in your code, but this only works for arrays whose bounds are completely specified.

      -

      31.2.3.2 Complex and unbounded arrays

      +

      31.2.3.2 Complex and unbounded arrays

      @@ -509,7 +509,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.

      -

      31.2.3.3 Using an object

      +

      31.2.3.3 Using an object

      @@ -523,7 +523,7 @@ Consider writing an object when the ending condition of your array is complex, such as using a required sentinel, etc.

      -

      31.2.3.4 Example typemap for a function taking float * and int

      +

      31.2.3.4 Example typemap for a function taking float * and int

      @@ -574,7 +574,7 @@ void printfloats( float *tab, int len ); -

      31.2.4 C++ Classes

      +

      31.2.4 C++ Classes

      @@ -617,7 +617,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the returned value for the same object.

      -

      31.2.4.1 STL vector and string Example

      +

      31.2.4.1 STL vector and string Example

      @@ -697,7 +697,7 @@ baz # -

      31.2.4.2 C++ Class Example

      +

      31.2.4.2 C++ Class Example

      @@ -727,7 +727,7 @@ public: }; -

      31.2.4.3 Compiling the example

      +

      31.2.4.3 Compiling the example

      @@ -745,7 +745,7 @@ bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
   -L$QTPATH/lib -cclib -lqt
      -

      31.2.4.4 Sample Session

      +

      31.2.4.4 Sample Session

      @@ -772,10 +772,10 @@ Assuming you have a working installation of QT, you will see a window
 containing the string "hi" in a button.
 
      
 
-
      31.2.5 Director Classes
      
+
      31.2.5 Director Classes
      
 
 
-
      31.2.5.1 Director Introduction
      
+
      31.2.5.1 Director Introduction
      
 
 
 
      
@@ -802,7 +802,7 @@ class foo {
 };
      -

      31.2.5.2 Overriding Methods in Ocaml

      +

      31.2.5.2 Overriding Methods in Ocaml

      @@ -830,7 +830,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.

      -

      31.2.5.3 Director Usage Example

      +

      31.2.5.3 Director Usage Example

      @@ -889,7 +889,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the program in C++.

      -

      31.2.5.4 Creating director objects

      +

      31.2.5.4 Creating director objects

      @@ -930,7 +930,7 @@ object from causing a core dump, as long as the object is destroyed properly.

      -

      31.2.5.5 Typemaps for directors, directorin, directorout, directorargout

      +

      31.2.5.5 Typemaps for directors, directorin, directorout, directorargout

      @@ -941,7 +941,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.

      -

      31.2.5.6 directorin typemap

      +

      31.2.5.6 directorin typemap

      @@ -952,7 +952,7 @@ code receives when you are called. In general, a simple directorin typ can use the same body as a simple out typemap.

      -

      31.2.5.7 directorout typemap

      +

      31.2.5.7 directorout typemap

      @@ -963,7 +963,7 @@ for the same type, except when there are special requirements for object ownership, etc.

      -

      31.2.5.8 directorargout typemap

      +

      31.2.5.8 directorargout typemap

      @@ -980,7 +980,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.

      -

      31.2.6 Exceptions

      +

      31.2.6 Exceptions

      diff --git a/Doc/Manual/Octave.html b/Doc/Manual/Octave.html index 53ee86f7c..df484103d 100644 --- a/Doc/Manual/Octave.html +++ b/Doc/Manual/Octave.html @@ -8,7 +8,7 @@ -

      32 SWIG and Octave

      +

      32 SWIG and Octave

        @@ -59,7 +59,7 @@ More information can be found at O Also, there are a dozen or so examples in the Examples/octave directory, and hundreds in the test suite (Examples/test-suite and Examples/test-suite/octave).

        -

        32.1 Preliminaries

        +

        32.1 Preliminaries

        @@ -67,7 +67,7 @@ As of SWIG 3.0.7, the Octave module is regularly tested with Octave versions 3.2 Use of older Octave versions is not recommended, as these versions are no longer tested with SWIG.

        -

        32.2 Running SWIG

        +

        32.2 Running SWIG

        @@ -99,7 +99,7 @@ The -c++ option is also required when wrapping C++ code: This creates a C++ source file "example_wrap.cpp". A C++ file is generated even when wrapping C code as Octave is itself written in C++ and requires wrapper code to be in the same language. The generated C++ source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application (in this case, the gcd implementation) to create an extension module.

        -

        32.2.1 Command-line options

        +

        32.2.1 Command-line options

        @@ -122,7 +122,7 @@ The special name "." loads C global variables into the module namespace, i.e. al The -opprefix options sets the prefix of the names of global/friend operator functions.

        -

        32.2.2 Compiling a dynamic module

        +

        32.2.2 Compiling a dynamic module

        @@ -149,7 +149,7 @@ $ mkoctfile example_wrap.cpp example.c 

        octave:1> swigexample
        -

        32.2.3 Using your module

        +

        32.2.3 Using your module

        @@ -167,10 +167,10 @@ octave:4> swigexample.cvar.Foo=4; octave:5> swigexample.cvar.Foo ans = 4

      -

      32.3 A tour of basic C/C++ wrapping

      +

      32.3 A tour of basic C/C++ wrapping

      -

      32.3.1 Modules

      +

      32.3.1 Modules

      @@ -215,7 +215,7 @@ octave:4> swigexample.gcd(4,6) ans = 2 -

      32.3.2 Functions

      +

      32.3.2 Functions

      @@ -232,7 +232,7 @@ int fact(int n); 

      octave:1> swigexample.fact(4)
 24
      -

      32.3.3 Global variables

      +

      32.3.3 Global variables

      @@ -285,7 +285,7 @@ octave:2> swigexample.PI=3.142; octave:3> swigexample.PI ans = 3.1420 -

      32.3.4 Constants and enums

      +

      32.3.4 Constants and enums

      @@ -307,7 +307,7 @@ swigexample.SCONST="Hello World" swigexample.SUNDAY=0 .... -

      32.3.5 Pointers

      +

      32.3.5 Pointers

      @@ -354,7 +354,7 @@ octave:2> f=swigexample.fopen("not there","r"); error: value on right hand side of assignment is undefined error: evaluating assignment expression near line 2, column 2 -

      32.3.6 Structures and C++ classes

      +

      32.3.6 Structures and C++ classes

      @@ -489,7 +489,7 @@ ans = 1 Depending on the ownership setting of a swig_ref, it may call C++ destructors when its reference count goes to zero. See the section on memory management below for details.

      -

      32.3.7 C++ inheritance

      +

      32.3.7 C++ inheritance

      @@ -498,7 +498,7 @@ This information contains the full class hierarchy. When an indexing operation ( the tree is walked to find a match in the current class as well as any of its bases. The lookup is then cached in the swig_ref.

      -

      32.3.8 C++ overloaded functions

      +

      32.3.8 C++ overloaded functions

      @@ -508,7 +508,7 @@ The dispatch function selects which overload to call (if any) based on the passe typecheck typemaps are used to analyze each argument, as well as assign precedence. See the chapter on typemaps for details.

      -

      32.3.9 C++ operators

      +

      32.3.9 C++ operators

      @@ -612,7 +612,7 @@ On the C++ side, the default mappings are as follows: Octave can also utilise friend (i.e. non-member) operators with a simple %rename: see the example in the Examples/octave/operator directory.

      -

      32.3.10 Class extension with %extend

      +

      32.3.10 Class extension with %extend

      @@ -642,7 +642,7 @@ octave:3> printf("%s\n",a); octave:4> a.__str() 4 -

      32.3.11 C++ templates

      +

      32.3.11 C++ templates

      @@ -719,10 +719,10 @@ ans = -

      32.3.12 C++ Smart Pointers

      +

      32.3.12 C++ Smart Pointers

      -

      32.3.12.1 The shared_ptr Smart Pointer

      +

      32.3.12.1 The shared_ptr Smart Pointer

      @@ -733,14 +733,14 @@ in the shared_ptr smart pointer -

      32.3.12.2 Generic Smart Pointers

      +

      32.3.12.2 Generic Smart Pointers

      C++ smart pointers are fully supported as in other modules.

      -

      32.3.13 Directors (calling Octave from C++ code)

      +

      32.3.13 Directors (calling Octave from C++ code)

      @@ -821,14 +821,14 @@ c-side routine called octave-side routine called -

      32.3.14 Threads

      +

      32.3.14 Threads

      The use of threads in wrapped Director code is not supported; i.e., an Octave-side implementation of a C++ class must be called from the Octave interpreter's thread. Anything fancier (apartment/queue model, whatever) is left to the user. Without anything fancier, this amounts to the limitation that Octave must drive the module... like, for example, an optimization package that calls Octave to evaluate an objective function.

      -

      32.3.15 Memory management

      +

      32.3.15 Memory management

      @@ -862,14 +862,14 @@ The %newobject directive may be used to control this behavior for pointers retur In the case where one wishes for the C++ side to own an object that was created in Octave (especially a Director object), one can use the __disown() method to invert this logic. Then letting the Octave reference count go to zero will not destroy the object, but destroying the object will invalidate the Octave-side object if it still exists (and call destructors of other C++ bases in the case of multiple inheritance/subclass()'ing).

      -

      32.3.16 STL support

      +

      32.3.16 STL support

      Various STL library files are provided for wrapping STL containers.

      -

      32.3.17 Matrix typemaps

      +

      32.3.17 Matrix typemaps

      diff --git a/Doc/Manual/Perl5.html b/Doc/Manual/Perl5.html index 8bc7cbfd3..bb912ec8e 100644 --- a/Doc/Manual/Perl5.html +++ b/Doc/Manual/Perl5.html @@ -6,7 +6,7 @@ -

      33 SWIG and Perl5

      +

      33 SWIG and Perl5

        @@ -96,7 +96,7 @@ later. We're no longer testing regularly with older versions, but Perl 5.6 seems to mostly work, while older versions don't.

        -

        33.1 Overview

        +

        33.1 Overview

        @@ -117,7 +117,7 @@ described. Advanced customization features, typemaps, and other options are found near the end of the chapter.

        -

        33.2 Preliminaries

        +

        33.2 Preliminaries

        @@ -142,7 +142,7 @@ To build the module, you will need to compile the file example_wrap.c and link it with the rest of your program.

        -

        33.2.1 Getting the right header files

        +

        33.2.1 Getting the right header files

        @@ -174,7 +174,7 @@ $ perl -e 'use Config; print "$Config{archlib}\n";'

      -

      33.2.2 Compiling a dynamic module

      +

      33.2.2 Compiling a dynamic module

      @@ -207,7 +207,7 @@ the target should be named `example.so', `example.sl', or the appropriate dynamic module name on your system.

      -

      33.2.3 Building a dynamic module with MakeMaker

      +

      33.2.3 Building a dynamic module with MakeMaker

      @@ -241,7 +241,7 @@ the preferred approach to compilation. More information about MakeMaker can be found in "Programming Perl, 2nd ed." by Larry Wall, Tom Christiansen, and Randal Schwartz.

      -

      33.2.4 Building a static version of Perl

      +

      33.2.4 Building a static version of Perl

      @@ -310,7 +310,7 @@ added to it. Depending on your machine, you may need to link with additional libraries such as -lsocket, -lnsl, -ldl, etc.

      -

      33.2.5 Using the module

      +

      33.2.5 Using the module

      @@ -463,7 +463,7 @@ system configuration (this requires root access and you will need to read the man pages).

      -

      33.2.6 Compilation problems and compiling with C++

      +

      33.2.6 Compilation problems and compiling with C++

      @@ -606,7 +606,7 @@ have to find the macro that conflicts and add an #undef into the .i file. Pleas any conflicting macros you find to swig-user mailing list.

      -

      33.2.7 Compiling for 64-bit platforms

      +

      33.2.7 Compiling for 64-bit platforms

      @@ -633,7 +633,7 @@ also introduce problems on platforms that support more than one linking standard (e.g., -o32 and -n32 on Irix).

      -

      33.3 Building Perl Extensions under Windows

      +

      33.3 Building Perl Extensions under Windows

      @@ -644,7 +644,7 @@ section assumes you are using SWIG with Microsoft Visual C++ although the procedure may be similar with other compilers.

      -

      33.3.1 Running SWIG from Developer Studio

      +

      33.3.1 Running SWIG from Developer Studio

      @@ -707,7 +707,7 @@ print "$a\n"; -

      33.3.2 Using other compilers

      +

      33.3.2 Using other compilers

      @@ -715,7 +715,7 @@ SWIG is known to work with Cygwin and may work with other compilers on Windows. For general hints and suggestions refer to the Windows chapter.

      -

      33.4 The low-level interface

      +

      33.4 The low-level interface

      @@ -725,7 +725,7 @@ can be used to control your application. However, it is also used to construct more user-friendly proxy classes as described in the next section.

      -

      33.4.1 Functions

      +

      33.4.1 Functions

      @@ -748,7 +748,7 @@ use example; $a = &example::fact(2); -

      33.4.2 Global variables

      +

      33.4.2 Global variables

      @@ -818,7 +818,7 @@ extern char *path; // Declared later in the input -

      33.4.3 Constants

      +

      33.4.3 Constants

      @@ -858,7 +858,7 @@ print example::FOO,"\n"; -

      33.4.4 Pointers

      +

      33.4.4 Pointers

      @@ -967,7 +967,7 @@ as XS and xsubpp. Given the advancement of the SWIG typesystem and the SWIG and XS, this is no longer supported.

      -

      33.4.5 Structures

      +

      33.4.5 Structures

      @@ -1101,7 +1101,7 @@ void Bar_f_set(Bar *b, Foo *val) { -

      33.4.6 C++ classes

      +

      33.4.6 C++ classes

      @@ -1166,7 +1166,7 @@ provides direct access to C++ objects. A higher level interface using Perl prox can be built using these low-level accessors. This is described shortly.

      -

      33.4.7 C++ classes and type-checking

      +

      33.4.7 C++ classes and type-checking

      @@ -1202,7 +1202,7 @@ If necessary, the type-checker also adjusts the value of the pointer (as is nece multiple inheritance is used).

      -

      33.4.8 C++ overloaded functions

      +

      33.4.8 C++ overloaded functions

      @@ -1246,7 +1246,7 @@ example::Spam_foo_d($s,3.14); Please refer to the "SWIG Basics" chapter for more information.

      -

      33.4.9 Operators

      +

      33.4.9 Operators

      @@ -1273,7 +1273,7 @@ The following C++ operators are currently supported by the Perl module:

    • operator or
      • -

      33.4.10 Modules and packages

      +

      33.4.10 Modules and packages

      @@ -1368,7 +1368,7 @@ print Foo::fact(4),"\n"; # Call a function in package FooBar --> -

      33.5 Input and output parameters

      +

      33.5 Input and output parameters

      @@ -1587,7 +1587,7 @@ print "$c\n"; Note: The REFERENCE feature is only currently supported for numeric types (integers and floating point).

      -

      33.6 Exception handling

      +

      33.6 Exception handling

      @@ -1752,7 +1752,7 @@ This is still supported, but it is deprecated. The newer %exception di functionality, but it has additional capabilities that make it more powerful.

      -

      33.7 Remapping datatypes with typemaps

      +

      33.7 Remapping datatypes with typemaps

      @@ -1769,7 +1769,7 @@ Typemaps are only used if you want to change some aspect of the primitive C-Perl interface.

      -

      33.7.1 A simple typemap example

      +

      33.7.1 A simple typemap example

      @@ -1873,7 +1873,7 @@ example::count("e","Hello World"); -

      33.7.2 Perl5 typemaps

      +

      33.7.2 Perl5 typemaps

      @@ -1978,7 +1978,7 @@ Return of C++ member data (all languages). Check value of input parameter. -

      33.7.3 Typemap variables

      +

      33.7.3 Typemap variables

      @@ -2049,7 +2049,7 @@ properly assigned. The Perl name of the wrapper function being created. -

      33.7.4 Useful functions

      +

      33.7.4 Useful functions

      @@ -2118,7 +2118,7 @@ int sv_isa(SV *, char *0; -

      33.8 Typemap Examples

      +

      33.8 Typemap Examples

      @@ -2127,7 +2127,7 @@ might look at the files "perl5.swg" and "typemaps.i" in the SWIG library.

      -

      33.8.1 Converting a Perl5 array to a char **

      +

      33.8.1 Converting a Perl5 array to a char **

      @@ -2219,7 +2219,7 @@ print @$b,"\n"; # Print it out -

      33.8.2 Return values

      +

      33.8.2 Return values

      @@ -2248,7 +2248,7 @@ can be done using the EXTEND() macro as in: } -

      33.8.3 Returning values from arguments

      +

      33.8.3 Returning values from arguments

      @@ -2302,7 +2302,7 @@ print "multout(7,13) = @r\n"; ($x,$y) = multout(7,13); -

      33.8.4 Accessing array structure members

      +

      33.8.4 Accessing array structure members

      @@ -2365,7 +2365,7 @@ the "in" typemap in the previous section would be used to convert an to copy the converted array into a C data structure.

      -

      33.8.5 Turning Perl references into C pointers

      +

      33.8.5 Turning Perl references into C pointers

      @@ -2430,7 +2430,7 @@ print "$c\n"; -

      33.8.6 Pointer handling

      +

      33.8.6 Pointer handling

      @@ -2509,7 +2509,7 @@ For example: -

      33.9 Proxy classes

      +

      33.9 Proxy classes

      @@ -2525,7 +2525,7 @@ to the underlying code. This section describes the implementation details of the proxy interface.

      -

      33.9.1 Preliminaries

      +

      33.9.1 Preliminaries

      @@ -2547,7 +2547,7 @@ SWIG creates a collection of high-level Perl wrappers. In your scripts, you wil high level wrappers. The wrappers, in turn, interact with the low-level procedural module.

      -

      33.9.2 Structure and class wrappers

      +

      33.9.2 Structure and class wrappers

      @@ -2673,7 +2673,7 @@ $v->DESTROY(); -

      33.9.3 Object Ownership

      +

      33.9.3 Object Ownership

      @@ -2760,7 +2760,7 @@ counting, garbage collection, or advanced features one might find in sophisticated languages.

      -

      33.9.4 Nested Objects

      +

      33.9.4 Nested Objects

      @@ -2813,7 +2813,7 @@ $p->{f}->{x} = 0.0; %${$p->{v}} = ( x=>0, y=>0, z=>0); -

      33.9.5 Proxy Functions

      +

      33.9.5 Proxy Functions

      @@ -2847,7 +2847,7 @@ This function replaces the original function, but operates in an identical manner.

      -

      33.9.6 Inheritance

      +

      33.9.6 Inheritance

      @@ -2923,7 +2923,7 @@ particular, inheritance of data members is extremely tricky (and I'm not even sure if it really works).

      -

      33.9.7 Modifying the proxy methods

      +

      33.9.7 Modifying the proxy methods

      @@ -2951,7 +2951,7 @@ public: }; -

      33.10 Adding additional Perl code

      +

      33.10 Adding additional Perl code

      @@ -3002,7 +3002,7 @@ set_transform($im, $a); -

      33.11 Cross language polymorphism

      +

      33.11 Cross language polymorphism

      @@ -3036,7 +3036,7 @@ proxy classes, director classes, and C wrapper functions takes care of all the cross-language method routing transparently.

      -

      33.11.1 Enabling directors

      +

      33.11.1 Enabling directors

      @@ -3126,7 +3126,7 @@ sub one { -

      33.11.2 Director classes

      +

      33.11.2 Director classes

      @@ -3206,7 +3206,7 @@ so there is no need for the extra overhead involved with routing the calls through Perl.

      -

      33.11.3 Ownership and object destruction

      +

      33.11.3 Ownership and object destruction

      @@ -3255,7 +3255,7 @@ sub DESTROY { -

      33.11.4 Exception unrolling

      +

      33.11.4 Exception unrolling

      @@ -3311,7 +3311,7 @@ Swig::DirectorMethodException is thrown, Perl will register the exception as soon as the C wrapper function returns.

      -

      33.11.5 Overhead and code bloat

      +

      33.11.5 Overhead and code bloat

      @@ -3345,7 +3345,7 @@ directive) for only those methods that are likely to be extended in Perl.

      -

      33.11.6 Typemaps

      +

      33.11.6 Typemaps

      diff --git a/Doc/Manual/Php.html b/Doc/Manual/Php.html index 623adb68a..e1adce5ad 100644 --- a/Doc/Manual/Php.html +++ b/Doc/Manual/Php.html @@ -7,7 +7,7 @@ -

      34 SWIG and PHP

      +

      34 SWIG and PHP

        @@ -80,7 +80,7 @@ your extension into php directly, you will need the complete PHP source tree available.

        -

        34.1 Generating PHP Extensions

        +

        34.1 Generating PHP Extensions

        @@ -125,7 +125,7 @@ and it doesn't play nicely with package system. We don't recommend this approach, or provide explicit support for it.

        -

        34.1.1 Building a loadable extension

        +

        34.1.1 Building a loadable extension

        @@ -140,7 +140,7 @@ least work for Linux though): gcc -shared example_wrap.o example.o -o example.so

      -

      34.1.2 Using PHP Extensions

      +

      34.1.2 Using PHP Extensions

      @@ -188,7 +188,7 @@ This PHP module also defines the PHP classes for the wrapped API, so you'll almost certainly want to include it anyway.

      -

      34.2 Basic PHP interface

      +

      34.2 Basic PHP interface

      @@ -199,7 +199,7 @@ other symbols unless care is taken to %rename them. At present SWIG doesn't have support for the namespace feature added in PHP 5.3.

      -

      34.2.1 Constants

      +

      34.2.1 Constants

      @@ -276,7 +276,7 @@ is treated as true by the if test, when the value of the intended constant would be treated as false!

      -

      34.2.2 Global Variables

      +

      34.2.2 Global Variables

      @@ -325,7 +325,7 @@ undefined. At this time SWIG does not support custom accessor methods.

      -

      34.2.3 Functions

      +

      34.2.3 Functions

      @@ -378,7 +378,7 @@ print $s; # The value of $s was not changed. --> -

      34.2.4 Overloading

      +

      34.2.4 Overloading

      @@ -434,7 +434,7 @@ taking the integer argument.

      --> -

      34.2.5 Pointers and References

      +

      34.2.5 Pointers and References

      @@ -579,7 +579,7 @@ PHP in a number of ways: by using unset on an existing variable, or assigning NULL to a variable.

      -

      34.2.6 Structures and C++ classes

      +

      34.2.6 Structures and C++ classes

      @@ -640,7 +640,7 @@ Would be used in the following way from PHP5: Member variables and methods are accessed using the -> operator.

      -

      34.2.6.1 Using -noproxy

      +

      34.2.6.1 Using -noproxy

      @@ -666,7 +666,7 @@ Complex_im_set($obj,$d); Complex_im_get($obj); -

      34.2.6.2 Constructors and Destructors

      +

      34.2.6.2 Constructors and Destructors

      @@ -707,7 +707,7 @@ the programmer can either reassign the variable or call unset($v)

      -

      34.2.6.3 Static Member Variables

      +

      34.2.6.3 Static Member Variables

      @@ -750,7 +750,7 @@ Ko::threats(10); echo "There have now been " . Ko::threats() . " threats\n"; -

      34.2.6.4 Static Member Functions

      +

      34.2.6.4 Static Member Functions

      @@ -772,7 +772,7 @@ Ko::threats(); -

      34.2.6.5 Specifying Implemented Interfaces

      +

      34.2.6.5 Specifying Implemented Interfaces

      @@ -790,7 +790,7 @@ so: If there are multiple interfaces, just list them separated by commas.

      -

      34.2.7 PHP Pragmas, Startup and Shutdown code

      +

      34.2.7 PHP Pragmas, Startup and Shutdown code

      @@ -878,7 +878,7 @@ The %rinit and %rshutdown statements are very similar but inse into the request init (PHP_RINIT_FUNCTION) and request shutdown (PHP_RSHUTDOWN_FUNCTION) code respectively.

      -

      34.3 Cross language polymorphism

      +

      34.3 Cross language polymorphism

      @@ -913,7 +913,7 @@ wrapper functions takes care of all the cross-language method routing transparently.

      -

      34.3.1 Enabling directors

      +

      34.3.1 Enabling directors

      @@ -1002,7 +1002,7 @@ class MyFoo extends Foo { -

      34.3.2 Director classes

      +

      34.3.2 Director classes

      @@ -1082,7 +1082,7 @@ so there is no need for the extra overhead involved with routing the calls through PHP.

      -

      34.3.3 Ownership and object destruction

      +

      34.3.3 Ownership and object destruction

      @@ -1138,7 +1138,7 @@ In this example, we are assuming that FooContainer will take care of deleting all the Foo pointers it contains at some point.

      -

      34.3.4 Exception unrolling

      +

      34.3.4 Exception unrolling

      @@ -1197,7 +1197,7 @@ Swig::DirectorMethodException is thrown, PHP will register the exception as soon as the C wrapper function returns.

      -

      34.3.5 Overhead and code bloat

      +

      34.3.5 Overhead and code bloat

      @@ -1230,7 +1230,7 @@ optimized by selectively enabling director methods (using the %feature directive) for only those methods that are likely to be extended in PHP.

      -

      34.3.6 Typemaps

      +

      34.3.6 Typemaps

      @@ -1244,7 +1244,7 @@ need to be supported.

      -

      34.3.7 Miscellaneous

      +

      34.3.7 Miscellaneous

      Director typemaps for STL classes are mostly in place, and hence you diff --git a/Doc/Manual/Pike.html b/Doc/Manual/Pike.html index 44c6930f8..c7e75d00c 100644 --- a/Doc/Manual/Pike.html +++ b/Doc/Manual/Pike.html @@ -6,7 +6,7 @@ -

      35 SWIG and Pike

      +

      35 SWIG and Pike

        @@ -46,10 +46,10 @@ least, make sure you read the "SWIG Basics" chapter.

        -

        35.1 Preliminaries

        +

        35.1 Preliminaries

        -

        35.1.1 Running SWIG

        +

        35.1.1 Running SWIG

        @@ -94,7 +94,7 @@ can use the -o option: 

        $ swig -pike -o pseudonym.c example.i
        -

        35.1.2 Getting the right header files

        +

        35.1.2 Getting the right header files

        @@ -114,7 +114,7 @@ You're looking for files with the names global.h, program.h and so on.

        -

        35.1.3 Using your module

        +

        35.1.3 Using your module

        @@ -129,10 +129,10 @@ Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend) (1) Result: 24

      -

      35.2 Basic C/C++ Mapping

      +

      35.2 Basic C/C++ Mapping

      -

      35.2.1 Modules

      +

      35.2.1 Modules

      @@ -143,7 +143,7 @@ concerned), SWIG's %module directive doesn't really have any significance.

      -

      35.2.2 Functions

      +

      35.2.2 Functions

      @@ -168,7 +168,7 @@ exactly as you'd expect it to: (1) Result: 24 -

      35.2.3 Global variables

      +

      35.2.3 Global variables

      @@ -197,7 +197,7 @@ will result in two functions, Foo_get() and Foo_set(): (3) Result: 3.141590 -

      35.2.4 Constants and enumerated types

      +

      35.2.4 Constants and enumerated types

      @@ -205,7 +205,7 @@ Enumerated types in C/C++ declarations are wrapped as Pike constants, not as Pike enums.

      -

      35.2.5 Constructors and Destructors

      +

      35.2.5 Constructors and Destructors

      @@ -213,7 +213,7 @@ Constructors are wrapped as create() methods, and destructors are wrapped as destroy() methods, for Pike classes.

      -

      35.2.6 Static Members

      +

      35.2.6 Static Members

      diff --git a/Doc/Manual/Preface.html b/Doc/Manual/Preface.html index 6ddea588a..186bc415d 100644 --- a/Doc/Manual/Preface.html +++ b/Doc/Manual/Preface.html @@ -6,7 +6,7 @@ -

      1 Preface

      +

      1 Preface

        @@ -35,7 +35,7 @@ -

        1.1 Introduction

        +

        1.1 Introduction

        @@ -58,7 +58,7 @@ has since evolved into a general purpose tool that is used in a wide variety of applications--in fact almost anything where C/C++ programming is involved. -

        1.2 SWIG Versions

        +

        1.2 SWIG Versions

        @@ -70,7 +70,7 @@ An official stable version was released along with the decision to make SWIG license changes and this gave rise to version 2.0.0 in 2010.

        -

        1.3 SWIG License

        +

        1.3 SWIG License

        @@ -86,7 +86,7 @@ under license terms of the user's choice/requirements and at the same time the S source was placed under the GNU General Public License version 3.

        -

        1.4 SWIG resources

        +

        1.4 SWIG resources

        @@ -126,7 +126,7 @@ about this can be obtained at: -

        1.5 Prerequisites

        +

        1.5 Prerequisites

        @@ -151,7 +151,7 @@ However, this isn't meant to be a tutorial on C++ programming. For many of the gory details, you will almost certainly want to consult a good C++ reference. If you don't program in C++, you may just want to skip those parts of the manual. -

        1.6 Organization of this manual

        +

        1.6 Organization of this manual

        @@ -163,7 +163,7 @@ can probably skip to that chapter and find almost everything you need to know.

        -

        1.7 How to avoid reading the manual

        +

        1.7 How to avoid reading the manual

        @@ -175,7 +175,7 @@ The SWIG distribution also comes with a large directory of examples that illustrate different topics.

        -

        1.8 Backwards compatibility

        +

        1.8 Backwards compatibility

        @@ -211,7 +211,7 @@ Note: The version symbol is not defined in the generated SWIG wrapper file. The SWIG preprocessor has defined SWIG_VERSION since SWIG-1.3.11.

        -

        1.9 Release notes

        +

        1.9 Release notes

        @@ -220,7 +220,7 @@ contain, respectively, detailed release notes for the current version, detailed release notes for previous releases and summary release notes from SWIG-1.3.22 onwards.

        -

        1.10 Credits

        +

        1.10 Credits

        @@ -233,7 +233,7 @@ who have made contributions at all levels over time. Contributors are mentioned either in the COPYRIGHT file or CHANGES files shipped with SWIG or in submitted bugs.

        -

        1.11 Bug reports

        +

        1.11 Bug reports

        @@ -248,10 +248,10 @@ used, and any important pieces of the SWIG generated wrapper code. We can only fix bugs if we know about them.

        -

        1.12 Installation

        +

        1.12 Installation

        -

        1.12.1 Windows installation

        +

        1.12.1 Windows installation

        @@ -262,7 +262,7 @@ the top level directory. Otherwise it is exactly the same as the main SWIG distribution. There is no need to download anything else.

        -

        1.12.2 Unix installation

        +

        1.12.2 Unix installation

        @@ -350,7 +350,7 @@ a number of packages to be installed. Full instructions at

      -

      1.12.3 Macintosh OS X installation

      +

      1.12.3 Macintosh OS X installation

      @@ -378,7 +378,7 @@ Darwin's two-level namespaces. Some details about this can be found here Needless to say, you might have to experiment a bit to get things working at first.

      -

      1.12.4 Testing

      +

      1.12.4 Testing

      @@ -432,7 +432,7 @@ have many different target languages installed and a slow machine, it might take more than an hour to run the test-suite.

      -

      1.12.5 Examples

      +

      1.12.5 Examples

      diff --git a/Doc/Manual/Preprocessor.html b/Doc/Manual/Preprocessor.html index e188fc0be..b8a6e9b0e 100644 --- a/Doc/Manual/Preprocessor.html +++ b/Doc/Manual/Preprocessor.html @@ -6,7 +6,7 @@ -

      8 Preprocessing

      +

      8 Preprocessing

        @@ -37,7 +37,7 @@ However, a number of modifications and enhancements have been made. This chapter describes some of these modifications.

        -

        8.1 File inclusion

        +

        8.1 File inclusion

        @@ -63,7 +63,7 @@ By default, the #include is ignored unless you run SWIG with the is that you often don't want SWIG to try and wrap everything included in standard header system headers and auxiliary files. -

        8.2 File imports

        +

        8.2 File imports

        @@ -92,7 +92,7 @@ The -importall directive tells SWIG to follow all #include sta as imports. This might be useful if you want to extract type definitions from system header files without generating any wrappers. -

        8.3 Conditional Compilation

        +

        8.3 Conditional Compilation

        @@ -156,7 +156,7 @@ SWIG (except for the symbol `SWIG' which is only defined within the SWIG compiler).

        -

        8.4 Macro Expansion

        +

        8.4 Macro Expansion

        @@ -211,7 +211,7 @@ like #x. This is a non-standard SWIG extension.

      -

      8.5 SWIG Macros

      +

      8.5 SWIG Macros

      @@ -257,7 +257,7 @@ many of SWIG's advanced features and libraries are built using this mechanism (s support).

      -

      8.6 C99 and GNU Extensions

      +

      8.6 C99 and GNU Extensions

      @@ -313,14 +313,14 @@ interface building. However, they are used internally to implement a number of SWIG directives and are provided to make SWIG more compatible with C99 code.

      -

      8.7 Preprocessing and delimiters

      +

      8.7 Preprocessing and delimiters

      The preprocessor handles { }, " " and %{ %} delimiters differently.

      -

      8.7.1 Preprocessing and %{ ... %} & " ... " delimiters

      +

      8.7.1 Preprocessing and %{ ... %} & " ... " delimiters

      @@ -345,7 +345,7 @@ the contents of the %{ ... %} block are copied without modification to the output (including all preprocessor directives).

      -

      8.7.2 Preprocessing and { ... } delimiters

      +

      8.7.2 Preprocessing and { ... } delimiters

      @@ -387,7 +387,7 @@ to actually go into the wrapper file, prefix the preprocessor directives with % and leave the preprocessor directive in the code.

      -

      8.8 Preprocessor and Typemaps

      +

      8.8 Preprocessor and Typemaps

      @@ -458,7 +458,7 @@ would generate

      -

      8.9 Viewing preprocessor output

      +

      8.9 Viewing preprocessor output

      @@ -468,7 +468,7 @@ Instead the results after the preprocessor has run are displayed. This might be useful as an aid to debugging and viewing the results of macro expansions.

      -

      8.10 The #error and #warning directives

      +

      8.10 The #error and #warning directives

      diff --git a/Doc/Manual/Python.html b/Doc/Manual/Python.html index c5219b693..c288581b7 100644 --- a/Doc/Manual/Python.html +++ b/Doc/Manual/Python.html @@ -6,7 +6,7 @@ -

      36 SWIG and Python

      +

      36 SWIG and Python

        @@ -148,7 +148,7 @@ very least, make sure you read the "SWIG Basics" chapter.

        -

        36.1 Overview

        +

        36.1 Overview

        @@ -175,10 +175,10 @@ described followed by a discussion of low-level implementation details.

        -

        36.2 Preliminaries

        +

        36.2 Preliminaries

        -

        36.2.1 Running SWIG

        +

        36.2.1 Running SWIG

        @@ -276,7 +276,7 @@ The following sections have further practical examples and details on how you might go about compiling and using the generated files.

        -

        36.2.2 Using distutils

        +

        36.2.2 Using distutils

        @@ -368,7 +368,7 @@ This same approach works on all platforms if the appropriate compiler is install can even build extensions to the standard Windows Python using MingGW)

        -

        36.2.3 Hand compiling a dynamic module

        +

        36.2.3 Hand compiling a dynamic module

        @@ -416,7 +416,7 @@ module actually consists of two files; socket.py and

        -

        36.2.4 Static linking

        +

        36.2.4 Static linking

        @@ -495,7 +495,7 @@ If using static linking, you might want to rely on a different approach (perhaps using distutils).

        -

        36.2.5 Using your module

        +

        36.2.5 Using your module

        @@ -652,7 +652,7 @@ system configuration (this requires root access and you will need to read the man pages).

        -

        36.2.6 Compilation of C++ extensions

        +

        36.2.6 Compilation of C++ extensions

        @@ -744,7 +744,7 @@ erratic program behavior. If working with lots of software components, you might want to investigate using a more formal standard such as COM.

        -

        36.2.7 Compiling for 64-bit platforms

        +

        36.2.7 Compiling for 64-bit platforms

        @@ -781,7 +781,7 @@ and -m64 allow you to choose the desired binary format for your python extension.

        -

        36.2.8 Building Python Extensions under Windows

        +

        36.2.8 Building Python Extensions under Windows

        @@ -910,7 +910,7 @@ SWIG Wiki.

        -

        36.3 A tour of basic C/C++ wrapping

        +

        36.3 A tour of basic C/C++ wrapping

        @@ -919,7 +919,7 @@ to your C/C++ code. Functions are wrapped as functions, classes are wrapped as This section briefly covers the essential aspects of this wrapping.

        -

        36.3.1 Modules

        +

        36.3.1 Modules

        @@ -932,7 +932,7 @@ module name, make sure you don't use the same name as a built-in Python command or standard module name.

        -

        36.3.2 Functions

        +

        36.3.2 Functions

        @@ -956,7 +956,7 @@ like you think it does: >>>

      -

      36.3.3 Global variables

      +

      36.3.3 Global variables

      @@ -1094,7 +1094,7 @@ that starts with a leading underscore. SWIG does not create cvar if there are no global variables in a module.

      -

      36.3.4 Constants and enums

      +

      36.3.4 Constants and enums

      @@ -1134,7 +1134,7 @@ other object. Unfortunately, there is no easy way for SWIG to generate code that prevents this. You will just have to be careful.

      -

      36.3.5 Pointers

      +

      36.3.5 Pointers

      @@ -1275,7 +1275,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return None if the conversion can't be performed.

      -

      36.3.6 Structures

      +

      36.3.6 Structures

      @@ -1464,7 +1464,7 @@ everything works just like you would expect. For example:

      -

      36.3.7 C++ classes

      +

      36.3.7 C++ classes

      @@ -1553,7 +1553,7 @@ they are accessed through cvar like this: -

      36.3.8 C++ inheritance

      +

      36.3.8 C++ inheritance

      @@ -1608,7 +1608,7 @@ then the function spam() accepts Foo * or a pointer to any cla It is safe to use multiple inheritance with SWIG.

      -

      36.3.9 Pointers, references, values, and arrays

      +

      36.3.9 Pointers, references, values, and arrays

      @@ -1669,7 +1669,7 @@ treated as a returning value, and it will follow the same allocation/deallocation process.

      -

      36.3.10 C++ overloaded functions

      +

      36.3.10 C++ overloaded functions

      @@ -1792,7 +1792,7 @@ first declaration takes precedence. Please refer to the "SWIG and C++" chapter for more information about overloading.

      -

      36.3.11 C++ operators

      +

      36.3.11 C++ operators

      @@ -1881,7 +1881,7 @@ Also, be aware that certain operators don't map cleanly to Python. For instance overloaded assignment operators don't map to Python semantics and will be ignored.

      -

      36.3.12 C++ namespaces

      +

      36.3.12 C++ namespaces

      @@ -1948,7 +1948,7 @@ utilizes thousands of small deeply nested namespaces each with identical symbol names, well, then you get what you deserve.

      -

      36.3.13 C++ templates

      +

      36.3.13 C++ templates

      @@ -2002,10 +2002,10 @@ Some more complicated examples will appear later.

      -

      36.3.14 C++ Smart Pointers

      +

      36.3.14 C++ Smart Pointers

      -

      36.3.14.1 The shared_ptr Smart Pointer

      +

      36.3.14.1 The shared_ptr Smart Pointer

      @@ -2016,7 +2016,7 @@ in the shared_ptr smart pointer -

      36.3.14.2 Generic Smart Pointers

      +

      36.3.14.2 Generic Smart Pointers

      @@ -2100,7 +2100,7 @@ simply use the __deref__() method. For example: -

      36.3.15 C++ reference counted objects

      +

      36.3.15 C++ reference counted objects

      @@ -2109,7 +2109,7 @@ Python examples of memory management using referencing counting.

      -

      36.4 Further details on the Python class interface

      +

      36.4 Further details on the Python class interface

      @@ -2132,7 +2132,7 @@ the -builtin option are in the Built-in section.

      -

      36.4.1 Proxy classes

      +

      36.4.1 Proxy classes

      @@ -2221,7 +2221,7 @@ you can attach new Python methods to the class and you can even inherit from it by Python built-in types until Python 2.2).

      -

      36.4.2 Built-in Types

      +

      36.4.2 Built-in Types

      @@ -2265,7 +2265,7 @@ please refer to the python documentation:

      http://docs.python.org/extending/newtypes.html

      -

      36.4.2.1 Limitations

      +

      36.4.2.1 Limitations

      Use of the -builtin option implies a couple of limitations: @@ -2433,7 +2433,7 @@ assert(issubclass(B.Derived, A.Base)) -

      36.4.2.2 Operator overloads -- use them!

      +

      36.4.2.2 Operator overloads -- use them!

      The entire justification for the -builtin option is improved @@ -2534,7 +2534,7 @@ structs.

      -

      36.4.3 Memory management

      +

      36.4.3 Memory management

      NOTE: Although this section refers to proxy objects, everything here also applies @@ -2729,7 +2729,7 @@ It is also possible to deal with situations like this using typemaps--an advanced topic discussed later.

      -

      36.4.4 Python 2.2 and classic classes

      +

      36.4.4 Python 2.2 and classic classes

      @@ -2766,7 +2766,7 @@ class itself. In Python-2.1 and earlier, they have to be accessed as a global function or through an instance (see the earlier section).

      -

      36.5 Cross language polymorphism

      +

      36.5 Cross language polymorphism

      @@ -2800,7 +2800,7 @@ proxy classes, director classes, and C wrapper functions takes care of all the cross-language method routing transparently.

      -

      36.5.1 Enabling directors

      +

      36.5.1 Enabling directors

      @@ -2892,7 +2892,7 @@ class MyFoo(mymodule.Foo): -

      36.5.2 Director classes

      +

      36.5.2 Director classes

      @@ -2974,7 +2974,7 @@ so there is no need for the extra overhead involved with routing the calls through Python.

      -

      36.5.3 Ownership and object destruction

      +

      36.5.3 Ownership and object destruction

      @@ -3041,7 +3041,7 @@ deleting all the Foo pointers it contains at some point. Note that no hard references to the Foo objects remain in Python.

      -

      36.5.4 Exception unrolling

      +

      36.5.4 Exception unrolling

      @@ -3100,7 +3100,7 @@ Swig::DirectorMethodException is thrown, Python will register the exception as soon as the C wrapper function returns.

      -

      36.5.5 Overhead and code bloat

      +

      36.5.5 Overhead and code bloat

      @@ -3134,7 +3134,7 @@ directive) for only those methods that are likely to be extended in Python.

      -

      36.5.6 Typemaps

      +

      36.5.6 Typemaps

      @@ -3148,7 +3148,7 @@ need to be supported.

      -

      36.5.7 Miscellaneous

      +

      36.5.7 Miscellaneous

      @@ -3195,7 +3195,7 @@ methods that return const references.

      -

      36.6 Common customization features

      +

      36.6 Common customization features

      @@ -3208,7 +3208,7 @@ This section describes some common SWIG features that are used to improve your the interface to an extension module.

      -

      36.6.1 C/C++ helper functions

      +

      36.6.1 C/C++ helper functions

      @@ -3289,7 +3289,7 @@ hard to implement. It is possible to clean this up using Python code, typemaps, customization features as covered in later sections.

      -

      36.6.2 Adding additional Python code

      +

      36.6.2 Adding additional Python code

      @@ -3541,7 +3541,7 @@ The same applies for overloaded constructors.

      -

      36.6.3 Class extension with %extend

      +

      36.6.3 Class extension with %extend

      @@ -3630,7 +3630,7 @@ Vector(12,14,16) in any way---the extensions only show up in the Python interface.

      -

      36.6.4 Exception handling with %exception

      +

      36.6.4 Exception handling with %exception

      @@ -3756,7 +3756,7 @@ The language-independent exception.i library file can also be used to raise exceptions. See the SWIG Library chapter.

      -

      36.7 Tips and techniques

      +

      36.7 Tips and techniques

      @@ -3766,7 +3766,7 @@ strings, binary data, and arrays. This chapter discusses the common techniques solving these problems.

      -

      36.7.1 Input and output parameters

      +

      36.7.1 Input and output parameters

      @@ -3979,7 +3979,7 @@ void foo(Bar *OUTPUT); may not have the intended effect since typemaps.i does not define an OUTPUT rule for Bar.

      -

      36.7.2 Simple pointers

      +

      36.7.2 Simple pointers

      @@ -4048,7 +4048,7 @@ If you replace %pointer_functions() by %pointer_class(type,name)SWIG Library chapter for further details.

      -

      36.7.3 Unbounded C Arrays

      +

      36.7.3 Unbounded C Arrays

      @@ -4110,7 +4110,7 @@ well suited for applications in which you need to create buffers, package binary data, etc.

      -

      36.7.4 String handling

      +

      36.7.4 String handling

      @@ -4180,7 +4180,7 @@ also be used to extra binary data from arbitrary pointers.

      -

      36.7.5 Default arguments

      +

      36.7.5 Default arguments

      @@ -4279,7 +4279,7 @@ Versions of SWIG prior to this varied in their ability to convert C++ default va equivalent Python default argument values.

      -

      36.8 Typemaps

      +

      36.8 Typemaps

      @@ -4296,7 +4296,7 @@ Typemaps are only used if you want to change some aspect of the primitive C-Python interface or if you want to elevate your guru status.

      -

      36.8.1 What is a typemap?

      +

      36.8.1 What is a typemap?

      @@ -4412,7 +4412,7 @@ parameter is omitted): -

      36.8.2 Python typemaps

      +

      36.8.2 Python typemaps

      @@ -4453,7 +4453,7 @@ a look at the SWIG library version 1.3.20 or so.

      -

      36.8.3 Typemap variables

      +

      36.8.3 Typemap variables

      @@ -4524,7 +4524,7 @@ properly assigned. The Python name of the wrapper function being created. -

      36.8.4 Useful Python Functions

      +

      36.8.4 Useful Python Functions

      @@ -4652,7 +4652,7 @@ write me -

      36.9 Typemap Examples

      +

      36.9 Typemap Examples

      @@ -4661,7 +4661,7 @@ might look at the files "python.swg" and "typemaps.i" in the SWIG library.

      -

      36.9.1 Converting Python list to a char **

      +

      36.9.1 Converting Python list to a char **

      @@ -4741,7 +4741,7 @@ memory allocation is used to allocate memory for the array, the the C function.

      -

      36.9.2 Expanding a Python object into multiple arguments

      +

      36.9.2 Expanding a Python object into multiple arguments

      @@ -4820,7 +4820,7 @@ to supply the argument count. This is automatically set by the typemap code. F -

      36.9.3 Using typemaps to return arguments

      +

      36.9.3 Using typemaps to return arguments

      @@ -4908,7 +4908,7 @@ function can now be used as follows: >>> -

      36.9.4 Mapping Python tuples into small arrays

      +

      36.9.4 Mapping Python tuples into small arrays

      @@ -4957,7 +4957,7 @@ array, such an approach would not be recommended for huge arrays, but for small structures, this approach works fine.

      -

      36.9.5 Mapping sequences to C arrays

      +

      36.9.5 Mapping sequences to C arrays

      @@ -5046,7 +5046,7 @@ static int convert_darray(PyObject *input, double *ptr, int size) { -

      36.9.6 Pointer handling

      +

      36.9.6 Pointer handling

      @@ -5143,7 +5143,7 @@ class object (if applicable). -

      36.10 Docstring Features

      +

      36.10 Docstring Features

      @@ -5171,7 +5171,7 @@ of your users much simpler.

      -

      36.10.1 Module docstring

      +

      36.10.1 Module docstring

      @@ -5205,7 +5205,7 @@ layout of controls on a panel, etc. to be loaded from an XML file." -

      36.10.2 %feature("autodoc")

      +

      36.10.2 %feature("autodoc")

      @@ -5233,7 +5233,7 @@ four levels for autodoc controlled by the value given to the feature, %feature("autodoc", "level"). The four values for level are covered in the following sub-sections. -

      36.10.2.1 %feature("autodoc", "0")

      +

      36.10.2.1 %feature("autodoc", "0")

      @@ -5262,7 +5262,7 @@ def function_name(*args, **kwargs): -

      36.10.2.2 %feature("autodoc", "1")

      +

      36.10.2.2 %feature("autodoc", "1")

      @@ -5287,7 +5287,7 @@ def function_name(*args, **kwargs): -

      36.10.2.3 %feature("autodoc", "2")

      +

      36.10.2.3 %feature("autodoc", "2")

      @@ -5349,7 +5349,7 @@ def function_name(*args, **kwargs): -

      36.10.2.4 %feature("autodoc", "3")

      +

      36.10.2.4 %feature("autodoc", "3")

      @@ -5375,7 +5375,7 @@ def function_name(*args, **kwargs): -

      36.10.2.5 %feature("autodoc", "docstring")

      +

      36.10.2.5 %feature("autodoc", "docstring")

      @@ -5394,7 +5394,7 @@ void GetPosition(int* OUTPUT, int* OUTPUT); -

      36.10.3 %feature("docstring")

      +

      36.10.3 %feature("docstring")

      @@ -5426,7 +5426,7 @@ with more than one line. -

      36.11 Python Packages

      +

      36.11 Python Packages

      Python has concepts of modules and packages. Modules are separate units of @@ -5484,7 +5484,7 @@ users may need to use special features such as the package option in th %module directive or import related command line options. These are explained in the following sections.

      -

      36.11.1 Setting the Python package

      +

      36.11.1 Setting the Python package

      @@ -5538,7 +5538,7 @@ pkg1/pkg2/_foo.so # (shared library built from C/C++ code generated by SWI -

      36.11.2 Absolute and relative imports

      +

      36.11.2 Absolute and relative imports

      Suppose, we have the following hierarchy of files:

      @@ -5677,7 +5677,7 @@ uses relative imports. Second case is, when one puts import directives in __init__.py to import symbols from submodules or subpackages and the submodule depends on other submodules (discussed later).

      -

      36.11.3 Enforcing absolute import semantics

      +

      36.11.3 Enforcing absolute import semantics

      As you may know, there is an incompatibility in import semantics (for the @@ -5714,7 +5714,7 @@ from __future__ import absolute_import -

      36.11.4 Importing from __init__.py

      +

      36.11.4 Importing from __init__.py

      Imports in __init__.py are handy when you want to populate a @@ -5825,7 +5825,7 @@ effect (note, that the Python 2 case also needs the -relativeimport workaround).

      -

      36.12 Python 3 Support

      +

      36.12 Python 3 Support

      @@ -5852,7 +5852,7 @@ The following are Python 3.0 new features that are currently supported by SWIG.

      -

      36.12.1 Function annotation

      +

      36.12.1 Function annotation

      @@ -5885,7 +5885,7 @@ For detailed usage of function annotation, see PEP 3107.

      -

      36.12.2 Buffer interface

      +

      36.12.2 Buffer interface

      @@ -6037,7 +6037,7 @@ modify the buffer. -

      36.12.3 Abstract base classes

      +

      36.12.3 Abstract base classes

      @@ -6078,7 +6078,7 @@ For details of abstract base class, please see PEP 3119.

      -

      36.12.4 Byte string output conversion

      +

      36.12.4 Byte string output conversion

      @@ -6164,7 +6164,7 @@ For more details about the surrogateescape error handler, please see PEP 383.

      -

      36.12.5 Python 2 Unicode

      +

      36.12.5 Python 2 Unicode

      diff --git a/Doc/Manual/R.html b/Doc/Manual/R.html index 50e861b22..fc60f368e 100644 --- a/Doc/Manual/R.html +++ b/Doc/Manual/R.html @@ -6,7 +6,7 @@ -

      37 SWIG and R

      +

      37 SWIG and R

        @@ -33,7 +33,7 @@ compile and run an R interface to QuantLib running on Mandriva Linux with gcc. The R bindings also work on Microsoft Windows using Visual C++.

        -

        37.1 Bugs

        +

        37.1 Bugs

        @@ -45,7 +45,7 @@ Currently the following features are not implemented or broken:

      • C Array wrappings
      -

      37.2 Using R and SWIG

      +

      37.2 Using R and SWIG

      @@ -136,7 +136,7 @@ Error in .Call("R_swig_fact", s_arg1, as.logical(.copy), PACKAGE = "example") :

    • Make sure the architecture of the shared library(x64 for instance), matches the architecture of the R program you want to load your shared library into -

      37.3 Precompiling large R files

      +

      37.3 Precompiling large R files

      In cases where the R file is large, one make save a lot of loading @@ -154,7 +154,7 @@ will save a large amount of loading time. -

      37.4 General policy

      +

      37.4 General policy

      @@ -163,7 +163,7 @@ wrapping over the underlying functions and rely on the R type system to provide R syntax.

      -

      37.5 Language conventions

      +

      37.5 Language conventions

      @@ -172,7 +172,7 @@ and [ are overloaded to allow for R syntax (one based indices and slices)

      -

      37.6 C++ classes

      +

      37.6 C++ classes

      @@ -184,7 +184,7 @@ keep track of the pointer object which removes the necessity for a lot of the proxy class baggage you see in other languages.

      -

      37.7 Enumerations

      +

      37.7 Enumerations

      diff --git a/Doc/Manual/Ruby.html b/Doc/Manual/Ruby.html index 2de9f673e..4663b4c95 100644 --- a/Doc/Manual/Ruby.html +++ b/Doc/Manual/Ruby.html @@ -7,7 +7,7 @@ -

      38 SWIG and Ruby

      +

      38 SWIG and Ruby

        @@ -148,7 +148,7 @@

        This chapter describes SWIG's support of Ruby.

        -

        38.1 Preliminaries

        +

        38.1 Preliminaries

        SWIG 3.0 is known to work with Ruby versions 1.8 and later. @@ -163,7 +163,7 @@ read the "SWIG Basics" chapter. It is also assumed that the reader has a basic understanding of Ruby.

        -

        38.1.1 Running SWIG

        +

        38.1.1 Running SWIG

        To build a Ruby module, run SWIG using the -ruby @@ -187,7 +187,7 @@ if compiling a C++ extension) that contains all of the code needed to build a Ruby extension module. To finish building the module, you need to compile this file and link it with the rest of your program.

        -

        38.1.2 Getting the right header files

        +

        38.1.2 Getting the right header files

        In order to compile the wrapper code, the compiler needs the ruby.h @@ -216,7 +216,7 @@ installed, you can run Ruby to find out. For example:

      -

      38.1.3 Compiling a dynamic module

      +

      38.1.3 Compiling a dynamic module

      Ruby extension modules are typically compiled into shared @@ -289,7 +289,7 @@ manual pages for your compiler and linker to determine the correct set of options. You might also check the SWIG Wiki for additional information.

      -

      38.1.4 Using your module

      +

      38.1.4 Using your module

      Ruby module names must be capitalized, @@ -319,7 +319,7 @@ begins with:

      will result in an extension module using the feature name "example" and Ruby module name "Example".

      -

      38.1.5 Static linking

      +

      38.1.5 Static linking

      An alternative approach to dynamic linking is to rebuild the @@ -334,7 +334,7 @@ finding the Ruby source, adding an entry to the ext/Setup file, adding your directory to the list of extensions in the file, and finally rebuilding Ruby.

      -

      38.1.6 Compilation of C++ extensions

      +

      38.1.6 Compilation of C++ extensions

      On most machines, C++ extension modules should be linked @@ -366,7 +366,7 @@ $libs = append_library($libs, "supc++") create_makefile('example')

      • -

      38.2 Building Ruby Extensions under Windows 95/NT

      +

      38.2 Building Ruby Extensions under Windows 95/NT

      Building a SWIG extension to Ruby under Windows 95/NT is @@ -391,7 +391,7 @@ order to build extensions, you may need to download the source distribution to the Ruby package, as you will need the Ruby header files.

      -

      38.2.1 Running SWIG from Developer Studio

      +

      38.2.1 Running SWIG from Developer Studio

      If you are developing your application within Microsoft @@ -455,13 +455,13 @@ Foo = 3.0 -

      38.3 The Ruby-to-C/C++ Mapping

      +

      38.3 The Ruby-to-C/C++ Mapping

      This section describes the basics of how SWIG maps C or C++ declarations in your SWIG interface files to Ruby constructs.

      -

      38.3.1 Modules

      +

      38.3.1 Modules

      The SWIG %module directive specifies @@ -533,7 +533,7 @@ option to wrap everything into the global module, take care that the names of your constants, classes and methods don't conflict with any of Ruby's built-in names.

      -

      38.3.2 Functions

      +

      38.3.2 Functions

      Global functions are wrapped as Ruby module methods. For @@ -567,7 +567,7 @@ irb(main):002:0> Example.fact(4) 24 -

      38.3.3 Variable Linking

      +

      38.3.3 Variable Linking

      C/C++ global variables are wrapped as a pair of singleton @@ -629,7 +629,7 @@ directive. For example:

      effect until it is explicitly disabled using %mutable.

      -

      38.3.4 Constants

      +

      38.3.4 Constants

      C/C++ constants are wrapped as module constants initialized @@ -657,7 +657,7 @@ irb(main):002:0> Example::PI 3.14159 -

      38.3.5 Pointers

      +

      38.3.5 Pointers

      "Opaque" pointers to arbitrary C/C++ types (i.e. types that @@ -681,7 +681,7 @@ returns an instance of an internally generated Ruby class:

      A NULL pointer is always represented by the Ruby nil object.

      -

      38.3.6 Structures

      +

      38.3.6 Structures

      C/C++ structs are wrapped as Ruby classes, with accessor @@ -786,7 +786,7 @@ void Bar_f_set(Bar *b, Foo *val) { } -

      38.3.7 C++ classes

      +

      38.3.7 C++ classes

      Like structs, C++ classes are wrapped by creating a new Ruby @@ -841,7 +841,7 @@ Ale 3 -

      38.3.8 C++ Inheritance

      +

      38.3.8 C++ Inheritance

      The SWIG type-checker is fully aware of C++ inheritance. @@ -994,7 +994,7 @@ inherit from both Base1 and Base2 (i.e. they exhibit "Duck Typing").

      -

      38.3.9 C++ Overloaded Functions

      +

      38.3.9 C++ Overloaded Functions

      C++ overloaded functions, methods, and constructors are @@ -1084,7 +1084,7 @@ arises--in this case, the first declaration takes precedence.

      Please refer to the "SWIG and C++" chapter for more information about overloading.

      -

      38.3.10 C++ Operators

      +

      38.3.10 C++ Operators

      For the most part, overloaded operators are handled @@ -1126,7 +1126,7 @@ c = Example.add_complex(a, b) is discussed in the section on operator overloading.

      -

      38.3.11 C++ namespaces

      +

      38.3.11 C++ namespaces

      SWIG is aware of C++ namespaces, but namespace names do not @@ -1183,7 +1183,7 @@ and create extension modules for each namespace separately. If your program utilizes thousands of small deeply nested namespaces each with identical symbol names, well, then you get what you deserve.

      -

      38.3.12 C++ templates

      +

      38.3.12 C++ templates

      C++ templates don't present a huge problem for SWIG. However, @@ -1225,7 +1225,7 @@ irb(main):004:0> p.second 4 -

      38.3.13 C++ Standard Template Library (STL)

      +

      38.3.13 C++ Standard Template Library (STL)

      On a related note, the standard SWIG library contains a @@ -1318,7 +1318,7 @@ puts v shown in these examples. More details can be found in the SWIG and C++ chapter.

      -

      38.3.14 C++ STL Functors

      +

      38.3.14 C++ STL Functors

      Some containers in the STL allow you to modify their default @@ -1379,7 +1379,7 @@ b -

      38.3.15 C++ STL Iterators

      +

      38.3.15 C++ STL Iterators

      The STL is well known for the use of iterators. There @@ -1462,10 +1462,10 @@ i

      If you'd rather have STL classes without any iterators, you should define -DSWIG_NO_EXPORT_ITERATOR_METHODS when running swig.

      -

      38.3.16 C++ Smart Pointers

      +

      38.3.16 C++ Smart Pointers

      -

      38.3.16.1 The shared_ptr Smart Pointer

      +

      38.3.16.1 The shared_ptr Smart Pointer

      @@ -1476,7 +1476,7 @@ in the shared_ptr smart pointer -

      38.3.16.2 Generic Smart Pointers

      +

      38.3.16.2 Generic Smart Pointers

      In certain C++ programs, it is common to use classes that @@ -1541,7 +1541,7 @@ method. For example: 

      irb(main):004:0> f = p.__deref__() # Returns underlying Foo *
      -

      38.3.17 Cross-Language Polymorphism

      +

      38.3.17 Cross-Language Polymorphism

      SWIG's Ruby module supports cross-language polymorphism @@ -1550,7 +1550,7 @@ module. Rather than duplicate the information presented in the 38.3.17.1 Exception Unrolling +

      38.3.17.1 Exception Unrolling

      Whenever a C++ director class routes one of its virtual @@ -1573,7 +1573,7 @@ method is "wrapped" using the rb_rescue2() function from Ruby's C API. If any Ruby exception is raised, it will be caught here and a C++ exception is raised in its place.

      -

      38.4 Naming

      +

      38.4 Naming

      Ruby has several common naming conventions. Constants are @@ -1611,7 +1611,7 @@ generated by SWIG, it is turned off by default in SWIG 1.3.28. However, it is planned to become the default option in future releases.

      -

      38.4.1 Defining Aliases

      +

      38.4.1 Defining Aliases

      It's a fairly common practice in the Ruby built-ins and @@ -1681,7 +1681,7 @@ matching rules used for other kinds of features apply (see the chapter on "Customization Features") for more details).

      -

      38.4.2 Predicate Methods

      +

      38.4.2 Predicate Methods

      Ruby methods that return a boolean value and end in a @@ -1730,7 +1730,7 @@ using SWIG's "features" mechanism and so the same name matching rules used for other kinds of features apply (see the chapter on "Customization Features") for more details).

      -

      38.4.3 Bang Methods

      +

      38.4.3 Bang Methods

      Ruby methods that modify an object in-place and end in an @@ -1762,7 +1762,7 @@ using SWIG's "features" mechanism and so the same name matching rules used for other kinds of features apply (see the chapter on "Customization Features") for more details).

      -

      38.4.4 Getters and Setters

      +

      38.4.4 Getters and Setters

      Often times a C++ library will expose properties through @@ -1797,7 +1797,7 @@ irb(main):003:0> puts foo.value %rename("value=") Foo::setValue(int value); -

      38.5 Input and output parameters

      +

      38.5 Input and output parameters

      A common problem in some C programs is handling parameters @@ -1936,10 +1936,10 @@ void get_dimensions(Matrix *m, int *rows, int*columns); 

      r, c = Example.get_dimensions(m)
      -

      38.6 Exception handling

      +

      38.6 Exception handling

      -

      38.6.1 Using the %exception directive

      +

      38.6.1 Using the %exception directive

      The SWIG %exception directive can be @@ -2048,7 +2048,7 @@ methods and functions named getitem and setitem. limited to C++ exception handling. See the chapter on Customization Features for more examples.

      -

      38.6.2 Handling Ruby Blocks

      +

      38.6.2 Handling Ruby Blocks

      One of the highlights of Ruby and most of its standard library @@ -2115,7 +2115,7 @@ a special in typemap, like:

      For more information on typemaps, see Typemaps.

      -

      38.6.3 Raising exceptions

      +

      38.6.3 Raising exceptions

      There are three ways to raise exceptions from C++ code to @@ -2272,7 +2272,7 @@ function. The first argument passed to rb_raise() is the exception type. You can raise a custom exception type or one of the built-in Ruby exception types.

      -

      38.6.4 Exception classes

      +

      38.6.4 Exception classes

      Starting with SWIG 1.3.28, the Ruby module supports the %exceptionclass @@ -2309,7 +2309,7 @@ end

      For another example look at swig/Examples/ruby/exception_class.

      -

      38.7 Typemaps

      +

      38.7 Typemaps

      This section describes how you can modify SWIG's default @@ -2324,7 +2324,7 @@ a required part of using SWIG---the default wrapping behavior is enough in most cases. Typemaps are only used if you want to change some aspect of the primitive C-Ruby interface.

      -

      38.7.1 What is a typemap?

      +

      38.7.1 What is a typemap?

      A typemap is nothing more than a code generation rule that is @@ -2481,7 +2481,7 @@ to be used as follows (notice how the length parameter is omitted):

      2 -

      38.7.2 Typemap scope

      +

      38.7.2 Typemap scope

      Once defined, a typemap remains in effect for all of the @@ -2527,7 +2527,7 @@ where the class itself is defined. For example:

      }; -

      38.7.3 Copying a typemap

      +

      38.7.3 Copying a typemap

      A typemap is copied by using assignment. For example:

      @@ -2569,7 +2569,7 @@ rules as for %apply (char *buf, int len) { (char *buffer, int size) }; // Multiple arguments -

      38.7.4 Deleting a typemap

      +

      38.7.4 Deleting a typemap

      A typemap can be deleted by simply defining no code. For @@ -2594,7 +2594,7 @@ defined by typemaps, clearing a fundamental type like int will make that type unusable unless you also define a new set of typemaps immediately after the clear operation.

      -

      38.7.5 Placement of typemaps

      +

      38.7.5 Placement of typemaps

      Typemap declarations can be declared in the global scope, @@ -2665,13 +2665,13 @@ In this example, this is done using the class declaration class string .

      -

      38.7.6 Ruby typemaps

      +

      38.7.6 Ruby typemaps

      The following list details all of the typemap methods that can be used by the Ruby module:

      -

      38.7.6.1 "in" typemap

      +

      38.7.6.1 "in" typemap

      Converts Ruby objects to input @@ -2738,7 +2738,7 @@ arguments to be specified. For example:

      At this time, only zero or one arguments may be converted.

      -

      38.7.6.2 "typecheck" typemap

      +

      38.7.6.2 "typecheck" typemap

      The "typecheck" typemap is used to support overloaded @@ -2760,7 +2760,7 @@ program uses overloaded methods, you should also define a collection of "typecheck" typemaps. More details about this follow in a later section on "Typemaps and Overloading."

      -

      38.7.6.3 "out" typemap

      +

      38.7.6.3 "out" typemap

      Converts return value of a C function @@ -2811,7 +2811,7 @@ version of the C datatype matched by the typemap.

      -

      38.7.6.4 "arginit" typemap

      +

      38.7.6.4 "arginit" typemap

      The "arginit" typemap is used to set the initial value of a @@ -2826,7 +2826,7 @@ applications. For example:

      } -

      38.7.6.5 "default" typemap

      +

      38.7.6.5 "default" typemap

      The "default" typemap is used to turn an argument into a @@ -2851,7 +2851,7 @@ arguments that follow must have default values. See the 38.7.6.6 "check" typemap +

      38.7.6.6 "check" typemap

      The "check" typemap is used to supply value checking code @@ -2866,7 +2866,7 @@ arguments have been converted. For example:

      } -

      38.7.6.7 "argout" typemap

      +

      38.7.6.7 "argout" typemap

      The "argout" typemap is used to return values from arguments. @@ -2920,7 +2920,7 @@ some function like SWIG_Ruby_AppendOutput.

      See the typemaps.i library for examples.

      -

      38.7.6.8 "freearg" typemap

      +

      38.7.6.8 "freearg" typemap

      The "freearg" typemap is used to cleanup argument data. It is @@ -2947,7 +2947,7 @@ This code is also placed into a special variable $cleanup that may be used in other typemaps whenever a wrapper function needs to abort prematurely.

      -

      38.7.6.9 "newfree" typemap

      +

      38.7.6.9 "newfree" typemap

      The "newfree" typemap is used in conjunction with the %newobject @@ -2971,7 +2971,7 @@ string *foo();

      See Object ownership and %newobject for further details.

      -

      38.7.6.10 "memberin" typemap

      +

      38.7.6.10 "memberin" typemap

      The "memberin" typemap is used to copy data from an @@ -2989,21 +2989,21 @@ example:

      already provides a default implementation for arrays, strings, and other objects.

      -

      38.7.6.11 "varin" typemap

      +

      38.7.6.11 "varin" typemap

      The "varin" typemap is used to convert objects in the target language to C for the purposes of assigning to a C/C++ global variable. This is implementation specific.

      -

      38.7.6.12 "varout" typemap

      +

      38.7.6.12 "varout" typemap

      The "varout" typemap is used to convert a C/C++ object to an object in the target language when reading a C/C++ global variable. This is implementation specific.

      -

      38.7.6.13 "throws" typemap

      +

      38.7.6.13 "throws" typemap

      The "throws" typemap is only used when SWIG parses a C++ @@ -3044,7 +3044,7 @@ specification yet they do throw exceptions, SWIG cannot know how to deal with them. For a neat way to handle these, see the Exception handling with %exception section.

      -

      38.7.6.14 directorin typemap

      +

      38.7.6.14 directorin typemap

      Converts C++ objects in director @@ -3103,7 +3103,7 @@ referring to the class itself. -

      38.7.6.15 directorout typemap

      +

      38.7.6.15 directorout typemap

      Converts Ruby objects in director @@ -3176,7 +3176,7 @@ exception.

      -

      38.7.6.16 directorargout typemap

      +

      38.7.6.16 directorargout typemap

      Output argument processing in director @@ -3234,19 +3234,19 @@ referring to the instance of the class itself -

      38.7.6.17 ret typemap

      +

      38.7.6.17 ret typemap

      Cleanup of function return values

      -

      38.7.6.18 globalin typemap

      +

      38.7.6.18 globalin typemap

      Setting of C global variables

      -

      38.7.7 Typemap variables

      +

      38.7.7 Typemap variables

      @@ -3296,7 +3296,7 @@ so that their values can be properly assigned.

      The Ruby name of the wrapper function being created.
      -

      38.7.8 Useful Functions

      +

      38.7.8 Useful Functions

      When you write a typemap, you usually have to work directly @@ -3311,7 +3311,7 @@ stick to the swig functions instead of the native Ruby functions. That should help you avoid having to rewrite a lot of typemaps across multiple languages.

      -

      38.7.8.1 C Datatypes to Ruby Objects

      +

      38.7.8.1 C Datatypes to Ruby Objects

      @@ -3353,7 +3353,7 @@ SWIG_From_float(float)
      -

      38.7.8.2 Ruby Objects to C Datatypes

      +

      38.7.8.2 Ruby Objects to C Datatypes

      Here, while the Ruby versions return the value directly, the SWIG @@ -3421,7 +3421,7 @@ versions do not, but return a status value to indicate success (SWIG_OK -

      38.7.8.3 Macros for VALUE

      +

      38.7.8.3 Macros for VALUE

      RSTRING_LEN(str)

      @@ -3444,7 +3444,7 @@ versions do not, but return a status value to indicate success (SWIG_OK
      pointer to array storage
      -

      38.7.8.4 Exceptions

      +

      38.7.8.4 Exceptions

      void rb_raise(VALUE exception, const char *fmt, @@ -3523,7 +3523,7 @@ message to standard error if Ruby was invoked with the -w flag. The given format string fmt and remaining arguments are interpreted as with printf(). -

      38.7.8.5 Iterators

      +

      38.7.8.5 Iterators

      void rb_iter_break()

      @@ -3569,14 +3569,14 @@ VALUE), VALUE value)

      Equivalent to Ruby's throw.
      -

      38.7.9 Typemap Examples

      +

      38.7.9 Typemap Examples

      This section includes a few examples of typemaps. For more examples, you might look at the examples in the Example/ruby directory.

      -

      38.7.10 Converting a Ruby array to a char **

      +

      38.7.10 Converting a Ruby array to a char **

      A common problem in many C programs is the processing of @@ -3641,7 +3641,7 @@ array. Since dynamic memory allocation is used to allocate memory for the array, the "freearg" typemap is used to later release this memory after the execution of the C function.

      -

      38.7.11 Collecting arguments in a hash

      +

      38.7.11 Collecting arguments in a hash

      Ruby's solution to the "keyword arguments" capability of some @@ -3855,7 +3855,7 @@ memory leak. Fortunately, this typemap is a lot easier to write:

      program that uses the extension, can be found in the Examples/ruby/hashargs directory of the SWIG distribution.

      -

      38.7.12 Pointer handling

      +

      38.7.12 Pointer handling

      Occasionally, it might be necessary to convert pointer values @@ -3914,7 +3914,7 @@ For example:

      } -

      38.7.12.1 Ruby Datatype Wrapping

      +

      38.7.12.1 Ruby Datatype Wrapping

      VALUE Data_Wrap_Struct(VALUE class, void @@ -3941,7 +3941,7 @@ as above. type c-type from the data object obj and assigns that pointer to ptr. -

      38.7.13 Example: STL Vector to Ruby Array

      +

      38.7.13 Example: STL Vector to Ruby Array

      Another use for macros and type maps is to create a Ruby array @@ -4033,7 +4033,7 @@ STL with ruby, you are advised to use the standard swig STL library, which does much more than this. Refer to the section called the C++ Standard Template Library. -

      38.8 Docstring Features

      +

      38.8 Docstring Features

      @@ -4067,7 +4067,7 @@ generate ri documentation from a c wrap file, you could do:

      $ rdoc -r file_wrap.c -

      38.8.1 Module docstring

      +

      38.8.1 Module docstring

      @@ -4097,7 +4097,7 @@ layout of controls on a panel, etc. to be loaded from an XML file." %module(docstring=DOCSTRING) xrc -

      38.8.2 %feature("autodoc")

      +

      38.8.2 %feature("autodoc")

      Since SWIG does know everything about the function it wraps, @@ -4118,7 +4118,7 @@ several options for autodoc controlled by the value given to the feature, described below.

      -

      38.8.2.1 %feature("autodoc", "0")

      +

      38.8.2.1 %feature("autodoc", "0")

      @@ -4142,7 +4142,7 @@ Then Ruby code like this will be generated: ... -

      38.8.2.2 %feature("autodoc", "1")

      +

      38.8.2.2 %feature("autodoc", "1")

      @@ -4162,7 +4162,7 @@ this: ... -

      38.8.2.3 %feature("autodoc", "2")

      +

      38.8.2.3 %feature("autodoc", "2")

      @@ -4174,7 +4174,7 @@ parameter types with the "2" option will result in Ruby code like this:

      -

      38.8.2.4 %feature("autodoc", "3")

      +

      38.8.2.4 %feature("autodoc", "3")

      @@ -4195,7 +4195,7 @@ Parameters: bar - Bar -

      38.8.2.5 %feature("autodoc", "docstring")

      +

      38.8.2.5 %feature("autodoc", "docstring")

      @@ -4211,7 +4211,7 @@ generated string. For example: void GetPosition(int* OUTPUT, int* OUTPUT); -

      38.8.3 %feature("docstring")

      +

      38.8.3 %feature("docstring")

      @@ -4222,10 +4222,10 @@ docstring associated with classes, function or methods are output. If an item already has an autodoc string then it is combined with the docstring and they are output together.

      -

      38.9 Advanced Topics

      +

      38.9 Advanced Topics

      -

      38.9.1 Operator overloading

      +

      38.9.1 Operator overloading

      SWIG allows operator overloading with, by using the %extend @@ -4406,7 +4406,7 @@ separate method for handling inequality since Ruby parses the expression a != b as !(a == b).

      -

      38.9.2 Creating Multi-Module Packages

      +

      38.9.2 Creating Multi-Module Packages

      The chapter on Working @@ -4532,7 +4532,7 @@ irb(main):005:0> c.getX() 5.0 -

      38.9.3 Specifying Mixin Modules

      +

      38.9.3 Specifying Mixin Modules

      The Ruby language doesn't support multiple inheritance, but @@ -4599,7 +4599,7 @@ matching rules used for other kinds of features apply (see the chapter on "Customization Features") for more details).

      -

      38.10 Memory Management

      +

      38.10 Memory Management

      One of the most common issues in generating SWIG bindings for @@ -4622,7 +4622,7 @@ to C++ (or vice versa) depending on what function or methods are invoked. Clearly, developing a SWIG wrapper requires a thorough understanding of how the underlying library manages memory.

      -

      38.10.1 Mark and Sweep Garbage Collector

      +

      38.10.1 Mark and Sweep Garbage Collector

      Ruby uses a mark and sweep garbage collector. When the garbage @@ -4654,7 +4654,7 @@ any memory has been allocated in creating the underlying C struct or C++ struct, then a "free" function must be defined that deallocates this memory.

      -

      38.10.2 Object Ownership

      +

      38.10.2 Object Ownership

      As described above, memory management depends on clearly @@ -4799,7 +4799,7 @@ public:

      This code can be seen in swig/examples/ruby/tracking.

      -

      38.10.3 Object Tracking

      +

      38.10.3 Object Tracking

      The remaining parts of this section will use the class library @@ -5025,7 +5025,7 @@ However, if you implement your own free functions (see below) you may also have to call the SWIG_RubyRemoveTracking and RubyUnlinkObjects methods.

      -

      38.10.4 Mark Functions

      +

      38.10.4 Mark Functions

      With a bit more testing, we see that our class library still @@ -5154,7 +5154,7 @@ irb(main):016:0>

      This code can be seen in swig/examples/ruby/mark_function.

      -

      38.10.5 Free Functions

      +

      38.10.5 Free Functions

      By default, SWIG creates a "free" function that is called when @@ -5323,7 +5323,7 @@ been freed, and thus raises a runtime exception.

      This code can be seen in swig/examples/ruby/free_function.

      -

      38.10.6 Embedded Ruby and the C++ Stack

      +

      38.10.6 Embedded Ruby and the C++ Stack

      As has been said, the Ruby GC runs and marks objects before diff --git a/Doc/Manual/SWIG.html b/Doc/Manual/SWIG.html index 774e00b23..c31d8255f 100644 --- a/Doc/Manual/SWIG.html +++ b/Doc/Manual/SWIG.html @@ -6,7 +6,7 @@ -

      5 SWIG Basics

      +

      5 SWIG Basics

        @@ -94,7 +94,7 @@ Specific details about each target language are described in later chapters.

        -

        5.1 Running SWIG

        +

        5.1 Running SWIG

        @@ -156,7 +156,7 @@ can be obtained by typing swig -help or swig

      -

      5.1.1 Input format

      +

      5.1.1 Input format

      @@ -203,7 +203,7 @@ semantics in SWIG is analogous to that of the declarations section used in input files to parser generation tools such as yacc or bison.

      -

      5.1.2 SWIG Output

      +

      5.1.2 SWIG Output

      @@ -263,7 +263,7 @@ as the output directory for the language files is the same directory as the generated C/C++ file if not overridden with -outdir.

      -

      5.1.3 Comments

      +

      5.1.3 Comments

      @@ -273,7 +273,7 @@ documentation files. However, this feature is currently under repair and will reappear in a later SWIG release.

      -

      5.1.4 C Preprocessor

      +

      5.1.4 C Preprocessor

      @@ -297,7 +297,7 @@ make it more powerful than the normal C preprocessor. These extensions are described in the "Preprocessor" chapter.

      -

      5.1.5 SWIG Directives

      +

      5.1.5 SWIG Directives

      @@ -328,7 +328,7 @@ included in C header files using conditional compilation like this: it is parsing an input file.

      -

      5.1.6 Parser Limitations

      +

      5.1.6 Parser Limitations

      @@ -426,7 +426,7 @@ does not utilize a separate typedef-name terminal symbol as described on p. 234 of K&R).

      -

      5.2 Wrapping Simple C Declarations

      +

      5.2 Wrapping Simple C Declarations

      @@ -489,7 +489,7 @@ environments, and semantics, it is not always possible to do so. The next few sections describe various aspects of this mapping.

      -

      5.2.1 Basic Type Handling

      +

      5.2.1 Basic Type Handling

      @@ -614,7 +614,7 @@ will use the same internal representation (e.g., UCS-2 vs. UCS-4). You may need to write some special conversion functions.

      -

      5.2.2 Global Variables

      +

      5.2.2 Global Variables

      @@ -669,7 +669,7 @@ Earlier versions of SWIG incorrectly handled const and created constants instead.

      -

      5.2.3 Constants

      +

      5.2.3 Constants

      @@ -758,7 +758,7 @@ is only used when you want to add constants to the scripting language interface that are not defined in the original header file.

      -

      5.2.4 A brief word about const

      +

      5.2.4 A brief word about const

      @@ -860,7 +860,7 @@ const int spam = 42; -

      5.2.5 A cautionary tale of char *

      +

      5.2.5 A cautionary tale of char *

      @@ -899,7 +899,7 @@ input values. However, it must be noted that you could change the behavior of using typemaps.

      -

      5.3 Pointers and complex objects

      +

      5.3 Pointers and complex objects

      @@ -907,7 +907,7 @@ Most C programs manipulate arrays, structures, and other types of objects. This discusses the handling of these datatypes.

      -

      5.3.1 Simple pointers

      +

      5.3.1 Simple pointers

      @@ -973,7 +973,7 @@ simplified and less prone to error.

    -

    5.3.2 Run time pointer type checking

    +

    5.3.2 Run time pointer type checking

    @@ -995,7 +995,7 @@ as sentinel values or to denote a missing/empty value. Therefore, SWIG leaves NULL pointer checking up to the application.

    -

    5.3.3 Derived types, structs, and classes

    +

    5.3.3 Derived types, structs, and classes

    @@ -1052,7 +1052,7 @@ In this case f1, f2, and buffer are all opaque objects containing C pointers. It doesn't matter what value they contain--our program works just fine without this knowledge.

    -

    5.3.4 Undefined datatypes

    +

    5.3.4 Undefined datatypes

    @@ -1112,7 +1112,7 @@ The only way to fix this problem is to make sure you properly declare type names -

    5.3.5 Typedef

    +

    5.3.5 Typedef

    @@ -1201,7 +1201,7 @@ The corresponding wrapper function will accept arguments of type unsigned int * or size_t *.

    -

    5.4 Other Practicalities

    +

    5.4 Other Practicalities

    @@ -1211,7 +1211,7 @@ more difficult to map to a scripting language interface. This section describes some of these issues.

    -

    5.4.1 Passing structures by value

    +

    5.4.1 Passing structures by value

    @@ -1242,7 +1242,7 @@ to Vectors instead of Vectors. For the most part, this transformation is transparent so you might not notice.

    -

    5.4.2 Return by value

    +

    5.4.2 Return by value

    @@ -1297,7 +1297,7 @@ don't work correctly if Vector doesn't define a default constructor. The section on SWIG and C++ has more information about this case.

    -

    5.4.3 Linking to structure variables

    +

    5.4.3 Linking to structure variables

    @@ -1329,7 +1329,7 @@ C++ classes must supply a properly defined copy constructor in order for assignment to work correctly.

    -

    5.4.4 Linking to char *

    +

    5.4.4 Linking to char *

    @@ -1458,7 +1458,7 @@ value is not released. -

    5.4.5 Arrays

    +

    5.4.5 Arrays

    @@ -1594,7 +1594,7 @@ void pathname_set(char *value) { In the target language, the value can be set like a normal variable.

    -

    5.4.6 Creating read-only variables

    +

    5.4.6 Creating read-only variables

    @@ -1668,10 +1668,10 @@ generate a warning message. Simply change the directives to %immutable;%mutable; to silence the warning. Don't forget the extra semicolon!

    -

    5.4.7 Renaming and ignoring declarations

    +

    5.4.7 Renaming and ignoring declarations

    -

    5.4.7.1 Simple renaming of specific identifiers

    +

    5.4.7.1 Simple renaming of specific identifiers

    @@ -1769,7 +1769,7 @@ This directive is still supported, but it is deprecated and should probably be a directive is more powerful and better supports wrapping of raw header file information.

    -

    5.4.7.2 Advanced renaming support

    +

    5.4.7.2 Advanced renaming support

    @@ -1971,7 +1971,7 @@ are exactly equivalent and %rename can be used to selectively ignore multiple declarations using the previously described matching possibilities.

    -

    5.4.7.3 Limiting global renaming rules

    +

    5.4.7.3 Limiting global renaming rules

    @@ -2069,7 +2069,7 @@ wrap C++ overloaded functions and methods or C++ methods which use default argum

    -

    5.4.7.4 Ignoring everything then wrapping a few selected symbols

    +

    5.4.7.4 Ignoring everything then wrapping a few selected symbols

    @@ -2111,7 +2111,7 @@ members of the class, so when the chosen class is unignored, all of its methods -

    5.4.8 Default/optional arguments

    +

    5.4.8 Default/optional arguments

    @@ -2148,7 +2148,7 @@ Please refer to the section on def in the C++ chapter for further details.

    -

    5.4.9 Pointers to functions and callbacks

    +

    5.4.9 Pointers to functions and callbacks

    @@ -2301,7 +2301,7 @@ See the Typemaps chapter for more about typ and individual target language chapters for more on callbacks and the 'director' feature.

    -

    5.5 Structures and unions

    +

    5.5 Structures and unions

    @@ -2383,7 +2383,7 @@ delete_Vector(v) However, most of SWIG's language modules also provide a high-level interface that is more convenient. Keep reading.

    -

    5.5.1 Typedef and structures

    +

    5.5.1 Typedef and structures

    @@ -2429,7 +2429,7 @@ vector_struct, SWIG knows that this is the same as Vector and it generates the appropriate type-checking code.

    -

    5.5.2 Character strings and structures

    +

    5.5.2 Character strings and structures

    @@ -2476,7 +2476,7 @@ Note: If the -c++ option is used, new and delete are perform memory allocation.

    -

    5.5.3 Array members

    +

    5.5.3 Array members

    @@ -2498,7 +2498,7 @@ discussed in a later chapter. In many cases, the warning message is harmless.

    -

    5.5.4 Structure data members

    +

    5.5.4 Structure data members

    @@ -2604,7 +2604,7 @@ class, or union. This is unlikely to break existing code. However, if you need datatype is really a struct, simply use a forward struct declaration such as "struct Foo;".

    -

    5.5.5 C constructors and destructors

    +

    5.5.5 C constructors and destructors

    @@ -2693,7 +2693,7 @@ the target languages, and it is highly recommended you don't use them.

    -

    5.5.6 Adding member functions to C structures

    +

    5.5.6 Adding member functions to C structures

    @@ -2966,7 +2966,7 @@ be used to extend a structure with more than just methods, a more suitable directive name has been chosen.

    -

    5.5.7 Nested structures

    +

    5.5.7 Nested structures

    @@ -3050,7 +3050,7 @@ Finally, note that nesting is handled differently in C++ mode, see Nested classes.

    -

    5.5.8 Other things to note about structure wrapping

    +

    5.5.8 Other things to note about structure wrapping

    @@ -3112,7 +3112,7 @@ interface described here, most of SWIG's language modules use it in some way or another.

    -

    5.6 Code Insertion

    +

    5.6 Code Insertion

    @@ -3122,7 +3122,7 @@ additional C code to perform initialization or other operations. There are four common ways to insert code, but it's useful to know how the output of SWIG is structured first.

    -

    5.6.1 The output of SWIG

    +

    5.6.1 The output of SWIG

    @@ -3158,7 +3158,7 @@ the module upon loading. -

    5.6.2 Code insertion blocks

    +

    5.6.2 Code insertion blocks

    @@ -3236,7 +3236,7 @@ static Vector *new_Vector() { Vector *new_Vector(); -

    5.6.3 Inlined code blocks

    +

    5.6.3 Inlined code blocks

    @@ -3263,7 +3263,7 @@ declaration. Since the code inside an %inline %{ ... %} block is given to both the C compiler and SWIG, it is illegal to include any SWIG directives inside a %{ ... %} block.

    -

    5.6.4 Initialization blocks

    +

    5.6.4 Initialization blocks

    @@ -3278,7 +3278,7 @@ initialization on module loading, you could write this: %} -

    5.7 An Interface Building Strategy

    +

    5.7 An Interface Building Strategy

    @@ -3286,7 +3286,7 @@ This section describes the general approach for building interfaces with SWIG. The specifics related to a particular scripting language are found in later chapters.

    -

    5.7.1 Preparing a C program for SWIG

    +

    5.7.1 Preparing a C program for SWIG

    @@ -3340,7 +3340,7 @@ to the swig-devel mailing list or to SWIG bug tracker.

    -

    5.7.2 The SWIG interface file

    +

    5.7.2 The SWIG interface file

    @@ -3393,7 +3393,7 @@ The main advantage of this approach is minimal maintenance of an interface file In more complex projects, an interface file containing numerous %include and #include statements like this is one of the most common approaches to interface file design due to lower maintenance overhead.

    -

    5.7.3 Why use separate interface files?

    +

    5.7.3 Why use separate interface files?

    @@ -3422,7 +3422,7 @@ and immediately see what is available without having to dig it out of header files. -

    5.7.4 Getting the right header files

    +

    5.7.4 Getting the right header files

    @@ -3442,7 +3442,7 @@ include certain header files by using a %{,%} block like this: ... -

    5.7.5 What to do with main()

    +

    5.7.5 What to do with main()

    diff --git a/Doc/Manual/SWIGPlus.html b/Doc/Manual/SWIGPlus.html index d138073d9..1127a8ee8 100644 --- a/Doc/Manual/SWIGPlus.html +++ b/Doc/Manual/SWIGPlus.html @@ -6,7 +6,7 @@ -

    6 SWIG and C++

    +

    6 SWIG and C++

      @@ -75,7 +75,7 @@ how SWIG wraps ANSI C. Support for C++ builds upon ANSI C wrapping and that material will be useful in understanding this chapter.

      -

      6.1 Comments on C++ Wrapping

      +

      6.1 Comments on C++ Wrapping

      @@ -117,7 +117,7 @@ crossing language boundaries and provides many opportunities to shoot yourself in the foot. You will just have to be careful.

      -

      6.2 Approach

      +

      6.2 Approach

      @@ -158,7 +158,7 @@ proxy classes. More detailed coverage can be found in the documentation for each target language.

      -

      6.3 Supported C++ features

      +

      6.3 Supported C++ features

      @@ -197,7 +197,7 @@ in future releases. However, we make no promises. Also, submitting a bug repor good way to get problems fixed (wink).

      -

      6.4 Command line options and compilation

      +

      6.4 Command line options and compilation

      @@ -231,7 +231,7 @@ details. The SWIG Wiki also has further details. The -noproxy commandline option is recognised by many target languages and will generate just this interface as in earlier versions. -

      6.5 Proxy classes

      +

      6.5 Proxy classes

      @@ -243,7 +243,7 @@ wrapped by a Python proxy class. Or if you're building a Java module, each C++ class is wrapped by a Java proxy class.

      -

      6.5.1 Construction of proxy classes

      +

      6.5.1 Construction of proxy classes

      @@ -325,7 +325,7 @@ Whenever possible, proxies try to take advantage of language features that are s might include operator overloading, exception handling, and other features.

      -

      6.5.2 Resource management in proxies

      +

      6.5.2 Resource management in proxies

      @@ -479,7 +479,7 @@ every possible memory management problem. However, proxies do provide a mechani can be used (if necessary) to address some of the more tricky memory management problems.

      -

      6.5.3 Language specific details

      +

      6.5.3 Language specific details

      @@ -487,7 +487,7 @@ Language specific details on proxy classes are contained in the chapters describ chapter has merely introduced the topic in a very general way.

      -

      6.6 Simple C++ wrapping

      +

      6.6 Simple C++ wrapping

      @@ -520,7 +520,7 @@ To generate wrappers for this class, SWIG first reduces the class to a collectio accessor functions which are then used by the proxy classes.

      -

      6.6.1 Constructors and destructors

      +

      6.6.1 Constructors and destructors

      @@ -537,7 +537,7 @@ void delete_List(List *l) {

    -

    6.6.2 Default constructors, copy constructors and implicit destructors

    +

    6.6.2 Default constructors, copy constructors and implicit destructors

    @@ -686,7 +686,7 @@ leaks, and so it is strongly recommended to not use them.

    -

    6.6.3 When constructor wrappers aren't created

    +

    6.6.3 When constructor wrappers aren't created

    @@ -763,7 +763,7 @@ public: More information about %feature can be found in the Customization features chapter.

    -

    6.6.4 Copy constructors

    +

    6.6.4 Copy constructors

    @@ -865,7 +865,7 @@ constructor is set to new_CopyFoo(). This is the same as in older versions.

    -

    6.6.5 Member functions

    +

    6.6.5 Member functions

    @@ -891,7 +891,7 @@ wrapper functions. However, the name and calling convention of the low-level procedural wrappers match the accessor function prototype described above.

    -

    6.6.6 Static members

    +

    6.6.6 Static members

    @@ -901,7 +901,7 @@ transformations. For example, the static member function in the generated wrapper code.

    -

    6.6.7 Member data

    +

    6.6.7 Member data

    @@ -1093,7 +1093,7 @@ a few problems related to structure wrapping and some of SWIG's customization features.

    -

    6.7 Default arguments

    +

    6.7 Default arguments

    @@ -1199,7 +1199,7 @@ Keyword arguments are a language feature of some scripting languages, for exampl SWIG is unable to support kwargs when wrapping overloaded methods, so the default approach cannot be used.

    -

    6.8 Protection

    +

    6.8 Protection

    @@ -1219,7 +1219,7 @@ until you explicitly give a `public:' declaration (This is the same convention used by C++).

    -

    6.9 Enums and constants

    +

    6.9 Enums and constants

    @@ -1249,7 +1249,7 @@ Swig_STOUT = Swig::STOUT Members declared as const are wrapped as read-only members and do not create constants.

    -

    6.10 Friends

    +

    6.10 Friends

    @@ -1310,7 +1310,7 @@ namespace bar { and a wrapper for the method 'blah' will not be generated.

    -

    6.11 References and pointers

    +

    6.11 References and pointers

    @@ -1410,7 +1410,7 @@ templates and the STL. This was first added in SWIG-1.3.12.

    -

    6.12 Pass and return by value

    +

    6.12 Pass and return by value

    @@ -1514,7 +1514,7 @@ classes that don't define a default constructor. It is not used for C++ pointers or references.

    -

    6.13 Inheritance

    +

    6.13 Inheritance

    @@ -1700,7 +1700,7 @@ functions for virtual members that are already defined in a base class.

    -

    6.14 A brief discussion of multiple inheritance, pointers, and type checking

    +

    6.14 A brief discussion of multiple inheritance, pointers, and type checking

    @@ -1832,7 +1832,7 @@ int y = B_function((B *) pB); In practice, the pointer is held as an integral number in the target language proxy class.

    -

    6.15 Wrapping Overloaded Functions and Methods

    +

    6.15 Wrapping Overloaded Functions and Methods

    @@ -1895,7 +1895,7 @@ it might be used like this -

    6.15.1 Dispatch function generation

    +

    6.15.1 Dispatch function generation

    @@ -2020,7 +2020,7 @@ checked in the same order as they appear in this ranking. If you're still confused, don't worry about it---SWIG is probably doing the right thing.

    -

    6.15.2 Ambiguity in Overloading

    +

    6.15.2 Ambiguity in Overloading

    @@ -2138,7 +2138,7 @@ it means that the target language module has not yet implemented support for ove functions and methods. The only way to fix the problem is to read the next section.

    -

    6.15.3 Ambiguity resolution and renaming

    +

    6.15.3 Ambiguity resolution and renaming

    @@ -2567,7 +2567,7 @@ to wrapping methods with default arguments was introduced. -

    6.15.4 Comments on overloading

    +

    6.15.4 Comments on overloading

    @@ -2584,7 +2584,7 @@ As a general rule, statically typed languages like Java are able to provide more than dynamically typed languages like Perl, Python, Ruby, and Tcl.

    -

    6.16 Wrapping overloaded operators

    +

    6.16 Wrapping overloaded operators

    @@ -2768,7 +2768,7 @@ are ignored as well as conversion operators. -

    6.17 Class extension

    +

    6.17 Class extension

    @@ -2867,7 +2867,7 @@ be used to extend a structure with more than just methods, a more suitable directive name has been chosen.

    -

    6.18 Templates

    +

    6.18 Templates

    @@ -3701,7 +3701,7 @@ as the class name. For example: Similar changes apply to typemaps and other customization features.

    -

    6.19 Namespaces

    +

    6.19 Namespaces

    @@ -4150,7 +4150,7 @@ with any namespace awareness. In the future, language modules may or may not p more advanced namespace support.

    -

    6.19.1 The nspace feature for namespaces

    +

    6.19.1 The nspace feature for namespaces

    @@ -4231,7 +4231,7 @@ namespace MyWorld { Compatibility Note: The nspace feature was first introduced in SWIG-2.0.0.

    -

    6.20 Renaming templated types in namespaces

    +

    6.20 Renaming templated types in namespaces

    @@ -4309,7 +4309,7 @@ namespace Space { -

    6.21 Exception specifications

    +

    6.21 Exception specifications

    @@ -4360,7 +4360,7 @@ Consult the "Exception hand The next section details a way of simulating an exception specification or replacing an existing one.

    -

    6.22 Exception handling with %catches

    +

    6.22 Exception handling with %catches

    @@ -4410,7 +4410,7 @@ just a single catch handler for the base class, EBase will be generated

    -

    6.23 Pointers to Members

    +

    6.23 Pointers to Members

    @@ -4460,7 +4460,7 @@ when checking types. However, no such support is currently provided for member pointers.

    -

    6.24 Smart pointers and operator->()

    +

    6.24 Smart pointers and operator->()

    @@ -4672,7 +4672,7 @@ p = f.__deref__() # Raw pointer from operator-> Note: Smart pointer support was first added in SWIG-1.3.14.

    -

    6.25 C++ reference counted objects - ref/unref feature

    +

    6.25 C++ reference counted objects - ref/unref feature

    @@ -4844,7 +4844,7 @@ exit # 'a' is released, SWIG unref 'a' called in the destructor wra -

    6.26 Using declarations and inheritance

    +

    6.26 Using declarations and inheritance

    @@ -5007,7 +5007,7 @@ public: -

    6.27 Nested classes

    +

    6.27 Nested classes

    @@ -5071,7 +5071,7 @@ Nested class warnings could also not be suppressed using %warnfilter.

    -

    6.28 A brief rant about const-correctness

    +

    6.28 A brief rant about const-correctness

    @@ -5129,7 +5129,7 @@ using another tool if maintaining constness is the most important part of your project.

    -

    6.29 Where to go for more information

    +

    6.29 Where to go for more information

    diff --git a/Doc/Manual/Scilab.html b/Doc/Manual/Scilab.html index 5a894d587..1f5876270 100644 --- a/Doc/Manual/Scilab.html +++ b/Doc/Manual/Scilab.html @@ -8,7 +8,7 @@ -

    39 SWIG and Scilab

    +

    39 SWIG and Scilab

      @@ -87,7 +87,7 @@ This chapter explains how to use SWIG for Scilab. After this introduction, you s

      -

      39.1 Preliminaries

      +

      39.1 Preliminaries

      @@ -104,7 +104,7 @@ SWIG for Scilab supports C language. C++ is partially supported. See 39.2 Running SWIG +

      39.2 Running SWIG

      @@ -138,7 +138,7 @@ Note: a code in an %inline section is both parsed and wrapped by SWIG,

      -

      39.2.1 Generating the module

      +

      39.2.1 Generating the module

      @@ -181,7 +181,7 @@ The swig executable has several other command line options you can use.

      -

      39.2.2 Building the module

      +

      39.2.2 Building the module

      @@ -201,7 +201,7 @@ $ gcc -shared example_wrap.o -o libexample.so Note: we supposed in this example that the path to the Scilab include directory is /usr/local/include/scilab (which is the case in a Debian environment), this should be changed for another environment.

      -

      39.2.3 Loading the module

      +

      39.2.3 Loading the module

      @@ -225,7 +225,7 @@ Link done. which means that Scilab has successfully loaded the shared library. The module functions and other symbols are now available in Scilab.

      -

      39.2.4 Using the module

      +

      39.2.4 Using the module

      @@ -259,7 +259,7 @@ ans = Note: for conciseness, we assume in the subsequent Scilab code examples that the modules have been beforehand built and loaded in Scilab.

      -

      39.2.5 Scilab command line options

      +

      39.2.5 Scilab command line options

      @@ -314,10 +314,10 @@ $ swig -scilab -help

    -

    39.3 A basic tour of C/C++ wrapping

    +

    39.3 A basic tour of C/C++ wrapping

    -

    39.3.1 Overview

    +

    39.3.1 Overview

    @@ -326,7 +326,7 @@ This means that functions, structs, classes, variables, etc... are interfaced th There are a few exceptions, such as constants and enumerations, which can be wrapped directly as Scilab variables.

    -

    39.3.2 Identifiers

    +

    39.3.2 Identifiers

    @@ -337,7 +337,7 @@ In Scilab 5.x, identifier names are composed of 24 characters maximum (this limi In these cases, the %rename directive can be used to choose a different Scilab name.

    -

    39.3.3 Functions

    +

    39.3.3 Functions

    @@ -368,7 +368,7 @@ ans = 24. -

    39.3.3.1 Argument passing

    +

    39.3.3.1 Argument passing

    @@ -421,7 +421,7 @@ In Scilab, parameters are passed by value. The output (and inout) parameters are 7. -

    39.3.3.2 Multiple output arguments

    +

    39.3.3.2 Multiple output arguments

    @@ -469,7 +469,7 @@ int divide(int n, int d, int q*, int *r) { -

    39.3.4 Global variables

    +

    39.3.4 Global variables

    @@ -538,10 +538,10 @@ It works the same:

    -

    39.3.5 Constants and enumerations

    +

    39.3.5 Constants and enumerations

    -

    39.3.5.1 Constants

    +

    39.3.5.1 Constants

    @@ -682,7 +682,7 @@ are mapped to Scilab variables, with the same name: 3.14 -

    39.3.5.2 Enumerations

    +

    39.3.5.2 Enumerations

    @@ -747,7 +747,7 @@ typedef enum { RED, BLUE, GREEN } color; -

    39.3.6 Pointers

    +

    39.3.6 Pointers

    @@ -789,7 +789,7 @@ These functions can be used in a natural way from Scilab: The user of a pointer is responsible for freeing it or, like in the example, closing any resources associated with it (just as is required in a C program).

    -

    39.3.6.1 Utility functions

    +

    39.3.6.1 Utility functions

    @@ -820,7 +820,7 @@ SWIG comes with two pointer utility functions: --> fclose(f); -

    39.3.6.2 Null pointers

    +

    39.3.6.2 Null pointers

    By default, Scilab does not provide a way to test or create null pointers. @@ -836,7 +836,7 @@ But it is possible to have a null pointer by using the previous functions SW -

    39.3.7 Structures

    +

    39.3.7 Structures

    @@ -931,7 +931,7 @@ ans = -

    39.3.8 C++ classes

    +

    39.3.8 C++ classes

    @@ -981,7 +981,7 @@ ans = --> delete_Point(p2); -

    39.3.9 C++ inheritance

    +

    39.3.9 C++ inheritance

    @@ -1056,7 +1056,7 @@ But we can use either use the get_perimeter() function of the parent cl 18.84 -

    39.3.10 Pointers, references, values, and arrays

    +

    39.3.10 Pointers, references, values, and arrays

    @@ -1114,7 +1114,7 @@ All these functions will return a pointer to an instance of Foo. As the function spam7 returns a value, new instance of Foo has to be allocated, and a pointer on this instance is returned.

    -

    39.3.11 C++ templates

    +

    39.3.11 C++ templates

    @@ -1174,7 +1174,7 @@ Then in Scilab: More details on template support can be found in the templates documentation.

    -

    39.3.12 C++ operators

    +

    39.3.12 C++ operators

    @@ -1227,7 +1227,7 @@ private: -

    39.3.13 C++ namespaces

    +

    39.3.13 C++ namespaces

    @@ -1305,7 +1305,7 @@ Note: the nspace feature is

    -

    39.3.14 C++ exceptions

    +

    39.3.14 C++ exceptions

    @@ -1388,17 +1388,17 @@ More complex or custom exception types require specific exception typemaps to be See the SWIG C++ documentation for more details.

    -

    39.3.15 C++ STL

    +

    39.3.15 C++ STL

    The Standard Template Library (STL) is partially supported. See STL for more details.

    -

    39.4 Type mappings and libraries

    +

    39.4 Type mappings and libraries

    -

    39.4.1 Default primitive type mappings

    +

    39.4.1 Default primitive type mappings

    @@ -1447,7 +1447,7 @@ The default behaviour is for SWIG to generate code that will give a runtime erro -

    39.4.2 Default type mappings for non-primitive types

    +

    39.4.2 Default type mappings for non-primitive types

    @@ -1455,7 +1455,7 @@ The default mapped type for C/C++ non-primitive types is the Scilab pointer, for

    -

    39.4.3 Arrays

    +

    39.4.3 Arrays

    @@ -1510,7 +1510,7 @@ void printArray(int values[], int len) { [ 0 1 2 3 ] -

    39.4.4 Pointer-to-pointers

    +

    39.4.4 Pointer-to-pointers

    @@ -1583,7 +1583,7 @@ void print_matrix(double **M, int nbRows, int nbCols) { -

    39.4.5 Matrices

    +

    39.4.5 Matrices

    @@ -1676,7 +1676,7 @@ The remarks made earlier for arrays also apply here:

  • There is no control while converting double values to integers, double values are truncated without any checking or warning.
    • -

    39.4.6 STL

    +

    39.4.6 STL

    @@ -1876,7 +1876,7 @@ ans = --> delete_PersonPtrSet(p); -

    39.5 Module initialization

    +

    39.5 Module initialization

    @@ -1900,7 +1900,7 @@ For example, to initialize the module example: --> example_Init(); -

    39.6 Building modes

    +

    39.6 Building modes

    @@ -1915,7 +1915,7 @@ To produce a dynamic module, when generating the wrapper, there are two possibil

  • the builder mode. In this mode, Scilab is responsible of building. -

    39.6.1 No-builder mode

    +

    39.6.1 No-builder mode

    @@ -1928,7 +1928,7 @@ This mode is the best option to use when you have to integrate the module build

    -

    39.6.2 Builder mode

    +

    39.6.2 Builder mode

    @@ -1968,14 +1968,14 @@ The command is: $ swig -scilab -builder -buildercflags -I/opt/foo/include -builderldflags "-L/opt/foo/lib -lfoo" -buildersources baa1.cxx,baa2.cxx example.i -

    39.7 Generated scripts

    +

    39.7 Generated scripts

    In this part we give some details about the generated Scilab scripts.

    -

    39.7.1 Builder script

    +

    39.7.1 Builder script

    @@ -2000,7 +2000,7 @@ ilib_build(ilib_name,table,files,libs);

  • table: two column string matrix containing a table of pairs of 'scilab function name', 'C function name'.
    • -

    39.7.2 Loader script

    +

    39.7.2 Loader script

    @@ -2039,7 +2039,7 @@ clear get_file_path; -

    39.8 Other resources

    +

    39.8 Other resources

      diff --git a/Doc/Manual/Scripting.html b/Doc/Manual/Scripting.html index c714fa0d7..9e5e85e7d 100644 --- a/Doc/Manual/Scripting.html +++ b/Doc/Manual/Scripting.html @@ -6,7 +6,7 @@ -

      4 Scripting Languages

      +

      4 Scripting Languages

        @@ -37,7 +37,7 @@ programming and the mechanisms by which scripting language interpreters access C and C++ code.

        -

        4.1 The two language view of the world

        +

        4.1 The two language view of the world

        @@ -68,7 +68,7 @@ languages can be used for rapid prototyping, interactive debugging, scripting, and access to high-level data structures such associative arrays.

        -

        4.2 How does a scripting language talk to C?

        +

        4.2 How does a scripting language talk to C?

        @@ -93,7 +93,7 @@ function, arguments, and so forth. The next few sections illustrate the process.

        -

        4.2.1 Wrapper functions

        +

        4.2.1 Wrapper functions

        @@ -165,7 +165,7 @@ Python. Both require special wrappers to be written and both need additional initialization code. Only the specific details are different.

        -

        4.2.2 Variable linking

        +

        4.2.2 Variable linking

        @@ -201,7 +201,7 @@ typing $Foo = 4 would call the underlying set function to change the value.

        -

        4.2.3 Constants

        +

        4.2.3 Constants

        @@ -222,7 +222,7 @@ functions for creating variables so installing constants is usually a trivial exercise.

        -

        4.2.4 Structures and classes

        +

        4.2.4 Structures and classes

        @@ -283,7 +283,7 @@ internals of an object, the interpreter does not need to know anything about the actual representation of a Vector.

        -

        4.2.5 Proxy classes

        +

        4.2.5 Proxy classes

        @@ -345,7 +345,7 @@ affect both objects equally and for all practical purposes, it appears as if you are simply manipulating a C/C++ object.

        -

        4.3 Building scripting language extensions

        +

        4.3 Building scripting language extensions

        @@ -358,7 +358,7 @@ recompile the scripting language interpreter with your extensions added to it.

        -

        4.3.1 Shared libraries and dynamic loading

        +

        4.3.1 Shared libraries and dynamic loading

        @@ -400,7 +400,7 @@ changing the link line to the following :

        c++ -shared example.o example_wrap.o -o example.so
      -

      4.3.2 Linking with shared libraries

      +

      4.3.2 Linking with shared libraries

      @@ -447,7 +447,7 @@ the path using linker options instead.

    -

    4.3.3 Static linking

    +

    4.3.3 Static linking

    diff --git a/Doc/Manual/Tcl.html b/Doc/Manual/Tcl.html index 874a5325a..a3e6ae99a 100644 --- a/Doc/Manual/Tcl.html +++ b/Doc/Manual/Tcl.html @@ -6,7 +6,7 @@ -

    40 SWIG and Tcl

    +

    40 SWIG and Tcl

      @@ -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.

      -

      40.1 Preliminaries

      +

      40.1 Preliminaries

      @@ -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.

      -

      40.1.1 Getting the right header files

      +

      40.1.1 Getting the right header files

      @@ -127,7 +127,7 @@ this is the case, you should probably make a symbolic link so that tcl.h -

      40.1.2 Compiling a dynamic module

      +

      40.1.2 Compiling a dynamic module

      @@ -163,7 +163,7 @@ The name of the module is specified using the %module directive or the -module command line option.

      -

      40.1.3 Static linking

      +

      40.1.3 Static linking

      @@ -229,7 +229,7 @@ minimal in most situations (and quite frankly not worth the extra hassle in the opinion of this author).

      -

      40.1.4 Using your module

      +

      40.1.4 Using your module

      @@ -357,7 +357,7 @@ to the default system configuration (this requires root access and you will need the man pages).

      -

      40.1.5 Compilation of C++ extensions

      +

      40.1.5 Compilation of C++ extensions

      @@ -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.

      -

      40.1.6 Compiling for 64-bit platforms

      +

      40.1.6 Compiling for 64-bit platforms

      @@ -467,7 +467,7 @@ also introduce problems on platforms that support more than one linking standard (e.g., -o32 and -n32 on Irix).

      -

      40.1.7 Setting a package prefix

      +

      40.1.7 Setting a package prefix

      @@ -486,7 +486,7 @@ option will append the prefix to the name when creating a command and call it "Foo_bar".

      -

      40.1.8 Using namespaces

      +

      40.1.8 Using namespaces

      @@ -508,7 +508,7 @@ When the -namespace option is used, objects in the module are always accessed with the namespace name such as Foo::bar.

      -

      40.2 Building Tcl/Tk Extensions under Windows 95/NT

      +

      40.2 Building Tcl/Tk Extensions under Windows 95/NT

      @@ -519,7 +519,7 @@ covers the process of using SWIG with Microsoft Visual C++. although the procedure may be similar with other compilers.

      -

      40.2.1 Running SWIG from Developer Studio

      +

      40.2.1 Running SWIG from Developer Studio

      @@ -577,7 +577,7 @@ MSDOS > tclsh80 %

    -

    40.2.2 Using NMAKE

    +

    40.2.2 Using NMAKE

    @@ -640,7 +640,7 @@ to get you started. With a little practice, you'll be making lots of Tcl extensions.

    -

    40.3 A tour of basic C/C++ wrapping

    +

    40.3 A tour of basic C/C++ wrapping

    @@ -651,7 +651,7 @@ classes. This section briefly covers the essential aspects of this wrapping.

    -

    40.3.1 Modules

    +

    40.3.1 Modules

    @@ -685,7 +685,7 @@ To fix this, supply an extra argument to load like this: -

    40.3.2 Functions

    +

    40.3.2 Functions

    @@ -710,7 +710,7 @@ like you think it does: % -

    40.3.3 Global variables

    +

    40.3.3 Global variables

    @@ -790,7 +790,7 @@ extern char *path; // Read-only (due to %immutable) -

    40.3.4 Constants and enums

    +

    40.3.4 Constants and enums

    @@ -874,7 +874,7 @@ When an identifier name is given, it is used to perform an implicit hash-table l conversion. This allows the global statement to be omitted.

    -

    40.3.5 Pointers

    +

    40.3.5 Pointers

    @@ -970,7 +970,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return None if the conversion can't be performed.

    -

    40.3.6 Structures

    +

    40.3.6 Structures

    @@ -1252,7 +1252,7 @@ Note: Tcl only destroys the underlying object if it has ownership. See the memory management section that appears shortly.

    -

    40.3.7 C++ classes

    +

    40.3.7 C++ classes

    @@ -1319,7 +1319,7 @@ In Tcl, the static member is accessed as follows: -

    40.3.8 C++ inheritance

    +

    40.3.8 C++ inheritance

    @@ -1368,7 +1368,7 @@ For instance: It is safe to use multiple inheritance with SWIG.

    -

    40.3.9 Pointers, references, values, and arrays

    +

    40.3.9 Pointers, references, values, and arrays

    @@ -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).

    -

    40.3.10 C++ overloaded functions

    +

    40.3.10 C++ overloaded functions

    @@ -1545,7 +1545,7 @@ first declaration takes precedence. Please refer to the "SWIG and C++" chapter for more information about overloading.

    -

    40.3.11 C++ operators

    +

    40.3.11 C++ operators

    @@ -1647,7 +1647,7 @@ There are ways to make this operator appear as part of the class using the % Keep reading.

    -

    40.3.12 C++ namespaces

    +

    40.3.12 C++ namespaces

    @@ -1711,7 +1711,7 @@ utilizes thousands of small deeply nested namespaces each with identical symbol names, well, then you get what you deserve.

    -

    40.3.13 C++ templates

    +

    40.3.13 C++ templates

    @@ -1763,7 +1763,7 @@ More details can be found in the SWIG and C++ -

    40.3.14 C++ Smart Pointers

    +

    40.3.14 C++ Smart Pointers

    @@ -1847,7 +1847,7 @@ simply use the __deref__() method. For example: -

    40.4 Further details on the Tcl class interface

    +

    40.4 Further details on the Tcl class interface

    @@ -1860,7 +1860,7 @@ of low-level details were omitted. This section provides a brief overview of how the proxy classes work.

    -

    40.4.1 Proxy classes

    +

    40.4.1 Proxy classes

    @@ -1925,7 +1925,7 @@ function. This allows objects to be encapsulated objects that look a lot like as shown in the last section.

    -

    40.4.2 Memory management

    +

    40.4.2 Memory management

    @@ -2113,7 +2113,7 @@ typemaps--an advanced topic discussed later.

    -

    40.5 Input and output parameters

    +

    40.5 Input and output parameters

    @@ -2301,7 +2301,7 @@ set c [lindex $dim 1] -

    40.6 Exception handling

    +

    40.6 Exception handling

    @@ -2435,7 +2435,7 @@ Since SWIG's exception handling is user-definable, you are not limited to C++ ex See the chapter on "Customization Features" for more examples.

    -

    40.7 Typemaps

    +

    40.7 Typemaps

    @@ -2452,7 +2452,7 @@ Typemaps are only used if you want to change some aspect of the primitive C-Tcl interface.

    -

    40.7.1 What is a typemap?

    +

    40.7.1 What is a typemap?

    @@ -2569,7 +2569,7 @@ parameter is omitted): -

    40.7.2 Tcl typemaps

    +

    40.7.2 Tcl typemaps

    @@ -2707,7 +2707,7 @@ Initialize an argument to a value before any conversions occur. Examples of these methods will appear shortly.

    -

    40.7.3 Typemap variables

    +

    40.7.3 Typemap variables

    @@ -2778,7 +2778,7 @@ properly assigned. The Tcl name of the wrapper function being created. -

    40.7.4 Converting a Tcl list to a char **

    +

    40.7.4 Converting a Tcl list to a char **

    @@ -2840,7 +2840,7 @@ argv[2] = Larry 3 -

    40.7.5 Returning values in arguments

    +

    40.7.5 Returning values in arguments

    @@ -2882,7 +2882,7 @@ result, a Tcl function using these typemaps will work like this : % -

    40.7.6 Useful functions

    +

    40.7.6 Useful functions

    @@ -2958,7 +2958,7 @@ int Tcl_IsShared(Tcl_Obj *obj); -

    40.7.7 Standard typemaps

    +

    40.7.7 Standard typemaps

    @@ -3043,7 +3043,7 @@ work) -

    40.7.8 Pointer handling

    +

    40.7.8 Pointer handling

    @@ -3119,7 +3119,7 @@ For example: -

    40.8 Turning a SWIG module into a Tcl Package.

    +

    40.8 Turning a SWIG module into a Tcl Package.

    @@ -3191,7 +3191,7 @@ As a final note, most SWIG examples do not yet use the to use the load command instead.

    -

    40.9 Building new kinds of Tcl interfaces (in Tcl)

    +

    40.9 Building new kinds of Tcl interfaces (in Tcl)

    @@ -3290,7 +3290,7 @@ danger of blowing something up (although it is easily accomplished with an out of bounds array access).

    -

    40.9.1 Proxy classes

    +

    40.9.1 Proxy classes

    @@ -3411,7 +3411,7 @@ short, but clever Tcl script can be combined with SWIG to do many interesting things.

    -

    40.10 Tcl/Tk Stubs

    +

    40.10 Tcl/Tk Stubs

    diff --git a/Doc/Manual/Typemaps.html b/Doc/Manual/Typemaps.html index 3d6abf88e..770604684 100644 --- a/Doc/Manual/Typemaps.html +++ b/Doc/Manual/Typemaps.html @@ -6,7 +6,7 @@ -

    11 Typemaps

    +

    11 Typemaps

      @@ -97,7 +97,7 @@ -

      11.1 Introduction

      +

      11.1 Introduction

      @@ -114,7 +114,7 @@ to re-read the earlier chapters if you have found your way to this chapter with only a vague idea of what SWIG already does by default.

      -

      11.1.1 Type conversion

      +

      11.1.1 Type conversion

      @@ -207,7 +207,7 @@ to read the extension documentation for your favorite language to know how it works (an exercise left to the reader).

      -

      11.1.2 Typemaps

      +

      11.1.2 Typemaps

      @@ -308,7 +308,7 @@ parts of the generated wrapper functions. Because arbitrary code can be insert possible to completely change the way in which values are converted.

      -

      11.1.3 Pattern matching

      +

      11.1.3 Pattern matching

      @@ -410,7 +410,7 @@ In this case, a single input object is expanded into a pair of C arguments. Thi provides a hint to the unusual variable naming scheme involving $1, $2, and so forth.

      -

      11.1.4 Reusing typemaps

      +

      11.1.4 Reusing typemaps

      @@ -466,7 +466,7 @@ typedef int size_t; then SWIG already knows that the int typemaps apply. You don't have to do anything.

      -

      11.1.5 What can be done with typemaps?

      +

      11.1.5 What can be done with typemaps?

      @@ -578,7 +578,7 @@ typemaps that expand upon this list. For example, the Java module defines a var aspects of the Java bindings. Consult language specific documentation for further details.

      -

      11.1.6 What can't be done with typemaps?

      +

      11.1.6 What can't be done with typemaps?

      @@ -641,7 +641,7 @@ void wrap_foo(char *s, int x) {

    -

    11.1.7 Similarities to Aspect Oriented Programming

    +

    11.1.7 Similarities to Aspect Oriented Programming

    @@ -659,7 +659,7 @@ SWIG can also be viewed as has having a second set of aspects based around %exception are also cross-cutting concerns as they encapsulate code that can be used to add logging or exception handling to any function.

    -

    11.1.8 The rest of this chapter

    +

    11.1.8 The rest of this chapter

    @@ -679,14 +679,14 @@ of "The C Programming Language" by Kernighan and Ritchie or "The C++ Programming Language" by Stroustrup before going any further.

    -

    11.2 Typemap specifications

    +

    11.2 Typemap specifications

    This section describes the behavior of the %typemap directive itself.

    -

    11.2.1 Defining a typemap

    +

    11.2.1 Defining a typemap

    @@ -799,7 +799,7 @@ Admittedly, it's not the most readable syntax at first glance. However, the pur individual pieces will become clear.

    -

    11.2.2 Typemap scope

    +

    11.2.2 Typemap scope

    @@ -849,7 +849,7 @@ class Foo { -

    11.2.3 Copying a typemap

    +

    11.2.3 Copying a typemap

    @@ -907,7 +907,7 @@ The patterns for %apply follow the same rules as for %typemap. -

    11.2.4 Deleting a typemap

    +

    11.2.4 Deleting a typemap

    @@ -940,7 +940,7 @@ For example: after the clear operation.

    -

    11.2.5 Placement of typemaps

    +

    11.2.5 Placement of typemaps

    @@ -1020,7 +1020,7 @@ It should be noted that for scoping to work, SWIG has to know that stringclass string.

    -

    11.3 Pattern matching rules

    +

    11.3 Pattern matching rules

    @@ -1028,7 +1028,7 @@ The section describes the pattern matching rules by which C/C++ datatypes are as The matching rules can be observed in practice by using the debugging options also described.

    -

    11.3.1 Basic matching rules

    +

    11.3.1 Basic matching rules

    @@ -1127,7 +1127,7 @@ void F(int x[1000]); // int [ANY] rule (typemap 5) stripped all qualifiers in one step.

    -

    11.3.2 Typedef reductions matching

    +

    11.3.2 Typedef reductions matching

    @@ -1302,7 +1302,7 @@ void go(Struct aStruct); -

    11.3.3 Default typemap matching rules

    +

    11.3.3 Default typemap matching rules

    @@ -1440,7 +1440,7 @@ Finally the best way to view the typemap matching rules in action is via the -

    11.3.4 Multi-arguments typemaps

    +

    11.3.4 Multi-arguments typemaps

    @@ -1470,7 +1470,7 @@ but all subsequent arguments must match exactly.

    -

    11.3.5 Matching rules compared to C++ templates

    +

    11.3.5 Matching rules compared to C++ templates

    @@ -1629,7 +1629,7 @@ are similar to those for specialized template handling.

    -

    11.3.6 Debugging typemap pattern matching

    +

    11.3.6 Debugging typemap pattern matching

    @@ -1842,7 +1842,7 @@ Also the types may be displayed slightly differently - char const * and -

    11.4 Code generation rules

    +

    11.4 Code generation rules

    @@ -1850,7 +1850,7 @@ This section describes rules by which typemap code is inserted into the generated wrapper code.

    -

    11.4.1 Scope

    +

    11.4.1 Scope

    @@ -1928,7 +1928,7 @@ a block scope when it is emitted. This sometimes results in a less complicated Note that only the third of the three typemaps have the typemap code passed through the SWIG preprocessor.

    -

    11.4.2 Declaring new local variables

    +

    11.4.2 Declaring new local variables

    @@ -2095,7 +2095,7 @@ each type must have its own local variable declaration. -

    11.4.3 Special variables

    +

    11.4.3 Special variables

    @@ -2347,7 +2347,7 @@ Another approach, which only works for arrays is to use the $1_basetype -

    11.4.4 Special variable macros

    +

    11.4.4 Special variable macros

    @@ -2359,7 +2359,7 @@ it is done during the SWIG parsing/compilation stages. The following special variable macros are available across all language modules.

    -

    11.4.4.1 $descriptor(type)

    +

    11.4.4.1 $descriptor(type)

    @@ -2370,7 +2370,7 @@ For example, $descriptor(std::vector<int> *) will expand into Run-time type checker usage section.

    -

    11.4.4.2 $typemap(method, typepattern)

    +

    11.4.4.2 $typemap(method, typepattern)

    @@ -2428,7 +2428,7 @@ The result is the following expansion -

    11.4.5 Special variables and typemap attributes

    +

    11.4.5 Special variables and typemap attributes

    @@ -2455,7 +2455,7 @@ is equivalent to the following as $*1_ltype expands to unsigned int -

    11.4.6 Special variables combined with special variable macros

    +

    11.4.6 Special variables combined with special variable macros

    @@ -2497,7 +2497,7 @@ which then expands to: -

    11.5 Common typemap methods

    +

    11.5 Common typemap methods

    @@ -2505,7 +2505,7 @@ The set of typemaps recognized by a language module may vary. However, the following typemap methods are nearly universal:

    -

    11.5.1 "in" typemap

    +

    11.5.1 "in" typemap

    @@ -2565,7 +2565,7 @@ Usually numinputs is not specified, whereupon the default value is 1, t is the same as the old "ignore" typemap.

    -

    11.5.2 "typecheck" typemap

    +

    11.5.2 "typecheck" typemap

    @@ -2591,7 +2591,7 @@ If you define new "in" typemaps and your program uses overloaded method "typecheck" typemaps. More details about this follow in the Typemaps and overloading section.

    -

    11.5.3 "out" typemap

    +

    11.5.3 "out" typemap

    @@ -2622,7 +2622,7 @@ $symname - Name of function/method being wrapped The "out" typemap supports an optional attribute flag called "optimal". This is for code optimisation and is detailed in the Optimal code generation when returning by value section.

    -

    11.5.4 "arginit" typemap

    +

    11.5.4 "arginit" typemap

    @@ -2641,7 +2641,7 @@ For example: -

    11.5.5 "default" typemap

    +

    11.5.5 "default" typemap

    @@ -2674,7 +2674,7 @@ See the Default/optional arguments sec for further information on default argument wrapping.

    -

    11.5.6 "check" typemap

    +

    11.5.6 "check" typemap

    @@ -2693,7 +2693,7 @@ converted. For example: -

    11.5.7 "argout" typemap

    +

    11.5.7 "argout" typemap

    @@ -2739,7 +2739,7 @@ return values are often appended to return value of the function. See the typemaps.i library file for examples.

    -

    11.5.8 "freearg" typemap

    +

    11.5.8 "freearg" typemap

    @@ -2772,7 +2772,7 @@ be used in other typemaps whenever a wrapper function needs to abort prematurely.

    -

    11.5.9 "newfree" typemap

    +

    11.5.9 "newfree" typemap

    @@ -2801,7 +2801,7 @@ string *foo(); See Object ownership and %newobject for further details.

    -

    11.5.10 "memberin" typemap

    +

    11.5.10 "memberin" typemap

    @@ -2823,7 +2823,7 @@ It is rarely necessary to write "memberin" typemaps---SWIG already provides a default implementation for arrays, strings, and other objects.

    -

    11.5.11 "varin" typemap

    +

    11.5.11 "varin" typemap

    @@ -2831,7 +2831,7 @@ The "varin" typemap is used to convert objects in the target language to C for t purposes of assigning to a C/C++ global variable. This is implementation specific.

    -

    11.5.12 "varout" typemap

    +

    11.5.12 "varout" typemap

    @@ -2839,7 +2839,7 @@ The "varout" typemap is used to convert a C/C++ object to an object in the targe language when reading a C/C++ global variable. This is implementation specific.

    -

    11.5.13 "throws" typemap

    +

    11.5.13 "throws" typemap

    @@ -2885,7 +2885,7 @@ Note that if your methods do not have an exception specification yet they do thr For a neat way to handle these, see the Exception handling with %exception section.

    -

    11.6 Some typemap examples

    +

    11.6 Some typemap examples

    @@ -2893,7 +2893,7 @@ This section contains a few examples. Consult language module documentation for more examples.

    -

    11.6.1 Typemaps for arrays

    +

    11.6.1 Typemaps for arrays

    @@ -3152,7 +3152,7 @@ Now, you will find that member access is quite nice: useless and has since been eliminated. To return structure members, simply use the "out" typemap.

    -

    11.6.2 Implementing constraints with typemaps

    +

    11.6.2 Implementing constraints with typemaps

    @@ -3200,7 +3200,7 @@ a NULL pointer. As a result, SWIG can often prevent a potential segmentation faults or other run-time problems by raising an exception rather than blindly passing values to the underlying C/C++ program.

    -

    11.7 Typemaps for multiple target languages

    +

    11.7 Typemaps for multiple target languages

    @@ -3230,7 +3230,7 @@ The example above also shows a common approach of issuing a warning for an as ye %typemap(ruby,in) int "$1 = NUM2INT($input);".

    -

    11.8 Optimal code generation when returning by value

    +

    11.8 Optimal code generation when returning by value

    @@ -3419,7 +3419,7 @@ example.i:7: Warning 475: optimal attribute usage in the out typemap. However, it doesn't always get it right, for example when $1 is within some commented out code.

    -

    11.9 Multi-argument typemaps

    +

    11.9 Multi-argument typemaps

    @@ -3686,7 +3686,7 @@ with non-consecutive C/C++ arguments; a workaround such as a helper function re- the arguments to make them consecutive will need to be written.

    -

    11.10 Typemap warnings

    +

    11.10 Typemap warnings

    @@ -3695,7 +3695,7 @@ See the information in the issuing warnings

    -

    11.11 Typemap fragments

    +

    11.11 Typemap fragments

    @@ -3948,7 +3948,7 @@ fragment usage unless a desire to really get to grips with some powerful but tricky macro and fragment usage that is used in parts of the SWIG typemap library.

    -

    11.11.1 Fragment type specialization

    +

    11.11.1 Fragment type specialization

    @@ -3981,7 +3981,7 @@ struct A { -

    11.11.2 Fragments and automatic typemap specialization

    +

    11.11.2 Fragments and automatic typemap specialization

    @@ -4027,7 +4027,7 @@ The interested (or very brave) reader can take a look at the fragments.swg file

    -

    11.12 The run-time type checker

    +

    11.12 The run-time type checker

    @@ -4053,7 +4053,7 @@ language modules.

  • Modules can be unloaded from the type system.
    • -

    11.12.1 Implementation

    +

    11.12.1 Implementation

    @@ -4239,7 +4239,7 @@ structures rather than creating new ones. These swig_module_info structures are chained together in a circularly linked list.

    -

    11.12.2 Usage

    +

    11.12.2 Usage

    This section covers how to use these functions from typemaps. To learn how to @@ -4333,7 +4333,7 @@ probably just look at the output of SWIG to get a better sense for how types are managed.

    -

    11.13 Typemaps and overloading

    +

    11.13 Typemaps and overloading

    @@ -4664,7 +4664,7 @@ Subsequent "in" typemaps would then perform more extensive type-checking. -

    11.14 More about %apply and %clear

    +

    11.14 More about %apply and %clear

    @@ -4750,7 +4750,7 @@ example: -

    11.15 Passing data between typemaps

    +

    11.15 Passing data between typemaps

    @@ -4787,7 +4787,7 @@ sure that the typemaps sharing information have exactly the same types and names

    -

    11.16 C++ "this" pointer

    +

    11.16 C++ "this" pointer

    @@ -4847,7 +4847,7 @@ will also match the typemap. One work around is to create an interface file tha the method, but gives the argument a name other than self.

    -

    11.17 Where to go for more information?

    +

    11.17 Where to go for more information?

    diff --git a/Doc/Manual/Varargs.html b/Doc/Manual/Varargs.html index 360bbaa12..c2f55b019 100644 --- a/Doc/Manual/Varargs.html +++ b/Doc/Manual/Varargs.html @@ -6,7 +6,7 @@ -

    14 Variable Length Arguments

    +

    14 Variable Length Arguments

      @@ -42,7 +42,7 @@ added in SWIG-1.3.12. Most other wrapper generation tools have wisely chosen to avoid this issue.

      -

      14.1 Introduction

      +

      14.1 Introduction

      @@ -139,7 +139,7 @@ List make_list(const char *s, ...) {

    -

    14.2 The Problem

    +

    14.2 The Problem

    @@ -232,7 +232,7 @@ can also support real varargs wrapping (with stack-frame manipulation) if you are willing to get hands dirty. Keep reading.

    -

    14.3 Default varargs support

    +

    14.3 Default varargs support

    @@ -301,7 +301,7 @@ Read on for further solutions.

    -

    14.4 Argument replacement using %varargs

    +

    14.4 Argument replacement using %varargs

    @@ -412,7 +412,7 @@ mixed argument types such as printf(). Providing general purpose wrappers to such functions presents special problems (covered shortly).

    -

    14.5 Varargs and typemaps

    +

    14.5 Varargs and typemaps

    @@ -589,7 +589,7 @@ really want to elevate your guru status and increase your job security, continue to the next section.

    -

    14.6 Varargs wrapping with libffi

    +

    14.6 Varargs wrapping with libffi

    @@ -841,7 +841,7 @@ provide an argument number for the first extra argument. This can be used to in values. Please consult the chapter on each language module for more details.

    -

    14.7 Wrapping of va_list

    +

    14.7 Wrapping of va_list

    @@ -895,7 +895,7 @@ int my_vprintf(const char *fmt, ...) { -

    14.8 C++ Issues

    +

    14.8 C++ Issues

    @@ -964,7 +964,7 @@ design or to provide an alternative interface using a helper function than it is fully general wrapper to a varargs C++ member function.

    -

    14.9 Discussion

    +

    14.9 Discussion

    diff --git a/Doc/Manual/Warnings.html b/Doc/Manual/Warnings.html index 2336120d3..92ec5000c 100644 --- a/Doc/Manual/Warnings.html +++ b/Doc/Manual/Warnings.html @@ -6,7 +6,7 @@ -

    15 Warning Messages

    +

    15 Warning Messages

      @@ -35,7 +35,7 @@ -

      15.1 Introduction

      +

      15.1 Introduction

      @@ -55,7 +55,7 @@ where the generated wrapper code will probably compile, but it may not work like you expect.

      -

      15.2 Warning message suppression

      +

      15.2 Warning message suppression

      @@ -147,7 +147,7 @@ your interface. Ignore the warning messages at your own peril.

      -

      15.3 Enabling extra warnings

      +

      15.3 Enabling extra warnings

      @@ -220,7 +220,7 @@ that is, any warnings suppressed or added in %warnfilter, #pragma S or the -w option.

      -

      15.4 Issuing a warning message

      +

      15.4 Issuing a warning message

      @@ -274,7 +274,7 @@ example.i:24: Warning 901: You are really going to regret this usage of blah * s

    -

    15.5 Symbolic symbols

    +

    15.5 Symbolic symbols

    @@ -309,7 +309,7 @@ or -

    15.6 Commentary

    +

    15.6 Commentary

    @@ -326,7 +326,7 @@ no obvious recovery. There is no mechanism for suppressing error messages.

    -

    15.7 Warnings as errors

    +

    15.7 Warnings as errors

    @@ -335,7 +335,7 @@ option. This will cause SWIG to exit with a non successful exit code if a warning is encountered.

    -

    15.8 Message output format

    +

    15.8 Message output format

    @@ -354,10 +354,10 @@ $ swig -python -Fmicrosoft example.i example.i(4) : Syntax error in input(1). -

    15.9 Warning number reference

    +

    15.9 Warning number reference

    -

    15.9.1 Deprecated features (100-199)

    +

    15.9.1 Deprecated features (100-199)

      @@ -385,7 +385,7 @@ example.i(4) : Syntax error in input(1).
    • 126. The 'nestedworkaround' feature is deprecated.
    -

    15.9.2 Preprocessor (200-299)

    +

    15.9.2 Preprocessor (200-299)

      @@ -397,7 +397,7 @@ example.i(4) : Syntax error in input(1).
    • 206. Unexpected tokens after #directive directive.
    -

    15.9.3 C/C++ Parser (300-399)

    +

    15.9.3 C/C++ Parser (300-399)

      @@ -474,7 +474,7 @@ example.i(4) : Syntax error in input(1).
    • 395. operator delete[] ignored.
    -

    15.9.4 Types and typemaps (400-499)

    +

    15.9.4 Types and typemaps (400-499)

      @@ -505,7 +505,7 @@ example.i(4) : Syntax error in input(1). -

      15.9.5 Code generation (500-599)

      +

      15.9.5 Code generation (500-599)

        @@ -534,7 +534,7 @@ example.i(4) : Syntax error in input(1).
      • 523. Use of an illegal destructor name 'name' in %extend is deprecated, the destructor name should be 'name'.
      -

      15.9.6 Language module specific (700-899)

      +

      15.9.6 Language module specific (700-899)

        @@ -585,14 +585,14 @@ example.i(4) : Syntax error in input(1).
      • 871. Unrecognized pragma pragma. (Php).
      -

      15.9.7 User defined (900-999)

      +

      15.9.7 User defined (900-999)

      These numbers can be used by your own application.

      -

      15.10 History

      +

      15.10 History

      diff --git a/Doc/Manual/Windows.html b/Doc/Manual/Windows.html index d85737e52..fecdf48ed 100644 --- a/Doc/Manual/Windows.html +++ b/Doc/Manual/Windows.html @@ -6,7 +6,7 @@ -

      3 Getting started on Windows

      +

      3 Getting started on Windows

        @@ -52,7 +52,7 @@ Usage within the Unix like environments MinGW and Cygwin is also detailed.

        -

        3.1 Installation on Windows

        +

        3.1 Installation on Windows

        @@ -63,7 +63,7 @@ SWIG does not come with the usual Windows type installation program, however it

      • Set environment variables as described in the SWIG Windows Examples section in order to run examples using Visual C++.
      -

      3.1.1 Windows Executable

      +

      3.1.1 Windows Executable

      @@ -72,7 +72,7 @@ If you want to build your own swig.exe have a look at 3.2 SWIG Windows Examples +

      3.2 SWIG Windows Examples

      @@ -87,7 +87,7 @@ Alternatively run the examples using Cygwin More information on each of the examples is available with the examples distributed with SWIG (Examples/index.html). -

      3.2.1 Instructions for using the Examples with Visual Studio

      +

      3.2.1 Instructions for using the Examples with Visual Studio

      @@ -105,7 +105,7 @@ If you don't want to use environment variables then change all occurrences of th If you are interested in how the project files are set up there is explanatory information in some of the language module's documentation.

      -

      3.2.1.1 C#

      +

      3.2.1.1 C#

      @@ -115,7 +115,7 @@ The accompanying C# and C++ project files are automatically used by the solution

      -

      3.2.1.2 Java

      +

      3.2.1.2 Java

      @@ -129,7 +129,7 @@ JAVA_BIN: D:\jdk1.3\bin

      -

      3.2.1.3 Perl

      +

      3.2.1.3 Perl

      @@ -143,7 +143,7 @@ PERL5_LIB: D:\nsPerl5.004_04\lib\CORE\perl.lib

      -

      3.2.1.4 Python

      +

      3.2.1.4 Python

      @@ -157,7 +157,7 @@ PYTHON_LIB: D:\python21\libs\python21.lib

      -

      3.2.1.5 TCL

      +

      3.2.1.5 TCL

      @@ -171,7 +171,7 @@ TCL_LIB: D:\tcl\lib\tcl83.lib

      -

      3.2.1.6 R

      +

      3.2.1.6 R

      @@ -185,7 +185,7 @@ R_LIB: C:\Program Files\R\R-2.5.1\bin\Rdll.lib

      -

      3.2.1.7 Ruby

      +

      3.2.1.7 Ruby

      @@ -199,21 +199,21 @@ RUBY_LIB: D:\ruby\lib\mswin32-ruby16.lib

      -

      3.2.2 Instructions for using the Examples with other compilers

      +

      3.2.2 Instructions for using the Examples with other compilers

      If you do not have access to Visual C++ you will have to set up project files / Makefiles for your chosen compiler. There is a section in each of the language modules detailing what needs setting up using Visual C++ which may be of some guidance. Alternatively you may want to use Cygwin as described in the following section.

      -

      3.3 SWIG on Cygwin and MinGW

      +

      3.3 SWIG on Cygwin and MinGW

      SWIG can also be compiled and run using Cygwin or MinGW which provides a Unix like front end to Windows and comes free with gcc, an ANSI C/C++ compiler. However, this is not a recommended approach as the prebuilt executable is supplied.

      -

      3.3.1 Building swig.exe on Windows

      +

      3.3.1 Building swig.exe on Windows

      @@ -223,7 +223,7 @@ This information is provided for those that want to modify the SWIG source code Normally this is not needed, so most people will want to ignore this section.

      -

      3.3.1.1 Building swig.exe using MinGW and MSYS

      +

      3.3.1.1 Building swig.exe using MinGW and MSYS

      @@ -341,7 +341,7 @@ make -

      3.3.1.2 Building swig.exe using Cygwin

      +

      3.3.1.2 Building swig.exe using Cygwin

      @@ -352,7 +352,7 @@ Note that the Cygwin environment will also allow one to regenerate the autotool These files are generated using the autogen.sh script and will only need regenerating in circumstances such as changing the build system.

      -

      3.3.1.3 Building swig.exe alternatives

      +

      3.3.1.3 Building swig.exe alternatives

      @@ -362,7 +362,7 @@ file in order to build swig.exe from the Visual C++ IDE.

      -

      3.3.2 Running the examples on Windows using Cygwin

      +

      3.3.2 Running the examples on Windows using Cygwin

      @@ -371,7 +371,7 @@ The modules which are known to work are Python, Tcl, Perl, Ruby, Java and C#. Follow the Unix instructions in the README file in the SWIG root directory to build the examples.

      -

      3.4 Microsoft extensions and other Windows quirks

      +

      3.4 Microsoft extensions and other Windows quirks