<html> <head> <title>SWIG:Examples:python:constants</title> </head> <body bgcolor="#ffffff"> <tt>SWIG/Examples/python/constants/</tt> <hr> <H2>Wrapping C Constants</H2> <tt>$Header: /cvs/projects/SWIG/Examples/python/constants/index.html,v 1.1 2000/06/17 21:40:59 beazley Exp $</tt><br> <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>
