@@ -62,17 +79,19 @@ With wrapper interfaces generated by SWIG, it is easy to use the functionality o Flattening C++ language constructs into a set of C-style functions obviously comes with many limitations and inconveniences, but this module is actually also capable of generating C++ wrappers defined completely inline using the C functions, thus wrapping the original C++ library API in another, similar C++ API. Contrary to the natural initial reaction, this is far from being completely pointless, as wrapping C++ API in this way avoids all problems due to C++ ABI issues, e.g. it is now possible to use the original C++ API using a different C++ compiler, or a different version of the same compiler, or even the same compiler, but with different compilation options affecting the ABI. The C++ wrapper API is not identical to the original one, but strives to be as close to it as possible.
-@@ -107,7 +126,7 @@ $ swig -c++ -c example.i
Note that -c is the option specifying the target language and -c++ controls what the input language is. -
+
This will generate an example_wrap.c file or, in the latter case, example_wrap.cxx file, along with example_wrap.h (the same extension is used in both C and C++ cases for the last one). The names of the files are derived from the name of the input file by default, but can be changed using the -o and -oh options common to all language modules. @@ -117,7 +136,7 @@ This will generate an example_wrap.c file or, in the latter case, e The xxx_wrap.c file contains the wrapper functions, which perform the main functionality of SWIG: each of the wrappers translates the input arguments from C to C++, makes calls to the original functions and marshals C++ output back to C data. The xxx_wrap.h header file contains the declarations of these functions as well as global variables.
-@@ -150,7 +169,7 @@ $ swig -c -help -
@@ -177,7 +196,7 @@ $ g++ -shared example_wrap.o -o libexample.so Now the shared library module is ready to use. Note that the name of the generated module is important: is should be prefixed with lib on Unix, and have the specific extension, like .dll for Windows or .so for Unix systems.
-@@ -192,7 +211,7 @@ $ gcc runme.c -L. -lexample -o runme This will compile the application code (runme.c) and link it against the generated shared module. Following the -L option is the path to the directory containing the shared module. The output executable is ready to use. The last thing to do is to supply to the operating system the information of location of our module. This is system dependant, for instance Unix systems look for shared modules in certain directories, like /usr/lib, and additionally we can set the environment variable LD_LIBRARY_PATH (Unix) or PATH (Windows) for other directories.
-@@ -209,7 +228,7 @@ It is also possible to output arbitrary additional code into the generated heade %} -
@@ -273,7 +292,7 @@ int _wrap_gcd(int arg1, int arg2) { This time calling gcd with negative value argument will trigger an error message. This can save you time writing all the constraint checking code by hand.
-@@ -311,7 +330,7 @@ ms.x = 123; ms.d = 123.123; -
@@ -320,6 +339,7 @@ The main reason of having the C module in SWIG is to be able to access C++ from
By default, SWIG attempts to build a natural C interface to your C/C++ code. +
| C++ Type | @@ -343,10 +363,13 @@ By default, SWIG attempts to build a natural C interface to your C/C++ code.
|---|
This section briefly covers the essential aspects of this wrapping.
-C enums and unscoped C++ enums are simply copied to the generated code and both the enum itself and its elements keep the same name as in the original code unless -namespace option is used or nspace feature is enabled, in which case the prefix corresponding to the specified namespace is used. @@ -356,7 +379,7 @@ For scoped C++11 enums, the enum name itself is used as an additional prefix.
-@@ -434,9 +457,11 @@ radius: 1.500000 area: 7.068583 -
To get a better idea of which typemap is used for which generated code, have a look at the following 'walk through'. @@ -514,7 +540,9 @@ To get a better idea of which typemap is used for which generated code, have a l Let's assume we have the following C++ interface file, we'd like to generate code for:
-%module example @@ -550,7 +578,8 @@ SomeIntTemplateClass * SomeIntTemplateClass_new(); void SomeIntTemplateClass_delete(SomeIntTemplateClass * carg1);
We'll examine the generation of the wrapper function first. @@ -693,7 +722,8 @@ replaced with either 0 or nothing, depending on whether the function has a non-void return value or not.
-Compared to the wrapper code generation, the header code is very simple. @@ -719,13 +749,15 @@ SomeIntTemplateClass * SomeIntTemplateClass_new(); void SomeIntTemplateClass_delete(SomeIntTemplateClass * carg1); -
Any call to a C++ function may throw an exception, which cannot be caught by C code. Instead, the special SWIG_CException_get_pending() function must be called to check for this. If it returns a non-null pointer, SWIG_CException_msg_get() can be called to retrieve the error message associated with the exception. Finally, SWIG_CException_reset_pending() must be called to free the exception object and reset the current pending exception. Note that exception handling is much simpler when using C++, rather than C, wrappers, see sections 36.6.2.
-When -c++ command line option is used (and -nocxx one is not), the header file generated by SWIG will also contain the declarations of C++ wrapper functions and classes mirroring the original API. All C++ wrappers are fully inline, i.e. don't need to be compiled separately, and are always defined inside the namespace (or nested namespaces) specified by -namespace command-line option or the namespace with the same name as the SWIG module name if this option is not specified. @@ -748,7 +780,8 @@ Other ones are due to things that could be supported but haven't been implemente
Generated C++ code can be customized by inserting custom code in the following sections: @@ -767,7 +800,8 @@ The following features are taken into account when generating C++ wrappers:
Exception handling in C++ is more natural, as the exceptions are re-thrown when using C++ wrappers and so can be caught, as objects of the special SWIG_CException type, using the usual try/catch statement. The objects of SWIG_CException class have code() and msg() methods, with the latter returning the error message associated with the exception. diff --git a/Doc/Manual/Contents.html b/Doc/Manual/Contents.html index fd2f034ed..ae81eb4ef 100644 --- a/Doc/Manual/Contents.html +++ b/Doc/Manual/Contents.html @@ -466,6 +466,10 @@
@@ -97,7 +97,7 @@ Also, this chapter is not meant to be a hand-holding tutorial. As a starting po you should probably look at one of SWIG's existing modules.
-@@ -127,7 +127,7 @@ obvious, but almost all SWIG directives as well as the low-level generation of wrapper code are driven by C++ datatypes.
-@@ -164,7 +164,7 @@ role in making the system work. For example, both typemaps and declaration anno based on pattern matching and interact heavily with the underlying type system.
-@@ -209,7 +209,7 @@ latter stage of compilation. The next few sections briefly describe some of these stages.
-@@ -290,7 +290,7 @@ been expanded as well as everything else that goes into the low-level construction of the wrapper code.
-@@ -391,7 +391,7 @@ returning a foo and taking types a and b as arguments).
-@@ -679,7 +679,7 @@ debug-module stage 1
@@ -698,7 +698,7 @@ that matches the name of the target language. For example, python:foo perl:foo.
-@@ -786,7 +786,7 @@ example.i:5. Previous declaration is foo_i(int )
@@ -841,7 +841,7 @@ For example, the exception code above is simply stored without any modifications.
-@@ -963,7 +963,7 @@ public : The role of these functions is described shortly.
-@@ -976,7 +976,7 @@ internal data structures, it may be useful to keep XML in the back of your mind as a model.
-@@ -1022,7 +1022,7 @@ typedef Hash Typetab; -
@@ -1168,7 +1168,7 @@ At most one of DOH_REPLACE_ANY and DOH_REPLACE_FIRST should be -
@@ -1253,7 +1253,7 @@ Returns the list of sorted hash table keys. -
@@ -1342,7 +1342,7 @@ If t is not a standard object, it is assumed to be a char * and is used to create a String object. -
@@ -1827,7 +1827,7 @@ the attribute is optional. Swig_restore() must always be called after function. -
@@ -1836,7 +1836,7 @@ pointers, references, and pointers to members. A detailed discussion of type theory is impossible here. However, let's cover the highlights.
-@@ -1937,7 +1937,7 @@ make the final type, the two parts are just joined together using string concatenation.
-@@ -2106,7 +2106,7 @@ Returns the prefix of a type. For example, if ty is ty is unmodified. -
@@ -2193,7 +2193,7 @@ Checks if ty is a varargs type. Checks if ty is a templatized type. -
@@ -2295,7 +2295,7 @@ Fully reduces ty according to typedef rules. Resulting datatype will consist only of primitive typenames. -
@@ -2332,7 +2332,7 @@ Literal y; // type = 'Literal', ltype='p.char' -
@@ -2394,7 +2394,7 @@ SWIG, but is most commonly associated with type-descriptor objects that appear in wrappers (e.g., SWIGTYPE_p_double). -
@@ -2493,7 +2493,7 @@ included. Used to emit prototypes. Returns the number of required (non-optional) arguments in p. -
@@ -2508,7 +2508,7 @@ describes the creation of a minimal Python module. You should be able to extra this to other languages.
-@@ -2518,7 +2518,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.
-@@ -2626,7 +2626,7 @@ that activates your module. For example, swig -python foo.i. The messages from your new module should appear.
-@@ -2685,7 +2685,7 @@ to mark the option as valid. If you forget to do this, SWIG will terminate wit unrecognized command line option error.
-@@ -2734,7 +2734,7 @@ an implementation file python.cxx and a configuration file python.swg.
-@@ -2792,7 +2792,7 @@ int Python::top(Node *n) { -
@@ -3247,7 +3247,7 @@ Discuss the kinds of functions typically needed for SWIG runtime support (e.g. the SWIG files that implement those functions.
-@@ -3266,7 +3266,7 @@ The following are the minimum that are usually supported: Please copy these and modify for any new language.
-@@ -3295,7 +3295,7 @@ during this process, see the section on .
-@@ -3354,7 +3354,7 @@ It is therefore essential that the runtime tests are written in a manner that di but error/exception out with an error message on stderr on failure.
-@@ -3548,7 +3548,7 @@ It can be run in the same way as the other language test-suites, replacing [lang The test cases used and the way it works is described in Examples/test-suite/errors/Makefile.in.
-@@ -3580,7 +3580,7 @@ Some topics that you'll want to be sure to address include: if available.
@@ -3605,7 +3605,7 @@ should be avoided as unlike the SWIG developers, users will never have consisten
-@@ -3614,7 +3614,7 @@ the Target language in This section provides more details on how this status is given.
-@@ -3661,7 +3661,7 @@ A target language is given the 'Supported' status when
@@ -3726,7 +3726,7 @@ Some minimum requirements and notes about languages with the 'Experimental' stat -
@@ -3790,7 +3790,7 @@ the existing tests.
-@@ -3818,7 +3818,7 @@ There are various command line options which can aid debugging a SWIG interface The complete list of command line options for SWIG are available by running swig -help.
-@@ -4226,7 +4226,7 @@ extern "X" { ... } declaration. -
diff --git a/Doc/Manual/Guile.html b/Doc/Manual/Guile.html index d40681587..ea8444270 100644 --- a/Doc/Manual/Guile.html +++ b/Doc/Manual/Guile.html @@ -456,16 +456,16 @@ mapping:
- MAP(SWIG_MemoryError, "swig-memory-error");
- MAP(SWIG_IOError, "swig-io-error");
- MAP(SWIG_RuntimeError, "swig-runtime-error");
- MAP(SWIG_IndexError, "swig-index-error");
- MAP(SWIG_TypeError, "swig-type-error");
- MAP(SWIG_DivisionByZero, "swig-division-by-zero");
- MAP(SWIG_OverflowError, "swig-overflow-error");
- MAP(SWIG_SyntaxError, "swig-syntax-error");
- MAP(SWIG_ValueError, "swig-value-error");
- MAP(SWIG_SystemError, "swig-system-error");
+ MAP(SWIG_MemoryError, "swig-memory-error");
+ MAP(SWIG_IOError, "swig-io-error");
+ MAP(SWIG_RuntimeError, "swig-runtime-error");
+ MAP(SWIG_IndexError, "swig-index-error");
+ MAP(SWIG_TypeError, "swig-type-error");
+ MAP(SWIG_DivisionByZero, "swig-division-by-zero");
+ MAP(SWIG_OverflowError, "swig-overflow-error");
+ MAP(SWIG_SyntaxError, "swig-syntax-error");
+ MAP(SWIG_ValueError, "swig-value-error");
+ MAP(SWIG_SystemError, "swig-system-error");
MAP(SWIG_NullReferenceError, "swig-null-reference-error");
-
Change the access modifier to public for the derived class by adding the following before SWIG parses the DerivedClass:
%feature("java:methodmodifiers") DerivedClass::baseMethod2 "public"
-
Simply ignore the method in the derived class altogether as it cannot be used as a protected method in Java as the C++ design intended:
%ignore DerivedClass::baseMethod2;
SWIG has some support for complex floating types. By default the keyword _Complex is understood by the parser but complex is not diff --git a/Doc/Manual/Mzscheme.html b/Doc/Manual/Mzscheme.html index 070f9140c..efbaf383b 100644 --- a/Doc/Manual/Mzscheme.html +++ b/Doc/Manual/Mzscheme.html @@ -8,7 +8,7 @@
-@@ -66,7 +66,7 @@ Then in scheme, you can use regular struct access procedures like
@@ -167,7 +167,7 @@ Some points of interest:
diff --git a/Doc/Manual/Ocaml.html b/Doc/Manual/Ocaml.html index 094d97df5..946f9f694 100644 --- a/Doc/Manual/Ocaml.html +++ b/Doc/Manual/Ocaml.html @@ -7,7 +7,7 @@
-@@ -105,7 +105,7 @@ file Examples/Makefile illustrate how to compile and link SWIG modules that will be loaded dynamically. This has only been tested on Linux so far.
-@@ -128,7 +128,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).
-@@ -165,7 +165,7 @@ in C++ mode, you must:
@@ -241,7 +241,7 @@ let b = C_string (getenv "PATH") -
@@ -255,7 +255,7 @@ option to build your functions into the primitive list. This option is not needed when you build native code.
-@@ -275,7 +275,7 @@ liberal with pointer types may not compile under the C++ compiler. Most code meant to be compiled as C++ will not have problems.
-@@ -375,7 +375,7 @@ value items pass through directly, but you must make your own type signature for a function that uses value in this way.
-@@ -409,7 +409,7 @@ it describes the output SWIG will generate for class definitions. -
@@ -472,7 +472,7 @@ val x : Enum_test.c_obj = C_enum `a -
@@ -485,10 +485,10 @@ functions imported from different modules. You must convert values to master values using the swig_val function before sharing them with another module.
-@@ -509,7 +509,7 @@ arrays of simple types with known bounds in your code, but this only works for arrays whose bounds are completely specified.
-@@ -522,7 +522,7 @@ SWIG can't predict which of these methods will be used in the array, so you have to specify it for yourself in the form of a typemap.
-@@ -536,7 +536,7 @@ Consider writing an object when the ending condition of your array is complex, such as using a required sentinel, etc.
-@@ -587,7 +587,7 @@ void printfloats( float *tab, int len ); -
@@ -630,7 +630,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the returned value for the same object.
-@@ -710,7 +710,7 @@ baz # -
@@ -739,7 +739,7 @@ public: }; -
@@ -756,7 +756,7 @@ $ ocamlmktop -custom swig.cmo -I `camlp4 -where` \ -L$QTPATH/lib -cclib -lqt
@@ -783,10 +783,10 @@ Assuming you have a working installation of QT, you will see a window containing the string "hi" in a button. -39.2.5 Director Classes
+40.2.5 Director Classes
-39.2.5.1 Director Introduction
+40.2.5.1 Director Introduction
@@ -813,7 +813,7 @@ class foo { };
@@ -841,7 +841,7 @@ In this example, I'll examine the objective caml code involved in providing an overloaded class. This example is contained in Examples/ocaml/shapes.
-