html error fixes
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@7247 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
parent
7c9e7a7e6d
commit
3a23e98a13
8 changed files with 61 additions and 52 deletions
|
|
@ -29,9 +29,9 @@
|
|||
|
||||
<p>
|
||||
The purpose of the C# module is to offer an automated way of accessing existing C/C++ code from .NET languages.
|
||||
The wrapper code implementation uses C# and the Platform Invoke (PINVOKE) interface to access natively compiled C/C++ code.
|
||||
The PINVOKE interface has been chosen over Microsoft's Managed C++ interface as it is portable to both Microsoft Windows and non-Microsoft platforms.
|
||||
PINVOKE is part of the ECMA/ISO C# specification.
|
||||
The wrapper code implementation uses C# and the Platform Invoke (PInvoke) interface to access natively compiled C/C++ code.
|
||||
The PInvoke interface has been chosen over Microsoft's Managed C++ interface as it is portable to both Microsoft Windows and non-Microsoft platforms.
|
||||
PInvoke is part of the ECMA/ISO C# specification.
|
||||
It is also better suited for robust production environments due to the Managed C++ flaw called the
|
||||
<a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vcconMixedDLLLoadingProblem.asp">Mixed DLL Loading Problem</a>.
|
||||
Swig C# works equally well on non-Microsoft operating systems such as Linux, Solaris and Apple Mac using
|
||||
|
|
@ -96,7 +96,7 @@ Note that %csconst(0) will be ignored when wrapping C/C++ enums with proper C# e
|
|||
This is because C# enum items must be initialised from a compile time constant.
|
||||
If an enum item has an initialiser and the initialiser doesn't compile as C# code,
|
||||
then the %csconstvalue directive must be used as %csconst(0) will have no effect.
|
||||
If it was used, it would generate an illegal runtime initialisation via a PINVOKE call.
|
||||
If it was used, it would generate an illegal runtime initialisation via a PInvoke call.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
|
|
@ -451,11 +451,15 @@ the code contains a call to <tt>SWIG_CSharpSetPendingExceptionArgument()</tt>. T
|
|||
|
||||
%typemap(check, canthrow=1) int number %{
|
||||
if ($1 < 0) {
|
||||
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException, "only positive numbers accepted", "number");
|
||||
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException,
|
||||
"only positive numbers accepted", "number");
|
||||
return $null;
|
||||
}
|
||||
// SWIGEXCODE is a macro used by many other csout typemaps
|
||||
%define SWIGEXCODE "\n if ($modulePINVOKE.SWIGPendingException.Pending) throw $modulePINVOKE.SWIGPendingException.Retrieve();" %enddef
|
||||
%define SWIGEXCODE
|
||||
"\n if ($modulePINVOKE.SWIGPendingException.Pending)"
|
||||
"\n throw $modulePINVOKE.SWIGPendingException.Retrieve();"
|
||||
%enddef
|
||||
%typemap(csout, excode=SWIGEXCODE) void {
|
||||
$imcall;$excode
|
||||
}
|
||||
|
|
@ -504,13 +508,14 @@ Now let's analyse the generated code to gain a fuller understanding of the typem
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
DllExport void SWIGSTDCALL CSharp_positivesonly(int jarg1) {
|
||||
SWIGEXPORT void SWIGSTDCALL CSharp_positivesonly(int jarg1) {
|
||||
int arg1 ;
|
||||
|
||||
arg1 = (int)jarg1;
|
||||
|
||||
if (arg1 < 0) {
|
||||
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException, "only positive numbers accepted", "number");
|
||||
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException,
|
||||
"only positive numbers accepted", "number");
|
||||
return ;
|
||||
}
|
||||
|
||||
|
|
@ -529,7 +534,8 @@ This largely comes from the "check" typemap. The managed code in the module clas
|
|||
public class example {
|
||||
public static void positivesonly(int number) {
|
||||
examplePINVOKE.positivesonly(number);
|
||||
if (examplePINVOKE.SWIGPendingException.Pending) throw examplePINVOKE.SWIGPendingException.Retrieve();
|
||||
if (examplePINVOKE.SWIGPendingException.Pending)
|
||||
throw examplePINVOKE.SWIGPendingException.Retrieve();
|
||||
}
|
||||
|
||||
}
|
||||
|
|
@ -578,7 +584,8 @@ In fact, the code above would be generated if the <tt>canthrow</tt> attribute wa
|
|||
<pre>
|
||||
%typemap(check) int number %{
|
||||
if ($1 < 0) {
|
||||
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException, "only positive numbers accepted", "number");
|
||||
SWIG_CSharpSetPendingExceptionArgument(SWIG_CSharpArgumentOutOfRangeException,
|
||||
"only positive numbers accepted", "number");
|
||||
return $null;
|
||||
}
|
||||
%}
|
||||
|
|
@ -634,7 +641,7 @@ The generated unmanaged code this time catches the C++ exception and converts it
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
DllExport void SWIGSTDCALL CSharp_negativesonly(int jarg1) {
|
||||
SWIGEXPORT void SWIGSTDCALL CSharp_negativesonly(int jarg1) {
|
||||
int arg1 ;
|
||||
|
||||
arg1 = (int)jarg1;
|
||||
|
|
@ -659,7 +666,8 @@ The managed code generated does check for the pending exception as mentioned ear
|
|||
<pre>
|
||||
public static void negativesonly(int value) {
|
||||
examplePINVOKE.negativesonly(value);
|
||||
if (examplePINVOKE.SWIGPendingException.Pending) throw examplePINVOKE.SWIGPendingException.Retrieve();
|
||||
if (examplePINVOKE.SWIGPendingException.Pending)
|
||||
throw examplePINVOKE.SWIGPendingException.Retrieve();
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -683,7 +691,7 @@ such as the <tt>evensonly</tt> method below.
|
|||
}
|
||||
|
||||
%inline %{
|
||||
#include <stdexcept>
|
||||
#include <stdexcept>
|
||||
void evensonly(int input) throw (std::out_of_range) {
|
||||
if (input%2 != 0)
|
||||
throw std::out_of_range("number is not even");
|
||||
|
|
@ -699,7 +707,7 @@ SWIG generates a try catch block with the throws typemap code in the catch handl
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
DllExport void SWIGSTDCALL CSharp_evensonly(int jarg1) {
|
||||
SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
|
||||
int arg1 ;
|
||||
|
||||
arg1 = (int)jarg1;
|
||||
|
|
@ -750,11 +758,13 @@ the C# code can be generated into the intermediary class using the <tt>imclassco
|
|||
typedef void (SWIGSTDCALL* CSharpExceptionCallback_t)(const char *);
|
||||
CSharpExceptionCallback_t customExceptionCallback = NULL;
|
||||
|
||||
extern "C" DllExport void SWIGSTDCALL CustomExceptionRegisterCallback(CSharpExceptionCallback_t customCallback) {
|
||||
extern "C" SWIGEXPORT
|
||||
void SWIGSTDCALL CustomExceptionRegisterCallback(CSharpExceptionCallback_t customCallback) {
|
||||
customExceptionCallback = customCallback;
|
||||
}
|
||||
|
||||
// Note that SWIG detects any method calls named starting with SWIG_CSharpSetPendingException for warning 845
|
||||
// Note that SWIG detects any method calls named starting with
|
||||
// SWIG_CSharpSetPendingException for warning 845
|
||||
static void SWIG_CSharpSetPendingExceptionCustom(const char *msg) {
|
||||
customExceptionCallback(msg);
|
||||
}
|
||||
|
|
@ -764,7 +774,8 @@ the C# code can be generated into the intermediary class using the <tt>imclassco
|
|||
class CustomExceptionHelper {
|
||||
// C# delegate for the C/C++ customExceptionCallback
|
||||
public delegate void CustomExceptionDelegate(string message);
|
||||
static CustomExceptionDelegate customDelegate = new CustomExceptionDelegate(SetPendingCustomException);
|
||||
static CustomExceptionDelegate customDelegate =
|
||||
new CustomExceptionDelegate(SetPendingCustomException);
|
||||
|
||||
[DllImport("$dllimport", EntryPoint="CustomExceptionRegisterCallback")]
|
||||
public static extern void CustomExceptionRegisterCallback(CustomExceptionDelegate customCallback);
|
||||
|
|
|
|||
|
|
@ -379,10 +379,10 @@
|
|||
<li><a href="Typemaps.html#Typemaps_nn46">Usage</a>
|
||||
</ul>
|
||||
<li><a href="Typemaps.html#Typemaps_overloading">Typemaps and overloading</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn45">More about <tt>%apply</tt> and <tt>%clear</tt></a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn46">Reducing wrapper code size</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn48">More about <tt>%apply</tt> and <tt>%clear</tt></a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn49">Reducing wrapper code size</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn47">Passing data between typemaps</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn48">Where to go for more information?</a>
|
||||
<li><a href="Typemaps.html#Typemaps_nn51">Where to go for more information?</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -519,11 +519,11 @@
|
|||
<li><a href="Chicken.html#Chicken_nn10">Exceptions</a>
|
||||
</ul>
|
||||
<li><a href="Chicken.html#Chicken_nn11">TinyCLOS</a>
|
||||
<li><a href="Chicken.html#Chicken_nn12">Compilation</a>
|
||||
<li><a href="Chicken.html#Chicken_nn13">Linkage</a>
|
||||
<li><a href="Chicken.html#Chicken_nn12">Linkage</a>
|
||||
<ul>
|
||||
<li><a href="Chicken.html#Chicken_nn14">Shared library</a>
|
||||
<li><a href="Chicken.html#Chicken_nn15">Static binary</a>
|
||||
<li><a href="Chicken.html#Chicken_nn13">Static binary or shared library linked at compile time</a>
|
||||
<li><a href="Chicken.html#Chicken_nn14">Building chicken extension libraries</a>
|
||||
<li><a href="Chicken.html#Chicken_nn15">Linking multiple SWIG modules with TinyCLOS</a>
|
||||
</ul>
|
||||
<li><a href="Chicken.html#Chicken_nn16">Typemaps</a>
|
||||
<li><a href="Chicken.html#Chicken_nn17">Pointers</a>
|
||||
|
|
|
|||
|
|
@ -356,8 +356,7 @@ back to this behavior, use</p>
|
|||
%values_as_list;</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
<li><em>Multiple values as vectors.</em>
|
||||
<li><p><em>Multiple values as vectors.</em>
|
||||
By issuing
|
||||
</p>
|
||||
|
||||
|
|
@ -368,7 +367,7 @@ By issuing
|
|||
|
||||
<p>
|
||||
vectors instead of lists will be used.
|
||||
<li><em>Multiple values for multiple-value continuations.</em>
|
||||
<li><p><em>Multiple values for multiple-value continuations.</em>
|
||||
<strong>This is the most elegant way.</strong> By issuing
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -137,7 +137,7 @@ object is created using <tt>calloc()</tt>. In C++, <tt>new</tt> is used.
|
|||
|
||||
<div class="indent"><p>
|
||||
Deletes an object type <tt>type</tt>.
|
||||
<p></div>
|
||||
</p></div>
|
||||
|
||||
<p>
|
||||
<tt>void name_assign(type *obj, type value)</tt>
|
||||
|
|
|
|||
|
|
@ -2728,7 +2728,7 @@ likely to be extended in Python and used in C++.
|
|||
<p>
|
||||
Compared to classes that do not use directors, the call routing in the
|
||||
director methods does add some overhead. In particular, at least one
|
||||
dynamic cast and one extra function call occur per method call from
|
||||
dynamic cast and one extra function call occurs per method call from
|
||||
Python. Relative to the speed of Python execution this is probably
|
||||
completely negligible. For worst case routing, a method call that
|
||||
ultimately resolves in C++ may take one extra detour through Python in
|
||||
|
|
@ -2754,8 +2754,8 @@ Typemaps for input and output of most of the basic types from director
|
|||
classes have been written. These are roughly the reverse of the usual
|
||||
input and output typemaps used by the wrapper code. The typemap
|
||||
operation names are 'directorin', 'directorout', and 'directorargout'.
|
||||
The director code does not use any of the other kinds of typemaps
|
||||
yet. It is not clear at this point which kinds are appropriate and
|
||||
The director code does not currently use any of the other kinds of typemaps.
|
||||
It is not clear at this point which kinds are appropriate and
|
||||
need to be supported.
|
||||
</p>
|
||||
|
||||
|
|
@ -2765,7 +2765,7 @@ need to be supported.
|
|||
|
||||
<p>
|
||||
Director typemaps for STL classes are in place, and hence you should
|
||||
be able to use std::vector, std::string, etc., as any other raw type.
|
||||
be able to use std::vector, std::string, etc., as you would any other type.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -2776,7 +2776,7 @@ references, such as
|
|||
<pre>
|
||||
class Foo {
|
||||
…
|
||||
virtual const int& bar();
|
||||
virtual const int& bar();
|
||||
…
|
||||
};
|
||||
</pre>
|
||||
|
|
@ -2784,10 +2784,10 @@ class Foo {
|
|||
|
||||
<p>
|
||||
will work only for simple call scenarios. Usually the resulting code
|
||||
is neither thread or reentrant safe. Hence, the user is adviced to
|
||||
avoid returning const reference in director methods. For example,
|
||||
the user could modify the method interface to use a lvalue return
|
||||
types, when possible, i.e.
|
||||
is neither thread or reentrant safe. Hence, the user is advised to
|
||||
avoid returning const references in director methods. For example,
|
||||
the user could modify the method interface to use lvalue return
|
||||
types, wherever possible, for example
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -2801,13 +2801,11 @@ class Foo {
|
|||
</div>
|
||||
|
||||
<p>
|
||||
If that is not possible, the user should avoid to enable the
|
||||
If that is not possible, the user should avoid enabling the
|
||||
director feature for reentrant, recursive or threaded member
|
||||
methods that return const references.
|
||||
</p>
|
||||
|
||||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn40"></a>26.6 Common customization features</H2>
|
||||
|
||||
|
|
|
|||
|
|
@ -4033,8 +4033,7 @@ public:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
<li>Resolving ambiguity in overloading may prevent declarations from being
|
||||
<li><p>Resolving ambiguity in overloading may prevent declarations from being
|
||||
imported by <tt>using</tt>. For example:
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -70,10 +70,10 @@
|
|||
<li><a href="#Typemaps_nn46">Usage</a>
|
||||
</ul>
|
||||
<li><a href="#Typemaps_overloading">Typemaps and overloading</a>
|
||||
<li><a href="#Typemaps_nn45">More about <tt>%apply</tt> and <tt>%clear</tt></a>
|
||||
<li><a href="#Typemaps_nn46">Reducing wrapper code size</a>
|
||||
<li><a href="#Typemaps_nn48">More about <tt>%apply</tt> and <tt>%clear</tt></a>
|
||||
<li><a href="#Typemaps_nn49">Reducing wrapper code size</a>
|
||||
<li><a href="#Typemaps_nn47">Passing data between typemaps</a>
|
||||
<li><a href="#Typemaps_nn48">Where to go for more information?</a>
|
||||
<li><a href="#Typemaps_nn51">Where to go for more information?</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -2837,6 +2837,8 @@ information storage, the generated SWIG code needs to provide it.
|
|||
|
||||
<p>
|
||||
Requirements for the type system:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Store inheritance and type equivalence information and be able to correctly
|
||||
re-create the type pointer.</li>
|
||||
<li>Share type information between modules.</li>
|
||||
|
|
@ -2847,7 +2849,7 @@ dependency.</li>
|
|||
language modules.</li>
|
||||
<li>Custom, language specific information can be attached to types.</li>
|
||||
<li>Modules can be unloaded from the type system.</li>
|
||||
</p>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Typemaps_nn45"></a>10.8.1 Implementation</H3>
|
||||
|
||||
|
|
@ -3016,7 +3018,7 @@ Each module has one swig_module_info structure which looks like this:
|
|||
* Each module generates one structure like this, and the runtime collects
|
||||
* all of these structures and stores them in a circularly linked list.*/
|
||||
typedef struct swig_module_info {
|
||||
swig_type_info **types; /* Array of pointers to swig_type_info structures that are in this module */
|
||||
swig_type_info **types; /* Array of pointers to swig_type_info structures in this module */
|
||||
int size; /* Number of types in this module */
|
||||
struct swig_module_info *next; /* Pointer to next element in circularly linked list */
|
||||
swig_type_info **type_initial; /* Array of initially generated type structures */
|
||||
|
|
@ -3476,7 +3478,7 @@ Subsequent "in" typemaps would then perform more extensive type-checking.
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H2><a name="Typemaps_nn45"></a>10.10 More about <tt>%apply</tt> and <tt>%clear</tt></H2>
|
||||
<H2><a name="Typemaps_nn48"></a>10.10 More about <tt>%apply</tt> and <tt>%clear</tt></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3561,7 +3563,7 @@ example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Typemaps_nn46"></a>10.11 Reducing wrapper code size</H2>
|
||||
<H2><a name="Typemaps_nn49"></a>10.11 Reducing wrapper code size</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3679,7 +3681,7 @@ sure that the typemaps sharing information have exactly the same types and names
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_nn48"></a>10.13 Where to go for more information?</H2>
|
||||
<H2><a name="Typemaps_nn51"></a>10.13 Where to go for more information?</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -55,11 +55,11 @@ Usage within the Unix like environments MinGW and Cygwin is also detailed.
|
|||
|
||||
<p>
|
||||
SWIG does not come with the usual Windows type installation program, however it is quite easy to get started. The main steps are:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Download the swigwin zip package from the <a href="http://www.swig.org">SWIG website</a> and unzip into a directory. This is all that needs downloading for the Windows platform.
|
||||
<li>Set environment variables as described in the <a href="#examples">SWIG Windows Examples</a> section in order to run examples using Visual C++.
|
||||
</ul>
|
||||
</p>
|
||||
|
||||
<H3><a name="Windows_nn3"></a>3.1.1 Windows Executable</H3>
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ Most languages require some environment variables to be set <b>before</b> runnin
|
|||
Note that Visual C++ must be re-started to pick up any changes in environment variables.
|
||||
Open up an example .dsp file, Visual C++ will create a workspace for you (.dsw file).
|
||||
Ensure the Release build is selected then do a Rebuild All from the Build menu.
|
||||
The required environment variables are displayed with their current values. <p>
|
||||
The required environment variables are displayed with their current values.
|
||||
</p>
|
||||
<p>
|
||||
The list of required environment variables for each module language is also listed below.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue