| 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| 2 | <html> |
| 3 | <head> |
| 4 | <title>Typemaps</title> |
| 5 | <link rel="stylesheet" type="text/css" href="style.css"> |
| 6 | </head> |
| 7 | |
| 8 | <body bgcolor="#ffffff"> |
| 9 | <H1><a name="Typemaps"></a>10 Typemaps</H1> |
| 10 | <!-- INDEX --> |
| 11 | <div class="sectiontoc"> |
| 12 | <ul> |
| 13 | <li><a href="#Typemaps_nn2">Introduction</a> |
| 14 | <ul> |
| 15 | <li><a href="#Typemaps_nn3">Type conversion</a> |
| 16 | <li><a href="#Typemaps_nn4">Typemaps</a> |
| 17 | <li><a href="#Typemaps_nn5">Pattern matching</a> |
| 18 | <li><a href="#Typemaps_nn6">Reusing typemaps</a> |
| 19 | <li><a href="#Typemaps_nn7">What can be done with typemaps?</a> |
| 20 | <li><a href="#Typemaps_nn8">What can't be done with typemaps?</a> |
| 21 | <li><a href="#Typemaps_nn9">The rest of this chapter</a> |
| 22 | </ul> |
| 23 | <li><a href="#Typemaps_nn10">Typemap specifications</a> |
| 24 | <ul> |
| 25 | <li><a href="#Typemaps_nn11">Defining a typemap</a> |
| 26 | <li><a href="#Typemaps_nn12">Typemap scope</a> |
| 27 | <li><a href="#Typemaps_nn13">Copying a typemap</a> |
| 28 | <li><a href="#Typemaps_nn14">Deleting a typemap</a> |
| 29 | <li><a href="#Typemaps_nn15">Placement of typemaps</a> |
| 30 | </ul> |
| 31 | <li><a href="#Typemaps_nn16">Pattern matching rules</a> |
| 32 | <ul> |
| 33 | <li><a href="#Typemaps_nn17">Basic matching rules</a> |
| 34 | <li><a href="#Typemaps_nn18">Typedef reductions</a> |
| 35 | <li><a href="#Typemaps_nn19">Default typemaps</a> |
| 36 | <li><a href="#Typemaps_mixed_default">Mixed default typemaps</a> |
| 37 | <li><a href="#Typemaps_nn20">Multi-arguments typemaps</a> |
| 38 | </ul> |
| 39 | <li><a href="#Typemaps_nn21">Code generation rules</a> |
| 40 | <ul> |
| 41 | <li><a href="#Typemaps_nn22">Scope</a> |
| 42 | <li><a href="#Typemaps_nn23">Declaring new local variables</a> |
| 43 | <li><a href="#Typemaps_nn24">Special variables</a> |
| 44 | </ul> |
| 45 | <li><a href="#Typemaps_nn25">Common typemap methods</a> |
| 46 | <ul> |
| 47 | <li><a href="#Typemaps_nn26">"in" typemap</a> |
| 48 | <li><a href="#Typemaps_nn27">"typecheck" typemap</a> |
| 49 | <li><a href="#Typemaps_nn28">"out" typemap</a> |
| 50 | <li><a href="#Typemaps_nn29">"arginit" typemap</a> |
| 51 | <li><a href="#Typemaps_nn30">"default" typemap</a> |
| 52 | <li><a href="#Typemaps_nn31">"check" typemap</a> |
| 53 | <li><a href="#Typemaps_nn32">"argout" typemap</a> |
| 54 | <li><a href="#Typemaps_nn33">"freearg" typemap</a> |
| 55 | <li><a href="#Typemaps_nn34">"newfree" typemap</a> |
| 56 | <li><a href="#Typemaps_nn35">"memberin" typemap</a> |
| 57 | <li><a href="#Typemaps_nn36">"varin" typemap</a> |
| 58 | <li><a href="#Typemaps_nn37">"varout" typemap</a> |
| 59 | <li><a href="#throws_typemap">"throws" typemap</a> |
| 60 | </ul> |
| 61 | <li><a href="#Typemaps_nn39">Some typemap examples</a> |
| 62 | <ul> |
| 63 | <li><a href="#Typemaps_nn40">Typemaps for arrays</a> |
| 64 | <li><a href="#Typemaps_nn41">Implementing constraints with typemaps</a> |
| 65 | </ul> |
| 66 | <li><a href="#Typemaps_nn42">Multi-argument typemaps</a> |
| 67 | <li><a href="#runtime_type_checker">The run-time type checker</a> |
| 68 | <ul> |
| 69 | <li><a href="#Typemaps_nn45">Implementation</a> |
| 70 | <li><a href="#Typemaps_nn46">Usage</a> |
| 71 | </ul> |
| 72 | <li><a href="#Typemaps_overloading">Typemaps and overloading</a> |
| 73 | <li><a href="#Typemaps_nn48">More about <tt>%apply</tt> and <tt>%clear</tt></a> |
| 74 | <li><a href="#Typemaps_nn49">Reducing wrapper code size</a> |
| 75 | <li><a href="#Typemaps_nn47">Passing data between typemaps</a> |
| 76 | <li><a href="#Typemaps_nn51">Where to go for more information?</a> |
| 77 | </ul> |
| 78 | </div> |
| 79 | <!-- INDEX --> |
| 80 | |
| 81 | |
| 82 | |
| 83 | <p> |
| 84 | <b>Disclaimer: This chapter is under construction!</b> |
| 85 | </p> |
| 86 | |
| 87 | <H2><a name="Typemaps_nn2"></a>10.1 Introduction</H2> |
| 88 | |
| 89 | |
| 90 | <p> |
| 91 | Chances are, you are reading this chapter for one of two reasons; you |
| 92 | either want to customize SWIG's behavior or you overheard someone |
| 93 | mumbling some incomprehensible drivel about "typemaps" and you asked |
| 94 | yourself "typemaps, what are those?" That said, let's start with a |
| 95 | short disclaimer that "typemaps" are an advanced customization feature |
| 96 | that provide direct access to SWIG's low-level code generator. Not |
| 97 | only that, they are an integral part of the SWIG C++ type system (a |
| 98 | non-trivial topic of its own). Typemaps are generally |
| 99 | <em>not</em> a required part of using SWIG. Therefore, you might want |
| 100 | to re-read the earlier chapters if you have found your way to this |
| 101 | chapter with only a vaque idea of what SWIG already does by default. |
| 102 | </p> |
| 103 | |
| 104 | <H3><a name="Typemaps_nn3"></a>10.1.1 Type conversion</H3> |
| 105 | |
| 106 | |
| 107 | <p> |
| 108 | One of the most important problems in wrapper code generation is the |
| 109 | conversion of datatypes between programming languages. Specifically, |
| 110 | for every C/C++ declaration, SWIG must somehow generate wrapper code |
| 111 | that allows values to be passed back and forth between languages. |
| 112 | Since every programming language represents data differently, this is |
| 113 | not a simple of matter of simply linking code together with the |
| 114 | C linker. Instead, SWIG has to know something about how data is |
| 115 | represented in each language and how it can be manipulated. |
| 116 | </p> |
| 117 | |
| 118 | <p> |
| 119 | To illustrate, suppose you had a simple C function like this: |
| 120 | </p> |
| 121 | |
| 122 | <div class="code"> |
| 123 | <pre> |
| 124 | int factorial(int n); |
| 125 | </pre> |
| 126 | </div> |
| 127 | |
| 128 | <p> |
| 129 | To access this function from Python, a pair of Python API functions |
| 130 | are used to convert integer values. For example: |
| 131 | </p> |
| 132 | |
| 133 | <div class="code"> |
| 134 | <pre> |
| 135 | long PyInt_AsLong(PyObject *obj); /* Python --> C */ |
| 136 | PyObject *PyInt_FromLong(long x); /* C --> Python */ |
| 137 | </pre> |
| 138 | </div> |
| 139 | |
| 140 | <p> |
| 141 | The first function is used to convert the input argument from a Python integer object |
| 142 | to C <tt>long</tt>. The second function is used to convert a value from C back into a Python integer object. |
| 143 | </p> |
| 144 | |
| 145 | <p> |
| 146 | Inside the wrapper function, you might see these functions used like this: |
| 147 | </p> |
| 148 | |
| 149 | <div class="code"> |
| 150 | <pre> |
| 151 | PyObject *wrap_factorial(PyObject *self, PyObject *args) { |
| 152 | int arg1; |
| 153 | int result; |
| 154 | PyObject *obj1; |
| 155 | PyObject *resultobj; |
| 156 | |
| 157 | if (!PyArg_ParseTuple("O:factorial", &obj1)) return NULL; |
| 158 | <b>arg1 = PyInt_AsLong(obj1);</b> |
| 159 | result = factorial(arg1); |
| 160 | <b>resultobj = PyInt_FromLong(result);</b> |
| 161 | return resultobj; |
| 162 | } |
| 163 | </pre> |
| 164 | </div> |
| 165 | |
| 166 | <p> |
| 167 | Every target language supported by SWIG has functions that work in a similar manner. For example, in |
| 168 | Perl, the following functions are used: |
| 169 | </p> |
| 170 | |
| 171 | <div class="code"> |
| 172 | <pre> |
| 173 | IV SvIV(SV *sv); /* Perl --> C */ |
| 174 | void sv_setiv(SV *sv, IV val); /* C --> Perl */ |
| 175 | </pre> |
| 176 | </div> |
| 177 | |
| 178 | <p> |
| 179 | In Tcl: |
| 180 | </p> |
| 181 | |
| 182 | <div class="code"> |
| 183 | <pre> |
| 184 | int Tcl_GetLongFromObj(Tcl_Interp *interp, Tcl_Obj *obj, long *value); |
| 185 | Tcl_Obj *Tcl_NewIntObj(long value); |
| 186 | </pre> |
| 187 | </div> |
| 188 | |
| 189 | <p> |
| 190 | The precise details are not so important. What is important is that |
| 191 | all of the underlying type conversion is handled by collections of |
| 192 | utility functions and short bits of C code like this---you simply have |
| 193 | to read the extension documentation for your favorite language to know |
| 194 | how it works (an exercise left to the reader). |
| 195 | </p> |
| 196 | |
| 197 | <H3><a name="Typemaps_nn4"></a>10.1.2 Typemaps</H3> |
| 198 | |
| 199 | |
| 200 | <p> |
| 201 | Since type handling is so central to wrapper code generation, SWIG |
| 202 | allows it to be completely defined (or redefined) by the user. To do this, |
| 203 | a special <tt>%typemap</tt> directive is used. For example: |
| 204 | </p> |
| 205 | |
| 206 | <div class="code"> |
| 207 | <pre> |
| 208 | /* Convert from Python --> C */ |
| 209 | %typemap(in) int { |
| 210 | $1 = PyInt_AsLong($input); |
| 211 | } |
| 212 | |
| 213 | /* Convert from C --> Python */ |
| 214 | %typemap(out) int { |
| 215 | $result = PyInt_FromLong($1); |
| 216 | } |
| 217 | </pre> |
| 218 | </div> |
| 219 | |
| 220 | <p> |
| 221 | At first glance, this code will look a little confusing. |
| 222 | However, there is really not much to it. The first typemap (the "in" |
| 223 | typemap) is used to convert a value from the target language to C. The second |
| 224 | typemap (the "out" typemap) is used to convert in the other |
| 225 | direction. The content of each typemap is a small fragment of C code |
| 226 | that is inserted directly into the SWIG generated wrapper functions. Within |
| 227 | this code, a number of special variables prefixed with a $ are expanded. These are |
| 228 | really just placeholders for C variables that are generated in the course |
| 229 | of creating the wrapper function. In this case, <tt>$input</tt> refers to an |
| 230 | input object that needs to be converted to C and <tt>$result</tt> |
| 231 | refers to an object that is going to be returned by a wrapper |
| 232 | function. <tt>$1</tt> refers to a C variable that has the same type as |
| 233 | specified in the typemap declaration (an <tt>int</tt> in this |
| 234 | example). |
| 235 | </p> |
| 236 | |
| 237 | <p> |
| 238 | A short example might make this a little more clear. If you were wrapping a |
| 239 | function like this: |
| 240 | </p> |
| 241 | |
| 242 | <div class="code"> |
| 243 | <pre> |
| 244 | int gcd(int x, int y); |
| 245 | </pre> |
| 246 | </div> |
| 247 | |
| 248 | <p> |
| 249 | A wrapper function would look approximately like this: |
| 250 | </p> |
| 251 | |
| 252 | <div class="code"> |
| 253 | <pre> |
| 254 | PyObject *wrap_gcd(PyObject *self, PyObject *args) { |
| 255 | int arg1; |
| 256 | int arg2; |
| 257 | int result; |
| 258 | PyObject *obj1; |
| 259 | PyObject *obj2; |
| 260 | PyObject *resultobj; |
| 261 | |
| 262 | if (!PyArg_ParseTuple("OO:gcd", &obj1, &obj2)) return NULL; |
| 263 | |
| 264 | /* "in" typemap, argument 1 */<b> |
| 265 | { |
| 266 | arg1 = PyInt_AsLong(obj1); |
| 267 | } |
| 268 | </b> |
| 269 | /* "in" typemap, argument 2 */<b> |
| 270 | { |
| 271 | arg2 = PyInt_AsLong(obj2); |
| 272 | } |
| 273 | </b> |
| 274 | result = gcd(arg1,arg2); |
| 275 | |
| 276 | /* "out" typemap, return value */<b> |
| 277 | { |
| 278 | resultobj = PyInt_FromLong(result); |
| 279 | } |
| 280 | </b> |
| 281 | return resultobj; |
| 282 | } |
| 283 | </pre> |
| 284 | </div> |
| 285 | |
| 286 | <p> |
| 287 | In this code, you can see how the typemap code has been inserted into |
| 288 | the function. You can also see how the special $ variables have been |
| 289 | expanded to match certain variable names inside the wrapper function. This is really the |
| 290 | whole idea behind typemaps--they simply let you insert arbitrary code into different |
| 291 | parts of the generated wrapper functions. Because arbitrary code can be inserted, it |
| 292 | possible to completely change the way in which values are converted. |
| 293 | </p> |
| 294 | |
| 295 | <H3><a name="Typemaps_nn5"></a>10.1.3 Pattern matching</H3> |
| 296 | |
| 297 | |
| 298 | <p> |
| 299 | As the name implies, the purpose of a typemap is to "map" C datatypes to |
| 300 | types in the target language. Once a typemap is defined for a C datatype, |
| 301 | it is applied to all future occurrences of that type in the input file. For example: |
| 302 | </p> |
| 303 | |
| 304 | <div class="code"> |
| 305 | <pre> |
| 306 | /* Convert from Perl --> C */ |
| 307 | %typemap(in) <b>int</b> { |
| 308 | $1 = SvIV($input); |
| 309 | } |
| 310 | |
| 311 | ... |
| 312 | int factorial(<b>int</b> n); |
| 313 | int gcd(<b>int</b> x, <b>int</b> y); |
| 314 | int count(char *s, char *t, <b>int</b> max); |
| 315 | </pre> |
| 316 | </div> |
| 317 | |
| 318 | <p> |
| 319 | The matching of typemaps to C datatypes is more than a simple textual match. In fact, |
| 320 | typemaps are fully built into the underlying type system. Therefore, typemaps are |
| 321 | unaffected by <tt>typedef</tt>, namespaces, and other declarations that might hide the |
| 322 | underlying type. For example, you could have code like this: |
| 323 | </p> |
| 324 | |
| 325 | <div class="code"> |
| 326 | <pre> |
| 327 | /* Convert from Ruby--> C */ |
| 328 | %typemap(in) <b>int</b> { |
| 329 | $1 = NUM2INT($input); |
| 330 | } |
| 331 | ... |
| 332 | typedef int Integer; |
| 333 | namespace foo { |
| 334 | typedef Integer Number; |
| 335 | }; |
| 336 | |
| 337 | int foo(<b>int</b> x); |
| 338 | int bar(<b>Integer</b> y); |
| 339 | int spam(<b>foo::Number</b> a, <b>foo::Number</b> b); |
| 340 | </pre> |
| 341 | </div> |
| 342 | |
| 343 | <p> |
| 344 | In this case, the typemap is still applied to the proper arguments even though typenames don't always |
| 345 | match the text "int". This ability to track types is a critical part of SWIG--in fact, all |
| 346 | of the target language modules work merely define a set of typemaps for the basic types. Yet, it |
| 347 | is never necessary to write new typemaps for typenames introduced by <tt>typedef</tt>. |
| 348 | </p> |
| 349 | |
| 350 | <p> |
| 351 | In addition to tracking typenames, typemaps may also be specialized to match against a specific argument name. For |
| 352 | example, you could write a typemap like this: |
| 353 | </p> |
| 354 | |
| 355 | <div class="code"> |
| 356 | <pre> |
| 357 | %typemap(in) <b>double nonnegative</b> { |
| 358 | $1 = PyFloat_AsDouble($input); |
| 359 | if ($1 < 0) { |
| 360 | PyErr_SetString(PyExc_ValueError,"argument must be nonnegative."); |
| 361 | return NULL; |
| 362 | } |
| 363 | } |
| 364 | |
| 365 | ... |
| 366 | double sin(double x); |
| 367 | double cos(double x); |
| 368 | double sqrt(<b>double nonnegative</b>); |
| 369 | |
| 370 | typedef double Real; |
| 371 | double log(<b>Real nonnegative</b>); |
| 372 | ... |
| 373 | </pre> |
| 374 | </div> |
| 375 | |
| 376 | <p> |
| 377 | For certain tasks such as input argument conversion, typemaps can be defined for sequences of |
| 378 | consecutive arguments. For example: |
| 379 | </p> |
| 380 | |
| 381 | <div class="code"> |
| 382 | <pre> |
| 383 | %typemap(in) (<b>char *str, int len</b>) { |
| 384 | $1 = PyString_AsString($input); /* char *str */ |
| 385 | $2 = PyString_Size($input); /* int len */ |
| 386 | } |
| 387 | ... |
| 388 | int count(<b>char *str, int len</b>, char c); |
| 389 | </pre> |
| 390 | </div> |
| 391 | |
| 392 | <p> |
| 393 | In this case, a single input object is expanded into a pair of C arguments. This example also |
| 394 | provides a hint to the unusual variable naming scheme involving <tt>$1</tt>, <tt>$2</tt>, and so forth. |
| 395 | </p> |
| 396 | |
| 397 | <H3><a name="Typemaps_nn6"></a>10.1.4 Reusing typemaps</H3> |
| 398 | |
| 399 | |
| 400 | <p> |
| 401 | Typemaps are normally defined for specific type and argument name patterns. However, typemaps can also |
| 402 | be copied and reused. One way to do this is to use assignment like this: |
| 403 | </p> |
| 404 | |
| 405 | <div class="code"> |
| 406 | <pre> |
| 407 | %typemap(in) Integer = int; |
| 408 | %typemap(in) (char *buffer, int size) = (char *str, int len); |
| 409 | </pre> |
| 410 | </div> |
| 411 | |
| 412 | <p> |
| 413 | A more general form of copying is found in the <tt>%apply</tt> directive like this: |
| 414 | </p> |
| 415 | |
| 416 | <div class="code"> |
| 417 | <pre> |
| 418 | %typemap(in) int { |
| 419 | /* Convert an integer argument */ |
| 420 | ... |
| 421 | } |
| 422 | %typemap(out) int { |
| 423 | /* Return an integer value */ |
| 424 | ... |
| 425 | } |
| 426 | |
| 427 | /* Apply all of the integer typemaps to size_t */ |
| 428 | %apply int { size_t }; |
| 429 | </pre> |
| 430 | </div> |
| 431 | |
| 432 | <p> |
| 433 | <tt>%apply</tt> merely takes <em>all</em> of the typemaps that are defined for one type and |
| 434 | applies them to other types. Note: you can include a comma separated set of types in the |
| 435 | <tt>{ ... }</tt> part of <tt>%apply</tt>. |
| 436 | </p> |
| 437 | |
| 438 | <p> |
| 439 | It should be noted that it is not necessary to copy typemaps for types that are related by <tt>typedef</tt>. |
| 440 | For example, if you have this, |
| 441 | </p> |
| 442 | |
| 443 | <div class="code"> |
| 444 | <pre> |
| 445 | typedef int size_t; |
| 446 | </pre> |
| 447 | </div> |
| 448 | |
| 449 | <p> |
| 450 | then SWIG already knows that the <tt>int</tt> typemaps apply. You don't have to do anything. |
| 451 | </p> |
| 452 | |
| 453 | <H3><a name="Typemaps_nn7"></a>10.1.5 What can be done with typemaps?</H3> |
| 454 | |
| 455 | |
| 456 | <p> |
| 457 | The primary use of typemaps is for defining wrapper generation behavior at the level |
| 458 | of individual C/C++ datatypes. There are currently six general categories of problems that |
| 459 | typemaps address: |
| 460 | </p> |
| 461 | |
| 462 | <p> |
| 463 | <b>Argument handling</b> |
| 464 | </p> |
| 465 | |
| 466 | <div class="code"> |
| 467 | <pre> |
| 468 | int foo(<b>int x, double y, char *s</b>); |
| 469 | </pre> |
| 470 | </div> |
| 471 | |
| 472 | <ul> |
| 473 | <li>Input argument conversion ("in" typemap).</li> |
| 474 | <li>Input argument type checking ("typecheck" typemap).</li> |
| 475 | <li>Output argument handling ("argout" typemap).</li> |
| 476 | <li>Input argument value checking ("check" typemap).</li> |
| 477 | <li>Input argument initialization ("arginit" typemap).</li> |
| 478 | <li>Default arguments ("default" typemap).</li> |
| 479 | <li>Input argument resource management ("freearg" typemap).</li> |
| 480 | </ul> |
| 481 | |
| 482 | <p> |
| 483 | <b>Return value handling</b> |
| 484 | </p> |
| 485 | |
| 486 | <div class="code"> |
| 487 | <pre> |
| 488 | <b>int</b> foo(int x, double y, char *s); |
| 489 | </pre> |
| 490 | </div> |
| 491 | |
| 492 | <ul> |
| 493 | <li>Function return value conversion ("out" typemap).</li> |
| 494 | <li>Return value resource management ("ret" typemap).</li> |
| 495 | <li>Resource management for newly allocated objects ("newfree" typemap).</li> |
| 496 | </ul> |
| 497 | |
| 498 | <p> |
| 499 | <b>Exception handling</b> |
| 500 | </p> |
| 501 | |
| 502 | <div class="code"> |
| 503 | <pre> |
| 504 | <b>int</b> foo(int x, double y, char *s) throw(<b>MemoryError, IndexError</b>); |
| 505 | </pre> |
| 506 | </div> |
| 507 | |
| 508 | <ul> |
| 509 | <li>Handling of C++ exception specifications. ("throw" typemap).</li> |
| 510 | </ul> |
| 511 | |
| 512 | <p> |
| 513 | <b>Global variables</b> |
| 514 | </p> |
| 515 | |
| 516 | <div class="code"> |
| 517 | <pre> |
| 518 | <b>int foo;</b> |
| 519 | </pre> |
| 520 | </div> |
| 521 | |
| 522 | <ul> |
| 523 | <li>Assignment of a global variable. ("varin" typemap).</li> |
| 524 | <li>Reading a global variable. ("varout" typemap).</li> |
| 525 | </ul> |
| 526 | |
| 527 | <p> |
| 528 | <b>Member variables</b> |
| 529 | </p> |
| 530 | |
| 531 | <div class="code"> |
| 532 | <pre> |
| 533 | struct Foo { |
| 534 | <b>int x[20]</b>; |
| 535 | }; |
| 536 | </pre> |
| 537 | </div> |
| 538 | |
| 539 | <ul> |
| 540 | <li>Assignment of data to a class/structure member. ("memberin" typemap).</li> |
| 541 | </ul> |
| 542 | |
| 543 | <p> |
| 544 | <b>Constant creation</b> |
| 545 | </p> |
| 546 | |
| 547 | <div class="code"> |
| 548 | <pre> |
| 549 | #define FOO 3 |
| 550 | %constant int BAR = 42; |
| 551 | enum { ALE, LAGER, STOUT }; |
| 552 | </pre> |
| 553 | </div> |
| 554 | |
| 555 | <ul> |
| 556 | <li>Creation of constant values. ("consttab" or "constcode" typemap).</li> |
| 557 | </ul> |
| 558 | |
| 559 | <p> |
| 560 | Details of each of these typemaps will be covered shortly. Also, certain language modules may define additional |
| 561 | typemaps that expand upon this list. For example, the Java module defines a variety of typemaps for controlling additional |
| 562 | aspects of the Java bindings. Consult language specific documentation for further details. |
| 563 | </p> |
| 564 | |
| 565 | <H3><a name="Typemaps_nn8"></a>10.1.6 What can't be done with typemaps?</H3> |
| 566 | |
| 567 | |
| 568 | <p> |
| 569 | Typemaps can't be used to define properties that apply to C/C++ declarations as a whole. For example, |
| 570 | suppose you had a declaration like this, |
| 571 | </p> |
| 572 | |
| 573 | <div class="code"> |
| 574 | <pre> |
| 575 | Foo *make_Foo(); |
| 576 | </pre> |
| 577 | </div> |
| 578 | |
| 579 | <p> |
| 580 | and you wanted to tell SWIG that <tt>make_Foo()</tt> returned a newly |
| 581 | allocated object (for the purposes of providing better memory |
| 582 | management). Clearly, this property of <tt>make_Foo()</tt> is |
| 583 | <em>not</em> a property that would be associated with the datatype |
| 584 | <tt>Foo *</tt> by itself. Therefore, a completely different SWIG |
| 585 | customization mechanism (<tt>%feature</tt>) is used for this purpose. Consult the <a |
| 586 | href="Customization.html#Customization">Customization Features</a> chapter for more |
| 587 | information about that. |
| 588 | </p> |
| 589 | |
| 590 | <p> |
| 591 | Typemaps also can't be used to rearrange or transform the order of arguments. For example, |
| 592 | if you had a function like this: |
| 593 | </p> |
| 594 | |
| 595 | <div class="code"> |
| 596 | <pre> |
| 597 | void foo(int, char *); |
| 598 | </pre> |
| 599 | </div> |
| 600 | |
| 601 | <p> |
| 602 | you can't use typemaps to interchange the arguments, allowing you to call the |
| 603 | function like this: |
| 604 | </p> |
| 605 | |
| 606 | <div class="targetlang"> |
| 607 | <pre> |
| 608 | foo("hello",3) # Reversed arguments |
| 609 | </pre> |
| 610 | </div> |
| 611 | |
| 612 | <p> |
| 613 | If you want to change the calling conventions of a function, write a helper |
| 614 | function instead. For example: |
| 615 | </p> |
| 616 | |
| 617 | <div class="code"> |
| 618 | <pre> |
| 619 | %rename(foo) wrap_foo; |
| 620 | %inline %{ |
| 621 | void wrap_foo(char *s, int x) { |
| 622 | foo(x,s); |
| 623 | } |
| 624 | %} |
| 625 | </pre> |
| 626 | </div> |
| 627 | |
| 628 | <H3><a name="Typemaps_nn9"></a>10.1.7 The rest of this chapter</H3> |
| 629 | |
| 630 | |
| 631 | <p> |
| 632 | The rest of this chapter provides detailed information for people who |
| 633 | want to write new typemaps. This information is of particular importance to anyone |
| 634 | who intends to write a new SWIG target language module. Power users can also |
| 635 | use this information to write application specific type conversion rules. |
| 636 | </p> |
| 637 | |
| 638 | <p> |
| 639 | Since typemaps are strongly tied to the underlying C++ type system, |
| 640 | subsequent sections assume that you are reasonably familiar with the |
| 641 | basic details of values, pointers, references, arrays, type qualifiers |
| 642 | (e.g., <tt>const</tt>), structures, namespaces, templates, and memory |
| 643 | management in C/C++. If not, you would be well-advised to consult a copy |
| 644 | of "The C Programming Language" by Kernighan and Ritchie or |
| 645 | "The C++ Programming Language" by Stroustrup before going any further. |
| 646 | </p> |
| 647 | |
| 648 | <H2><a name="Typemaps_nn10"></a>10.2 Typemap specifications</H2> |
| 649 | |
| 650 | |
| 651 | <p> |
| 652 | This section describes the behavior of the <tt>%typemap</tt> directive itself. |
| 653 | </p> |
| 654 | |
| 655 | <H3><a name="Typemaps_nn11"></a>10.2.1 Defining a typemap</H3> |
| 656 | |
| 657 | |
| 658 | <p> |
| 659 | New typemaps are defined using the <tt>%typemap</tt> declaration. The general form of |
| 660 | this declaration is as follows (parts enclosed in [ ... ] are optional): |
| 661 | </p> |
| 662 | |
| 663 | <div class="code"> |
| 664 | <pre> |
| 665 | %typemap(<em>method</em> [, <em>modifiers</em>]) <em>typelist</em> <em>code</em> ; |
| 666 | </pre> |
| 667 | </div> |
| 668 | |
| 669 | <p> |
| 670 | <em>method</em> is a simply a name that specifies what kind of typemap is being defined. It |
| 671 | is usually a name like <tt>"in"</tt>, <tt>"out"</tt>, or <tt>"argout"</tt>. The purpose of |
| 672 | these methods is described later. |
| 673 | </p> |
| 674 | |
| 675 | <p> |
| 676 | <em>modifiers</em> is an optional comma separated list of <tt>name="value"</tt> values. These |
| 677 | are sometimes to attach extra information to a typemap and is often target-language dependent. |
| 678 | </p> |
| 679 | |
| 680 | <p> |
| 681 | <em>typelist</em> is a list of the C++ type patterns that the typemap will match. The general form of |
| 682 | this list is as follows: |
| 683 | </p> |
| 684 | |
| 685 | <div class="diagram"> |
| 686 | <pre> |
| 687 | typelist : typepattern [, typepattern, typepattern, ... ] ; |
| 688 | |
| 689 | typepattern : type [ (parms) ] |
| 690 | | type name [ (parms) ] |
| 691 | | ( typelist ) [ (parms) ] |
| 692 | |
| 693 | </pre> |
| 694 | </div> |
| 695 | |
| 696 | <p> |
| 697 | Each type pattern is either a simple type, a simple type and argument name, or a list of types in the |
| 698 | case of multi-argument typemaps. In addition, each type pattern can be parameterized with a list of temporary |
| 699 | variables (parms). The purpose of these variables will be explained shortly. |
| 700 | </p> |
| 701 | |
| 702 | <p><em>code</em> specifies the C code used in the typemap. It can take any one of the following |
| 703 | forms: |
| 704 | </p> |
| 705 | |
| 706 | <div class="diagram"> |
| 707 | <pre> |
| 708 | code : { ... } |
| 709 | | " ... " |
| 710 | | %{ ... %} |
| 711 | </pre> |
| 712 | </div> |
| 713 | |
| 714 | <p> |
| 715 | Here are some examples of valid typemap specifications: |
| 716 | </p> |
| 717 | |
| 718 | <div class="code"> |
| 719 | <pre> |
| 720 | /* Simple typemap declarations */ |
| 721 | %typemap(in) int { |
| 722 | $1 = PyInt_AsLong($input); |
| 723 | } |
| 724 | %typemap(in) int "$1 = PyInt_AsLong($input);"; |
| 725 | %typemap(in) int %{ |
| 726 | $1 = PyInt_AsLong($input); |
| 727 | %} |
| 728 | |
| 729 | /* Typemap with extra argument name */ |
| 730 | %typemap(in) int nonnegative { |
| 731 | ... |
| 732 | } |
| 733 | |
| 734 | /* Multiple types in one typemap */ |
| 735 | %typemap(in) int, short, long { |
| 736 | $1 = SvIV($input); |
| 737 | } |
| 738 | |
| 739 | /* Typemap with modifiers */ |
| 740 | %typemap(in,doc="integer") int "$1 = gh_scm2int($input);"; |
| 741 | |
| 742 | /* Typemap applied to patterns of multiple arguments */ |
| 743 | %typemap(in) (char *str, int len), |
| 744 | (char *buffer, int size) |
| 745 | { |
| 746 | $1 = PyString_AsString($input); |
| 747 | $2 = PyString_Size($input); |
| 748 | } |
| 749 | |
| 750 | /* Typemap with extra pattern parameters */ |
| 751 | %typemap(in, numinputs=0) int *output (int temp), |
| 752 | long *output (long temp) |
| 753 | { |
| 754 | $1 = &temp; |
| 755 | } |
| 756 | </pre> |
| 757 | </div> |
| 758 | |
| 759 | <p> |
| 760 | Admittedly, it's not the most readable syntax at first glance. However, the purpose of the |
| 761 | individual pieces will become clear. |
| 762 | </p> |
| 763 | |
| 764 | <H3><a name="Typemaps_nn12"></a>10.2.2 Typemap scope</H3> |
| 765 | |
| 766 | |
| 767 | <p> |
| 768 | Once defined, a typemap remains in effect for all of the declarations that follow. A typemap may be redefined for |
| 769 | different sections of an input file. For example: |
| 770 | </p> |
| 771 | |
| 772 | <div class="code"> |
| 773 | <pre> |
| 774 | // typemap1 |
| 775 | %typemap(in) int { |
| 776 | ... |
| 777 | } |
| 778 | |
| 779 | int fact(int); // typemap1 |
| 780 | int gcd(int x, int y); // typemap1 |
| 781 | |
| 782 | // typemap2 |
| 783 | %typemap(in) int { |
| 784 | ... |
| 785 | } |
| 786 | |
| 787 | int isprime(int); // typemap2 |
| 788 | </pre> |
| 789 | </div> |
| 790 | |
| 791 | <p> |
| 792 | One exception to the typemap scoping rules pertains to the <tt>%extend</tt> declaration. <tt>%extend</tt> is used to attach |
| 793 | new declarations to a class or structure definition. Because of this, all of the declarations in an <tt>%extend</tt> block are |
| 794 | subject to the typemap rules that are in effect at the point where the class itself is defined. For example: |
| 795 | </p> |
| 796 | |
| 797 | <div class="code"> |
| 798 | <pre> |
| 799 | class Foo { |
| 800 | ... |
| 801 | }; |
| 802 | |
| 803 | %typemap(in) int { |
| 804 | ... |
| 805 | } |
| 806 | |
| 807 | %extend Foo { |
| 808 | int blah(int x); // typemap has no effect. Declaration is attached to Foo which |
| 809 | // appears before the %typemap declaration. |
| 810 | }; |
| 811 | </pre> |
| 812 | </div> |
| 813 | |
| 814 | <H3><a name="Typemaps_nn13"></a>10.2.3 Copying a typemap</H3> |
| 815 | |
| 816 | |
| 817 | <p> |
| 818 | A typemap is copied by using assignment. For example: |
| 819 | </p> |
| 820 | |
| 821 | <div class="code"> |
| 822 | <pre> |
| 823 | %typemap(in) Integer = int; |
| 824 | </pre> |
| 825 | </div> |
| 826 | |
| 827 | <p> |
| 828 | or this: |
| 829 | </p> |
| 830 | |
| 831 | <div class="code"> |
| 832 | <pre> |
| 833 | %typemap(in) Integer, Number, int32_t = int; |
| 834 | </pre> |
| 835 | </div> |
| 836 | |
| 837 | <p> |
| 838 | Types are often managed by a collection of different typemaps. For example: |
| 839 | </p> |
| 840 | |
| 841 | <div class="code"> |
| 842 | <pre> |
| 843 | %typemap(in) int { ... } |
| 844 | %typemap(out) int { ... } |
| 845 | %typemap(varin) int { ... } |
| 846 | %typemap(varout) int { ... } |
| 847 | </pre> |
| 848 | </div> |
| 849 | |
| 850 | <p> |
| 851 | To copy all of these typemaps to a new type, use <tt>%apply</tt>. For example: |
| 852 | </p> |
| 853 | |
| 854 | <div class="code"> |
| 855 | <pre> |
| 856 | %apply int { Integer }; // Copy all int typemaps to Integer |
| 857 | %apply int { Integer, Number }; // Copy all int typemaps to both Integer and Number |
| 858 | </pre> |
| 859 | </div> |
| 860 | |
| 861 | <p> |
| 862 | The patterns for <tt>%apply</tt> follow the same rules as for <tt>%typemap</tt>. For example: |
| 863 | </p> |
| 864 | |
| 865 | <div class="code"> |
| 866 | <pre> |
| 867 | %apply int *output { Integer *output }; // Typemap with name |
| 868 | %apply (char *buf, int len) { (char *buffer, int size) }; // Multiple arguments |
| 869 | </pre> |
| 870 | </div> |
| 871 | |
| 872 | <H3><a name="Typemaps_nn14"></a>10.2.4 Deleting a typemap</H3> |
| 873 | |
| 874 | |
| 875 | <p> |
| 876 | A typemap can be deleted by simply defining no code. For example: |
| 877 | </p> |
| 878 | |
| 879 | <div class="code"> |
| 880 | <pre> |
| 881 | %typemap(in) int; // Clears typemap for int |
| 882 | %typemap(in) int, long, short; // Clears typemap for int, long, short |
| 883 | %typemap(in) int *output; |
| 884 | </pre> |
| 885 | </div> |
| 886 | |
| 887 | <p> |
| 888 | The <tt>%clear</tt> directive clears all typemaps for a given type. |
| 889 | For example: |
| 890 | </p> |
| 891 | |
| 892 | <div class="code"> |
| 893 | <pre> |
| 894 | %clear int; // Removes all types for int |
| 895 | %clear int *output, long *output; |
| 896 | </pre> |
| 897 | </div> |
| 898 | |
| 899 | <p> |
| 900 | <b>Note:</b> Since SWIG's default behavior is defined by typemaps, clearing a fundamental type like |
| 901 | <tt>int</tt> will make that type unusable unless you also define a new set of typemaps immediately |
| 902 | after the clear operation. |
| 903 | </p> |
| 904 | |
| 905 | <H3><a name="Typemaps_nn15"></a>10.2.5 Placement of typemaps</H3> |
| 906 | |
| 907 | |
| 908 | <p> |
| 909 | Typemap declarations can be declared in the global scope, within a C++ namespace, and within a C++ class. For |
| 910 | example: |
| 911 | </p> |
| 912 | |
| 913 | <div class="code"> |
| 914 | <pre> |
| 915 | %typemap(in) int { |
| 916 | ... |
| 917 | } |
| 918 | |
| 919 | namespace std { |
| 920 | class string; |
| 921 | %typemap(in) string { |
| 922 | ... |
| 923 | } |
| 924 | } |
| 925 | |
| 926 | class Bar { |
| 927 | public: |
| 928 | typedef const int & const_reference; |
| 929 | %typemap(out) const_reference { |
| 930 | ... |
| 931 | } |
| 932 | }; |
| 933 | </pre> |
| 934 | </div> |
| 935 | |
| 936 | <p> |
| 937 | When a typemap appears inside a namespace or class, it stays in effect until the end of the SWIG input |
| 938 | (just like before). However, the typemap takes the local scope into account. Therefore, this |
| 939 | code |
| 940 | </p> |
| 941 | |
| 942 | <div class="code"> |
| 943 | <pre> |
| 944 | namespace std { |
| 945 | class string; |
| 946 | %typemap(in) string { |
| 947 | ... |
| 948 | } |
| 949 | } |
| 950 | </pre> |
| 951 | </div> |
| 952 | |
| 953 | <p> |
| 954 | is really defining a typemap for the type <tt>std::string</tt>. You could have code like this: |
| 955 | </p> |
| 956 | |
| 957 | <div class="code"> |
| 958 | <pre> |
| 959 | namespace std { |
| 960 | class string; |
| 961 | %typemap(in) string { /* std::string */ |
| 962 | ... |
| 963 | } |
| 964 | } |
| 965 | |
| 966 | namespace Foo { |
| 967 | class string; |
| 968 | %typemap(in) string { /* Foo::string */ |
| 969 | ... |
| 970 | } |
| 971 | } |
| 972 | </pre> |
| 973 | </div> |
| 974 | |
| 975 | <p> |
| 976 | In this case, there are two completely distinct typemaps that apply to two completely different |
| 977 | types (<tt>std::string</tt> and <tt>Foo::string</tt>). |
| 978 | </p> |
| 979 | |
| 980 | <p> |
| 981 | It should be noted that for scoping to work, SWIG has to know that <tt>string</tt> is a typename defined |
| 982 | within a particular namespace. In this example, this is done using the class declaration <tt>class string</tt>. |
| 983 | </p> |
| 984 | |
| 985 | <H2><a name="Typemaps_nn16"></a>10.3 Pattern matching rules</H2> |
| 986 | |
| 987 | |
| 988 | <p> |
| 989 | The section describes the pattern matching rules by which C datatypes are associated with typemaps. |
| 990 | </p> |
| 991 | |
| 992 | <H3><a name="Typemaps_nn17"></a>10.3.1 Basic matching rules</H3> |
| 993 | |
| 994 | |
| 995 | <p> |
| 996 | Typemaps are matched using both a type and a name (typically the name of a argument). For a given |
| 997 | <tt>TYPE NAME</tt> pair, the following rules are applied, in order, to find a match. The first typemap found |
| 998 | is used. |
| 999 | </p> |
| 1000 | |
| 1001 | <ul> |
| 1002 | <li>Typemaps that exactly match <tt>TYPE</tt> and <tt>NAME</tt>. |
| 1003 | <li>Typemaps that exactly match <tt>TYPE</tt> only. |
| 1004 | </ul> |
| 1005 | |
| 1006 | <p> |
| 1007 | If <tt>TYPE</tt> includes qualifiers (const, volatile, etc.), they are stripped and the following |
| 1008 | checks are made: |
| 1009 | </p> |
| 1010 | |
| 1011 | <ul> |
| 1012 | <li>Typemaps that match the stripped <tt>TYPE</tt> and <tt>NAME</tt>. |
| 1013 | <Li>Typemaps that match the stripped <tt>TYPE</tt> only. |
| 1014 | </ul> |
| 1015 | |
| 1016 | <p> |
| 1017 | If <tt>TYPE</tt> is an array. The following transformation is made: |
| 1018 | </p> |
| 1019 | |
| 1020 | <ul> |
| 1021 | <li>Replace all dimensions to <tt>[ANY]</tt> and look for a generic array typemap. |
| 1022 | </ul> |
| 1023 | |
| 1024 | <p> |
| 1025 | To illustrate, suppose that you had a function like this: |
| 1026 | </p> |
| 1027 | |
| 1028 | <div class="code"> |
| 1029 | <pre> |
| 1030 | int foo(const char *s); |
| 1031 | </pre> |
| 1032 | </div> |
| 1033 | |
| 1034 | <p> |
| 1035 | To find a typemap for the argument <tt>const char *s</tt>, SWIG will search for the following typemaps: |
| 1036 | </p> |
| 1037 | |
| 1038 | <div class="diagram"> |
| 1039 | <pre> |
| 1040 | const char *s Exact type and name match |
| 1041 | const char * Exact type match |
| 1042 | char *s Type and name match (stripped qualifiers) |
| 1043 | char * Type match (stripped qualifiers) |
| 1044 | </pre> |
| 1045 | </div> |
| 1046 | |
| 1047 | <p> |
| 1048 | When more than one typemap rule might be defined, only the first match |
| 1049 | found is actually used. Here is an example that |
| 1050 | shows how some of the basic rules are applied: |
| 1051 | </p> |
| 1052 | |
| 1053 | <div class="code"><pre> |
| 1054 | %typemap(in) int *x { |
| 1055 | ... typemap 1 |
| 1056 | } |
| 1057 | |
| 1058 | %typemap(in) int * { |
| 1059 | ... typemap 2 |
| 1060 | } |
| 1061 | |
| 1062 | %typemap(in) const int *z { |
| 1063 | ... typemap 3 |
| 1064 | } |
| 1065 | |
| 1066 | %typemap(in) int [4] { |
| 1067 | ... typemap 4 |
| 1068 | } |
| 1069 | |
| 1070 | %typemap(in) int [ANY] { |
| 1071 | ... typemap 5 |
| 1072 | } |
| 1073 | |
| 1074 | void A(int *x); // int *x rule (typemap 1) |
| 1075 | void B(int *y); // int * rule (typemap 2) |
| 1076 | void C(const int *x); // int *x rule (typemap 1) |
| 1077 | void D(const int *z); // int * rule (typemap 3) |
| 1078 | void E(int x[4]); // int [4] rule (typemap 4) |
| 1079 | void F(int x[1000]); // int [ANY] rule (typemap 5) |
| 1080 | </pre> |
| 1081 | </div> |
| 1082 | |
| 1083 | <H3><a name="Typemaps_nn18"></a>10.3.2 Typedef reductions</H3> |
| 1084 | |
| 1085 | |
| 1086 | <p> |
| 1087 | If no match is found using the rules in the previous section, SWIG |
| 1088 | applies a typedef reduction to the type and repeats the typemap search |
| 1089 | for the reduced type. To illustrate, suppose you had code like this: |
| 1090 | </p> |
| 1091 | |
| 1092 | <div class="code"> |
| 1093 | <pre> |
| 1094 | %typemap(in) int { |
| 1095 | ... typemap 1 |
| 1096 | } |
| 1097 | |
| 1098 | typedef int Integer; |
| 1099 | void blah(Integer x); |
| 1100 | </pre> |
| 1101 | </div> |
| 1102 | |
| 1103 | <p> |
| 1104 | To find the typemap for <tt>Integer x</tt>, SWIG will first search for the following |
| 1105 | typemaps: |
| 1106 | </p> |
| 1107 | |
| 1108 | <div class="diagram"> |
| 1109 | <pre> |
| 1110 | Integer x |
| 1111 | Integer |
| 1112 | </pre> |
| 1113 | </div> |
| 1114 | |
| 1115 | <p> |
| 1116 | Finding no match, it then applies a reduction <tt>Integer -> int</tt> to the type and |
| 1117 | repeats the search. |
| 1118 | </p> |
| 1119 | |
| 1120 | <div class="diagram"> |
| 1121 | <pre> |
| 1122 | int x |
| 1123 | int --> match: typemap 1 |
| 1124 | </pre> |
| 1125 | </div> |
| 1126 | |
| 1127 | <p> |
| 1128 | Even though two types might be the same via typedef, SWIG allows typemaps to be defined |
| 1129 | for each typename independently. This allows for interesting customization possibilities based |
| 1130 | solely on the typename itself. For example, you could write code like this: |
| 1131 | </p> |
| 1132 | |
| 1133 | <div class="code"> |
| 1134 | <pre> |
| 1135 | typedef double pdouble; // Positive double |
| 1136 | |
| 1137 | // typemap 1 |
| 1138 | %typemap(in) double { |
| 1139 | ... get a double ... |
| 1140 | } |
| 1141 | // typemap 2 |
| 1142 | %typemap(in) pdouble { |
| 1143 | ... get a positive double ... |
| 1144 | } |
| 1145 | double sin(double x); // typemap 1 |
| 1146 | pdouble sqrt(pdouble x); // typemap 2 |
| 1147 | </pre> |
| 1148 | </div> |
| 1149 | |
| 1150 | <p> |
| 1151 | When reducing the type, only one typedef reduction is applied at a |
| 1152 | time. The search process continues to apply reductions until a |
| 1153 | match is found or until no more reductions can be made. |
| 1154 | </p> |
| 1155 | |
| 1156 | <p> |
| 1157 | For complicated types, the reduction process can generate a long list of patterns. Consider the following: |
| 1158 | </p> |
| 1159 | |
| 1160 | <div class="code"> |
| 1161 | <pre> |
| 1162 | typedef int Integer; |
| 1163 | typedef Integer Row4[4]; |
| 1164 | void foo(Row4 rows[10]); |
| 1165 | </pre> |
| 1166 | </div> |
| 1167 | |
| 1168 | <p> |
| 1169 | To find a match for the <tt>Row4 rows[10]</tt> argument, SWIG would |
| 1170 | check the following patterns, stopping only when it found a match: |
| 1171 | </p> |
| 1172 | |
| 1173 | <div class="code"> |
| 1174 | <pre> |
| 1175 | Row4 rows[10] |
| 1176 | Row4 [10] |
| 1177 | Row4 rows[ANY] |
| 1178 | Row4 [ANY] |
| 1179 | |
| 1180 | # Reduce Row4 --> Integer[4] |
| 1181 | Integer rows[10][4] |
| 1182 | Integer [10][4] |
| 1183 | Integer rows[ANY][ANY] |
| 1184 | Integer [ANY][ANY] |
| 1185 | |
| 1186 | # Reduce Integer --> int |
| 1187 | int rows[10][4] |
| 1188 | int [10][4] |
| 1189 | int rows[ANY][ANY] |
| 1190 | int [ANY][ANY] |
| 1191 | </pre> |
| 1192 | </div> |
| 1193 | |
| 1194 | <p> |
| 1195 | For parametized types like templates, the situation is even more complicated. Suppose you had some declarations |
| 1196 | like this: |
| 1197 | </p> |
| 1198 | |
| 1199 | <div class="code"> |
| 1200 | <pre> |
| 1201 | typedef int Integer; |
| 1202 | typedef foo<Integer,Integer> fooii; |
| 1203 | void blah(fooii *x); |
| 1204 | </pre> |
| 1205 | </div> |
| 1206 | |
| 1207 | <p> |
| 1208 | In this case, the following typemap patterns are searched for the argument <tt>fooii *x</tt>: |
| 1209 | </p> |
| 1210 | |
| 1211 | <div class="code"> |
| 1212 | <pre> |
| 1213 | fooii *x |
| 1214 | fooii * |
| 1215 | |
| 1216 | # Reduce fooii --> foo<Integer,Integer> |
| 1217 | foo<Integer,Integer> *x |
| 1218 | foo<Integer,Integer> * |
| 1219 | |
| 1220 | # Reduce Integer -> int |
| 1221 | foo<int, Integer> *x |
| 1222 | foo<int, Integer> * |
| 1223 | |
| 1224 | # Reduce Integer -> int |
| 1225 | foo<int, int> *x |
| 1226 | foo<int, int> * |
| 1227 | </pre> |
| 1228 | </div> |
| 1229 | |
| 1230 | <p> |
| 1231 | Typemap reductions are always applied to the left-most type that appears. Only when no reductions can be made to the left-most |
| 1232 | type are reductions made to other parts of the type. This behavior means that you could define a typemap for |
| 1233 | <tt>foo<int,Integer></tt>, but a typemap for <tt>foo<Integer,int></tt> would never be matched. Admittedly, this |
| 1234 | is rather esoteric--there's little practical reason to write a typemap quite like that. Of course, you could rely on this |
| 1235 | to confuse your coworkers even more. |
| 1236 | </p> |
| 1237 | |
| 1238 | <H3><a name="Typemaps_nn19"></a>10.3.3 Default typemaps</H3> |
| 1239 | |
| 1240 | |
| 1241 | <p> |
| 1242 | Most SWIG language modules use typemaps to define the default behavior of the C primitive types. This |
| 1243 | is entirely straightforward. For example, a set of typemaps are written like this: |
| 1244 | </p> |
| 1245 | |
| 1246 | <div class="code"> |
| 1247 | <pre> |
| 1248 | %typemap(in) int "convert an int"; |
| 1249 | %typemap(in) short "convert a short"; |
| 1250 | %typemap(in) float "convert a float"; |
| 1251 | ... |
| 1252 | </pre> |
| 1253 | </div> |
| 1254 | |
| 1255 | <p> |
| 1256 | Since typemap matching follows all <tt>typedef</tt> declarations, any sort of type that is |
| 1257 | mapped to a primitive type through <tt>typedef</tt> will be picked up by one of these primitive typemaps. |
| 1258 | </p> |
| 1259 | |
| 1260 | <p> |
| 1261 | The default behavior for pointers, arrays, references, and other kinds of types are handled by |
| 1262 | specifying rules for variations of the reserved <tt>SWIGTYPE</tt> type. For example: |
| 1263 | </p> |
| 1264 | |
| 1265 | <div class="code"> |
| 1266 | <pre> |
| 1267 | %typemap(in) SWIGTYPE * { ... default pointer handling ... } |
| 1268 | %typemap(in) SWIGTYPE & { ... default reference handling ... } |
| 1269 | %typemap(in) SWIGTYPE [] { ... default array handling ... } |
| 1270 | %typemap(in) enum SWIGTYPE { ... default handling for enum values ... } |
| 1271 | %typemap(in) SWIGTYPE (CLASS::*) { ... default pointer member handling ... } |
| 1272 | </pre> |
| 1273 | </div> |
| 1274 | |
| 1275 | <p> |
| 1276 | These rules match any kind of pointer, reference, or array--even when |
| 1277 | multiple levels of indirection or multiple array dimensions are used. |
| 1278 | Therefore, if you wanted to change SWIG's default handling for all |
| 1279 | types of pointers, you would simply redefine the rule for <tt>SWIGTYPE |
| 1280 | *</tt>. |
| 1281 | </p> |
| 1282 | |
| 1283 | <p> |
| 1284 | Finally, the following typemap rule is used to match against simple types that don't match any other rules: |
| 1285 | </p> |
| 1286 | |
| 1287 | <div class="code"> |
| 1288 | <pre> |
| 1289 | %typemap(in) SWIGTYPE { ... handle an unknown type ... } |
| 1290 | </pre> |
| 1291 | </div> |
| 1292 | |
| 1293 | <p> |
| 1294 | This typemap is important because it is the rule that gets triggered |
| 1295 | when call or return by value is used. For instance, if you have a |
| 1296 | declaration like this: |
| 1297 | </p> |
| 1298 | |
| 1299 | <div class="code"> |
| 1300 | <pre> |
| 1301 | double dot_product(Vector a, Vector b); |
| 1302 | </pre> |
| 1303 | </div> |
| 1304 | |
| 1305 | <p> |
| 1306 | The <tt>Vector</tt> type will usually just get matched against |
| 1307 | <tt>SWIGTYPE</tt>. The default implementation of <tt>SWIGTYPE</tt> is |
| 1308 | to convert the value into pointers (as described in chapter 3). |
| 1309 | </p> |
| 1310 | |
| 1311 | <p> |
| 1312 | By redefining <tt>SWIGTYPE</tt> it may be possible to implement other |
| 1313 | behavior. For example, if you cleared all typemaps for |
| 1314 | <tt>SWIGTYPE</tt>, SWIG simply won't wrap any unknown datatype (which might |
| 1315 | be useful for debugging). Alternatively, you might modify SWIGTYPE to marshal |
| 1316 | objects into strings instead of converting them to pointers. |
| 1317 | </p> |
| 1318 | |
| 1319 | <p> |
| 1320 | The best way to explore the default typemaps is to look at the ones |
| 1321 | already defined for a particular language module. Typemaps |
| 1322 | definitions are usually found in the SWIG library in a file such as |
| 1323 | <tt>python.swg</tt>, <tt>tcl8.swg</tt>, etc. |
| 1324 | </p> |
| 1325 | |
| 1326 | <H3><a name="Typemaps_mixed_default"></a>10.3.4 Mixed default typemaps</H3> |
| 1327 | |
| 1328 | |
| 1329 | <p> |
| 1330 | The default typemaps described above can be mixed with <tt>const</tt> and with each other. |
| 1331 | For example the <tt>SWIGTYPE *</tt> typemap is for default pointer handling, but if a <tt>const SWIGTYPE *</tt> typemap |
| 1332 | is defined it will be used instead for constant pointers. Some further examples follow: |
| 1333 | </p> |
| 1334 | |
| 1335 | <div class="code"> |
| 1336 | <pre> |
| 1337 | %typemap(in) enum SWIGTYPE & { ... enum references ... } |
| 1338 | %typemap(in) const enum SWIGTYPE & { ... const enum references ... } |
| 1339 | %typemap(in) SWIGTYPE *& { ... pointers passed by reference ... } |
| 1340 | %typemap(in) SWIGTYPE * const & { ... constant pointers passed by reference ... } |
| 1341 | %typemap(in) SWIGTYPE[ANY][ANY] { ... 2D arrays ... } |
| 1342 | </pre> |
| 1343 | </div> |
| 1344 | |
| 1345 | <p> |
| 1346 | Note that the the typedef reduction described earlier is also used with these mixed default typemaps. |
| 1347 | For example, say the following typemaps are defined and SWIG is looking for the best match for the enum shown below: |
| 1348 | </p> |
| 1349 | |
| 1350 | <div class="code"> |
| 1351 | <pre> |
| 1352 | %typemap(in) const Hello & { ... } |
| 1353 | %typemap(in) const enum SWIGTYPE & { ... } |
| 1354 | %typemap(in) enum SWIGTYPE & { ... } |
| 1355 | %typemap(in) SWIGTYPE & { ... } |
| 1356 | %typemap(in) SWIGTYPE { ... } |
| 1357 | |
| 1358 | enum Hello {}; |
| 1359 | const Hello &hi; |
| 1360 | </pre> |
| 1361 | </div> |
| 1362 | |
| 1363 | <p> |
| 1364 | The typemap at the top of the list will be chosen, not because it is defined first, but because it is the closest match for the type being wrapped. |
| 1365 | If any of the typemaps in the above list were not defined, then the next one on the list would have precedence. |
| 1366 | In other words the typemap chosen is the closest explicit match. |
| 1367 | </p> |
| 1368 | |
| 1369 | <p> |
| 1370 | <b>Compatibility note: </b> The mixed default typemaps were introduced in SWIG-1.3.23, but were not used much in this version. |
| 1371 | Expect to see them being used more and more within the various libraries in later versions of SWIG. |
| 1372 | </p> |
| 1373 | |
| 1374 | |
| 1375 | <H3><a name="Typemaps_nn20"></a>10.3.5 Multi-arguments typemaps</H3> |
| 1376 | |
| 1377 | |
| 1378 | <p> |
| 1379 | When multi-argument typemaps are specified, they take precedence over |
| 1380 | any typemaps specified for a single type. For example: |
| 1381 | </p> |
| 1382 | |
| 1383 | <div class="code"> |
| 1384 | <pre> |
| 1385 | %typemap(in) (char *buffer, int len) { |
| 1386 | // typemap 1 |
| 1387 | } |
| 1388 | |
| 1389 | %typemap(in) char *buffer { |
| 1390 | // typemap 2 |
| 1391 | } |
| 1392 | |
| 1393 | void foo(char *buffer, int len, int count); // (char *buffer, int len) |
| 1394 | void bar(char *buffer, int blah); // char *buffer |
| 1395 | </pre> |
| 1396 | </div> |
| 1397 | |
| 1398 | <p> |
| 1399 | Multi-argument typemaps are also more restrictive in the way that they are matched. |
| 1400 | Currently, the first argument follows the matching rules described in the previous section, |
| 1401 | but all subsequent arguments must match exactly. |
| 1402 | </p> |
| 1403 | |
| 1404 | |
| 1405 | <H2><a name="Typemaps_nn21"></a>10.4 Code generation rules</H2> |
| 1406 | |
| 1407 | |
| 1408 | <p> |
| 1409 | This section describes rules by which typemap code is inserted into |
| 1410 | the generated wrapper code. |
| 1411 | </p> |
| 1412 | |
| 1413 | <H3><a name="Typemaps_nn22"></a>10.4.1 Scope</H3> |
| 1414 | |
| 1415 | |
| 1416 | <p> |
| 1417 | When a typemap is defined like this: |
| 1418 | </p> |
| 1419 | |
| 1420 | <div class="code"> |
| 1421 | <pre> |
| 1422 | %typemap(in) int { |
| 1423 | $1 = PyInt_AsLong($input); |
| 1424 | } |
| 1425 | </pre> |
| 1426 | </div> |
| 1427 | |
| 1428 | <p> |
| 1429 | the typemap code is inserted into the wrapper function using a new block scope. In other words, the |
| 1430 | wrapper code will look like this: |
| 1431 | </p> |
| 1432 | |
| 1433 | <div class="code"> |
| 1434 | <pre> |
| 1435 | wrap_whatever() { |
| 1436 | ... |
| 1437 | // Typemap code |
| 1438 | { |
| 1439 | arg1 = PyInt_AsLong(obj1); |
| 1440 | } |
| 1441 | ... |
| 1442 | } |
| 1443 | </pre> |
| 1444 | </div> |
| 1445 | |
| 1446 | <p> |
| 1447 | Because the typemap code is enclosed in its own block, it is legal to declare temporary variables |
| 1448 | for use during typemap execution. For example: |
| 1449 | </p> |
| 1450 | |
| 1451 | <div class="code"> |
| 1452 | <pre> |
| 1453 | %typemap(in) short { |
| 1454 | long temp; /* Temporary value */ |
| 1455 | if (Tcl_GetLongFromObj(interp, $input, &temp) != TCL_OK) { |
| 1456 | return TCL_ERROR; |
| 1457 | } |
| 1458 | $1 = (short) temp; |
| 1459 | } |
| 1460 | </pre> |
| 1461 | </div> |
| 1462 | |
| 1463 | <p> |
| 1464 | Of course, any variables that you declare inside a typemap are destroyed as soon as the typemap |
| 1465 | code has executed (they are not visible to other parts of the wrapper function or other typemaps |
| 1466 | that might use the same variable names). |
| 1467 | </p> |
| 1468 | |
| 1469 | <p> |
| 1470 | Occasionally, typemap code will be specified using a few alternative forms. For example: |
| 1471 | </p> |
| 1472 | |
| 1473 | <div class="code"> |
| 1474 | <pre> |
| 1475 | %typemap(in) int "$1 = PyInt_AsLong($input);"; |
| 1476 | %typemap(in) int %{ |
| 1477 | $1 = PyInt_AsLong($input); |
| 1478 | %} |
| 1479 | </pre> |
| 1480 | </div> |
| 1481 | |
| 1482 | <p> |
| 1483 | These two forms are mainly used for cosmetics--the specified code is not enclosed inside |
| 1484 | a block scope when it is emitted. This sometimes results in a less complicated looking wrapper function. |
| 1485 | </p> |
| 1486 | |
| 1487 | <H3><a name="Typemaps_nn23"></a>10.4.2 Declaring new local variables</H3> |
| 1488 | |
| 1489 | |
| 1490 | <p> |
| 1491 | Sometimes it is useful to declare a new local variable that exists |
| 1492 | within the scope of the entire wrapper function. A good example of this |
| 1493 | might be an application in which you wanted to marshal strings. Suppose |
| 1494 | you had a C++ function like this |
| 1495 | </p> |
| 1496 | |
| 1497 | <div class="code"> |
| 1498 | <pre> |
| 1499 | int foo(std::string *s); |
| 1500 | </pre> |
| 1501 | </div> |
| 1502 | |
| 1503 | <p> |
| 1504 | and you wanted to pass a native string in the target language as an argument. For instance, |
| 1505 | in Perl, you wanted the function to work like this: |
| 1506 | </p> |
| 1507 | |
| 1508 | <div class="targetlang"> |
| 1509 | <pre> |
| 1510 | $x = foo("Hello World"); |
| 1511 | </pre> |
| 1512 | </div> |
| 1513 | |
| 1514 | <p> |
| 1515 | To do this, you can't just pass a raw Perl string as the <tt>std::string *</tt> argument. |
| 1516 | Instead, you have to create a temporary <tt>std::string</tt> object, copy the Perl string data into it, and |
| 1517 | then pass a pointer to the object. To do this, simply specify the typemap with an extra parameter like this: |
| 1518 | </p> |
| 1519 | |
| 1520 | <div class="code"> |
| 1521 | <pre> |
| 1522 | %typemap(in) std::string * <b>(std::string temp)</b> { |
| 1523 | unsigned int len; |
| 1524 | char *s; |
| 1525 | s = SvPV($input,len); /* Extract string data */ |
| 1526 | temp.assign(s,len); /* Assign to temp */ |
| 1527 | $1 = &temp; /* Set argument to point to temp */ |
| 1528 | } |
| 1529 | </pre> |
| 1530 | </div> |
| 1531 | |
| 1532 | <p> |
| 1533 | In this case, <tt>temp</tt> becomes a local variable in |
| 1534 | the scope of the entire wrapper function. For example: |
| 1535 | </p> |
| 1536 | |
| 1537 | <div class="code"> |
| 1538 | <pre> |
| 1539 | wrap_foo() { |
| 1540 | std::string temp; <--- Declaration of temp goes here |
| 1541 | ... |
| 1542 | |
| 1543 | /* Typemap code */ |
| 1544 | { |
| 1545 | ... |
| 1546 | temp.assign(s,len); |
| 1547 | ... |
| 1548 | } |
| 1549 | ... |
| 1550 | } |
| 1551 | </pre> |
| 1552 | </div> |
| 1553 | |
| 1554 | <p> |
| 1555 | When you set <tt>temp</tt> to a value, it |
| 1556 | persists for the duration of the wrapper function and gets |
| 1557 | cleaned up automatically on exit. |
| 1558 | </p> |
| 1559 | |
| 1560 | <p> |
| 1561 | It is perfectly safe to use more than one typemap involving local |
| 1562 | variables in the same declaration. For example, you could declare a |
| 1563 | function as :</p> |
| 1564 | |
| 1565 | <div class="code"><pre> |
| 1566 | void foo(std::string *x, std::string *y, std::string *z); |
| 1567 | </pre></div> |
| 1568 | |
| 1569 | <p> |
| 1570 | This is safely handled because SWIG actually renames all local |
| 1571 | variable references by appending an argument number suffix. Therefore, the |
| 1572 | generated code would actually look like this: |
| 1573 | </p> |
| 1574 | |
| 1575 | <div class="code"> |
| 1576 | <pre> |
| 1577 | wrap_foo() { |
| 1578 | int *arg1; /* Actual arguments */ |
| 1579 | int *arg2; |
| 1580 | int *arg3; |
| 1581 | std::string temp1; /* Locals declared in the typemap */ |
| 1582 | std::string temp2; |
| 1583 | std::string temp3; |
| 1584 | ... |
| 1585 | { |
| 1586 | char *s; |
| 1587 | unsigned int len; |
| 1588 | ... |
| 1589 | temp1.assign(s,len); |
| 1590 | arg1 = *temp1; |
| 1591 | } |
| 1592 | { |
| 1593 | char *s; |
| 1594 | unsigned int len; |
| 1595 | ... |
| 1596 | temp2.assign(s,len); |
| 1597 | arg2 = &temp2; |
| 1598 | } |
| 1599 | { |
| 1600 | char *s; |
| 1601 | unsigned int len; |
| 1602 | ... |
| 1603 | temp3.assign(s,len); |
| 1604 | arg3 = &temp3; |
| 1605 | } |
| 1606 | ... |
| 1607 | } |
| 1608 | </pre> |
| 1609 | </div> |
| 1610 | |
| 1611 | <p> |
| 1612 | Some typemaps do not recognize local variables (or they may simply not |
| 1613 | apply). At this time, only typemaps that apply to argument conversion support this. |
| 1614 | </p> |
| 1615 | |
| 1616 | |
| 1617 | <H3><a name="Typemaps_nn24"></a>10.4.3 Special variables</H3> |
| 1618 | |
| 1619 | |
| 1620 | <p> |
| 1621 | Within all typemaps, the following special variables are expanded. |
| 1622 | </p> |
| 1623 | |
| 1624 | <center> |
| 1625 | <table border=1 summary="Typemap special variables"> |
| 1626 | <tr><th>Variable</th><th>Meaning</th></tr> |
| 1627 | |
| 1628 | <tr> |
| 1629 | <td>$<em>n</em></td> |
| 1630 | <td> |
| 1631 | A C local variable corresponding to type <em>n</em> in the typemap |
| 1632 | pattern. |
| 1633 | </td> |
| 1634 | </tr> |
| 1635 | |
| 1636 | <tr> |
| 1637 | <td>$argnum</td> |
| 1638 | <td>Argument number. Only available in typemaps related to argument conversion</td> |
| 1639 | </tr> |
| 1640 | |
| 1641 | <tr> |
| 1642 | <td>$<em>n</em>_name</td> |
| 1643 | <td>Argument name</td> |
| 1644 | </tr> |
| 1645 | |
| 1646 | <tr> |
| 1647 | <td>$<em>n</em>_type</td> |
| 1648 | <td>Real C datatype of type <em>n</em>.</td> |
| 1649 | </tr> |
| 1650 | |
| 1651 | <tr> |
| 1652 | <td>$<em>n</em>_ltype</td> |
| 1653 | <td>ltype of type <em>n</em></td> |
| 1654 | </tr> |
| 1655 | |
| 1656 | <tr> |
| 1657 | <td>$<em>n</em>_mangle</td> |
| 1658 | <td>Mangled form of type <em>n</em>. For example <tt>_p_Foo</tt></td> |
| 1659 | </tr> |
| 1660 | |
| 1661 | <tr> |
| 1662 | <td>$<em>n</em>_descriptor</td> |
| 1663 | <td>Type descriptor structure for type <em>n</em>. For example |
| 1664 | <tt>SWIGTYPE_p_Foo</tt>. This is primarily used when interacting with the |
| 1665 | run-time type checker (described later).</td> |
| 1666 | </tr> |
| 1667 | |
| 1668 | |
| 1669 | <tr> |
| 1670 | <td>$*<em>n</em>_type</td> |
| 1671 | <td>Real C datatype of type <em>n</em> with one pointer removed.</td> |
| 1672 | </tr> |
| 1673 | |
| 1674 | <tr> |
| 1675 | <td>$*<em>n</em>_ltype</td> |
| 1676 | <td>ltype of type <em>n</em> with one pointer removed.</td> |
| 1677 | </tr> |
| 1678 | |
| 1679 | <tr> |
| 1680 | <td>$*<em>n</em>_mangle</td> |
| 1681 | <td>Mangled form of type <em>n</em> with one pointer removed. </td> |
| 1682 | </tr> |
| 1683 | |
| 1684 | <tr> |
| 1685 | <td>$*<em>n</em>_descriptor</td> |
| 1686 | <td>Type descriptor structure for type <em>n</em> with one pointer removed. |
| 1687 | </tr> |
| 1688 | |
| 1689 | |
| 1690 | <tr> |
| 1691 | <td>$&<em>n</em>_type</td> |
| 1692 | <td>Real C datatype of type <em>n</em> with one pointer added.</td> |
| 1693 | </tr> |
| 1694 | |
| 1695 | <tr> |
| 1696 | <td>$&<em>n</em>_ltype</td> |
| 1697 | <td>ltype of type <em>n</em> with one pointer added.</td> |
| 1698 | </tr> |
| 1699 | |
| 1700 | <tr> |
| 1701 | <td>$&<em>n</em>_mangle</td> |
| 1702 | <td>Mangled form of type <em>n</em> with one pointer added.</td> |
| 1703 | </tr> |
| 1704 | |
| 1705 | <tr> |
| 1706 | <td>$&<em>n</em>_descriptor</td> |
| 1707 | <td>Type descriptor structure for type <em>n</em> with one pointer added. |
| 1708 | </tr> |
| 1709 | |
| 1710 | <tr> |
| 1711 | <td>$<em>n</em>_basetype</td> |
| 1712 | <td>Base typename with all pointers and qualifiers stripped. |
| 1713 | </td> |
| 1714 | </tr> |
| 1715 | |
| 1716 | </table> |
| 1717 | </center> |
| 1718 | |
| 1719 | <p> |
| 1720 | Within the table, $<em>n</em> refers to a specific type within the typemap specification. For example, |
| 1721 | if you write this |
| 1722 | </p> |
| 1723 | |
| 1724 | <div class="code"> |
| 1725 | <pre> |
| 1726 | %typemap(in) int *INPUT { |
| 1727 | |
| 1728 | } |
| 1729 | </pre> |
| 1730 | </div> |
| 1731 | |
| 1732 | <p> |
| 1733 | then $1 refers to <tt>int *INPUT</tt>. If you have a typemap like this, |
| 1734 | </p> |
| 1735 | |
| 1736 | <div class="code"> |
| 1737 | <pre> |
| 1738 | %typemap(in) (int argc, char *argv[]) { |
| 1739 | ... |
| 1740 | } |
| 1741 | </pre> |
| 1742 | </div> |
| 1743 | |
| 1744 | <p> |
| 1745 | then $1 refers to <tt>int argc</tt> and $2 refers to <tt>char *argv[]</tt>. |
| 1746 | </p> |
| 1747 | |
| 1748 | <p> |
| 1749 | Substitutions related to types and names always fill in values from the actual code that was matched. |
| 1750 | This is useful when a typemap might match multiple C datatype. For example: |
| 1751 | </p> |
| 1752 | |
| 1753 | <div class="code"> |
| 1754 | <pre> |
| 1755 | %typemap(in) int, short, long { |
| 1756 | $1 = ($1_ltype) PyInt_AsLong($input); |
| 1757 | } |
| 1758 | </pre> |
| 1759 | </div> |
| 1760 | |
| 1761 | <p> |
| 1762 | In this case, <tt>$1_ltype</tt> is replaced with the datatype that is actually matched. |
| 1763 | </p> |
| 1764 | |
| 1765 | |
| 1766 | <p> |
| 1767 | When typemap code is emitted, the C/C++ datatype of the special variables <tt>$1</tt> and |
| 1768 | <tt>$2</tt> is always an "ltype." An "ltype" is simply a type that can legally appear |
| 1769 | on the left-hand side of a C assignment operation. Here are a few examples of types |
| 1770 | and ltypes: |
| 1771 | </p> |
| 1772 | |
| 1773 | <div class="diagram"> |
| 1774 | <pre> |
| 1775 | type ltype |
| 1776 | ------ ---------------- |
| 1777 | int int |
| 1778 | const int int |
| 1779 | conts int * int * |
| 1780 | int [4] int * |
| 1781 | int [4][5] int (*)[5] |
| 1782 | </pre> |
| 1783 | </div> |
| 1784 | |
| 1785 | <p> |
| 1786 | In most cases a ltype is simply the C datatype with qualifiers stripped off. In addition, |
| 1787 | arrays are converted into pointers. |
| 1788 | </p> |
| 1789 | |
| 1790 | <p> |
| 1791 | Variables such as <tt>$&1_type</tt> and <tt>$*1_type</tt> are used to |
| 1792 | safely modify the type by removing or adding pointers. Although not |
| 1793 | needed in most typemaps, these substitutions are sometimes needed to properly |
| 1794 | work with typemaps that convert values between pointers and values. |
| 1795 | </p> |
| 1796 | |
| 1797 | <p> |
| 1798 | If necessary, type related substitutions can also be used when declaring locals. For example: |
| 1799 | </p> |
| 1800 | |
| 1801 | <div class="code"> |
| 1802 | <pre> |
| 1803 | %typemap(in) int * ($*1_type temp) { |
| 1804 | temp = PyInt_AsLong($input); |
| 1805 | $1 = &temp; |
| 1806 | } |
| 1807 | </pre> |
| 1808 | </div> |
| 1809 | |
| 1810 | <p> |
| 1811 | There is one word of caution about declaring local variables in this manner. If you declare a local variable |
| 1812 | using a type substitution such as <tt>$1_ltype temp</tt>, it won't work like you expect for arrays and certain |
| 1813 | kinds of pointers. For example, if you wrote this, |
| 1814 | </p> |
| 1815 | |
| 1816 | <div class="code"> |
| 1817 | <pre> |
| 1818 | %typemap(in) int [10][20] { |
| 1819 | $1_ltype temp; |
| 1820 | } |
| 1821 | </pre> |
| 1822 | </div> |
| 1823 | |
| 1824 | <p> |
| 1825 | then the declaration of <tt>temp</tt> will be expanded as |
| 1826 | </p> |
| 1827 | |
| 1828 | <div class="code"> |
| 1829 | <pre> |
| 1830 | int (*)[20] temp; |
| 1831 | </pre> |
| 1832 | </div> |
| 1833 | |
| 1834 | <p> |
| 1835 | This is illegal C syntax and won't compile. There is currently no |
| 1836 | straightforward way to work around this problem in SWIG due to the way |
| 1837 | that typemap code is expanded and processed. However, one possible workaround |
| 1838 | is to simply pick an alternative type such as <tt>void *</tt> and use |
| 1839 | casts to get the correct type when needed. For example: |
| 1840 | </p> |
| 1841 | |
| 1842 | <div class="code"> |
| 1843 | <pre> |
| 1844 | %typemap(in) int [10][20] { |
| 1845 | void *temp; |
| 1846 | ... |
| 1847 | (($1_ltype) temp)[i][j] = x; /* set a value */ |
| 1848 | ... |
| 1849 | } |
| 1850 | </pre> |
| 1851 | </div> |
| 1852 | |
| 1853 | <p> |
| 1854 | Another approach, which only works for arrays is to use the <tt>$1_basetype</tt> substitution. For example: |
| 1855 | </p> |
| 1856 | |
| 1857 | <div class="code"> |
| 1858 | <pre> |
| 1859 | %typemap(in) int [10][20] { |
| 1860 | $1_basetype temp[10][20]; |
| 1861 | ... |
| 1862 | temp[i][j] = x; /* set a value */ |
| 1863 | ... |
| 1864 | } |
| 1865 | </pre> |
| 1866 | </div> |
| 1867 | |
| 1868 | <H2><a name="Typemaps_nn25"></a>10.5 Common typemap methods</H2> |
| 1869 | |
| 1870 | |
| 1871 | <p> |
| 1872 | The set of typemaps recognized by a language module may vary. However, |
| 1873 | the following typemap methods are nearly universal: |
| 1874 | </p> |
| 1875 | |
| 1876 | <H3><a name="Typemaps_nn26"></a>10.5.1 "in" typemap</H3> |
| 1877 | |
| 1878 | |
| 1879 | <p> |
| 1880 | The "in" typemap is used to convert function arguments from the target language |
| 1881 | to C. For example: |
| 1882 | </p> |
| 1883 | |
| 1884 | <div class="code"> |
| 1885 | <pre> |
| 1886 | %typemap(in) int { |
| 1887 | $1 = PyInt_AsLong($input); |
| 1888 | } |
| 1889 | </pre> |
| 1890 | </div> |
| 1891 | |
| 1892 | <p> |
| 1893 | The following special variables are available: |
| 1894 | </p> |
| 1895 | |
| 1896 | <div class="code"> |
| 1897 | <pre> |
| 1898 | $input - Input object holding value to be converted. |
| 1899 | $symname - Name of function/method being wrapped |
| 1900 | </pre> |
| 1901 | </div> |
| 1902 | |
| 1903 | <p> |
| 1904 | This is probably the most commonly redefined typemap because it can be used |
| 1905 | to implement customized conversions. |
| 1906 | </p> |
| 1907 | |
| 1908 | <p> |
| 1909 | In addition, the "in" typemap allows the number of converted arguments to be |
| 1910 | specified. For example: |
| 1911 | </p> |
| 1912 | |
| 1913 | <div class="code"> |
| 1914 | <pre> |
| 1915 | // Ignored argument. |
| 1916 | %typemap(in, numinputs=0) int *out (int temp) { |
| 1917 | $1 = &temp; |
| 1918 | } |
| 1919 | </pre> |
| 1920 | </div> |
| 1921 | |
| 1922 | <p> |
| 1923 | At this time, only zero or one arguments may be converted. |
| 1924 | </p> |
| 1925 | |
| 1926 | <p> |
| 1927 | <b>Compatibility note: </b> Specifying <tt>numinputs=0</tt> |
| 1928 | is the same as the old "ignore" typemap. |
| 1929 | </p> |
| 1930 | |
| 1931 | <H3><a name="Typemaps_nn27"></a>10.5.2 "typecheck" typemap</H3> |
| 1932 | |
| 1933 | |
| 1934 | <p> |
| 1935 | The "typecheck" typemap is used to support overloaded functions and methods. It merely checks an argument |
| 1936 | to see whether or not it matches a specific type. For example: |
| 1937 | </p> |
| 1938 | |
| 1939 | <div class="code"> |
| 1940 | <pre> |
| 1941 | %typemap(typecheck,precedence=SWIG_TYPECHECK_INTEGER) int { |
| 1942 | $1 = PyInt_Check($input) ? 1 : 0; |
| 1943 | } |
| 1944 | </pre> |
| 1945 | </div> |
| 1946 | |
| 1947 | <p> |
| 1948 | For typechecking, the $1 variable is always a simple integer that is set to 1 or 0 depending on whether or not |
| 1949 | the input argument is the correct type. |
| 1950 | </p> |
| 1951 | |
| 1952 | <p> |
| 1953 | If you define new "in" typemaps <em>and</em> your program uses overloaded methods, you should also define a collection of |
| 1954 | "typecheck" typemaps. More details about this follow in a later section on "Typemaps and Overloading." |
| 1955 | </p> |
| 1956 | |
| 1957 | <H3><a name="Typemaps_nn28"></a>10.5.3 "out" typemap</H3> |
| 1958 | |
| 1959 | |
| 1960 | <p> |
| 1961 | The "out" typemap is used to convert function/method return values from C |
| 1962 | into the target language. For example: |
| 1963 | </p> |
| 1964 | |
| 1965 | <div class="code"> |
| 1966 | <pre> |
| 1967 | %typemap(out) int { |
| 1968 | $result = PyInt_FromLong($1); |
| 1969 | } |
| 1970 | </pre> |
| 1971 | </div> |
| 1972 | |
| 1973 | <p> |
| 1974 | The following special variables are available. |
| 1975 | </p> |
| 1976 | |
| 1977 | <div class="code"> |
| 1978 | <pre> |
| 1979 | $result - Result object returned to target language. |
| 1980 | $symname - Name of function/method being wrapped |
| 1981 | </pre> |
| 1982 | </div> |
| 1983 | |
| 1984 | <H3><a name="Typemaps_nn29"></a>10.5.4 "arginit" typemap</H3> |
| 1985 | |
| 1986 | |
| 1987 | <p> |
| 1988 | The "arginit" typemap is used to set the initial value of a function |
| 1989 | argument--before any conversion has occurred. This is not normally |
| 1990 | necessary, but might be useful in highly specialized applications. |
| 1991 | For example: |
| 1992 | </p> |
| 1993 | |
| 1994 | <div class="code"> |
| 1995 | <pre> |
| 1996 | // Set argument to NULL before any conversion occurs |
| 1997 | %typemap(arginit) int *data { |
| 1998 | $1 = NULL; |
| 1999 | } |
| 2000 | </pre> |
| 2001 | </div> |
| 2002 | |
| 2003 | <H3><a name="Typemaps_nn30"></a>10.5.5 "default" typemap</H3> |
| 2004 | |
| 2005 | |
| 2006 | <p> |
| 2007 | The "default" typemap is used to turn an argument into a default |
| 2008 | argument. For example: |
| 2009 | </p> |
| 2010 | |
| 2011 | <div class="code"> |
| 2012 | <pre> |
| 2013 | %typemap(default) int flags { |
| 2014 | $1 = DEFAULT_FLAGS; |
| 2015 | } |
| 2016 | ... |
| 2017 | int foo(int x, int y, int flags); |
| 2018 | </pre> |
| 2019 | </div> |
| 2020 | |
| 2021 | <p> |
| 2022 | The primary use of this typemap is to either change the wrapping of |
| 2023 | default arguments or specify a default argument in a language where |
| 2024 | they aren't supported (like C). Target languages that do not support |
| 2025 | optional arguments, such as Java and C#, effecively ignore the value specified |
| 2026 | by this typemap as all arguments must be given. |
| 2027 | </p> |
| 2028 | |
| 2029 | <p> |
| 2030 | Once a default typemap has been applied to an argument, all arguments |
| 2031 | that follow must have default values. |
| 2032 | See the <a href="SWIG.html#SWIG_default_args">Default/optional arguments</a> section |
| 2033 | for further information on default argument wrapping. |
| 2034 | </p> |
| 2035 | |
| 2036 | <H3><a name="Typemaps_nn31"></a>10.5.6 "check" typemap</H3> |
| 2037 | |
| 2038 | |
| 2039 | <p> |
| 2040 | The "check" typemap is used to supply value checking code during argument |
| 2041 | conversion. The typemap is applied <em>after</em> arguments have been |
| 2042 | converted. For example: |
| 2043 | </p> |
| 2044 | |
| 2045 | <div class="code"> |
| 2046 | <pre> |
| 2047 | %typemap(check) int positive { |
| 2048 | if ($1 <= 0) { |
| 2049 | SWIG_exception(SWIG_ValueError,"Expected positive value."); |
| 2050 | } |
| 2051 | } |
| 2052 | </pre> |
| 2053 | </div> |
| 2054 | |
| 2055 | <H3><a name="Typemaps_nn32"></a>10.5.7 "argout" typemap</H3> |
| 2056 | |
| 2057 | |
| 2058 | <p> |
| 2059 | The "argout" typemap is used to return values from arguments. This |
| 2060 | is most commonly used to write wrappers for C/C++ functions that need |
| 2061 | to return multiple values. The "argout" typemap is almost always combined |
| 2062 | with an "in" typemap---possibly to ignore the input value. For example: |
| 2063 | </p> |
| 2064 | |
| 2065 | <div class="code"> |
| 2066 | <pre> |
| 2067 | /* Set the input argument to point to a temporary variable */ |
| 2068 | %typemap(in, numinputs=0) int *out (int temp) { |
| 2069 | $1 = &temp; |
| 2070 | } |
| 2071 | |
| 2072 | %typemap(argout) int *out { |
| 2073 | // Append output value $1 to $result |
| 2074 | ... |
| 2075 | } |
| 2076 | </pre> |
| 2077 | </div> |
| 2078 | |
| 2079 | <p> |
| 2080 | The following special variables are available. |
| 2081 | </p> |
| 2082 | |
| 2083 | <div class="diagram"> |
| 2084 | <pre> |
| 2085 | $result - Result object returned to target language. |
| 2086 | $input - The original input object passed. |
| 2087 | $symname - Name of function/method being wrapped |
| 2088 | </pre> |
| 2089 | </div> |
| 2090 | |
| 2091 | <p> |
| 2092 | The code supplied to the "argout" typemap is always placed after |
| 2093 | the "out" typemap. If multiple return values are used, the extra |
| 2094 | return values are often appended to return value of the function. |
| 2095 | </p> |
| 2096 | |
| 2097 | <p> |
| 2098 | See the <tt>typemaps.i</tt> library for examples. |
| 2099 | </p> |
| 2100 | |
| 2101 | <H3><a name="Typemaps_nn33"></a>10.5.8 "freearg" typemap</H3> |
| 2102 | |
| 2103 | |
| 2104 | <p> |
| 2105 | The "freearg" typemap is used to cleanup argument data. It is only |
| 2106 | used when an argument might have allocated resources that need to be |
| 2107 | cleaned up when the wrapper function exits. The "freearg" typemap |
| 2108 | usually cleans up argument resources allocated by the "in" typemap. |
| 2109 | For example: |
| 2110 | </p> |
| 2111 | |
| 2112 | <div class="code"> |
| 2113 | <pre> |
| 2114 | // Get a list of integers |
| 2115 | %typemap(in) int *items { |
| 2116 | int nitems = Length($input); |
| 2117 | $1 = (int *) malloc(sizeof(int)*nitems); |
| 2118 | } |
| 2119 | // Free the list |
| 2120 | %typemap(freearg) int *items { |
| 2121 | free($1); |
| 2122 | } |
| 2123 | </pre> |
| 2124 | </div> |
| 2125 | |
| 2126 | <p> |
| 2127 | The "freearg" typemap inserted at the end of the wrapper function, |
| 2128 | just before control is returned back to the target language. This |
| 2129 | code is also placed into a special variable <tt>$cleanup</tt> that may |
| 2130 | be used in other typemaps whenever a wrapper function needs to abort |
| 2131 | prematurely. |
| 2132 | </p> |
| 2133 | |
| 2134 | <H3><a name="Typemaps_nn34"></a>10.5.9 "newfree" typemap</H3> |
| 2135 | |
| 2136 | |
| 2137 | <p> |
| 2138 | The "newfree" typemap is used in conjunction with the <tt>%newobject</tt> |
| 2139 | directive and is used to deallocate memory used by the return result |
| 2140 | of a function. For example: |
| 2141 | </p> |
| 2142 | |
| 2143 | <div class="code"> |
| 2144 | <pre> |
| 2145 | %typemap(newfree) string * { |
| 2146 | delete $1; |
| 2147 | } |
| 2148 | %typemap(out) string * { |
| 2149 | $result = PyString_FromString($1->c_str()); |
| 2150 | } |
| 2151 | ... |
| 2152 | |
| 2153 | %newobject foo; |
| 2154 | ... |
| 2155 | string *foo(); |
| 2156 | </pre> |
| 2157 | </div> |
| 2158 | |
| 2159 | <H3><a name="Typemaps_nn35"></a>10.5.10 "memberin" typemap</H3> |
| 2160 | |
| 2161 | |
| 2162 | <p> |
| 2163 | The "memberin" typemap is used to copy data from <em>an already converted input value</em> |
| 2164 | into a structure member. It is typically used to handle array members and other special |
| 2165 | cases. For example: |
| 2166 | </p> |
| 2167 | |
| 2168 | <div class="code"> |
| 2169 | <pre> |
| 2170 | %typemap(memberin) int [4] { |
| 2171 | memmove($1, $input, 4*sizeof(int)); |
| 2172 | } |
| 2173 | </pre> |
| 2174 | </div> |
| 2175 | |
| 2176 | <p> |
| 2177 | It is rarely necessary to write "memberin" typemaps---SWIG already provides |
| 2178 | a default implementation for arrays, strings, and other objects. |
| 2179 | </p> |
| 2180 | |
| 2181 | <H3><a name="Typemaps_nn36"></a>10.5.11 "varin" typemap</H3> |
| 2182 | |
| 2183 | |
| 2184 | <p> |
| 2185 | The "varin" typemap is used to convert objects in the target language to C for the |
| 2186 | purposes of assigning to a C/C++ global variable. This is implementation specific. |
| 2187 | </p> |
| 2188 | |
| 2189 | <H3><a name="Typemaps_nn37"></a>10.5.12 "varout" typemap</H3> |
| 2190 | |
| 2191 | |
| 2192 | <p> |
| 2193 | The "varout" typemap is used to convert a C/C++ object to an object in the target |
| 2194 | language when reading a C/C++ global variable. This is implementation specific. |
| 2195 | </p> |
| 2196 | |
| 2197 | <H3><a name="throws_typemap"></a>10.5.13 "throws" typemap</H3> |
| 2198 | |
| 2199 | |
| 2200 | <p> |
| 2201 | The "throws" typemap is only used when SWIG parses a C++ method with an exception specification. |
| 2202 | It provides a default mechanism for handling C++ methods that have declared the exceptions it will throw. |
| 2203 | The purpose of this typemap is to convert a C++ exception into an error or exception in the target language. |
| 2204 | It is slightly different to the other typemaps as it is based around the exception type rather than the type of a parameter or variable. |
| 2205 | For example: |
| 2206 | </p> |
| 2207 | |
| 2208 | <div class="code"> |
| 2209 | <pre> |
| 2210 | %typemap(throws) const char * %{ |
| 2211 | PyErr_SetString(PyExc_RuntimeError, $1); |
| 2212 | SWIG_fail; |
| 2213 | %} |
| 2214 | void bar() throw (const char *); |
| 2215 | </pre> |
| 2216 | </div> |
| 2217 | |
| 2218 | <p> |
| 2219 | As can be seen from the generated code below, SWIG generates an exception handler |
| 2220 | with the catch block comprising the "throws" typemap content. |
| 2221 | </p> |
| 2222 | |
| 2223 | <div class="code"> |
| 2224 | <pre> |
| 2225 | ... |
| 2226 | try { |
| 2227 | bar(); |
| 2228 | } |
| 2229 | catch(char const *_e) { |
| 2230 | PyErr_SetString(PyExc_RuntimeError, _e); |
| 2231 | SWIG_fail; |
| 2232 | |
| 2233 | } |
| 2234 | ... |
| 2235 | </pre> |
| 2236 | </div> |
| 2237 | |
| 2238 | <p> |
| 2239 | Note that if your methods do not have an exception specification yet they do throw exceptions, SWIG cannot know how to deal with them. |
| 2240 | For a neat way to handle these, see the <a href="Customization.html#exception">Exception handling with %exception</a> section. |
| 2241 | </p> |
| 2242 | |
| 2243 | <H2><a name="Typemaps_nn39"></a>10.6 Some typemap examples</H2> |
| 2244 | |
| 2245 | |
| 2246 | <p> |
| 2247 | This section contains a few examples. Consult language module documentation |
| 2248 | for more examples. |
| 2249 | </p> |
| 2250 | |
| 2251 | <H3><a name="Typemaps_nn40"></a>10.6.1 Typemaps for arrays</H3> |
| 2252 | |
| 2253 | |
| 2254 | <p> |
| 2255 | A common use of typemaps is to provide support for C arrays appearing both as |
| 2256 | arguments to functions and as structure members. |
| 2257 | </p> |
| 2258 | |
| 2259 | <p> |
| 2260 | For example, suppose you had a function like this: |
| 2261 | </p> |
| 2262 | |
| 2263 | <div class="code"> |
| 2264 | <pre> |
| 2265 | void set_vector(int type, float value[4]); |
| 2266 | </pre> |
| 2267 | </div> |
| 2268 | |
| 2269 | <p> |
| 2270 | If you wanted to handle <tt>float value[4]</tt> as a list of floats, you might write a typemap |
| 2271 | similar to this: |
| 2272 | </p> |
| 2273 | |
| 2274 | <div class="code"> |
| 2275 | <pre> |
| 2276 | |
| 2277 | %typemap(in) float value[4] (float temp[4]) { |
| 2278 | int i; |
| 2279 | if (!PySequence_Check($input)) { |
| 2280 | PyErr_SetString(PyExc_ValueError,"Expected a sequence"); |
| 2281 | return NULL; |
| 2282 | } |
| 2283 | if (PySequence_Length($input) != 4) { |
| 2284 | PyErr_SetString(PyExc_ValueError,"Size mismatch. Expected 4 elements"); |
| 2285 | return NULL; |
| 2286 | } |
| 2287 | for (i = 0; i < 4; i++) { |
| 2288 | PyObject *o = PySequence_GetItem($input,i); |
| 2289 | if (PyNumber_Check(o)) { |
| 2290 | temp[i] = (float) PyFloat_AsDouble(o); |
| 2291 | } else { |
| 2292 | PyErr_SetString(PyExc_ValueError,"Sequence elements must be numbers"); |
| 2293 | return NULL; |
| 2294 | } |
| 2295 | } |
| 2296 | $1 = temp; |
| 2297 | } |
| 2298 | </pre> |
| 2299 | </div> |
| 2300 | |
| 2301 | <p> |
| 2302 | In this example, the variable <tt>temp</tt> allocates a small array on the |
| 2303 | C stack. The typemap then populates this array and passes it to the underlying C function. |
| 2304 | </p> |
| 2305 | |
| 2306 | <p> |
| 2307 | When used from Python, the typemap allows the following type of function call: |
| 2308 | </p> |
| 2309 | |
| 2310 | <div class="targetlang"> |
| 2311 | <pre> |
| 2312 | >>> set_vector(type, [ 1, 2.5, 5, 20 ]) |
| 2313 | </pre> |
| 2314 | </div> |
| 2315 | |
| 2316 | <p> |
| 2317 | If you wanted to generalize the typemap to apply to arrays of all dimensions you might write this: |
| 2318 | </p> |
| 2319 | |
| 2320 | <div class="code"> |
| 2321 | <pre> |
| 2322 | %typemap(in) float value[ANY] (float temp[$1_dim0]) { |
| 2323 | int i; |
| 2324 | if (!PySequence_Check($input)) { |
| 2325 | PyErr_SetString(PyExc_ValueError,"Expected a sequence"); |
| 2326 | return NULL; |
| 2327 | } |
| 2328 | if (PySequence_Length($input) != $1_dim0) { |
| 2329 | PyErr_SetString(PyExc_ValueError,"Size mismatch. Expected $1_dim0 elements"); |
| 2330 | return NULL; |
| 2331 | } |
| 2332 | for (i = 0; i < $1_dim0; i++) { |
| 2333 | PyObject *o = PySequence_GetItem($input,i); |
| 2334 | if (PyNumber_Check(o)) { |
| 2335 | temp[i] = (float) PyFloat_AsDouble(o); |
| 2336 | } else { |
| 2337 | PyErr_SetString(PyExc_ValueError,"Sequence elements must be numbers"); |
| 2338 | return NULL; |
| 2339 | } |
| 2340 | } |
| 2341 | $1 = temp; |
| 2342 | } |
| 2343 | </pre> |
| 2344 | </div> |
| 2345 | |
| 2346 | <p> |
| 2347 | In this example, the special variable <tt>$1_dim0</tt> is expanded with the actual |
| 2348 | array dimensions. Multidimensional arrays can be matched in a similar manner. For example: |
| 2349 | </p> |
| 2350 | |
| 2351 | <div class="code"> |
| 2352 | <pre> |
| 2353 | %typemap(python,in) float matrix[ANY][ANY] (float temp[$1_dim0][$1_dim1]) { |
| 2354 | ... convert a 2d array ... |
| 2355 | } |
| 2356 | </pre> |
| 2357 | </div> |
| 2358 | |
| 2359 | <p> |
| 2360 | For large arrays, it may be impractical to allocate storage on the stack using a temporary variable |
| 2361 | as shown. To work with heap allocated data, the following technique can be used. |
| 2362 | </p> |
| 2363 | |
| 2364 | <div class="code"> |
| 2365 | <pre> |
| 2366 | %typemap(in) float value[ANY] { |
| 2367 | int i; |
| 2368 | if (!PySequence_Check($input)) { |
| 2369 | PyErr_SetString(PyExc_ValueError,"Expected a sequence"); |
| 2370 | return NULL; |
| 2371 | } |
| 2372 | if (PySequence_Length($input) != $1_dim0) { |
| 2373 | PyErr_SetString(PyExc_ValueError,"Size mismatch. Expected $1_dim0 elements"); |
| 2374 | return NULL; |
| 2375 | } |
| 2376 | $1 = (float *) malloc($1_dim0*sizeof(float)); |
| 2377 | for (i = 0; i < $1_dim0; i++) { |
| 2378 | PyObject *o = PySequence_GetItem($input,i); |
| 2379 | if (PyNumber_Check(o)) { |
| 2380 | $1[i] = (float) PyFloat_AsDouble(o); |
| 2381 | } else { |
| 2382 | PyErr_SetString(PyExc_ValueError,"Sequence elements must be numbers"); |
| 2383 | free($1); |
| 2384 | return NULL; |
| 2385 | } |
| 2386 | } |
| 2387 | } |
| 2388 | %typemap(freearg) float value[ANY] { |
| 2389 | if ($1) free($1); |
| 2390 | } |
| 2391 | </pre> |
| 2392 | </div> |
| 2393 | |
| 2394 | <p> |
| 2395 | In this case, an array is allocated using <tt>malloc</tt>. The <tt>freearg</tt> typemap is then used |
| 2396 | to release the argument after the function has been called. |
| 2397 | </p> |
| 2398 | |
| 2399 | <p> |
| 2400 | Another common use of array typemaps is to provide support for array structure members. |
| 2401 | Due to subtle differences between pointers and arrays in C, you can't just "assign" to |
| 2402 | a array structure member. Instead, you have to explicitly copy elements into the array. |
| 2403 | For example, suppose you had a structure like this: |
| 2404 | </p> |
| 2405 | |
| 2406 | <div class="code"><pre> |
| 2407 | struct SomeObject { |
| 2408 | float value[4]; |
| 2409 | ... |
| 2410 | }; |
| 2411 | </pre></div> |
| 2412 | |
| 2413 | <p> |
| 2414 | When SWIG runs, it won't produce any code to set the <tt>vec</tt> member. |
| 2415 | You may even get a warning message like this: |
| 2416 | </p> |
| 2417 | |
| 2418 | <div class="shell"><pre> |
| 2419 | swig -python example.i |
| 2420 | Generating wrappers for Python |
| 2421 | example.i:10. Warning. Array member value will be read-only. |
| 2422 | </pre></div> |
| 2423 | |
| 2424 | <p> |
| 2425 | These warning messages indicate that SWIG does not know how you want |
| 2426 | to set the <tt>vec</tt> field. |
| 2427 | </p> |
| 2428 | |
| 2429 | <p> |
| 2430 | To fix this, you can supply a special "memberin" typemap like this: |
| 2431 | </p> |
| 2432 | |
| 2433 | <div class="code"><pre> |
| 2434 | %typemap(memberin) float [ANY] { |
| 2435 | int i; |
| 2436 | for (i = 0; i < $1_dim0; i++) { |
| 2437 | $1[i] = $input[i]; |
| 2438 | } |
| 2439 | } |
| 2440 | </pre></div> |
| 2441 | |
| 2442 | <p> |
| 2443 | The memberin typemap is used to set a structure member from data that has already been converted |
| 2444 | from the target language to C. In this case, <tt>$input</tt> is the local variable in which |
| 2445 | converted input data is stored. This typemap then copies this data into the structure. |
| 2446 | </p> |
| 2447 | |
| 2448 | <p> |
| 2449 | When combined with the earlier typemaps for arrays, the combination of the "in" and "memberin" typemap allows |
| 2450 | the following usage: |
| 2451 | </p> |
| 2452 | |
| 2453 | <div class="targetlang"> |
| 2454 | <pre> |
| 2455 | >>> s = SomeObject() |
| 2456 | >>> s.x = [1, 2.5, 5, 10] |
| 2457 | </pre> |
| 2458 | </div> |
| 2459 | |
| 2460 | <p> |
| 2461 | Related to structure member input, it may be desirable to return structure members as a new kind of |
| 2462 | object. For example, in this example, you will get very odd program behavior where the structure member |
| 2463 | can be set nicely, but reading the member simply returns a pointer: |
| 2464 | </p> |
| 2465 | |
| 2466 | <div class="targetlang"> |
| 2467 | <pre> |
| 2468 | >>> s = SomeObject() |
| 2469 | >>> s.x = [1, 2.5, 5, 10] |
| 2470 | >>> print s.x |
| 2471 | _1008fea8_p_float |
| 2472 | >>> |
| 2473 | </pre> |
| 2474 | </div> |
| 2475 | |
| 2476 | <p> |
| 2477 | To fix this, you can write an "out" typemap. For example: |
| 2478 | </p> |
| 2479 | |
| 2480 | <div class="code"> |
| 2481 | <pre> |
| 2482 | %typemap(out) float [ANY] { |
| 2483 | int i; |
| 2484 | $result = PyList_New($1_dim0); |
| 2485 | for (i = 0; i < $1_dim0; i++) { |
| 2486 | PyObject *o = PyFloat_FromDouble((double) $1[i]); |
| 2487 | PyList_SetItem($result,i,o); |
| 2488 | } |
| 2489 | } |
| 2490 | </pre> |
| 2491 | </div> |
| 2492 | |
| 2493 | <p> |
| 2494 | Now, you will find that member access is quite nice: |
| 2495 | </p> |
| 2496 | |
| 2497 | <div class="targetlang"> |
| 2498 | <pre> |
| 2499 | >>> s = SomeObject() |
| 2500 | >>> s.x = [1, 2.5, 5, 10] |
| 2501 | >>> print s.x |
| 2502 | [ 1, 2.5, 5, 10] |
| 2503 | </pre> |
| 2504 | </div> |
| 2505 | |
| 2506 | <p> |
| 2507 | <b>Compatibility Note:</b> SWIG1.1 used to provide a special "memberout" typemap. However, it was mostly |
| 2508 | useless and has since been eliminated. To return structure members, simply use the "out" typemap. |
| 2509 | </p> |
| 2510 | |
| 2511 | <H3><a name="Typemaps_nn41"></a>10.6.2 Implementing constraints with typemaps</H3> |
| 2512 | |
| 2513 | |
| 2514 | <p> |
| 2515 | One particularly interesting application of typemaps is the |
| 2516 | implementation of argument constraints. This can be done with the |
| 2517 | "check" typemap. When used, this allows you to provide code for |
| 2518 | checking the values of function arguments. For example :</p> |
| 2519 | |
| 2520 | <div class="code"><pre> |
| 2521 | %module math |
| 2522 | |
| 2523 | %typemap(check) double posdouble { |
| 2524 | if ($1 < 0) { |
| 2525 | croak("Expecting a positive number"); |
| 2526 | } |
| 2527 | } |
| 2528 | |
| 2529 | ... |
| 2530 | double sqrt(double posdouble); |
| 2531 | |
| 2532 | </pre></div> |
| 2533 | |
| 2534 | <p> |
| 2535 | This provides a sanity check to your wrapper function. If a negative |
| 2536 | number is passed to this function, a Perl exception will be raised and |
| 2537 | your program terminated with an error message.</p> |
| 2538 | |
| 2539 | <p> |
| 2540 | This kind of checking can be particularly useful when working with |
| 2541 | pointers. For example :</p> |
| 2542 | |
| 2543 | <div class="code"><pre> |
| 2544 | %typemap(check) Vector * { |
| 2545 | if ($1 == 0) { |
| 2546 | PyErr_SetString(PyExc_TypeError,"NULL Pointer not allowed"); |
| 2547 | return NULL; |
| 2548 | } |
| 2549 | } |
| 2550 | |
| 2551 | </pre></div> |
| 2552 | |
| 2553 | <p> |
| 2554 | will prevent any function involving a <tt>Vector *</tt> from accepting |
| 2555 | a NULL pointer. As a result, SWIG can often prevent a potential |
| 2556 | segmentation faults or other run-time problems by raising an exception |
| 2557 | rather than blindly passing values to the underlying C/C++ program.</p> |
| 2558 | |
| 2559 | <p> |
| 2560 | Note: A more advanced constraint checking system is in development. Stay tuned. |
| 2561 | </p> |
| 2562 | |
| 2563 | <H2><a name="Typemaps_nn42"></a>10.7 Multi-argument typemaps</H2> |
| 2564 | |
| 2565 | |
| 2566 | <p> |
| 2567 | So far, the typemaps presented have focused on the problem of dealing with |
| 2568 | single values. For example, converting a single input object to a single argument |
| 2569 | in a function call. However, certain conversion problems are difficult to handle |
| 2570 | in this manner. As an example, consider the example at the very beginning of this |
| 2571 | chapter: |
| 2572 | </p> |
| 2573 | |
| 2574 | <div class="code"> |
| 2575 | <pre> |
| 2576 | int foo(int argc, char *argv[]); |
| 2577 | </pre> |
| 2578 | </div> |
| 2579 | |
| 2580 | <p> |
| 2581 | Suppose that you wanted to wrap this function so that it accepted a single |
| 2582 | list of strings like this: |
| 2583 | </p> |
| 2584 | |
| 2585 | <div class="targetlang"> |
| 2586 | <pre> |
| 2587 | >>> foo(["ale","lager","stout"]) |
| 2588 | </pre> |
| 2589 | </div> |
| 2590 | |
| 2591 | <p> |
| 2592 | To do this, you not only need to map a list of strings to <tt> char *argv[]</tt>, but the |
| 2593 | value of <tt>int argc</tt> is implicitly determined by the length of the list. Using only simple |
| 2594 | typemaps, this type of conversion is possible, but extremely painful. Therefore, SWIG1.3 |
| 2595 | introduces the notion of multi-argument typemaps. |
| 2596 | </p> |
| 2597 | |
| 2598 | <p> |
| 2599 | A multi-argument typemap is a conversion rule that specifies how to |
| 2600 | convert a <em>single</em> object in the target language to set of |
| 2601 | consecutive function arguments in C/C++. For example, the following multi-argument |
| 2602 | maps perform the conversion described for the above example: |
| 2603 | </p> |
| 2604 | |
| 2605 | <div class="code"> |
| 2606 | <pre> |
| 2607 | %typemap(in) (int argc, char *argv[]) { |
| 2608 | int i; |
| 2609 | if (!PyList_Check($input)) { |
| 2610 | PyErr_SetString(PyExc_ValueError, "Expecting a list"); |
| 2611 | return NULL; |
| 2612 | } |
| 2613 | $1 = PyList_Size($input); |
| 2614 | $2 = (char **) malloc(($1+1)*sizeof(char *)); |
| 2615 | for (i = 0; i < $1; i++) { |
| 2616 | PyObject *s = PyList_GetItem($input,i); |
| 2617 | if (!PyString_Check(s)) { |
| 2618 | free($2); |
| 2619 | PyErr_SetString(PyExc_ValueError, "List items must be strings"); |
| 2620 | return NULL; |
| 2621 | } |
| 2622 | $2[i] = PyString_AsString(s); |
| 2623 | } |
| 2624 | $2[i] = 0; |
| 2625 | } |
| 2626 | |
| 2627 | %typemap(freearg) (int argc, char *argv[]) { |
| 2628 | if ($2) free($2); |
| 2629 | } |
| 2630 | </pre> |
| 2631 | </div> |
| 2632 | |
| 2633 | <p> |
| 2634 | A multi-argument map is always specified by surrounding the arguments with parentheses as shown. |
| 2635 | For example: |
| 2636 | </p> |
| 2637 | |
| 2638 | <div class="code"> |
| 2639 | <pre> |
| 2640 | %typemap(in) (int argc, char *argv[]) { ... } |
| 2641 | </pre> |
| 2642 | </div> |
| 2643 | |
| 2644 | <p> |
| 2645 | Within the typemap code, the variables <tt>$1</tt>, <tt>$2</tt>, and so forth refer to each type |
| 2646 | in the map. All of the usual substitutions apply--just use the appropriate <tt>$1</tt> or <tt>$2</tt> |
| 2647 | prefix on the variable name (e.g., <tt>$2_type</tt>, <tt>$1_ltype</tt>, etc.) |
| 2648 | </p> |
| 2649 | |
| 2650 | <p> |
| 2651 | Multi-argument typemaps always have precedence over simple typemaps and SWIG always performs longest-match searching. |
| 2652 | Therefore, you will get the following behavior: |
| 2653 | </p> |
| 2654 | |
| 2655 | <div class="code"> |
| 2656 | <pre> |
| 2657 | %typemap(in) int argc { ... typemap 1 ... } |
| 2658 | %typemap(in) (int argc, char *argv[]) { ... typemap 2 ... } |
| 2659 | %typemap(in) (int argc, char *argv[], char *env[]) { ... typemap 3 ... } |
| 2660 | |
| 2661 | int foo(int argc, char *argv[]); // Uses typemap 2 |
| 2662 | int bar(int argc, int x); // Uses typemap 1 |
| 2663 | int spam(int argc, char *argv[], char *env[]); // Uses typemap 3 |
| 2664 | </pre> |
| 2665 | </div> |
| 2666 | |
| 2667 | <p> |
| 2668 | It should be stressed that multi-argument typemaps can appear anywhere in a function declaration and can |
| 2669 | appear more than once. For example, you could write this: |
| 2670 | </p> |
| 2671 | |
| 2672 | <div class="code"> |
| 2673 | <pre> |
| 2674 | %typemap(in) (int scount, char *swords[]) { ... } |
| 2675 | %typemap(in) (int wcount, char *words[]) { ... } |
| 2676 | |
| 2677 | void search_words(int scount, char *swords[], int wcount, char *words[], int maxcount); |
| 2678 | </pre> |
| 2679 | </div> |
| 2680 | |
| 2681 | <p> |
| 2682 | Other directives such as <tt>%apply</tt> and <tt>%clear</tt> also work with multi-argument maps. For example: |
| 2683 | </p> |
| 2684 | |
| 2685 | <div class="code"> |
| 2686 | <pre> |
| 2687 | %apply (int argc, char *argv[]) { |
| 2688 | (int scount, char *swords[]), |
| 2689 | (int wcount, char *words[]) |
| 2690 | }; |
| 2691 | ... |
| 2692 | %clear (int scount, char *swords[]), (int wcount, char *words[]); |
| 2693 | ... |
| 2694 | </pre> |
| 2695 | </div> |
| 2696 | |
| 2697 | <p> |
| 2698 | Although multi-argument typemaps may seem like an exotic, little used feature, there |
| 2699 | are several situations where they make sense. First, suppose you wanted to wrap |
| 2700 | functions similar to the low-level <tt>read()</tt> and <tt>write()</tt> system calls. |
| 2701 | For example: |
| 2702 | </p> |
| 2703 | |
| 2704 | <div class="code"> |
| 2705 | <pre> |
| 2706 | typedef unsigned int size_t; |
| 2707 | |
| 2708 | int read(int fd, void *rbuffer, size_t len); |
| 2709 | int write(int fd, void *wbuffer, size_t len); |
| 2710 | </pre> |
| 2711 | </div> |
| 2712 | |
| 2713 | <p> |
| 2714 | As is, the only way to use the functions would be to allocate memory and pass some kind of pointer |
| 2715 | as the second argument---a process that might require the use of a helper function. However, using |
| 2716 | multi-argument maps, the functions can be transformed into something more natural. For example, you |
| 2717 | might write typemaps like this: |
| 2718 | </p> |
| 2719 | |
| 2720 | <div class="code"> |
| 2721 | <pre> |
| 2722 | // typemap for an outgoing buffer |
| 2723 | %typemap(in) (void *wbuffer, size_t len) { |
| 2724 | if (!PyString_Check($input)) { |
| 2725 | PyErr_SetString(PyExc_ValueError, "Expecting a string"); |
| 2726 | return NULL; |
| 2727 | } |
| 2728 | $1 = (void *) PyString_AsString($input); |
| 2729 | $2 = PyString_Size($input); |
| 2730 | } |
| 2731 | |
| 2732 | // typemap for an incoming buffer |
| 2733 | %typemap(in) (void *rbuffer, size_t len) { |
| 2734 | if (!PyInt_Check($input)) { |
| 2735 | PyErr_SetString(PyExc_ValueError, "Expecting an integer"); |
| 2736 | return NULL; |
| 2737 | } |
| 2738 | $2 = PyInt_AsLong($input); |
| 2739 | if ($2 < 0) { |
| 2740 | PyErr_SetString(PyExc_ValueError, "Positive integer expected"); |
| 2741 | return NULL; |
| 2742 | } |
| 2743 | $1 = (void *) malloc($2); |
| 2744 | } |
| 2745 | |
| 2746 | // Return the buffer. Discarding any previous return result |
| 2747 | %typemap(argout) (void *rbuffer, size_t len) { |
| 2748 | Py_XDECREF($result); /* Blow away any previous result */ |
| 2749 | if (result < 0) { /* Check for I/O error */ |
| 2750 | free($1); |
| 2751 | PyErr_SetFromErrno(PyExc_IOError); |
| 2752 | return NULL; |
| 2753 | } |
| 2754 | $result = PyString_FromStringAndSize($1,result); |
| 2755 | free($1); |
| 2756 | } |
| 2757 | </pre> |
| 2758 | </div> |
| 2759 | |
| 2760 | <p> |
| 2761 | (note: In the above example, <tt>$result</tt> and <tt>result</tt> are two different variables. |
| 2762 | <tt>result</tt> is the real C datatype that was returned by the function. <tt>$result</tt> is the |
| 2763 | scripting language object being returned to the interpreter.). |
| 2764 | </p> |
| 2765 | |
| 2766 | <p> |
| 2767 | Now, in a script, you can write code that simply passes buffers as strings like this: |
| 2768 | </p> |
| 2769 | |
| 2770 | <div class="targetlang"> |
| 2771 | <pre> |
| 2772 | >>> f = example.open("Makefile") |
| 2773 | >>> example.read(f,40) |
| 2774 | 'TOP = ../..\nSWIG = $(TOP)/.' |
| 2775 | >>> example.read(f,40) |
| 2776 | './swig\nSRCS = example.c\nTARGET ' |
| 2777 | >>> example.close(f) |
| 2778 | 0 |
| 2779 | >>> g = example.open("foo", example.O_WRONLY | example.O_CREAT, 0644) |
| 2780 | >>> example.write(g,"Hello world\n") |
| 2781 | 12 |
| 2782 | >>> example.write(g,"This is a test\n") |
| 2783 | 15 |
| 2784 | >>> example.close(g) |
| 2785 | 0 |
| 2786 | >>> |
| 2787 | </pre> |
| 2788 | </div> |
| 2789 | |
| 2790 | <p> |
| 2791 | A number of multi-argument typemap problems also arise in libraries that |
| 2792 | perform matrix-calculations--especially if they are mapped onto low-level Fortran |
| 2793 | or C code. For example, you might have a function like this: |
| 2794 | </p> |
| 2795 | |
| 2796 | <div class="code"> |
| 2797 | <pre> |
| 2798 | int is_symmetric(double *mat, int rows, int columns); |
| 2799 | </pre> |
| 2800 | </div> |
| 2801 | |
| 2802 | <p> |
| 2803 | In this case, you might want to pass some kind of higher-level object as an matrix. To do |
| 2804 | this, you could write a multi-argument typemap like this: |
| 2805 | </p> |
| 2806 | |
| 2807 | <div class="code"> |
| 2808 | <pre> |
| 2809 | %typemap(in) (double *mat, int rows, int columns) { |
| 2810 | MatrixObject *a; |
| 2811 | a = GetMatrixFromObject($input); /* Get matrix somehow */ |
| 2812 | |
| 2813 | /* Get matrix properties */ |
| 2814 | $1 = GetPointer(a); |
| 2815 | $2 = GetRows(a); |
| 2816 | $3 = GetColumns(a); |
| 2817 | } |
| 2818 | </pre> |
| 2819 | </div> |
| 2820 | |
| 2821 | <p> |
| 2822 | This kind of technique can be used to hook into scripting-language matrix packages such as |
| 2823 | Numeric Python. However, it should also be stressed that some care is in order. For example, |
| 2824 | when crossing languages you may need to worry about issues such as row-major vs. column-major |
| 2825 | ordering (and perform conversions if needed). |
| 2826 | </p> |
| 2827 | |
| 2828 | <H2><a name="runtime_type_checker"></a>10.8 The run-time type checker</H2> |
| 2829 | |
| 2830 | |
| 2831 | <p> |
| 2832 | Most scripting languages need type information at run-time. This type information |
| 2833 | can include how to construct types, how to garbage collect types, and the inheritance |
| 2834 | relationships between types. If the language interface does not provide its own type |
| 2835 | information storage, the generated SWIG code needs to provide it. |
| 2836 | </p> |
| 2837 | |
| 2838 | <p> |
| 2839 | Requirements for the type system: |
| 2840 | </p> |
| 2841 | <ul> |
| 2842 | <li>Store inheritance and type equivalence information and be able to correctly |
| 2843 | re-create the type pointer.</li> |
| 2844 | <li>Share type information between modules.</li> |
| 2845 | <li>Modules can be loaded in any order, irregardless of actual type |
| 2846 | dependency.</li> |
| 2847 | <li>Avoid the use of dynamically allocated memory, and library/system calls in general.</li> |
| 2848 | <li>Provide a reasonably fast implementation, minimizing the lookup time for all |
| 2849 | language modules.</li> |
| 2850 | <li>Custom, language specific information can be attached to types.</li> |
| 2851 | <li>Modules can be unloaded from the type system.</li> |
| 2852 | </ul> |
| 2853 | |
| 2854 | <H3><a name="Typemaps_nn45"></a>10.8.1 Implementation</H3> |
| 2855 | |
| 2856 | |
| 2857 | <p> |
| 2858 | The run-time type checker is used by many, but not all, of SWIG's supported target languages. |
| 2859 | The run-time type checker features |
| 2860 | are not required and are thus not used for strongly typed languages such as Java and C#. |
| 2861 | The scripting and scheme based languages rely on it and it forms |
| 2862 | a critical part of SWIG's operation for these languages. |
| 2863 | </p> |
| 2864 | |
| 2865 | <p> |
| 2866 | When pointers, arrays, and objects are wrapped by SWIG, they are normally converted |
| 2867 | into typed pointer objects. For example, an instance of <tt>Foo *</tt> might be |
| 2868 | a string encoded like this: |
| 2869 | </p> |
| 2870 | |
| 2871 | <div class="diagram"> |
| 2872 | <pre> |
| 2873 | _108e688_p_Foo |
| 2874 | </pre> |
| 2875 | </div> |
| 2876 | |
| 2877 | <p> |
| 2878 | At a basic level, the type checker simply restores some type-safety to |
| 2879 | extension modules. However, the type checker is also responsible for |
| 2880 | making sure that wrapped C++ classes are handled |
| 2881 | correctly---especially when inheritance is used. This is especially |
| 2882 | important when an extension module makes use of multiple inheritance. |
| 2883 | For example: |
| 2884 | </p> |
| 2885 | |
| 2886 | <div class="code"> |
| 2887 | <pre> |
| 2888 | class Foo { |
| 2889 | int x; |
| 2890 | }; |
| 2891 | |
| 2892 | class Bar { |
| 2893 | int y; |
| 2894 | }; |
| 2895 | |
| 2896 | class FooBar : public Foo, public Bar { |
| 2897 | int z; |
| 2898 | }; |
| 2899 | </pre> |
| 2900 | </div> |
| 2901 | |
| 2902 | <p> |
| 2903 | When the class <tt>FooBar</tt> is organized in memory, it contains the contents |
| 2904 | of the classes <tt>Foo</tt> and <tt>Bar</tt> as well as its own data members. For example: |
| 2905 | </p> |
| 2906 | |
| 2907 | <div class="diagram"> |
| 2908 | <pre> |
| 2909 | FooBar --> | -----------| <-- Foo |
| 2910 | | int x | |
| 2911 | |------------| <-- Bar |
| 2912 | | int y | |
| 2913 | |------------| |
| 2914 | | int z | |
| 2915 | |------------| |
| 2916 | </pre> |
| 2917 | </div> |
| 2918 | |
| 2919 | <p> |
| 2920 | Because of the way that base class data is stacked together, the |
| 2921 | casting of a <tt>Foobar *</tt> to either of the base classes may |
| 2922 | change the actual value of the pointer. This means that it is |
| 2923 | generally not safe to represent pointers using a simple integer or a |
| 2924 | bare <tt>void *</tt>---type tags are needed to implement correct |
| 2925 | handling of pointer values (and to make adjustments when needed). |
| 2926 | </p> |
| 2927 | |
| 2928 | <p> |
| 2929 | In the wrapper code generated for each language, pointers are handled through |
| 2930 | the use of special type descriptors and conversion functions. For example, |
| 2931 | if you look at the wrapper code for Python, you will see code like this: |
| 2932 | </p> |
| 2933 | |
| 2934 | <div class="code"> |
| 2935 | <pre> |
| 2936 | if ((SWIG_ConvertPtr(obj0,(void **) &arg1, SWIGTYPE_p_Foo,1)) == -1) return NULL; |
| 2937 | </pre> |
| 2938 | </div> |
| 2939 | |
| 2940 | <p> |
| 2941 | In this code, <tt>SWIGTYPE_p_Foo</tt> is the type descriptor that |
| 2942 | describes <tt>Foo *</tt>. The type descriptor is actually a pointer to a |
| 2943 | structure that contains information about the type name to use in the |
| 2944 | target language, a list of equivalent typenames (via typedef or |
| 2945 | inheritance), and pointer value handling information (if applicable). |
| 2946 | The <tt>SWIG_ConvertPtr()</tt> function is simply a utility function |
| 2947 | that takes a pointer object in the target language and a |
| 2948 | type-descriptor objects and uses this information to generate a C++ |
| 2949 | pointer. However, the exact name and calling conventions of the conversion |
| 2950 | function depends on the target language (see language specific chapters for details). |
| 2951 | </p> |
| 2952 | |
| 2953 | <p> |
| 2954 | The actual type code is in swigrun.swg, and gets inserted near the top of the generated |
| 2955 | swig wrapper file. The phrase "a type X that can cast into a type Y" means |
| 2956 | that given a type X, it can be converted into a type Y. In other words, X is a derived |
| 2957 | class of Y or X is a typedef of Y. The structure to store type information looks like this: |
| 2958 | </p> |
| 2959 | |
| 2960 | <div class="code"> |
| 2961 | <pre> |
| 2962 | /* Structure to store information on one type */ |
| 2963 | typedef struct swig_type_info { |
| 2964 | const char *name; /* mangled name of this type */ |
| 2965 | const char *str; /* human readable name for this type */ |
| 2966 | swig_dycast_func dcast; /* dynamic cast function down a hierarchy */ |
| 2967 | struct swig_cast_info *cast; /* Linked list of types that can cast into this type */ |
| 2968 | void *clientdata; /* Language specific type data */ |
| 2969 | } swig_type_info; |
| 2970 | |
| 2971 | /* Structure to store a type and conversion function used for casting */ |
| 2972 | typedef struct swig_cast_info { |
| 2973 | swig_type_info *type; /* pointer to type that is equivalent to this type */ |
| 2974 | swig_converter_func converter; /* function to cast the void pointers */ |
| 2975 | struct swig_cast_info *next; /* pointer to next cast in linked list */ |
| 2976 | struct swig_cast_info *prev; /* pointer to the previous cast */ |
| 2977 | } swig_cast_info; |
| 2978 | </pre> |
| 2979 | </div> |
| 2980 | |
| 2981 | <p> |
| 2982 | Each <tt>swig_type_info</tt> stores a linked list of types that it is equivalent to. Each entry in this |
| 2983 | doubly linked list stores a pointer back to another swig_type_info structure, |
| 2984 | along with a pointer to a conversion function. This conversion function is used |
| 2985 | to solve the above problem of the FooBar class, correctly returning a pointer to |
| 2986 | the type we want. |
| 2987 | </p> |
| 2988 | |
| 2989 | <p> |
| 2990 | The basic problem we need to solve is verifying and building arguments passed to functions. |
| 2991 | So going back to the <tt>SWIG_ConvertPtr()</tt> function example from above, we are |
| 2992 | expecting a <tt>Foo *</tt> and need to |
| 2993 | check if <tt>obj0</tt> is in fact a <tt>Foo *</tt>. From before, <tt>SWIGTYPE_p_Foo</tt> is just |
| 2994 | a pointer to the <tt>swig_type_info</tt> structure describing <tt>Foo *</tt>. So we loop though the |
| 2995 | linked list of <tt>swig_cast_info</tt> structures attached to <tt>SWIGTYPE_p_Foo</tt>. If we see that the type of <tt>obj0</tt> is in the |
| 2996 | linked list, we pass the object through the associated conversion function and |
| 2997 | then return a positive. If we reach the end of the linked list without a match, |
| 2998 | then <tt>obj0</tt> can not be converted to a <tt>Foo *</tt> and an error is generated. |
| 2999 | </p> |
| 3000 | |
| 3001 | <p> |
| 3002 | Another issue needing to be addressed is sharing type information between multiple modules. |
| 3003 | More explicitly, we need |
| 3004 | to have ONE <tt>swig_type_info</tt> for each type. If two modules both use the type, the |
| 3005 | second module loaded must lookup and use the swig_type_info structure from the module already loaded. |
| 3006 | Because no dynamic memory is used and the circular dependencies of the |
| 3007 | casting information, loading the type information is somewhat tricky, and not explained here. |
| 3008 | A complete description is in the <tt>common.swg</tt> file (and near the top of any generated file). |
| 3009 | </p> |
| 3010 | |
| 3011 | <p> |
| 3012 | Each module has one swig_module_info structure which looks like this: |
| 3013 | </p> |
| 3014 | |
| 3015 | <div class="code"> |
| 3016 | <pre> |
| 3017 | /* Structure used to store module information |
| 3018 | * Each module generates one structure like this, and the runtime collects |
| 3019 | * all of these structures and stores them in a circularly linked list.*/ |
| 3020 | typedef struct swig_module_info { |
| 3021 | swig_type_info **types; /* Array of pointers to swig_type_info structs in this module */ |
| 3022 | int size; /* Number of types in this module */ |
| 3023 | struct swig_module_info *next; /* Pointer to next element in circularly linked list */ |
| 3024 | swig_type_info **type_initial; /* Array of initially generated type structures */ |
| 3025 | swig_cast_info **cast_initial; /* Array of initially generated casting structures */ |
| 3026 | void *clientdata; /* Language specific module data */ |
| 3027 | } swig_module_info; |
| 3028 | </pre> |
| 3029 | </div> |
| 3030 | |
| 3031 | <p> |
| 3032 | Each module stores an array of pointers to <tt>swig_type_info</tt> structures and the number of |
| 3033 | types in this module. So when a second module is loaded, it finds the <tt>swig_module_info</tt> |
| 3034 | structure for the first module and searches the array of types. If any of its own |
| 3035 | types are in the first module and have already been loaded, it uses those <tt>swig_type_info</tt> |
| 3036 | structures rather than creating new ones. These <tt>swig_module_info</tt> |
| 3037 | structures are chained together in a circularly linked list. |
| 3038 | </p> |
| 3039 | |
| 3040 | <H3><a name="Typemaps_nn46"></a>10.8.2 Usage</H3> |
| 3041 | |
| 3042 | |
| 3043 | <p>This section covers how to use these functions from typemaps. To learn how to |
| 3044 | call these functions from external files (not the generated _wrap.c file), see |
| 3045 | the <a href="Modules.html#external_run_time">External access to the run-time system</a> |
| 3046 | section.</p> |
| 3047 | |
| 3048 | <p>When pointers are converted in a typemap, the typemap code often looks |
| 3049 | similar to this: |
| 3050 | </p> |
| 3051 | |
| 3052 | <div class="code"> |
| 3053 | <pre> |
| 3054 | %typemap(in) Foo * { |
| 3055 | if ((SWIG_ConvertPtr($input, (void **) &$1, $1_descriptor)) == -1) return NULL; |
| 3056 | } |
| 3057 | </pre> |
| 3058 | </div> |
| 3059 | |
| 3060 | <p> |
| 3061 | The most critical part is the typemap is the use of the <tt>$1_descriptor</tt> |
| 3062 | special variable. When placed in a typemap, this is expanded into the |
| 3063 | <tt>SWIGTYPE_*</tt> type descriptor object above. As a general rule, |
| 3064 | you should always use <tt>$1_descriptor</tt> instead of trying to |
| 3065 | hard-code the type descriptor name directly. |
| 3066 | </p> |
| 3067 | |
| 3068 | <p> |
| 3069 | There is another reason why you should always use the |
| 3070 | <tt>$1_descriptor</tt> variable. When this special variable is |
| 3071 | expanded, SWIG marks the corresponding type as "in use." When |
| 3072 | type-tables and type information is emitted in the wrapper file, |
| 3073 | descriptor information is only generated for those datatypes that were |
| 3074 | actually used in the interface. This greatly reduces the size of the |
| 3075 | type tables and improves efficiency. |
| 3076 | </p> |
| 3077 | |
| 3078 | <p> |
| 3079 | Occassionally, you might need to write a typemap that needs to convert |
| 3080 | pointers of other types. To handle this, a special macro substition |
| 3081 | <tt>$descriptor(type)</tt> can be used to generate the SWIG type |
| 3082 | descriptor name for any C datatype. For example: |
| 3083 | </p> |
| 3084 | |
| 3085 | <div class="code"> |
| 3086 | <pre> |
| 3087 | %typemap(in) Foo * { |
| 3088 | if ((SWIG_ConvertPtr($input, (void **) &$1, $1_descriptor)) == -1) { |
| 3089 | Bar *temp; |
| 3090 | if ((SWIG_ConvertPtr($input, (void **) &temp, <b>$descriptor(Bar *)</b>) == -1) { |
| 3091 | return NULL; |
| 3092 | } |
| 3093 | $1 = (Foo *) temp; |
| 3094 | } |
| 3095 | } |
| 3096 | </pre> |
| 3097 | </div> |
| 3098 | |
| 3099 | <p> |
| 3100 | The primary use of <tt>$descriptor(type)</tt> is when writing typemaps for container |
| 3101 | objects and other complex data structures. There are some restrictions on the argument---namely it must |
| 3102 | be a fully defined C datatype. It can not be any of the special typemap variables. |
| 3103 | </p> |
| 3104 | |
| 3105 | <p> |
| 3106 | In certain cases, SWIG may not generate type-descriptors like you expect. For example, |
| 3107 | if you are converting pointers in some non-standard way or working with an unusual |
| 3108 | combination of interface files and modules, you may find that SWIG omits information |
| 3109 | for a specific type descriptor. To fix this, you may need to use the <tt>%types</tt> directive. |
| 3110 | For example: |
| 3111 | </p> |
| 3112 | |
| 3113 | <div class="code"> |
| 3114 | <pre> |
| 3115 | %types(int *, short *, long *, float *, double *); |
| 3116 | </pre> |
| 3117 | </div> |
| 3118 | |
| 3119 | <p> |
| 3120 | When <tt>%types</tt> is used, SWIG generates type-descriptor |
| 3121 | information even if those datatypes never appear elsewhere in the |
| 3122 | interface file. |
| 3123 | </p> |
| 3124 | |
| 3125 | <p> |
| 3126 | A final problem related to the type-checker is the conversion of types |
| 3127 | in code that is external to the SWIG wrapper file. This situation is |
| 3128 | somewhat rare in practice, but occasionally a programmer may want to |
| 3129 | convert a typed pointer object into a C++ pointer somewhere else in |
| 3130 | their program. The only problem is that the SWIG type descriptor |
| 3131 | objects are only defined in the wrapper code and not normally |
| 3132 | accessible. |
| 3133 | </p> |
| 3134 | |
| 3135 | <p> |
| 3136 | To correctly deal with this situation, the following technique can be used: |
| 3137 | </p> |
| 3138 | |
| 3139 | <div class="code"> |
| 3140 | <pre> |
| 3141 | |
| 3142 | /* Some non-SWIG file */ |
| 3143 | |
| 3144 | /* External declarations */ |
| 3145 | extern void *SWIG_TypeQuery(const char *); |
| 3146 | extern int SWIG_ConvertPtr(PyObject *, void **ptr, void *descr); |
| 3147 | |
| 3148 | void foo(PyObject *o) { |
| 3149 | Foo *f; |
| 3150 | static void *descr = 0; |
| 3151 | if (!descr) { |
| 3152 | descr = SWIG_TypeQuery("Foo *"); /* Get the type descriptor structure for Foo */ |
| 3153 | assert(descr); |
| 3154 | } |
| 3155 | if ((SWIG_ConvertPtr(o,(void **) &f, descr) == -1)) { |
| 3156 | abort(); |
| 3157 | } |
| 3158 | ... |
| 3159 | } |
| 3160 | </pre> |
| 3161 | </div> |
| 3162 | |
| 3163 | <p> |
| 3164 | Further details about the run-time type checking can be found in the documentation for |
| 3165 | individual language modules. Reading the source code may also help. The file |
| 3166 | <tt>swigrun.swg</tt> in the SWIG library contains all of the source code for |
| 3167 | type-checking. This code is also included in every generated wrapped file so you |
| 3168 | probably just look at the output of SWIG to get a better sense for how types are |
| 3169 | managed. |
| 3170 | </p> |
| 3171 | |
| 3172 | <H2><a name="Typemaps_overloading"></a>10.9 Typemaps and overloading</H2> |
| 3173 | |
| 3174 | |
| 3175 | <p> |
| 3176 | In many target languages, SWIG fully supports C++ overloaded methods and functions. For example, |
| 3177 | if you have a collection of functions like this: |
| 3178 | </p> |
| 3179 | |
| 3180 | <div class="code"> |
| 3181 | <pre> |
| 3182 | int foo(int x); |
| 3183 | int foo(double x); |
| 3184 | int foo(char *s, int y); |
| 3185 | </pre> |
| 3186 | </div> |
| 3187 | |
| 3188 | <p> |
| 3189 | You can access the functions in a normal way from the scripting interpreter: |
| 3190 | </p> |
| 3191 | |
| 3192 | <div class="targetlang"> |
| 3193 | <pre> |
| 3194 | # Python |
| 3195 | foo(3) # foo(int) |
| 3196 | foo(3.5) # foo(double) |
| 3197 | foo("hello",5) # foo(char *, int) |
| 3198 | |
| 3199 | # Tcl |
| 3200 | foo 3 # foo(int) |
| 3201 | foo 3.5 # foo(double) |
| 3202 | foo hello 5 # foo(char *, int) |
| 3203 | </pre> |
| 3204 | </div> |
| 3205 | |
| 3206 | <p> |
| 3207 | To implement overloading, SWIG generates a separate wrapper function for each overloaded method. |
| 3208 | For example, the above functions would produce something roughly like this: |
| 3209 | </p> |
| 3210 | |
| 3211 | <div class="code"> |
| 3212 | <pre> |
| 3213 | // wrapper pseudocode |
| 3214 | _wrap_foo_0(argc, args[]) { // foo(int) |
| 3215 | int arg1; |
| 3216 | int result; |
| 3217 | ... |
| 3218 | arg1 = FromInteger(args[0]); |
| 3219 | result = foo(arg1); |
| 3220 | return ToInteger(result); |
| 3221 | } |
| 3222 | |
| 3223 | _wrap_foo_1(argc, args[]) { // foo(double) |
| 3224 | double arg1; |
| 3225 | int result; |
| 3226 | ... |
| 3227 | arg1 = FromDouble(args[0]); |
| 3228 | result = foo(arg1); |
| 3229 | return ToInteger(result); |
| 3230 | } |
| 3231 | |
| 3232 | _wrap_foo_2(argc, args[]) { // foo(char *, int) |
| 3233 | char *arg1; |
| 3234 | int arg2; |
| 3235 | int result; |
| 3236 | ... |
| 3237 | arg1 = FromString(args[0]); |
| 3238 | arg2 = FromInteger(args[1]); |
| 3239 | result = foo(arg1,arg2); |
| 3240 | return ToInteger(result); |
| 3241 | } |
| 3242 | |
| 3243 | </pre> |
| 3244 | </div> |
| 3245 | |
| 3246 | <p> |
| 3247 | Next, a dynamic dispatch function is generated: |
| 3248 | </p> |
| 3249 | |
| 3250 | <div class="code"> |
| 3251 | <pre> |
| 3252 | _wrap_foo(argc, args[]) { |
| 3253 | if (argc == 1) { |
| 3254 | if (IsInteger(args[0])) { |
| 3255 | return _wrap_foo_0(argc,args); |
| 3256 | } |
| 3257 | if (IsDouble(args[0])) { |
| 3258 | return _wrap_foo_1(argc,args); |
| 3259 | } |
| 3260 | } |
| 3261 | if (argc == 2) { |
| 3262 | if (IsString(args[0]) && IsInteger(args[1])) { |
| 3263 | return _wrap_foo_2(argc,args); |
| 3264 | } |
| 3265 | } |
| 3266 | error("No matching function!\n"); |
| 3267 | } |
| 3268 | </pre> |
| 3269 | </div> |
| 3270 | |
| 3271 | <p> |
| 3272 | The purpose of the dynamic dispatch function is to select the appropriate C++ function based on |
| 3273 | argument types---a task that must be performed at runtime in most of SWIG's target languages. |
| 3274 | </p> |
| 3275 | |
| 3276 | <p> |
| 3277 | The generation of the dynamic dispatch function is a relatively tricky affair. Not only must input typemaps |
| 3278 | be taken into account (these typemaps can radically change the types of arguments accepted), but overloaded |
| 3279 | methods must also be sorted and checked in a very specific order to resolve potential ambiguity. A high-level |
| 3280 | overview of this ranking process is found in the "<a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a>" chapter. What isn't mentioned in that chapter |
| 3281 | is the mechanism by which it is implemented---as a collection of typemaps. |
| 3282 | </p> |
| 3283 | |
| 3284 | <p> |
| 3285 | To support dynamic dispatch, SWIG first defines a general purpose type hierarchy as follows: |
| 3286 | </p> |
| 3287 | |
| 3288 | <div class="diagram"> |
| 3289 | <pre> |
| 3290 | Symbolic Name Precedence Value |
| 3291 | ------------------------------ ------------------ |
| 3292 | SWIG_TYPECHECK_POINTER 0 |
| 3293 | SWIG_TYPECHECK_VOIDPTR 10 |
| 3294 | SWIG_TYPECHECK_BOOL 15 |
| 3295 | SWIG_TYPECHECK_UINT8 20 |
| 3296 | SWIG_TYPECHECK_INT8 25 |
| 3297 | SWIG_TYPECHECK_UINT16 30 |
| 3298 | SWIG_TYPECHECK_INT16 35 |
| 3299 | SWIG_TYPECHECK_UINT32 40 |
| 3300 | SWIG_TYPECHECK_INT32 45 |
| 3301 | SWIG_TYPECHECK_UINT64 50 |
| 3302 | SWIG_TYPECHECK_INT64 55 |
| 3303 | SWIG_TYPECHECK_UINT128 60 |
| 3304 | SWIG_TYPECHECK_INT128 65 |
| 3305 | SWIG_TYPECHECK_INTEGER 70 |
| 3306 | SWIG_TYPECHECK_FLOAT 80 |
| 3307 | SWIG_TYPECHECK_DOUBLE 90 |
| 3308 | SWIG_TYPECHECK_COMPLEX 100 |
| 3309 | SWIG_TYPECHECK_UNICHAR 110 |
| 3310 | SWIG_TYPECHECK_UNISTRING 120 |
| 3311 | SWIG_TYPECHECK_CHAR 130 |
| 3312 | SWIG_TYPECHECK_STRING 140 |
| 3313 | SWIG_TYPECHECK_BOOL_ARRAY 1015 |
| 3314 | SWIG_TYPECHECK_INT8_ARRAY 1025 |
| 3315 | SWIG_TYPECHECK_INT16_ARRAY 1035 |
| 3316 | SWIG_TYPECHECK_INT32_ARRAY 1045 |
| 3317 | SWIG_TYPECHECK_INT64_ARRAY 1055 |
| 3318 | SWIG_TYPECHECK_INT128_ARRAY 1065 |
| 3319 | SWIG_TYPECHECK_FLOAT_ARRAY 1080 |
| 3320 | SWIG_TYPECHECK_DOUBLE_ARRAY 1090 |
| 3321 | SWIG_TYPECHECK_CHAR_ARRAY 1130 |
| 3322 | SWIG_TYPECHECK_STRING_ARRAY 1140 |
| 3323 | </pre> |
| 3324 | </div> |
| 3325 | |
| 3326 | <p> |
| 3327 | (These precedence levels are defined in <tt>swig.swg</tt>, a library file that's included by all target language modules.) |
| 3328 | </p> |
| 3329 | |
| 3330 | <p> |
| 3331 | In this table, the precedence-level determines the order in which types are going to be checked. Low values |
| 3332 | are always checked before higher values. For example, integers are checked before floats, single values are checked |
| 3333 | before arrays, and so forth. |
| 3334 | </p> |
| 3335 | |
| 3336 | <p> |
| 3337 | Using the above table as a guide, each target language defines a collection of "typecheck" typemaps. |
| 3338 | The follow excerpt from the Python module illustrates this: |
| 3339 | </p> |
| 3340 | |
| 3341 | <div class="code"> |
| 3342 | <pre> |
| 3343 | /* Python type checking rules */ |
| 3344 | /* Note: %typecheck(X) is a macro for %typemap(typecheck,precedence=X) */ |
| 3345 | |
| 3346 | %typecheck(SWIG_TYPECHECK_INTEGER) |
| 3347 | int, short, long, |
| 3348 | unsigned int, unsigned short, unsigned long, |
| 3349 | signed char, unsigned char, |
| 3350 | long long, unsigned long long, |
| 3351 | const int &, const short &, const long &, |
| 3352 | const unsigned int &, const unsigned short &, const unsigned long &, |
| 3353 | const long long &, const unsigned long long &, |
| 3354 | enum SWIGTYPE, |
| 3355 | bool, const bool & |
| 3356 | { |
| 3357 | $1 = (PyInt_Check($input) || PyLong_Check($input)) ? 1 : 0; |
| 3358 | } |
| 3359 | |
| 3360 | %typecheck(SWIG_TYPECHECK_DOUBLE) |
| 3361 | float, double, |
| 3362 | const float &, const double & |
| 3363 | { |
| 3364 | $1 = (PyFloat_Check($input) || PyInt_Check($input) || PyLong_Check($input)) ? 1 : 0; |
| 3365 | } |
| 3366 | |
| 3367 | %typecheck(SWIG_TYPECHECK_CHAR) char { |
| 3368 | $1 = (PyString_Check($input) && (PyString_Size($input) == 1)) ? 1 : 0; |
| 3369 | } |
| 3370 | |
| 3371 | %typecheck(SWIG_TYPECHECK_STRING) char * { |
| 3372 | $1 = PyString_Check($input) ? 1 : 0; |
| 3373 | } |
| 3374 | |
| 3375 | %typecheck(SWIG_TYPECHECK_POINTER) SWIGTYPE *, SWIGTYPE &, SWIGTYPE [] { |
| 3376 | void *ptr; |
| 3377 | if (SWIG_ConvertPtr($input, (void **) &ptr, $1_descriptor, 0) == -1) { |
| 3378 | $1 = 0; |
| 3379 | PyErr_Clear(); |
| 3380 | } else { |
| 3381 | $1 = 1; |
| 3382 | } |
| 3383 | } |
| 3384 | |
| 3385 | %typecheck(SWIG_TYPECHECK_POINTER) SWIGTYPE { |
| 3386 | void *ptr; |
| 3387 | if (SWIG_ConvertPtr($input, (void **) &ptr, $&1_descriptor, 0) == -1) { |
| 3388 | $1 = 0; |
| 3389 | PyErr_Clear(); |
| 3390 | } else { |
| 3391 | $1 = 1; |
| 3392 | } |
| 3393 | } |
| 3394 | |
| 3395 | %typecheck(SWIG_TYPECHECK_VOIDPTR) void * { |
| 3396 | void *ptr; |
| 3397 | if (SWIG_ConvertPtr($input, (void **) &ptr, 0, 0) == -1) { |
| 3398 | $1 = 0; |
| 3399 | PyErr_Clear(); |
| 3400 | } else { |
| 3401 | $1 = 1; |
| 3402 | } |
| 3403 | } |
| 3404 | |
| 3405 | %typecheck(SWIG_TYPECHECK_POINTER) PyObject * |
| 3406 | { |
| 3407 | $1 = ($input != 0); |
| 3408 | } |
| 3409 | </pre> |
| 3410 | </div> |
| 3411 | |
| 3412 | <p> |
| 3413 | It might take a bit of contemplation, but this code has merely organized all of the basic C++ types, provided some simple type-checking |
| 3414 | code, and assigned each type a precedence value. |
| 3415 | </p> |
| 3416 | |
| 3417 | <p> |
| 3418 | Finally, to generate the dynamic dispatch function, SWIG uses the following algorithm: |
| 3419 | </p> |
| 3420 | |
| 3421 | <ul> |
| 3422 | <li>Overloaded methods are first sorted by the number of required arguments.</li> |
| 3423 | <li>Methods with the same number of arguments are then sorted by precedence values of argument types.</li> |
| 3424 | <li>Typecheck typemaps are then emitted to produce a dispatch function that checks arguments in the correct order.</li> |
| 3425 | </ul> |
| 3426 | |
| 3427 | <p> |
| 3428 | If you haven't written any typemaps of your own, it is unnecessary to worry about the typechecking rules. |
| 3429 | However, if you have written new input typemaps, you might have to supply a typechecking rule as well. |
| 3430 | An easy way to do this is to simply copy one of the existing typechecking rules. |
| 3431 | Here is an example, |
| 3432 | </p> |
| 3433 | |
| 3434 | <div class="code"> |
| 3435 | <pre> |
| 3436 | // Typemap for a C++ string |
| 3437 | %typemap(in) std::string { |
| 3438 | if (PyString_Check($input)) { |
| 3439 | $1 = std::string(PyString_AsString($input)); |
| 3440 | } else { |
| 3441 | SWIG_exception(SWIG_TypeError, "string expected"); |
| 3442 | } |
| 3443 | } |
| 3444 | // Copy the typecheck code for "char *". |
| 3445 | %typemap(typecheck) std::string = char *; |
| 3446 | </pre> |
| 3447 | </div> |
| 3448 | |
| 3449 | <p> |
| 3450 | The bottom line: If you are writing new typemaps and you are using overloaded methods, you will probably |
| 3451 | have to write typecheck code or copy existing code. Since this is a relatively new SWIG feature, there are |
| 3452 | few examples to work with. However, you might look at some of the existing library files likes 'typemaps.i' for |
| 3453 | a guide. |
| 3454 | </p> |
| 3455 | |
| 3456 | <p> |
| 3457 | <b>Notes:</b> |
| 3458 | </p> |
| 3459 | |
| 3460 | <ul> |
| 3461 | <li>Typecheck typemaps are not used for non-overloaded methods. Because of this, it is |
| 3462 | still always necessary to check types in any "in" typemaps. |
| 3463 | </li> |
| 3464 | |
| 3465 | <li>The dynamic dispatch process is only meant to be a heuristic. There are many corner |
| 3466 | cases where SWIG simply can't disambiguate types to the same degree as C++. The only way to |
| 3467 | resolve this ambiguity is to use the %rename directive to rename one of the overloaded methods (effectively |
| 3468 | eliminating overloading). |
| 3469 | </li> |
| 3470 | |
| 3471 | <li> |
| 3472 | Typechecking may be partial. For example, if working with arrays, the typecheck code might |
| 3473 | simply check the type of the first array element and use that to dispatch to the correct function. |
| 3474 | Subsequent "in" typemaps would then perform more extensive type-checking. |
| 3475 | </li> |
| 3476 | |
| 3477 | <li>Make sure you read the section on overloading in the "<a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a>" chapter. |
| 3478 | </li> |
| 3479 | </ul> |
| 3480 | |
| 3481 | <H2><a name="Typemaps_nn48"></a>10.10 More about <tt>%apply</tt> and <tt>%clear</tt></H2> |
| 3482 | |
| 3483 | |
| 3484 | <p> |
| 3485 | In order to implement certain kinds of program behavior, it is sometimes necessary to |
| 3486 | write sets of typemaps. For example, to support output arguments, one often writes |
| 3487 | a set of typemaps like this: |
| 3488 | </p> |
| 3489 | |
| 3490 | <div class="code"> |
| 3491 | <pre> |
| 3492 | %typemap(in,numinputs=0) int *OUTPUT (int temp) { |
| 3493 | $1 = &temp; |
| 3494 | } |
| 3495 | %typemap(argout) int *OUTPUT { |
| 3496 | // return value somehow |
| 3497 | } |
| 3498 | </pre> |
| 3499 | </div> |
| 3500 | |
| 3501 | <p> |
| 3502 | To make it easier to apply the typemap to different argument types and names, the <tt>%apply</tt> directive |
| 3503 | performs a copy of all typemaps from one type to another. For example, if you specify this, |
| 3504 | </p> |
| 3505 | |
| 3506 | <div class="code"> |
| 3507 | <pre> |
| 3508 | %apply int *OUTPUT { int *retvalue, int32 *output }; |
| 3509 | </pre> |
| 3510 | </div> |
| 3511 | |
| 3512 | <p> |
| 3513 | then all of the <tt>int *OUTPUT</tt> typemaps are copied to <tt>int *retvalue</tt> and <tt>int32 *output</tt>. |
| 3514 | </p> |
| 3515 | |
| 3516 | <p> |
| 3517 | However, there is a subtle aspect of <tt>%apply</tt> that needs more description. Namely, <tt>%apply</tt> does not |
| 3518 | overwrite a typemap rule if it is already defined for the target datatype. This behavior allows you to do two things: |
| 3519 | </p> |
| 3520 | |
| 3521 | <ul> |
| 3522 | <li>You can specialize parts of a complex typemap rule by first defining a few typemaps and then using |
| 3523 | <tt>%apply</tt> to incorporate the remaining pieces. |
| 3524 | </li> |
| 3525 | |
| 3526 | <li>Sets of different typemaps can be applied to the same datatype using repeated <tt>%apply</tt> directives. |
| 3527 | </li> |
| 3528 | </ul> |
| 3529 | |
| 3530 | <p> |
| 3531 | For example: |
| 3532 | </p> |
| 3533 | |
| 3534 | <div class="code"> |
| 3535 | <pre> |
| 3536 | %typemap(in) int *INPUT (int temp) { |
| 3537 | temp = ... get value from $input ...; |
| 3538 | $1 = &temp; |
| 3539 | } |
| 3540 | |
| 3541 | %typemap(check) int *POSITIVE { |
| 3542 | if (*$1 <= 0) { |
| 3543 | SWIG_exception(SWIG_ValueError,"Expected a positive number!\n"); |
| 3544 | return NULL; |
| 3545 | } |
| 3546 | } |
| 3547 | |
| 3548 | ... |
| 3549 | %apply int *INPUT { int *invalue }; |
| 3550 | %apply int *POSITIVE { int *invalue }; |
| 3551 | </pre> |
| 3552 | </div> |
| 3553 | |
| 3554 | <p> |
| 3555 | Since <tt>%apply</tt> does not overwrite or replace any existing rules, the only way to reset behavior is to |
| 3556 | use the <tt>%clear</tt> directive. <tt>%clear</tt> removes all typemap rules defined for a specific datatype. For |
| 3557 | example: |
| 3558 | </p> |
| 3559 | |
| 3560 | <div class="code"> |
| 3561 | <pre> |
| 3562 | %clear int *invalue; |
| 3563 | </pre> |
| 3564 | </div> |
| 3565 | |
| 3566 | <H2><a name="Typemaps_nn49"></a>10.11 Reducing wrapper code size</H2> |
| 3567 | |
| 3568 | |
| 3569 | <p> |
| 3570 | Since the code supplied to a typemap is inlined directly into wrapper functions, typemaps can result |
| 3571 | in a tremendous amount of code bloat. For example, consider this typemap for an array: |
| 3572 | </p> |
| 3573 | |
| 3574 | <div class="code"> |
| 3575 | <pre> |
| 3576 | %typemap(in) float [ANY] { |
| 3577 | int i; |
| 3578 | if (!PySequence_Check($input)) { |
| 3579 | PyErr_SetString(PyExc_ValueError,"Expected a sequence"); |
| 3580 | return NULL; |
| 3581 | } |
| 3582 | if (PySequence_Length($input) != $1_dim0) { |
| 3583 | PyErr_SetString(PyExc_ValueError,"Size mismatch. Expected $1_dim0 elements"); |
| 3584 | return NULL; |
| 3585 | } |
| 3586 | $1 = (float) malloc($1_dim0*sizeof(float)); |
| 3587 | for (i = 0; i < $1_dim0; i++) { |
| 3588 | PyObject *o = PySequence_GetItem($input,i); |
| 3589 | if (PyNumber_Check(o)) { |
| 3590 | $1[i] = (float) PyFloat_AsDouble(o); |
| 3591 | } else { |
| 3592 | PyErr_SetString(PyExc_ValueError,"Sequence elements must be numbers"); |
| 3593 | free(result); |
| 3594 | return NULL; |
| 3595 | } |
| 3596 | } |
| 3597 | } |
| 3598 | </pre> |
| 3599 | </div> |
| 3600 | |
| 3601 | <p> |
| 3602 | If you had a large interface with hundreds of functions all accepting |
| 3603 | array parameters, this typemap would be replicated |
| 3604 | repeatedly--generating a huge amount of code. A better approach might |
| 3605 | be to consolidate some of the typemap into a function. For example: |
| 3606 | </p> |
| 3607 | |
| 3608 | <div class="code"> |
| 3609 | <pre> |
| 3610 | %{ |
| 3611 | /* Define a helper function */ |
| 3612 | static float * |
| 3613 | convert_float_array(PyObject *input, int size) { |
| 3614 | int i; |
| 3615 | float *result; |
| 3616 | if (!PySequence_Check(input)) { |
| 3617 | PyErr_SetString(PyExc_ValueError,"Expected a sequence"); |
| 3618 | return NULL; |
| 3619 | } |
| 3620 | if (PySequence_Length(input) != size) { |
| 3621 | PyErr_SetString(PyExc_ValueError,"Size mismatch. "); |
| 3622 | return NULL; |
| 3623 | } |
| 3624 | result = (float) malloc(size*sizeof(float)); |
| 3625 | for (i = 0; i < size; i++) { |
| 3626 | PyObject *o = PySequence_GetItem(input,i); |
| 3627 | if (PyNumber_Check(o)) { |
| 3628 | result[i] = (float) PyFloat_AsDouble(o); |
| 3629 | } else { |
| 3630 | PyErr_SetString(PyExc_ValueError,"Sequence elements must be numbers"); |
| 3631 | free(result); |
| 3632 | return NULL; |
| 3633 | } |
| 3634 | } |
| 3635 | return result; |
| 3636 | } |
| 3637 | %} |
| 3638 | |
| 3639 | %typemap(in) float [ANY] { |
| 3640 | $1 = convert_float_array($input, $1_dim0); |
| 3641 | if (!$1) return NULL; |
| 3642 | } |
| 3643 | %} |
| 3644 | </pre> |
| 3645 | </div> |
| 3646 | |
| 3647 | <H2><a name="Typemaps_nn47"></a>10.12 Passing data between typemaps</H2> |
| 3648 | |
| 3649 | |
| 3650 | <p> |
| 3651 | It is also important to note that the primary use of local variables |
| 3652 | is to create stack-allocated objects for temporary use inside a |
| 3653 | wrapper function (this is faster and less-prone to error than |
| 3654 | allocating data on the heap). In general, the variables are not intended |
| 3655 | to pass information between different types of typemaps. However, this |
| 3656 | can be done if you realize that local names have the argument number appended |
| 3657 | to them. For example, you could do this: |
| 3658 | </p> |
| 3659 | |
| 3660 | <div class="code"> |
| 3661 | <pre> |
| 3662 | %typemap(in) int *(int temp) { |
| 3663 | temp = (int) PyInt_AsLong($input); |
| 3664 | $1 = &temp; |
| 3665 | } |
| 3666 | |
| 3667 | %typemap(argout) int * { |
| 3668 | PyObject *o = PyInt_FromLong(temp$argnum); |
| 3669 | ... |
| 3670 | } |
| 3671 | </pre> |
| 3672 | </div> |
| 3673 | |
| 3674 | <p> |
| 3675 | In this case, the <tt>$argnum</tt> variable is expanded into the argument |
| 3676 | number. Therefore, the code will reference the appropriate local |
| 3677 | such as <tt>temp1</tt> and <tt>temp2</tt>. It should be noted that there are |
| 3678 | plenty of opportunities to break the universe here and that accessing locals |
| 3679 | in this manner should probably be avoided. At the very least, you should make |
| 3680 | sure that the typemaps sharing information have exactly the same types and names. |
| 3681 | </p> |
| 3682 | |
| 3683 | |
| 3684 | <H2><a name="Typemaps_nn51"></a>10.13 Where to go for more information?</H2> |
| 3685 | |
| 3686 | |
| 3687 | <p> |
| 3688 | The |
| 3689 | best place to find out more information about writing typemaps is to |
| 3690 | look in the SWIG library. Most language modules define all of their |
| 3691 | default behavior using typemaps. These are found in files such as |
| 3692 | <tt>python.swg</tt>, <tt>perl5.swg</tt>, <tt>tcl8.swg</tt> and so |
| 3693 | forth. The <tt>typemaps.i</tt> file in the library also contains |
| 3694 | numerous examples. You should look at these files to get a feel |
| 3695 | for how to define typemaps of your own. |
| 3696 | Some of the language modules support additional typemaps and further |
| 3697 | information is available in the individual chapters for each target language. |
| 3698 | </p> |
| 3699 | |
| 3700 | </body> |
| 3701 | </html> |