The Android chapter is fairly short as support for Android is the same as for Java, where the Java Native Interface (JNI) is used to call from Android Java into C or C++ compiled code. -Everything in the Java chapter applies to generating code for access from Android Java code. +Everything in the Java chapter applies to generating code for access from Android Java code. This chapter contains a few Android specific notes and examples.
diff --git a/Doc/Manual/CSharp.html b/Doc/Manual/CSharp.html index 18fc3037e..e55013b1c 100644 --- a/Doc/Manual/CSharp.html +++ b/Doc/Manual/CSharp.html @@ -1740,7 +1740,7 @@ should pass the call on to CSharpDefaults.DefaultMethod(int)using the C-When using multiple modules it is is possible to compile each SWIG generated wrapper +When using multiple modules it is is possible to compile each SWIG generated wrapper into a different assembly. However, by default the generated code may not compile if generated classes in one assembly use generated classes in another assembly. diff --git a/Doc/Manual/D.html b/Doc/Manual/D.html index 47dab50f1..984b81bb8 100644 --- a/Doc/Manual/D.html +++ b/Doc/Manual/D.html @@ -50,7 +50,7 @@
While these issues can be worked around relatively easy by hand-coding a thin wrapper layer around the C library in question, there is another issue where writing wrapper code per hand is not feasible: C++ libraries. D did not support interfacing to C++ in version 1 at all, and even if extern(C++) has been added to D2, the support is still very limited, and a custom wrapper layer is still required in many cases.
-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).
+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).
By default, SWIG generates code for D1/Tango. Use the -d2 flag to target D2/Phobos instead.
-By default, SWIG generates two D modules: the proxy module, named like the source module (either specified via the %module directive or via the module command line switch), which contains all the proxy classes, functions, enums, etc., and the intermediary module (named like the proxy module, but suffixed with _im), which contains all the extern(C) function declarations and other private parts only used internally by the proxy module.
If the split proxy mode is enabled by passing this switch at the command line, all proxy classes and enums are emitted to their own D module instead. The main proxy module only contains free functions and constants in this case.
@@ -125,7 +125,7 @@Used for converting between the types for C/C++ and D when generating the code for the wrapper functions (on the C++ side).
-The code from the in typemap is used to convert arguments to the C wrapper function to the type used in the wrapped code (ctype->original C++ type), the out typemap is utilized to convert values from the wrapped code to wrapper function return types (original C++ type->ctype).
+The code from the in typemap is used to convert arguments to the C wrapper function to the type used in the wrapped code (ctype->original C++ type), the out typemap is utilized to convert values from the wrapped code to wrapper function return types (original C++ type->ctype).
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).
@@ -135,11 +135,11 @@Typemaps for code generation in D proxy and type wrapper classes.
-The din typemap is used for converting function parameter types from the type used in the proxy module or class to the type used in the intermediary D module (the $dinput macro is replaced). To inject further parameter processing code before or after the call to the intermediary layer, the pre, post and terminator attributes can be used (please refer to the C# date marshalling example for more information on these).
+The din typemap is used for converting function parameter types from the type used in the proxy module or class to the type used in the intermediary D module (the $dinput macro is replaced). To inject further parameter processing code before or after the call to the intermediary layer, the pre, post and terminator attributes can be used (please refer to the C# date marshalling example for more information on these).
-The dout typemap is used for converting function return values from the return type used in the intermediary D module to the type returned by the proxy function. The $excode special variable in dout typemaps is replaced by the excode typemap attribute code if the method can throw any exceptions from unmanaged code, otherwise by nothing (the $imcall and $owner macros are replaced).
+The dout typemap is used for converting function return values from the return type used in the intermediary D module to the type returned by the proxy function. The $excode special variable in dout typemaps is replaced by the excode typemap attribute code if the method can throw any exceptions from unmanaged code, otherwise by nothing (the $imcall and $owner macros are replaced).
-The code from the ddirectorin and ddirectorout typemaps is used for conversion in director callback functions. Arguments are converted to the type used in the proxy class method they are calling by using the code from ddirectorin, the proxy class method return value is converted to the type the C++ code expects via the ddirectorout typemap (the $dcall and $winput macros are replaced).
+The code from the ddirectorin and ddirectorout typemaps is used for conversion in director callback functions. Arguments are converted to the type used in the proxy class method they are calling by using the code from ddirectorin, the proxy class method return value is converted to the type the C++ code expects via the ddirectorout typemap (the $dcall and $winput macros are replaced).
The full chain of type conversions when a director callback is invoked looks like this:
@@ -172,7 +172,7 @@Using dcode and dimports, you can specify additional D code which will be emitted into the class body respectively the imports section of the D module the class is written to.
-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.
+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.
In code inserted into the generated C/C++ wrapper functions, this variable is replaced by either 0 or nothing at all, depending on whether the function has a return value or not. It can be used to bail out early e.g. in case of errors (return $null;).
This variable is used in din typemaps and is replaced by the expression which is to be passed to C/C++.
For example, this input
@@ -214,7 +214,7 @@ void foo(SomeClass arg) { example_im.foo(SomeClass.getCPointer(arg)); }These variables are used in dout typemaps. $imcall contains the call to the intermediary module which provides the value to be used, and $owner signals if the caller is responsible for managing the object lifetime (that is, if the called method is a constructor or has been marked via %newobject).
Consider the following example:
@@ -243,7 +243,7 @@ SomeClass bar() {These variables are used in the director-specific typemaps ddirectorin and ddirectorout. They are more or less the reverse of the $imcall and $dinput macros: $dcall contains the invocation of the D proxy method of which the return value is to be passed back to C++, $winput contains the parameter value from C++.
These variables are used in the director-specific typemaps ddirectorin and ddirectorout. They are more or less the reverse of the $imcall and $dinput macros: $dcall contains the invocation of the D proxy method of which the return value is to be passed back to C++, $winput contains the parameter value from C++.
This variable is used in dout and dconstructor typemaps and is filled with the contents of the excode typemap attribute if an exception could be thrown from the C++ side. See the C# documentation for details.
This macro is used in the dimports typemap if a dependency on another D type generated by SWIG is added by a custom typemap.
Consider the following code snippet:
diff --git a/Doc/Manual/Introduction.html b/Doc/Manual/Introduction.html index 02a41169a..e0dd3c044 100644 --- a/Doc/Manual/Introduction.html +++ b/Doc/Manual/Introduction.html @@ -334,7 +334,7 @@ major features include:-Most of C++11 is also supported. Details are in the C++11 section. +Most of C++11 is also supported. Details are in the C++11 section.
diff --git a/Doc/Manual/Java.html b/Doc/Manual/Java.html index c33c1c16c..b6885b94f 100644 --- a/Doc/Manual/Java.html +++ b/Doc/Manual/Java.html @@ -213,7 +213,7 @@ The Java module requires your system to support shared libraries and dynamic loa This is the commonly used method to load JNI code so your system will more than likely support this.
-Android uses Java JNI and also works with SWIG. Please read the Android chapter in conjunction with this one if you are targeting Android. +Android uses Java JNI and also works with SWIG. Please read the Android chapter in conjunction with this one if you are targeting Android.
-When using multiple modules or the nspace feature it is common to invoke SWIG with a different -package +When using multiple modules or the nspace feature it is common to invoke SWIG with a different -package command line option for each module. However, by default the generated code may not compile if generated classes in one package use generated classes in another package. diff --git a/Doc/Manual/Makefile b/Doc/Manual/Makefile index 893b4a05d..d7011db06 100644 --- a/Doc/Manual/Makefile +++ b/Doc/Manual/Makefile @@ -9,7 +9,7 @@ # validation. # # Additional html validation can be done using the validate target. -# Additional link checking can be done using the linkchecker target. +# Additional link checking can be done using the linkchecker1 and linkchecker2 target. # # Note the # and " are escaped @@ -34,6 +34,14 @@ check: tidy -errors --gnu-emacs yes -quiet Sections.html all=`sed '/^#/d' chapters | grep -v CCache.html`; for a in $$all; do tidy -errors --gnu-emacs yes -quiet $$a; done; +# Check for links which don't work including those generated from the individual .html files into SWIGDocumentation.html +linkchecker: + rm -rf linkchecker-tmp + mkdir linkchecker-tmp + cp SWIGDocumentation.html linkchecker-tmp + cp *.png linkchecker-tmp + (cd linkchecker-tmp && linkchecker -F text --no-warnings SWIGDocumentation.html) + generate: swightml.book swigpdf.book htmldoc --batch swightml.book || true htmldoc --batch swigpdf.book || true diff --git a/Doc/Manual/Preface.html b/Doc/Manual/Preface.html index d17dc229c..23481d751 100644 --- a/Doc/Manual/Preface.html +++ b/Doc/Manual/Preface.html @@ -255,7 +255,7 @@ can only fix bugs if we know about them.
-Please see the dedicated Windows chapter for instructions on installing +Please see the dedicated Windows chapter for instructions on installing SWIG on Windows and running the examples. The Windows distribution is called swigwin and includes a prebuilt SWIG executable, swig.exe, included in the top level directory. Otherwise it is exactly the same as @@ -332,7 +332,7 @@ be configured with a subset of target languages. SWIG used to include a set of runtime libraries for some languages for working with multiple modules. These are no longer built during the installation stage. However, users can build them just like any wrapper module as described in -the Modules chapter. +the Modules chapter. The CHANGES file shipped with SWIG in the top level directory also lists some examples which build the runtime library.
diff --git a/Doc/Manual/Scilab.html b/Doc/Manual/Scilab.html index cb4a3af90..5a894d587 100644 --- a/Doc/Manual/Scilab.html +++ b/Doc/Manual/Scilab.html @@ -321,7 +321,7 @@ $ swig -scilab -help-SWIG for Scilab provides only a low-level C interface for Scilab (see Scripting Languages for the general approach to wrapping). +SWIG for Scilab provides only a low-level C interface for Scilab (see Scripting Languages for the general approach to wrapping). This means that functions, structs, classes, variables, etc... are interfaced through C functions. These C functions are mapped as Scilab functions. There are a few exceptions, such as constants and enumerations, which can be wrapped directly as Scilab variables.
diff --git a/Doc/Manual/Typemaps.html b/Doc/Manual/Typemaps.html index 51fadb095..3d6abf88e 100644 --- a/Doc/Manual/Typemaps.html +++ b/Doc/Manual/Typemaps.html @@ -655,7 +655,7 @@ The %feature. +SWIG can also be viewed as has having a second set of aspects based around %feature. Features such as %exception are also cross-cutting concerns as they encapsulate code that can be used to add logging or exception handling to any function.