Initial commit of OpenSPARC T2 architecture model.
[OpenSPARC-T2-SAM] / sam-t2 / devtools / v8plus / html / swig / Library.html
CommitLineData
920dae64
AT
1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2<html>
3<head>
4<title>SWIG Library</title>
5<link rel="stylesheet" type="text/css" href="style.css">
6</head>
7
8<body bgcolor="#ffffff">
9<H1><a name="Library"></a>8 SWIG library</H1>
10<!-- INDEX -->
11<div class="sectiontoc">
12<ul>
13<li><a href="#Library_nn2">The %include directive and library search path</a>
14<li><a href="#Library_nn3">C Arrays and Pointers</a>
15<ul>
16<li><a href="#Library_nn4">cpointer.i</a>
17<li><a href="#Library_nn5">carrays.i</a>
18<li><a href="#Library_nn6">cmalloc.i</a>
19<li><a href="#Library_nn7">cdata.i</a>
20</ul>
21<li><a href="#Library_nn8">C String Handling</a>
22<ul>
23<li><a href="#Library_nn9">Default string handling</a>
24<li><a href="#Library_nn10">Passing binary data</a>
25<li><a href="#Library_nn11">Using %newobject to release memory</a>
26<li><a href="#Library_nn12">cstring.i</a>
27</ul>
28<li><a href="#Library_stl_cpp_library">STL/C++ Library</a>
29<ul>
30<li><a href="#Library_nn14">std_string.i</a>
31<li><a href="#Library_nn15">std_vector.i</a>
32<li><a href="#Library_stl_exceptions">STL exceptions</a>
33</ul>
34<li><a href="#Library_nn16">Utility Libraries</a>
35<ul>
36<li><a href="#Library_nn17">exception.i</a>
37</ul>
38</ul>
39</div>
40<!-- INDEX -->
41
42
43
44<p>
45To help build extension modules, SWIG is packaged with a library of
46support files that you can include in your own interfaces. These
47files often define new SWIG directives or provide utility
48functions that can be used to access parts of the standard C and C++ libraries.
49This chapter provides a reference to the current set of supported library files.
50</p>
51
52<p>
53<b>Compatibility note:</b> Older versions of SWIG included a number of
54library files for manipulating pointers, arrays, and other structures. Most
55these files are now deprecated and have been removed from the distribution.
56Alternative libraries provide similar functionality. Please read this chapter
57carefully if you used the old libraries.
58</p>
59
60<H2><a name="Library_nn2"></a>8.1 The %include directive and library search path</H2>
61
62
63<p>
64Library files are included using the <tt>%include</tt> directive.
65When searching for files, directories are searched in the following order:
66</p>
67
68<ul>
69<li>The current directory
70<li>Directories specified with the <tt>-I</tt> command line option
71<li>.<tt>/swig_lib</tt>
72<li><tt>/usr/local/lib/swig_lib</tt> (or wherever you installed SWIG)
73<li>On Windows, SWIG also looks for the library relative to the location of <tt>swig.exe</tt>.
74</ul>
75
76<p>
77Within each directory, SWIG first looks for a subdirectory corresponding to a target language (e.g., <tt>python</tt>,
78<tt>tcl</tt>, etc.). If found, SWIG will search the language specific directory first. This allows
79for language-specific implementations of library files.
80</p>
81
82<p>
83You can override the location of the SWIG library by setting the
84<tt>SWIG_LIB</tt> environment variable.
85</p>
86
87<H2><a name="Library_nn3"></a>8.2 C Arrays and Pointers</H2>
88
89
90<p>
91This section describes library modules for manipulating low-level C arrays and pointers.
92The primary use of these modules is in supporting C declarations that manipulate bare
93pointers such as <tt>int *</tt>, <tt>double *</tt>, or <tt>void *</tt>. The modules can be
94used to allocate memory, manufacture pointers, dereference memory, and wrap
95pointers as class-like objects. Since these functions provide direct access to
96memory, their use is potentially unsafe and you should exercise caution.
97</p>
98
99<H3><a name="Library_nn4"></a>8.2.1 cpointer.i</H3>
100
101
102<p>
103The <tt>cpointer.i</tt> module defines macros that can be used to used
104to generate wrappers around simple C pointers. The primary use of
105this module is in generating pointers to primitive datatypes such as
106<tt>int</tt> and <tt>double</tt>.
107</p>
108
109<p>
110<b><tt>%pointer_functions(type,name)</tt></b>
111</p>
112
113<div class="indent">
114<p>Generates a collection of four functions for manipulating a pointer <tt>type *</tt>:</p>
115
116<p>
117<tt>type *new_name()</tt>
118</p>
119
120<div class="indent"><p>
121Creates a new object of type <tt>type</tt> and returns a pointer to it. In C, the
122object is created using <tt>calloc()</tt>. In C++, <tt>new</tt> is used.
123</p></div>
124
125<p>
126<tt>type *copy_name(type value)</tt>
127</p>
128
129<div class="indent"><p>
130Creates a new object of type <tt>type</tt> and returns a pointer to it.
131An initial value is set by copying it from <tt>value</tt>. In C, the
132object is created using <tt>calloc()</tt>. In C++, <tt>new</tt> is used.
133</p></div>
134
135<p>
136<tt>type *delete_name(type *obj)</tt>
137</p>
138
139<div class="indent"><p>
140Deletes an object type <tt>type</tt>.
141</p></div>
142
143<p>
144<tt>void name_assign(type *obj, type value)</tt>
145</p>
146
147<div class="indent"><p>
148Assigns <tt>*obj = value</tt>.
149</p></div>
150
151<p>
152<tt>type name_value(type *obj)</tt>
153</p>
154
155<div class="indent"><p>
156Returns the value of <tt>*obj</tt>.
157</p></div>
158
159<p>
160When using this macro, <tt>type</tt> may be any type and <tt>name</tt> must be a legal identifier in the target
161language. <tt>name</tt> should not correspond to any other name used in the interface file.
162</p>
163
164
165<p>
166Here is a simple example of using <tt>%pointer_functions()</tt>:
167</p>
168
169<div class="code">
170<pre>
171%module example
172%include "cpointer.i"
173
174/* Create some functions for working with "int *" */
175%pointer_functions(int, intp);
176
177/* A function that uses an "int *" */
178void add(int x, int y, int *result);
179</pre>
180</div>
181
182<p>
183Now, in Python:
184</p>
185
186<div class="targetlang">
187<pre>
188&gt;&gt;&gt; import example
189&gt;&gt;&gt; c = example.new_intp() # Create an "int" for storing result
190&gt;&gt;&gt; example.add(3,4,c) # Call function
191&gt;&gt;&gt; example.intp_value(c) # Dereference
1927
193&gt;&gt;&gt; example.delete_intp(c) # Delete
194</pre>
195</div>
196
197</div>
198
199<p>
200<b><tt>%pointer_class(type,name)</tt></b>
201</p>
202
203<div class="indent">
204
205<p>
206Wraps a pointer of <tt>type *</tt> inside a class-based interface. This
207interface is as follows:
208</p>
209
210<div class="code">
211<pre>
212struct name {
213 name(); // Create pointer object
214 ~name(); // Delete pointer object
215 void assign(type value); // Assign value
216 type value(); // Get value
217 type *cast(); // Cast the pointer to original type
218 static name *frompointer(type *); // Create class wrapper from existing
219 // pointer
220};
221</pre>
222</div>
223
224<p>
225When using this macro, <tt>type</tt> is restricted to a simple type
226name like <tt>int</tt>, <tt>float</tt>, or <tt>Foo</tt>. Pointers and
227other complicated types are not allowed. <tt>name</tt> must be a
228valid identifier not already in use. When a pointer is wrapped as a class,
229the "class" may be transparently passed to any function that expects the pointer.
230</p>
231
232<p>
233If the target language does not support proxy classes, the use of this macro will produce the example
234same functions as <tt>%pointer_functions()</tt> macro.
235</p>
236
237
238<p>
239It should be noted that the class interface does introduce a new object or wrap a pointer inside a special
240structure. Instead, the raw pointer is used directly.
241</p>
242
243
244
245<p>
246Here is the same example using a class instead:
247</p>
248
249<div class="code">
250<pre>
251%module example
252%include "cpointer.i"
253
254/* Wrap a class interface around an "int *" */
255%pointer_class(int, intp);
256
257/* A function that uses an "int *" */
258void add(int x, int y, int *result);
259</pre>
260</div>
261
262<p>
263Now, in Python (using proxy classes)
264</p>
265
266<div class="targetlang">
267<pre>
268&gt;&gt;&gt; import example
269&gt;&gt;&gt; c = example.intp() # Create an "int" for storing result
270&gt;&gt;&gt; example.add(3,4,c) # Call function
271&gt;&gt;&gt; c.value() # Dereference
2727
273</pre>
274</div>
275
276<p>
277Of the two macros, <tt>%pointer_class</tt> is probably the most convenient when working with simple
278pointers. This is because the pointers are access like objects and they can be easily garbage collected
279(destruction of the pointer object destroys the underlying object).
280</p>
281
282</div>
283
284<p>
285<b><tt>%pointer_cast(type1, type2, name)</tt></b>
286</p>
287
288<div class="indent">
289
290<p>
291Creates a casting function that converts <tt>type1</tt> to <tt>type2</tt>. The name of the function is <tt>name</tt>.
292For example:
293</p>
294
295<div class="code">
296<pre>
297%pointer_cast(int *, unsigned int *, int_to_uint);
298</pre>
299</div>
300
301<p>
302In this example, the function <tt>int_to_uint()</tt> would be used to cast types in the target language.
303</p>
304
305</div>
306
307<p>
308<b>Note:</b> None of these macros can be used to safely work with strings (<tt>char *</tt> or <tt>char **</tt>).
309</p>
310
311<P>
312<b>Note:</b> When working with simple pointers, typemaps can often be used to provide more seamless operation.
313</p>
314
315<H3><a name="Library_nn5"></a>8.2.2 carrays.i</H3>
316
317
318<p>
319This module defines macros that assist in wrapping ordinary C pointers as arrays.
320The module does not provide any safety or an extra layer of wrapping--it merely
321provides functionality for creating, destroying, and modifying the contents of
322raw C array data.
323</p>
324
325<p>
326<b><tt>%array_functions(type,name)</tt></b>
327</p>
328
329<div class="indent">
330<p>Creates four functions.</p>
331
332<p>
333<tt>type *new_name(int nelements)</tt>
334</p>
335
336<div class="indent"><p>
337Creates a new array of objects of type <tt>type</tt>. In C, the array is allocated using
338<tt>calloc()</tt>. In C++, <tt>new []</tt> is used.
339</p></div>
340
341<p>
342<tt>type *delete_name(type *ary)</tt>
343</p>
344
345<div class="indent"><p>
346Deletes an array. In C, <tt>free()</tt> is used. In C++, <tt>delete []</tt> is used.
347</p></div>
348
349<p>
350<tt>type name_getitem(type *ary, int index)</tt>
351</p>
352
353<div class="indent"><p>
354Returns the value <tt>ary[index]</tt>.
355</p></div>
356
357<p>
358<tt>void name_setitem(type *ary, int index, type value)</tt>
359</p>
360
361<div class="indent"><p>
362Assigns <tt>ary[index] = value</tt>.
363</p></div>
364
365<p>
366When using this macro, <tt>type</tt> may be any type and <tt>name</tt>
367must be a legal identifier in the target language. <tt>name</tt>
368should not correspond to any other name used in the interface file.
369</p>
370
371<p>
372Here is an example of <tt>%array_functions()</tt>. Suppose you had a
373function like this:
374</p>
375
376<div class="code">
377<pre>
378void print_array(double x[10]) {
379 int i;
380 for (i = 0; i &lt; 10; i++) {
381 printf("[%d] = %g\n", i, x[i]);
382 }
383}
384</pre>
385</div>
386
387<p>
388To wrap it, you might write this:
389</p>
390
391<div class="code">
392<pre>
393%module example
394
395%include "carrays.i"
396%array_functions(double, doubleArray);
397
398void print_array(double x[10]);
399</pre>
400</div>
401
402<p>
403Now, in a scripting language, you might write this:
404</p>
405
406<div class="code">
407<pre>
408a = new_doubleArray(10) # Create an array
409for i in range(0,10):
410 doubleArray_setitem(a,i,2*i) # Set a value
411print_array(a) # Pass to C
412delete_doubleArray(a) # Destroy array
413</pre>
414</div>
415
416</div>
417
418<b><tt>%array_class(type,name)</tt></b>
419<div class="indent">
420
421<p>
422Wraps a pointer of <tt>type *</tt> inside a class-based interface. This
423interface is as follows:
424</p>
425
426<div class="code">
427<pre>
428struct name {
429 name(int nelements); // Create an array
430 ~name(); // Delete array
431 type getitem(int index); // Return item
432 void setitem(int index, type value); // Set item
433 type *cast(); // Cast to original type
434 static name *frompointer(type *); // Create class wrapper from
435 // existing pointer
436};
437</pre>
438</div>
439
440<p>
441When using this macro, <tt>type</tt> is restricted to a simple type
442name like <tt>int</tt> or <tt>float</tt>. Pointers and
443other complicated types are not allowed. <tt>name</tt> must be a
444valid identifier not already in use. When a pointer is wrapped as a class,
445it can be transparently passed to any function that expects the pointer.
446</p>
447
448
449<p>
450When combined with proxy classes, the <tt>%array_class()</tt> macro can be especially useful.
451For example:
452</p>
453
454<div class="code">
455<pre>
456%module example
457%include "carrays.i"
458%array_class(double, doubleArray);
459
460void print_array(double x[10]);
461</pre>
462</div>
463
464<p>
465Allows you to do this:
466</p>
467
468<div class="code">
469<pre>
470import example
471c = example.doubleArray(10) # Create double[10]
472for i in range(0,10):
473 c[i] = 2*i # Assign values
474example.print_array(c) # Pass to C
475</pre>
476</div>
477
478</div>
479
480<p>
481<b>Note:</b> These macros do not encapsulate C arrays inside a special data structure
482or proxy. There is no bounds checking or safety of any kind. If you want this,
483you should consider using a special array object rather than a bare pointer.
484</p>
485
486<p>
487<b>Note:</b> <tt>%array_functions()</tt> and <tt>%array_class()</tt> should not be
488used with types of <tt>char</tt> or <tt>char *</tt>.
489</p>
490
491<H3><a name="Library_nn6"></a>8.2.3 cmalloc.i</H3>
492
493
494<p>
495This module defines macros for wrapping the low-level C memory allocation functions
496<tt>malloc()</tt>, <tt>calloc()</tt>, <tt>realloc()</tt>, and <tt>free()</tt>.
497</p>
498
499<p>
500<b><tt>%malloc(type [,name=type])</tt></b>
501</p>
502
503<div class="indent">
504
505<p>
506Creates a wrapper around <tt>malloc()</tt> with the following prototype:
507</p>
508
509<div class="code"><pre>
510<em>type</em> *malloc_<em>name</em>(int nbytes = sizeof(<em>type</em>));
511</pre>
512</div>
513
514<p>
515If <tt>type</tt> is <tt>void</tt>, then the size parameter <tt>nbytes</tt> is required.
516The <tt>name</tt> parameter only needs to be specified when wrapping a type that
517is not a valid identifier (e.g., "<tt>int *</tt>", "<tt>double **</tt>", etc.).
518</p>
519
520</div>
521
522<p>
523<b><tt>%calloc(type [,name=type])</tt></b>
524</p>
525
526<div class="indent">
527
528<p>
529Creates a wrapper around <tt>calloc()</tt> with the following prototype:
530</p>
531
532<div class="code"><pre>
533<em>type</em> *calloc_<em>name</em>(int nobj =1, int sz = sizeof(<em>type</em>));
534</pre>
535</div>
536
537<p>
538If <tt>type</tt> is <tt>void</tt>, then the size parameter <tt>sz</tt> is required.
539</p>
540
541</div>
542
543<p>
544<b><tt>%realloc(type [,name=type])</tt></b>
545</p>
546
547<div class="indent">
548
549<p>
550Creates a wrapper around <tt>realloc()</tt> with the following prototype:
551</p>
552
553<div class="code"><pre>
554<em>type</em> *realloc_<em>name</em>(<em>type</em> *ptr, int nitems);
555</pre>
556</div>
557
558<p>
559Note: unlike the C <tt>realloc()</tt>, the wrapper generated by this macro implicitly includes the
560size of the corresponding type. For example, <tt>realloc_int(p, 100)</tt> reallocates <tt>p</tt> so that
561it holds 100 integers.
562</p>
563
564</div>
565
566<p>
567<b><tt>%free(type [,name=type])</tt></b>
568</p>
569
570<div class="indent">
571
572<p>
573Creates a wrapper around <tt>free()</tt> with the following prototype:
574</p>
575
576<div class="code"><pre>
577void free_<em>name</em>(<em>type</em> *ptr);
578</pre>
579</div>
580</div>
581
582<p>
583<b><tt>%sizeof(type [,name=type])</tt></b>
584</p>
585
586<div class="indent">
587
588<p>
589Creates the constant:
590</p>
591
592<div class="code"><pre>
593%constant int sizeof_<em>name</em> = sizeof(<em>type</em>);
594</pre>
595</div>
596</div>
597
598<p>
599<b><tt>%allocators(type [,name=type])</tt></b>
600</p>
601
602<div class="indent"><p>
603Generates wrappers for all five of the above operations.
604</p></div>
605
606<p>
607Here is a simple example that illustrates the use of these macros:
608</p>
609
610<div class="code">
611<pre>
612// SWIG interface
613%module example
614%include "cmalloc.i"
615
616%malloc(int);
617%free(int);
618
619%malloc(int *, intp);
620%free(int *, intp);
621
622%allocators(double);
623</pre>
624</div>
625
626<p>
627Now, in a script:
628</p>
629
630<div class="targetlang">
631<pre>
632&gt;&gt;&gt; from example import *
633&gt;&gt;&gt; a = malloc_int()
634&gt;&gt;&gt; a
635'_000efa70_p_int'
636&gt;&gt;&gt; free_int(a)
637&gt;&gt;&gt; b = malloc_intp()
638&gt;&gt;&gt; b
639'_000efb20_p_p_int'
640&gt;&gt;&gt; free_intp(b)
641&gt;&gt;&gt; c = calloc_double(50)
642&gt;&gt;&gt; c
643'_000fab98_p_double'
644&gt;&gt;&gt; c = realloc_double(100000)
645&gt;&gt;&gt; free_double(c)
646&gt;&gt;&gt; print sizeof_double
6478
648&gt;&gt;&gt;
649</pre>
650</div>
651
652<H3><a name="Library_nn7"></a>8.2.4 cdata.i</H3>
653
654
655<p>
656The <tt>cdata.i</tt> module defines functions for converting raw C data to and from strings
657in the target language. The primary applications of this module would be packing/unpacking of
658binary data structures---for instance, if you needed to extract data from a buffer.
659The target language must support strings with embedded binary data
660in order for this to work.
661</p>
662
663<p>
664<b><tt>char *cdata(void *ptr, int nbytes)</tt></b>
665</p>
666
667<div class="indent"><p>
668Converts <tt>nbytes</tt> of data at <tt>ptr</tt> into a string. <tt>ptr</tt> can be any
669pointer.
670</p></div>
671
672<p>
673<b><tt>void memmove(void *ptr, char *s)</tt></b>
674</p>
675
676<div class="indent"><p>
677Copies all of the string data in <tt>s</tt> into the memory pointed to by
678<tt>ptr</tt>. The string may contain embedded NULL bytes. The length of
679the string is implicitly determined in the underlying wrapper code.
680</p></div>
681
682<p>
683One use of these functions is packing and unpacking data from memory.
684Here is a short example:
685</p>
686
687<div class="code">
688<pre>
689// SWIG interface
690%module example
691%include "carrays.i"
692%include "cdata.i"
693
694%array_class(int, intArray);
695</pre>
696</div>
697
698<p>
699Python example:
700</p>
701
702<div class="targetlang">
703<pre>
704&gt;&gt;&gt; a = intArray(10)
705&gt;&gt;&gt; for i in range(0,10):
706... a[i] = i
707&gt;&gt;&gt; b = cdata(a,40)
708&gt;&gt;&gt; b
709'\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\x04
710\x00\x00\x00\x05\x00\x00\x00\x06\x00\x00\x00\x07\x00\x00\x00\x08\x00\x00\x00\t'
711&gt;&gt;&gt; c = intArray(10)
712&gt;&gt;&gt; memmove(c,b)
713&gt;&gt;&gt; print c[4]
7144
715&gt;&gt;&gt;
716</pre>
717</div>
718
719<p>
720Since the size of data is not always known, the following macro is also defined:
721</p>
722
723<p>
724<b><tt>%cdata(type [,name=type])</tt></b>
725</p>
726
727<div class="indent">
728
729<p>
730Generates the following function for extracting C data for a given type.
731</p>
732
733<div class="code">
734<pre>
735char *cdata_<em>name</em>(type* ptr, int nitems)
736</pre>
737</div>
738
739<p>
740<tt>nitems</tt> is the number of items of the given type to extract.
741</p>
742
743</div>
744
745<p>
746<b>Note:</b> These functions provide direct access to memory and can be used to overwrite data.
747Clearly they are unsafe.
748</p>
749
750<H2><a name="Library_nn8"></a>8.3 C String Handling</H2>
751
752
753<p>
754A common problem when working with C programs is dealing with
755functions that manipulate raw character data using <tt>char *</tt>.
756In part, problems arise because there are different interpretations of
757<tt>char *</tt>---it could be a NULL-terminated string or it could
758point to binary data. Moreover, functions that manipulate raw strings
759may mutate data, perform implicit memory allocations, or utilize
760fixed-sized buffers.
761</p>
762
763<p>
764The problems (and perils) of using <tt>char *</tt> are
765well-known. However, SWIG is not in the business of enforcing
766morality. The modules in this section provide basic functionality
767for manipulating raw C strings.
768</p>
769
770<H3><a name="Library_nn9"></a>8.3.1 Default string handling</H3>
771
772
773<p>
774Suppose you have a C function with this prototype:
775</p>
776
777<div class="code">
778<pre>
779char *foo(char *s);
780</pre>
781</div>
782
783<p>
784The default wrapping behavior for this function is to set <tt>s</tt>
785to a raw <tt>char *</tt> that refers to the internal string data in the
786target language. In other words, if you were using a language like Tcl,
787and you wrote this,
788</p>
789
790<div class="code">
791<pre>
792% foo Hello
793</pre>
794</div>
795
796<p>
797then <tt>s</tt> would point to the representation of "Hello" inside
798the Tcl interpreter. When returning a <tt>char *</tt>, SWIG assumes
799that it is a NULL-terminated string and makes a copy of it. This
800gives the target language its own copy of the result.
801</p>
802
803<p>
804There are obvious problems with the default behavior. First, since
805a <tt>char *</tt> argument points to data inside the target language, it is
806<b>NOT</b> safe for a function to modify this data (doing so may corrupt the
807interpreter and lead to a crash). Furthermore, the default behavior does
808not work well with binary data. Instead, strings are assumed to be NULL-terminated.
809</p>
810
811<H3><a name="Library_nn10"></a>8.3.2 Passing binary data</H3>
812
813
814<p>
815If you have a function that expects binary data,
816</p>
817
818<div class="code">
819<pre>
820int parity(char *str, int len, int initial);
821</pre>
822</div>
823
824<p>
825you can wrap the parameters <tt>(char *str, int len)</tt> as a single
826argument using a typemap. Just do this:
827</p>
828
829<div class="code">
830<pre>
831%apply (char *STRING, int LENGTH) { (char *str, int len) };
832...
833int parity(char *str, int len, int initial);
834</pre>
835</div>
836
837<p>
838Now, in the target language, you can use binary string data like this:
839</p>
840
841<div class="code">
842<pre>
843&gt;&gt;&gt; s = "H\x00\x15eg\x09\x20"
844&gt;&gt;&gt; parity(s,0)
845</pre>
846</div>
847
848<p>
849In the wrapper function, the passed string will be expanded to a pointer and length parameter.
850</p>
851
852<H3><a name="Library_nn11"></a>8.3.3 Using %newobject to release memory</H3>
853
854
855<p>
856If you have a function that allocates memory like this,
857</p>
858
859<div class="code">
860<pre>
861char *foo() {
862 char *result = (char *) malloc(...);
863 ...
864 return result;
865}
866</pre>
867</div>
868
869<p>
870then the SWIG generated wrappers will have a memory leak--the returned data will be copied
871into a string object and the old contents ignored.
872</p>
873
874<p>
875To fix the memory leak, use the <tt>%newobject</tt> directive.
876</p>
877
878<div class="code">
879<pre>
880%newobject foo;
881...
882char *foo();
883</pre>
884</div>
885
886<p>
887This will release the result.
888</p>
889
890<H3><a name="Library_nn12"></a>8.3.4 cstring.i</H3>
891
892
893<p>
894The <tt>cstring.i</tt> library file provides a collection of macros
895for dealing with functions that either mutate string arguments or
896which try to output string data through their arguments. An
897example of such a function might be this rather questionable
898implementation:
899</p>
900
901<div class="code">
902<pre>
903void get_path(char *s) {
904 // Potential buffer overflow---uh, oh.
905 sprintf(s,"%s/%s", base_directory, sub_directory);
906}
907...
908// Somewhere else in the C program
909{
910 char path[1024];
911 ...
912 get_path(path);
913 ...
914}
915</pre>
916</div>
917
918<p>
919(Off topic rant: If your program really has functions like this, you
920would be well-advised to replace them with safer alternatives
921involving bounds checking).
922</p>
923
924<p>
925The macros defined in this module all expand to various combinations of
926typemaps. Therefore, the same pattern matching rules and ideas apply.
927</p>
928
929<p>
930<b>%cstring_bounded_output(parm, maxsize)</b>
931</p>
932
933<div class="indent">
934
935<p>
936Turns parameter <tt><em>parm</em></tt> into an output value. The
937output string is assumed to be NULL-terminated and smaller than
938<tt><em>maxsize</em></tt> characters. Here is an example:
939</p>
940
941<div class="code">
942<pre>
943%cstring_bounded_output(char *path, 1024);
944...
945void get_path(char *path);
946</pre>
947</div>
948
949<p>
950In the target language:
951</p>
952
953<div class="targetlang">
954<pre>
955&gt;&gt;&gt; get_path()
956/home/beazley/packages/Foo/Bar
957&gt;&gt;&gt;
958</pre>
959</div>
960
961<p>
962Internally, the wrapper function allocates a small buffer (on the stack) of the
963requested size and passes it as the pointer value. Data stored in the buffer is then
964returned as a function return value.
965If the function already returns a value, then the return value and the output string
966are returned together (multiple return values). <b>If more than <tt><em>maxsize</em></tt>
967bytes are written, your program will crash with a buffer overflow!</b>
968</p>
969
970</div>
971
972<p>
973<b>%cstring_chunk_output(parm, chunksize)</b>
974</p>
975
976<div class="indent">
977
978<p>
979Turns parameter <tt><em>parm</em></tt> into an output value. The
980output string is always <tt><em>chunksize</em></tt> and may contain
981binary data. Here is an example:
982</p>
983
984<div class="code">
985<pre>
986%cstring_chunk_output(char *packet, PACKETSIZE);
987...
988void get_packet(char *packet);
989</pre>
990</div>
991
992<p>
993In the target language:
994</p>
995
996<div class="targetlang">
997<pre>
998&gt;&gt;&gt; get_packet()
999'\xa9Y:\xf6\xd7\xe1\x87\xdbH;y\x97\x7f"\xd3\x99\x14V\xec\x06\xea\xa2\x88'
1000&gt;&gt;&gt;
1001</pre>
1002</div>
1003
1004<p>
1005This macro is essentially identical to <tt>%cstring_bounded_output</tt>. The
1006only difference is that the result is always <tt><em>chunksize</em></tt> characters.
1007Furthermore, the result can contain binary data.
1008<b>If more than <tt><em>maxsize</em></tt>
1009bytes are written, your program will crash with a buffer overflow!</b>
1010</p>
1011
1012</div>
1013
1014<p>
1015<b>%cstring_bounded_mutable(parm, maxsize)</b>
1016</p>
1017
1018<div class="indent">
1019
1020<p>
1021Turns parameter <tt><em>parm</em></tt> into a mutable string argument.
1022The input string is assumed to be NULL-terminated and smaller than
1023<tt><em>maxsize</em></tt> characters. The output string is also assumed
1024to be NULL-terminated and less than <tt><em>maxsize</em></tt> characters.
1025</p>
1026
1027<div class="code">
1028<pre>
1029%cstring_bounded_mutable(char *ustr, 1024);
1030...
1031void make_upper(char *ustr);
1032</pre>
1033</div>
1034
1035<p>
1036In the target language:
1037</p>
1038
1039<div class="targetlang">
1040<pre>
1041&gt;&gt;&gt; make_upper("hello world")
1042'HELLO WORLD'
1043&gt;&gt;&gt;
1044</pre>
1045</div>
1046
1047<p>
1048Internally, this macro is almost exactly the same as
1049<tt>%cstring_bounded_output</tt>. The only difference is that the
1050parameter accepts an input value that is used to initialize the
1051internal buffer. It is important to emphasize that this function
1052does not mutate the string value passed---instead it makes a copy of the
1053input value, mutates it, and returns it as a result.
1054<b>If more than <tt><em>maxsize</em></tt> bytes are
1055written, your program will crash with a buffer overflow!</b>
1056</p>
1057
1058</div>
1059
1060<p>
1061<b>%cstring_mutable(parm [, expansion])</b>
1062</p>
1063
1064<div class="indent">
1065
1066<p>
1067Turns parameter <tt><em>parm</em></tt> into a mutable string argument.
1068The input string is assumed to be NULL-terminated. An optional
1069parameter <tt><em>expansion</em></tt> specifies the number of
1070extra characters by which the string might grow when it is modified.
1071The output string is assumed to be NULL-terminated and less than
1072the size of the input string plus any expansion characters.
1073</p>
1074
1075<div class="code">
1076<pre>
1077%cstring_mutable(char *ustr);
1078...
1079void make_upper(char *ustr);
1080
1081%cstring_mutable(char *hstr, HEADER_SIZE);
1082...
1083void attach_header(char *hstr);
1084</pre>
1085</div>
1086
1087<p>
1088In the target language:
1089</p>
1090
1091<div class="targetlang">
1092<pre>
1093&gt;&gt;&gt; make_upper("hello world")
1094'HELLO WORLD'
1095&gt;&gt;&gt; attach_header("Hello world")
1096'header: Hello world'
1097&gt;&gt;&gt;
1098</pre>
1099</div>
1100
1101<p>
1102This macro differs from <tt>%cstring_bounded_mutable()</tt> in that a
1103buffer is dynamically allocated (on the heap using
1104<tt>malloc/new</tt>). This buffer is always large enough to store a
1105copy of the input value plus any expansion bytes that might have been
1106requested.
1107It is important to emphasize that this function
1108does not directly mutate the string value passed---instead it makes a copy of the
1109input value, mutates it, and returns it as a result.
1110<b>If the function expands the result by more than <tt><em>expansion</em></tt> extra
1111bytes, then the program will crash with a buffer overflow!</b>
1112</p>
1113
1114</div>
1115
1116
1117<p>
1118<b>%cstring_output_maxsize(parm, maxparm)</b>
1119</p>
1120
1121<div class="indent">
1122
1123<p>
1124This macro is used to handle bounded character output functions where
1125both a <tt>char *</tt> and a maximum length parameter are provided.
1126As input, a user simply supplies the maximum length.
1127The return value is assumed to be a NULL-terminated string.
1128</p>
1129
1130<div class="code">
1131<pre>
1132%cstring_output_maxsize(char *path, int maxpath);
1133...
1134void get_path(char *path, int maxpath);
1135</pre>
1136</div>
1137
1138<p>
1139In the target language:
1140</p>
1141
1142<div class="targetlang">
1143<pre>
1144&gt;&gt;&gt; get_path(1024)
1145'/home/beazley/Packages/Foo/Bar'
1146&gt;&gt;&gt;
1147</pre>
1148</div>
1149
1150<p>
1151This macro provides a safer alternative for functions that need to
1152write string data into a buffer. User supplied buffer size is
1153used to dynamically allocate memory on heap. Results are placed
1154into that buffer and returned as a string object.
1155</p>
1156
1157</div>
1158
1159
1160
1161<p>
1162<b>%cstring_output_withsize(parm, maxparm)</b>
1163</p>
1164
1165<div class="indent">
1166
1167<p>
1168This macro is used to handle bounded character output functions where
1169both a <tt>char *</tt> and a pointer <tt>int *</tt> are passed. Initially,
1170the <tt>int *</tt> parameter points to a value containing the maximum size.
1171On return, this value is assumed to contain the actual number of bytes.
1172As input, a user simply supplies the maximum length. The output value is a
1173string that may contain binary data.
1174</p>
1175
1176<div class="code">
1177<pre>
1178%cstring_output_withsize(char *data, int *maxdata);
1179...
1180void get_data(char *data, int *maxdata);
1181</pre>
1182</div>
1183
1184<p>
1185In the target language:
1186</p>
1187
1188<div class="targetlang">
1189<pre>
1190&gt;&gt;&gt; get_data(1024)
1191'x627388912'
1192&gt;&gt;&gt; get_data(1024)
1193'xyzzy'
1194&gt;&gt;&gt;
1195</pre>
1196</div>
1197
1198<p>
1199This macro is a somewhat more powerful version of <tt>%cstring_output_chunk()</tt>. Memory
1200is dynamically allocated and can be arbitrary large. Furthermore, a function can control
1201how much data is actually returned by changing the value of the <tt>maxparm</tt> argument.
1202</p>
1203
1204</div>
1205
1206
1207<p>
1208<b>%cstring_output_allocate(parm, release)</b>
1209</p>
1210
1211<div class="indent">
1212
1213<p>
1214This macro is used to return strings that are allocated within the program and
1215returned in a parameter of type <tt>char **</tt>. For example:
1216</p>
1217
1218<div class="code">
1219<pre>
1220void foo(char **s) {
1221 *s = (char *) malloc(64);
1222 sprintf(*s, "Hello world\n");
1223}
1224</pre>
1225</div>
1226
1227<p>
1228The returned string is assumed to be NULL-terminated. <tt><em>release</em></tt>
1229specifies how the allocated memory is to be released (if applicable). Here is an
1230example:
1231</p>
1232
1233<div class="code">
1234<pre>
1235%cstring_output_allocate(char **s, free(*$1));
1236...
1237void foo(char **s);
1238</pre>
1239</div>
1240
1241<p>
1242In the target language:
1243</p>
1244
1245<div class="targetlang">
1246<pre>
1247&gt;&gt;&gt; foo()
1248'Hello world\n'
1249&gt;&gt;&gt;
1250</pre>
1251</div>
1252</div>
1253
1254
1255<p>
1256<b>%cstring_output_allocate_size(parm, szparm, release)</b>
1257</p>
1258
1259<div class="indent">
1260
1261<p>
1262This macro is used to return strings that are allocated within the program and
1263returned in two parameters of type <tt>char **</tt> and <tt>int *</tt>. For example:
1264</p>
1265
1266<div class="code">
1267<pre>
1268void foo(char **s, int *sz) {
1269 *s = (char *) malloc(64);
1270 *sz = 64;
1271 // Write some binary data
1272 ...
1273}
1274</pre>
1275</div>
1276
1277<p>
1278The returned string may contain binary data. <tt><em>release</em></tt>
1279specifies how the allocated memory is to be released (if applicable). Here is an
1280example:
1281</p>
1282
1283<div class="code">
1284<pre>
1285%cstring_output_allocate_size(char **s, int *slen, free(*$1));
1286...
1287void foo(char **s, int *slen);
1288</pre>
1289</div>
1290
1291<p>
1292In the target language:
1293</p>
1294
1295<div class="targetlang">
1296<pre>
1297&gt;&gt;&gt; foo()
1298'\xa9Y:\xf6\xd7\xe1\x87\xdbH;y\x97\x7f"\xd3\x99\x14V\xec\x06\xea\xa2\x88'
1299&gt;&gt;&gt;
1300</pre>
1301</div>
1302
1303<p>
1304This is the safest and most reliable way to return binary string data in
1305SWIG. If you have functions that conform to another prototype, you might
1306consider wrapping them with a helper function. For example, if you had this:
1307</p>
1308
1309<div class="code">
1310<pre>
1311char *get_data(int *len);
1312</pre>
1313</div>
1314
1315<p>
1316You could wrap it with a function like this:
1317</p>
1318
1319<div class="code">
1320<pre>
1321void my_get_data(char **result, int *len) {
1322 *result = get_data(len);
1323}
1324</pre>
1325</div>
1326</div>
1327
1328<p>
1329<b>Comments:</b>
1330</p>
1331
1332<ul>
1333<li>Support for the <tt>cstring.i</tt> module depends on the target language. Not all
1334SWIG modules currently support this library.
1335</li>
1336
1337<li>Reliable handling of raw C strings is a delicate topic. There are many ways
1338to accomplish this in SWIG. This library provides support for a few common techniques.
1339</li>
1340
1341<li>If used in C++, this library uses <tt>new</tt> and <tt>delete []</tt> for memory
1342allocation. If using ANSI C, the library uses <tt>malloc()</tt> and <tt>free()</tt>.
1343</li>
1344
1345<li>Rather than manipulating <tt>char *</tt> directly, you might consider using a special string
1346structure or class instead.
1347</li>
1348</ul>
1349
1350<H2><a name="Library_stl_cpp_library"></a>8.4 STL/C++ Library</H2>
1351
1352
1353<p>
1354The library modules in this section provide access to parts of the standard C++ library including the STL.
1355SWIG support for the STL is an ongoing effort. Support is quite comprehensive for some language modules
1356but some of the lesser used modules do not have quite as much library code written.
1357</p>
1358
1359<p>
1360The following table shows which C++ classes are supported and the equivalent SWIG interface library file for the C++ library.
1361</p>
1362
1363<table BORDER summary="SWIG C++ library files">
1364<tr VALIGN=TOP>
1365<td><b>C++ class</b></td>
1366<td><b>C++ Library file</b></td>
1367<td><b>SWIG Interface library file</b></td>
1368</tr>
1369
1370<tr> <td>std::deque</td> <td>deque</td> <td>std_deque.i</td> </tr>
1371<tr> <td>std::list</td> <td>list</td> <td>std_list.i</td> </tr>
1372<tr> <td>std::map</td> <td>map</td> <td>std_map.i</td> </tr>
1373<tr> <td>std::pair</td> <td>utility</td> <td>std_pair.i</td> </tr>
1374<tr> <td>std::set</td> <td>set</td> <td>std_set.i</td> </tr>
1375<tr> <td>std::string</td> <td>string</td> <td>std_string.i</td> </tr>
1376<tr> <td>std::vector</td> <td>vector</td> <td>std_vector.i</td> </tr>
1377
1378</table>
1379
1380<p>
1381The list is by no means complete; some language modules support a subset of the above and some support additional STL classes.
1382Please look for the library files in the appropriate language library directory.
1383</p>
1384
1385
1386<H3><a name="Library_nn14"></a>8.4.1 std_string.i</H3>
1387
1388
1389<p>
1390The <tt>std_string.i</tt> library provides typemaps for converting C++ <tt>std::string</tt>
1391objects to and from strings in the target scripting language. For example:
1392</p>
1393
1394<div class="code">
1395<pre>
1396%module example
1397%include "std_string.i"
1398
1399std::string foo();
1400void bar(const std::string &amp;x);
1401</pre>
1402</div>
1403
1404<p>
1405In the target language:
1406</p>
1407
1408<div class="targetlang">
1409<pre>
1410x = foo(); # Returns a string object
1411bar("Hello World"); # Pass string as std::string
1412</pre>
1413</div>
1414
1415<p>
1416This module only supports types <tt>std::string</tt> and
1417<tt>const std::string &amp;</tt>. Pointers and non-const references
1418are left unmodified and returned as SWIG pointers.
1419</p>
1420
1421<p>
1422This library file is fully aware of C++ namespaces. If you export <tt>std::string</tt> or rename
1423it with a typedef, make sure you include those declarations in your interface. For example:
1424</p>
1425
1426<div class="code">
1427<pre>
1428%module example
1429%include "std_string.i"
1430
1431using namespace std;
1432typedef std::string String;
1433...
1434void foo(string s, const String &amp;t); // std_string typemaps still applied
1435</pre>
1436</div>
1437
1438<p>
1439<b>Note:</b> The <tt>std_string</tt> library is incompatible with Perl on some platforms.
1440We're looking into it.
1441</p>
1442
1443<H3><a name="Library_nn15"></a>8.4.2 std_vector.i</H3>
1444
1445
1446<p>
1447The <tt>std_vector.i</tt> library provides support for the C++ <tt>vector</tt> class in the STL.
1448Using this library involves the use of the <tt>%template</tt> directive. All you need to do is to
1449instantiate different versions of <tt>vector</tt> for the types that you want to use. For example:
1450</p>
1451
1452<div class="code">
1453<pre>
1454%module example
1455%include "std_vector.i"
1456
1457namespace std {
1458 %template(vectori) vector&lt;int&gt;;
1459 %template(vectord) vector&lt;double&gt;;
1460};
1461</pre>
1462</div>
1463
1464<p>
1465When a template <tt>vector&lt;X&gt;</tt> is instantiated a number of things happen:
1466</p>
1467
1468<ul>
1469<li>A class that exposes the C++ API is created in the target language .
1470This can be used to create objects, invoke methods, etc. This class is
1471currently a subset of the real STL vector class.
1472</li>
1473
1474<li>Input typemaps are defined for <tt>vector&lt;X&gt;</tt>, <tt>const vector&lt;X&gt; &amp;</tt>, and
1475<tt>const vector&lt;X&gt; *</tt>. For each of these, a pointer <tt>vector&lt;X&gt; *</tt> may be passed or
1476a native list object in the target language.
1477</li>
1478
1479<li>An output typemap is defined for <tt>vector&lt;X&gt;</tt>. In this case, the values in the
1480vector are expanded into a list object in the target language.
1481</li>
1482
1483<li>For all other variations of the type, the wrappers expect to receive a <tt>vector&lt;X&gt; *</tt>
1484object in the usual manner.
1485</li>
1486
1487<li>An exception handler for <tt>std::out_of_range</tt> is defined.
1488</li>
1489
1490<li>Optionally, special methods for indexing, item retrieval, slicing, and element assignment
1491may be defined. This depends on the target language.
1492</li>
1493</ul>
1494
1495<p>
1496To illustrate the use of this library, consider the following functions:
1497</p>
1498
1499<div class="code">
1500<pre>
1501/* File : example.h */
1502
1503#include &lt;vector&gt;
1504#include &lt;algorithm&gt;
1505#include &lt;functional&gt;
1506#include &lt;numeric&gt;
1507
1508double average(std::vector&lt;int&gt; v) {
1509 return std::accumulate(v.begin(),v.end(),0.0)/v.size();
1510}
1511
1512std::vector&lt;double&gt; half(const std::vector&lt;double&gt;&amp; v) {
1513 std::vector&lt;double&gt; w(v);
1514 for (unsigned int i=0; i&lt;w.size(); i++)
1515 w[i] /= 2.0;
1516 return w;
1517}
1518
1519void halve_in_place(std::vector&lt;double&gt;&amp; v) {
1520 std::transform(v.begin(),v.end(),v.begin(),
1521 std::bind2nd(std::divides&lt;double&gt;(),2.0));
1522}
1523</pre>
1524</div>
1525
1526<p>
1527To wrap with SWIG, you might write the following:
1528</p>
1529
1530<div class="code">
1531<pre>
1532%module example
1533%{
1534#include "example.h"
1535%}
1536
1537%include "std_vector.i"
1538// Instantiate templates used by example
1539namespace std {
1540 %template(IntVector) vector&lt;int&gt;;
1541 %template(DoubleVector) vector&lt;double&gt;;
1542}
1543
1544// Include the header file with above prototypes
1545%include "example.h"
1546</pre>
1547</div>
1548
1549<p>
1550Now, to illustrate the behavior in the scripting interpreter, consider this Python example:
1551</p>
1552
1553<div class="targetlang">
1554<pre>
1555&gt;&gt;&gt; from example import *
1556&gt;&gt;&gt; iv = IntVector(4) # Create an vector&lt;int&gt;
1557&gt;&gt;&gt; for i in range(0,4):
1558... iv[i] = i
1559&gt;&gt;&gt; average(iv) # Call method
15601.5
1561&gt;&gt;&gt; average([0,1,2,3]) # Call with list
15621.5
1563&gt;&gt;&gt; half([1,2,3]) # Half a list
1564(0.5,1.0,1.5)
1565&gt;&gt;&gt; halve_in_place([1,2,3]) # Oops
1566Traceback (most recent call last):
1567 File "&lt;stdin&gt;", line 1, in ?
1568TypeError: Type error. Expected _p_std__vectorTdouble_t
1569&gt;&gt;&gt; dv = DoubleVector(4)
1570&gt;&gt;&gt; for i in range(0,4):
1571... dv[i] = i
1572&gt;&gt;&gt; halve_in_place(dv) # Ok
1573&gt;&gt;&gt; for i in dv:
1574... print i
1575...
15760.0
15770.5
15781.0
15791.5
1580&gt;&gt;&gt; dv[20] = 4.5
1581Traceback (most recent call last):
1582 File "&lt;stdin&gt;", line 1, in ?
1583 File "example.py", line 81, in __setitem__
1584 def __setitem__(*args): return apply(examplec.DoubleVector___setitem__,args)
1585IndexError: vector index out of range
1586&gt;&gt;&gt;
1587</pre>
1588</div>
1589
1590<p>
1591This library module is fully aware of C++ namespaces. If you use vectors with other names,
1592make sure you include the appropriate <tt>using</tt> or typedef directives. For example:
1593</p>
1594
1595<div class="code">
1596<pre>
1597%include "std_vector.i"
1598
1599namespace std {
1600 %template(IntVector) vector&lt;int&gt;;
1601}
1602
1603using namespace std;
1604typedef std::vector Vector;
1605
1606void foo(vector&lt;int&gt; *x, const Vector &amp;x);
1607</pre>
1608</div>
1609
1610<p>
1611<b>Note:</b> This module makes use of several advanced SWIG features including templatized typemaps
1612and template partial specialization. If you are tring to wrap other C++ code with templates, you
1613might look at the code contained in <tt>std_vector.i</tt>. Alternatively, you can show them the code
1614if you want to make their head explode.
1615</p>
1616
1617<p>
1618<b>Note:</b> This module is defined for all SWIG target languages. However argument conversion
1619details and the public API exposed to the interpreter vary.
1620</p>
1621
1622<p>
1623<b>Note:</b> <tt>std_vector.i</tt> was written by Luigi "The Amazing" Ballabio.
1624</p>
1625
1626
1627<H3><a name="Library_stl_exceptions"></a>8.4.3 STL exceptions</H3>
1628
1629
1630<p>
1631Many of the STL wrapper functions add parameter checking and will throw a language dependent error/exception
1632should the values not be valid. The classic example is array bounds checking.
1633The library wrappers are written to throw a C++ exception in the case of error.
1634The C++ exception in turn gets converted into an appropriate error/exception for the target language.
1635By and large this handling should not need customising, however, customisation can easily be achieved by supplying appropriate "throws" typemaps.
1636For example:
1637</p>
1638
1639<div class="code">
1640<pre>
1641%module example
1642%include "std_vector.i"
1643%typemap(throws) std::out_of_range {
1644 // custom exception handler
1645}
1646%template(VectInt) std::vector&lt;int&gt;;
1647</pre>
1648</div>
1649
1650<p>
1651The custom exception handler might, for example, log the exception then convert it into a specific error/exception for the target language.
1652</p>
1653
1654<p>
1655When using the STL it is advisable to add in an exception handler to catch all STL exceptions.
1656The <tt>%exception</tt> directive can be used by placing the following code before any other methods or libraries to be wrapped:
1657</p>
1658
1659<div class="code">
1660<pre>
1661%include "exception.i"
1662
1663%exception {
1664 try {
1665 $action
1666 } catch (const std::exception&amp; e) {
1667 SWIG_exception(SWIG_RuntimeError, e.what());
1668 }
1669}
1670</pre>
1671</div>
1672
1673<p>
1674Any thrown STL exceptions will then be gracefully handled instead of causing a crash.
1675</p>
1676
1677
1678<H2><a name="Library_nn16"></a>8.5 Utility Libraries</H2>
1679
1680
1681<H3><a name="Library_nn17"></a>8.5.1 exception.i</H3>
1682
1683
1684<p>
1685The <tt>exception.i</tt> library provides a language-independent function for raising a run-time
1686exception in the target language. This library is largely used by the SWIG library writers.
1687If possible, use the error handling scheme available to your target language as there is greater
1688flexibility in what errors/exceptions can be thrown.
1689</p>
1690
1691<p>
1692<b><tt>SWIG_exception(int code, const char *message)</tt></b>
1693</p>
1694
1695<div class="indent">
1696
1697<p>
1698Raises an exception in the target language. <tt>code</tt> is one of the following symbolic
1699constants:
1700</p>
1701
1702<div class="code">
1703<pre>
1704SWIG_MemoryError
1705SWIG_IOError
1706SWIG_RuntimeError
1707SWIG_IndexError
1708SWIG_TypeError
1709SWIG_DivisionByZero
1710SWIG_OverflowError
1711SWIG_SyntaxError
1712SWIG_ValueError
1713SWIG_SystemError
1714</pre>
1715</div>
1716
1717<p>
1718<tt>message</tt> is a string indicating more information about the problem.
1719</p>
1720
1721</div>
1722
1723<p>
1724The primary use of this module is in writing language-independent exception handlers.
1725For example:
1726</p>
1727
1728<div class="code">
1729<pre>
1730%include "exception.i"
1731%exception std::vector::getitem {
1732 try {
1733 $action
1734 } catch (std::out_of_range&amp; e) {
1735 SWIG_exception(SWIG_IndexError,const_cast&lt;char*&gt;(e.what()));
1736 }
1737}
1738</pre>
1739</div>
1740
1741
1742</body>
1743</html>