diff options
| author | Karl Wette <karl.wette@gmail.com> | 2014-10-04 18:16:17 +0200 |
|---|---|---|
| committer | Karl Wette <karl.wette@gmail.com> | 2014-10-04 19:19:32 +0200 |
| commit | 56fefcc7e0adb2a4a25a30280047c1d7c097454f (patch) | |
| tree | bceda16934c32d2e0d442dc83c95def694f533e2 /Doc/Manual/Octave.html | |
| parent | bf12d76d037dddb68c294cd77c3ad1f6b6d2e985 (diff) | |
| download | swig-56fefcc7e0adb2a4a25a30280047c1d7c097454f.tar.gz | |
Octave: whitespace/style cleanup of Doc/Manual/Octave.html
Diffstat (limited to 'Doc/Manual/Octave.html')
| -rw-r--r-- | Doc/Manual/Octave.html | 453 |
1 files changed, 300 insertions, 153 deletions
diff --git a/Doc/Manual/Octave.html b/Doc/Manual/Octave.html index 9c3489fb8..e48083afd 100644 --- a/Doc/Manual/Octave.html +++ b/Doc/Manual/Octave.html @@ -5,7 +5,6 @@ <link rel="stylesheet" type="text/css" href="style.css"> </head> - <body bgcolor="#ffffff"> <H1><a name="Octave"></a>32 SWIG and Octave</H1> @@ -43,29 +42,29 @@ </div> <!-- INDEX --> - - <p> - Octave is a high-level language intended for numerical programming that is mostly compatible with MATLAB. -More information can be found at <a href="http://www.gnu.org/software/octave/">Octave web site</a>. +Octave is a high-level language intended for numerical programming that is +mostly compatible with MATLAB. More information can be found +at <a href="http://www.gnu.org/software/octave/">Octave web site</a>. </p> <p> - This chapter is intended to give an introduction to using the module. You should also read the SWIG documentation that is not specific to Octave. -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). +This chapter is intended to give an introduction to using the module. You +should also read the SWIG documentation that is not specific to Octave. 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). </p> <H2><a name="Octave_nn2"></a>32.1 Preliminaries</H2> - <p> -As of SWIG 3.0.0, the Octave module has been tested with Octave versions 3.0.5, 3.2.4, 3.4.3, 3.6.4, and 3.8.0. -Use of Octave versions older than 3.x.x is not recommended, as these versions are no longer tested with SWIG. +As of SWIG 3.0.0, the Octave module has been tested with Octave versions 3.0.5, +3.2.4, 3.4.3, 3.6.4, and 3.8.0. Use of Octave versions older than 3.x.x is not +recommended, as these versions are no longer tested with SWIG. </p> <H2><a name="Octave_nn3"></a>32.2 Running SWIG</H2> - <p> Let's start with a very simple SWIG interface file, example.i: </p> @@ -76,54 +75,67 @@ Let's start with a very simple SWIG interface file, example.i: #include "example.h" %} int gcd(int x, int y); -extern double Foo; </pre></div> +extern double Foo; +</pre></div> <p> -To build an Octave module when wrapping C code, run SWIG using the <tt>-octave</tt> option: +To build an Octave module when wrapping C code, run <tt>swig</tt> using +the <tt>-octave</tt> option: </p> -<div class="shell"><pre>$ swig -octave -o example_wrap.cpp example.i </pre></div> +<div class="shell"><pre> +$ swig -octave -o example_wrap.cpp example.i +</pre></div> <p> The <tt>-c++</tt> option is also required when wrapping C++ code: </p> - -<div class="shell"><pre>$ swig -octave -c++ -o example_wrap.cpp example.i </pre></div> +<div class="shell"><pre> +$ swig -octave -c++ -o example_wrap.cpp example.i +</pre></div> <p> -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. +This creates a C++ source file <em>example_wrap.cpp</em>. 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. </p> <H3><a name="Octave_nn4"></a>32.2.1 Command-line options</H3> - <p> -The swig command line has a number of options you can use, like to redirect its output. Use <tt>swig -help</tt> to learn about these. -Options specific to the Octave module are: +The <tt>swig</tt> command line has a number of options you can use, like to +redirect its output. Use <tt>swig -help</tt> to learn about these. Options +specific to the Octave module are: </p> <div class="shell"> <pre>$ swig -octave -help ... Octave Options (available with -octave) - -globals <em>name</em> - Set <em>name</em> used to access C global variables [default: 'cvar'] - Use '.' to load C global variables into module namespace - -opprefix <em>str</em> - Prefix <em>str</em> for global operator functions [default: 'op_'] + -globals <name> - Set <name> used to access C global variables [default: 'cvar'] + Use '.' to load C global variables into module namespace + -opprefix <str> - Prefix <str> for global operator functions [default: 'op_'] </pre></div> <p> -The <em>-globals</em> option sets the name of the variable which is the namespace for C global variables exported by the module. -The special name "." loads C global variables into the module namespace, i.e. alongside C functions and structs exported by the module. -The <em>-opprefix</em> options sets the prefix of the names of global/friend <a href="#Octave_nn18">operator</a> functions. +The <tt>-globals</tt> option sets the name of the variable which is the +namespace for C global variables exported by the module. The special +name <em>.</em> loads C global variables into the module namespace, +i.e. alongside C functions and structs exported by the module. +The <tt>-opprefix</tt> options sets the prefix of the names of +global/friend <a href="#Octave_nn18">operator</a> functions. </p> <H3><a name="Octave_nn5"></a>32.2.2 Compiling a dynamic module</H3> - <p> -Octave modules are DLLs/shared objects having the ".oct" suffix. -Building an oct file is usually done with the mkoctfile command (either within Octave itself, or from the shell). For example, +Octave modules are DLLs/shared objects having the <em>.oct</em> suffix. +Building an <em>.oct</em> file is usually done with the <tt>mkoctfile</tt> +command (either within Octave itself, or from the shell). For example, </p> <div class="shell"><pre> @@ -132,28 +144,30 @@ $ mkoctfile example_wrap.cpp example.c </pre></div> <p> - where "example.c" is the file containing the gcd() implementation. +where <em>example.c</em> is the file containing the gcd() implementation. </p> <p> - mkoctfile can also be used to extract the build parameters required to invoke the compiler and linker yourself. See the Octave manual and mkoctfile man page. +<tt>mkoctfile</tt> can also be used to extract the build parameters required to +invoke the compiler and linker yourself. See the Octave manual +and <tt>mkoctfile</tt> man page. </p> <p> - mkoctfile will produce "swigexample.oct", which contains the compiled extension module. Loading it into Octave is then a matter of invoking +<tt>mkoctfile</tt> will produce <em>swigexample.oct</em>, which contains the +compiled extension module. Loading it into Octave is then a matter of invoking </p> - <div class="targetlang"><pre>octave:1> swigexample</pre></div> +<div class="targetlang"><pre>octave:1> swigexample +</pre></div> <H3><a name="Octave_nn6"></a>32.2.3 Using your module</H3> - <p> -Assuming all goes well, you will be able to do this: - <br> +Assuming all goes well, you will be able to do this: </p> - <div class="targetlang"><pre>$ octave -q +<div class="targetlang"><pre>$ octave -q octave:1> swigexample octave:2> swigexample.gcd(4,6) ans = 2 @@ -161,20 +175,27 @@ octave:3> swigexample.cvar.Foo ans = 3 octave:4> swigexample.cvar.Foo=4; octave:5> swigexample.cvar.Foo -ans = 4 </pre></div> +ans = 4 +</pre></div> <H2><a name="Octave_nn7"></a>32.3 A tour of basic C/C++ wrapping</H2> - <H3><a name="Octave_nn8"></a>32.3.1 Modules</H3> - <p> -The SWIG module directive specifies the name of the Octave module. If you specify "module swigexample", then in Octave everything in the module will be accessible under "swigexample", as in the above example. When choosing a module name, make sure you don't use the same name as a built-in Octave command or standard module name. +The SWIG <tt>module</tt> directive specifies the name of the Octave module. If +you specify <tt>module swigexample</tt>, then in Octave everything in the module +will be accessible under <tt>swigexample</tt>, as in the above example. When +choosing a module name, make sure you don't use the same name as a built-in +Octave command or standard module name. </p> <p> -When Octave is asked to invoke <tt>swigexample</tt>, it will try to find the ".m" or ".oct" file that defines the function "swigexample". You therefore need to make sure that "swigexample.oct" is in Octave's search path, which can be specified with the environment variable "OCTAVE_PATH". +When Octave is asked to invoke <tt>swigexample</tt>, it will try to find +the <em>.m</em> or <em>.oct</em> file that defines the +function <tt>swigexample</tt>. You therefore need to make sure +that <em>swigexample.oct</em> is in Octave's search path, which can be specified +with the environment variable <tt>OCTAVE_PATH</tt>. </p> <p> @@ -193,8 +214,9 @@ ans = 4 </pre></div> <p> -Modules can also be loaded from within functions, even before being loaded in the base context. -If the module is also used in the base context, however, it must first be loaded again: +Modules can also be loaded from within functions, even before being loaded in +the base context. If the module is also used in the base context, however, it +must first be loaded again: </p> <div class="targetlang"><pre> @@ -213,112 +235,135 @@ ans = 2 <H3><a name="Octave_nn9"></a>32.3.2 Functions</H3> - <p> -Global functions are wrapped as new Octave built-in functions. For example, +Global functions are wrapped as new Octave built-in functions. For example, </p> - <div class="code"><pre>%module swigexample -int fact(int n); </pre></div> +<div class="code"><pre> +%module swigexample +int fact(int n); +</pre></div> <p> - creates a built-in function <tt>swigexample.fact(n)</tt> that works exactly like you think it does: +creates a built-in function <tt>swigexample.fact(n)</tt> that works exactly like +you think it does: </p> - <div class="targetlang"><pre>octave:1> swigexample.fact(4) -24 </pre></div> +<div class="targetlang"><pre>octave:1> swigexample.fact(4) +24 +</pre></div> <H3><a name="Octave_nn10"></a>32.3.3 Global variables</H3> - <p> - Global variables are a little special in Octave. Given a global variable: +Global variables are a little special in Octave. Given a global variable: </p> -<div class="code"><pre>%module swigexample +<div class="code"><pre> +%module swigexample extern double Foo; </pre></div> <p> - To expose variables, SWIG actually generates two functions, to get and set the value. In this case, Foo_set and Foo_set would be generated. SWIG then automatically calls these functions when you get and set the variable-- in the former case creating a local copy in the interpreter of the C variables, and in the latter case copying an interpreter variables onto the C variable. +To expose variables, SWIG actually generates two functions, to get and set the +value. In this case, <tt>Foo_set</tt> and <tt>Foo_set</tt> would be +generated. SWIG then automatically calls these functions when you get and set +the variable -- in the former case creating a local copy in the interpreter of +the C variables, and in the latter case copying an interpreter variables onto +the C variable. </p> - <div class="targetlang"><pre>octave:1> swigexample; +<div class="targetlang"><pre>octave:1> swigexample; octave:2> c=swigexample.cvar.Foo c = 3 octave:3> swigexample.cvar.Foo=4; octave:4> c c = 3 octave:5> swigexample.cvar.Foo -ans = 4</pre></div> +ans = 4 +</pre></div> <p> -If a variable is marked with the %immutable directive then any attempts to set this variable will cause an Octave error. Given a global variable: +If a variable is marked with the <tt>%immutable</tt> directive then any attempts +to set this variable will cause an Octave error. Given a global variable: </p> - <div class="code"><pre>%module swigexample +<div class="code"><pre> +%module swigexample %immutable; extern double Foo; %mutable; </pre></div> <p> - SWIG will allow the reading of <tt>Foo</tt> but when a set attempt is made, an error function will be called. +SWIG will allow the reading of <tt>Foo</tt> but when a set attempt is made, an +error function will be called. </p> - <div class="targetlang"><pre>octave:1> swigexample +<div class="targetlang"><pre>octave:1> swigexample octave:2> swigexample.Foo=4 error: attempt to set immutable member variable error: assignment failed, or no method for `swig_type = scalar' -error: evaluating assignment expression near line 2, column 12 </pre></div> +error: evaluating assignment expression near line 2, column 12 +</pre></div> <p> - It is possible to add new functions or variables to the module. This also allows the user to rename/remove existing functions and constants (but not linked variables, mutable or immutable). Therefore users are recommended to be careful when doing so. +It is possible to add new functions or variables to the module. This also allows +the user to rename/remove existing functions and constants (but not linked +variables, mutable or immutable). Therefore users are recommended to be careful +when doing so. </p> - <div class="targetlang"><pre>octave:1> swigexample; +<div class="targetlang"><pre>octave:1> swigexample; octave:2> swigexample.PI=3.142; octave:3> swigexample.PI -ans = 3.1420 </pre></div> +ans = 3.1420 +</pre></div> <H3><a name="Octave_nn11"></a>32.3.4 Constants and enums</H3> - <p> - Because Octave doesn't really have the concept of constants, C/C++ constants are not really constant in Octave. They are actually just a copy of the value into the Octave interpreter. Therefore they can be changed just as any other value. For example given some constants: +Because Octave doesn't really have the concept of constants, C/C++ constants are +not really constant in Octave. They are actually just a copy of the value into +the Octave interpreter. Therefore they can be changed just as any other +value. For example given some constants: </p> - <div class="code"><pre>%module swigexample +<div class="code"><pre> +%module swigexample %constant int ICONST=42; #define SCONST "Hello World" enum Days{SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY}; </pre></div> <p> - This is 'effectively' converted into the following Octave code: +This is effectively converted into the following Octave code: </p> - <div class="targetlang"><pre>swigexample.ICONST=42 +<div class="targetlang"><pre>swigexample.ICONST=42 swigexample.SCONST="Hello World" swigexample.SUNDAY=0 -.... </pre></div> +.... +</pre></div> <H3><a name="Octave_nn12"></a>32.3.5 Pointers</H3> - <p> - C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the <file.h> interface: - C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the <file.h> interface: +C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem +working with incomplete type information. Given a wrapping of +the <em>file.h</em> interface: </p> -<div class="code"><pre>%module swigexample +<div class="code"><pre> +%module swigexample FILE *fopen(const char *filename, const char *mode); int fputs(const char *, FILE *); int fclose(FILE *); </pre></div> <p> -When wrapped, you will be able to use the functions in a natural way from Octave. For example: +When wrapped, you will be able to use the functions in a natural way from +Octave. For example: </p> <div class="targetlang"><pre> @@ -329,7 +374,7 @@ octave:4> swigexample.fclose(f); </pre></div> <p> - Simply printing the value of a wrapped C++ type will print its typename. E.g., +Simply printing the value of a wrapped C++ type will print its typename, e.g.: </p> <div class="targetlang"><pre>octave:1> swigexample; @@ -339,55 +384,67 @@ f = { _p_FILE, ptr = 0x9b0cd00 -} </pre></div> +} +</pre></div> <p> - As the user of the pointer, you are responsible for freeing it, or closing any resources associated with it (just as you would in a C program). This does not apply so strictly to classes and structs (see below). +As the user of the pointer, you are responsible for freeing it, or closing any +resources associated with it (just as you would in a C program). This does not +apply so strictly to classes and structs (see below). </p> - <div class="targetlang"><pre>octave:1> swigexample; +<div class="targetlang"><pre>octave:1> swigexample; 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 </pre></div> +error: evaluating assignment expression near line 2, column 2 +</pre></div> <H3><a name="Octave_nn13"></a>32.3.6 Structures and C++ classes</H3> - <p> - SWIG wraps C structures and C++ classes by using a special Octave type called a <tt>swig_ref</tt>. A <tt>swig_ref</tt> contains a reference to one or more instances of C/C++ objects, or just the type information for an object. -For each wrapped structure and class, a <tt>swig_ref</tt> will be exposed that has the name of the type. When invoked as a function, it creates a new object of its type and returns a <tt>swig_ref</tt> that points to that instance. This provides a very natural interface. For example, +SWIG wraps C structures and C++ classes by using a special Octave type called +a <tt>swig_ref</tt>. A <tt>swig_ref</tt> contains a reference to one or more +instances of C/C++ objects, or just the type information for an object. For +each wrapped structure and class, a <tt>swig_ref</tt> will be exposed that has +the name of the type. When invoked as a function, it creates a new object of its +type and returns a <tt>swig_ref</tt> that points to that instance. This provides +a very natural interface. For example, </p> - <div class="code"><pre>struct Point{ +<div class="code"><pre> +struct Point{ int x,y; }; </pre></div> <p> - is used as follows: +is used as follows: </p> - <div class="targetlang"> - <pre>octave:1> swigexample; +<div class="targetlang"><pre>octave:1> swigexample; octave:2> p=swigexample.Point(); octave:3> p.x=3; octave:4> p.y=5; octave:5> p.x, p.y ans = 3 -ans = 5 +ans = 5 </pre></div> + <p> In C++, invoking the type object in this way calls the object's constructor. -<tt>swig_ref</tt> objects can also be acquired by having a wrapped function return a pointer, reference, or value of a non-primitive type. +<tt>swig_ref</tt> objects can also be acquired by having a wrapped function +return a pointer, reference, or value of a non-primitive type. </p> -<p> -The swig_ref type handles indexing operations such that usage maps closely to what you would have in C/C++. -Structure members are accessed as in the above example, by calling set and get methods for C++ variables. -Methods also work as expected. For example, code wrapped in the following way +<p> +The <tt>swig_ref</tt> type handles indexing operations such that usage maps +closely to what you would have in C/C++. Structure members are accessed as in +the above example, by calling set and get methods for C++ variables. Methods +also work as expected. For example, code wrapped in the following way </p> - <div class="code"><pre>class Point{ +<div class="code"><pre> +class Point{ public: int x,y; Point(int _x,int _y) : x(_x),y(_y) {} @@ -399,34 +456,41 @@ public: } }; </pre></div> + <p> can be used from Octave like this </p> - <div class="targetlang"> - <pre>octave:1> swigexample; + +<div class="targetlang"><pre>octave:1> swigexample; octave:2> p1=swigexample.Point(3,5); octave:3> p2=swigexample.Point(1,2); octave:4> p1.distance(p2) ans = 3.6056 </pre></div> + <p> -By using the <tt>swig_this()</tt> and <tt>swig_type()</tt> functions, one can discover the pointers to and types of the underlying C/C++ object. +By using the <tt>swig_this()</tt> and <tt>swig_type()</tt> functions, one can +discover the pointers to and types of the underlying C/C++ object. </p> - <div class="targetlang"> - <pre> +<div class="targetlang"><pre> octave:5> swig_this(p1) ans = 162504808 octave:6> swig_type(p1) ans = Point </pre></div> + <p> -Note that <tt>swig_ref</tt> is a reference-counted pointer to a C/C++ object/type, and as such has pass-by-reference semantics. For example if one has a allocated a single object but has two <tt>swig_ref</tt>'s pointing to it, modifying the object through either of them will change the single allocated object. -This differs from the usual pass-by-value (copy-on-write) semantics that Octave maintains for built-in types. For example, in the following snippet, modifying <tt>b</tt> does not modify <tt>a</tt>, +Note that <tt>swig_ref</tt> is a reference-counted pointer to a C/C++ +object/type, and as such has pass-by-reference semantics. For example if one has +a allocated a single object but has two <tt>swig_ref</tt>'s pointing to it, +modifying the object through either of them will change the single allocated +object. This differs from the usual pass-by-value (copy-on-write) semantics +that Octave maintains for built-in types. For example, in the following snippet, +modifying <tt>b</tt> does not modify <tt>a</tt>, </p> - <div class="targetlang"> - <pre> +<div class="targetlang"><pre> octave:7> a=struct('x',4) a = { @@ -452,12 +516,12 @@ a = x = 4 } </pre></div> + <p> However, when dealing with wrapped objects, one gets the behavior </p> - <div class="targetlang"> - <pre> +<div class="targetlang"><pre> octave:2> a=Point(3,5) a = @@ -482,41 +546,58 @@ ans = 1 </pre></div> <p> -Depending on the ownership setting of a <tt>swig_ref</tt>, it may call C++ destructors when its reference count goes to zero. See the section on memory management below for details. +Depending on the ownership setting of a <tt>swig_ref</tt>, it may call C++ +destructors when its reference count goes to zero. See the section on memory +management below for details. </p> <H3><a name="Octave_nn15"></a>32.3.7 C++ inheritance</H3> - <p> -Single and multiple inheritance are fully supported. The <tt>swig_ref</tt> type carries type information along with any C++ object pointer it holds. -This information contains the full class hierarchy. When an indexing operation (such as a method invocation) occurs, -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 <tt>swig_ref</tt>. +Single and multiple inheritance are fully supported. The <tt>swig_ref</tt> type +carries type information along with any C++ object pointer it holds. This +information contains the full class hierarchy. When an indexing operation (such +as a method invocation) occurs, 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 <tt>swig_ref</tt>. </p> <H3><a name="Octave_nn17"></a>32.3.8 C++ overloaded functions</H3> - <p> -Overloaded functions are supported, and handled as in other modules. That is, -each overload is wrapped separately (under internal names), and a dispatch function is also emitted under the external/visible name. -The dispatch function selects which overload to call (if any) based on the passed arguments. -<tt>typecheck</tt> typemaps are used to analyze each argument, as well as assign precedence. See the chapter on typemaps for details. +Overloaded functions are supported, and handled as in other modules. That is, +each overload is wrapped separately (under internal names), and a dispatch +function is also emitted under the external/visible name. The dispatch function +selects which overload to call (if any) based on the passed arguments. +<tt>typecheck</tt> typemaps are used to analyze each argument, as well as assign +precedence. See the chapter on typemaps for details. </p> <H3><a name="Octave_nn18"></a>32.3.9 C++ operators</H3> - <p> C++ operator overloading is supported, in a way similar to other modules. -The <tt>swig_ref</tt> type supports all unary and binary operators between itself and all other types that exist in the system at module load time. When an operator is used (where one of the operands is a <tt>swig_ref</tt>), the runtime routes the call to either a member function of the given object, or to a global function whose named is derived from the types of the operands (either both or just the lhs or rhs). +The <tt>swig_ref</tt> type supports all unary and binary operators between +itself and all other types that exist in the system at module load time. When an +operator is used (where one of the operands is a <tt>swig_ref</tt>), the runtime +routes the call to either a member function of the given object, or to a global +function whose named is derived from the types of the operands (either both or +just the lhs or rhs). </p> + <p> -For example, if <tt>a</tt> and <tt>b</tt> are SWIG variables in Octave, <tt>a+b</tt> becomes <tt>a.__add(b)</tt>. The wrapper is then free to implement __add to do whatever it wants. A wrapper may define the <tt>__add</tt> function manually, %rename some other function to it, or %rename a C++ operator to it. +For example, if <tt>a</tt> and <tt>b</tt> are SWIG variables in +Octave, <tt>a+b</tt> becomes <tt>a.__add(b)</tt>. The wrapper is then free to +implement __add to do whatever it wants. A wrapper may define the <tt>__add</tt> +function manually, <tt>%rename</tt> some other function to it, +or <tt>%rename</tt> a C++ operator to it. </p> + <p> -By default the C++ operators are renamed to their corresponding Octave operators. So without doing any work, the following interface +By default the C++ operators are renamed to their corresponding Octave +operators. So without doing any work, the following interface </p> + <div class="code"><pre> %inline { struct A { @@ -528,16 +609,20 @@ struct A { }; } </pre></div> + <p> is usable from Octave like this: </p> + <div class="targetlang"><pre> a=A(2), b=A(3), c=a+b assert(c.value==5); </pre></div> + <p> Octave operators are mapped in the following way: </p> + <div class="code"><pre> __brace a{args} __brace_asgn a{args} = rhs @@ -572,9 +657,11 @@ __el_ldiv a .\ b __el_and a & b __el_or a | b </pre></div> + <p> On the C++ side, the default mappings are as follows: </p> + <div class="code"><pre> %rename(__add) *::operator+; %rename(__add) *::operator+(); @@ -605,18 +692,21 @@ On the C++ side, the default mappings are as follows: </pre></div> <p> -Octave can also utilise friend (i.e. non-member) operators with a simple %rename: see the example in the Examples/octave/operator directory. +Octave can also utilise friend (i.e. non-member) operators with a simple +<tt>%rename</tt>: see the example in the Examples/octave/operator directory. </p> <H3><a name="Octave_nn19"></a>32.3.10 Class extension with %extend</H3> - <p> -The %extend directive works the same as in other modules. -</p> -<p> -You can use it to define special behavior, like for example defining Octave operators not mapped to C++ operators, or defining certain Octave mechanisms such as how an object prints. For example, the <tt>octave_value::{is_string,string_value,print}</tt> functions are routed to a special method <tt>__str</tt> that can be defined inside an %extend. +The <tt>%extend</tt> directive works the same as in other modules. You can use +it to define special behavior, like for example defining Octave operators not +mapped to C++ operators, or defining certain Octave mechanisms such as how an +object prints. For example, +the <tt>octave_value::{is_string,string_value,print}</tt> functions are routed +to a special method <tt>__str</tt> that can be defined inside an <tt>extend></tt>. </p> + <div class="code"><pre> %extend A { string __str() { @@ -626,9 +716,11 @@ string __str() { } } </pre></div> + <p> Then in Octave one gets, </p> + <div class="targetlang"><pre> octave:1> a=A(4); octave:2> a @@ -638,15 +730,18 @@ octave:3> printf("%s\n",a); octave:4> a.__str() 4 </pre></div> -<H3><a name="Octave_nn20"></a>32.3.11 C++ templates</H3> +<H3><a name="Octave_nn20"></a>32.3.11 C++ templates</H3> <p> -C++ class and function templates are fully supported as in other modules, in that the %template directive may used to create explicit instantiations of templated types. -For example, function templates can be instantiated as follows: +C++ class and function templates are fully supported as in other modules, in +that the <tt>template></tt> directive may used to create explicit instantiations of +templated types. For example, function templates can be instantiated as +follows: </p> -<div class="code"><pre>%module swigexample +<div class="code"><pre> +%module swigexample %inline { template<class __scalar> __scalar mul(__scalar a,__scalar b) { @@ -657,6 +752,7 @@ For example, function templates can be instantiated as follows: %template(mul) mul<std::complex<double> > %template(mul) mul<double> </pre></div> + <p> and then used from Octave </p> @@ -674,7 +770,8 @@ ans = 22 + 46i Similarly, class templates can be instantiated as in the following example, </p> -<div class="code"><pre>%module swigexample +<div class="code"><pre> +%module swigexample %include <std_complex.i> %include <std_string.i> %inline { @@ -714,26 +811,30 @@ ans = (7,4) </pre></div> - <H3><a name="Octave_nn21"></a>32.3.12 C++ Smart Pointers</H3> - <p> C++ smart pointers are fully supported as in other modules. </p> <H3><a name="Octave_nn22"></a>32.3.13 Directors (calling Octave from C++ code)</H3> - <p> -There is full support for SWIG Directors, which permits Octave code to subclass C++ classes, and implement their virtual methods. +There is full support for SWIG directors, which permits Octave code to subclass +C++ classes, and implement their virtual methods. </p> + <p> -Octave has no direct support for object oriented programming, however the <tt>swig_ref</tt> type provides some of this support. You can manufacture a <tt>swig_ref</tt> using the <tt>subclass</tt> function (provided by the SWIG/Octave runtime). +Octave has no direct support for object oriented programming, however +the <tt>swig_ref</tt> type provides some of this support. You can manufacture +a <tt>swig_ref</tt> using the <tt>subclass</tt> function (provided by the +SWIG/Octave runtime). </p> + <p> For example, </p> + <div class="targetlang"><pre> octave:1> a=subclass(); octave:2> a.my_var = 4; @@ -741,9 +842,12 @@ octave:3> a.my_method = @(self) printf("my_var = ",self.my_var); octave:4> a.my_method(); my_var = 4 </pre></div> + <p> -<tt>subclass()</tt> can also be used to subclass one or more C++ types. Suppose you have an interface defined by +<tt>subclass()</tt> can also be used to subclass one or more C++ types. Suppose +you have an interface defined by </p> + <div class="code"><pre> %inline { class A { @@ -757,9 +861,11 @@ void call_your_method(A& a) { } } </pre></div> + <p> Then from Octave you can say: </p> + <div class="targetlang"><pre> octave:1> B=@() subclass(A(),@my_method); octave:2> function my_method(self) @@ -768,30 +874,46 @@ octave:4> end octave:5> call_your_method(B()); octave-side routine called </pre></div> + <p> or more concisely, </p> + <div class="targetlang"><pre> octave:1> B=@() subclass(A(),'my_method',@(self) printf("octave-side routine called\n")); octave:2> call_your_method(B()); octave-side routine called </pre></div> + <p> -Note that you have to enable directors via the %feature directive (see other modules for this). +Note that you have to enable directors via the <tt>%feature</tt> directive (see +other modules for this). </p> + <p> -<tt>subclass()</tt> will accept any number of C++ bases or other <tt>subclass()</tt>'ed objects, <tt>(string,octave_value)</tt> pairs, and <tt>function_handles</tt>. In the first case, these are taken as base classes; in the second case, as named members (either variables or functions, depending on whether the given value is a function handle); in the third case, as member functions whose name is taken from the given function handle. E.g., +<tt>subclass()</tt> will accept any number of C++ bases or +other <tt>subclass()</tt>'ed objects, <tt>(string,octave_value)</tt> pairs, +and <tt>function_handles</tt>. In the first case, these are taken as base +classes; in the second case, as named members (either variables or functions, +depending on whether the given value is a function handle); in the third case, +as member functions whose name is taken from the given function handle, e.g.: </p> + <div class="targetlang"><pre> octave:1> B=@(some_var=2) subclass(A(),'some_var',some_var,@some_func,'another_func', @(self) do_stuff()) </pre></div> + <p> -You can also assign non-C++ member variables and functions after construct time. There is no support for non-C++ static members. +You can also assign non-C++ member variables and functions after construction +time. There is no support for non-C++ static members. </p> + <p> -There is limited support for explicitly referencing C++ bases. So, in the example above, we could have +There is limited support for explicitly referencing C++ bases. So, in the +example above, we could have </p> + <div class="targetlang"><pre> octave:1> B=@() subclass(A(),@my_method); octave:2> function my_method(self) @@ -805,19 +927,29 @@ octave-side routine called <H3><a name="Octave_nn23"></a>32.3.14 Threads</H3> - <p> -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. +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. </p> <H3><a name="Octave_nn24"></a>32.3.15 Memory management</H3> - <p> -As noted above, <tt>swig_ref</tt> represents a reference counted pointer to a C/C++-side object. It also contains a flag indicating whether Octave or the C/C++ code owns the object. If Octave owns it, any destructors will be called when the reference count reaches zero. If the C/C++ side owns the object, then destructors will not be called when the reference count goes to zero. +As noted above, <tt>swig_ref</tt> represents a reference counted pointer to a +C/C++-side object. It also contains a flag indicating whether Octave or the +C/C++ code owns the object. If Octave owns it, any destructors will be called +when the reference count reaches zero. If the C/C++ side owns the object, then +destructors will not be called when the reference count goes to zero. </p> + <p> For example, +</p> + <div class="code"><pre> %inline { class A { @@ -827,9 +959,11 @@ public: }; } </pre></div> + <p> -Would produce this behavior in Octave: +would produce this behavior in Octave: </p> + <div class="targetlang"><pre> octave:1> a=A(); A constructing @@ -838,36 +972,49 @@ octave:3> clear a; octave:4> b=4; A destructing </pre></div> + <p> -The %newobject directive may be used to control this behavior for pointers returned from functions. +The <tt>%newobject</tt> directive may be used to control this behavior for +pointers returned from functions. +</p> + <p> -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/<tt>subclass()</tt>'ing). +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/<tt>subclass()</tt>'ing). </p> <H3><a name="Octave_nn25"></a>32.3.16 STL support</H3> - <p> Various STL library files are provided for wrapping STL containers. </p> <H3><a name="Octave_nn26"></a>32.3.17 Matrix typemaps</H3> - <p> -Octave provides a rich set of classes for dealing with matrices. Currently there are no built-in typemaps to deal with those. However, these are relatively straight forward for users to add themselves (see the docs on typemaps). Without much work (a single typemap decl-- say, 5 lines of code in the interface file), it would be possible to have a function +Octave provides a rich set of classes for dealing with matrices. Currently there +are no built-in typemaps to deal with those. However, these are relatively +straight forward for users to add themselves (see the docs on typemaps). Without +much work (a single typemap decl -- say, 5 lines of code in the interface file), +it would be possible to have a function </p> + <div class="code"><pre> double my_det(const double* mat,int m,int n); </pre></div> + <p> that is accessed from Octave as, </p> + <div class="targetlang"><pre> octave:1> my_det(rand(4)); ans = -0.18388 </pre></div> - <tt><br></tt> - </body> +</body> </html> |