trunk/Examples/python/constants/index.html - third_party/swig - Git at Google

 <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="example.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>
	<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="example.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>