blob: 58a50ad2e14c4cb981147cb15f5d69c072de1630 [file] [log] [blame]
<html>
<head>
<title>SWIG:Examples:perl5:class</title>
</head>
<body bgcolor="#ffffff">
<tt>SWIG/Examples/perl5/class/</tt>
<hr>
<H2>Wrapping a simple C++ class</H2>
<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 Perl script</h2>
Click <a href="runme.pl">here</a> to see a script that calls the C++ functions from Perl.
<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::Shape_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 class in which
the data member is defined is used. For example <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>
<p>
<li>Static member variables are wrapped as C global variables. For example:
<blockquote>
<pre>
$n = $example::Shape_nshapes; # Get a static data member
$example::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. Proxy 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).
</ul>
<hr>
</body>
</html>