summaryrefslogtreecommitdiff
path: root/Doc/Manual/Lua.html
diff options
context:
space:
mode:
authorWilliam S Fulton <wsf@fultondesigns.co.uk>2008-03-02 22:13:14 +0000
committerWilliam S Fulton <wsf@fultondesigns.co.uk>2008-03-02 22:13:14 +0000
commitf74c2b9eded7c66411c65920cbefd07ba0d03d33 (patch)
tree3297f632fd0c45a6c50a7f020c9fd20864cd4aad /Doc/Manual/Lua.html
parent2ded60495f35bd8e8757c609be208f79d15a1153 (diff)
downloadswig-f74c2b9eded7c66411c65920cbefd07ba0d03d33.tar.gz
Add in Octave and R sections
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@10292 626c5289-ae23-0410-ae9c-e8d60b6d4f22
Diffstat (limited to 'Doc/Manual/Lua.html')
-rw-r--r--Doc/Manual/Lua.html52
1 files changed, 26 insertions, 26 deletions
diff --git a/Doc/Manual/Lua.html b/Doc/Manual/Lua.html
index 3f56be1fc..635d9b4dc 100644
--- a/Doc/Manual/Lua.html
+++ b/Doc/Manual/Lua.html
@@ -6,7 +6,7 @@
</head>
<body bgcolor="#ffffff">
-<H1><a name="Lua_nn1"></a>22 SWIG and Lua</H1>
+<H1><a name="Lua_nn1"></a>13 SWIG and Lua</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@@ -50,13 +50,13 @@
<p>
Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in clean C (that is, in the common subset of ANSI C and C++). Its also a <em>really</em> tiny language, less than 6000 lines of code, which compiles to &lt;100 kilobytes of binary code. It can be found at <a href="http://www.lua.org">http://www.lua.org</a>
</p>
-<H2><a name="Lua_nn2"></a>22.1 Preliminaries</H2>
+<H2><a name="Lua_nn2"></a>13.1 Preliminaries</H2>
<p>
The current SWIG implementation is designed to work with Lua 5.0.x and Lua 5.1.x. It should work with later versions of Lua, but certainly not with Lua 4.0 due to substantial API changes. ((Currently SWIG generated code has only been tested on Windows with MingW, though given the nature of Lua, is should not have problems on other OS's)). 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).
</p>
-<H2><a name="Lua_nn3"></a>22.2 Running SWIG</H2>
+<H2><a name="Lua_nn3"></a>13.2 Running SWIG</H2>
<p>
@@ -88,7 +88,7 @@ This creates a C/C++ source file <tt>example_wrap.c</tt> or <tt>example_wrap.cxx
<p>
The name of the wrapper file is derived from the name of the input file. For example, if the input file is <tt>example.i</tt>, the name of the wrapper file is <tt>example_wrap.c</tt>. To change this, you can use the -o option. The wrappered module will export one function <tt>"int luaopen_example(lua_State* L)"</tt> which must be called to register the module with the Lua interpreter. The name "luaopen_example" depends upon the name of the module.
</p>
-<H3><a name="Lua_nn4"></a>22.2.1 Compiling and Linking and Interpreter</H3>
+<H3><a name="Lua_nn4"></a>13.2.1 Compiling and Linking and Interpreter</H3>
<p>
@@ -135,7 +135,7 @@ $ gcc -c example.c -o example.o
$ gcc -I/usr/include/lua -L/usr/lib/lua min.o example_wrap.o example.o -o my_lua
</pre></div>
-<H3><a name="Lua_nn5"></a>22.2.2 Compiling a dynamic module</H3>
+<H3><a name="Lua_nn5"></a>13.2.2 Compiling a dynamic module</H3>
<p>
@@ -203,7 +203,7 @@ Is quite obvious (Go back and consult the Lua documents on how to enable loadlib
-<H3><a name="Lua_nn6"></a>22.2.3 Using your module</H3>
+<H3><a name="Lua_nn6"></a>13.2.3 Using your module</H3>
<p>
@@ -221,19 +221,19 @@ $ ./my_lua
&gt;
</pre></div>
-<H2><a name="Lua_nn7"></a>22.3 A tour of basic C/C++ wrapping</H2>
+<H2><a name="Lua_nn7"></a>13.3 A tour of basic C/C++ wrapping</H2>
<p>
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.
</p>
-<H3><a name="Lua_nn8"></a>22.3.1 Modules</H3>
+<H3><a name="Lua_nn8"></a>13.3.1 Modules</H3>
<p>
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.
</p>
-<H3><a name="Lua_nn9"></a>22.3.2 Functions</H3>
+<H3><a name="Lua_nn9"></a>13.3.2 Functions</H3>
<p>
@@ -271,7 +271,7 @@ It is also possible to rename the module with an assignment.
24
</pre></div>
-<H3><a name="Lua_nn10"></a>22.3.3 Global variables</H3>
+<H3><a name="Lua_nn10"></a>13.3.3 Global variables</H3>
<p>
@@ -345,7 +345,7 @@ nil
3.142
</pre></div>
-<H3><a name="Lua_nn11"></a>22.3.4 Constants and enums</H3>
+<H3><a name="Lua_nn11"></a>13.3.4 Constants and enums</H3>
<p>
@@ -368,7 +368,7 @@ example.SUNDAY=0
<p>
Constants are not guaranteed to remain constant in Lua. The name of the constant could be accidentally reassigned to refer to some other object. Unfortunately, there is no easy way for SWIG to generate code that prevents this. You will just have to be careful.
</p>
-<H3><a name="Lua_nn12"></a>22.3.5 Pointers</H3>
+<H3><a name="Lua_nn12"></a>13.3.5 Pointers</H3>
<p>
@@ -406,7 +406,7 @@ Lua enforces the integrity of its userdata, so it is virtually impossible to cor
nil
</pre></div>
-<H3><a name="Lua_nn13"></a>22.3.6 Structures</H3>
+<H3><a name="Lua_nn13"></a>13.3.6 Structures</H3>
<p>
@@ -492,7 +492,7 @@ Because the pointer points inside the structure, you can modify the contents and
&gt; x.a = 3 -- Modifies the same structure
</pre></div>
-<H3><a name="Lua_nn14"></a>22.3.7 C++ classes</H3>
+<H3><a name="Lua_nn14"></a>13.3.7 C++ classes</H3>
<p>
@@ -553,7 +553,7 @@ It is not (currently) possible to access static members of an instance:
-- does NOT work
</pre></div>
-<H3><a name="Lua_nn15"></a>22.3.8 C++ inheritance</H3>
+<H3><a name="Lua_nn15"></a>13.3.8 C++ inheritance</H3>
<p>
@@ -578,7 +578,7 @@ then the function <tt>spam()</tt> accepts a Foo pointer or a pointer to any clas
<p>
It is safe to use multiple inheritance with SWIG.
</p>
-<H3><a name="Lua_nn16"></a>22.3.9 Pointers, references, values, and arrays</H3>
+<H3><a name="Lua_nn16"></a>13.3.9 Pointers, references, values, and arrays</H3>
<p>
@@ -609,7 +609,7 @@ Foo spam7();
<p>
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.
</p>
-<H3><a name="Lua_nn17"></a>22.3.10 C++ overloaded functions</H3>
+<H3><a name="Lua_nn17"></a>13.3.10 C++ overloaded functions</H3>
<p>
@@ -695,7 +695,7 @@ Please refer to the "SWIG and C++" chapter for more information about overloadin
<p>
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.
</p>
-<H3><a name="Lua_nn18"></a>22.3.11 C++ operators</H3>
+<H3><a name="Lua_nn18"></a>13.3.11 C++ operators</H3>
<p>
@@ -807,7 +807,7 @@ It is also possible to overload the operator<tt>[]</tt>, but currently this cann
};
</pre></div>
-<H3><a name="Lua_nn19"></a>22.3.12 Class extension with %extend</H3>
+<H3><a name="Lua_nn19"></a>13.3.12 Class extension with %extend</H3>
<p>
@@ -862,7 +862,7 @@ true
<p>
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).
</p>
-<H3><a name="Lua_nn20"></a>22.3.13 C++ templates</H3>
+<H3><a name="Lua_nn20"></a>13.3.13 C++ templates</H3>
<p>
@@ -897,7 +897,7 @@ In Lua:
<p>
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.
</p>
-<H3><a name="Lua_nn21"></a>22.3.14 C++ Smart Pointers</H3>
+<H3><a name="Lua_nn21"></a>13.3.14 C++ Smart Pointers</H3>
<p>
@@ -949,7 +949,7 @@ If you ever need to access the underlying pointer returned by <tt>operator-&gt;(
&gt; f = p:__deref__() -- Returns underlying Foo *
</pre></div>
-<H3><a name="Lua_nn22"></a>22.3.15 Writing your own custom wrappers</H3>
+<H3><a name="Lua_nn22"></a>13.3.15 Writing your own custom wrappers</H3>
<p>
@@ -968,7 +968,7 @@ int native_function(lua_State*L) // my native code
The <tt>%native</tt> directive in the above example, tells SWIG that there is a function <tt>int native_function(lua_State*L);</tt> which is to be added into the module under the name '<tt>my_func</tt>'. SWIG will not add any wrappering for this function, beyond adding it into the function table. How you write your code is entirely up to you.
</p>
-<H2><a name="Lua_nn23"></a>22.4 Details on the Lua binding</H2>
+<H2><a name="Lua_nn23"></a>13.4 Details on the Lua binding</H2>
<p>
@@ -979,7 +979,7 @@ The <tt>%native</tt> directive in the above example, tells SWIG that there is a
</i>
</p>
-<H3><a name="Lua_nn24"></a>22.4.1 Binding global data into the module.</H3>
+<H3><a name="Lua_nn24"></a>13.4.1 Binding global data into the module.</H3>
<p>
@@ -1039,7 +1039,7 @@ end
<p>
That way when you call '<tt>a=example.Foo</tt>', 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 '<tt>example.Foo=10</tt>', 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)'.
</p>
-<H3><a name="Lua_nn25"></a>22.4.2 Userdata and Metatables</H3>
+<H3><a name="Lua_nn25"></a>13.4.2 Userdata and Metatables</H3>
<p>
@@ -1119,7 +1119,7 @@ Note: Both the opaque structures (like the FILE*) and normal wrappered classes/s
<p>
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' &amp; '__call' to the classes 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.
</p>
-<H3><a name="Lua_nn26"></a>22.4.3 Memory management</H3>
+<H3><a name="Lua_nn26"></a>13.4.3 Memory management</H3>
<p>