New example
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@775 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
parent
cb4255a086
commit
53bf5fb465
7 changed files with 407 additions and 0 deletions
239
Examples/python/class/index.html
Normal file
239
Examples/python/class/index.html
Normal file
|
|
@ -0,0 +1,239 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>SWIG:Examples:python:class</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
|
||||
<tt>SWIG/Examples/python/class/</tt>
|
||||
<hr>
|
||||
|
||||
<H2>Wrapping a simple C++ class</H2>
|
||||
|
||||
<tt>$Header$</tt><br>
|
||||
|
||||
<p>
|
||||
This example illustrates the most primitive form of C++ class wrapping performed
|
||||
by SWIG. In this case, C++ classes are simply transformed into a collection of
|
||||
C-style functions that provide access to class members.
|
||||
|
||||
<h2>The C++ Code</h2>
|
||||
|
||||
Suppose you have some C++ classes described by the following (and admittedly lame)
|
||||
header file:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
/* File : example.h */
|
||||
|
||||
class Shape {
|
||||
public:
|
||||
Shape() {
|
||||
nshapes++;
|
||||
}
|
||||
virtual ~Shape() {
|
||||
nshapes--;
|
||||
};
|
||||
double x, y;
|
||||
void move(double dx, double dy);
|
||||
virtual double area() = 0;
|
||||
virtual double perimeter() = 0;
|
||||
static int nshapes;
|
||||
};
|
||||
|
||||
class Circle : public Shape {
|
||||
private:
|
||||
double radius;
|
||||
public:
|
||||
Circle(double r) : radius(r) { };
|
||||
virtual double area();
|
||||
virtual double perimeter();
|
||||
};
|
||||
|
||||
class Square : public Shape {
|
||||
private:
|
||||
double width;
|
||||
public:
|
||||
Square(double w) : width(w) { };
|
||||
virtual double area();
|
||||
virtual double perimeter();
|
||||
};
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<h2>The SWIG interface</h2>
|
||||
|
||||
A simple SWIG interface for this can be built by simply grabbing the header file
|
||||
like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
|
||||
/* Let's just grab the original header file here */
|
||||
%include "example.h"
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
Note: when creating a C++ extension, you must run SWIG with the <tt>-c++</tt> option like this:
|
||||
<blockquote>
|
||||
<pre>
|
||||
% swig -c++ -python example.i
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<h2>A sample Python script</h2>
|
||||
|
||||
Click <a href="example.py">here</a> to see a script that calls the C++ functions from Python.
|
||||
|
||||
<h2>Key points</h2>
|
||||
|
||||
<ul>
|
||||
<li>To create a new object, you call a constructor like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
c = example.new_Circle(10.0)
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
<li>To access member data, a pair of accessor functions are used.
|
||||
For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
example.Circle_x_set(c,15) # Set member data
|
||||
x = example.Shape_x_get(c) # Get member data
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
Note: when accessing member data, the name of the base class or the derived class can be
|
||||
used in the function name as shown above. Of course, it would probably be more
|
||||
proper to just use the base class version such as <tt>Shape_x_get()</tt>
|
||||
|
||||
<p>
|
||||
<li>To invoke a member function, you simply do this
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
print "The area is ", example.Shape_area(c)
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
<li>Type checking knows about the inheritance structure of C++. For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
example.Shape_area(c) # Works (c is a Shape)
|
||||
example.Circle_area(c) # Works (c is a Circle)
|
||||
example.Square_area(c) # Fails (c is definitely not a Square)
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
<li>To invoke a destructor, simply do this
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
example.delete_Shape(c) # Deletes a shape
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
(Note: destructors are currently not inherited. This might change later).
|
||||
|
||||
<p>
|
||||
<li>Static member variables are wrapped as C global variables. For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
n = example.cvar.Shape_nshapes # Get a static data member
|
||||
example.cvar.Shapes_nshapes = 13 # Set a static data member
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
</ul>
|
||||
|
||||
<h2>General Comments</h2>
|
||||
|
||||
<ul>
|
||||
<li>This low-level interface is not the only way to handle C++ code. Shadow classes
|
||||
provide a much higher-level interface.
|
||||
|
||||
<p>
|
||||
<li>SWIG *does* know how to properly perform upcasting of objects in an inheritance
|
||||
hierarchy (including multiple inheritance). Therefore it is perfectly safe to pass
|
||||
an object of a derived class to any function involving a base class.
|
||||
|
||||
<p>
|
||||
<li>A wide variety of C++ features are not currently supported by SWIG. Here is the
|
||||
short and incomplete list:
|
||||
|
||||
<p>
|
||||
<ul>
|
||||
<li>Overloaded methods and functions. SWIG wrappers don't know how to resolve name
|
||||
conflicts so you must give an alternative name to any overloaded method name using the
|
||||
%name directive like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
void foo(int a);
|
||||
%name(foo2) void foo(double a, double b);
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
<li>Overloaded operators. Not supported at all. The only workaround for this is
|
||||
to write a helper function. For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
%inline %{
|
||||
Vector *vector_add(Vector *a, Vector *b) {
|
||||
... whatever ...
|
||||
}
|
||||
%}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
<li>Namespaces. Not supported at all. Won't be supported until SWIG2.0 (if at all).
|
||||
|
||||
<p>
|
||||
<li>Templates. Not supported at all. SWIG throws out anything that looks like a template.
|
||||
You can work around the problem by aliasing a template class behind a typedef however.
|
||||
For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
%{
|
||||
typedef vector<int> IntVector;
|
||||
%}
|
||||
|
||||
class IntVector {
|
||||
public:
|
||||
... methods ...
|
||||
};
|
||||
</pre>
|
||||
</blockquote>
|
||||
</ul>
|
||||
<p>
|
||||
<li>There is no guarantee that an extremely complex C++ application will be able to compile
|
||||
as a Python extension. Sorry.
|
||||
|
||||
<p>
|
||||
<li>Dave's snide remark: Like a large bottle of strong Tequilla, it's better to
|
||||
use C++ in moderation.
|
||||
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
</body>
|
||||
</html>
|
||||
Loading…
Add table
Add a link
Reference in a new issue