jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update the typemap documentation

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@7691 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
John Lenz 2005-10-20 01:02:43 +00:00
commit 7a6d5c1b7c
2 changed files with 5 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

3
SWIG/CHANGES.current
View file

@ -1,6 +1,9 @@
Version 1.3.27 (October 15, 2005) Version 1.3.27 (October 15, 2005)
================================= =================================
10/19/2005: wuzzeb
Update the Runtime Typemap documentation in Typemaps.html
10/18/2005: wuzzeb 10/18/2005: wuzzeb
Chicken: Chicken:
- Correctly handle %ignored classes - Correctly handle %ignored classes

42
SWIG/Doc/Manual/Typemaps.html
View file

@ -3005,7 +3005,7 @@ to have ONE <tt>swig_type_info</tt> for each type. If two modules both use the
second module loaded must lookup and use the swig_type_info structure from the module already loaded. second module loaded must lookup and use the swig_type_info structure from the module already loaded.
Because no dynamic memory is used and the circular dependencies of the Because no dynamic memory is used and the circular dependencies of the
casting information, loading the type information is somewhat tricky, and not explained here. casting information, loading the type information is somewhat tricky, and not explained here.
A complete description is in the <tt>common.swg</tt> file (and near the top of any generated file). A complete description is in the <tt>Lib/swiginit.swg</tt> file (and near the top of any generated file).
</p> </p>
<p> <p>
@ -3122,48 +3122,10 @@ information even if those datatypes never appear elsewhere in the
interface file. interface file.
</p> </p>
<p>
A final problem related to the type-checker is the conversion of types
in code that is external to the SWIG wrapper file. This situation is
somewhat rare in practice, but occasionally a programmer may want to
convert a typed pointer object into a C++ pointer somewhere else in
their program. The only problem is that the SWIG type descriptor
objects are only defined in the wrapper code and not normally
accessible.
</p>
<p>
To correctly deal with this situation, the following technique can be used:
</p>
<div class="code">
<pre>
/* Some non-SWIG file */
/* External declarations */
extern void *SWIG_TypeQuery(const char *);
extern int SWIG_ConvertPtr(PyObject *, void **ptr, void *descr);
void foo(PyObject *o) {
Foo *f;
static void *descr = 0;
if (!descr) {
descr = SWIG_TypeQuery("Foo *"); /* Get the type descriptor structure for Foo */
assert(descr);
}
if ((SWIG_ConvertPtr(o,(void **) &amp;f, descr) == -1)) {
abort();
}
...
}
</pre>
</div>
<p> <p>
Further details about the run-time type checking can be found in the documentation for Further details about the run-time type checking can be found in the documentation for
individual language modules. Reading the source code may also help. The file individual language modules. Reading the source code may also help. The file
<tt>swigrun.swg</tt> in the SWIG library contains all of the source code for <tt>Lib/swigrun.swg</tt> in the SWIG library contains all of the source code for
type-checking. This code is also included in every generated wrapped file so you type-checking. This code is also included in every generated wrapped file so you
probably just look at the output of SWIG to get a better sense for how types are probably just look at the output of SWIG to get a better sense for how types are
managed. managed.