jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

New example

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@742 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Dave Beazley 2000-08-30 22:38:51 +00:00
commit 59d16fffd4
7 changed files with 333 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

102
SWIG/Examples/python/variables/index.html Normal file
View file

@ -0,0 +1,102 @@
<html>
<head>
<title>SWIG:Examples:python:variables</title>
</head>
<body bgcolor="#ffffff">
<tt>SWIG/Examples/python/variables/</tt>
<hr>
<H2>Wrapping C Global Variables</H2>
<tt>$Header$</tt><br>
<p>
When a C global variable appears in an interface file, SWIG tries to
wrap it using a technique known as "variable linking." The idea is
pretty simple---we try to create a Python variable that magically
retrieves or updates the value of the underlying C variable when it is
accessed. Click <a href="example.i">here</a> to see a SWIG interface with some variable
declarations in it.
<h2>Manipulating Variables from Python</h2>
Before going any further, it is important to understand some important
differences between C and Python variables. In C, a variable is
simply a name that refers to a specific location in memory. For
example, when you declare a global variable '<tt>double a</tt>' you
know that somewhere in memory, 8 bytes have been set aside to hold a
<tt>double</tt> and that <tt>a</tt> is bound to this location for the
life of the program. In Python, variable creation is nothing more
than a naming operation. For example, when you say '<tt>a = 3</tt>',
'a' becomes a name that refers to some object '3'. Later on, if you say
'<tt>a = 7.5</tt>, the name 'a' is bound to an entirely different object
containing the value '7.5' (the contents of the original object are not
changed). The end result of this is that a variable in Python can refer
to a virtually unlimited number of different objects (memory locations)
over the lifetime of a program.
<p>
Because of Python's somewhat unusual variable assignment semantics, it is not
possible to directly link a C global variable into an equivalent Python variable.
Instead, all C global variables are accessed as attributes of a special object
called 'cvar'. For example, if you had a global variable
<blockquote>
<pre>
double foo;
</pre>
</blockquote>
it will be accessed in the Python module as <tt>cvar.foo</tt>. Click
<a href="example.py">here</a> to see a script that updates and prints
out the values of the variables using this technique.
<h2>Key points</h2>
<ul>
<li>When a global variable has the type "<tt>char *</tt>", SWIG manages it as a character
string. However, whenever the value of such a variable is set from Python, the old
value is destroyed using <tt>free()</tt> or <tt>delete</tt> (the choice of which depends
on whether or not SWIG was run with the -c++ option).
<li><tt>signed char</tt> and <tt>unsigned char</tt> are handled as small 8-bit integers.
<li>String array variables such as '<tt>char name[256]</tt>' are managed as Python strings, but
when setting the value, the result is truncated to the maximum length of the array. Furthermore, the string is assumed to be null-terminated.
<li>When structures and classes are used as global variables, they are mapped into pointers.
Getting the "value" returns a pointer to the global variable. Setting the value of a structure results in a memory copy from a pointer to the global.
</ul>
<h2>Creating read-only variables</h2>
The <tt>%readonly</tt> and <tt>%readwrite</tt> directives can be used to
specify a collection of read-only variables. For example:
<blockquote>
<pre>
%readonly
int status;
double blah;
...
%readwrite
</pre>
</blockquote>
The <tt>%readonly</tt> directive remains in effect until it is explicitly disabled
using the <tt>%readwrite</tt> directive.
<h2>Comments</h2>
<ul>
<li>Management of global variables is one of the most problematic aspects
of C/C++ wrapping because the scripting interface and resulting memory management
is much trickier than simply creating a wrapper function.
<p>
<li>Because of the potential for a namespace conflict, you should not use
the <tt>from module import *</tt> statement for a SWIG module with global
variables. Doing so will cause a collision on the 'cvar' object should
more than one module be loaded in this manner.
</ul>
</body>
</html>
<hr>