mirror of https://github.com/swig/swig
96 lines
3.5 KiB
HTML
96 lines
3.5 KiB
HTML
<html>
|
|
<head>
|
|
<title>SWIG:Examples:ruby:variables</title>
|
|
</head>
|
|
|
|
<body bgcolor="#ffffff">
|
|
|
|
<tt>SWIG/Examples/ruby/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 Ruby variable (actually module method) 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 Ruby</h2>
|
|
|
|
Before going any further, it is important to understand some important
|
|
differences between C and Ruby 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 Ruby, 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 Ruby can refer
|
|
to a virtually unlimited number of different objects (memory locations)
|
|
over the lifetime of a program.
|
|
|
|
<p>
|
|
Because of Ruby's somewhat unusual variable assignment semantics, it is not
|
|
possible to directly link a C global variable into an equivalent Ruby variable.
|
|
Instead, all C global variables are accessed as attributes of the module.
|
|
For example, if you had a global variable
|
|
|
|
<blockquote>
|
|
<pre>
|
|
double foo;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
it will be accessed in the Ruby module as <tt>Example.foo</tt>. Click
|
|
<a href="runme.rb">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 Ruby, the old
|
|
value is destroyed using <tt>free()</tt>.
|
|
<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 Ruby 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.
|
|
</ul>
|
|
|
|
</body>
|
|
</html>
|
|
<hr> |