PageRenderTime 468ms CodeModel.GetById 33ms RepoModel.GetById 17ms app.codeStats 0ms

/tags/ttn-post-libtool-1-4-3-upgrade/SWIG/Doc/Manual/Advanced.html

#
HTML | 350 lines | 293 code | 53 blank | 4 comment | 0 complexity | b02f2caa0c57eb30a07009175faca205 MD5 | raw file
Possible License(s): LGPL-2.1, Cube, GPL-3.0, 0BSD, GPL-2.0 
    

  1. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    2. 

  2. <!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
    3. 

  3. <!-- And munged by Dave's special Python script -->
    4. 

  4. <html>
    5. 

  5. <head>
    6. 

  6. <title>Advanced Topics</title>
    7. 

  7. </head>
    8. 

  8. 

  9. <body bgcolor="#ffffff">
    10. 

  10. <a name="n1"></a><H1>13 Advanced Topics</H1>
    11. 

  11. <!-- INDEX -->
    12. 

  12. <ul>
    13. 

  13. <li><a href="#n2">Creating multi-module packages</a>
    14. 

  14. <ul>
    15. 

  15. <li><a href="#n3">Runtime support (and potential problems)</a>
    16. 

  16. <li><a href="#n4">Why doesn't C++ inheritance work between modules?</a>
    17. 

  17. <li><a href="#n5">The SWIG runtime library</a>
    18. 

  18. <li><a href="#n6">A few dynamic loading gotchas</a>
    19. 

  19. </ul>
    20. 

  20. <li><a href="#n7">Dynamic Loading of C++ modules</a>
    21. 

  21. <li><a href="#n8">Inside the SWIG type-checker</a>
    22. 

  22. <ul>
    23. 

  23. <li><a href="#n9">Type equivalence</a>
    24. 

  24. <li><a href="#n10">Type casting</a>
    25. 

  25. <li><a href="#n11">Why a name based approach?</a>
    26. 

  26. <li><a href="#n12">Performance of the type-checker</a>
    27. 

  27. </ul>
    28. 

  28. </ul>
    29. 

  29. <!-- INDEX -->
    30. 

  30. 

  31. 

  32. 

  33. <b>Caution: This chapter is under repair!</b>
    34. 

  34. 

  35. <a name="n2"></a><H2>13.1 Creating multi-module packages</H2>
    36. 

  36. 

  37. 

  38. SWIG can be used to create packages consisting of many different modules. However, there are some technical aspects of doing this and techniques for managing the problem.<p>
    39. 

  39. <a name="n3"></a><H3>13.1.1 Runtime support (and potential problems)</H3>
    40. 

  40. 

  41. 

  42. All SWIG generated modules rely upon a small collection of functions that are used during run-time. These functions are primarily used for pointer type-checking, exception handling, and so on. When you run SWIG, these functions are included in the wrapper file (and declared as static). If you create a system consisting of many modules, each one will have an identical copy of these runtime libraries :<p>
    43. 

  43. <center><img src="ch11.1.png"></center><p>
    44. 

  44. <p>
    45. 

  45. This duplication of runtime libraries is usually harmless since there are no namespace conflicts and memory overhead is minimal. However, there is serious problem related to the fact that modules do not share type-information.  This is particularly a problem when working with C++ (as described next).<p>
    46. 

  46. <a name="n4"></a><H3>13.1.2 Why doesn't C++ inheritance work between modules?</H3>
    47. 

    48. 

  48. 

  49. Consider for a moment the following two interface files :<p>
    50. 

  50. <p>
    51. 

  51. <blockquote><pre>// File : a.i
    52. 

  52. %module a
    53. 

  53. 

  54. // Here is a base class
    55. 

  55. class a {
    56. 

  56. public:
    57. 

  57. 	a();
    58. 

  58. 	~a();
    59. 

  59. 	void foo(double);
    60. 

  60. };
    61. 

  61. 

  62. 

  63. // File : b.i
    64. 

  64. %module b
    65. 

  65. 

  66. // Here is a derived class
    67. 

  67. %import a.i                 // Gets definition of base class
    68. 

  68. 

  69. class b : public a {
    70. 

  70. public:
    71. 

  71. 	bar();
    72. 

  72. };
    73. 

  73. 

  74. </pre></blockquote>
    75. 

  75. When compiled into two separate modules, the code does not work properly. In fact, you get a type error such as the following:<p>
    76. 

  76. <p>
    77. 

  77. <blockquote><pre>
    78. 

  78. [beazley@guinness shadow]$ <b>python</b>
    79. 

  79. Python 1.4 (Jan 16 1997)  [GCC 2.7.2]
    80. 

  80. Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    81. 

  81. &gt;&gt;&gt; <b>from a import *</b>
    82. 

  82. &gt;&gt;&gt; <b>from b import *</b>
    83. 

  83. &gt;&gt;&gt; <b># Create a new "b"</b>
    84. 

  84. &gt;&gt;&gt; <b>b = new_b()</b>
    85. 

  85. &gt;&gt;&gt; <b># Call a function in the base class</b>
    86. 

  86. ...
    87. 

  87. &gt;&gt;&gt; <b>a_foo(b,3)</b>
    88. 

  88. Traceback (innermost last):
    89. 

  89.   File "&lt;stdin&gt;", line 1, in ?
    90. 

  90. TypeError: Type error in argument 1 of a_foo. Expected _a_p.
    91. 

  91. &gt;&gt;&gt;
    92. 

  92. </pre></blockquote>
    93. 

  93. <p>
    94. 

  94. However, from our class definitions we know that "b" is an "a" by inheritance and there should be no type-error. This problem is directly due to the lack of type-sharing between modules. If we look closely at the module modules created here, they look like this :<p>
    95. 

  95. <center><img src="ch11.2.png"></center><p>
    96. 

  96. <p>
    97. 

  97. The type information listed shows the acceptable values for various C datatypes.  In the "a" module, we see that "a" can only accept instances of itself.  In the "b" module, we see that "a"  can accept both "a" and "b" instances--which is correct given that a "b"  is an "a" by inheritance.<p>
    98. 

  98. <p>
    99. 

  99. Unfortunately, this problem is inherent in the method by which SWIG makes modules.  When we made the "a" module, we had no idea what derived classes might be used at a later time. However, it's impossible to produce the proper type information until after we know all of the derived classes.   A nice problem to be sure, but one that can be fixed by making all modules share a single copy of the SWIG run-time library.<p>
    100. 

  100. <a name="n5"></a><H3>13.1.3 The SWIG runtime library</H3>
    101. 

  101. 

  102. 

  103. To reduce overhead and to fix type-handling problems, it is possible to share the SWIG run-time functions between multiple modules. This requires the use of the SWIG runtime library which is optionally built during SWIG installation.  To use the runtime libraries, follow these steps:<p>
    104. 

  104. <p>
    105. 

  105. 1.  Build the SWIG run-time libraries.  The <tt>SWIG/Runtime</tt> directory contains a makefile for doing this. If successfully built, you will end up with 8 files that are usually installed in <tt>/usr/local/lib</tt>.<p>
    106. 

  106. <p>
    107. 

  107. <blockquote><pre>
    108. 

  108. libswigpl.a                  # Perl library (static)
    109. 

  109. libswigpl.so                 # Perl library (shared)
    110. 

  110. libswigpy.a                  # Python library (static)
    111. 

  111. libswigpy.so                 # Python library (shared)
    112. 

  112. libswigtcl8.a                # Tcl 8.x library (static)
    113. 

  113. libswigtcl8.so               # Tcl 8.x library (shared)
    114. 

  114. libswigrb.a                  # Ruby library (static)
    115. 

  115. libswigrb.so                 # Ruby library (shared)
    116. 

  116. </pre></blockquote>
    117. 

  117. <p>
    118. 

  118. Note that certain libraries may be missing due to missing packages or unsupported features (like dynamic loading) on your machine.<p>
    119. 

  119. <p>
    120. 

  120. 2.   Compile all SWIG modules using the <tt>-c</tt> option.   For example :<p>
    121. 

  121. <p>
    122. 

  122. <blockquote><pre>
    123. 

  123. % <b>swig -c -python a.i</b>
    124. 

  124. % <b>swig -c -python b.i</b>
    125. 

  125. </pre></blockquote>
    126. 

  126. The <tt>-c</tt> option tells SWIG to omit runtime support.  It's now up to you to provide it separately--which we will do using our libraries.<p>
    127. 

  127. <p>
    128. 

  128. 3.   Build SWIG modules by linking against the appropriate runtime libraries.<p>
    129. 

  129. <p>
    130. 

  130. <blockquote><pre>
    131. 

  131. % <b>swig -c -python a.i</b>
    132. 

  132. % <b>swig -c -python b.i</b>
    133. 

  133. % <b>gcc -c a_wrap.c b_wrap.c -I/usr/local/include</b>
    134. 

  134. % <b>ld -shared a_wrap.o b_wrap.o -lswigpy  -o a.so</b>
    135. 

  135. 

  136. </pre></blockquote>
    137. 

  137. or if building a new executable (static linking)<p>
    138. 

  138. <p>
    139. 

  139. <blockquote><pre>
    140. 

  140. % <b>swig -c -tcl -ltclsh.i a.i</b>
    141. 

  141. % <b>gcc a_wrap.c -I/usr/local/include -L/usr/local/lib -ltcl -lswigtcl -lm -o mytclsh</b>
    142. 

  142. 

  143. </pre></blockquote>
    144. 

  144. <p>
    145. 

  145. When completed you should now end up with a collection of modules like this:<p>
    146. 

  146. <center><img src="ch11.3.png"></center><p>
    147. 

  147. <p>
    148. 

  148. <p>
    149. 

  149. In this configuration, the runtime library manages all datatypes and other information between modules.   This management process is dynamic in nature--when new modules are loaded, they contribute information to the run-time system.   In the C++ world, one could incrementally load classes as needed.  As this process occurs, type information is updated and base-classes learn about derived classes as needed.<p>
    150. 

  150. <a name="n6"></a><H3>13.1.4 A few dynamic loading gotchas</H3>
    151. 

  151. 

  152. 

  153. When working with dynamic loading, it is critical to check that only one copy of the run-time library is being loaded into the system.  When working with <tt>.a</tt> library files, problems can sometimes occur so there are a few approaches to the problem.<p>
    154. 

  154. <p>
    155. 

  155. 1.  Rebuild the scripting language executable with the SWIG runtime library attached to it.   This is actually, fairly easy to do using SWIG.  For example :<p>
    156. 

  156. <p>
    157. 

  157. <blockquote><pre>%module mytclsh
    158. 

  158. %{
    159. 

  159. 

  160. static void *__embedfunc(void *a) { return a};
    161. 

  161. %}
    162. 

  162. 

  163. void *__embedfunc(void *);
    164. 

  164. %include tclsh.i
    165. 

  165. 

  166. </pre></blockquote>
    167. 

  167. <p>
    168. 

  168. Now, run SWIG and compile as follows:<p>
    169. 

  169. <p>
    170. 

  170. <blockquote><pre>
    171. 

  171. % <b>swig -c -tcl mytclsh.i</b>
    172. 

  172. % <b>gcc mytclsh_wrap.c -I/usr/local/include -L/usr/local/lib -ltcl -lswigtcl -ldl -lm \
    173. 

  173.       -o tclsh</b>
    174. 

  174. </pre></blockquote>
    175. 

  175. This produces a new executable "<tt>tclsh</tt>" that contains a copy of the SWIG runtime library. The weird <tt>__embedfunc()</tt> function is needed to force the functions in the runtime library to be included in the final executable.<p>
    176. 

  176. <p>
    177. 

  177. To make new dynamically loadable SWIG modules, simply compile as follows :<p>
    178. 

  178. <p>
    179. 

  179. <blockquote><pre>
    180. 

  180. % <b>swig -c -tcl example.i</b>
    181. 

  181. % <b>gcc -c example_wrap.c -I/usr/local/include</b>
    182. 

  182. % <b>ld -shared example_wrap.o -o example.so</b>
    183. 

  183. </pre></blockquote>
    184. 

  184. Linking against the <tt>swigtcl</tt> library is no longer necessary as all of the functions are now included in the <tt>tclsh</tt> executable and will be resolved when your module is loaded.<p>
    185. 

  185. <p>
    186. 

  186. 2.  Using shared library versions of the runtime library<p>
    187. 

  187. <p>
    188. 

  188. If supported on your machine, the runtime libraries will be built as shared libraries (indicated by a <tt>.so</tt>, <tt>.sl</tt>, or .<tt>dll</tt> suffix). To compile using the runtime libraries, you link process should look something like this:<p>
    189. 

  189. <blockquote><pre>
    190. 

  190. % <b>ld -shared swigtcl_wrap.o -o libswigtcl.so</b>             # Irix
    191. 

  191. % <b>gcc -shared swigtcl_wrap.o -o libswigtcl.so</b>            # Linux
    192. 

  192. % <b>ld -G swigtcl_wrap.o -o libswigtcl.so</b>                  # Solaris
    193. 

  193. </pre></blockquote>
    194. 

  194. In order for the <tt>libswigtcl.so</tt> library to work, it needs to be placed in a location where the dynamic loader can find it. Typically this is a system library directory (ie. <tt>/usr/local/lib</tt> or <tt>/usr/lib</tt>).<p>
    195. 

  195. <p>
    196. 

  196. When running with the shared libary version, you may get error messages such as the following:<p>
    197. 

  197. <p>
    198. 

  198. <blockquote><pre>Unable to locate libswigtcl.so</pre></blockquote>
    199. 

  199. This indicates that the loader was unable to find the shared libary at run-time. To find shared libaries, the loader looks through a collection of predetermined paths. If the <tt>libswigtcl.so</tt> file is not in any of these directories, it results in an error. On most machines, you can change the loader search path by changing the Unix environment variable <tt>LD_LIBRARY_PATH</tt>, e.g.<p>
    200. 

  200. <p>
    201. 

  201. <blockquote><pre>% <b>setenv LD_LIBRARY_PATH .:/home/beazley/packages/lib</b></pre></blockquote>
    202. 

  202. A somewhat better approach is to link your module with the proper path encoded. This is typically done using the `<tt>-rpath</tt>' or `<tt>-R</tt>' option to your linker (see the man page). For example:<p>
    203. 

  203. <p>
    204. 

  204. <blockquote><pre>% <b>ld -shared example_wrap.o example.o -rpath /home/beazley/packages/lib \
    205. 

  205.        -L/home/beazley/packages/lib -lswigtcl.so -o example.so</b>
    206. 

  206. </pre></blockquote>
    207. 

  207. The <tt>-rpath</tt> option encodes the location of shared libraries into your modules and gets around having to set the <tt>LD_LIBRARY_PATH</tt> variable.<p>
    208. 

  208. <p>
    209. 

  209. If all else fails, pull up the man pages for your linker and start playing around.<p>
    210. 

  210. <a name="n7"></a><H2>13.2 Dynamic Loading of C++ modules</H2>
    211. 

  211. 

  212. 

  213. Dynamic loading of C++ modules presents a special problem for many systems. This is because C++ modules often need additional supporting code for proper initialization and operation. Static constructors are also a bit of a problem.<p>
    214. 

  214. <p>
    215. 

  215. While the process of building C++ modules is, by no means, and exact science, here are a few rules of thumb to follow :<p>
    216. 

  216. <p>
    217. 

  217. <ul>
    218. 

  218. <li>Don't use static constructors if at all possible (not always avoidable).
    219. 

  219. <li>Try linking your module with the C++ compiler using a command like `c++ -shared'.  This often solves alot of problems.
    220. 

  220. <li>Sometimes it is necessary to link against special libraries.  For example, modules compiled with g++ often need to be linked against the <tt>libgcc.a</tt>, <tt>libg++.a</tt>, and <tt>libstdc++.a</tt> libraries.
    221. 

  221. <li>Read the compiler and linker man pages over and over until you have them memorized (this may not help in some cases however).
    222. 

  222. <li>Search articles on Usenet, particularly in <tt>comp.lang.tcl</tt>, <tt>comp.lang.perl</tt>, <tt>comp.lang.python</tt> and <tt>comp.lang.ruby</tt>. Building C++ modules is a common problem.
    223. 

  223. </ul>
    224. 

  224. <p>
    225. 

  225. The SWIG distribution contains some additional documentation about C++ modules in the Doc directory as well.<p>
    226. 

  226. <a name="n8"></a><H2>13.3 Inside the SWIG type-checker</H2>
    227. 

    228. 

    229. 

  229. The SWIG runtime type-checker plays a critical role in the correct operation of SWIG modules.   It not only checks the validity of pointer types, but also manages C++ inheritance, and performs proper type-casting of pointers when necessary.  This section provides some insight into what it does, how it works, and why it is the way it is.<p>
    230. 

    231. 

  231. <a name="n9"></a><H3>13.3.1 Type equivalence</H3>
    232. 

    233. 

    234. 

  234. SWIG uses a name-based approach to managing pointer datatypes. For example, if you are using a pointer like "<tt>double *</tt>", the type-checker will look for a particular string representation of that datatype such as "<tt>_double_p</tt>".   If no match is found, a type-error is reported.<p>
    235. 

  235. <p>
    236. 

  236. However, the matching process is complicated by the fact that datatypes may use a variety of different names.  For example, the following declarations<p>
    237. 

  237. <p>
    238. 

  238. <blockquote><pre>typedef double   Real;
    239. 

  239. typedef Real *   RealPtr;
    240. 

  240. typedef double   Float;
    241. 

    242. 

  242. </pre></blockquote>
    243. 

  243. define two sets of equivalent types :<p>
    244. 

  244. <p>
    245. 

  245. <blockquote><pre>{double, Real, Float}
    246. 

  246. {RealPtr, Real *}
    247. 

    248. 

  248. </pre></blockquote>
    249. 

  249. All of the types in each set are freely interchangable and the type-checker knows about the relationships by managing a table of equivalences such as the following :<p>
    250. 

  250. <blockquote><pre>
    251. 

  251. double    =&gt; { Real, Float }
    252. 

  252. Real      =&gt; { double, Float }
    253. 

  253. Float     =&gt; { double, Real }
    254. 

  254. RealPtr   =&gt; { Real * }
    255. 

  255. Real *    =&gt; { RealPtr }
    256. 

    257. 

  257. </pre></blockquote>
    258. 

  258. <p>
    259. 

  259. When you declare a function such as the following :<p>
    260. 

  260. <p>
    261. 

  261. <blockquote><pre>void foo(Real *a);
    262. 

    263. 

  263. </pre></blockquote>
    264. 

  264. SWIG first checks to see if the argument passed is a "<tt>Real *</tt>".   If not, it checks to see if it is any of the other equivalent types (<tt>double *</tt>, <tt>RealPtr</tt>, <tt>Float *</tt>).  If so, the value is accepted and no error occurs.<p>
    265. 

  265. <p>
    266. 

  266. Derived versions of the various datatypes are also legal.  For example, if you had a function like this,<p>
    267. 

  267. <p>
    268. 

  268. <blockquote><pre>void bar(Float ***a);
    269. 

    270. 

  270. </pre></blockquote>
    271. 

  271. The type-checker will accept pointers of type <tt>double ***</tt> and <tt>Real ***.</tt>  However, the type-checker does not always capture the full-range of possibilities.  For example, a datatype of `<tt>RealPtr **</tt>' is equivalent to a `<tt>Float ***</tt>' but would be flagged as a type error.   If you encounter this kind of problem, you can manually force SWIG to make an equivalence as follows:<p>
    272. 

  272. <p>
    273. 

  273. <blockquote><pre>// Tell the type checker that `Float_ppp' and `RealPtr_pp' are equivalent.
    274. 

  274. %init %{
    275. 

  275. 	SWIG_RegisterMapping("Float_ppp","RealPtr_pp",0);
    276. 

  276. %}
    277. 

  277. 

  278. </pre></blockquote>
    279. 

  279. Doing this should hardly ever be necessary (I have never encountered a case where this was necessary), but if all else fails, you can force the run-time type checker into doing what you want.<p>
    280. 

  280. <p>
    281. 

  281. Type-equivalence of C++ classes is handled in a similar manner, but is encoded in a manner to support inheritance.  For example, consider the following classes hierarchy :<p>
    282. 

  282. <p>
    283. 

  283. <blockquote><pre>class A { };
    284. 

  284. class B : public A { };
    285. 

  285. class C : public B { };
    286. 

  286. class D {};
    287. 

  287. class E : public C, public D {};
    288. 

  288. 

  289. </pre></blockquote>
    290. 

  290. The type-checker encodes this into the following sets :<p>
    291. 

  291. <p>
    292. 

  292. <blockquote><pre>A =&gt; { B, C, E }              "B isa A, C isa A, E isa A"
    293. 

  293. B =&gt; { C, E }                 "C isa B, E isa B"
    294. 

  294. C =&gt; { E }                    "E isa C"
    295. 

  295. D =&gt; { E }                    "E isa D"
    296. 

  296. E =&gt; { }
    297. 

  297. 

  298. </pre></blockquote>
    299. 

  299. The encoding reflects the class hierarchy. For example, any object of type "A" will also accept objects of type B,C, and E because these are all derived from A.  However, it is not legal to go the other way. For example, a function operating on a object from class E will not accept an object from class A.<p>
    300. 

  300. <a name="n10"></a><H3>13.3.2 Type casting</H3>
    301. 

  301. 

  302. 

  303. When working with C++ classes, SWIG needs to perform proper typecasting between derived and base classes.  This is particularly important when working with multiple inheritance.   To do this, conversion functions are created such as the following :<p>
    304. 

  304. <p>
    305. 

  305. <blockquote><pre>void *EtoA(void *ptr) {
    306. 

  306. 	E *in = (E *) ptr;
    307. 

  307. 	A *out = (A *) in;       // Cast using C++
    308. 

  308. 	return (void *) out;
    309. 

  309. }
    310. 

  310. 

  311. </pre></blockquote>
    312. 

  312. All pointers are internally represented as void *, but conversion functions are always invoked when pointer values are converted between base and derived classes in a C++ class hierarchy.<p>
    313. 

  313. 

  314. <a name="n11"></a><H3>13.3.3 Why a name based approach?</H3>
    315. 

  315. 

  316. 

  317. SWIG uses a name-based approach to type-checking for a number of reasons :<p>
    318. 

  318. <p>
    319. 

  319. <ul>
    320. 

  320. <li>One of SWIG's main uses is code development and debugging.   In this environment, the type name of an object turns out to be a useful piece of information in tracking down problems.
    321. 

  321. <li>In languages like Perl, the name of a datatype is used to determine things like packages and classes.    By using datatype names we get a natural mapping between C and Perl.
    322. 

  322. <li>I believe using the original names of datatypes is more intuitive than munging them into something completely different.
    323. 

  323. </ul>
    324. 

  324. <p>
    325. 

  325. An alternative to a name based scheme would be to generate type-signatures based on the structure of a datatype.   Such a scheme would result in perfect type-checking, but I think it would also result in a very confusing scripting language module.  For this reason, I see SWIG sticking with the name-based approach--at least for the foreseeable future.  <p>
    326. 

  326. <a name="n12"></a><H3>13.3.4 Performance of the type-checker</H3>
    327. 

  327. 

  328. 

  329. The type-checker performs the following steps when matching a datatype :<p>
    330. 

  330. <p>
    331. 

  331. 

  332. <dl>
    333. 

  333. <dt>1.	 Check a pointer against the type supplied in the original C declaration.  If there is a perfect match, we're done.
    334. 

  334. <dt>2.	 Check the supplied pointer against a cache of recently used datatypes.  
    335. 

  335. <dt>3.	 Search for a match against the full list of equivalent datatypes.
    336. 

  336. <dt>4.	 If not found, report an error.
    337. 

  337. 

  338. </dl>
    339. 

  339. <p>
    340. 

  340. Most well-structured C codes will find an exact match on the first attempt, providing the best possible performance.  For C++ codes, it is quite common to be passing various objects of a common base-class around between functions.   When base-class functions are invoked, it almost always results in a miscompare (because the type-checker is looking for the base-type).  In this case, we drop down to a small cache of recently used datatypes.   If we've used a pointer of the same type recently, it will be in the cache and we can match against it.    For tight loops, this results in about 10-15% overhead over finding a match on the first try.   Finally, as a last resort, we need to search the internal pointer tables for a match.  This involves a combination of hash table lookup and linear search.  If a match is found, it is placed into the cache and the result returned.  If not, we finally report a type-mismatch.<p>
    341. 

  341. <p>
    342. 

  342. As a rule of  thumb, C++ programs require somewhat more processing than C programs, but this seems to be avoidable.    Also, keep in mind that performance penalties in the type-checker don't necessarily translate into big penalties in the overall application.  Performance is most greatly affected by the efficiency of the target scripting language and the types of operations your C code is performing.<p>
    343. 

  343. <p>
    344. 

  344. <p>
    345. 

  345. 

  346. <p><hr>
    347. 

  347. 

  348. <address>SWIG 1.1 - Last Modified : Mon Aug  4 10:47:13 1997</address>
    349. 

  349. </body>
    350. 

  350. </html>
    351.