*** empty log message ***
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@3553 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Dave Beazley
parent
a4f0fde1da
commit
d3922eb1e0
8 changed files with 479 additions and 59 deletions
277
swigweb/article_cpp.ht
Normal file
277
swigweb/article_cpp.ht
Normal file
|
|
@ -0,0 +1,277 @@
|
|||
Thoughts on the Insanity C++ Parsing
|
||||
|
||||
<h2>Thoughts on the Insanity of C++ Parsing</h2>
|
||||
|
||||
<center>
|
||||
<em>
|
||||
"Parsing C++ is simply too complex to do correctly." -- Anonymous
|
||||
</em>
|
||||
</center>
|
||||
<p>
|
||||
Author: David Beazley (beazley@cs.uchicago.edu)
|
||||
|
||||
<p>
|
||||
August 12, 2002
|
||||
|
||||
<p>
|
||||
A central goal of the SWIG project is to generate extension modules by
|
||||
parsing the contents of C++ header files. It's not too hard to come up
|
||||
with reasons why this might be useful---after all, if you've got
|
||||
several hundred class definitions, do you really want to go off and
|
||||
write a bunch of hand-crafted wrappers? No, of course not---you're
|
||||
busy and like everyone else, you've got better things to do with
|
||||
your time.
|
||||
|
||||
<p>
|
||||
Okay, so there are many reasons why parsing C++ would be nice.
|
||||
However, parsing C++ is also a nightmare. In fact, C++ would
|
||||
probably the last language that any normal person would choose to
|
||||
serve as an interface specification language. It's hard to parse,
|
||||
hard to analyze, and it involves all sorts
|
||||
of nasty little problems related to scoping, typenames, templates,
|
||||
access, and so forth. Because of this, most of the tools that claim
|
||||
to "parse" C++ don't. Instead, they parse a subset of the language
|
||||
that happens to match the C++ programming style used by the tool's
|
||||
creator (believe me, I know---this is how SWIG started). Not
|
||||
surprisingly, these tools tend to break down when presented with code
|
||||
that starts to challenge the capabilities of the C++ compiler.
|
||||
Needless to say, critics see this as opportunity to make bold claims
|
||||
such as "writing a C++ parser is folly" or "this whole approach is too
|
||||
hard to ever work correctly."
|
||||
|
||||
<p>
|
||||
Well, one does have to give the critics a little credit---writing a
|
||||
C++ parser certainly <em>is</em> hard and writing a parser that
|
||||
actually works correctly is even harder. However, these tasks are
|
||||
certainly not "impossible." After all, there would be no working C++
|
||||
compiler if such claims were true! Therefore, the question of whether
|
||||
or not a wrapper generator can parse C++ is clearly the wrong question
|
||||
to ask. Instead, the real question is whether or not a wrapper
|
||||
generation tool that parses C++ can actually do anything useful.
|
||||
|
||||
<p>
|
||||
<h3>The problem with using C++ as an interface definition language</h3>
|
||||
|
||||
If you cut through all of the low-level details of parsing, the primary
|
||||
problem of using C++ as an module specification language is that of
|
||||
ambiguity. Consider a declaration like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
void foo(double *x, int n);
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
If you look at this declaration, you can ask yourself the question,
|
||||
what is "x"? Is it a single input value? Is it an output value
|
||||
(modified by the function)? Is it an array? Is "n" somehow related?
|
||||
Perhaps the real problem in this example is that of expressing the
|
||||
programmer's intent. Yes, the function clearly accepts a pointer to
|
||||
some object and an integer, but the declaration does not contain
|
||||
enough additional information to determine the purpose of these
|
||||
parameters--information that could be useful in generating a suitable
|
||||
set of a wrappers.
|
||||
|
||||
<p>
|
||||
IDL compilers associated with popular component frameworks (e.g.,
|
||||
CORBA, COM, etc.) get around this problem by requiring interfaces to
|
||||
be precisely specified--input and output values are clearly indicated
|
||||
as such. Thus, one might adopt a similar approach and extend C++
|
||||
syntax with some special modifiers or qualifiers. For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
void foo(%output double *x, int n);
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
The problem with this approach is that it breaks from C++ syntax and
|
||||
it requires the user to annotate their input files (a task that C++
|
||||
wrapper generators are supposed to eliminate). Meanwhile, critics sit
|
||||
back and say "Ha! I told you C++ parsing would never work."
|
||||
|
||||
<p>
|
||||
Another problem with using C++ as an input language is that interface
|
||||
building often involves more than just blindly wrapping declarations. For instance,
|
||||
users might want to rename declarations, specify exception handling procedures,
|
||||
add customized code, and so forth. This suggests that a
|
||||
wrapper generator really needs to do
|
||||
more than just parse C++---it must give users the freedom to customize
|
||||
various aspects of the wrapper generation process. Again, things aren't
|
||||
looking too good for C++.
|
||||
|
||||
<p>
|
||||
<h3>The SWIG approach: pattern matching</h3>
|
||||
|
||||
SWIG takes a different approach to the C++ wrapping problem.
|
||||
Instead of trying to modify C++ with all sorts of little modifiers and
|
||||
add-ons, wrapping is largely controlled by a pattern matching mechanism that is
|
||||
built into the underlying C++ type system.
|
||||
|
||||
<p>
|
||||
One part of the pattern matcher is programmed to look for specific sequences of
|
||||
datatypes and argument names. These patterns, known as typemaps, are
|
||||
responsible for all aspects of data conversion. They work by simply attaching
|
||||
bits of C conversion code to specific datatypes and argument names in the
|
||||
input file. For example, a typemap might be used like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
%typemap(in) <b>double *items</b> {
|
||||
// Get an array from the input
|
||||
...
|
||||
}
|
||||
...
|
||||
void foo(<b>double *items</b>, int n);
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
With this approach, type and argument names are used as
|
||||
a basis for specifying customized wrapping behavior. For example, if a program
|
||||
always used an argument of <tt>double *items</tt> to refer to an
|
||||
array, SWIG can latch onto that and use it to provide customized
|
||||
processing. It is even possible to write pattern matching rules for
|
||||
sequences of arguments. For example, you could write the following:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
%typemap(in) (<b>double *items, int n</b>) {
|
||||
// Get an array of items. Set n to number of items
|
||||
...
|
||||
}
|
||||
...
|
||||
void foo(<b>double *items, int n</b>);
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
The precise details of typemaps are not so important (in fact, most of
|
||||
this pattern matching is hidden from SWIG users). What is important
|
||||
is that pattern matching allows customized data handling to be
|
||||
specified without breaking C++ syntax--instead, a user merely has to
|
||||
define a few patterns that get applied across the declarations that
|
||||
appear in C++ header files. In some sense, you might view this
|
||||
approach as providing customization through naming conventions rather than
|
||||
having to annotate arguments with extra qualifiers.
|
||||
|
||||
<p>
|
||||
The other pattern matching mechanism used by SWIG is a declaration annotator
|
||||
that is used to attach properties to specific declarations. A simple example of declaration
|
||||
annotation might be renaming. For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
%rename(cprint) print; // Rename all occurrences of 'print' to 'cprint'
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
A more advanced form of declaration matching would be exception handling.
|
||||
For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
%exception Foo::getitem(int) {
|
||||
try {
|
||||
$action
|
||||
} catch (std::out_of_range& e) {
|
||||
SWIG_exception(SWIG_IndexError,const_cast<char*>(e.what()));
|
||||
}
|
||||
}
|
||||
|
||||
...
|
||||
template<class T> class Foo {
|
||||
public:
|
||||
...
|
||||
T &getitem(int index); // Exception handling code attached
|
||||
...
|
||||
};
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
Like typemaps, declaration matching does not break from C++ syntax.
|
||||
Instead, a user merely specifies special processing rules in advance.
|
||||
These rules are then attached to any matching C++
|
||||
declaration that appears later in the input. This means that raw C++
|
||||
header files can often be parsed and customized with few, if any,
|
||||
modifications.
|
||||
|
||||
<h3>The SWIG difference</h2>
|
||||
|
||||
Pattern based approaches to wrapper code generation are not unique to SWIG.
|
||||
However, most prior efforts have based their pattern matching engines on simple
|
||||
regular-expression matching. The key difference between SWIG and these systems
|
||||
is that SWIG's customization features are fully integrated into the
|
||||
underlying C++ type system. This means that SWIG is able to deal with very
|
||||
complicated types of C/C++ code---especially code that makes heavy use of
|
||||
<tt>typedef</tt>, namespaces, aliases, class hierarchies, and more. To
|
||||
illustrate, consider some code like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
// A simple SWIG typemap
|
||||
%typemap(in) int {
|
||||
$1 = PyInt_AsLong($input);
|
||||
}
|
||||
|
||||
...
|
||||
// Some raw C++ code (included later)
|
||||
namespace X {
|
||||
typedef int Integer;
|
||||
|
||||
class _FooImpl {
|
||||
public:
|
||||
typedef Integer value_type;
|
||||
};
|
||||
typedef _FooImpl Foo;
|
||||
}
|
||||
|
||||
namespace Y = X;
|
||||
using Y::Foo;
|
||||
|
||||
class Bar : public Foo {
|
||||
};
|
||||
|
||||
void spam(Bar::value_type x);
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
If you trace your way through this example, you will find that the
|
||||
<tt>Bar::value_type</tt> argument to function <tt>spam()</tt> is
|
||||
really an integer. What's more, if you take a close look at the SWIG
|
||||
generated wrappers, you will find that the typemap pattern defined for
|
||||
<tt>int</tt> is applied to it--in other words, SWIG does exactly the right thing despite
|
||||
our efforts to make the code confusing.
|
||||
|
||||
<p>
|
||||
Similarly, declaration annotation is integrated into the type system
|
||||
and can be used to define properties that span inheritance hierarchies
|
||||
and more (in fact, there are many similarities between the operation of
|
||||
SWIG and tools developed for Aspect Oriented Programming).
|
||||
|
||||
<h3>What does this mean?</h3>
|
||||
|
||||
Pattern-based approaches allow wrapper generation tools to parse C++
|
||||
declarations and to provide a wide variety of high-level customization
|
||||
features. Although this approach is quite different than that found
|
||||
in a typical IDL, the use of patterns makes it possible to work from
|
||||
existing header files without having to make many (if any) changes to
|
||||
those files. Moreover, when the underlying pattern matching mechanism
|
||||
is integrated with the C++ type system, it is possible to build
|
||||
reliable wrappers to real software---even if that software is filled
|
||||
with namespaces, templates, classes, <tt>typedef</tt> declarations,
|
||||
pointers, and other bits of nastiness.
|
||||
|
||||
<h3>The bottom line</h3>
|
||||
|
||||
Not only is it possible to generate extension modules by parsing C++,
|
||||
it is possible to do so with real software and with a high degree of
|
||||
reliability. Don't believe me? Download SWIG-1.3.14 and try it for
|
||||
yourself.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -50,6 +50,16 @@ The password to the cvs account is 'cvs'.
|
|||
</pre>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<li>To build the system, follow these steps
|
||||
<p>
|
||||
<pre>
|
||||
% cd SWIG
|
||||
% ./autogen.sh
|
||||
% ./configure --prefix=/some/directory
|
||||
% make
|
||||
% make install
|
||||
</pre>
|
||||
</ol>
|
||||
|
||||
<b>Note:</b> The CVS repository is read-only so the system will not
|
||||
|
|
|
|||
|
|
@ -7,36 +7,14 @@ SWIG Documentation, Presentations, and Papers
|
|||
<H3>SWIG1.3</h3>
|
||||
<ul>
|
||||
|
||||
<li> <a href="Doc1.3/index.html">Development Documentation</a> for SWIG1.3.13.
|
||||
<li> <a href="Doc1.3/index.html">Development Documentation</a> for SWIG1.3.14.
|
||||
<li> Also available in <a href="swigdoc.pdf">PDF</a> and <a href="swigdoc.ps">postscript</a> (SWIG-1.3.11).
|
||||
</ul>
|
||||
|
||||
<h3>SWIG1.1</h3>
|
||||
<ul>
|
||||
<li> <a href="Doc1.1/HTML/Contents.html">Online Users Manual</a>.
|
||||
<p>
|
||||
<li> The latest version of the <a href="Doc1.1/PDF/SWIGManual.pdf">User Manual</a> (318 pages, Adobe PDF).
|
||||
<ul>
|
||||
<li> <a href="Doc1.1/PDF/Preface.pdf">Preface</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Introduction.pdf">Introduction</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Scripting.pdf">Scripting languages</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/SWIG.pdf">SWIG Basics</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Library.pdf">Multiple files and the SWIG library</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Documentation.pdf">Documentation system.</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Typemaps.pdf">Pointers, constraints, and typemaps</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Exceptions.pdf">Exception handling</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Perl5.pdf">Perl 5</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Python.pdf">Python</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Tcl.pdf">Tcl</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Advanced.pdf">Advanced topics</a> (PDF)
|
||||
<li> <a href="Doc1.1/PDF/Extending.pdf">Extending SWIG</a> (PDF)
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
<li> SWIG <a href="Doc1.1/PDF/Reference.pdf">Reference Manual</a> (PDF).
|
||||
<p>
|
||||
<li> Postscript versions of the documentation are available on the SWIG
|
||||
<a href="ftp://ftp.swig.org/pub">FTP</a> site.
|
||||
<li> Also available in <a href="Doc1.1/PDF/SWIGManual.pdf">PDF</a> (318 pages).
|
||||
</ul>
|
||||
|
||||
<h3> Online Papers about SWIG </h3>
|
||||
|
|
|
|||
|
|
@ -2,45 +2,188 @@ Guilty Parties
|
|||
|
||||
<p><img src="images/guilty.png" alt="Guilty Parties">
|
||||
|
||||
<p><b>The primaries</b>
|
||||
<p>
|
||||
<b>Active Developers</b>
|
||||
|
||||
<table cellpadding=0 cellspacing=8 width="100%" border=0>
|
||||
<tr>
|
||||
<td>
|
||||
<img src="images/Dave2.jpg"><br>
|
||||
<b>Dave Beazley (Chicago, Illinois).</b><br>
|
||||
SWIG core, type system, Python, Tcl, Perl.
|
||||
</td>
|
||||
<td>
|
||||
<img src="images/luigi.jpg"><br>
|
||||
<b>Luigi Ballabio (Milano, Italy).</b><br>
|
||||
Macintosh port, STL libraries, Python.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<img src="images/fulton3.jpg"><br>
|
||||
<b>William Fulton (Bath, UK).</b> <br>
|
||||
Java module.
|
||||
</td>
|
||||
<td>
|
||||
<img src="images/lyle.jpg"><br>
|
||||
<b>Lyle Johnson (Madison, Alabama).</b><br>
|
||||
Ruby module.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<img src="blank.jpg"><br>
|
||||
<b>Matthias Köppe (Magdeburg, Germany).</b> <br>
|
||||
Guile module.
|
||||
</td>
|
||||
<td>
|
||||
<img src="blank.jpg"><br>
|
||||
<b>Sam Liddicott (Wakefield, UK).</b> <br>
|
||||
PHP module.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<img src="blank.jpg"><br>
|
||||
<b>Marcelo Matus (Tuscon, AZ).</b> <br>
|
||||
Evil C++ testing.
|
||||
</td>
|
||||
<td>
|
||||
<img src="blank.jpg"><br>
|
||||
<b>Richard Palmer.</b> <br>
|
||||
PHP module.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<img src="blank.jpg"><br>
|
||||
<b>Jason Stewart (Albuquerque, New Mexico).</b> <br>
|
||||
Perl module.
|
||||
</td>
|
||||
<td>
|
||||
<img src="blank.jpg"><br>
|
||||
<b>Klaus Wiederänders (Vienna, Austria).</b> <br>
|
||||
XML module.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<img src="blank.jpg"><br>
|
||||
<b>Art Yerkes (Chicago, Illinois).</b> <br>
|
||||
OCAML module.
|
||||
</td>
|
||||
<td>
|
||||
<img src="images/yoshiki.jpg"><br>
|
||||
<b>Shibukawa Yoshiki (Tokyo, Japan).</b> <br>
|
||||
Japanese translation.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<p>
|
||||
<b>Students</b>
|
||||
<ul>
|
||||
<li>Dave Beazley, (a.k.a., "Mr. Swig")
|
||||
<li>William Fulton (Java)
|
||||
<li>Matthias Köppe (Guile)
|
||||
<li>Richard Palmer (PHP)
|
||||
<li>Lyle Johnson (Ruby)
|
||||
<li>Luigi Ballabio (Macintosh port)
|
||||
<li>Jason Stewart (Perl)
|
||||
<li>Thien-Thi Nguyen (Guile)
|
||||
<li>Loic Dachary (Perl)
|
||||
<li>Oleg Tolmatcev (Mzscheme)
|
||||
<li>Masaki Fukushima (Ruby)
|
||||
<li>Songyan Feng (Chicago).
|
||||
<li>Xinghua Shi (Chicago).
|
||||
<li>Jing Cao (Chicago).
|
||||
</ul>
|
||||
|
||||
<p><b>Aiding and Abetting</b>
|
||||
<p>
|
||||
<b>Major contributors</b>
|
||||
|
||||
<ul>
|
||||
<li>Edward Zimmermann (for DNS)
|
||||
<li>David Ascher (quality control).
|
||||
<li>John Buckman (original port to NT).
|
||||
<li>Kevin Butler (further NT support).
|
||||
<li>Dominique Dumont (Perl5 module debugging).
|
||||
<li>Pier Giorgio Esposito (Borland Makefiles).
|
||||
<li>David Fletcher (Perl5 shadow class design).
|
||||
<li>Gary Holt (Perl5 shadow class design)
|
||||
<li>Harco de Hilster (Java)
|
||||
<li>Dustin Mitchell.
|
||||
<li>Ian Cooke.
|
||||
<li>Hasan Baran Kovuk.
|
||||
<li>Thien-Thi Nguyen
|
||||
<li>Loic Dachary
|
||||
<li>Oleg Tolmatcev
|
||||
<li>Masaki Fukushima
|
||||
<li>Edward Zimmermann
|
||||
<li>David Ascher
|
||||
<li>John Buckman
|
||||
<li>Kevin Butler
|
||||
<li>Dominique Dumont
|
||||
<li>Pier Giorgio Esposito
|
||||
<li>David Fletcher
|
||||
<li>Gary Holt
|
||||
<li>Harco de Hilster
|
||||
<li>Dustin Mitchell
|
||||
<li>Ian Cooke
|
||||
<li>Hasan Baran Kovuk
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
<b>Bug reports and patches</b>
|
||||
<blockquote>
|
||||
Adam Hupp,
|
||||
Brad Clements,
|
||||
Brett Williams,
|
||||
Buck Hodges,
|
||||
Burkhard Kloss,
|
||||
Chia-Liang Kao,
|
||||
Craig Files,
|
||||
Dennis Marsa,
|
||||
Dieter Baron,
|
||||
Drake Diedrich,
|
||||
Fleur Diana Dragan,
|
||||
Gary Pennington,
|
||||
Geoffrey Hort,
|
||||
Gerald Williams,
|
||||
Greg Anderson,
|
||||
Greg Kochanski,
|
||||
Greg Troxel,
|
||||
Henry Rowley.
|
||||
Irina Kotlova,
|
||||
Israel Taller,
|
||||
James Bailey,
|
||||
Jim Fulton,
|
||||
Joel Reed,
|
||||
Jon Travis,
|
||||
Junio Hamano,
|
||||
Karl Forner,
|
||||
Keith Davidson,
|
||||
Krzysztof Kozminski,
|
||||
Larry Virden,
|
||||
Magnus Ljung,
|
||||
Marc Zonzon,
|
||||
Marcio Luis Teixeira
|
||||
Mark Howson,
|
||||
Micahel Scharf,
|
||||
Michel Sanner,
|
||||
Mike Romberg,
|
||||
Mike Simons,
|
||||
Mike Weiblen,
|
||||
Paul Brannan,
|
||||
Ram Bhamidipaty,
|
||||
Reinhard Fobbe,
|
||||
Rich Wales,
|
||||
Richard Salz,
|
||||
Robin Dunn,
|
||||
Roy Lecates,
|
||||
Rudy Albachten,
|
||||
Scott Drummonds
|
||||
Scott Michel,
|
||||
Shaun Lowry,
|
||||
Steve Galser,
|
||||
Tal Shalif,
|
||||
Tarn Weisner Burton,
|
||||
Tony Seward,
|
||||
Uwe Steinmann,
|
||||
Vadim Chugunov,
|
||||
Wyss Clemens,
|
||||
Zhong Ren.
|
||||
</blockquote>
|
||||
|
||||
<p><b>Friends</b>
|
||||
<ul>
|
||||
<li>The F street crew
|
||||
<li>Peter Lomdahl
|
||||
<li>Tim Germann
|
||||
<li>Chris Myers
|
||||
<li>John Schmidt
|
||||
<li>Tim Germann
|
||||
<li>Paul Dubois
|
||||
<li>Kurtis Bleeker
|
||||
<li>Larry Virden
|
||||
|
|
|
|||
|
|
@ -48,6 +48,8 @@ handling of overloaded functions added.
|
|||
<li>December 10, 2001. SWIG-1.3.10 released.
|
||||
<li>January 31, 2002. SWIG-1.3.11 released.
|
||||
<li>June 2, 2002. SWIG-1.3.12 released.
|
||||
<li>June 17, 2002. SWIG-1.3.13 released.
|
||||
<li>August 12, 2002. SWIG-1.3.14 released.
|
||||
</ul>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -24,6 +24,17 @@ noncommercial use.
|
|||
<li> <a href="http://swig.cs.uchicago.edu/cgi-bin/wiki.pl">SwigWiki!</a>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
<h3>SWIG-2.0 project</h3>
|
||||
|
||||
Essays related to the future of SWIG development and the ongoing
|
||||
development work.
|
||||
|
||||
<ul>
|
||||
<li> <a href="article_cpp.html">"Thoughts on the insanity of C++ Parsing"</a>. David Beazley, August 12, 2002.
|
||||
<li> <a href="future.html">"SWIG-1.3.12, SWIG-2.0, and Beyond"</a>. David Beazley, June 2, 2002.
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
<h3>News</h3>
|
||||
|
||||
|
|
|
|||
|
|
@ -32,27 +32,27 @@ The <a href ="http://www.python.org"> Python </a> homepage. <br>
|
|||
|
||||
<ul>
|
||||
The <a href="ftp://ftp.parc.xerox.com/pub/ilu/ilu.html"> ILU </a> homepage (Xerox PARC) <br>
|
||||
<a href="http://www.uni-frankfurt.de/~fp/Tools/tclobj"> TclObj </a> </br>
|
||||
<a href="http://www.fpx.de/fp/Software/tclobj"> TclObj </a> </br>
|
||||
<a href="http://www.amath.washington.edu/~lf/software/tcl++">Modular Tcl</a></br>
|
||||
<a href="http://lnc.usc.edu/~holt/matwrap/">Matwrap</a>. A wrapper
|
||||
generator for matrix languages. <br>
|
||||
<a href="http://www.river-bank.demon.co.uk/software">SIP</a>. A wrapper generator
|
||||
<a href="http://www.riverbankcomputing.co.uk/sip">SIP</a>. A wrapper generator
|
||||
for integrating C++ libraries with Python. <br>
|
||||
<a href="http://xfiles.llnl.gov/python.htm">CXX</a>. A C++ friendly extension API for Python.<br>
|
||||
<a href="http://xfiles.llnl.gov/python.htm">pyfort</a>. A wrapper generator for interfacing Fortran with Python.<br>
|
||||
<a href="http://cxx.sourceforge.net">CXX</a>. A C++ friendly extension API for Python.<br>
|
||||
<a href="http://pyfortran.sourceforge.net">pyfort</a>. A wrapper generator for interfacing Fortran with Python.<br>
|
||||
<a href="http://www.acl.lanl.gov/siloon">SILOON</a>. A wrapper generation tool
|
||||
with some ambitious goals for C++.<br>
|
||||
<a href="http://www9.informatik.uni-erlangen.de/eng/research/rendering/vision/itcl/">Itcl++</a>.
|
||||
A wrapper generator for interfacing C++ with [incr Tcl].<br>
|
||||
|
||||
<a href="http://www.hlla.is.tsukuba.ac.jp/~chiba">OpenC++</a>. A very cool compiler project that lets you crawl inside C++ parse trees and more. <br>
|
||||
<a href="http://www.hlla.is.tsukuba.ac.jp/~chiba/openc++.html">OpenC++</a>. A very cool compiler project that lets you crawl inside C++ parse trees and more. <br>
|
||||
<a href="http://www.stack.nl/~dimitri/doxygen">Doxygen</a>. Generate documentation and more for C/C++ programs.<br>
|
||||
<a href="http://www.cs.cmu.edu/~chrislee/Software/g-wrap/">G-Wrap</a>. A wrapper generator for interfacing C and Scheme (including Guile).<br>
|
||||
|
||||
<a href="http://cens.ioc.ee/projects/f2py2e">f2py</a>. An interface generator for binding Fortran and Python.<br>
|
||||
|
||||
<a href="http://www.boost.org/libs/python/doc/index.html">Boost Python Library</a>. Includes a powerful interface generator for wrapping C++ classes with a Python interface.<br>
|
||||
<a href="http://www.execpc.com/~deaven/Dave/Software/cxxwrap/">cxxwrap</a>. Java JNI wrapper code generator for C++.<br>
|
||||
<a href="http://www.deaven.net/~deaven/Software/cxxwrap/">cxxwrap</a>. Java JNI wrapper code generator for C++.<br>
|
||||
<a href="http://www.excelsior-usa.com/xfunction.html">xFunction</a>. Java native code access library.<br>
|
||||
<a href="http://www.gnu.org/software/gcc/java/index.html">GCJ</a>. Gnu Compiler for Java - Part of GCC 3.0 and later. C++ and Java can be easily mixed together - Java objects are C++ objects and all Java classes are C++ classes using CNI, the alternative to JNI.<br>
|
||||
<a href="http://inline.perl.org">Inline</a>. Perl programmers will definitely want to take a look at
|
||||
|
|
|
|||
|
|
@ -89,9 +89,8 @@ Turning C code into a Python module is also easy. Simply do the following (show
|
|||
|
||||
unix % swig -python example.i
|
||||
unix % gcc -c example.c example_wrap.c \
|
||||
-I/usr/local/include/python1.4 \
|
||||
-I/usr/local/lib/python1.4/config
|
||||
unix % ld -shared example.o example_wrap.o -o examplemodule.so
|
||||
-I/usr/local/include/python2.1
|
||||
unix % ld -shared example.o example_wrap.o -o _example.so
|
||||
</pre> </tt> </blockquote>
|
||||
|
||||
We can now use the Python module as follows :
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue