Examples/python/constants/index.html

<html>
<head>
<title>SWIG:Examples:python:constants</title>
</head>

<body bgcolor="#ffffff">

<tt>SWIG/Examples/python/constants/</tt>
<hr>

<H2>Wrapping C Constants</H2>

<p>
When SWIG encounters C preprocessor macros and C declarations that look like constants,
it creates Python variables with an identical value.  Click <a href="example.i">here</a>
to see a SWIG interface with some constant declarations in it.

<h2>Accessing Constants from Python</h2>

Click <a href="runme.py">here</a> to see a script that prints out the values
of the constants contained in the above file.

<h2>Key points</h2>

<ul>
<li>The values of preprocessor macros are converted into Python constants.
<li>Types are inferred by syntax (e.g., "3" is an integer and "3.5" is a float).
<li>Character constants such as 'x' are converted into Python strings.
<li>C string literals such as "Hello World" are converted into Python strings.
<li>Macros that are not fully defined are simply ignored.  For example:
<blockquote>
<pre>
#define EXTERN extern
</pre>
</blockquote>
is ignored because SWIG has no idea what type of variable this would be.

<p>
<li>Expressions are allowed provided that all of their components are defined. Otherwise, the constant is ignored.

<li>Certain C declarations involving 'const' are also turned into Python constants. 
<li>The Python variables that SWIG creates are not protected from modification.  For example,
even if you had this:
<blockquote>
<pre>
#define FOO 73
</pre>
</blockquote>
a user could come along in a script and type
<blockquote>
<pre>
example.FOO = 13
</pre>
</blockquote>
Unfortunately, there's no easy way to prevent this.

<p>
<li>The constants that appear in a SWIG interface file do not have to appear in any sort
of matching C source file since the creation of a constant does not require linkage
to a stored value (i.e., a value held in a C global variable or memory location).
</ul>

<hr>


</body>
</html>