summaryrefslogtreecommitdiff
path: root/Examples/tcl/class/index.html
blob: 5b09b7a9d17aea33e4a0be7f69b57369fee109e9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
<html>
<head>
<title>SWIG:Examples:tcl:class</title>
</head>

<body bgcolor="#ffffff">


<tt>SWIG/Examples/tcl/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++ -tcl example.i
</pre>
</blockquote>

<h2>Some sample Tcl scripts</h2>

SWIG performs two forms of C++ wrapping-- a low level interface and a high level widget-like interface.
<ul>
<li>
Click <a href="runme.tcl">here</a> to see a script that calls the C++ functions using the
low-level interface.
<li>
Click <a href="runme2.tcl">here</a> to see the same script written with the high-level
interface.
</ul>

<h2>Key points</h2>

<ul>
<li>The low-level C++ interface works like this:
<p>
<ul>
<li>To create a new object, you call a constructor like this:

<blockquote>
<pre>
set c [new_Circle 10.0]
</pre>
</blockquote>

<p>
<li>To access member data, a pair of accessor functions are used.
For example:

<blockquote>
<pre>
Shape_x_set $c 15        ;# Set member data
set x [Shape_x_get $c]   ;# Get member data
</pre>
</blockquote>

Note: when accessing member data, the name of the base class must
be used such as <tt>Shape_x_get</tt>

<p>
<li>To invoke a member function, you simply do this

<blockquote>
<pre>
puts "The area is [Shape_area $c]"
</pre>
</blockquote>

<p>
<li>Type checking knows about the inheritance structure of C++. For example:

<blockquote>
<pre>
Shape_area $c       # Works (c is a Shape)
Circle_area $c      # Works (c is a Circle)
Square_area $c      # Fails (c is definitely not a Square)
</pre>
</blockquote>

<p>
<li>To invoke a destructor, simply do this

<blockquote>
<pre>
delete_Shape $c     # Deletes a shape
</pre>
</blockquote>

<p>
<li>Static member variables are wrapped as C global variables.  For example:

<blockquote>
<pre>
set n $Shape_nshapes    # Get a static data member
set Shapes_nshapes 13   # Set a static data member
</pre>
</blockquote>

</ul>

<p>
<li>The high-level interface works like a Tk widget

<p>
<ul>
<li>To create a new object, you call a constructor like this:

<blockquote>
<pre>
Circle c 10      # c becomes a name for the Circle object
</pre>
</blockquote>

<p>
<li>To access member data, use cget and configure methods.
For example:

<blockquote>
<pre>
c configure -x 15        ;# Set member data
set x [c cget -x]        ;# Get member data
</pre>
</blockquote>

<p>
<li>To invoke a member function, you simply do this

<blockquote>
<pre>
puts "The area is [c area]"
</pre>
</blockquote>

<p>
<li>To invoke a destructor, simply destroy the object name like this:

<blockquote>
<pre>
rename c ""         # c goes away
</pre>
</blockquote>

<p>
<li>Static member variables are wrapped as C global variables.  For example:

<blockquote>
<pre>
set n $Shape_nshapes    # Get a static data member
set Shapes_nshapes 13   # Set a static data member
</pre>
</blockquote>

</ul>
</ul>

<h2>General Comments</h2>

<ul>

<li>The low-level function interface is much faster than the high-level interface.
In fact, all the higher level interface does is call functions in the low-level interface.

<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.

<li>C++ Namespaces - %nspace isn't yet supported for Python.

</ul>

<hr>
</body>
</html>