~ubuntu-branches/ubuntu/edgy/swig1.3/edgy

« back to all changes in this revision

Viewing changes to Doc/Manual/Perl5.html

  • Committer: Bazaar Package Importer
  • Author(s): Adam Conrad
  • Date: 2005-12-05 01:16:04 UTC
  • mfrom: (1.2.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20051205011604-ygx904it6413k3go
Tags: 1.3.27-1ubuntu1
Resynchronise with Debian again, for the new subversion packages.

Show diffs side-by-side

added added

removed removed

Lines of Context:
2
2
<html>
3
3
<head>
4
4
<title>SWIG and Perl5</title>
 
5
<link rel="stylesheet" type="text/css" href="style.css">
5
6
</head>
6
7
 
7
8
<body bgcolor="#ffffff">
8
9
<H1><a name="Perl5"></a>23 SWIG and Perl5</H1>
9
10
<!-- INDEX -->
 
11
<div class="sectiontoc">
10
12
<ul>
11
13
<li><a href="#Perl5_nn2">Overview</a>
12
14
<li><a href="#Perl5_nn3">Preliminaries</a>
66
68
<li><a href="#Perl5_nn46">Modifying the proxy methods</a>
67
69
</ul>
68
70
</ul>
 
71
</div>
69
72
<!-- INDEX -->
70
73
 
71
74
 
72
75
 
 
76
<p>
73
77
<b>Caution: This chapter is under repair!</b>
 
78
</p>
74
79
 
75
80
<p>
76
81
This chapter describes SWIG's support of Perl5. Although the Perl5
84
89
<H2><a name="Perl5_nn2"></a>23.1 Overview</H2>
85
90
 
86
91
 
 
92
<p>
87
93
To build Perl extension modules, SWIG uses a layered approach.  At
88
94
the lowest level, simple procedural wrappers are generated for
89
95
functions, classes, methods, and other declarations in the input file.
90
96
Then, for structures and classes, an optional collection of Perl
91
97
proxy classes can be generated in order to provide a more natural object oriented Perl
92
98
interface. These proxy classes simply build upon the low-level interface.
 
99
</p>
93
100
 
94
101
<p>
95
102
In describing the Perl interface, this chapter begins by covering the
108
115
follows :
109
116
</p>
110
117
 
111
 
<blockquote><pre>
 
118
<div class="code"><pre>
112
119
swig -perl example.i
113
120
 
114
 
</pre></blockquote>
 
121
</pre></div>
115
122
 
 
123
<p>
116
124
This produces two files. The first file, <tt>example_wrap.c</tt>
117
125
contains all of the C code needed to build a Perl5 module. The second
118
126
file, <tt>example.pm</tt> contains supporting Perl code needed to
119
127
properly load the module.
 
128
</p>
120
129
 
121
130
<p>
122
131
To build the module, you will need to compile the file
129
138
<p>
130
139
In order to compile, SWIG extensions need the following Perl5 header files :</p>
131
140
 
132
 
<blockquote><pre>
 
141
<div class="code"><pre>
133
142
#include "Extern.h"
134
143
#include "perl.h"
135
144
#include "XSUB.h"
136
 
</pre></blockquote>
 
145
</pre></div>
137
146
 
138
147
<p>
139
148
These are typically located in a directory like this</p>
140
149
 
141
 
<blockquote><pre>
 
150
<div class="code"><pre>
142
151
/usr/lib/perl5/5.00503/i386-linux/CORE
143
 
</pre></blockquote>
 
152
</pre></div>
144
153
 
145
154
<p>
146
155
The SWIG configuration script automatically tries to locate this directory so
148
157
loaded, an easy way to find out is to run Perl itself.
149
158
</p>
150
159
 
151
 
<blockquote>
 
160
<div class="code">
152
161
<pre>
153
162
% perl -e 'use Config; print $Config{archlib};'
154
163
/usr/lib/perl5/5.00503/i386-linux
155
164
</pre>
156
 
</blockquote>
 
165
</div>
157
166
 
158
167
<H3><a name="Perl5_nn5"></a>23.2.2 Compiling a dynamic module</H3>
159
168
 
160
169
 
 
170
<p>
161
171
The preferred approach to building an extension module is to compile it into
162
172
a shared object file or DLL.   To do this, you will need to compile your program
163
173
using comands like this (shown for Linux):
 
174
</p>
164
175
 
165
 
<blockquote><pre>
 
176
<div class="code"><pre>
166
177
$ swig -perl example.i
167
178
% gcc example.c
168
179
% gcc -c example_wrap.c -I/usr/lib/perl5/5.00503/i386-linux/CORE -Dbool=char
169
180
% gcc -shared example.o example_wrap.o -o example.so
170
 
</pre></blockquote>
 
181
</pre></div>
171
182
 
 
183
<p>
172
184
The exact compiler options vary from platform to platform. 
173
185
SWIG tries to guess the right options when it is installed.  Therefore, 
174
186
you may want to start with one of the examples in the <tt>SWIG/Examples/perl5</tt> 
176
188
your compiler and linker to get the right set of options.  You might also
177
189
check the <a href="http://swig.cs.uchicago.edu/cgi-bin/wiki.pl">SWIG Wiki</a> for
178
190
additional information.
 
191
</p>
179
192
 
180
193
<p>
181
194
When linking the module, the name of the shared object file must match the module name used in
192
205
for you using the MakeMaker utility.  To do this, write a Perl
193
206
script such as the following :</p>
194
207
 
195
 
<blockquote><pre>
 
208
<div class="code"><pre>
196
209
# File : Makefile.PL
197
210
use ExtUtils::MakeMaker;
198
211
WriteMakefile(
201
214
        `OBJECT'  =&gt; `example.o example_wrap.o'  # Object files
202
215
);
203
216
 
204
 
</pre></blockquote>
 
217
</pre></div>
205
218
 
206
219
<p>
207
220
Now, to build a module, simply follow these steps :</p>
208
221
 
209
 
<blockquote><pre>
 
222
<div class="code"><pre>
210
223
% perl Makefile.PL
211
224
% make
212
225
% make install
213
 
</pre></blockquote>
 
226
</pre></div>
214
227
 
215
228
<p>
216
229
If you are planning to distribute a SWIG-generated module, this is
227
240
interpreter with your SWIG extensions added to it. To build a static
228
241
extension, you first need to invoke SWIG as follows :</p>
229
242
 
230
 
<blockquote><pre>
 
243
<div class="code"><pre>
231
244
% swig -perl -static example.i
232
 
</pre></blockquote>
 
245
</pre></div>
233
246
 
234
247
<p>
235
248
By default SWIG includes code for dynamic loading, but the
241
254
this may sound daunting, SWIG can do this for you automatically as
242
255
follows :</p>
243
256
 
244
 
<blockquote><pre>
 
257
<div class="code"><pre>
245
258
%module example
246
259
 
 
260
%inline %{
247
261
extern double My_variable;
248
262
extern int fact(int);
 
263
%}
249
264
 
250
265
// Include code for rebuilding Perl
251
266
%include perlmain.i
252
 
</pre></blockquote>
 
267
</pre></div>
253
268
 
254
269
<p>
255
270
The same thing can be accomplished by running SWIG as follows :</p>
256
271
 
257
 
<blockquote><pre>
 
272
<div class="code"><pre>
258
273
% swig -perl -static -lperlmain.i example.i
259
 
</pre></blockquote>
 
274
</pre></div>
260
275
 
261
276
<p>
262
277
The <tt>permain.i</tt> file inserts Perl's <tt>main()</tt> function
273
288
for a dynamic module, but change the link line to something like this:
274
289
</p>
275
290
 
276
 
<blockquote><pre>
 
291
<div class="code"><pre>
277
292
% gcc example.o example_wrap.o -L/usr/lib/perl5/5.00503/i386-linux/CORE \
278
293
        -lperl -lsocket -lnsl -lm -o myperl
279
 
</pre></blockquote>
 
294
</pre></div>
280
295
 
281
296
<p>
282
297
This will produce a new version of Perl called <tt>myperl</tt>. It
293
308
all goes well, you will be able to do this:
294
309
</p>
295
310
 
296
 
<blockquote><pre>
 
311
<div class="code"><pre>
297
312
$ perl
298
313
use example;
299
314
print example::fact(4),"\n";
300
315
24
301
 
</pre></blockquote>
 
316
</pre></div>
302
317
 
 
318
<p>
303
319
A common error received by first-time users is the following:
 
320
</p>
304
321
 
305
 
<blockquote>
 
322
<div class="code">
306
323
<pre>
307
324
use example;
308
325
Can't locate example.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-lin
310
327
rl5/site_perl/5.005 .) at - line 1.
311
328
BEGIN failed--compilation aborted at - line 1.
312
329
</pre>
313
 
</blockquote>
 
330
</div>
314
331
 
 
332
<p>
315
333
This error is almost caused when the name of the shared object file you created doesn't match the module name
316
334
you specified with the <tt>%module</tt> directive.  
 
335
</p>
317
336
 
318
337
<p>
319
338
A somewhat related, but slightly different error is this:
320
339
</p>
321
340
 
322
 
<blockquote>
 
341
<div class="code">
323
342
<pre>
324
343
use example;
325
344
Can't find 'boot_example' symbol in ./example.so
326
345
 at - line 1
327
346
BEGIN failed--compilation aborted at - line 1.
328
347
</pre>
329
 
</blockquote>
 
348
</div>
330
349
 
 
350
<p>
331
351
This error is generated because Perl can't locate the module bootstrap function in the
332
352
SWIG extension module.  This could be caused by a mismatch between the module name and the shared library name.
333
353
However, another possible cause is forgetting to link the SWIG-generated wrapper code with the rest
334
354
of your application when you linked the extension module.
 
355
</p>
335
356
 
336
357
<p>
337
358
Another common error is the following:
338
359
</p>
339
360
 
340
 
<blockquote>
 
361
<div class="code">
341
362
<pre>
342
363
use example;
343
364
Can't load './example.so' for module example: ./example.so: 
346
367
 at - line 1
347
368
BEGIN failed--compilation aborted at - line 1.
348
369
</pre>
349
 
</blockquote>
 
370
</div>
350
371
 
 
372
<p>
351
373
This error usually indicates that you forgot to include some object
352
374
files or libraries in the linking of the shared library file.  Make
353
375
sure you compile both the SWIG wrapper file and your original program
354
376
into a shared library file.  Make sure you pass all of the required libraries
355
377
to the linker.  
 
378
</p>
356
379
 
357
380
<p>
358
381
Sometimes unresolved symbols occur because a wrapper has been created
369
392
Finally, suppose that your extension module is linked with another library like this:
370
393
</p>
371
394
 
372
 
<blockquote>
 
395
<div class="code">
373
396
<pre>
374
397
$ gcc -shared example.o example_wrap.o -L/home/beazley/projects/lib -lfoo \
375
398
      -o example.so
376
399
</pre>
377
 
</blockquote>
 
400
</div>
378
401
 
 
402
<p>
379
403
If the <tt>foo</tt> library is compiled as a shared library, you might get the following
380
404
error when you try to use your module:
 
405
</p>
381
406
 
382
 
<blockquote>
 
407
<div class="code">
383
408
<pre>
384
409
use example;
385
410
Can't load './example.so' for module example: libfoo.so: cannot open shared object file: 
389
414
BEGIN failed--compilation aborted at - line 1.
390
415
&gt;&gt;&gt;                 
391
416
</pre>
392
 
</blockquote>
 
417
</div>
393
418
 
 
419
<p>
394
420
This error is generated because the dynamic linker can't locate the
395
421
<tt>libfoo.so</tt> library.  When shared libraries are loaded, the
396
422
system normally only checks a few standard locations such as
397
423
<tt>/usr/lib</tt> and <tt>/usr/local/lib</tt>.   To get the loader to look in other
398
424
locations, there are several things you can do.  First, you can recompile your extension
399
425
module with extra path information. For example, on Linux you can do this:
 
426
</p>
400
427
 
401
 
<blockquote>
 
428
<div class="code">
402
429
<pre>
403
430
$ gcc -shared example.o example_wrap.o -L/home/beazley/projects/lib -lfoo \
404
431
      <b>-Xlinker -rpath /home/beazley/projects/lib \</b>
405
432
      -o example.so
406
433
</pre>
407
 
</blockquote>
 
434
</div>
408
435
 
 
436
<p>
409
437
Alternatively, you can set the <tt>LD_LIBRARY_PATH</tt> environment
410
438
variable to include the directory with your shared libraries.  If
411
439
setting <tt>LD_LIBRARY_PATH</tt>, be aware that setting this variable
412
440
can introduce a noticeable performance impact on all other
413
441
applications that you run.  To set it only for Perl, you might want
414
442
to do this instead:
 
443
</p>
415
444
 
416
 
<blockquote>
 
445
<div class="code">
417
446
<pre>
418
447
$ env LD_LIBRARY_PATH=/home/beazley/projects/lib perl
419
448
</pre>
420
 
</blockquote>
 
449
</div>
421
450
 
 
451
<p>
422
452
Finally, you can use a command such as <tt>ldconfig</tt> (Linux) or
423
453
<tt>crle</tt> (Solaris) to add additional search paths to the default
424
454
system configuration (this requires root access and you will need to
425
455
read the man pages).
 
456
</p>
426
457
 
427
458
<H3><a name="Perl5_nn9"></a>23.2.6 Compilation problems and compiling with C++</H3>
428
459
 
429
460
 
 
461
<p>
430
462
Compilation of C++ extensions has traditionally been a tricky problem.
431
463
Since the Perl interpreter is written in C, you need to take steps to
432
464
make sure C++ is properly initialized and that modules are compiled
433
465
correctly.
 
466
</p>
434
467
 
435
468
<p>
436
469
On most machines, C++ extension modules should be linked using the C++
437
470
compiler.  For example:
438
471
</p>
439
472
 
440
 
<blockquote><pre>
 
473
<div class="code"><pre>
441
474
% swig -c++ -perl example.i
442
475
% g++ -c example.cxx
443
476
% g++ -c example_wrap.cxx -I/usr/lib/perl5/5.00503/i386-linux/CORE
444
477
% <b>g++ -shared example.o example_wrap.o -o example.so</b>
445
 
</pre></blockquote>
 
478
</pre></div>
446
479
 
447
480
<p>
448
481
In addition to this, you may need to include additional library
450
483
Solaris, you often need to add an extra library <tt>-lCrun</tt> like this:
451
484
</p>
452
485
 
453
 
<blockquote><pre>
 
486
<div class="code"><pre>
454
487
% swig -c++ -perl example.i
455
488
% g++ -c example.cxx
456
489
% g++ -c example_wrap.cxx -I/usr/lib/perl5/5.00503/i386-linux/CORE
457
490
% g++ -shared example.o example_wrap.o -o example.so <b>-lCrun</b>
458
 
</pre></blockquote>
 
491
</pre></div>
459
492
 
 
493
<p>
460
494
Of course, the names of the extra libraries are completely non-portable---you will 
461
495
probably need to do some experimentation.
 
496
</p>
462
497
 
463
498
<p>
464
499
Another possible compile problem comes from recent versions of Perl (5.8.0) and the GNU tools.
466
501
it needs to be.  So you should compile the wrapper like:
467
502
</p>
468
503
 
469
 
<blockquote><pre>
 
504
<div class="code"><pre>
470
505
% g++ -c example_wrap.cxx -I/usr/lib/perl/5.8.0/CORE -D_GNU_SOURCE
471
 
</pre></blockquote>
 
506
</pre></div>
472
507
 
 
508
<p>
473
509
-D_GNU_SOURCE is also included in the Perl ccflags, which can be found by running
474
 
<blockquote><pre>
 
510
</p>
 
511
 
 
512
<div class="code"><pre>
475
513
% perl -e 'use Config; print $Config{ccflags};'
476
 
</pre></blockquote>
 
514
</pre></div>
 
515
 
 
516
<p>
477
517
So you could also compile the wrapper like
478
 
<blockquote><pre>
 
518
</p>
 
519
 
 
520
<div class="code"><pre>
479
521
% g++ -c example_wrap.cxx -I/usr/lib/perl/5.8.0/CORE \
480
522
`perl -e 'use Config; print $Config{ccflags}'`
481
 
</pre></blockquote>
 
523
</pre></div>
482
524
 
483
525
<p>
484
526
Sometimes people have suggested that it is necessary to relink the
497
539
extension module. For example, notice the first line of output here:
498
540
</p>
499
541
 
500
 
<blockquote>
 
542
<div class="code">
501
543
<pre>
502
544
$ ldd swig
503
545
        <b>libstdc++-libc6.1-1.so.2 =&gt; /usr/lib/libstdc++-libc6.1-1.so.2 (0x40019000)</b>
506
548
        /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x40000000)
507
549
$
508
550
</pre>
509
 
</blockquote>
 
551
</div>
510
552
 
511
553
<p>
512
554
If linking wasn't enough of a problem, another major complication of C++ is that it does not
539
581
/usr/lib/perl/5.8.0/CORE/embed.h there is a line:
540
582
</p>
541
583
 
542
 
<blockquote><pre>
 
584
<div class="code"><pre>
543
585
#define do_open Perl_do_open
544
 
</pre></blockquote>
 
586
</pre></div>
545
587
 
 
588
<p>
546
589
The problem is, in the &lt;iostream&gt; header from GNU libstdc++v3 there is a private 
547
590
function named do_open.  If &lt;iostream&gt; is included after the perl headers, then
548
591
the Perl macro causes the iostream do_open to be renamed, which causes compile errors.
553
596
in Lib/perl5/noembed.h while compiling the wrapper, you will
554
597
have to find the macro that conflicts and add an #undef into the .i file.  Please report
555
598
any conflicting macros you find to <a href="http://www.swig.org/mail.html">swig mailing list</a>.
 
599
</p>
556
600
 
557
601
<H3><a name="Perl5_nn10"></a>23.2.7 Compiling for 64-bit platforms</H3>
558
602
 
559
603
 
 
604
<p>
560
605
On platforms that support 64-bit applications (Solaris, Irix, etc.),
561
606
special care is required when building extension modules.  On these
562
607
machines, 64-bit applications are compiled and linked using a different
563
608
set of compiler/linker options.  In addition, it is not generally possible to mix 
564
609
32-bit and 64-bit code together in the same application.
 
610
</p>
565
611
 
566
612
<p>
567
613
To utilize 64-bits, the Perl executable will need to be recompiled
582
628
<H2><a name="Perl5_nn11"></a>23.3 Building Perl Extensions under Windows</H2>
583
629
 
584
630
 
 
631
<p>
585
632
Building a SWIG extension to Perl under Windows is roughly
586
633
similar to the process used with Unix.  Normally, you will want to
587
634
produce a DLL that can be loaded into the Perl interpreter.  This
588
635
section assumes you are using SWIG with Microsoft Visual C++
589
636
although the procedure may be similar with other compilers.  
 
637
</p>
590
638
 
591
639
<H3><a name="Perl5_nn12"></a>23.3.1 Running SWIG from Developer Studio</H3>
592
640
 
643
691
use the use command as normal. For example :
644
692
</p>
645
693
 
646
 
<blockquote><pre>
 
694
<div class="code"><pre>
647
695
DOS &gt; perl
648
696
use example;
649
697
$a = example::fact(4);
650
698
print "$a\n";
651
699
 
652
 
</pre></blockquote>
 
700
</pre></div>
653
701
 
654
702
<H3><a name="Perl5_nn13"></a>23.3.2 Using other compilers</H3>
655
703
 
656
704
 
 
705
<p>
657
706
SWIG is known to work with Cygwin and may work with other compilers on Windows.
658
707
For general hints and suggestions refer to the <a href="Windows.html#Windows">Windows</a> chapter.
 
708
</p>
659
709
 
660
710
<H2><a name="Perl5_nn14"></a>23.4 The low-level interface</H2>
661
711
 
662
712
 
 
713
<p>
663
714
At its core, the Perl module uses a simple low-level interface
664
715
to C function, variables, constants, and classes.  This low-level interface
665
716
can be used to control your application.  However, it is also used to
666
717
construct more user-friendly proxy classes as described in the next section.
 
718
</p>
667
719
 
668
720
<H3><a name="Perl5_nn15"></a>23.4.1 Functions</H3>
669
721
 
673
725
subroutines). For example:
674
726
</p>
675
727
 
676
 
<blockquote><pre>
 
728
<div class="code"><pre>
677
729
%module example
678
730
int fact(int a);
679
731
...
680
 
</pre></blockquote>
 
732
</pre></div>
681
733
 
682
734
<p>
683
735
Now, in Perl:
684
736
</p>
685
737
 
686
 
<blockquote><pre>
 
738
<div class="code"><pre>
687
739
use example;
688
740
$a = &amp;example::fact(2);
689
 
</pre></blockquote>
 
741
</pre></div>
690
742
 
691
743
<H3><a name="Perl5_nn16"></a>23.4.2 Global variables</H3>
692
744
 
697
749
that intercept read/write operations and attaches them to a Perl variable with
698
750
the same name as the C global variable. Thus, an interface like this </p>
699
751
 
700
 
<blockquote><pre>
 
752
<div class="code"><pre>
701
753
%module example;
702
754
...
703
755
double Spam;
704
756
...
705
 
</pre></blockquote>
 
757
</pre></div>
706
758
 
707
759
<p>
708
760
is accessed as follows :</p>
709
761
 
710
 
<blockquote><pre>
 
762
<div class="code"><pre>
711
763
use example;
712
764
print $example::Spam,"\n";
713
765
$example::Spam = $example::Spam + 4
714
766
# ... etc ...
715
767
 
716
 
</pre></blockquote>
 
768
</pre></div>
717
769
 
718
770
<p>
719
771
If a variable is declared as <tt>const</tt>, it is wrapped as a
725
777
To make ordinary variables read-only, you can also use the <tt>%immutable</tt> directive. For example:
726
778
</p>
727
779
 
728
 
<blockquote>
 
780
<div class="code">
729
781
<pre>
 
782
%{
 
783
extern char *path;
 
784
%}
730
785
%immutable;
731
786
extern char *path;
732
787
%mutable;
733
788
</pre>
734
 
</blockquote>
735
 
 
736
 
The <tt>%immutable</tt> directive stays in effect until it is explicitly disabled using
737
 
<tt>%mutable</tt>.  It is also possible to tag a specific variable as read-only like this:
738
 
 
739
 
<blockquote>
 
789
</div>
 
790
 
 
791
<p>
 
792
The <tt>%immutable</tt> directive stays in effect until it is explicitly disabled or cleared using
 
793
<tt>%mutable</tt>.
 
794
See the <a href="SWIG.html#SWIG_readonly_variables">Creatng read-only variables</a> section for further details.
 
795
</p>
 
796
 
 
797
<p>
 
798
It is also possible to tag a specific variable as read-only like this:
 
799
</p>
 
800
 
 
801
<div class="code">
740
802
<pre>
 
803
%{
 
804
extern char *path;
 
805
%}
741
806
%immutable path; 
742
807
...
743
808
...
744
809
extern char *path;       // Declared later in the input
745
810
</pre>
746
 
</blockquote>
 
811
</div>
747
812
 
748
813
<H3><a name="Perl5_nn17"></a>23.4.3 Constants</H3>
749
814
 
750
815
 
 
816
<p>
751
817
Constants are wrapped as read-only Perl variables.  For example:
 
818
</p>
752
819
 
753
 
<blockquote>
 
820
<div class="code">
754
821
<pre>
755
822
%module example
756
823
 
757
824
#define FOO 42
758
825
</pre>
759
 
</blockquote>
 
826
</div>
760
827
 
 
828
<p>
761
829
In Perl:
 
830
</p>
762
831
 
763
 
<blockquote>
 
832
<div class="code">
764
833
<pre>
765
834
use example;
766
835
print $example::FOO,"\n";    # OK
767
836
$example::FOO = 2;           # Error
768
837
</pre>
769
 
</blockquote>
 
838
</div>
770
839
 
771
840
<H3><a name="Perl5_nn18"></a>23.4.4 Pointers</H3>
772
841
 
777
846
information attached to it indicating what kind of reference it
778
847
is. That is, if you have a C declaration like this :</p>
779
848
 
780
 
<blockquote><pre>
 
849
<div class="code"><pre>
781
850
Matrix *new_Matrix(int n, int m);
782
 
</pre></blockquote>
 
851
</pre></div>
783
852
 
784
853
<p>
785
854
The module returns a value generated as follows:
786
855
</p>
787
856
 
788
 
<blockquote><pre>
 
857
<div class="code"><pre>
789
858
$ptr = new_Matrix(int n, int m);     # Save pointer return result
790
859
bless $ptr, "p_Matrix";              # Bless it as a pointer to Matrix
791
 
</pre></blockquote>
 
860
</pre></div>
792
861
 
793
862
<p>
794
863
SWIG uses the "blessing" to check the datatype of various pointers.
799
868
To check to see if a value is the NULL pointer, use the
800
869
<tt>defined()</tt> command :</p>
801
870
 
802
 
<blockquote><pre>
 
871
<div class="code"><pre>
803
872
if (defined($ptr)) {
804
873
        print "Not a NULL pointer.";
805
874
} else {
806
875
        print "Is a NULL pointer.";
807
876
}
808
877
 
809
 
</pre></blockquote>
 
878
</pre></div>
810
879
 
811
880
<p>
812
881
To create a NULL pointer, you should pass the <tt>undef </tt>value to
824
893
dereference them as follows :
825
894
</p>
826
895
 
827
 
<blockquote><pre>
 
896
<div class="code"><pre>
828
897
if ($$a == $$b) {
829
898
        print "a and b point to the same thing in C";
830
899
} else {
831
900
        print "a and b point to different objects.";
832
901
}
833
902
 
834
 
</pre></blockquote>
 
903
</pre></div>
835
904
 
 
905
<p>
836
906
As much as you might be inclined to modify a pointer value directly
837
907
from Perl, don't.  Manipulating pointer values is architecture dependent and
838
908
could cause your program to crash.  Similarly, don't try to manually cast
841
911
casting C++ objects. If you need to cast a pointer or
842
912
change its value, consider writing some helper functions instead.  For
843
913
example:
 
914
</p>
844
915
 
845
 
<blockquote>
 
916
<div class="code">
846
917
<pre>
847
918
%inline %{
848
919
/* C-style cast */
860
931
}
861
932
%}
862
933
</pre>
863
 
</blockquote>
 
934
</div>
864
935
 
 
936
<p>
865
937
Also, if working with C++, you should always try
866
938
to use the new C++ style casts.  For example, in the above code, the
867
939
C-style cast may return a bogus result whereas as the C++-style cast will return
868
940
<tt>NULL</tt> if the conversion can't be performed.
 
941
</p>
869
942
 
870
943
<p>
871
944
<b>Compatibility Note:</b> In earlier versions, SWIG tried to preserve the same pointer naming conventions
881
954
accessor functions as described in the "SWIG Basics" chapter.  For example,
882
955
</p>
883
956
 
884
 
<blockquote><pre>
 
957
<div class="code"><pre>
885
958
struct Vector {
886
959
        double x,y,z;
887
960
};
888
 
</pre></blockquote>
 
961
</pre></div>
889
962
 
890
963
<p>
891
964
gets mapped into the following collection of accessor functions:
892
965
</p>
893
966
 
894
 
<blockquote><pre>
 
967
<div class="code"><pre>
895
968
struct Vector *new_Vector();
896
969
void           delete_Vector(Vector *v);
897
970
double         Vector_x_get(Vector *obj)
901
974
double         Vector_z_get(Vector *obj)
902
975
void           Vector_z_set(Vector *obj, double z)
903
976
 
904
 
</pre></blockquote>
 
977
</pre></div>
905
978
 
906
979
<p>
907
980
These functions are then used to access structure data from Perl as follows:
908
981
</p>
909
982
 
910
 
<blockquote><pre>
 
983
<div class="code"><pre>
911
984
$v = example::new_Vector();
912
985
print example::Vector_x_get($v),"\n";    # Get x component
913
986
example::Vector_x_set($v,7.8);          # Change x component
914
 
</pre></blockquote>
 
987
</pre></div>
915
988
 
916
989
<p>
917
990
Similar access is provided for unions and the data members of C++ classes.
922
995
can also be forced to be read-only using the <tt>%immutable</tt> directive. For example:
923
996
</p>
924
997
 
925
 
<blockquote>
 
998
<div class="code">
926
999
<pre>
927
1000
struct Foo {
928
1001
   ...
933
1006
   ...
934
1007
};
935
1008
</pre>
936
 
</blockquote>
 
1009
</div>
937
1010
 
938
1011
<p>
939
1012
When <tt>char *</tt> members of a structure are wrapped, the contents are assumed to be
947
1020
Array members are normally wrapped as read-only.   For example,
948
1021
</p>
949
1022
 
950
 
<blockquote>
 
1023
<div class="code">
951
1024
<pre>
952
1025
struct Foo {
953
1026
   int  x[50];
954
1027
};
955
1028
</pre>
956
 
</blockquote>
 
1029
</div>
957
1030
 
 
1031
<p>
958
1032
produces a single accessor function like this:
 
1033
</p>
959
1034
 
960
 
<blockquote>
 
1035
<div class="code">
961
1036
<pre>
962
1037
int *Foo_x_get(Foo *self) {
963
1038
    return self-&gt;x;
964
1039
};
965
1040
</pre>
966
 
</blockquote>
 
1041
</div>
967
1042
 
 
1043
<p>
968
1044
If you want to set an array member, you will need to supply a "memberin" typemap
969
1045
described later in this chapter.  As a special case, SWIG does generate
970
1046
code to set array members of type <tt>char</tt> (allowing you to store a Python
971
1047
string in the structure).
 
1048
</p>
972
1049
 
973
1050
<p>
974
1051
When structure members are wrapped, they are handled as pointers.   For example,
975
1052
</p>
976
1053
 
977
 
<blockquote>
 
1054
<div class="code">
978
1055
<pre>
979
1056
struct Foo {
980
1057
   ...
984
1061
   Foo f;
985
1062
};
986
1063
</pre>
987
 
</blockquote>
 
1064
</div>
988
1065
 
 
1066
<p>
989
1067
generates accessor functions such as this:
 
1068
</p>
990
1069
 
991
 
<blockquote>
 
1070
<div class="code">
992
1071
<pre>
993
1072
Foo *Bar_f_get(Bar *b) {
994
1073
    return &amp;b-&gt;f;
998
1077
    b-&gt;f = *val;
999
1078
}
1000
1079
</pre>
1001
 
</blockquote>
 
1080
</div>
1002
1081
 
1003
1082
 
1004
1083
<H3><a name="Perl5_nn20"></a>23.4.6 C++ classes</H3>
1009
1088
Consider the following class :
1010
1089
</p>
1011
1090
 
1012
 
<blockquote><pre>
 
1091
<div class="code"><pre>
1013
1092
class List {
1014
1093
public:
1015
1094
  List();
1021
1100
  int  length;
1022
1101
static void print(List *l);
1023
1102
};
1024
 
</pre></blockquote>
 
1103
</pre></div>
1025
1104
 
1026
1105
<p>
1027
1106
When wrapped by SWIG, the following functions are created :
1028
1107
</p>
1029
1108
 
1030
 
<blockquote><pre>
 
1109
<div class="code"><pre>
1031
1110
List    *new_List();
1032
1111
void     delete_List(List *l);
1033
1112
int      List_search(List *l, char *item);
1038
1117
void     List_length_set(List *l, int n);
1039
1118
void     List_print(List *l);
1040
1119
 
1041
 
</pre></blockquote>
 
1120
</pre></div>
1042
1121
 
 
1122
<p>
1043
1123
In Perl, these functions are used in a straightforward manner:
 
1124
</p>
1044
1125
 
1045
 
<blockquote><pre>
 
1126
<div class="code"><pre>
1046
1127
use example;
1047
1128
$l = example::new_List();
1048
1129
example::List_insert($l,"Ale");
1054
1135
Ale
1055
1136
print example::List_length_get($l),"\n";
1056
1137
3
1057
 
</pre></blockquote>
 
1138
</pre></div>
1058
1139
 
 
1140
<p>
1059
1141
At this low level, C++ objects are really just typed pointers.  Member
1060
1142
functions are accessed by calling a C-like wrapper with an instance pointer
1061
1143
as the first argument.   Although this interface is fairly primitive, it
1062
1144
provides direct access to C++ objects.  A higher level interface using Perl proxy classes
1063
1145
can be built using these low-level accessors.  This is described shortly.
 
1146
</p>
1064
1147
 
1065
1148
<H3><a name="Perl5_nn21"></a>23.4.7 C++ classes and type-checking</H3>
1066
1149
 
1067
1150
 
 
1151
<p>
1068
1152
The SWIG type-checker is fully aware of C++ inheritance.  Therefore, if you have
1069
1153
classes like this
 
1154
</p>
1070
1155
 
1071
 
<blockquote>
 
1156
<div class="code">
1072
1157
<pre>
1073
1158
class Foo {
1074
1159
...
1078
1163
...
1079
1164
};
1080
1165
</pre>
1081
 
</blockquote>
 
1166
</div>
1082
1167
 
 
1168
<p>
1083
1169
and a function
 
1170
</p>
1084
1171
 
1085
 
<blockquote>
 
1172
<div class="code">
1086
1173
<pre>
1087
1174
void spam(Foo *f);
1088
1175
</pre>
1089
 
</blockquote>
 
1176
</div>
1090
1177
 
 
1178
<p>
1091
1179
then the function <tt>spam()</tt> accepts <tt>Foo *</tt> or a pointer to any class derived from <tt>Foo</tt>.
1092
1180
If necesssary, the type-checker also adjusts the value of the pointer (as is necessary when
1093
1181
multiple inheritance is used).
 
1182
</p>
1094
1183
 
1095
1184
<H3><a name="Perl5_nn22"></a>23.4.8 C++ overloaded functions</H3>
1096
1185
 
1097
1186
 
 
1187
<p>
1098
1188
If you have a C++ program with overloaded functions or methods, you will need to disambiguate
1099
1189
those methods using <tt>%rename</tt>.   For example:
 
1190
</p>
1100
1191
 
1101
 
<blockquote>
 
1192
<div class="code">
1102
1193
<pre>
1103
1194
/* Forward renaming declarations */
1104
1195
%rename(foo_i) foo(int); 
1114
1205
   ...
1115
1206
};
1116
1207
</pre>
1117
 
</blockquote>
 
1208
</div>
1118
1209
 
 
1210
<p>
1119
1211
Now, in Perl, the methods are accessed as follows:
 
1212
</p>
1120
1213
 
1121
 
<blockquote>
 
1214
<div class="code">
1122
1215
<pre>
1123
1216
use example;
1124
1217
example::foo_i(3);
1126
1219
example::Spam_foo_i($s,3);
1127
1220
example::Spam_foo_d($s,3.14);
1128
1221
</pre>
1129
 
</blockquote>
 
1222
</div>
1130
1223
 
 
1224
<p>
1131
1225
Please refer to the "SWIG Basics" chapter for more information. 
 
1226
</p>
1132
1227
 
1133
1228
<H3><a name="Perl5_nn23"></a>23.4.9 Operators</H3>
1134
1229
 
1135
1230
 
 
1231
<p>
1136
1232
C++ operators can also be wrapped using the <tt>%rename</tt> directive.  All you need to do is
1137
1233
give the operator the name of a valid Perl identifier.  For example:
 
1234
</p>
1138
1235
 
1139
 
<blockquote>
 
1236
<div class="code">
1140
1237
<pre>
1141
1238
%rename(add_complex) operator+(Complex &amp;, Complex &amp;);
1142
1239
...
1143
1240
Complex operator+(Complex &amp;, Complex &amp;);
1144
1241
</pre>
1145
 
</blockquote>
 
1242
</div>
1146
1243
 
 
1244
<p>
1147
1245
Now, in Perl, you can do this:
 
1246
</p>
1148
1247
 
1149
 
<blockquote>
 
1248
<div class="code">
1150
1249
<pre>
1151
1250
use example;
1152
1251
$a = example::new_Complex(2,3);
1153
1252
$b = example::new_Complex(4,-1);
1154
1253
$c = example::add_complex($a,$b);
1155
1254
</pre>
1156
 
</blockquote>
 
1255
</div>
1157
1256
 
 
1257
<p>
1158
1258
Some preliminary work on mapping C++ operators into Perl operators has been completed. This is covered later.
 
1259
</p>
1159
1260
 
1160
1261
<H3><a name="Perl5_nn24"></a>23.4.10 Modules and packages</H3>
1161
1262
 
1166
1267
<tt>%module</tt> directive. To use the module, do the following :
1167
1268
</p>
1168
1269
 
1169
 
<blockquote><pre>
 
1270
<div class="code"><pre>
1170
1271
% perl5
1171
1272
use example;                      # load the example module
1172
1273
print example::fact(4),"\n"       # Call a function in it
1173
1274
24
1174
 
</pre></blockquote>
 
1275
</pre></div>
1175
1276
 
1176
1277
<p>
1177
1278
Usually, a module consists of a collection of code that is contained
1194
1295
nested namespace simply provide the fully qualified name in your
1195
1296
%module directive: </p>
1196
1297
 
1197
 
<blockquote><pre>
 
1298
<div class="code"><pre>
1198
1299
%module "Foo::Bar::Baz"
1199
 
</pre></blockquote>
 
1300
</pre></div>
1200
1301
 
1201
1302
<p>
1202
1303
<b>NOTE:</b> the double quotes are necessary.
1208
1309
option :
1209
1310
</p>
1210
1311
 
1211
 
<blockquote><pre>
 
1312
<div class="code"><pre>
1212
1313
% swig -perl -package Foo example.i
1213
 
</pre></blockquote>
 
1314
</pre></div>
1214
1315
 
1215
1316
<p>
1216
1317
In this case, you still create a module called `<tt>example</tt>' exactly as before, but
1218
1319
`<tt>Foo</tt>.' For example :
1219
1320
</p>
1220
1321
 
1221
 
<blockquote><pre>
 
1322
<div class="code"><pre>
1222
1323
use example;   # Load the module like before
1223
1324
print Foo::fact(4),"\n";        # Call a function in package FooBar
1224
 
</pre></blockquote>
 
1325
</pre></div>
1225
1326
-->
1226
1327
 
1227
1328
<H2><a name="Perl5_nn25"></a>23.5 Input and output parameters</H2>
1228
1329
 
1229
1330
 
 
1331
<p>
1230
1332
A common problem in some C programs is handling parameters passed as simple pointers.  For
1231
1333
example:
 
1334
</p>
1232
1335
 
1233
 
<blockquote>
 
1336
<div class="code">
1234
1337
<pre>
1235
1338
void add(int x, int y, int *result) {
1236
1339
   *result = x + y;
1237
1340
}
1238
1341
</pre>
1239
 
</blockquote>
 
1342
</div>
1240
1343
 
 
1344
<p>
1241
1345
or perhaps
 
1346
</p>
1242
1347
 
1243
 
<blockquote>
 
1348
<div class="code">
1244
1349
<pre>
1245
1350
int sub(int *x, int *y) {
1246
1351
   return *x+*y;
1247
1352
}
1248
1353
</pre>
1249
 
</blockquote>
 
1354
</div>
1250
1355
 
 
1356
<p>
1251
1357
The easiest way to handle these situations is to use the <tt>typemaps.i</tt> file.  For example:
 
1358
</p>
1252
1359
 
1253
 
<blockquote>
 
1360
<div class="code">
1254
1361
<pre>
1255
1362
%module example
1256
1363
%include "typemaps.i"
1258
1365
void add(int, int, int *OUTPUT);
1259
1366
int  sub(int *INPUT, int *INPUT);
1260
1367
</pre>
1261
 
</blockquote>
 
1368
</div>
1262
1369
 
 
1370
<p>
1263
1371
In Perl, this allows you to pass simple values.  For example:
 
1372
</p>
1264
1373
 
1265
 
<blockquote>
 
1374
<div class="code">
1266
1375
<pre>
1267
1376
$a = example::add(3,4);
1268
1377
print "$a\n";
1271
1380
print "$b\n";
1272
1381
3
1273
1382
</pre>
1274
 
</blockquote>
 
1383
</div>
1275
1384
 
1276
1385
<p>
1277
1386
Notice how the <tt>INPUT</tt> parameters allow integer values to be passed instead of pointers
1283
1392
directive.  For example:
1284
1393
</p>
1285
1394
 
1286
 
<blockquote>
 
1395
<div class="code">
1287
1396
<pre>
1288
1397
%module example
1289
1398
%include "typemaps.i"
1294
1403
void add(int x, int y, int *result);
1295
1404
int  sub(int *x, int *y);
1296
1405
</pre>
1297
 
</blockquote>
 
1406
</div>
1298
1407
 
1299
1408
<p>
1300
1409
If a function mutates one of its parameters like this,
1301
1410
</p>
1302
1411
 
1303
 
<blockquote>
 
1412
<div class="code">
1304
1413
<pre>
1305
1414
void negate(int *x) {
1306
1415
   *x = -(*x);
1307
1416
}
1308
1417
</pre>
1309
 
</blockquote>
 
1418
</div>
1310
1419
 
 
1420
<p>
1311
1421
you can use <tt>INOUT</tt> like this:
 
1422
</p>
1312
1423
 
1313
 
<blockquote>
 
1424
<div class="code">
1314
1425
<pre>
1315
1426
%include "typemaps.i"
1316
1427
...
1317
1428
void negate(int *INOUT);
1318
1429
</pre>
1319
 
</blockquote>
 
1430
</div>
1320
1431
 
 
1432
<p>
1321
1433
In Perl, a mutated parameter shows up as a return value.  For example:
 
1434
</p>
1322
1435
 
1323
 
<blockquote>
 
1436
<div class="code">
1324
1437
<pre>
1325
1438
$a = example::negate(3);
1326
1439
print "$a\n";
1327
1440
-3
1328
1441
</pre>
1329
 
</blockquote>
 
1442
</div>
1330
1443
 
1331
1444
<p>
1332
1445
The most common use of these special typemap rules is to handle functions that
1334
1447
as well as a special error code:
1335
1448
</p>
1336
1449
 
1337
 
<blockquote>
 
1450
<div class="code">
1338
1451
<pre>
1339
1452
/* send message, return number of bytes sent, along with success code */
1340
1453
int send_message(char *text, int len, int *success);
1341
1454
</pre>
1342
 
</blockquote>
 
1455
</div>
1343
1456
 
 
1457
<p>
1344
1458
To wrap such a function, simply use the <tt>OUTPUT</tt> rule above. For example:
 
1459
</p>
1345
1460
 
1346
 
<blockquote>
 
1461
<div class="code">
1347
1462
<pre>
1348
1463
%module example
1349
1464
%include "typemaps.i"
1351
1466
...
1352
1467
int send_message(char *text, int *success);
1353
1468
</pre>
1354
 
</blockquote>
 
1469
</div>
1355
1470
 
 
1471
<p>
1356
1472
When used in Perl, the function will return multiple values.  
 
1473
</p>
1357
1474
 
1358
 
<blockquote>
 
1475
<div class="code">
1359
1476
<pre>
1360
1477
($bytes, $success) = example::send_message("Hello World");
1361
1478
</pre>
1362
 
</blockquote>
 
1479
</div>
1363
1480
 
 
1481
<p>
1364
1482
Another common use of multiple return values are in query functions.  For example:
 
1483
</p>
1365
1484
 
1366
 
<blockquote>
 
1485
<div class="code">
1367
1486
<pre>
1368
1487
void get_dimensions(Matrix *m, int *rows, int *columns);
1369
1488
</pre>
1370
 
</blockquote>
 
1489
</div>
1371
1490
 
 
1491
<p>
1372
1492
To wrap this, you might use the following:
 
1493
</p>
1373
1494
 
1374
 
<blockquote>
 
1495
<div class="code">
1375
1496
<pre>
1376
1497
%module example
1377
1498
%include "typemaps.i"
1379
1500
...
1380
1501
void get_dimensions(Matrix *m, int *rows, *columns);
1381
1502
</pre>
1382
 
</blockquote>
 
1503
</div>
1383
1504
 
 
1505
<p>
1384
1506
Now, in Perl:
 
1507
</p>
1385
1508
 
1386
 
<blockquote>
 
1509
<div class="code">
1387
1510
<pre>
1388
1511
($r,$c) = example::get_dimensions($m);
1389
1512
</pre>
1390
 
</blockquote>
 
1513
</div>
1391
1514
 
 
1515
<p>
1392
1516
In certain cases, it is possible to treat Perl references as C pointers.  To do this, use the <tt>REFERENCE</tt> typemap.  For
1393
1517
example:
 
1518
</p>
1394
1519
 
1395
 
<blockquote>
 
1520
<div class="code">
1396
1521
<pre>
1397
1522
%module example
1398
1523
%include typemaps.i
1399
1524
 
1400
1525
void add(int x, int y, int *REFERENCE);
1401
1526
</pre>
1402
 
</blockquote>
 
1527
</div>
1403
1528
 
 
1529
<p>
1404
1530
In Perl:
 
1531
</p>
1405
1532
 
1406
 
<blockquote>
 
1533
<div class="code">
1407
1534
<pre>
1408
1535
use example;
1409
1536
$c = 0.0;
1411
1538
print "$c\n";
1412
1539
7
1413
1540
</pre>
1414
 
</blockquote>
 
1541
</div>
1415
1542
 
 
1543
<p>
1416
1544
<b>Note:</b> The <tt>REFERENCE</tt> feature is only currently supported for numeric types (integers and floating point).
 
1545
</p>
1417
1546
 
1418
1547
<H2><a name="Perl5_nn26"></a>23.6 Exception handling </H2>
1419
1548
 
1426
1555
following :
1427
1556
</p>
1428
1557
 
1429
 
<blockquote><pre>
 
1558
<div class="code"><pre>
1430
1559
class RangeError {};   // Used for an exception
1431
1560
 
1432
1561
class DoubleArray {
1465
1594
      }
1466
1595
    }
1467
1596
  };
1468
 
</pre></blockquote>
 
1597
</pre></div>
1469
1598
 
1470
1599
<p>
1471
1600
Since several methods in this class can throw an exception
1474
1603
interface file:
1475
1604
</p>
1476
1605
 
1477
 
<blockquote><pre>
 
1606
<div class="code"><pre>
1478
1607
%exception {
1479
1608
  try {
1480
1609
    $action
1487
1616
class DoubleArray {
1488
1617
...
1489
1618
};
1490
 
</pre></blockquote>
 
1619
</pre></div>
1491
1620
 
1492
1621
<p>
1493
1622
The exception handling code is inserted directly into generated wrapper
1503
1632
exception handler to only apply to specific methods like this:
1504
1633
</p>
1505
1634
 
1506
 
<blockquote>
 
1635
<div class="code">
1507
1636
<pre>
1508
1637
%exception getitem {
1509
1638
  try {
1523
1652
  }
1524
1653
}
1525
1654
</pre>
1526
 
</blockquote>
 
1655
</div>
1527
1656
 
 
1657
<p>
1528
1658
In this case, the exception handler is only attached to methods and functions
1529
1659
named <tt>getitem</tt> and <tt>setitem</tt>.
 
1660
</p>
1530
1661
 
1531
1662
<p>
1532
1663
If you had a lot of different methods, you can avoid extra typing by using a macro.
1533
1664
For example:
1534
1665
</p>
1535
1666
 
1536
 
<blockquote>
 
1667
<div class="code">
1537
1668
<pre>
1538
1669
%define RANGE_ERROR
1539
1670
{
1549
1680
%exception getitem RANGE_ERROR;
1550
1681
%exception setitem RANGE_ERROR;
1551
1682
</pre>
1552
 
</blockquote>
 
1683
</div>
1553
1684
 
 
1685
<p>
1554
1686
Since SWIG's exception handling is user-definable, you are not limited to C++ exception handling.
1555
1687
See the chapter on "<a href="Customization.html#Customization">Customization features</a>" for more examples.
 
1688
</p>
1556
1689
 
1557
1690
<p>
1558
1691
<b>Compatibility note:</b> In SWIG1.1, exceptions were defined using the older <tt>%except</tt> directive:
1559
1692
</p>
1560
1693
 
1561
 
<blockquote>
 
1694
<div class="code">
1562
1695
<pre>
1563
1696
%except(python) {
1564
1697
  try {
1569
1702
  }
1570
1703
}
1571
1704
</pre>
1572
 
</blockquote>
 
1705
</div>
1573
1706
 
 
1707
<p>
1574
1708
This is still supported, but it is deprecated.  The newer <tt>%exception</tt> directive provides the same
1575
1709
functionality, but it has additional capabilities that make it more powerful.
 
1710
</p>
1576
1711
 
1577
1712
<H2><a name="Perl5_nn27"></a>23.7 Remapping datatypes with typemaps</H2>
1578
1713
 
1600
1735
you might define a typemap like this:
1601
1736
</p>
1602
1737
 
1603
 
<blockquote><pre>
 
1738
<div class="code"><pre>
1604
1739
%module example
1605
1740
 
1606
1741
%typemap(in) int {
1608
1743
        printf("Received an integer : %d\n", $1);
1609
1744
}
1610
1745
...
 
1746
%inline %{
1611
1747
extern int fact(int n);
 
1748
%}
1612
1749
 
1613
 
</pre></blockquote>
 
1750
</pre></div>
1614
1751
 
1615
1752
<p>
1616
1753
Typemaps are always associated with some specific aspect of code generation.
1626
1763
When this example is used in Perl5, it will operate as follows :
1627
1764
</p>
1628
1765
 
1629
 
<blockquote><pre>
 
1766
<div class="code"><pre>
1630
1767
use example;
1631
1768
$n = example::fact(6);
1632
1769
print "$n\n";
1635
1772
Output :
1636
1773
Received an integer : 6
1637
1774
720
1638
 
</pre></blockquote>
 
1775
</pre></div>
1639
1776
 
1640
1777
<p>
1641
1778
The application of a typemap to specific datatypes and argument names involves
1645
1782
the typemap system follows <tt>typedef</tt> declarations.  For example:
1646
1783
</p>
1647
1784
 
1648
 
<blockquote>
 
1785
<div class="code">
1649
1786
<pre>
1650
1787
%typemap(in) int n {
1651
1788
        $1 = (int) SvIV($input);
1652
1789
        printf("n = %d\n",$1);
1653
1790
}
 
1791
%inline %{
1654
1792
typedef int Integer;
1655
1793
extern int fact(Integer n);    // Above typemap is applied
 
1794
%}
1656
1795
</pre>
1657
 
</blockquote>
 
1796
</div>
1658
1797
 
 
1798
<p>
1659
1799
It should be noted that the matching of <tt>typedef</tt> only occurs in one direction.  If you
1660
1800
defined a typemap for <tt>Integer</tt>, it is not applied to arguments of
1661
1801
type <tt>int</tt>.
 
1802
</p>
1662
1803
 
1663
1804
<p>
1664
1805
Typemaps can also be defined for groups of consecutive arguments.  For example:
1665
1806
</p>
1666
1807
 
1667
 
<blockquote>
 
1808
<div class="code">
1668
1809
<pre>
1669
1810
%typemap(in) (char *str, unsigned len) {
1670
1811
    $1 = SvPV($input,$2);
1672
1813
 
1673
1814
int count(char c, char *str, unsigned len);
1674
1815
</pre>
1675
 
</blockquote>
 
1816
</div>
1676
1817
 
 
1818
<p>
1677
1819
When a multi-argument typemap is defined, the arguments are always handled as a single
1678
1820
Perl object.  This allows the function to be used like this (notice how the length
1679
1821
parameter is ommitted):
 
1822
</p>
1680
1823
 
1681
 
<blockquote>
 
1824
<div class="code">
1682
1825
<pre>
1683
1826
example::count("e","Hello World");
1684
1827
1
1685
1828
&gt;&gt;&gt;
1686
1829
</pre>
1687
 
</blockquote>
 
1830
</div>
1688
1831
 
1689
1832
 
1690
1833
<H3><a name="Perl5_nn29"></a>23.7.2 Perl5 typemaps</H3>
1691
1834
 
1692
1835
 
 
1836
<p>
1693
1837
The previous section illustrated an "in" typemap for converting Perl objects to C.
1694
1838
A variety of different typemap methods are defined by the Perl module.  For example,
1695
1839
to convert a C integer back into a Perl object, you might define an "out" typemap
1696
1840
like this:
1697
 
 
1698
 
 
1699
 
<blockquote>
 
1841
</p>
 
1842
 
 
1843
 
 
1844
<div class="code">
1700
1845
<pre>
1701
1846
%typemap(out) int {
1702
1847
    $result = sv_newmortal();
1704
1849
    argvi++;
1705
1850
}
1706
1851
</pre>
1707
 
</blockquote>
 
1852
</div>
1708
1853
 
1709
1854
<p>
1710
1855
The following typemap methods are available:
1714
1859
<tt>%typemap(in)</tt>
1715
1860
</p>
1716
1861
 
1717
 
<blockquote>
 
1862
<div class="indent">
1718
1863
Converts Perl5 object to input function arguments.
1719
 
</blockquote>
 
1864
</div>
1720
1865
 
1721
1866
<p>
1722
1867
<tt>%typemap(out)</tt>
1723
1868
</p>
1724
1869
 
1725
 
<blockquote>
 
1870
<div class="indent">
1726
1871
Converts function return value to a Perl5 value.
1727
 
</blockquote>
 
1872
</div>
1728
1873
 
1729
1874
<p>
1730
1875
<tt>%typemap(varin)</tt>
1731
1876
</p>
1732
1877
 
1733
 
<blockquote>
 
1878
<div class="indent">
1734
1879
Converts a Perl5 object to a global variable.
1735
 
</blockquote>
 
1880
</div>
1736
1881
 
1737
1882
<p>
1738
1883
<tt>%typemap(varout)</tt>
1739
1884
</p>
1740
1885
 
1741
 
<blockquote>
 
1886
<div class="indent">
1742
1887
Converts a global variable to a Perl5 object.
1743
 
</blockquote>
 
1888
</div>
1744
1889
 
1745
1890
<p>
1746
1891
<tt>%typemap(freearg)</tt>
1747
1892
</p>
1748
1893
 
1749
 
<blockquote>
 
1894
<div class="indent">
1750
1895
Cleans up a function argument after a function call
1751
 
</blockquote>
 
1896
</div>
1752
1897
 
1753
1898
<p>
1754
1899
<tt>%typemap(argout)</tt>
1755
1900
</p>
1756
1901
 
1757
 
<blockquote>
 
1902
<div class="indent">
1758
1903
Output argument handling
1759
 
</blockquote>
 
1904
</div>
1760
1905
 
1761
1906
<p>
1762
1907
<tt>%typemap(ret)</tt>
1763
1908
</p>
1764
1909
 
1765
 
<blockquote>
 
1910
<div class="indent">
1766
1911
Clean up return value from a function.
1767
 
</blockquote>
 
1912
</div>
1768
1913
 
1769
1914
<p>
1770
1915
<tt>%typemap(memberin)</tt>
1771
1916
</p>
1772
1917
 
1773
 
<blockquote>
 
1918
<div class="indent">
1774
1919
Setting of C++ member data (all languages).
1775
 
</blockquote>
 
1920
</div>
1776
1921
 
1777
1922
<p>
1778
1923
<tt>%typemap(memberout)</tt>
1779
1924
</p>
1780
1925
 
1781
 
<blockquote>
 
1926
<div class="indent">
1782
1927
Return of C++ member data (all languages).
1783
 
</blockquote>
 
1928
</div>
1784
1929
 
1785
1930
<p>
1786
1931
<tt>%typemap(check)</tt>
1787
1932
</p>
1788
1933
 
1789
 
<blockquote>
 
1934
<div class="indent">
1790
1935
Check value of input parameter.
1791
 
</blockquote>
 
1936
</div>
1792
1937
 
1793
1938
<H3><a name="Perl5_nn30"></a>23.7.3 Typemap variables</H3>
1794
1939
 
1795
1940
 
 
1941
<p>
1796
1942
Within typemap code, a number of special variables prefaced with a <tt>$</tt> may appear.
1797
1943
A full list of variables can be found in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter.
1798
1944
This is a list of the most common variables:
 
1945
</p>
1799
1946
 
1800
1947
<p>
1801
1948
<tt>$1</tt>
1802
1949
</p>
1803
1950
 
1804
 
<blockquote>
 
1951
<div class="indent">
1805
1952
A C local variable corresponding to the actual type specified in the
1806
1953
<tt>%typemap</tt> directive.  For input values, this is a C local variable
1807
1954
that's supposed to hold an argument value.  For output values, this is
1808
1955
the raw result that's supposed to be returned to Perl.
1809
 
</blockquote>
 
1956
</div>
1810
1957
 
1811
1958
<p>
1812
1959
<tt>$input</tt>
1813
1960
</p>
1814
1961
 
1815
 
<blockquote>
 
1962
<div class="indent">
1816
1963
A Perl object holding the value of an argument of variable value.
1817
 
</blockquote>
 
1964
</div>
1818
1965
 
1819
1966
<p>
1820
1967
<tt>$result</tt>
1821
1968
</p>
1822
1969
 
1823
 
<blockquote>
 
1970
<div class="indent">
1824
1971
A Perl object that holds the result to be returned to Perl.
1825
 
</blockquote>
 
1972
</div>
1826
1973
 
1827
1974
<p>
1828
1975
<tt>$1_name</tt>
1829
1976
</p>
1830
1977
 
1831
 
<blockquote>
 
1978
<div class="indent">
1832
1979
The parameter name that was matched. 
1833
 
</blockquote>
 
1980
</div>
1834
1981
 
1835
1982
<p>
1836
1983
<tt>$1_type</tt>
1837
1984
</p>
1838
1985
 
1839
 
<blockquote>
 
1986
<div class="indent">
1840
1987
The actual C datatype matched by the typemap.
1841
 
</blockquote>
 
1988
</div>
1842
1989
 
1843
1990
<p>
1844
1991
<tt>$1_ltype</tt>
1845
1992
</p>
1846
1993
 
1847
 
<blockquote>
 
1994
<div class="indent">
1848
1995
An assignable version of the datatype matched by the typemap (a type that can appear on the left-hand-side of
1849
1996
a C assignment operation).  This type is stripped of qualifiers and may be an altered version of <tt>$1_type</tt>.
1850
1997
All arguments and local variables in wrapper functions are declared using this type so that their values can be
1851
1998
properly assigned.
1852
 
</blockquote>
 
1999
</div>
1853
2000
 
 
2001
<p>
1854
2002
<tt>$symname</tt>
1855
 
<blockquote>
 
2003
</p>
 
2004
 
 
2005
<div class="indent">
1856
2006
The Perl name of the wrapper function being created.
1857
 
</blockquote>
 
2007
</div>
1858
2008
 
1859
2009
<H3><a name="Perl5_nn31"></a>23.7.4 Useful functions</H3>
1860
2010
 
1873
2023
<b>Perl Integer Functions</b>
1874
2024
</p>
1875
2025
 
1876
 
<blockquote>
 
2026
<div class="code">
1877
2027
<pre>
1878
2028
int   SvIV(SV *);
1879
2029
void  sv_setiv(SV *sv, IV value);
1880
2030
SV   *newSViv(IV value);
1881
2031
int   SvIOK(SV *);
1882
2032
</pre>
1883
 
</blockquote>
 
2033
</div>
1884
2034
 
 
2035
<p>
1885
2036
<b>Perl Floating Point Functions</b>
 
2037
</p>
1886
2038
 
1887
 
<blockquote>
 
2039
<div class="code">
1888
2040
<pre>
1889
2041
double SvNV(SV *);
1890
2042
void   sv_setnv(SV *, double value);
1891
2043
SV    *newSVnv(double value);
1892
2044
int    SvNOK(SV *);
1893
2045
</pre>
1894
 
</blockquote>
 
2046
</div>
1895
2047
 
 
2048
<p>
1896
2049
<b>Perl String Functions</b>
 
2050
</p>
1897
2051
 
1898
 
<blockquote>
 
2052
<div class="code">
1899
2053
<pre>
1900
2054
char     *SvPV(SV *, STRLEN len);
1901
2055
void      sv_setpv(SV *, char *val);
1905
2059
void      sv_catpv(SV *, char *);
1906
2060
void      sv_catpvn(SV *, char *, STRLEN);
1907
2061
</pre>
1908
 
</blockquote>
 
2062
</div>
1909
2063
 
 
2064
<p>
1910
2065
<b>Perl References</b>
 
2066
</p>
1911
2067
 
1912
 
<blockquote>
 
2068
<div class="code">
1913
2069
<pre>
1914
2070
void      sv_setref_pv(SV *, char *, void *ptr);
1915
2071
int       sv_isobject(SV *);
1916
2072
SV       *SvRV(SV *);
1917
2073
int       sv_isa(SV *, char *0;
1918
2074
</pre>
1919
 
</blockquote>
 
2075
</div>
1920
2076
 
1921
2077
 
1922
2078
<H2><a name="Perl5_nn32"></a>23.8 Typemap Examples</H2>
1923
2079
 
1924
2080
 
 
2081
<p>
1925
2082
This section includes a few examples of typemaps.  For more examples, you
1926
2083
might look at the files "<tt>perl5.swg</tt>" and "<tt>typemaps.i</tt>" in
1927
2084
the SWIG library.
 
2085
</p>
1928
2086
 
1929
2087
<H3><a name="Perl5_nn33"></a>23.8.1 Converting a Perl5 array to a char ** </H3>
1930
2088
 
1936
2094
reference to be used as a char ** datatype.
1937
2095
</p>
1938
2096
 
1939
 
<blockquote><pre>
 
2097
<div class="code"><pre>
1940
2098
%module argv
1941
2099
 
1942
2100
// This tells SWIG to treat char ** as a special case
2002
2160
}
2003
2161
%}
2004
2162
 
2005
 
</pre></blockquote>
 
2163
</pre></div>
2006
2164
 
2007
2165
<p>
2008
2166
When this module is compiled, the wrapped C functions can be used in a
2009
2167
Perl script as follows :
2010
2168
</p>
2011
2169
 
2012
 
<blockquote><pre>
 
2170
<div class="code"><pre>
2013
2171
use argv;
2014
2172
@a = ("Dave", "Mike", "John", "Mary");           # Create an array of strings
2015
2173
argv::print_args(\@a);                           # Pass it to our C function
2016
2174
$b = argv::get_args();                           # Get array of strings from C
2017
2175
print @$b,"\n";                                  # Print it out
2018
 
</pre></blockquote>
 
2176
</pre></div>
2019
2177
 
2020
2178
 
2021
2179
<H3><a name="Perl5_nn34"></a>23.8.2 Return values </H3>
2036
2194
can be done using the <tt>EXTEND()</tt> macro as in :
2037
2195
</p>
2038
2196
 
2039
 
<blockquote><pre>
 
2197
<div class="code"><pre>
2040
2198
%typemap(argout) int *OUTPUT {
2041
2199
        if (argvi &gt;= items) {            
2042
2200
                EXTEND(sp,1);              /* Extend the stack by 1 object */
2045
2203
        sv_setiv($target,(IV) *($1));
2046
2204
        argvi++;
2047
2205
}
2048
 
</pre></blockquote>
 
2206
</pre></div>
2049
2207
 
2050
2208
<H3><a name="Perl5_nn35"></a>23.8.3 Returning values from arguments</H3>
2051
2209
 
2055
2213
its arguments.  This example describes the implementation of the <tt>OUTPUT</tt> typemap.
2056
2214
</p>
2057
2215
 
2058
 
<blockquote><pre>
 
2216
<div class="code"><pre>
2059
2217
%module return
2060
2218
 
2061
2219
// This tells SWIG to treat an double * argument with name 'OutDouble' as
2087
2245
 
2088
2246
int multout(double a, double b, double *OUTPUT, double *OUTPUT);
2089
2247
...
2090
 
</pre></blockquote>
 
2248
</pre></div>
2091
2249
 
2092
2250
<p>
2093
2251
When this function is called, the output arguments are appended to the stack used
2095
2253
For example :
2096
2254
</p>
2097
2255
 
2098
 
<blockquote><pre>
 
2256
<div class="code"><pre>
2099
2257
@r = multout(7,13);
2100
2258
print "multout(7,13) = @r\n";
2101
2259
($x,$y) = multout(7,13);
2102
 
</pre></blockquote>
 
2260
</pre></div>
2103
2261
 
2104
2262
<H3><a name="Perl5_nn36"></a>23.8.4 Accessing array structure members</H3>
2105
2263
 
2108
2266
Consider the following data structure :
2109
2267
</p>
2110
2268
 
2111
 
<blockquote><pre>
 
2269
<div class="code"><pre>
2112
2270
#define SIZE  8
2113
2271
typedef struct {
2114
2272
    int   values[SIZE];
2115
2273
    ...
2116
2274
} Foo;
2117
2275
 
2118
 
</pre></blockquote>
 
2276
</pre></div>
2119
2277
 
2120
2278
<p>
2121
2279
By default, SWIG doesn't know how to the handle the values structure
2124
2282
To make the member writable, a "memberin" typemap can be used.
2125
2283
</p>
2126
2284
 
2127
 
<blockquote><pre>
 
2285
<div class="code"><pre>
2128
2286
%typemap(memberin) int [SIZE] {
2129
2287
    int i;
2130
2288
    for (i = 0; i &lt; SIZE; i++) {
2132
2290
    }
2133
2291
}
2134
2292
 
2135
 
</pre></blockquote>
 
2293
</pre></div>
2136
2294
 
2137
2295
<p>
2138
2296
Whenever a <tt>int [SIZE]</tt> member is encountered in a structure
2145
2303
For example:
2146
2304
</p>
2147
2305
 
2148
 
<blockquote><pre>
 
2306
<div class="code"><pre>
2149
2307
%typemap(memberin) int [ANY] {
2150
2308
   int i;
2151
2309
   for (i = 0; i &lt; $1_dim0; i++) {
2152
2310
      $1[i] = $input[i];
2153
2311
   }
2154
2312
}
2155
 
</pre></blockquote>
 
2313
</pre></div>
2156
2314
 
 
2315
<p>
2157
2316
When setting structure members, the input object is always assumed to
2158
2317
be a C array of values that have already been converted from the
2159
2318
target language.  Because of this, the <tt>memberin</tt> typemap is
2161
2320
the "in" typemap in the previous section would be used to convert an
2162
2321
<tt>int[]</tt> array to C whereas the "memberin" typemap would be used
2163
2322
to copy the converted array into a C data structure.
 
2323
</p>
2164
2324
 
2165
2325
<H3><a name="Perl5_nn37"></a>23.8.5 Turning Perl references into C pointers</H3>
2166
2326
 
2171
2331
have a C function that modifies its arguments like this :
2172
2332
</p>
2173
2333
 
2174
 
<blockquote><pre>
 
2334
<div class="code"><pre>
2175
2335
void add(double a, double b, double *c) {
2176
2336
        *c = a + b;
2177
2337
}
2178
 
</pre></blockquote>
 
2338
</pre></div>
2179
2339
 
2180
2340
<p>
2181
2341
A common misinterpretation of this function is the following Perl script :
2182
2342
</p>
2183
2343
 
2184
 
<blockquote><pre>
 
2344
<div class="code"><pre>
2185
2345
# Perl script
2186
2346
$a = 3.5;
2187
2347
$b = 7.5;
2188
2348
$c = 0.0;          # Output value
2189
2349
add($a,$b,\$c);    # Place result in c (Except that it doesn't work)
2190
 
</pre></blockquote>
 
2350
</pre></div>
2191
2351
 
2192
2352
<p>
2193
2353
To make this work with a reference, you can use a typemap such as this:
2194
2354
</p>
2195
2355
 
2196
 
<blockquote><pre>
 
2356
<div class="code"><pre>
2197
2357
%typemap(in) double * (double dvalue) {
2198
2358
  SV* tempsv;
2199
2359
  if (!SvROK($input)) {
2210
2370
%typemap(argout) double * {
2211
2371
  SV *tempsv;
2212
2372
  tempsv = SvRV($input);
2213
 
  sv_setnv(tempsv, *$input);
 
2373
  sv_setnv(tempsv, *$1);
2214
2374
}
2215
 
</pre></blockquote>
 
2375
</pre></div>
2216
2376
 
2217
2377
<p>
2218
2378
Now, if you place this before the add function, you can do this :
2219
2379
</p>
2220
2380
 
2221
 
<blockquote><pre>
 
2381
<div class="code"><pre>
2222
2382
$a = 3.5;
2223
2383
$b = 7.5;
2224
2384
$c = 0.0;
2225
2385
add($a,$b,\$c);            # Now it works!
2226
2386
print "$c\n";
2227
2387
 
2228
 
</pre></blockquote>
 
2388
</pre></div>
2229
2389
 
2230
2390
<H3><a name="Perl5_nn38"></a>23.8.6 Pointer handling</H3>
2231
2391
 
2242
2402
</tt>
2243
2403
</p>
2244
2404
 
2245
 
<blockquote>
 
2405
<div class="indent">
2246
2406
Converts a Perl object <tt>obj</tt> to a C pointer.  The result of the conversion is placed
2247
2407
into the pointer located at <tt>ptr</tt>.  <tt>ty</tt> is a SWIG type descriptor structure.
2248
2408
<tt>flags</tt> is used to handle error checking and other aspects of conversion. <tt>flags</tt> is
2249
2409
currently undefined and reserved for future expansion.  Returns 0 on success and -1 on error.
2250
 
</blockquote>
 
2410
</div>
2251
2411
 
2252
2412
<p>
2253
2413
<tt>
2254
2414
void *SWIG_MakePtr(SV *obj, void *ptr, swig_type_info *ty, int flags)</tt>
2255
2415
</p>
2256
2416
 
2257
 
<blockquote>
 
2417
<div class="indent">
2258
2418
Creates a new Perl pointer object.  <tt>obj</tt> is a Perl SV that has been initialized to hold the result,
2259
2419
<tt>ptr</tt> is the pointer to convert, <tt>ty</tt> is the SWIG type descriptor structure that
2260
2420
describes the type, and <tt>flags</tt> is a flag that controls properties of the conversion.  <tt>flags</tt> is currently undefined
2261
2421
and reserved.
2262
 
</blockquote>
 
2422
</div>
2263
2423
 
2264
2424
<p>
2265
2425
Both of these functions require the use of a special SWIG
2270
2430
is usually accessed as follows:
2271
2431
</p>
2272
2432
 
2273
 
<blockquote>
 
2433
<div class="code">
2274
2434
<pre>
2275
2435
Foo *f;
2276
2436
if (SWIG_ConvertPtr($input, (void **) &amp;f, SWIGTYPE_p_Foo, 0) == -1) return NULL;
2278
2438
SV *sv = sv_newmortal();
2279
2439
SWIG_MakePtr(sv, f, SWIGTYPE_p_Foo, 0);
2280
2440
</pre>
2281
 
</blockquote>
 
2441
</div>
2282
2442
 
 
2443
<p>
2283
2444
In a typemap, the type descriptor should always be accessed using the special typemap
2284
2445
variable <tt>$1_descriptor</tt>.  For example:
 
2446
</p>
2285
2447
 
2286
 
<blockquote>
 
2448
<div class="code">
2287
2449
<pre>
2288
2450
%typemap(in) Foo * {
2289
2451
   if ((SWIG_ConvertPtr($input,(void **) &amp;$1, $1_descriptor,0)) == -1) return NULL;
2290
2452
}
2291
2453
</pre>
2292
 
</blockquote>
 
2454
</div>
2293
2455
 
 
2456
<p>
2294
2457
If necessary, the descriptor for any type can be obtained using the <tt>$descriptor()</tt> macro in a typemap.
2295
2458
For example:
 
2459
</p>
2296
2460
 
2297
 
<blockquote>
 
2461
<div class="code">
2298
2462
<pre>
2299
2463
%typemap(in) Foo * {
2300
2464
   if ((SWIG_ConvertPtr($input,(void **) &amp;$1, $descriptor(Foo *), 0)) == -1) return NULL;
2301
2465
}
2302
2466
</pre>
2303
 
</blockquote>
 
2467
</div>
2304
2468
 
2305
2469
<H2><a name="Perl5_nn39"></a>23.9 Proxy classes</H2>
2306
2470
 
2321
2485
<H3><a name="Perl5_nn40"></a>23.9.1 Preliminaries</H3>
2322
2486
 
2323
2487
 
 
2488
<p>
2324
2489
Proxy classes, are generated by default. If you want to turn them off, use the <tt>-noproxy</tt> command line option.
2325
2490
For example:
 
2491
</p>
2326
2492
 
2327
 
<blockquote>
 
2493
<div class="code">
2328
2494
<pre>
2329
2495
$ swig -c++ -perl -noproxy example.i
2330
2496
</pre>
2331
 
</blockquote>
 
2497
</div>
2332
2498
 
 
2499
<p>
2333
2500
When proxy classes are used, SWIG moves all of the low-level procedural wrappers to
2334
2501
another package name.  By default, this package is named 'modulec' where 'module' is the name of the module
2335
2502
you provided with the <tt>%module</tt> directive.  Then, in place of the original module, 
2336
2503
SWIG creates a collection of high-level Perl wrappers.  In your scripts, you will use these
2337
2504
high level wrappers.  The wrappers, in turn, interact with the low-level procedural module.
 
2505
</p>
2338
2506
 
2339
2507
<H3><a name="Perl5_nn41"></a>23.9.2 Structure and class wrappers</H3>
2340
2508
 
2343
2511
Suppose you have the following SWIG interface file :
2344
2512
</p>
2345
2513
 
2346
 
<blockquote><pre>
 
2514
<div class="code"><pre>
2347
2515
%module example
2348
2516
struct Vector {
2349
2517
        Vector(double x, double y, double z);
2351
2519
        double x,y,z;
2352
2520
};
2353
2521
 
2354
 
</pre></blockquote>
 
2522
</pre></div>
2355
2523
 
2356
2524
<p>
2357
2525
When wrapped, SWIG creates the following set of low-level accessor
2358
2526
functions as described in previous sections.
2359
2527
</p>
2360
2528
 
2361
 
<blockquote><pre>
 
2529
<div class="code"><pre>
2362
2530
Vector *new_Vector(double x, double y, double z);
2363
2531
void    delete_Vector(Vector *v);
2364
2532
double  Vector_x_get(Vector *v);
2368
2536
double  Vector_z_get(Vector *v);
2369
2537
double  Vector_z_set(Vector *v, double value);
2370
2538
 
2371
 
</pre></blockquote>
 
2539
</pre></div>
2372
2540
 
2373
2541
<p>
2374
2542
However, when proxy classes are enabled, these accessor functions are
2375
2543
wrapped inside a Perl class like this:
2376
2544
</p>
2377
2545
 
2378
 
<blockquote><pre>
 
2546
<div class="code"><pre>
2379
2547
package example::Vector;
2380
2548
@ISA = qw( example );
2381
2549
%OWNER = ();
2424
2592
        &amp;$member_func($self,$newval);
2425
2593
    }
2426
2594
}
2427
 
</pre></blockquote>
 
2595
</pre></div>
2428
2596
 
2429
2597
<p>
2430
2598
Each structure or class is mapped into a Perl package of the same
2441
2609
To use our new proxy class we can simply do the following:
2442
2610
</p>
2443
2611
 
2444
 
<blockquote><pre>
 
2612
<div class="code"><pre>
2445
2613
# Perl code using Vector class
2446
2614
$v = new Vector(2,3,4);
2447
2615
$w = Vector-&gt;new(-1,-2,-3);
2460
2628
# Destruction
2461
2629
$v-&gt;DESTROY();
2462
2630
 
2463
 
</pre></blockquote>
 
2631
</pre></div>
2464
2632
 
2465
2633
<H3><a name="Perl5_nn42"></a>23.9.3 Object Ownership</H3>
2466
2634
 
2471
2639
problem---suppose you had a function like this :
2472
2640
</p>
2473
2641
 
2474
 
<blockquote><pre>
 
2642
<div class="code"><pre>
2475
2643
Vector *Vector_get(Vector *v, int index) {
2476
2644
        return &amp;v[i];
2477
2645
}
2478
 
</pre></blockquote>
 
2646
</pre></div>
2479
2647
 
2480
2648
<p>
2481
2649
This function takes a Vector pointer and returns a pointer to another
2484
2652
Vector object :
2485
2653
</p>
2486
2654
 
2487
 
<blockquote><pre>
 
2655
<div class="code"><pre>
2488
2656
Vector *new_Vector(double x, double y, double z) {
2489
2657
        Vector *v;
2490
2658
        v = new Vector(x,y,z);        // Call C++ constructor
2491
2659
        return v;
2492
2660
}
2493
 
</pre></blockquote>
 
2661
</pre></div>
2494
2662
 
2495
2663
<p>
2496
2664
Both functions return a Vector, but the constructor is returning a
2526
2694
done using the <tt>DISOWN </tt>method.
2527
2695
</p>
2528
2696
 
2529
 
<blockquote><pre>
 
2697
<div class="code"><pre>
2530
2698
# Perl code to change ownership of an object
2531
2699
$v = new Vector(x,y,z);
2532
2700
$v-&gt;DISOWN();     
2533
 
</pre></blockquote>
 
2701
</pre></div>
2534
2702
 
2535
2703
<p>
2536
2704
To acquire ownership of an object, the <tt>ACQUIRE</tt> method can be used.
2537
2705
</p>
2538
2706
 
2539
 
<blockquote><pre>
 
2707
<div class="code"><pre>
2540
2708
# Given Perl ownership of a file
2541
2709
$u = Vector_get($v);
2542
2710
$u-&gt;ACQUIRE();
2543
2711
 
2544
 
</pre></blockquote>
 
2712
</pre></div>
2545
2713
 
2546
2714
<p>
2547
2715
As always, a little care is in order.  SWIG does not provide reference
2556
2724
Suppose that we have a new object that looks like this :
2557
2725
</p>
2558
2726
 
2559
 
<blockquote><pre>
 
2727
<div class="code"><pre>
2560
2728
struct Particle {
2561
2729
        Vector r;
2562
2730
        Vector v;
2564
2732
        int     type;
2565
2733
}
2566
2734
 
2567
 
</pre></blockquote>
 
2735
</pre></div>
2568
2736
 
2569
2737
<p>
2570
2738
In this case, the members of the structure are complex objects that
2573
2741
look like this (along with some supporting code) :
2574
2742
</p>
2575
2743
 
2576
 
<blockquote><pre>
 
2744
<div class="code"><pre>
2577
2745
package Particle;
2578
2746
...
2579
2747
%BLESSEDMEMBERS = (
2582
2750
        f =&gt; `Vector',
2583
2751
);
2584
2752
 
2585
 
</pre></blockquote>
 
2753
</pre></div>
2586
2754
 
2587
2755
<p>
2588
2756
When fetching members from the structure, <tt>%BLESSEDMEMBERS</tt> is
2595
2763
This implementation allows us to operate on nested structures as follows :
2596
2764
</p>
2597
2765
 
2598
 
<blockquote><pre>
 
2766
<div class="code"><pre>
2599
2767
# Perl access of nested structure
2600
2768
$p = new Particle();
2601
2769
$p-&gt;{f}-&gt;{x} = 0.0;
2602
2770
%${$p-&gt;{v}} = ( x=&gt;0, y=&gt;0, z=&gt;0);         
2603
 
</pre></blockquote>
 
2771
</pre></div>
2604
2772
 
2605
2773
<H3><a name="Perl5_nn44"></a>23.9.5 Proxy Functions</H3>
2606
2774
 
2610
2778
sometimes necessary to write a proxy function.  For example :
2611
2779
</p>
2612
2780
 
2613
 
<blockquote><pre>
 
2781
<div class="code"><pre>
2614
2782
double dot_product(Vector *v1, Vector *v2);
2615
 
</pre></blockquote>
 
2783
</pre></div>
2616
2784
 
2617
2785
<p>
2618
2786
Since Vector is an object already wrapped into a proxy class, we need
2621
2789
this :
2622
2790
</p>
2623
2791
 
2624
 
<blockquote><pre>
 
2792
<div class="code"><pre>
2625
2793
sub dot_product {
2626
2794
    my @args = @_;
2627
2795
    $args[0] = tied(%{$args[0]});         # Get the real pointer values
2629
2797
    my $result = vectorc::dot_product(@args);
2630
2798
    return $result;
2631
2799
}
2632
 
</pre></blockquote>
 
2800
</pre></div>
2633
2801
 
2634
2802
<p>
2635
2803
This function replaces the original function, but operates in an
2645
2813
interface file :
2646
2814
</p>
2647
2815
 
2648
 
<blockquote><pre>
 
2816
<div class="code"><pre>
2649
2817
// shapes.i
2650
2818
// SWIG interface file for shapes class
2651
2819
%module shapes
2674
2842
        double perimeter();
2675
2843
}
2676
2844
 
2677
 
</pre></blockquote>
 
2845
</pre></div>
2678
2846
 
2679
2847
<p>
2680
2848
The resulting, Perl wrapper class will create the following code :
2681
2849
</p>
2682
2850
 
2683
 
<blockquote><pre>
 
2851
<div class="code"><pre>
2684
2852
Package Shape;
2685
2853
@ISA = (shapes);
2686
2854
...
2690
2858
Package Square;
2691
2859
@ISA = (shapes Shape);
2692
2860
 
2693
 
</pre></blockquote>
 
2861
</pre></div>
2694
2862
 
2695
2863
<p>
2696
2864
The <tt>@ISA</tt> array determines where to look for methods of a
2715
2883
<H3><a name="Perl5_nn46"></a>23.9.7 Modifying the proxy methods</H3>
2716
2884
 
2717
2885
 
 
2886
<p>
2718
2887
It is possible to override the SWIG generated proxy/shadow methods, using <tt>%feature("shadow")</tt>.
2719
2888
It works like all the other <a href="Customization.html#features">%feature directives</a>.
2720
2889
Here is a simple example showing how to add some Perl debug code to the constructor:
 
2890
</p>
2721
2891
 
2722
 
<blockquote><pre>
 
2892
<div class="code"><pre>
2723
2893
/* Let's make the constructor of the class Square more verbose */
2724
2894
%feature("shadow") Square(double w)
2725
2895
%{
2736
2906
  Square(double w);
2737
2907
  ...
2738
2908
};
2739
 
</pre></blockquote>
 
2909
</pre></div>
2740
2910
 
2741
2911
 
2742
2912