Merge from trunk
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2009-sploving@12905 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Vincent Couvert
commit
dd3db36b1a
321 changed files with 12114 additions and 8559 deletions
378
CHANGES.current
378
CHANGES.current
|
|
@ -5,6 +5,384 @@ See the RELEASENOTES file for a summary of changes in each release.
|
|||
Version 2.0.5 (in progress)
|
||||
===========================
|
||||
|
||||
2012-01-24: wsfulton
|
||||
Fix crash with bad regex - bug #3474250.
|
||||
|
||||
2012-01-24: wsfulton
|
||||
[Python] Add Python stepped slicing support to the STL wrappers (std::vector, std::list).
|
||||
Assigning to a slice, reading a slice and deleting a slice with steps now work.
|
||||
For example:
|
||||
|
||||
%template(vector_i) std::vector<int>
|
||||
|
||||
vi = vector_i(range(10))
|
||||
print list(vi)
|
||||
vi[1:4:2] = [111, 333]
|
||||
print list(vi)
|
||||
del vi[3:10:3]
|
||||
print list(vi)
|
||||
print list(vi[::-1])
|
||||
|
||||
gives (same behaviour as native Python sequences such as list):
|
||||
|
||||
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
|
||||
[0, 111, 2, 333, 4, 5, 6, 7, 8, 9]
|
||||
[0, 111, 2, 4, 5, 7, 8]
|
||||
[8, 7, 5, 4, 2, 111, 0]
|
||||
|
||||
2012-01-23: klickverbot
|
||||
[D] Correctly annotate function pointers with C linkage.
|
||||
[D] Exception and Error have become blessed names; removed d_exception_name test case.
|
||||
|
||||
2012-01-20: wsfulton
|
||||
[Python] Fix some indexing bugs in Python STL wrappers when the index is negative, eg:
|
||||
|
||||
%template(vector_i) std::vector<int>
|
||||
|
||||
iv=vector_i([0,1,2,3,4,5])
|
||||
iv[-7:]
|
||||
|
||||
now returns [0, 1, 2, 3, 4, 5] instead of [5].
|
||||
|
||||
vv[7:9] = [22,33]
|
||||
|
||||
now returns [0, 1, 2, 3, 4, 5, 22, 33] instead of "index out range" error.
|
||||
|
||||
Also fix some segfaults when replacing ranges, eg when il is a std::list wrapper:
|
||||
|
||||
il[0:2] = [11]
|
||||
|
||||
2012-01-17: wsfulton
|
||||
[Go] Fix forward class declaration within a class when used as a base.
|
||||
|
||||
2012-01-07: wsfulton
|
||||
[C#] Add support for %nspace when using directors.
|
||||
|
||||
2012-01-06: wsfulton
|
||||
[Java] Patch #3452560 from Brant Kyser - add support for %nspace when using directors.
|
||||
|
||||
2011-12-21: wsfulton
|
||||
The 'directorin' typemap now accepts $1, $2 etc expansions instead of having to use workarounds -
|
||||
$1_name, $2_name etc.
|
||||
|
||||
2011-12-20: wsfulton
|
||||
[Java] Add (char *STRING, size_t LENGTH) director typemaps.
|
||||
|
||||
2011-12-20: wsfulton
|
||||
[C#, Go, Java, D] Add support for the 'directorargout' typemap.
|
||||
|
||||
2011-12-20: wsfulton
|
||||
[Ocaml, Octave, PHP, Python, Ruby] Correct special variables in 'directorargout' typemap.
|
||||
This change will break any 'directorargout' typemaps you may have written. Please change:
|
||||
$result to $1
|
||||
$input to $result
|
||||
|
||||
Also fix the named 'directorargout' DIRECTOROUT typemaps for these languages which didn't
|
||||
previously compile and add in $1, $2 etc expansion.
|
||||
|
||||
*** POTENTIAL INCOMPATIBILITY ***
|
||||
|
||||
2011-12-10: talby
|
||||
[perl5] SWIG_error() now gets decorated with perl source file/line number.
|
||||
[perl5] error handling now conforms to public XS api (fixes perl v5.14 issue).
|
||||
|
||||
2011-12-10: wsfulton
|
||||
[Android/Java] Fix directors to compile on Android.
|
||||
|
||||
Added documentation and examples for Android.
|
||||
|
||||
2011-12-08: vadz
|
||||
Bug fix: Handle methods renamed or ignored in the base class correctly in the derived classes
|
||||
(they could be sometimes mysteriously not renamed or ignored there before).
|
||||
|
||||
2011-12-03: klickverbot
|
||||
[D] Fix exception glue code for newer DMD 2 versions.
|
||||
[D] Do not default to 32 bit glue code for DMD anymore.
|
||||
[D] Use stdc.config.c_long/c_ulong to represent C long types.
|
||||
|
||||
2011-12-01: szager
|
||||
[python] Fixed bug 3447426: memory leak in vector.__getitem__.
|
||||
|
||||
2011-11-30: wsfulton
|
||||
[R] Remove C++ comments from generated C code.
|
||||
|
||||
2011-11-27: olly
|
||||
[Python] Fix some warnings when compiling generated wrappers with
|
||||
certain GCC warning options (Debian bug #650246).
|
||||
|
||||
2011-11-28: wsfulton
|
||||
Fix #3433541 %typemap(in, numinputs=0) with 10+ arguments.
|
||||
|
||||
2011-11-28: olly
|
||||
[Perl] Fix warnings when compiling generated wrappers with certain
|
||||
GCC warning options (Debian bug #436711).
|
||||
|
||||
2011-11-28: olly
|
||||
[PHP] Update keyword list to include keywords added in PHP releases up to 5.3.
|
||||
|
||||
2011-11-25: wsfulton
|
||||
[C#] Provide an easy way to override the default visibility for the proxy class pointer
|
||||
constructors and getCPtr() method. The visibility is 'internal' by default and if multiple
|
||||
SWIG modules are being used and compiled into different assemblies, then they need to be
|
||||
'public' in order to use the constructor or getCPtr() method from a different assembly.
|
||||
Use the following macros to change the visibilities in the proxy and type wrapper class:
|
||||
|
||||
SWIG_CSBODY_PROXY(public, public, SWIGTYPE)
|
||||
SWIG_CSBODY_TYPEWRAPPER(public, public, public, SWIGTYPE)
|
||||
|
||||
[Java] Provide an easy way to override the default visibility for the proxy class pointer
|
||||
constructors and getCPtr() method. The visibility is 'protected' by default and if multiple
|
||||
SWIG modules are being used and compiled into different packages, then they need to be
|
||||
'public' in order to use the constructor or getCPtr() method from a different package.
|
||||
Use the following macros to change the visibilities in the proxy and type wrapper class:
|
||||
|
||||
SWIG_JAVABODY_PROXY(public, public, SWIGTYPE)
|
||||
SWIG_JAVABODY_TYPEWRAPPER(public, public, public, SWIGTYPE)
|
||||
|
||||
The default for Java has changed from public to protected for the proxy classes. Use the
|
||||
SWIG_JAVABODY_PROXY macro above to restore to the previous visibilities.
|
||||
|
||||
*** POTENTIAL INCOMPATIBILITY ***
|
||||
|
||||
2011-11-22: szager
|
||||
[python] Bug 3440044: #ifdef out SWIG_Python_NonDynamicSetAttr if -builtin
|
||||
isn't being used, to avoid unnecessary binary incompatibilities between
|
||||
python installations.
|
||||
|
||||
2011-11-17: wsfulton
|
||||
Bug fix: Remove root directory from directory search list in Windows.
|
||||
|
||||
2011-11-13: wsfulton
|
||||
[Ruby] Apply patch #3421876 from Robin Stocker to fix #3416818 - same class name in
|
||||
different namespaces confusion when using multiple modules.
|
||||
|
||||
2011-11-11: wsfulton
|
||||
Fix pcre-build.sh to work with non-compressed tarballs - problem reported by Adrian Blakely.
|
||||
|
||||
2011-11-04: szager
|
||||
[python] Bug 3429388: python unsigned integer handling on 32-bit architectures.
|
||||
|
||||
2011-11-03: wsfulton
|
||||
Expand special variables in typemap warnings, eg:
|
||||
|
||||
%typemap(in, warning="1000:Test warning for 'in' typemap for $1_type $1_name") int "..."
|
||||
|
||||
2011-11-01: wsfulton
|
||||
Fix named output typemaps not being used when the symbol uses a qualifier and contains
|
||||
a number, eg:
|
||||
|
||||
%typemap(out) double ABC::m1 "..."
|
||||
|
||||
2011-10-24: talby
|
||||
[perl5] SF bug #3423119 - overload dispatch stack corruption fix. Better, but more research
|
||||
is needed on a stable path for tail calls in XS.
|
||||
|
||||
Also, fix for large long longs in 32 bit perl.
|
||||
|
||||
2011-10-13: xavier98
|
||||
[octave] Allow Octave modules to be re-loaded after a "clear all".
|
||||
|
||||
2011-09-19: wsfulton
|
||||
Fix regression introduced in swig-2.0.1 reported by Teemu Ikonone leading to uncompilable code
|
||||
when using typedef and function pointer references, for example:
|
||||
|
||||
typedef int FN(const int &a, int b);
|
||||
void *typedef_call1(FN *& precallback, FN * postcallback);
|
||||
|
||||
2011-09-14: wsfulton
|
||||
[Lua] Patch #3408012 from Raman Gopalan - add support for embedded Lua (eLua)
|
||||
including options for targeting Lua Tiny RAM (LTR).
|
||||
|
||||
2011-09-14: wsfulton
|
||||
[C#] Add boost_intrusive_ptr.i library contribution from patch #3401571.
|
||||
|
||||
2011-09-13: wsfulton
|
||||
Add warnings for badly named destructors, eg:
|
||||
|
||||
struct KStruct {
|
||||
~NOT_KStruct() {}
|
||||
};
|
||||
|
||||
cpp_extend_destructors.i:92: Warning 521: Illegal destructor name ~NOT_KStruct. Ignored.
|
||||
|
||||
2011-09-13: wsfulton
|
||||
Fix %extend and destructors for templates. The destructor in %extend was not always wrapped,
|
||||
for example:
|
||||
|
||||
%extend FooT {
|
||||
~FooT() { delete $self; } // was not wrapped as expected
|
||||
};
|
||||
template<class T> class FooT {};
|
||||
%template(FooTi) FooT<int>;
|
||||
|
||||
2011-09-13: wsfulton
|
||||
Fix special variables such as "$decl" and "$fulldecl" in destructors to include the ~ character.
|
||||
|
||||
2011-09-10: talby
|
||||
[perl5] SF bug #1481958 - Improve range checking for integer types.
|
||||
Enhance li_typemaps_runme.pl
|
||||
|
||||
2011-09-08: wsfulton
|
||||
Fix %extend on typedef classes in a namespace using the typedef name, for example:
|
||||
namespace Space {
|
||||
%extend CStruct {
|
||||
...
|
||||
}
|
||||
typedef struct tagCStruct { ... } CStruct;
|
||||
}
|
||||
|
||||
2011-08-31: xavier98
|
||||
[octave] patches from Karl Wette: improvements to module loading behavior;
|
||||
added example of friend operator to operator example; fixed octave panic/crash in 3.0.5;
|
||||
documentation improvements
|
||||
|
||||
2011-08-30: szager
|
||||
[python] Bug 3400486, fix error signalling for built-in constructors.
|
||||
|
||||
2011-08-26: wsfulton
|
||||
[Go] Fix file/line number display for "gotype" when using typemap debugging options
|
||||
-tmsearch and -tmused.
|
||||
|
||||
2011-08-26: wsfulton
|
||||
[C#, D] Fix %callback which was generating uncompileable code.
|
||||
|
||||
2011-08-25: wsfulton
|
||||
Fix constructors in named typedef class declarations as reported by Gregory Bronner:
|
||||
|
||||
typedef struct A {
|
||||
A(){} // Constructor which was not accepted by SWIG
|
||||
B(){} // NOT a constructor --illegal, but was accepted by SWIG
|
||||
} B;
|
||||
|
||||
For C code, the fix now results in the use of 'struct A *' instead of just 'B *' in
|
||||
the generated code when wrapping members in A, but ultimately this does not matter, as
|
||||
they are the same thing.
|
||||
|
||||
2011-08-23: wsfulton
|
||||
Fix %newobject when used in conjunction with %feature("ref") as reported by Jan Becker. The
|
||||
code from the "ref" feature was not always being generated for the function specified by %newobject.
|
||||
Documentation for "ref" and "unref" moved from Python to the C++ chapter.
|
||||
|
||||
2011-08-22: szager
|
||||
[python] Fixed memory leak with --builtin option (bug 3385089).
|
||||
|
||||
2011-08-22: wsfulton
|
||||
[Lua] SF patch #3394339 from Torsten Landschoff - new option -nomoduleglobal to disable installing
|
||||
the module table into the global namespace. Require call also returns the module table instead
|
||||
of a string.
|
||||
|
||||
2011-08-12: wsfulton
|
||||
SF bug # 3333549 - %shared_ptr fixes when the type is a template using template parameters
|
||||
that are typedef'd to another type.
|
||||
|
||||
Also fixed %shared_ptr when template parameters have default values.
|
||||
|
||||
2011-08-09: xavier98
|
||||
Fix bug 3387394; Octave patches for 3.4.0 compatibility, etc. (from Karl Wette)
|
||||
|
||||
2011-08-04: wsfulton
|
||||
Add in $symname expansion for director methods.
|
||||
|
||||
2011-07-29: olly
|
||||
[PHP] Don't generate "return $r;" in cases where $r hasn't been set.
|
||||
This was basically harmless, except it generated a PHP E_NOTICE if
|
||||
the calling code had enabled them.
|
||||
|
||||
2011-07-26: wsfulton
|
||||
Fix scoping of forward class declarations nested within a class (for C++). Previously the symbol
|
||||
was incorrectly put into the outer namespace, eg
|
||||
|
||||
namespace std {
|
||||
template<class Key, class T> struct map {
|
||||
class iterator;
|
||||
}
|
||||
}
|
||||
|
||||
iterator was scoped as std::iterator, but now it is correctly std::map<Key, T>::iterator;
|
||||
|
||||
Also fixed is %template and template parameters that are a typedef when the template contains
|
||||
default template parameters, eg:
|
||||
|
||||
namespace Std {
|
||||
template<class Key, class T, class C = int> struct Map {
|
||||
typedef Key key_type;
|
||||
typedef T mapped_type;
|
||||
}
|
||||
}
|
||||
tyepdef double DOUBLE;
|
||||
%typemap(MM) Std::Map<int, DOUBLE>;
|
||||
|
||||
All symbols within Map will be resolved correctly, eg key_type and mapped_type no matter if the
|
||||
wrapped code uses Std::Map<int, double> or std::Map<int, DOUBLE> or Std::Map<int, double, int>
|
||||
|
||||
Also fixes bug #3378145 - regression introduced in 2.0.4 - %template using traits.
|
||||
|
||||
2011-07-20 szager
|
||||
[python] Fix closure for tp_call slot.
|
||||
|
||||
2011-07-16: wsfulton
|
||||
[python] Fix director typemap using PyObject *.
|
||||
|
||||
2011-07-13: szager
|
||||
[python] SF patch #3365908 - Add all template parameters to map support code in std_map.i
|
||||
|
||||
2011-07-13: szager
|
||||
[python] Fix for bug 3324753: %rename member variables with -builtin.
|
||||
|
||||
2011-07-01: wsfulton
|
||||
Fix some scope and symbol lookup problems when template default parameters are being
|
||||
used with typedef. For example:
|
||||
|
||||
template<typename XX, typename TT = SomeType> struct Foo {
|
||||
typedef XX X;
|
||||
typedef TT T;
|
||||
};
|
||||
template<typename TT> struct UsesFoo {
|
||||
void x(typename Foo<TT>::T, typename Foo<TT>::X);
|
||||
};
|
||||
|
||||
Also fixes use of std::vector<int>::size_type for Python as reported by Aubrey Barnard.
|
||||
|
||||
2011-06-23: olly
|
||||
[PHP] Fix director code to work when PHP is built with ZTS enabled,
|
||||
which is the standard configuration on Microsoft Windows.
|
||||
|
||||
2011-06-21: mutandiz
|
||||
[allegrocl]
|
||||
- various small tweaks and bug fixes.
|
||||
- Avoid name conflicts between smart pointer wrappers and the wrappers for
|
||||
the actual class.
|
||||
- Fix default typemaps for C bindings, which were incorrectly attempting to
|
||||
call non-existent destructors on user-defined types.
|
||||
- New feature, feature:aclmixins, for adding superclass to the foreign class
|
||||
wrappers.
|
||||
- Improve longlong typemaps.
|
||||
|
||||
2011-06-19: wsfulton
|
||||
Fix incorrect typemaps being used for a symbol within a templated type, eg:
|
||||
A<int>::value_type would incorrectly use a typemap for type A.
|
||||
|
||||
2011-06-18: olly
|
||||
[Tcl] Fix variable declarations in middle of blocks which isn't
|
||||
permitted in C90 (issue probably introduced in 2.0.3 by patch #3224663).
|
||||
Reported by Paul Obermeier in SF#3288586.
|
||||
|
||||
2011-06-17: wsfulton
|
||||
[Java] SF #3312505 - slightly easier to wrap char[] or char[ANY] with a Java byte[]
|
||||
using arrays_java.i.
|
||||
|
||||
2011-06-13: wsfulton
|
||||
[Ruby, Octave] SF #3310528 Autodoc fixes similar to those described below for Python.
|
||||
|
||||
2011-06-10: wsfulton
|
||||
[Python] Few subtle bugfixes in autodoc documentation generation,
|
||||
- Unnamed argument names fix for autodoc levels > 0.
|
||||
- Display of template types fixed for autodoc levels > 1.
|
||||
- Fix SF #3310528 - display of typedef structs for autodoc levels > 1.
|
||||
- Add missing type for self for autodoc levels 1 and 3.
|
||||
- autodoc levels 2 and 3 documented.
|
||||
- Minor tweaks to autodoc style to conform with PEP8.
|
||||
|
||||
2011-05-30: olly
|
||||
[PHP] Fix handling of directors when -prefix is used.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,6 +54,7 @@ Past SWIG developers and major contributors include:
|
|||
Duncan Temple Lang (R)
|
||||
Miklos Vajna <vmiklos@frugalware.org> (PHP directors)
|
||||
Mark Gossage (mark@gossage.cjb.net) (Lua)
|
||||
Raman Gopalan (ramangopalan@gmail.com) (eLua)
|
||||
Gonzalo Garramuno (ggarra@advancedsl.com.ar) (Ruby, Ruby's UTL)
|
||||
John Lenz (Guile, MzScheme updates, Chicken module, runtime system)
|
||||
Baozeng Ding <sploving1@163.com> (Scilab)
|
||||
|
|
|
|||
749
Doc/Manual/Android.html
Normal file
749
Doc/Manual/Android.html
Normal file
|
|
@ -0,0 +1,749 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG and Android</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Android"></a>18 SWIG and Android</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#Android_overview">Overview</a>
|
||||
<li><a href="#Android_examples">Android examples</a>
|
||||
<ul>
|
||||
<li><a href="#Android_examples_intro">Examples introduction</a>
|
||||
<li><a href="#Android_example_simple">Simple C example</a>
|
||||
<li><a href="#Android_example_class">C++ class example</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
|
||||
|
||||
<p>
|
||||
This chapter describes SWIG's support of Android.
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
<H2><a name="Android_overview"></a>18.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
The Android chapter is fairly short as support for Android is the same as for Java, where the Java Native Interface (JNI) is
|
||||
used to call from Android Java into C or C++ compiled code.
|
||||
Everything in the <a href="Java.html">Java chapter</a> applies to generating code for access from Android Java code.
|
||||
This chapter contains a few Android specific notes and examples.
|
||||
</p>
|
||||
|
||||
<H2><a name="Android_examples"></a>18.2 Android examples</H2>
|
||||
|
||||
|
||||
<H3><a name="Android_examples_intro"></a>18.2.1 Examples introduction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The examples require the the <a href="http://developer.android.com/sdk/index.html">Android SDK</a> and <a href="http://developer.android.com/sdk/ndk/index.html">Android NDK</a> which can be installed as per instructions in the links.
|
||||
The Eclipse version is not required for these examples as just the command line tools are used (shown for Linux as the host, but Windows will be very similar, if not identical in most places).
|
||||
Add the SDK tools and NDK tools to your path and create a directory somewhere for your Android projects (adjust PATH as necessary to where you installed the tools):
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ export PATH=$HOME/android/android-sdk-linux_x86/tools:$HOME/android/android-sdk-linux_x86/platform-tools:$HOME/android/android-ndk-r6b:$PATH
|
||||
$ mkdir AndroidApps
|
||||
$ cd AnrdoidApps
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The examples use a target id of 1. This might need changing depending on your setup.
|
||||
After installation of the Android SDK, the available target ids can be viewed by running the command below.
|
||||
Please adjust the id to suit your target device.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ android list targets
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The following examples are shipped with SWIG under the Examples/android directory and include a Makefile to build and install each example.
|
||||
</p>
|
||||
|
||||
<H3><a name="Android_example_simple"></a>18.2.2 Simple C example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
This simple C example shows how to call a C function as well as read and modify a global variable.
|
||||
First we'll create and build a pure Java Android app. Afterwards the JNI code will be generated by SWIG and built into the app.
|
||||
First create and build an app called <tt>SwigSimple</tt> in a subdirectory called <tt>simple</tt> using the commands below.
|
||||
Adjust the <tt>--target</tt> id as mentioned earlier in the <a href="Android.html#Android_examples_intro">Examples introduction</a>.
|
||||
<a href="http://developer.android.com/guide/developing/projects/projects-cmdline.html">Managing Projects from the Command Line</a> on the Android developer's site is a useful reference for these steps.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ android create project --target 1 --name SwigSimple --path ./simple --activity SwigSimple --package org.swig.simple
|
||||
$ cd simple
|
||||
$ ant debug
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Modify <tt>src/org/swig/simple/SwigSimple.java</tt> from the default to:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
package org.swig.simple;
|
||||
|
||||
import android.app.Activity;
|
||||
import android.os.Bundle;
|
||||
import android.view.View;
|
||||
import android.widget.Button;
|
||||
import android.widget.TextView;
|
||||
import android.widget.ScrollView;
|
||||
import android.text.method.ScrollingMovementMethod;
|
||||
|
||||
public class SwigSimple extends Activity
|
||||
{
|
||||
TextView outputText = null;
|
||||
ScrollView scroller = null;
|
||||
|
||||
/** Called when the activity is first created. */
|
||||
@Override
|
||||
public void onCreate(Bundle savedInstanceState)
|
||||
{
|
||||
super.onCreate(savedInstanceState);
|
||||
setContentView(R.layout.main);
|
||||
|
||||
outputText = (TextView)findViewById(R.id.OutputText);
|
||||
outputText.setText("Press 'Run' to start...\n");
|
||||
outputText.setMovementMethod(new ScrollingMovementMethod());
|
||||
|
||||
scroller = (ScrollView)findViewById(R.id.Scroller);
|
||||
}
|
||||
|
||||
public void onRunButtonClick(View view)
|
||||
{
|
||||
outputText.append("Started...\n");
|
||||
nativeCall();
|
||||
outputText.append("Finished!\n");
|
||||
|
||||
// Ensure scroll to end of text
|
||||
scroller.post(new Runnable() {
|
||||
public void run() {
|
||||
scroller.fullScroll(ScrollView.FOCUS_DOWN);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// TODO
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The above simply adds a <i>Run</i> button and scrollable text view as the GUI aspects of the program.
|
||||
The associated resources need to be created, modify <tt>res/layout/main.xml</tt> as follows:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
android:orientation="vertical"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<Button
|
||||
android:id="@+id/RunButton"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
android:text="Run..."
|
||||
android:onClick="onRunButtonClick"
|
||||
/>
|
||||
<ScrollView
|
||||
android:id="@+id/Scroller"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<TextView
|
||||
android:id="@+id/OutputText"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
/>
|
||||
</ScrollView>
|
||||
</LinearLayout>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Rebuild the project with your changes:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ant debug
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Although there are no native function calls in the code, yet, you may want to check that this simple pure
|
||||
Java app runs before adding in the native calls.
|
||||
First, set up your Android device for hardware debugging, see <a href="http://developer.android.com/guide/developing/device.html">Using hardware devices</a> on the Android developer's site.
|
||||
When complete your device should be listed in those attached, something like:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ adb devices
|
||||
List of devices attached
|
||||
A32-6DBE0001-9FF80000-015D62C3-02018028 device
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
This means you are now ready to install the application...
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ adb install bin/SwigSimple-debug.apk
|
||||
95 KB/s (4834 bytes in 0.049s)
|
||||
pkg: /data/local/tmp/SwigSimple-debug.apk
|
||||
Success
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The newly installed 'SwigSimple' app will be amongst all your other applications on the home screen. Run the app and it will show a <i>Run</i> button text box below it.
|
||||
Press the <i>Run</i> button to see the simple text output.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The application can be uninstalled like any other application and in fact must be uninstalled before installing an updated version. Uninstalling is quite easy too from your host computer:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ adb uninstall org.swig.simple
|
||||
Success
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Now that you have a pure Java Android app working, let's add some JNI code generated from SWIG.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First create a <tt>jni</tt> subdirectory and then create some C source code in <tt>jni/example.c</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.c */
|
||||
|
||||
/* A global variable */
|
||||
double Foo = 3.0;
|
||||
|
||||
/* Compute the greatest common divisor of positive integers */
|
||||
int gcd(int x, int y) {
|
||||
int g;
|
||||
g = y;
|
||||
while (x > 0) {
|
||||
g = x;
|
||||
x = y % x;
|
||||
y = g;
|
||||
}
|
||||
return g;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Create a SWIG interface file for this C code, <tt>jni/example.i</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%inline %{
|
||||
extern int gcd(int x, int y);
|
||||
extern double Foo;
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Invoke SWIG as follows:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ swig -java -package org.swig.simple -outdir src/org/swig/simple -o jni/example_wrap.c jni/example.i
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
SWIG generates the following files:
|
||||
</p>
|
||||
<ul>
|
||||
<li><tt>src/org/swig/simple/exampleJNI.java</tt></li>
|
||||
<li><tt>src/org/swig/simple/example.java</tt></li>
|
||||
<li><tt>jni/example_wrap.c</tt></li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Next we need to create a standard Android NDK build system file <tt>jni/Android.mk</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.c example.c
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
See the <a href="http://developer.android.com/sdk/ndk/index.html">Android NDK documentation</a> for more on the NDK build system and getting started with the NDK.
|
||||
A simple invocation of ndk-build will compile the .c files and generate a shared object/system library. Output will be similar to:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ndk-build
|
||||
Compile thumb : example <= example_wrap.c
|
||||
Compile thumb : example <= example.c
|
||||
SharedLibrary : libexample.so
|
||||
Install : libexample.so => libs/armeabi/libexample.so
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Now that the C JNI layer has been built, we can write Java code to call into the this layer.
|
||||
Modify the <tt>nativeCall</tt> method in <tt>src/org/swig/simple/SwigSimple.java</tt> to call the JNI code as follows and add the static constructor to load the system library containing the compiled JNI C code:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// Call our gcd() function
|
||||
|
||||
int x = 42;
|
||||
int y = 105;
|
||||
int g = example.gcd(x,y);
|
||||
outputText.append("The greatest common divisor of " + x + " and " + y + " is " + g + "\n");
|
||||
|
||||
// Manipulate the Foo global variable
|
||||
|
||||
// Output its current value
|
||||
double foo = example.getFoo();
|
||||
outputText.append("Foo = " + foo + "\n");
|
||||
|
||||
// Change its value
|
||||
example.setFoo(3.1415926);
|
||||
|
||||
// See if the change took effect
|
||||
outputText.append("Foo = " + example.getFoo() + "\n");
|
||||
|
||||
// Restore value
|
||||
example.setFoo(foo);
|
||||
}
|
||||
|
||||
/** static constructor */
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Compile the Java code as usual, uninstall the old version of the app if still installed and re-install the new app:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ant debug
|
||||
$ adb uninstall org.swig.simple
|
||||
$ adb install bin/SwigSimple-debug.apk
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Run the app again and this time you will see the output pictured below, showing the result of calls into the C code:
|
||||
</p>
|
||||
|
||||
<center><img src="android-simple.png" alt="Android screenshot of SwigSimple example"></center>
|
||||
|
||||
|
||||
<H3><a name="Android_example_class"></a>18.2.3 C++ class example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The steps for calling C++ code are almost identical to those in the previous C code example.
|
||||
All the steps required to compile and use a simple hierarchy of classes for shapes are shown in this example.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First create an Android project called <tt>SwigClass</tt> in a subdirectory called <tt>class</tt>.
|
||||
The steps below create and build a the JNI C++ app.
|
||||
Adjust the <tt>--target</tt> id as mentioned earlier in the <a href="Android.html#Android_examples_intro">Examples introduction</a>.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ android create project --target 1 --name SwigClass --path ./class --activity SwigClass --package org.swig.classexample
|
||||
$ cd class
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Now create a <tt>jni</tt> subdirectory and then create a C++ header file <tt>jni/example.h</tt> which defines our
|
||||
hierarchy of shape classes:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.h */
|
||||
|
||||
class Shape {
|
||||
public:
|
||||
Shape() {
|
||||
nshapes++;
|
||||
}
|
||||
virtual ~Shape() {
|
||||
nshapes--;
|
||||
};
|
||||
double x, y;
|
||||
void move(double dx, double dy);
|
||||
virtual double area(void) = 0;
|
||||
virtual double perimeter(void) = 0;
|
||||
static int nshapes;
|
||||
};
|
||||
|
||||
class Circle : public Shape {
|
||||
private:
|
||||
double radius;
|
||||
public:
|
||||
Circle(double r) : radius(r) { };
|
||||
virtual double area(void);
|
||||
virtual double perimeter(void);
|
||||
};
|
||||
|
||||
class Square : public Shape {
|
||||
private:
|
||||
double width;
|
||||
public:
|
||||
Square(double w) : width(w) { };
|
||||
virtual double area(void);
|
||||
virtual double perimeter(void);
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
and create the implementation in the <tt>jni/example.cpp</tt> file:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.cpp */
|
||||
|
||||
#include "example.h"
|
||||
#define M_PI 3.14159265358979323846
|
||||
|
||||
/* Move the shape to a new location */
|
||||
void Shape::move(double dx, double dy) {
|
||||
x += dx;
|
||||
y += dy;
|
||||
}
|
||||
|
||||
int Shape::nshapes = 0;
|
||||
|
||||
double Circle::area(void) {
|
||||
return M_PI*radius*radius;
|
||||
}
|
||||
|
||||
double Circle::perimeter(void) {
|
||||
return 2*M_PI*radius;
|
||||
}
|
||||
|
||||
double Square::area(void) {
|
||||
return width*width;
|
||||
}
|
||||
|
||||
double Square::perimeter(void) {
|
||||
return 4*width;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Create a SWIG interface file for this C++ code in <tt>jni/example.i</tt>:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
|
||||
/* Let's just grab the original header file here */
|
||||
%include "example.h"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Invoke SWIG as follows, note that the -c++ option is required for C++ code:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ swig -c++ -java -package org.swig.classexample -outdir src/org/swig/classexample -o jni/example_wrap.cpp jni/example.i
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
SWIG generates the following files:
|
||||
</p>
|
||||
<ul>
|
||||
<li><tt>src/org/swig/classexample/Square.java</tt></li>
|
||||
<li><tt>src/org/swig/classexample/exampleJNI.java</tt></li>
|
||||
<li><tt>src/org/swig/classexample/example.java</tt></li>
|
||||
<li><tt>src/org/swig/classexample/Circle.java</tt></li>
|
||||
<li><tt>src/org/swig/classexample/Shape.java</tt></li>
|
||||
<li><tt>jni/example_wrap.cpp</tt></li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Next we need to create an Android NDK build system file for compiling the C++ code <tt>jni/Android.mk</tt>.
|
||||
The <tt>-frtti</tt> compiler flag isn't strictly needed for this example, but is needed for any code that uses C++ RTTI:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.cpp example.cpp
|
||||
LOCAL_CFLAGS := -frtti
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<p>
|
||||
A simple invocation of ndk-build will compile the .cpp files and generate a shared object/system library. Output will be similar to:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ndk-build
|
||||
Compile++ thumb : example <= example_wrap.cpp
|
||||
Compile++ thumb : example <= example.cpp
|
||||
StaticLibrary : libstdc++.a
|
||||
SharedLibrary : libexample.so
|
||||
Install : libexample.so => libs/armeabi/libexample.so
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Now that the C JNI layer has been built, we can write Java code to call into this layer.
|
||||
Modify <tt>src/org/swig/classexample/SwigClass.java</tt> from the default to:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
package org.swig.classexample;
|
||||
|
||||
import android.app.Activity;
|
||||
import android.os.Bundle;
|
||||
import android.view.View;
|
||||
import android.widget.Button;
|
||||
import android.widget.TextView;
|
||||
import android.widget.ScrollView;
|
||||
import android.text.method.ScrollingMovementMethod;
|
||||
|
||||
public class SwigClass extends Activity
|
||||
{
|
||||
TextView outputText = null;
|
||||
ScrollView scroller = null;
|
||||
|
||||
/** Called when the activity is first created. */
|
||||
@Override
|
||||
public void onCreate(Bundle savedInstanceState)
|
||||
{
|
||||
super.onCreate(savedInstanceState);
|
||||
setContentView(R.layout.main);
|
||||
|
||||
outputText = (TextView)findViewById(R.id.OutputText);
|
||||
outputText.setText("Press 'Run' to start...\n");
|
||||
outputText.setMovementMethod(new ScrollingMovementMethod());
|
||||
|
||||
scroller = (ScrollView)findViewById(R.id.Scroller);
|
||||
}
|
||||
|
||||
public void onRunButtonClick(View view)
|
||||
{
|
||||
outputText.append("Started...\n");
|
||||
nativeCall();
|
||||
outputText.append("Finished!\n");
|
||||
|
||||
// Ensure scroll to end of text
|
||||
scroller.post(new Runnable() {
|
||||
public void run() {
|
||||
scroller.fullScroll(ScrollView.FOCUS_DOWN);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// ----- Object creation -----
|
||||
|
||||
outputText.append( "Creating some objects:\n" );
|
||||
Circle c = new Circle(10);
|
||||
outputText.append( " Created circle " + c + "\n");
|
||||
Square s = new Square(10);
|
||||
outputText.append( " Created square " + s + "\n");
|
||||
|
||||
// ----- Access a static member -----
|
||||
|
||||
outputText.append( "\nA total of " + Shape.getNshapes() + " shapes were created\n" );
|
||||
|
||||
// ----- Member data access -----
|
||||
|
||||
// Notice how we can do this using functions specific to
|
||||
// the 'Circle' class.
|
||||
c.setX(20);
|
||||
c.setY(30);
|
||||
|
||||
// Now use the same functions in the base class
|
||||
Shape shape = s;
|
||||
shape.setX(-10);
|
||||
shape.setY(5);
|
||||
|
||||
outputText.append( "\nHere is their current position:\n" );
|
||||
outputText.append( " Circle = (" + c.getX() + " " + c.getY() + ")\n" );
|
||||
outputText.append( " Square = (" + s.getX() + " " + s.getY() + ")\n" );
|
||||
|
||||
// ----- Call some methods -----
|
||||
|
||||
outputText.append( "\nHere are some properties of the shapes:\n" );
|
||||
Shape[] shapes = {c,s};
|
||||
for (int i=0; i<shapes.length; i++)
|
||||
{
|
||||
outputText.append( " " + shapes[i].toString() + "\n" );
|
||||
outputText.append( " area = " + shapes[i].area() + "\n" );
|
||||
outputText.append( " perimeter = " + shapes[i].perimeter() + "\n" );
|
||||
}
|
||||
|
||||
// Notice how the area() and perimeter() functions really
|
||||
// invoke the appropriate virtual method on each object.
|
||||
|
||||
// ----- Delete everything -----
|
||||
|
||||
outputText.append( "\nGuess I'll clean up now\n" );
|
||||
|
||||
// Note: this invokes the virtual destructor
|
||||
// You could leave this to the garbage collector
|
||||
c.delete();
|
||||
s.delete();
|
||||
|
||||
outputText.append( Shape.getNshapes() + " shapes remain\n" );
|
||||
outputText.append( "Goodbye\n" );
|
||||
}
|
||||
|
||||
/** static constructor */
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Note the static constructor and the interesting JNI code is in the <tt>nativeCall</tt> method.
|
||||
The remaining code deals with the GUI aspects which are identical to the previous C simple example. Modify <tt>res/layout/main.xml</tt> to contain the xml for the 'Run' button and scrollable text view:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
android:orientation="vertical"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<Button
|
||||
android:id="@+id/RunButton"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
android:text="Run..."
|
||||
android:onClick="onRunButtonClick"
|
||||
/>
|
||||
<ScrollView
|
||||
android:id="@+id/Scroller"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<TextView
|
||||
android:id="@+id/OutputText"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
/>
|
||||
</ScrollView>
|
||||
</LinearLayout>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<p>
|
||||
Compile the Java code as usual, uninstall the old version of the app if installed and re-install the new app:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ ant debug
|
||||
$ adb uninstall org.swig.classexample
|
||||
$ adb install bin/SwigClass-debug.apk
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Run the app to see the result of calling the C++ code from Java:
|
||||
</p>
|
||||
|
||||
<center><img src="android-class.png" alt="Android screenshot of SwigClass example"></center>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
|
@ -5,12 +5,13 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="CSharp"></a>18 SWIG and C#</H1>
|
||||
<H1><a name="CSharp"></a>19 SWIG and C#</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#CSharp_introduction">Introduction</a>
|
||||
<li><a href="#CSharp_differences_java">Differences to the Java module</a>
|
||||
<li><a href="#CSharp_void_pointers">Void pointers</a>
|
||||
<li><a href="#CSharp_arrays">C# Arrays</a>
|
||||
<ul>
|
||||
<li><a href="#CSharp_arrays_swig_library">The SWIG C arrays library</a>
|
||||
|
|
@ -30,6 +31,7 @@
|
|||
<li><a href="#CSharp_directors_implementation">Directors implementation</a>
|
||||
<li><a href="#CSharp_director_caveats">Director caveats</a>
|
||||
</ul>
|
||||
<li><a href="#CSharp_multiple_modules">Multiples modules</a>
|
||||
<li><a href="#CSharp_typemap_examples">C# Typemap examples</a>
|
||||
<ul>
|
||||
<li><a href="#CSharp_memory_management_member_variables">Memory management when returning references to member variables</a>
|
||||
|
|
@ -46,7 +48,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="CSharp_introduction"></a>18.1 Introduction</H2>
|
||||
<H2><a name="CSharp_introduction"></a>19.1 Introduction</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -66,7 +68,7 @@ The <a href="http://msdn.microsoft.com">Microsoft Developer Network (MSDN)</a> h
|
|||
Monodoc, available from the Mono project, has a very useful section titled <a href="http://www.mono-project.com/Interop_with_Native_Libraries">Interop with native libraries</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_differences_java"></a>18.2 Differences to the Java module</H2>
|
||||
<H2><a name="CSharp_differences_java"></a>19.2 Differences to the Java module</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -169,6 +171,14 @@ javadestruct_derived -> csdestruct_derived
|
|||
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Typemap macros:</p>
|
||||
<div class="code"><pre>
|
||||
SWIG_JAVABODY_PROXY -> SWIG_CSBODY_PROXY
|
||||
SWIG_JAVABODY_TYPEWRAPPER -> SWIG_CSBODY_TYPEWRAPPER
|
||||
</pre></div>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Additional typemaps:</p>
|
||||
|
||||
|
|
@ -455,7 +465,25 @@ Windows users can also get the examples working using a
|
|||
<a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> environment for automatic configuration of the example makefiles.
|
||||
Any one of the three C# compilers (Portable.NET, Mono or Microsoft) can be detected from within a Cygwin or Mingw environment if installed in your path.
|
||||
|
||||
<H2><a name="CSharp_arrays"></a>18.3 C# Arrays</H2>
|
||||
<H2><a name="CSharp_void_pointers"></a>19.3 Void pointers</H2>
|
||||
|
||||
|
||||
<p>
|
||||
By default SWIG treats <tt>void *</tt> as any other pointer and hence marshalls it as a type wrapper class called <tt>SWIGTYPE_p_void</tt>.
|
||||
If you want to marshall with the .NET <tt>System.IntPtr</tt> type instead, there is a simple set of named typemaps called
|
||||
<tt>void *VOID_INT_PTR</tt> that can be used.
|
||||
They can be applied like any other named typemaps:
|
||||
</p>
|
||||
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%apply void *VOID_INT_PTR { void * }
|
||||
void * f(void *v);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="CSharp_arrays"></a>19.4 C# Arrays</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -467,7 +495,7 @@ with one of the following three approaches; namely the SWIG C arrays library, P/
|
|||
pinned arrays.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_arrays_swig_library"></a>18.3.1 The SWIG C arrays library</H3>
|
||||
<H3><a name="CSharp_arrays_swig_library"></a>19.4.1 The SWIG C arrays library</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -504,7 +532,7 @@ example.print_array(c.cast()); // Pass to C
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling"></a>18.3.2 Managed arrays using P/Invoke default array marshalling</H3>
|
||||
<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling"></a>19.4.2 Managed arrays using P/Invoke default array marshalling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -618,7 +646,7 @@ This results in the module class method
|
|||
</div>
|
||||
|
||||
<p>
|
||||
and intermediate class method
|
||||
and intermediary class method
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -631,7 +659,7 @@ and intermediate class method
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_arrays_pinning"></a>18.3.3 Managed arrays using pinning</H3>
|
||||
<H3><a name="CSharp_arrays_pinning"></a>19.4.3 Managed arrays using pinning</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -713,7 +741,7 @@ marshalling is the "unsafe" quantifier, which is required because we are handlin
|
|||
</p>
|
||||
|
||||
<p>
|
||||
Also the intermediate class method looks a little different from the default marshalling
|
||||
Also the intermediary class method looks a little different from the default marshalling
|
||||
example - the method is expecting an IntPtr as the parameter type.
|
||||
</p>
|
||||
|
||||
|
|
@ -726,7 +754,7 @@ public static extern void myArrayCopy(IntPtr jarg1, IntPtr jarg2, int jarg3);
|
|||
|
||||
|
||||
|
||||
<H2><a name="CSharp_exceptions"></a>18.4 C# Exceptions</H2>
|
||||
<H2><a name="CSharp_exceptions"></a>19.5 C# Exceptions</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -823,7 +851,7 @@ set so should only be used when a C# exception is not created.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="CSharp_exception_example_check_typemap"></a>18.4.1 C# exception example using "check" typemap</H3>
|
||||
<H3><a name="CSharp_exception_example_check_typemap"></a>19.5.1 C# exception example using "check" typemap</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1005,7 +1033,7 @@ method and C# code does not handle pending exceptions via the canthrow attribute
|
|||
Actually it will issue this warning for any function beginning with <tt>SWIG_CSharpSetPendingException</tt>.
|
||||
</P>
|
||||
|
||||
<H3><a name="CSharp_exception_example_percent_exception"></a>18.4.2 C# exception example using %exception</H3>
|
||||
<H3><a name="CSharp_exception_example_percent_exception"></a>19.5.2 C# exception example using %exception</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1070,7 +1098,7 @@ The managed code generated does check for the pending exception as mentioned ear
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_exception_example_exception_specifications"></a>18.4.3 C# exception example using exception specifications</H3>
|
||||
<H3><a name="CSharp_exception_example_exception_specifications"></a>19.5.3 C# exception example using exception specifications</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1127,7 +1155,7 @@ SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
|
|||
Multiple catch handlers are generated should there be more than one exception specifications declared.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_custom_application_exception"></a>18.4.4 Custom C# ApplicationException example</H3>
|
||||
<H3><a name="CSharp_custom_application_exception"></a>19.5.4 Custom C# ApplicationException example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1261,7 +1289,7 @@ try {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="CSharp_directors"></a>18.5 C# Directors</H2>
|
||||
<H2><a name="CSharp_directors"></a>19.6 C# Directors</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1274,7 +1302,7 @@ The following sections provide information on the C# director implementation and
|
|||
However, the <a href="Java.html#Java_directors">Java directors</a> section should also be read in order to gain more insight into directors.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_directors_example"></a>18.5.1 Directors example</H3>
|
||||
<H3><a name="CSharp_directors_example"></a>19.6.1 Directors example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1395,7 +1423,7 @@ CSharpDerived - UIntMethod(123)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_directors_implementation"></a>18.5.2 Directors implementation</H3>
|
||||
<H3><a name="CSharp_directors_implementation"></a>19.6.2 Directors implementation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1581,7 +1609,7 @@ void SwigDirector_Base::BaseBoolMethod(Base const &b, bool flag) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_director_caveats"></a>18.5.3 Director caveats</H3>
|
||||
<H3><a name="CSharp_director_caveats"></a>19.6.3 Director caveats</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1629,7 +1657,42 @@ However, a call from C# to <tt>CSharpDefaults.DefaultMethod()</tt> will of cours
|
|||
should pass the call on to <tt>CSharpDefaults.DefaultMethod(int)</tt>using the C++ default value, as shown above.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_typemap_examples"></a>18.6 C# Typemap examples</H2>
|
||||
<H2><a name="CSharp_multiple_modules"></a>19.7 Multiples modules</H2>
|
||||
|
||||
|
||||
<p>
|
||||
When using <a href="Modules.html">multiple modules</a> it is is possible to compile each SWIG generated wrapper
|
||||
into a different assembly.
|
||||
However, by default the generated code may not compile if
|
||||
generated classes in one assembly use generated classes in another assembly.
|
||||
The visibility of the
|
||||
<tt>getCPtr()</tt> and pointer constructor generated from the <tt>csbody</tt> typemaps needs changing.
|
||||
The default visibility is <tt>internal</tt> but it needs to be <tt>public</tt> for access from a different assembly.
|
||||
Just changing 'internal' to 'public' in the typemap achieves this.
|
||||
Two macros are available in <tt>csharp.swg</tt> to make this easier and using them is the preferred approach
|
||||
over simply copying the typemaps and modifying as this is forward compatible with any changes in
|
||||
the <tt>csbody</tt> typemap in future versions of SWIG.
|
||||
The macros are for the proxy and typewrapper classes and can respectively be used to
|
||||
to make the method and constructor public:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
SWIG_CSBODY_PROXY(public, public, SWIGTYPE)
|
||||
SWIG_CSBODY_TYPEWRAPPER(public, public, public, SWIGTYPE)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Alternatively, instead of exposing these as public, consider
|
||||
using the <tt>[assembly:InternalsVisibleTo("Name")]</tt> attribute available in the .NET framework when you
|
||||
know which assemblies these can be exposed to.
|
||||
Another approach would be to make these public, but also to hide them from intellisense by using
|
||||
the <tt>[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]</tt> attribute
|
||||
if you don't want users to easily stumble upon these so called 'internal workings' of the wrappers.
|
||||
</p>
|
||||
|
||||
<H2><a name="CSharp_typemap_examples"></a>19.8 C# Typemap examples</H2>
|
||||
|
||||
|
||||
This section includes a few examples of typemaps. For more examples, you
|
||||
|
|
@ -1637,7 +1700,7 @@ might look at the files "<tt>csharp.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
|
||||
|
||||
<H3><a name="CSharp_memory_management_member_variables"></a>18.6.1 Memory management when returning references to member variables</H3>
|
||||
<H3><a name="CSharp_memory_management_member_variables"></a>19.8.1 Memory management when returning references to member variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1761,7 +1824,7 @@ public class Bike : IDisposable {
|
|||
Note the <tt>addReference</tt> call.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_memory_management_objects"></a>18.6.2 Memory management for objects passed to the C++ layer</H3>
|
||||
<H3><a name="CSharp_memory_management_objects"></a>19.8.2 Memory management for objects passed to the C++ layer</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1880,7 +1943,7 @@ The 'cscode' typemap simply adds in the specified code into the C# proxy class.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="CSharp_date_marshalling"></a>18.6.3 Date marshalling using the csin typemap and associated attributes</H3>
|
||||
<H3><a name="CSharp_date_marshalling"></a>19.8.3 Date marshalling using the csin typemap and associated attributes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2166,7 +2229,7 @@ public class example {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_date_properties"></a>18.6.4 A date example demonstrating marshalling of C# properties</H3>
|
||||
<H3><a name="CSharp_date_properties"></a>19.8.4 A date example demonstrating marshalling of C# properties</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2267,7 +2330,7 @@ Some points to note:
|
|||
</ul>
|
||||
|
||||
|
||||
<H3><a name="CSharp_partial_classes"></a>18.6.5 Turning wrapped classes into partial classes</H3>
|
||||
<H3><a name="CSharp_partial_classes"></a>19.8.5 Turning wrapped classes into partial classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2367,7 +2430,7 @@ demonstrating that the class contains methods calling both unmanaged code - <tt>
|
|||
The following example is an alternative approach to adding managed code to the generated proxy class.
|
||||
</p>
|
||||
|
||||
<H3><a name="CSharp_extending_proxy_class"></a>18.6.6 Extending proxy classes with additional C# code</H3>
|
||||
<H3><a name="CSharp_extending_proxy_class"></a>19.8.6 Extending proxy classes with additional C# code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2406,7 +2469,7 @@ public class ExtendMe : IDisposable {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="CSharp_enum_underlying_type"></a>18.6.7 Underlying type for enums</H3>
|
||||
<H3><a name="CSharp_enum_underlying_type"></a>19.8.7 Underlying type for enums</H3>
|
||||
|
||||
|
||||
<P>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Chicken"></a>19 SWIG and Chicken</H1>
|
||||
<H1><a name="Chicken"></a>20 SWIG and Chicken</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -72,7 +72,7 @@
|
|||
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn2"></a>19.1 Preliminaries</H2>
|
||||
<H2><a name="Chicken_nn2"></a>20.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -89,7 +89,7 @@
|
|||
directory for the basic steps to run SWIG CHICKEN.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn3"></a>19.1.1 Running SWIG in C mode</H3>
|
||||
<H3><a name="Chicken_nn3"></a>20.1.1 Running SWIG in C mode</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,7 +122,7 @@
|
|||
object files and linked into your project.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn4"></a>19.1.2 Running SWIG in C++ mode</H3>
|
||||
<H3><a name="Chicken_nn4"></a>20.1.2 Running SWIG in C++ mode</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -151,10 +151,10 @@
|
|||
object files and linked into your project.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn5"></a>19.2 Code Generation</H2>
|
||||
<H2><a name="Chicken_nn5"></a>20.2 Code Generation</H2>
|
||||
|
||||
|
||||
<H3><a name="Chicken_nn6"></a>19.2.1 Naming Conventions</H3>
|
||||
<H3><a name="Chicken_nn6"></a>20.2.1 Naming Conventions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -170,7 +170,7 @@
|
|||
<tt>%rename</tt> SWIG directive in the SWIG interface file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn7"></a>19.2.2 Modules</H3>
|
||||
<H3><a name="Chicken_nn7"></a>20.2.2 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -192,7 +192,7 @@
|
|||
(uses <i>modulename</i>))</code> CHICKEN Scheme form.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn8"></a>19.2.3 Constants and Variables</H3>
|
||||
<H3><a name="Chicken_nn8"></a>20.2.3 Constants and Variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -229,7 +229,7 @@
|
|||
for info on how to apply the %feature.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn9"></a>19.2.4 Functions</H3>
|
||||
<H3><a name="Chicken_nn9"></a>20.2.4 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -248,7 +248,7 @@
|
|||
parameters). The return values can then be accessed with <code>(call-with-values)</code>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn10"></a>19.2.5 Exceptions</H3>
|
||||
<H3><a name="Chicken_nn10"></a>20.2.5 Exceptions</H3>
|
||||
|
||||
|
||||
<p>The SWIG chicken module has support for exceptions thrown from
|
||||
|
|
@ -290,7 +290,7 @@
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H2><a name="Chicken_nn11"></a>19.3 TinyCLOS</H2>
|
||||
<H2><a name="Chicken_nn11"></a>20.3 TinyCLOS</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -333,7 +333,7 @@
|
|||
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn12"></a>19.4 Linkage</H2>
|
||||
<H2><a name="Chicken_nn12"></a>20.4 Linkage</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -354,7 +354,7 @@
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Chicken_nn13"></a>19.4.1 Static binary or shared library linked at compile time</H3>
|
||||
<H3><a name="Chicken_nn13"></a>20.4.1 Static binary or shared library linked at compile time</H3>
|
||||
|
||||
|
||||
<p>We can easily use csc to build a static binary.</p>
|
||||
|
|
@ -395,7 +395,7 @@ in which case the test script does not need to be linked with example.so. The t
|
|||
be run with <tt>csi</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_nn14"></a>19.4.2 Building chicken extension libraries</H3>
|
||||
<H3><a name="Chicken_nn14"></a>20.4.2 Building chicken extension libraries</H3>
|
||||
|
||||
|
||||
<p>Building a shared library like in the above section only works if the library
|
||||
|
|
@ -453,7 +453,7 @@ distributed and used by anyone, even if SWIG is not installed.</p>
|
|||
<p>See the <tt>Examples/chicken/egg</tt> directory in the SWIG source for an example that builds
|
||||
two eggs, one using the first method and one using the second method.</p>
|
||||
|
||||
<H3><a name="Chicken_nn15"></a>19.4.3 Linking multiple SWIG modules with TinyCLOS</H3>
|
||||
<H3><a name="Chicken_nn15"></a>20.4.3 Linking multiple SWIG modules with TinyCLOS</H3>
|
||||
|
||||
|
||||
<p>Linking together multiple modules that share type information using the <code>%import</code>
|
||||
|
|
@ -477,7 +477,7 @@ with <code>(declare (uses ...))</code>.
|
|||
To create an extension library or an egg, just create a <tt>module_load.scm</tt> file that <code>(declare (uses ...))</code>
|
||||
all the modules.</p>
|
||||
|
||||
<H2><a name="Chicken_nn16"></a>19.5 Typemaps</H2>
|
||||
<H2><a name="Chicken_nn16"></a>20.5 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -486,7 +486,7 @@ all the modules.</p>
|
|||
<code>Lib/chicken/chicken.swg</code>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn17"></a>19.6 Pointers</H2>
|
||||
<H2><a name="Chicken_nn17"></a>20.6 Pointers</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -519,7 +519,7 @@ all the modules.</p>
|
|||
type. flags is either zero or SWIG_POINTER_DISOWN (see below).
|
||||
</p>
|
||||
|
||||
<H3><a name="Chicken_collection"></a>19.6.1 Garbage collection</H3>
|
||||
<H3><a name="Chicken_collection"></a>20.6.1 Garbage collection</H3>
|
||||
|
||||
|
||||
<p>If the owner flag passed to <code>SWIG_NewPointerObj</code> is 1, <code>NewPointerObj</code> will add a
|
||||
|
|
@ -550,7 +550,7 @@ all the modules.</p>
|
|||
must be called manually.
|
||||
</p>
|
||||
|
||||
<H2><a name="Chicken_nn18"></a>19.7 Unsupported features and known problems</H2>
|
||||
<H2><a name="Chicken_nn18"></a>20.7 Unsupported features and known problems</H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
@ -560,7 +560,7 @@ all the modules.</p>
|
|||
<a href="SWIGPlus.html#SWIGPlus_default_args">%feature(compactdefaultargs)</a>.</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Chicken_nn19"></a>19.7.1 TinyCLOS problems with Chicken version <= 1.92</H3>
|
||||
<H3><a name="Chicken_nn19"></a>20.7.1 TinyCLOS problems with Chicken version <= 1.92</H3>
|
||||
|
||||
|
||||
<p>In Chicken versions equal to or below 1.92, TinyCLOS has a limitation such that generic methods do not properly work on methods
|
||||
|
|
|
|||
|
|
@ -242,6 +242,7 @@
|
|||
<li><a href="SWIGPlus.html#SWIGPlus_catches">Exception handling with %catches</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn33">Pointers to Members</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_smart_pointers">Smart pointers and operator->()</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_ref_unref">C++ reference counted objects - ref/unref feature</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn35">Using declarations and inheritance</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nested_classes">Nested classes</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_const">A brief rant about const-correctness</a>
|
||||
|
|
@ -396,6 +397,7 @@
|
|||
<li><a href="Typemaps.html#Typemaps_nn43">Typemaps for multiple target languages</a>
|
||||
<li><a href="Typemaps.html#Typemaps_optimal">Optimal code generation when returning by value</a>
|
||||
<li><a href="Typemaps.html#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a>
|
||||
<li><a href="Typemaps.html#Typemaps_warnings">Typemap warnings</a>
|
||||
<li><a href="Typemaps.html#Typemaps_fragments">Typemap fragments</a>
|
||||
<ul>
|
||||
<li><a href="Typemaps.html#Typemaps_fragment_type_specialization">Fragment type specialization</a>
|
||||
|
|
@ -628,13 +630,30 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CSharp.html#CSharp">18 SWIG and C#</a></h3>
|
||||
<h3><a href="Android.html#Android">18 SWIG and Android</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="Android.html#Android_overview">Overview</a>
|
||||
<li><a href="Android.html#Android_examples">Android examples</a>
|
||||
<ul>
|
||||
<li><a href="Android.html#Android_examples_intro">Examples introduction</a>
|
||||
<li><a href="Android.html#Android_example_simple">Simple C example</a>
|
||||
<li><a href="Android.html#Android_example_class">C++ class example</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="CSharp.html#CSharp">19 SWIG and C#</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="CSharp.html#CSharp_introduction">Introduction</a>
|
||||
<li><a href="CSharp.html#CSharp_differences_java">Differences to the Java module</a>
|
||||
<li><a href="CSharp.html#CSharp_void_pointers">Void pointers</a>
|
||||
<li><a href="CSharp.html#CSharp_arrays">C# Arrays</a>
|
||||
<ul>
|
||||
<li><a href="CSharp.html#CSharp_arrays_swig_library">The SWIG C arrays library</a>
|
||||
|
|
@ -654,6 +673,7 @@
|
|||
<li><a href="CSharp.html#CSharp_directors_implementation">Directors implementation</a>
|
||||
<li><a href="CSharp.html#CSharp_director_caveats">Director caveats</a>
|
||||
</ul>
|
||||
<li><a href="CSharp.html#CSharp_multiple_modules">Multiples modules</a>
|
||||
<li><a href="CSharp.html#CSharp_typemap_examples">C# Typemap examples</a>
|
||||
<ul>
|
||||
<li><a href="CSharp.html#CSharp_memory_management_member_variables">Memory management when returning references to member variables</a>
|
||||
|
|
@ -668,7 +688,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Chicken.html#Chicken">19 SWIG and Chicken</a></h3>
|
||||
<h3><a href="Chicken.html#Chicken">20 SWIG and Chicken</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -706,7 +726,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="D.html#D">20 SWIG and D</a></h3>
|
||||
<h3><a href="D.html#D">21 SWIG and D</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -740,7 +760,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Go.html#Go">21 SWIG and Go</a></h3>
|
||||
<h3><a href="Go.html#Go">22 SWIG and Go</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -764,14 +784,14 @@
|
|||
<li><a href="Go.html#Go_templates">Go Templates</a>
|
||||
<li><a href="Go.html#Go_director_classes">Go Director Classes</a>
|
||||
<li><a href="Go.html#Go_primitive_type_mappings">Default Go primitive type mappings</a>
|
||||
<li><a href="#Go_output_arguments">Output arguments</a>
|
||||
<li><a href="#Go_adding_additional_code">Adding additional go code</a>
|
||||
<li><a href="Go.html#Go_output_arguments">Output arguments</a>
|
||||
<li><a href="Go.html#Go_adding_additional_code">Adding additional go code</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Guile.html#Guile">22 SWIG and Guile</a></h3>
|
||||
<h3><a href="Guile.html#Guile">23 SWIG and Guile</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -806,7 +826,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Java.html#Java">23 SWIG and Java</a></h3>
|
||||
<h3><a href="Java.html#Java">24 SWIG and Java</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -944,12 +964,12 @@
|
|||
<li><a href="Java.html#Java_performance">Performance concerns and hints</a>
|
||||
<li><a href="Java.html#Java_debugging">Debugging</a>
|
||||
</ul>
|
||||
<li><a href="Java.html#Java_examples">Examples</a>
|
||||
<li><a href="Java.html#Java_examples">Java Examples</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Lisp.html#Lisp">24 SWIG and Common Lisp</a></h3>
|
||||
<h3><a href="Lisp.html#Lisp">25 SWIG and Common Lisp</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -972,7 +992,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Lua.html#Lua">25 SWIG and Lua</a></h3>
|
||||
<h3><a href="Lua.html#Lua">26 SWIG and Lua</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -980,6 +1000,7 @@
|
|||
<li><a href="Lua.html#Lua_nn2">Preliminaries</a>
|
||||
<li><a href="Lua.html#Lua_nn3">Running SWIG</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_commandline">Additional command line options</a>
|
||||
<li><a href="Lua.html#Lua_nn4">Compiling and Linking and Interpreter</a>
|
||||
<li><a href="Lua.html#Lua_nn5">Compiling a dynamic module</a>
|
||||
<li><a href="Lua.html#Lua_nn6">Using your module</a>
|
||||
|
|
@ -998,38 +1019,39 @@
|
|||
<li><a href="Lua.html#Lua_nn17">C++ overloaded functions</a>
|
||||
<li><a href="Lua.html#Lua_nn18">C++ operators</a>
|
||||
<li><a href="Lua.html#Lua_nn19">Class extension with %extend</a>
|
||||
<li><a href="Lua.html#Lua_nn20">C++ templates</a>
|
||||
<li><a href="Lua.html#Lua_nn21">C++ Smart Pointers</a>
|
||||
<li><a href="Lua.html#Lua_nn22">C++ Exceptions</a>
|
||||
<li><a href="Lua.html#Lua_nn20">Using %newobject to release memory</a>
|
||||
<li><a href="Lua.html#Lua_nn21">C++ templates</a>
|
||||
<li><a href="Lua.html#Lua_nn22">C++ Smart Pointers</a>
|
||||
<li><a href="Lua.html#Lua_nn23">C++ Exceptions</a>
|
||||
</ul>
|
||||
<li><a href="Lua.html#Lua_nn23">Typemaps</a>
|
||||
<li><a href="Lua.html#Lua_nn24">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_nn24">What is a typemap?</a>
|
||||
<li><a href="Lua.html#Lua_nn25">Using typemaps</a>
|
||||
<li><a href="Lua.html#Lua_nn26">Typemaps and arrays</a>
|
||||
<li><a href="Lua.html#Lua_nn27">Typemaps and pointer-pointer functions</a>
|
||||
<li><a href="Lua.html#Lua_nn25">What is a typemap?</a>
|
||||
<li><a href="Lua.html#Lua_nn26">Using typemaps</a>
|
||||
<li><a href="Lua.html#Lua_nn27">Typemaps and arrays</a>
|
||||
<li><a href="Lua.html#Lua_nn28">Typemaps and pointer-pointer functions</a>
|
||||
</ul>
|
||||
<li><a href="Lua.html#Lua_nn28">Writing typemaps</a>
|
||||
<li><a href="Lua.html#Lua_nn29">Writing typemaps</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_nn29">Typemaps you can write</a>
|
||||
<li><a href="Lua.html#Lua_nn30">SWIG's Lua-C API</a>
|
||||
<li><a href="Lua.html#Lua_nn30">Typemaps you can write</a>
|
||||
<li><a href="Lua.html#Lua_nn31">SWIG's Lua-C API</a>
|
||||
</ul>
|
||||
<li><a href="Lua.html#Lua_nn31">Customization of your Bindings</a>
|
||||
<li><a href="Lua.html#Lua_nn32">Customization of your Bindings</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_nn32">Writing your own custom wrappers</a>
|
||||
<li><a href="Lua.html#Lua_nn33">Adding additional Lua code</a>
|
||||
<li><a href="Lua.html#Lua_nn33">Writing your own custom wrappers</a>
|
||||
<li><a href="Lua.html#Lua_nn34">Adding additional Lua code</a>
|
||||
</ul>
|
||||
<li><a href="Lua.html#Lua_nn34">Details on the Lua binding</a>
|
||||
<li><a href="Lua.html#Lua_nn35">Details on the Lua binding</a>
|
||||
<ul>
|
||||
<li><a href="Lua.html#Lua_nn35">Binding global data into the module.</a>
|
||||
<li><a href="Lua.html#Lua_nn36">Userdata and Metatables</a>
|
||||
<li><a href="Lua.html#Lua_nn37">Memory management</a>
|
||||
<li><a href="Lua.html#Lua_nn36">Binding global data into the module.</a>
|
||||
<li><a href="Lua.html#Lua_nn37">Userdata and Metatables</a>
|
||||
<li><a href="Lua.html#Lua_nn38">Memory management</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Modula3.html#Modula3">26 SWIG and Modula-3</a></h3>
|
||||
<h3><a href="Modula3.html#Modula3">27 SWIG and Modula-3</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1067,7 +1089,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Mzscheme.html#Mzscheme">27 SWIG and MzScheme/Racket</a></h3>
|
||||
<h3><a href="Mzscheme.html#Mzscheme">28 SWIG and MzScheme/Racket</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1079,7 +1101,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ocaml.html#Ocaml">28 SWIG and Ocaml</a></h3>
|
||||
<h3><a href="Ocaml.html#Ocaml">29 SWIG and Ocaml</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1130,7 +1152,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Octave.html#Octave">29 SWIG and Octave</a></h3>
|
||||
<h3><a href="Octave.html#Octave">30 SWIG and Octave</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1138,6 +1160,7 @@
|
|||
<li><a href="Octave.html#Octave_nn2">Preliminaries</a>
|
||||
<li><a href="Octave.html#Octave_nn3">Running SWIG</a>
|
||||
<ul>
|
||||
<li><a href="Octave.html#Octave_nn4">Command-line options</a>
|
||||
<li><a href="Octave.html#Octave_nn5">Compiling a dynamic module</a>
|
||||
<li><a href="Octave.html#Octave_nn6">Using your module</a>
|
||||
</ul>
|
||||
|
|
@ -1165,7 +1188,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Perl5.html#Perl5">30 SWIG and Perl5</a></h3>
|
||||
<h3><a href="Perl5.html#Perl5">31 SWIG and Perl5</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1232,7 +1255,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Php.html#Php">31 SWIG and PHP</a></h3>
|
||||
<h3><a href="Php.html#Php">32 SWIG and PHP</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1272,7 +1295,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Pike.html#Pike">32 SWIG and Pike</a></h3>
|
||||
<h3><a href="Pike.html#Pike">33 SWIG and Pike</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1296,7 +1319,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Python.html#Python">33 SWIG and Python</a></h3>
|
||||
<h3><a href="Python.html#Python">34 SWIG and Python</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1329,7 +1352,7 @@
|
|||
<li><a href="Python.html#Python_nn25">C++ namespaces</a>
|
||||
<li><a href="Python.html#Python_nn26">C++ templates</a>
|
||||
<li><a href="Python.html#Python_nn27">C++ Smart Pointers</a>
|
||||
<li><a href="Python.html#Python_nn27a">C++ Reference Counted Objects (ref/unref)</a>
|
||||
<li><a href="Python.html#Python_nn27a">C++ reference counted objects</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn28">Further details on the Python class interface</a>
|
||||
<ul>
|
||||
|
|
@ -1389,6 +1412,8 @@
|
|||
<ul>
|
||||
<li><a href="Python.html#Python_nn68">%feature("autodoc", "0")</a>
|
||||
<li><a href="Python.html#Python_nn69">%feature("autodoc", "1")</a>
|
||||
<li><a href="Python.html#Python_autodoc2">%feature("autodoc", "2")</a>
|
||||
<li><a href="Python.html#Python_autodoc3">%feature("autodoc", "3")</a>
|
||||
<li><a href="Python.html#Python_nn70">%feature("autodoc", "docstring")</a>
|
||||
</ul>
|
||||
<li><a href="Python.html#Python_nn71">%feature("docstring")</a>
|
||||
|
|
@ -1404,7 +1429,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="R.html#R">34 SWIG and R</a></h3>
|
||||
<h3><a href="R.html#R">35 SWIG and R</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1420,7 +1445,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Ruby.html#Ruby">35 SWIG and Ruby</a></h3>
|
||||
<h3><a href="Ruby.html#Ruby">36 SWIG and Ruby</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1554,7 +1579,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Tcl.html#Tcl">36 SWIG and Tcl</a></h3>
|
||||
<h3><a href="Tcl.html#Tcl">37 SWIG and Tcl</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1620,7 +1645,7 @@
|
|||
</div>
|
||||
<!-- INDEX -->
|
||||
|
||||
<h3><a href="Extending.html#Extending">37 Extending SWIG to support new languages</a></h3>
|
||||
<h3><a href="Extending.html#Extending">38 Extending SWIG to support new languages</a></h3>
|
||||
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
|
|
@ -1691,3 +1716,4 @@
|
|||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
|
|
|||
|
|
@ -704,6 +704,11 @@ depends on the target language on implementing the 'disown' mechanism
|
|||
properly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The use of <tt>%newobject</tt> is also integrated with reference counting and is covered in the
|
||||
<a href="SWIGPlus.html#SWIGPlus_ref_unref">C++ reference counted objects</a> section.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Compatibility note:</b> Previous versions of SWIG had a special <tt>%new</tt> directive. However, unlike <tt>%newobject</tt>,
|
||||
it only applied to the next declaration. For example:
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="D"></a>20 SWIG and D</H1>
|
||||
<H1><a name="D"></a>21 SWIG and D</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -41,10 +41,10 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="D_introduction"></a>20.1 Introduction</H2>
|
||||
<H2><a name="D_introduction"></a>21.1 Introduction</H2>
|
||||
|
||||
|
||||
<p>From the <a href="http://www.digitalmars.com/d/">D Programming Language</a> web site: <em>»D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. [...] The D language is statically typed and compiles directly to machine code.«</em> As such, it is not very surprising that D is able to directly <a href="http://www.digitalmars.com/d/1.0/interfaceToC.html">interface with C libraries</a>. Why would a SWIG module for D be needed then in the first place?</p>
|
||||
<p>From the <a href="http://www.digitalmars.com/d/">D Programming Language</a> web site: <em>D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. [...] The D language is statically typed and compiles directly to machine code.</em> As such, it is not very surprising that D is able to directly <a href="http://www.digitalmars.com/d/1.0/interfaceToC.html">interface with C libraries</a>. Why would a SWIG module for D be needed then in the first place?</p>
|
||||
|
||||
<p>Well, besides the obvious downside that the C header files have to be manually converted to D modules for this to work, there is one major inconvenience with this approach: D code usually is on a higher abstraction level than C, and many of the features that make D interesting are simply not available when dealing with C libraries, requiring you e.g. to manually convert strings between pointers to <tt>\0</tt>-terminated char arrays and D char arrays, making the algorithms from the D2 standard library unusable with C arrays and data structures, and so on.</p>
|
||||
|
||||
|
|
@ -53,7 +53,7 @@
|
|||
<p>To help addressing these issues, the SWIG C# module has been forked to support D. Is has evolved quite a lot since then, but there are still many similarities, so if you do not find what you are looking for on this page, it might be worth having a look at the chapter on <a href="CSharp.html">C#</a> (and also on <a href="Java.html">Java</a>, since the C# module was in turn forked from it).</p>
|
||||
|
||||
|
||||
<H2><a name="D_command_line_invocation"></a>20.2 Command line invocation</H2>
|
||||
<H2><a name="D_command_line_invocation"></a>21.2 Command line invocation</H2>
|
||||
|
||||
|
||||
<p>To activate the D module, pass the <tt>-d</tt> option to SWIG at the command line. The same standard command line switches as with any other language module are available, plus the following D specific ones:</p>
|
||||
|
|
@ -83,10 +83,10 @@
|
|||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_typemaps"></a>20.3 Typemaps</H2>
|
||||
<H2><a name="D_typemaps"></a>21.3 Typemaps</H2>
|
||||
|
||||
|
||||
<H3><a name="D_typemap_name_comparison"></a>20.3.1 C# <-> D name comparison</H3>
|
||||
<H3><a name="D_typemap_name_comparison"></a>21.3.1 C# <-> D name comparison</H3>
|
||||
|
||||
|
||||
<p>If you already know the SWIG C# module, you might find the following name comparison table useful:</p>
|
||||
|
|
@ -112,7 +112,7 @@
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="D_ctype_imtype_dtype"></a>20.3.2 ctype, imtype, dtype</H3>
|
||||
<H3><a name="D_ctype_imtype_dtype"></a>21.3.2 ctype, imtype, dtype</H3>
|
||||
|
||||
|
||||
<p>Mapping of types between the C/C++ library, the C/C++ library wrapper exposing the C functions, the D wrapper module importing these functions and the D proxy code.</p>
|
||||
|
|
@ -120,7 +120,7 @@
|
|||
<p>The <tt>ctype</tt> typemap is used to determine the types to use in the C wrapper functions. The types from the <tt>imtype</tt> typemap are used in the extern(C) declarations of these functions in the intermediary D module. The <tt>dtype</tt> typemap contains the D types used in the D proxy module/class.</p>
|
||||
|
||||
|
||||
<H3><a name="D_in_out_directorin_direcetorout"></a>20.3.3 in, out, directorin, directorout</H3>
|
||||
<H3><a name="D_in_out_directorin_direcetorout"></a>21.3.3 in, out, directorin, directorout</H3>
|
||||
|
||||
|
||||
<p>Used for converting between the types for C/C++ and D when generating the code for the wrapper functions (on the C++ side).</p>
|
||||
|
|
@ -130,7 +130,7 @@
|
|||
<p>The <tt>directorin</tt> typemap is used to convert parameters to the type used in the D director callback function, its return value is processed by <tt>directorout</tt> (see below).</p>
|
||||
|
||||
|
||||
<H3><a name="D_din_dout_ddirectorin_ddirectorout"></a>20.3.4 din, dout, ddirectorin, ddirectorout</H3>
|
||||
<H3><a name="D_din_dout_ddirectorin_ddirectorout"></a>21.3.4 din, dout, ddirectorin, ddirectorout</H3>
|
||||
|
||||
|
||||
<p>Typemaps for code generation in D proxy and type wrapper classes.</p>
|
||||
|
|
@ -157,13 +157,13 @@
|
|||
dtype DClass.method(dtype a)</pre></div>
|
||||
|
||||
|
||||
<H3><a name="D_typecheck_typemaps"></a>20.3.5 typecheck typemaps</H3>
|
||||
<H3><a name="D_typecheck_typemaps"></a>21.3.5 typecheck typemaps</H3>
|
||||
|
||||
|
||||
<p>Because, unlike many scripting languages supported by SWIG, D does not need any dynamic dispatch helper to access an overloaded function, the purpose of these is merely to issue a warning for overloaded C++ functions that cannot be overloaded in D (as more than one C++ type maps to a single D type).</p>
|
||||
|
||||
|
||||
<H3><a name="D_code_injection_typemaps"></a>20.3.6 Code injection typemaps</H3>
|
||||
<H3><a name="D_code_injection_typemaps"></a>21.3.6 Code injection typemaps</H3>
|
||||
|
||||
|
||||
<p>These typemaps are used for generating the skeleton of proxy classes for C++ types.</p>
|
||||
|
|
@ -175,7 +175,7 @@
|
|||
<p id="D_class_code_typemaps"><tt>dconstructor</tt>, <tt>ddestructor</tt>, <tt>ddispose</tt> and <tt>ddispose_derived</tt> are used to generate the class constructor, destructor and <tt>dispose()</tt> method, respectively. The auxiliary code for handling the pointer to the C++ object is stored in <tt>dbody</tt> and <tt>dbody_derived</tt>. You can override them for specific types.</p>
|
||||
|
||||
|
||||
<H3><a name="D_special_variables"></a>20.3.7 Special variable macros</H3>
|
||||
<H3><a name="D_special_variables"></a>21.3.7 Special variable macros</H3>
|
||||
|
||||
|
||||
<p>The standard SWIG special variables are available for use within typemaps as described in the <a href="Typemaps.html#Typemaps">Typemaps documentation</a>, for example <tt>$1</tt>, <tt>$input</tt>, <tt>$result</tt> etc.</p>
|
||||
|
|
@ -295,7 +295,7 @@ $importtype(AnotherInterface)
|
|||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_features"></a>20.4 <tt>%feature</tt>s</H2>
|
||||
<H2><a name="D_features"></a>21.4 <tt>%feature</tt>s</H2>
|
||||
|
||||
|
||||
<p>The D module defines a number of directives which modify the <a href="Customization.html#Customization_features">SWIG features</a> set globally or for a specific declaration:</p>
|
||||
|
|
@ -325,7 +325,7 @@ struct A {
|
|||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_pragmas"></a>20.5 Pragmas</H2>
|
||||
<H2><a name="D_pragmas"></a>21.5 Pragmas</H2>
|
||||
|
||||
|
||||
<p>There are a few SWIG pragmas specific to the D module, which you can use to influence the D code SWIG generates:</p>
|
||||
|
|
@ -364,7 +364,7 @@ struct A {
|
|||
</dl>
|
||||
|
||||
|
||||
<H2><a name="D_exceptions"></a>20.6 D Exceptions</H2>
|
||||
<H2><a name="D_exceptions"></a>21.6 D Exceptions</H2>
|
||||
|
||||
|
||||
<p>Out of the box, C++ exceptions are fundamentally incompatible to their equivalent in the D world and cannot simply be propagated to a calling D method. There is, however, an easy way to solve this problem: Just catch the exception in the C/C++ wrapper layer, pass the contents to D, and make the wrapper code rethrow the exception in the D world.</p>
|
||||
|
|
@ -374,7 +374,7 @@ struct A {
|
|||
<p>As this feature is implemented in exactly the same way it is for C#, please see the <a href="CSharp.html#CSharp_exceptions">C# documentation</a> for a more detailed explanation.</p>
|
||||
|
||||
|
||||
<H2><a name="D_directors"></a>20.7 D Directors</H2>
|
||||
<H2><a name="D_directors"></a>21.7 D Directors</H2>
|
||||
|
||||
|
||||
<p>When the directors feature is activated, SWIG generates extra code on both the C++ and the D side to enable cross-language polymorphism. Essentially, this means that if you subclass a proxy class in D, C++ code can access any overridden virtual methods just as if you created a derived class in C++.</p>
|
||||
|
|
@ -383,19 +383,19 @@ struct A {
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="D_other_features"></a>20.8 Other features</H2>
|
||||
<H2><a name="D_other_features"></a>21.8 Other features</H2>
|
||||
|
||||
|
||||
<H3><a name="D_nspace"></a>20.8.1 Extended namespace support (<tt>nspace</tt>)</H3>
|
||||
<H3><a name="D_nspace"></a>21.8.1 Extended namespace support (<tt>nspace</tt>)</H3>
|
||||
|
||||
|
||||
<p>By default, SWIG flattens all C++ namespaces into a single target language namespace, but as for Java and C#, the <a href="SWIGPlus.html#SWIGPlus_nspace"><tt>nspace</tt></a> feature is supported for D. If it is active, C++ namespaces are mapped to D packages/modules. Note, however, that like for the other languages, <em>free</em> variables and functions are not supported yet; currently, they are all allows written to the main proxy D module.</p>
|
||||
|
||||
|
||||
<H3><a name="D_native_pointer_support"></a>20.8.2 Native pointer support</H3>
|
||||
<H3><a name="D_native_pointer_support"></a>21.8.2 Native pointer support</H3>
|
||||
|
||||
|
||||
<p>Contrary to many of the scripting languages supported by SWIG, D fully supports C-style pointers. The D module thus includes a custom mechanism to wrap C pointers directly as D pointers where applicable, that is, if the type that is pointed to is represented the same in C and D (on the bit-level), dubbed a »primtive type« below.</p>
|
||||
<p>Contrary to many of the scripting languages supported by SWIG, D fully supports C-style pointers. The D module thus includes a custom mechanism to wrap C pointers directly as D pointers where applicable, that is, if the type that is pointed to is represented the same in C and D (on the bit-level), dubbed a <em>primitive type</em> below.</p>
|
||||
|
||||
<p>Central to this custom pointer handling scheme are two typemap attributes: the <tt>cprimitive</tt> attribute on the <tt>dtype</tt> typemap and the <tt>nativepointer</tt> attribute on all the typemaps which influence the D side of the code (<tt>dtype</tt>, <tt>din</tt>, <tt>dout</tt>, ...). When a D typemap is looked up, the following happens behind the scenes:</p>
|
||||
|
||||
|
|
@ -404,7 +404,7 @@ struct A {
|
|||
<p>To determine if a type should be considered primitive, the <tt>cprimitive</tt> attribute on its <tt>dtype</tt> attribute is used. For example, the <tt>dtype</tt> typemap for <tt>float</tt> has <tt>cprimitive="1"</tt>, so the code from the <tt>nativepointer</tt> attribute is taken into account e.g. for <tt>float **</tt> or the function pointer <tt>float (*)(float *)</tt>.</p>
|
||||
|
||||
|
||||
<H3><a name="D_operator_overloading"></a>20.8.3 Operator overloading</H3>
|
||||
<H3><a name="D_operator_overloading"></a>21.8.3 Operator overloading</H3>
|
||||
|
||||
|
||||
<p>The D module comes with basic operator overloading support for both D1 and D2. There are, however, a few limitations arising from conceptual differences between C++ and D:</p>
|
||||
|
|
@ -416,7 +416,7 @@ struct A {
|
|||
<p>There are also some cases where the operators can be translated to D, but the differences in the implementation details are big enough that a rather involved scheme would be required for automatic wrapping them, which has not been implemented yet. This affects, for example, the array subscript operator, <tt>[]</tt>, in combination with assignments - while <tt>operator []</tt> in C++ simply returns a reference which is then written to, D resorts to a separate <tt>opIndexAssign</tt> method -, or implicit casting (which was introduced in D2 via <tt>alias this</tt>). Despite the lack of automatic support, manually handling these cases should be perfectly possible.</p>
|
||||
|
||||
|
||||
<H3><a name="D_test_suite"></a>20.8.4 Running the test-suite</H3>
|
||||
<H3><a name="D_test_suite"></a>21.8.4 Running the test-suite</H3>
|
||||
|
||||
|
||||
<p>As with any other language, the SWIG test-suite can be built for D using the <tt>*-d-test-suite</tt> targets of the top-level Makefile. By default, D1 is targeted, to build it with D2, use the optional <tt>D_VERSION</tt> variable, e.g. <tt>make check-d-test-suite D_VERSION=2</tt>.</p>
|
||||
|
|
@ -424,14 +424,14 @@ struct A {
|
|||
<p>Note: If you want to use GDC on Linux or another platform which requires you to link <tt>libdl</tt> for dynamically loading the shared library, you might have to add <tt>-ldl</tt> manually to the <tt>d_compile</tt> target in <tt>Examples/Makefile</tt>, because GDC does not currently honor the <tt>pragma(lib,...)</tt> statement.</p>
|
||||
|
||||
|
||||
<H2><a name="D_typemap_examples"></a>20.9 D Typemap examples</H2>
|
||||
<H2><a name="D_typemap_examples"></a>21.9 D Typemap examples</H2>
|
||||
|
||||
|
||||
<p>There are no D-specific typemap examples yet. However, with the above <a href="D.html#D_typemap_name_comparison">name comparison table</a>, you should be able to get an idea what can be done by looking at the <a href="CSharp.html#CSharp_typemap_examples">corresponding C# section</a>.</p>
|
||||
|
||||
|
||||
|
||||
<H2><a name="D_planned_features"></a>20.10 Work in progress and planned features</H2>
|
||||
<H2><a name="D_planned_features"></a>21.10 Work in progress and planned features</H2>
|
||||
|
||||
|
||||
<p>There are a couple of features which are not implemented yet, but would be very useful and might be added in the near future:</p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Extending"></a>37 Extending SWIG to support new languages</H1>
|
||||
<H1><a name="Extending"></a>38 Extending SWIG to support new languages</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -75,7 +75,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="Extending_nn2"></a>37.1 Introduction</H2>
|
||||
<H2><a name="Extending_nn2"></a>38.1 Introduction</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -91,7 +91,7 @@ Also, this chapter is not meant to be a hand-holding tutorial. As a starting po
|
|||
you should probably look at one of SWIG's existing modules.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn3"></a>37.2 Prerequisites</H2>
|
||||
<H2><a name="Extending_nn3"></a>38.2 Prerequisites</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -121,7 +121,7 @@ obvious, but almost all SWIG directives as well as the low-level generation of
|
|||
wrapper code are driven by C++ datatypes.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn4"></a>37.3 The Big Picture</H2>
|
||||
<H2><a name="Extending_nn4"></a>38.3 The Big Picture</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -158,7 +158,7 @@ role in making the system work. For example, both typemaps and declaration anno
|
|||
based on pattern matching and interact heavily with the underlying type system.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn5"></a>37.4 Execution Model</H2>
|
||||
<H2><a name="Extending_nn5"></a>38.4 Execution Model</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -203,7 +203,7 @@ latter stage of compilation.
|
|||
The next few sections briefly describe some of these stages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn6"></a>37.4.1 Preprocessing</H3>
|
||||
<H3><a name="Extending_nn6"></a>38.4.1 Preprocessing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -284,7 +284,7 @@ been expanded as well as everything else that goes into the low-level
|
|||
construction of the wrapper code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn7"></a>37.4.2 Parsing</H3>
|
||||
<H3><a name="Extending_nn7"></a>38.4.2 Parsing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -385,7 +385,7 @@ returning a <tt>foo</tt> and taking types <tt>a</tt> and <tt>b</tt> as
|
|||
arguments).
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn8"></a>37.4.3 Parse Trees</H3>
|
||||
<H3><a name="Extending_nn8"></a>38.4.3 Parse Trees</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -640,7 +640,7 @@ $ swig -c++ -python -debug-module 4 example.i
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn9"></a>37.4.4 Attribute namespaces</H3>
|
||||
<H3><a name="Extending_nn9"></a>38.4.4 Attribute namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -659,7 +659,7 @@ that matches the name of the target language. For example, <tt>python:foo</tt>
|
|||
<tt>perl:foo</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn10"></a>37.4.5 Symbol Tables</H3>
|
||||
<H3><a name="Extending_nn10"></a>38.4.5 Symbol Tables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -750,7 +750,7 @@ example.i:5. Previous declaration is foo_i(int )
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn11"></a>37.4.6 The %feature directive</H3>
|
||||
<H3><a name="Extending_nn11"></a>38.4.6 The %feature directive</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -806,7 +806,7 @@ For example, the exception code above is simply
|
|||
stored without any modifications.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn12"></a>37.4.7 Code Generation</H3>
|
||||
<H3><a name="Extending_nn12"></a>38.4.7 Code Generation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -928,7 +928,7 @@ public :
|
|||
The role of these functions is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn13"></a>37.4.8 SWIG and XML</H3>
|
||||
<H3><a name="Extending_nn13"></a>38.4.8 SWIG and XML</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -941,7 +941,7 @@ internal data structures, it may be useful to keep XML in the back of
|
|||
your mind as a model.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn14"></a>37.5 Primitive Data Structures</H2>
|
||||
<H2><a name="Extending_nn14"></a>38.5 Primitive Data Structures</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -987,7 +987,7 @@ typedef Hash Typetab;
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn15"></a>37.5.1 Strings</H3>
|
||||
<H3><a name="Extending_nn15"></a>38.5.1 Strings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1128,7 +1128,7 @@ Returns the number of replacements made (if any).
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn16"></a>37.5.2 Hashes</H3>
|
||||
<H3><a name="Extending_nn16"></a>38.5.2 Hashes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1205,7 +1205,7 @@ Returns the list of hash table keys.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn17"></a>37.5.3 Lists</H3>
|
||||
<H3><a name="Extending_nn17"></a>38.5.3 Lists</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1294,7 +1294,7 @@ If <tt>t</tt> is not a standard object, it is assumed to be a <tt>char *</tt>
|
|||
and is used to create a String object.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn18"></a>37.5.4 Common operations</H3>
|
||||
<H3><a name="Extending_nn18"></a>38.5.4 Common operations</H3>
|
||||
|
||||
|
||||
The following operations are applicable to all datatypes.
|
||||
|
|
@ -1349,7 +1349,7 @@ objects and report errors.
|
|||
Gets the line number associated with <tt>x</tt>.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn19"></a>37.5.5 Iterating over Lists and Hashes</H3>
|
||||
<H3><a name="Extending_nn19"></a>38.5.5 Iterating over Lists and Hashes</H3>
|
||||
|
||||
|
||||
To iterate over the elements of a list or a hash table, the following functions are used:
|
||||
|
|
@ -1394,7 +1394,7 @@ for (j = First(j); j.item; j= Next(j)) {
|
|||
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn20"></a>37.5.6 I/O</H3>
|
||||
<H3><a name="Extending_nn20"></a>38.5.6 I/O</H3>
|
||||
|
||||
|
||||
Special I/O functions are used for all internal I/O. These operations
|
||||
|
|
@ -1531,7 +1531,7 @@ Similarly, the preprocessor and parser all operate on string-files.
|
|||
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn21"></a>37.6 Navigating and manipulating parse trees</H2>
|
||||
<H2><a name="Extending_nn21"></a>38.6 Navigating and manipulating parse trees</H2>
|
||||
|
||||
|
||||
Parse trees are built as collections of hash tables. Each node is a hash table in which
|
||||
|
|
@ -1665,7 +1665,7 @@ Deletes a node from the parse tree. Deletion reconnects siblings and properly u
|
|||
the parent so that sibling nodes are unaffected.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn22"></a>37.7 Working with attributes</H2>
|
||||
<H2><a name="Extending_nn22"></a>38.7 Working with attributes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1782,7 +1782,7 @@ the attribute is optional. <tt>Swig_restore()</tt> must always be called after
|
|||
function.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn23"></a>37.8 Type system</H2>
|
||||
<H2><a name="Extending_nn23"></a>38.8 Type system</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1791,7 +1791,7 @@ pointers, references, and pointers to members. A detailed discussion of
|
|||
type theory is impossible here. However, let's cover the highlights.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn24"></a>37.8.1 String encoding of types</H3>
|
||||
<H3><a name="Extending_nn24"></a>38.8.1 String encoding of types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1892,7 +1892,7 @@ make the final type, the two parts are just joined together using
|
|||
string concatenation.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn25"></a>37.8.2 Type construction</H3>
|
||||
<H3><a name="Extending_nn25"></a>38.8.2 Type construction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2061,7 +2061,7 @@ Returns the prefix of a type. For example, if <tt>ty</tt> is
|
|||
<tt>ty</tt> is unmodified.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn26"></a>37.8.3 Type tests</H3>
|
||||
<H3><a name="Extending_nn26"></a>38.8.3 Type tests</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2148,7 +2148,7 @@ Checks if <tt>ty</tt> is a varargs type.
|
|||
Checks if <tt>ty</tt> is a templatized type.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn27"></a>37.8.4 Typedef and inheritance</H3>
|
||||
<H3><a name="Extending_nn27"></a>38.8.4 Typedef and inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2250,7 +2250,7 @@ Fully reduces <tt>ty</tt> according to typedef rules. Resulting datatype
|
|||
will consist only of primitive typenames.
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn28"></a>37.8.5 Lvalues</H3>
|
||||
<H3><a name="Extending_nn28"></a>38.8.5 Lvalues</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2287,7 +2287,7 @@ Literal y; // type = 'Literal', ltype='p.char'
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn29"></a>37.8.6 Output functions</H3>
|
||||
<H3><a name="Extending_nn29"></a>38.8.6 Output functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2349,7 +2349,7 @@ SWIG, but is most commonly associated with type-descriptor objects
|
|||
that appear in wrappers (e.g., <tt>SWIGTYPE_p_double</tt>).
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn30"></a>37.9 Parameters</H2>
|
||||
<H2><a name="Extending_nn30"></a>38.9 Parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2448,7 +2448,7 @@ included. Used to emit prototypes.
|
|||
Returns the number of required (non-optional) arguments in <tt>p</tt>.
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_nn31"></a>37.10 Writing a Language Module</H2>
|
||||
<H2><a name="Extending_nn31"></a>38.10 Writing a Language Module</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2463,7 +2463,7 @@ describes the creation of a minimal Python module. You should be able to extra
|
|||
this to other languages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn32"></a>37.10.1 Execution model</H3>
|
||||
<H3><a name="Extending_nn32"></a>38.10.1 Execution model</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2473,7 +2473,7 @@ the parsing of command line options, all aspects of code generation are controll
|
|||
different methods of the <tt>Language</tt> that must be defined by your module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_starting_out"></a>37.10.2 Starting out</H3>
|
||||
<H3><a name="Extending_starting_out"></a>38.10.2 Starting out</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2581,7 +2581,7 @@ that activates your module. For example, <tt>swig -python foo.i</tt>. The
|
|||
messages from your new module should appear.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn34"></a>37.10.3 Command line options</H3>
|
||||
<H3><a name="Extending_nn34"></a>38.10.3 Command line options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2640,7 +2640,7 @@ to mark the option as valid. If you forget to do this, SWIG will terminate wit
|
|||
unrecognized command line option error.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn35"></a>37.10.4 Configuration and preprocessing</H3>
|
||||
<H3><a name="Extending_nn35"></a>38.10.4 Configuration and preprocessing</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2689,7 +2689,7 @@ an implementation file <tt>python.cxx</tt> and a configuration file
|
|||
<tt>python.swg</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn36"></a>37.10.5 Entry point to code generation</H3>
|
||||
<H3><a name="Extending_nn36"></a>38.10.5 Entry point to code generation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2747,7 +2747,7 @@ int Python::top(Node *n) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn37"></a>37.10.6 Module I/O and wrapper skeleton</H3>
|
||||
<H3><a name="Extending_nn37"></a>38.10.6 Module I/O and wrapper skeleton</H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to mgossage -->
|
||||
|
|
@ -2896,7 +2896,7 @@ functionWrapper : void Shape_y_set(Shape *self,double y)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Extending_nn38"></a>37.10.7 Low-level code generators</H3>
|
||||
<H3><a name="Extending_nn38"></a>38.10.7 Low-level code generators</H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to mgossage -->
|
||||
|
|
@ -3050,7 +3050,7 @@ but without the typemaps, there is still work to do.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Extending_configuration_files"></a>37.10.8 Configuration files</H3>
|
||||
<H3><a name="Extending_configuration_files"></a>38.10.8 Configuration files</H3>
|
||||
|
||||
|
||||
<!-- please report bugs in this section to ttn -->
|
||||
|
|
@ -3194,7 +3194,7 @@ politely displays the ignoring language message.
|
|||
</dl>
|
||||
|
||||
|
||||
<H3><a name="Extending_nn40"></a>37.10.9 Runtime support</H3>
|
||||
<H3><a name="Extending_nn40"></a>38.10.9 Runtime support</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3203,7 +3203,7 @@ Discuss the kinds of functions typically needed for SWIG runtime support (e.g.
|
|||
the SWIG files that implement those functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn41"></a>37.10.10 Standard library files</H3>
|
||||
<H3><a name="Extending_nn41"></a>38.10.10 Standard library files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3222,7 +3222,7 @@ The following are the minimum that are usually supported:
|
|||
Please copy these and modify for any new language.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_nn42"></a>37.10.11 User examples</H3>
|
||||
<H3><a name="Extending_nn42"></a>38.10.11 User examples</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3251,7 +3251,7 @@ during this process, see the section on <a href="#Extending_configuration_files"
|
|||
files</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_test_suite"></a>37.10.12 Test driven development and the test-suite</H3>
|
||||
<H3><a name="Extending_test_suite"></a>38.10.12 Test driven development and the test-suite</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3310,7 +3310,7 @@ It is therefore essential that the runtime tests are written in a manner that di
|
|||
but error/exception out with an error message on stderr on failure.
|
||||
</p>
|
||||
|
||||
<H4><a name="Extending_running_test_suite"></a>37.10.12.1 Running the test-suite</H4>
|
||||
<H4><a name="Extending_running_test_suite"></a>38.10.12.1 Running the test-suite</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3496,7 +3496,7 @@ The syntax for setting environment variables varies from one shell to the next,
|
|||
make ret_by_value.ctest SWIG_FEATURES="-debug-tmsearch"
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Extending_nn43"></a>37.10.13 Documentation</H3>
|
||||
<H3><a name="Extending_nn43"></a>38.10.13 Documentation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3528,7 +3528,7 @@ Some topics that you'll want to be sure to address include:
|
|||
if available.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Extending_prerequisites"></a>37.10.14 Prerequisites for adding a new language module to the SWIG distribution</H3>
|
||||
<H3><a name="Extending_prerequisites"></a>38.10.14 Prerequisites for adding a new language module to the SWIG distribution</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3585,7 +3585,7 @@ should be added should there be an area not already covered by
|
|||
the existing tests.
|
||||
</p>
|
||||
|
||||
<H3><a name="Extending_coding_style_guidelines"></a>37.10.15 Coding style guidelines</H3>
|
||||
<H3><a name="Extending_coding_style_guidelines"></a>38.10.15 Coding style guidelines</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3609,7 +3609,7 @@ The generated C/C++ code should also follow this style as close as possible. How
|
|||
should be avoided as unlike the SWIG developers, users will never have consistent tab settings.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_debugging_options"></a>37.11 Debugging Options</H2>
|
||||
<H2><a name="Extending_debugging_options"></a>38.11 Debugging Options</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3636,7 +3636,7 @@ There are various command line options which can aid debugging a SWIG interface
|
|||
The complete list of command line options for SWIG are available by running <tt>swig -help</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Extending_nn46"></a>37.12 Guide to parse tree nodes</H2>
|
||||
<H2><a name="Extending_nn46"></a>38.12 Guide to parse tree nodes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4044,7 +4044,7 @@ extern "X" { ... } declaration.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Extending_further_info"></a>37.13 Further Development Information</H2>
|
||||
<H2><a name="Extending_further_info"></a>38.13 Further Development Information</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Go"></a>21 SWIG and Go</H1>
|
||||
<H1><a name="Go"></a>22 SWIG and Go</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -43,7 +43,7 @@ the Go programming language
|
|||
see <a href="http://golang.org/">golang.org</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Go_overview"></a>21.1 Overview</H2>
|
||||
<H2><a name="Go_overview"></a>22.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -67,7 +67,7 @@ checking and runtime library are not used with Go. This should be
|
|||
borne in mind when reading the rest of the SWIG documentation.
|
||||
</p>
|
||||
|
||||
<H2><a name="Go_running_swig"></a>21.2 Running SWIG with Go</H2>
|
||||
<H2><a name="Go_running_swig"></a>22.2 Running SWIG with Go</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -76,7 +76,7 @@ default SWIG will generate code for the gc compilers. To generate
|
|||
code for gccgo, you should also use the <tt>-gccgo</tt> option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_commandline"></a>21.2.1 Additional Commandline Options</H3>
|
||||
<H3><a name="Go_commandline"></a>22.2.1 Additional Commandline Options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -129,7 +129,7 @@ swig -go -help
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Go_outputs"></a>21.2.2 Go Output Files</H3>
|
||||
<H3><a name="Go_outputs"></a>22.2.2 Go Output Files</H3>
|
||||
|
||||
|
||||
<p> When generating Go code, SWIG will generate the following
|
||||
|
|
@ -174,7 +174,7 @@ A typical command sequence would look like this:
|
|||
% 6l main.6
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Go_basic_tour"></a>21.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Go_basic_tour"></a>22.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -184,7 +184,7 @@ modifications have to occur. This section briefly covers the
|
|||
essential aspects of this wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_package"></a>21.3.1 Go Package Name</H3>
|
||||
<H3><a name="Go_package"></a>22.3.1 Go Package Name</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -194,7 +194,7 @@ directive. You may override this by using SWIG's <tt>-package</tt>
|
|||
command line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_names"></a>21.3.2 Go Names</H3>
|
||||
<H3><a name="Go_names"></a>22.3.2 Go Names</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -226,7 +226,7 @@ followed by that name, and the destructor will be
|
|||
named <tt>Delete</tt> followed by that name.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_constants"></a>21.3.3 Go Constants</H3>
|
||||
<H3><a name="Go_constants"></a>22.3.3 Go Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -234,7 +234,7 @@ C/C++ constants created via <tt>#define</tt> or the <tt>%constant</tt>
|
|||
directive become Go constants, declared with a <tt>const</tt>
|
||||
declaration.
|
||||
|
||||
<H3><a name="Go_enumerations"></a>21.3.4 Go Enumerations</H3>
|
||||
<H3><a name="Go_enumerations"></a>22.3.4 Go Enumerations</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -244,7 +244,7 @@ usual). The values of the enumeration will become variables in Go;
|
|||
code should avoid modifying those variables.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_classes"></a>21.3.5 Go Classes</H3>
|
||||
<H3><a name="Go_classes"></a>22.3.5 Go Classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -322,7 +322,7 @@ returns a go interface. If the returned pointer can be null, you can check
|
|||
for this by calling the Swigcptr() method.
|
||||
</p>
|
||||
|
||||
<H4><a name="Go_class_inheritance"></a>21.3.5.1 Go Class Inheritance</H4>
|
||||
<H4><a name="Go_class_inheritance"></a>22.3.5.1 Go Class Inheritance</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -334,7 +334,7 @@ Doing the reverse will require an explicit type assertion, which will
|
|||
be checked dynamically.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_templates"></a>21.3.6 Go Templates</H3>
|
||||
<H3><a name="Go_templates"></a>22.3.6 Go Templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -342,7 +342,7 @@ In order to use C++ templates in Go, you must tell SWIG to create
|
|||
wrappers for a particular template instantation. To do this, use
|
||||
the <tt>%template</tt> directive.
|
||||
|
||||
<H3><a name="Go_director_classes"></a>21.3.7 Go Director Classes</H3>
|
||||
<H3><a name="Go_director_classes"></a>22.3.7 Go Director Classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -385,7 +385,7 @@ method defined in Go. The Go code may of course call other methods on
|
|||
itself, and those methods may be defined either in Go or in C++.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_primitive_type_mappings"></a>21.3.8 Default Go primitive type mappings</H3>
|
||||
<H3><a name="Go_primitive_type_mappings"></a>22.3.8 Default Go primitive type mappings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -492,7 +492,7 @@ that typemap, or add new values, to control how C/C++ types are mapped
|
|||
into Go types.
|
||||
</p>
|
||||
|
||||
<H3><a name="Go_output_arguments"></a>21.3.9 Output arguments</H3>
|
||||
<H3><a name="Go_output_arguments"></a>22.3.9 Output arguments</H3>
|
||||
|
||||
|
||||
<p>Because of limitations in the way output arguments are processed in swig,
|
||||
|
|
@ -503,7 +503,7 @@ argument.</p>
|
|||
|
||||
<p>For example, suppose you were trying to wrap the modf() function in the
|
||||
C math library which splits x into integral and fractional parts (and
|
||||
returns the integer part in one of its parameters):<p>
|
||||
returns the integer part in one of its parameters):</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
double modf(double x, double *ip);
|
||||
|
|
@ -536,7 +536,7 @@ some <a href="#Embedded_go_code">additional functions written in go</a> that
|
|||
hide the ugly details.</p>
|
||||
|
||||
<p>There are no <code>char *OUTPUT</code> typemaps. However you can
|
||||
apply the <code>signed char *</code> typemaps instead:<p>
|
||||
apply the <code>signed char *</code> typemaps instead:</p>
|
||||
<div class="code">
|
||||
<pre>
|
||||
%include <typemaps.i>
|
||||
|
|
@ -545,7 +545,8 @@ void f(char *output);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Go_adding_additional_code"></a>21.3.10 Adding additional go code</H3>
|
||||
<H3><a name="Go_adding_additional_code"></a>22.3.10 Adding additional go code</H3>
|
||||
|
||||
|
||||
<p>Often the APIs generated by swig are not very natural in go, especially if
|
||||
there are output arguments. You can
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Guile"></a>22 SWIG and Guile</H1>
|
||||
<H1><a name="Guile"></a>23 SWIG and Guile</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -47,7 +47,7 @@
|
|||
<p>
|
||||
This section details guile-specific support in SWIG.
|
||||
|
||||
<H2><a name="Guile_nn2"></a>22.1 Meaning of "Module"</H2>
|
||||
<H2><a name="Guile_nn2"></a>23.1 Meaning of "Module"</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -55,7 +55,7 @@ There are three different concepts of "module" involved, defined
|
|||
separately for SWIG, Guile, and Libtool. To avoid horrible confusion,
|
||||
we explicitly prefix the context, e.g., "guile-module".
|
||||
|
||||
<H2><a name="Guile_nn3"></a>22.2 Using the SCM or GH Guile API</H2>
|
||||
<H2><a name="Guile_nn3"></a>23.2 Using the SCM or GH Guile API</H2>
|
||||
|
||||
|
||||
<p>The guile module can currently export wrapper files that use the guile GH interface or the
|
||||
|
|
@ -103,7 +103,7 @@ for the specific API. Currently only the guile language module has created a ma
|
|||
but there is no reason other languages (like mzscheme or chicken) couldn't also use this.
|
||||
If that happens, there is A LOT less code duplication in the standard typemaps.</p>
|
||||
|
||||
<H2><a name="Guile_nn4"></a>22.3 Linkage</H2>
|
||||
<H2><a name="Guile_nn4"></a>23.3 Linkage</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -111,7 +111,7 @@ Guile support is complicated by a lack of user community cohesiveness,
|
|||
which manifests in multiple shared-library usage conventions. A set of
|
||||
policies implementing a usage convention is called a <b>linkage</b>.
|
||||
|
||||
<H3><a name="Guile_nn5"></a>22.3.1 Simple Linkage</H3>
|
||||
<H3><a name="Guile_nn5"></a>23.3.1 Simple Linkage</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -206,7 +206,7 @@ placed between the <code>define-module</code> form and the
|
|||
<code>SWIG_init</code> via a preprocessor define to avoid symbol
|
||||
clashes. For this case, however, passive linkage is available.
|
||||
|
||||
<H3><a name="Guile_nn6"></a>22.3.2 Passive Linkage</H3>
|
||||
<H3><a name="Guile_nn6"></a>23.3.2 Passive Linkage</H3>
|
||||
|
||||
|
||||
<p>Passive linkage is just like simple linkage, but it generates an
|
||||
|
|
@ -216,7 +216,7 @@ package name (see below).
|
|||
<p>You should use passive linkage rather than simple linkage when you
|
||||
are using multiple modules.
|
||||
|
||||
<H3><a name="Guile_nn7"></a>22.3.3 Native Guile Module Linkage</H3>
|
||||
<H3><a name="Guile_nn7"></a>23.3.3 Native Guile Module Linkage</H3>
|
||||
|
||||
|
||||
<p>SWIG can also generate wrapper code that does all the Guile module
|
||||
|
|
@ -257,7 +257,7 @@ Newer Guile versions have a shorthand procedure for this:
|
|||
</div>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Guile_nn8"></a>22.3.4 Old Auto-Loading Guile Module Linkage</H3>
|
||||
<H3><a name="Guile_nn8"></a>23.3.4 Old Auto-Loading Guile Module Linkage</H3>
|
||||
|
||||
|
||||
<p>Guile used to support an autoloading facility for object-code
|
||||
|
|
@ -283,7 +283,7 @@ option, SWIG generates an exported module initialization function with
|
|||
an appropriate name.
|
||||
|
||||
|
||||
<H3><a name="Guile_nn9"></a>22.3.5 Hobbit4D Linkage</H3>
|
||||
<H3><a name="Guile_nn9"></a>23.3.5 Hobbit4D Linkage</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -308,7 +308,7 @@ my/lib/libfoo.so.X.Y.Z and friends. This scheme is still very
|
|||
experimental; the (hobbit4d link) conventions are not well understood.
|
||||
</p>
|
||||
|
||||
<H2><a name="Guile_nn10"></a>22.4 Underscore Folding</H2>
|
||||
<H2><a name="Guile_nn10"></a>23.4 Underscore Folding</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -320,7 +320,7 @@ complained so far.
|
|||
<code>%rename</code> to specify the Guile name of the wrapped
|
||||
functions and variables (see CHANGES).
|
||||
|
||||
<H2><a name="Guile_nn11"></a>22.5 Typemaps</H2>
|
||||
<H2><a name="Guile_nn11"></a>23.5 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -412,7 +412,7 @@ constant will appear as a scheme variable. See
|
|||
<a href="Customization.html#Customization_features">Features and the %feature directive</a>
|
||||
for info on how to apply the %feature.</p>
|
||||
|
||||
<H2><a name="Guile_nn12"></a>22.6 Representation of pointers as smobs</H2>
|
||||
<H2><a name="Guile_nn12"></a>23.6 Representation of pointers as smobs</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -433,7 +433,7 @@ representing the expected pointer type. See also
|
|||
If the Scheme object passed was not a SWIG smob representing a compatible
|
||||
pointer, a <code>wrong-type-arg</code> exception is raised.
|
||||
|
||||
<H3><a name="Guile_nn13"></a>22.6.1 GH Smobs</H3>
|
||||
<H3><a name="Guile_nn13"></a>23.6.1 GH Smobs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -462,7 +462,7 @@ that created them, so the first module we check will most likely be correct.
|
|||
Once we have a swig_type_info structure, we loop through the linked list of
|
||||
casts, using pointer comparisons.</p>
|
||||
|
||||
<H3><a name="Guile_nn14"></a>22.6.2 SCM Smobs</H3>
|
||||
<H3><a name="Guile_nn14"></a>23.6.2 SCM Smobs</H3>
|
||||
|
||||
|
||||
<p>The SCM interface (using the "-scm" argument to swig) uses swigrun.swg.
|
||||
|
|
@ -477,7 +477,7 @@ in the smob tag. If a generated GOOPS module has been loaded, smobs will be wra
|
|||
GOOPS class.</p>
|
||||
|
||||
|
||||
<H3><a name="Guile_nn15"></a>22.6.3 Garbage Collection</H3>
|
||||
<H3><a name="Guile_nn15"></a>23.6.3 Garbage Collection</H3>
|
||||
|
||||
|
||||
<p>Garbage collection is a feature of the new SCM interface, and it is automatically included
|
||||
|
|
@ -491,7 +491,7 @@ is exactly like described in <a href="Customization.html#Customization_ownership
|
|||
Object ownership and %newobject</a> in the SWIG manual. All typemaps use an $owner var, and
|
||||
the guile module replaces $owner with 0 or 1 depending on feature:new.</p>
|
||||
|
||||
<H2><a name="Guile_nn16"></a>22.7 Exception Handling</H2>
|
||||
<H2><a name="Guile_nn16"></a>23.7 Exception Handling</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -517,7 +517,7 @@ mapping:
|
|||
The default when not specified here is to use "swig-error".
|
||||
See Lib/exception.i for details.
|
||||
|
||||
<H2><a name="Guile_nn17"></a>22.8 Procedure documentation</H2>
|
||||
<H2><a name="Guile_nn17"></a>23.8 Procedure documentation</H2>
|
||||
|
||||
|
||||
<p>If invoked with the command-line option <code>-procdoc
|
||||
|
|
@ -553,7 +553,7 @@ like this:
|
|||
typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
|
||||
details.
|
||||
|
||||
<H2><a name="Guile_nn18"></a>22.9 Procedures with setters</H2>
|
||||
<H2><a name="Guile_nn18"></a>23.9 Procedures with setters</H2>
|
||||
|
||||
|
||||
<p>For global variables, SWIG creates a single wrapper procedure
|
||||
|
|
@ -581,7 +581,7 @@ struct members, the procedures <code>(<var>struct</var>-<var>member</var>-get
|
|||
pointer)</code> and <code>(<var>struct-member</var>-set pointer
|
||||
value)</code> are <em>not</em> generated.
|
||||
|
||||
<H2><a name="Guile_nn19"></a>22.10 GOOPS Proxy Classes</H2>
|
||||
<H2><a name="Guile_nn19"></a>23.10 GOOPS Proxy Classes</H2>
|
||||
|
||||
|
||||
<p>SWIG can also generate classes and generic functions for use with
|
||||
|
|
@ -730,7 +730,7 @@ Notice that <Foo> is used before it is defined. The fix is to just put th
|
|||
<code>%import "foo.h"</code> before the <code>%inline</code> block.
|
||||
</p>
|
||||
|
||||
<H3><a name="Guile_nn20"></a>22.10.1 Naming Issues</H3>
|
||||
<H3><a name="Guile_nn20"></a>23.10.1 Naming Issues</H3>
|
||||
|
||||
|
||||
<p>As you can see in the example above, there are potential naming conflicts. The default exported
|
||||
|
|
@ -767,7 +767,7 @@ guile-modules. For example,</p>
|
|||
(use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:)))
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Guile_nn21"></a>22.10.2 Linking</H3>
|
||||
<H3><a name="Guile_nn21"></a>23.10.2 Linking</H3>
|
||||
|
||||
|
||||
<p>The guile-modules generated above all need to be linked together. GOOPS support requires
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Java"></a>23 SWIG and Java</H1>
|
||||
<H1><a name="Java"></a>24 SWIG and Java</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -142,7 +142,7 @@
|
|||
<li><a href="#Java_performance">Performance concerns and hints</a>
|
||||
<li><a href="#Java_debugging">Debugging</a>
|
||||
</ul>
|
||||
<li><a href="#Java_examples">Examples</a>
|
||||
<li><a href="#Java_examples">Java Examples</a>
|
||||
</ul>
|
||||
</div>
|
||||
<!-- INDEX -->
|
||||
|
|
@ -155,7 +155,7 @@ It covers most SWIG features, but certain low-level details are covered in less
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Java_overview"></a>23.1 Overview</H2>
|
||||
<H2><a name="Java_overview"></a>24.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -190,7 +190,7 @@ Various customisation tips and techniques using SWIG directives are covered.
|
|||
The latter sections cover the advanced techniques of using typemaps for complete control of the wrapping process.
|
||||
</p>
|
||||
|
||||
<H2><a name="Java_preliminaries"></a>23.2 Preliminaries</H2>
|
||||
<H2><a name="Java_preliminaries"></a>24.2 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -206,7 +206,11 @@ Run <tt>make -k check</tt> from the SWIG root directory after installing SWIG on
|
|||
The Java module requires your system to support shared libraries and dynamic loading.
|
||||
This is the commonly used method to load JNI code so your system will more than likely support this.</p>
|
||||
|
||||
<H3><a name="Java_running_swig"></a>23.2.1 Running SWIG</H3>
|
||||
<p>
|
||||
Android uses Java JNI and also works with SWIG. Please read the <a href="Android.html">Android chapter</a> in conjunction with this one if you are targeting Android.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_running_swig"></a>24.2.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -265,7 +269,7 @@ The following sections have further practical examples and details on how you mi
|
|||
compiling and using the generated files.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_commandline"></a>23.2.2 Additional Commandline Options</H3>
|
||||
<H3><a name="Java_commandline"></a>24.2.2 Additional Commandline Options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -302,7 +306,7 @@ swig -java -help
|
|||
Their use will become clearer by the time you have finished reading this section on SWIG and Java.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_getting_right_headers"></a>23.2.3 Getting the right header files</H3>
|
||||
<H3><a name="Java_getting_right_headers"></a>24.2.3 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -317,7 +321,7 @@ They are usually in directories like this:</p>
|
|||
<p>
|
||||
The exact location may vary on your machine, but the above locations are typical. </p>
|
||||
|
||||
<H3><a name="Java_compiling_dynamic"></a>23.2.4 Compiling a dynamic module</H3>
|
||||
<H3><a name="Java_compiling_dynamic"></a>24.2.4 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -353,7 +357,7 @@ The name of the shared library output file is important.
|
|||
If the name of your SWIG module is "<tt>example</tt>", the name of the corresponding shared library file should be "<tt>libexample.so</tt>" (or equivalent depending on your machine, see <a href="#Java_dynamic_linking_problems">Dynamic linking problems</a> for more information).
|
||||
The name of the module is specified using the <tt>%module</tt> directive or<tt> -module</tt> command line option.</p>
|
||||
|
||||
<H3><a name="Java_using_module"></a>23.2.5 Using your module</H3>
|
||||
<H3><a name="Java_using_module"></a>24.2.5 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -364,7 +368,7 @@ To load your shared native library module in Java, simply use Java's <tt>System.
|
|||
|
||||
public class runme {
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
|
||||
public static void main(String argv[]) {
|
||||
|
|
@ -388,7 +392,7 @@ $
|
|||
If it doesn't work have a look at the following section which discusses problems loading the shared library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_dynamic_linking_problems"></a>23.2.6 Dynamic linking problems</H3>
|
||||
<H3><a name="Java_dynamic_linking_problems"></a>24.2.6 Dynamic linking problems</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -475,7 +479,7 @@ The following section also contains some C++ specific linking problems and solut
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_compilation_problems_cpp"></a>23.2.7 Compilation problems and compiling with C++</H3>
|
||||
<H3><a name="Java_compilation_problems_cpp"></a>24.2.7 Compilation problems and compiling with C++</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -528,7 +532,7 @@ Finally make sure the version of JDK header files matches the version of Java th
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_building_windows"></a>23.2.8 Building on Windows</H3>
|
||||
<H3><a name="Java_building_windows"></a>24.2.8 Building on Windows</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -537,7 +541,7 @@ You will want to produce a DLL that can be loaded by the Java Virtual Machine.
|
|||
This section covers the process of using SWIG with Microsoft Visual C++ 6 although the procedure may be similar with other compilers.
|
||||
In order for everything to work, you will need to have a JDK installed on your machine in order to read the JNI header files.</p>
|
||||
|
||||
<H4><a name="Java_visual_studio"></a>23.2.8.1 Running SWIG from Visual Studio</H4>
|
||||
<H4><a name="Java_visual_studio"></a>24.2.8.1 Running SWIG from Visual Studio</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -576,7 +580,7 @@ To run the native code in the DLL (example.dll), make sure that it is in your pa
|
|||
If the library fails to load have a look at <a href="#Java_dynamic_linking_problems">Dynamic linking problems</a>.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_nmake"></a>23.2.8.2 Using NMAKE</H4>
|
||||
<H4><a name="Java_nmake"></a>24.2.8.2 Using NMAKE</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -635,7 +639,7 @@ Of course you may want to make changes for it to work for C++ by adding in the -
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Java_basic_tour"></a>23.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Java_basic_tour"></a>24.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -645,7 +649,7 @@ variables are wrapped with JavaBean type getters and setters and so forth.
|
|||
This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_module_packages_classes"></a>23.3.1 Modules, packages and generated Java classes</H3>
|
||||
<H3><a name="Java_module_packages_classes"></a>24.3.1 Modules, packages and generated Java classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -681,7 +685,7 @@ swig -java -package com.bloggs.swig -outdir com/bloggs/swig example.i
|
|||
SWIG won't create the directory, so make sure it exists beforehand.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_functions"></a>23.3.2 Functions</H3>
|
||||
<H3><a name="Java_functions"></a>24.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -715,7 +719,7 @@ System.out.println(example.fact(4));
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Java_global_variables"></a>23.3.3 Global variables</H3>
|
||||
<H3><a name="Java_global_variables"></a>24.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -802,7 +806,7 @@ extern char *path; // Read-only (due to %immutable)
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Java_constants"></a>23.3.4 Constants</H3>
|
||||
<H3><a name="Java_constants"></a>24.3.4 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -942,7 +946,7 @@ Or if you decide this practice isn't so bad and your own class implements <tt>ex
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_enumerations"></a>23.3.5 Enumerations</H3>
|
||||
<H3><a name="Java_enumerations"></a>24.3.5 Enumerations</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -956,7 +960,7 @@ The final two approaches use simple integers for each enum item.
|
|||
Before looking at the various approaches for wrapping named C/C++ enums, anonymous enums are considered.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_anonymous_enums"></a>23.3.5.1 Anonymous enums</H4>
|
||||
<H4><a name="Java_anonymous_enums"></a>24.3.5.1 Anonymous enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1019,7 +1023,7 @@ As in the case of constants, you can access them through either the module class
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Java_typesafe_enums"></a>23.3.5.2 Typesafe enums</H4>
|
||||
<H4><a name="Java_typesafe_enums"></a>24.3.5.2 Typesafe enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1113,7 +1117,7 @@ When upgrading to JDK 1.5 or later, proper Java enums could be used instead, wit
|
|||
The following section details proper Java enum generation.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_proper_enums"></a>23.3.5.3 Proper Java enums</H4>
|
||||
<H4><a name="Java_proper_enums"></a>24.3.5.3 Proper Java enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1166,7 +1170,7 @@ The additional support methods need not be generated if none of the enum items h
|
|||
<a href="#Java_simpler_enum_classes">Simpler Java enums for enums without initializers</a> section.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_typeunsafe_enums"></a>23.3.5.4 Type unsafe enums</H4>
|
||||
<H4><a name="Java_typeunsafe_enums"></a>24.3.5.4 Type unsafe enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1214,7 +1218,7 @@ Note that unlike typesafe enums, this approach requires users to mostly use diff
|
|||
Thus the upgrade path to proper enums provided in JDK 1.5 is more painful.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_simple_enums"></a>23.3.5.5 Simple enums</H4>
|
||||
<H4><a name="Java_simple_enums"></a>24.3.5.5 Simple enums</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1233,7 +1237,7 @@ SWIG-1.3.21 and earlier versions wrapped all enums using this approach.
|
|||
The type unsafe approach is preferable to this one and this simple approach is only included for backwards compatibility with these earlier versions of SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_pointers"></a>23.3.6 Pointers</H3>
|
||||
<H3><a name="Java_pointers"></a>24.3.6 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1321,7 +1325,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
|
|||
a NULL pointer if the conversion can't be performed.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_structures"></a>23.3.7 Structures</H3>
|
||||
<H3><a name="Java_structures"></a>24.3.7 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1489,7 +1493,7 @@ x.setA(3); // Modify x.a - this is the same as b.f.a
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Java_classes"></a>23.3.8 C++ classes</H3>
|
||||
<H3><a name="Java_classes"></a>24.3.8 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1552,7 +1556,7 @@ int bar = Spam.getBar();
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Java_inheritance"></a>23.3.9 C++ inheritance</H3>
|
||||
<H3><a name="Java_inheritance"></a>24.3.9 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1613,7 +1617,7 @@ Note that Java does not support multiple inheritance so any multiple inheritance
|
|||
A warning is given when multiple inheritance is detected and only the first base class is used.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_pointers_refs_arrays"></a>23.3.10 Pointers, references, arrays and pass by value</H3>
|
||||
<H3><a name="Java_pointers_refs_arrays"></a>24.3.10 Pointers, references, arrays and pass by value</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1668,7 +1672,7 @@ to hold the result and a pointer is returned (Java will release this memory
|
|||
when the returned object's finalizer is run by the garbage collector).
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_null_pointers"></a>23.3.10.1 Null pointers</H4>
|
||||
<H4><a name="Java_null_pointers"></a>24.3.10.1 Null pointers</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1692,7 +1696,7 @@ For <tt>spam1</tt> and <tt>spam4</tt> above the Java <tt>null</tt> gets translat
|
|||
The converse also occurs, that is, NULL pointers are translated into <tt>null</tt> Java objects when returned from a C/C++ function.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_overloaded_functions"></a>23.3.11 C++ overloaded functions</H3>
|
||||
<H3><a name="Java_overloaded_functions"></a>24.3.11 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1807,7 +1811,7 @@ void spam(unsigned short); // Ignored
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Java_default_arguments"></a>23.3.12 C++ default arguments</H3>
|
||||
<H3><a name="Java_default_arguments"></a>24.3.12 C++ default arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1850,7 +1854,7 @@ Further details on default arguments and how to restore this approach are given
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_namespaces"></a>23.3.13 C++ namespaces</H3>
|
||||
<H3><a name="Java_namespaces"></a>24.3.13 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1930,7 +1934,12 @@ in an unnamed package.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Java_templates"></a>23.3.14 C++ templates</H3>
|
||||
<p>
|
||||
If the resulting use of the nspace feature and hence packages results in a proxy class in one package deriving or using a proxy class from another package,
|
||||
you will need to open up the visibility for the pointer constructor and <tt>getCPtr</tt> method from the default 'protected' to 'public' with the <tt>SWIG_JAVABODY_PROXY</tt> macro. See <a href="#Java_code_typemaps">Java code typemaps</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_templates"></a>24.3.14 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1979,7 +1988,7 @@ Obviously, there is more to template wrapping than shown in this example.
|
|||
More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a> chapter.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_smart_pointers"></a>23.3.15 C++ Smart Pointers</H3>
|
||||
<H3><a name="Java_smart_pointers"></a>24.3.15 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2063,7 +2072,7 @@ Foo f = p.__deref__(); // Returns underlying Foo *
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Java_further_details"></a>23.4 Further details on the generated Java classes</H2>
|
||||
<H2><a name="Java_further_details"></a>24.4 Further details on the generated Java classes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2078,7 +2087,7 @@ Finally enum classes are covered.
|
|||
First, the crucial intermediary JNI class is considered.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_imclass"></a>23.4.1 The intermediary JNI class</H3>
|
||||
<H3><a name="Java_imclass"></a>24.4.1 The intermediary JNI class</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2198,7 +2207,7 @@ If <tt>name</tt> is the same as <tt>modulename</tt> then the module class name g
|
|||
from <tt>modulename</tt> to <tt>modulenameModule</tt>.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_imclass_pragmas"></a>23.4.1.1 The intermediary JNI class pragmas</H4>
|
||||
<H4><a name="Java_imclass_pragmas"></a>24.4.1.1 The intermediary JNI class pragmas</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2277,7 +2286,7 @@ For example, let's change the intermediary JNI class access to just the default
|
|||
All the methods in the intermediary JNI class will then not be callable outside of the package as the method modifiers have been changed from public access to default access. This is useful if you want to prevent users calling these low level functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_module_class"></a>23.4.2 The Java module class</H3>
|
||||
<H3><a name="Java_module_class"></a>24.4.2 The Java module class</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2308,7 +2317,7 @@ example.egg(new Foo());
|
|||
The primary reason for having the module class wrapping the calls in the intermediary JNI class is to implement static type checking. In this case only a <tt>Foo</tt> can be passed to the <tt>egg</tt> function, whereas any <tt>long</tt> can be passed to the <tt>egg</tt> function in the intermediary JNI class.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_module_class_pragmas"></a>23.4.2.1 The Java module class pragmas</H4>
|
||||
<H4><a name="Java_module_class_pragmas"></a>24.4.2.1 The Java module class pragmas</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2359,7 +2368,7 @@ See <a href="#Java_imclass_pragmas">The intermediary JNI class pragmas</a> secti
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_proxy_classes"></a>23.4.3 Java proxy classes</H3>
|
||||
<H3><a name="Java_proxy_classes"></a>24.4.3 Java proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2379,7 +2388,7 @@ public class Foo {
|
|||
swigCPtr = cPtr;
|
||||
}
|
||||
|
||||
public static long getCPtr(Foo obj) {
|
||||
protected static long getCPtr(Foo obj) {
|
||||
return (obj == null) ? 0 : obj.swigCPtr;
|
||||
}
|
||||
|
||||
|
|
@ -2435,7 +2444,7 @@ int y = f.spam(5, new Foo());
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Java_memory_management"></a>23.4.3.1 Memory management</H4>
|
||||
<H4><a name="Java_memory_management"></a>24.4.3.1 Memory management</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2597,7 +2606,7 @@ and
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Java_inheritance_mirroring"></a>23.4.3.2 Inheritance</H4>
|
||||
<H4><a name="Java_inheritance_mirroring"></a>24.4.3.2 Inheritance</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2630,7 +2639,7 @@ public class Base {
|
|||
swigCPtr = cPtr;
|
||||
}
|
||||
|
||||
public static long getCPtr(Base obj) {
|
||||
protected static long getCPtr(Base obj) {
|
||||
return (obj == null) ? 0 : obj.swigCPtr;
|
||||
}
|
||||
|
||||
|
|
@ -2670,7 +2679,7 @@ public class Derived extends Base {
|
|||
swigCPtr = cPtr;
|
||||
}
|
||||
|
||||
public static long getCPtr(Derived obj) {
|
||||
protected static long getCPtr(Derived obj) {
|
||||
return (obj == null) ? 0 : obj.swigCPtr;
|
||||
}
|
||||
|
||||
|
|
@ -2713,7 +2722,7 @@ However, true cross language polymorphism can be achieved using the <a href="#Ja
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Java_proxy_classes_gc"></a>23.4.3.3 Proxy classes and garbage collection</H4>
|
||||
<H4><a name="Java_proxy_classes_gc"></a>24.4.3.3 Proxy classes and garbage collection</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2796,7 +2805,7 @@ The section on <a href="#Java_typemaps">Java typemaps</a> details how to specify
|
|||
See the <a href="http://www.devx.com/Java/Article/30192">How to Handle Java Finalization's Memory-Retention Issues</a> article for alternative approaches to managing memory by avoiding finalizers altogether.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_pgcpp"></a>23.4.3.4 The premature garbage collection prevention parameter for proxy class marshalling</H4>
|
||||
<H4><a name="Java_pgcpp"></a>24.4.3.4 The premature garbage collection prevention parameter for proxy class marshalling</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2918,7 +2927,7 @@ For example:
|
|||
<b>Compatibility note:</b> The generation of this additional parameter did not occur in versions prior to SWIG-1.3.30.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_multithread_libraries"></a>23.4.3.5 Single threaded applications and thread safety</H4>
|
||||
<H4><a name="Java_multithread_libraries"></a>24.4.3.5 Single threaded applications and thread safety</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2949,7 +2958,7 @@ public class Test {
|
|||
swigCPtr = cPtr;
|
||||
}
|
||||
|
||||
public static long getCPtr(Test obj) {
|
||||
protected static long getCPtr(Test obj) {
|
||||
return (obj == null) ? 0 : obj.swigCPtr;
|
||||
}
|
||||
|
||||
|
|
@ -3006,7 +3015,7 @@ for (int i=0; i<100000; i++) {
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Java_type_wrapper_classes"></a>23.4.4 Type wrapper classes</H3>
|
||||
<H3><a name="Java_type_wrapper_classes"></a>24.4.4 Type wrapper classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3093,7 +3102,7 @@ public static void spam(SWIGTYPE_p_int x, SWIGTYPE_p_int y, int z) { ... }
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Java_enum_classes"></a>23.4.5 Enum classes</H3>
|
||||
<H3><a name="Java_enum_classes"></a>24.4.5 Enum classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3102,7 +3111,7 @@ The <a href="#Java_enumerations">Enumerations</a> section discussed these but om
|
|||
The following sub-sections detail the various types of enum classes that can be generated.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_typesafe_enums_classes"></a>23.4.5.1 Typesafe enum classes</H4>
|
||||
<H4><a name="Java_typesafe_enums_classes"></a>24.4.5.1 Typesafe enum classes</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3186,7 +3195,7 @@ The <tt>swigValue</tt> method is used for marshalling in the other direction.
|
|||
The <tt>toString</tt> method is overridden so that the enum name is available.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_proper_enums_classes"></a>23.4.5.2 Proper Java enum classes</H4>
|
||||
<H4><a name="Java_proper_enums_classes"></a>24.4.5.2 Proper Java enum classes</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3264,7 +3273,7 @@ These needn't be generated if the enum being wrapped does not have any initializ
|
|||
<a href="#Java_simpler_enum_classes">Simpler Java enums for enums without initializers</a> section describes how typemaps can be used to achieve this.
|
||||
</p>
|
||||
|
||||
<H4><a name="Java_typeunsafe_enums_classes"></a>23.4.5.3 Type unsafe enum classes</H4>
|
||||
<H4><a name="Java_typeunsafe_enums_classes"></a>24.4.5.3 Type unsafe enum classes</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3295,7 +3304,7 @@ public final class Beverage {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Java_directors"></a>23.5 Cross language polymorphism using directors</H2>
|
||||
<H2><a name="Java_directors"></a>24.5 Cross language polymorphism using directors</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3317,7 +3326,7 @@ The upshot is that C++ classes can be extended in Java and from C++ these extens
|
|||
Neither C++ code nor Java code needs to know where a particular method is implemented: the combination of proxy classes, director classes, and C wrapper functions transparently takes care of all the cross-language method routing.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_enabling_directors"></a>23.5.1 Enabling directors</H3>
|
||||
<H3><a name="Java_enabling_directors"></a>24.5.1 Enabling directors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3388,7 +3397,7 @@ public:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Java_directors_classes"></a>23.5.2 Director classes</H3>
|
||||
<H3><a name="Java_directors_classes"></a>24.5.2 Director classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3415,7 +3424,7 @@ If the correct implementation is in Java, the Java API is used to call the metho
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_directors_overhead"></a>23.5.3 Overhead and code bloat</H3>
|
||||
<H3><a name="Java_directors_overhead"></a>24.5.3 Overhead and code bloat</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3433,7 +3442,7 @@ This situation can be optimized by selectively enabling director methods (using
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_directors_example"></a>23.5.4 Simple directors example</H3>
|
||||
<H3><a name="Java_directors_example"></a>24.5.4 Simple directors example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3461,7 +3470,7 @@ void callup(DirectorBase *director) {
|
|||
<p>
|
||||
The following <code>DirectorDerived</code> Java class is derived from the Java proxy class <code>DirectorBase</code> and overrides <code>upcall_method()</code>.
|
||||
When C++ code invokes <code>upcall_method()</code>, the SWIG-generated C++ code redirects the call via JNI to the Java <code>DirectorDerived</code> subclass.
|
||||
Naturally, the SWIG generated C++ code and the generated Java intermediate class marshal and convert arguments between C++ and Java when needed.
|
||||
Naturally, the SWIG generated C++ code and the generated Java intermediary class marshal and convert arguments between C++ and Java when needed.
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -3498,7 +3507,7 @@ DirectorDerived::upcall_method() invoked.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Java_directors_threading"></a>23.5.5 Director threading issues</H3>
|
||||
<H3><a name="Java_directors_threading"></a>24.5.5 Director threading issues</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3518,7 +3527,7 @@ Macros can be defined on the commandline when compiling your C++ code, or altern
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Java_allprotected"></a>23.6 Accessing protected members</H2>
|
||||
<H2><a name="Java_allprotected"></a>24.6 Accessing protected members</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3614,7 +3623,7 @@ class MyProtectedBase extends ProtectedBase
|
|||
|
||||
|
||||
|
||||
<H2><a name="Java_common_customization"></a>23.7 Common customization features</H2>
|
||||
<H2><a name="Java_common_customization"></a>24.7 Common customization features</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3626,7 +3635,7 @@ be awkward. This section describes some common SWIG features that are used
|
|||
to improve the interface to existing C/C++ code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_helper_functions"></a>23.7.1 C/C++ helper functions</H3>
|
||||
<H3><a name="Java_helper_functions"></a>24.7.1 C/C++ helper functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3692,7 +3701,7 @@ hard to implement. It is possible to improve on this using Java code, typemaps,
|
|||
customization features as covered in later sections, but sometimes helper functions are a quick and easy solution to difficult cases.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_class_extension"></a>23.7.2 Class extension with %extend</H3>
|
||||
<H3><a name="Java_class_extension"></a>24.7.2 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3755,7 +3764,7 @@ Vector(2,3,4)
|
|||
in any way---the extensions only show up in the Java interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_exception_handling"></a>23.7.3 Exception handling with %exception and %javaexception</H3>
|
||||
<H3><a name="Java_exception_handling"></a>24.7.3 Exception handling with %exception and %javaexception</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3914,7 +3923,7 @@ to raise exceptions. See the <a href="Library.html#Library">SWIG Library</a> ch
|
|||
The typemap example <a href="#Java_exception_typemap">Handling C++ exception specifications as Java exceptions</a> provides further exception handling capabilities.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_method_access"></a>23.7.4 Method access with %javamethodmodifiers</H3>
|
||||
<H3><a name="Java_method_access"></a>24.7.4 Method access with %javamethodmodifiers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3940,7 +3949,7 @@ protected static void protect_me() {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Java_tips_techniques"></a>23.8 Tips and techniques</H2>
|
||||
<H2><a name="Java_tips_techniques"></a>24.8 Tips and techniques</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3950,7 +3959,7 @@ strings and arrays. This chapter discusses the common techniques for
|
|||
solving these problems.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_input_output_parameters"></a>23.8.1 Input and output parameters using primitive pointers and references</H3>
|
||||
<H3><a name="Java_input_output_parameters"></a>24.8.1 Input and output parameters using primitive pointers and references</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4124,7 +4133,7 @@ void foo(Bar *OUTPUT);
|
|||
will not have the intended effect since <tt>typemaps.i</tt> does not define an OUTPUT rule for <tt>Bar</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_simple_pointers"></a>23.8.2 Simple pointers</H3>
|
||||
<H3><a name="Java_simple_pointers"></a>24.8.2 Simple pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4190,7 +4199,7 @@ System.out.println("3 + 4 = " + result);
|
|||
See the <a href="Library.html#Library">SWIG Library</a> chapter for further details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_c_arrays"></a>23.8.3 Wrapping C arrays with Java arrays</H3>
|
||||
<H3><a name="Java_c_arrays"></a>24.8.3 Wrapping C arrays with Java arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4257,7 +4266,7 @@ Please be aware that the typemaps in this library are not efficient as all the e
|
|||
There is an alternative approach using the SWIG array library and this is covered in the next section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_unbounded_c_arrays"></a>23.8.4 Unbounded C Arrays</H3>
|
||||
<H3><a name="Java_unbounded_c_arrays"></a>24.8.4 Unbounded C Arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4402,7 +4411,7 @@ well suited for applications in which you need to create buffers,
|
|||
package binary data, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_binary_char"></a>23.8.5 Binary data vs Strings</H3>
|
||||
<H3><a name="Java_binary_char"></a>24.8.5 Binary data vs Strings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4446,7 +4455,7 @@ len: 5 data: 68 69 0 6a 6b
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Java_heap_allocations"></a>23.8.6 Overriding new and delete to allocate from Java heap</H3>
|
||||
<H3><a name="Java_heap_allocations"></a>24.8.6 Overriding new and delete to allocate from Java heap</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4563,7 +4572,7 @@ model and use these functions in place of malloc and free in your own
|
|||
code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Java_typemaps"></a>23.9 Java typemaps</H2>
|
||||
<H2><a name="Java_typemaps"></a>24.9 Java typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4584,7 +4593,7 @@ Before proceeding, it should be stressed that typemaps are not a required
|
|||
part of using SWIG---the default wrapping behavior is enough in most cases.
|
||||
Typemaps are only used if you want to change some aspect of the generated code.
|
||||
|
||||
<H3><a name="Java_default_primitive_type_mappings"></a>23.9.1 Default primitive type mappings</H3>
|
||||
<H3><a name="Java_default_primitive_type_mappings"></a>24.9.1 Default primitive type mappings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4736,7 +4745,7 @@ However, the mappings allow the full range of values for each C type from Java.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_default_non_primitive_typemaps"></a>23.9.2 Default typemaps for non-primitive types</H3>
|
||||
<H3><a name="Java_default_non_primitive_typemaps"></a>24.9.2 Default typemaps for non-primitive types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4751,7 +4760,7 @@ So in summary, the C/C++ pointer to non-primitive types is cast into the 64 bit
|
|||
The Java type is either the proxy class or type wrapper class.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_jvm64"></a>23.9.3 Sixty four bit JVMs</H3>
|
||||
<H3><a name="Java_jvm64"></a>24.9.3 Sixty four bit JVMs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4764,7 +4773,7 @@ Unfortunately it won't of course hold true for JNI code.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_what_is_typemap"></a>23.9.4 What is a typemap?</H3>
|
||||
<H3><a name="Java_what_is_typemap"></a>24.9.4 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4887,7 +4896,7 @@ int c = example.count('e',"Hello World");
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Java_typemaps_c_to_java_types"></a>23.9.5 Typemaps for mapping C/C++ types to Java types</H3>
|
||||
<H3><a name="Java_typemaps_c_to_java_types"></a>24.9.5 Typemaps for mapping C/C++ types to Java types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5147,7 +5156,7 @@ These are listed below:
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Java_typemap_attributes"></a>23.9.6 Java typemap attributes</H3>
|
||||
<H3><a name="Java_typemap_attributes"></a>24.9.6 Java typemap attributes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5193,7 +5202,7 @@ The "javain" typemap has the optional 'pre', 'post' and 'pgcppname' attributes.
|
|||
Note that when the 'pre' or 'post' attributes are specified and the associated type is used in a constructor, a constructor helper function is generated. This is necessary as the Java proxy constructor wrapper makes a call to a support constructor using a <i>this</i> call. In Java the <i>this</i> call must be the first statement in the constructor body. The constructor body thus calls the helper function and the helper function instead makes the JNI call, ensuring the 'pre' code is called before the JNI call is made. There is a <a href="#Java_date_marshalling">Date marshalling</a> example showing 'pre', 'post' and 'pgcppname' attributes in action.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_special_variables"></a>23.9.7 Java special variables</H3>
|
||||
<H3><a name="Java_special_variables"></a>24.9.7 Java special variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5344,7 +5353,7 @@ This special variable expands to the intermediary class name. Usually this is th
|
|||
unless the jniclassname attribute is specified in the <a href="Java.html#Java_module_directive">%module directive</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_typemaps_for_c_and_cpp"></a>23.9.8 Typemaps for both C and C++ compilation</H3>
|
||||
<H3><a name="Java_typemaps_for_c_and_cpp"></a>24.9.8 Typemaps for both C and C++ compilation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5381,7 +5390,7 @@ If you do not intend your code to be targeting both C and C++ then your typemaps
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_code_typemaps"></a>23.9.9 Java code typemaps</H3>
|
||||
<H3><a name="Java_code_typemaps"></a>24.9.9 Java code typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5453,7 +5462,7 @@ import statements for Java class: empty default
|
|||
|
||||
<p><tt>%typemap(javainterfaces)</tt></p>
|
||||
<div class="indent">
|
||||
interfaces (extends) for Java class: empty default
|
||||
interfaces (implements) for Java class: empty default
|
||||
</div>
|
||||
|
||||
<p><tt>%typemap(javafinalize)</tt></p>
|
||||
|
|
@ -5550,15 +5559,8 @@ The typemap code is the same that is in "<tt>java.swg</tt>", barring the last tw
|
|||
Note that <tt>SWIGTYPE</tt> will target all proxy classes, but not the type wrapper classes.
|
||||
Also the above typemap is only used for proxy classes that are potential base classes.
|
||||
To target proxy classes that are derived from a wrapped class as well, the "javabody_derived" typemap should also be overridden.
|
||||
There is a macro in <tt>java.swg</tt> that implements this and the above can instead be implemented using:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
SWIG_JAVABODY_METHODS(protected, protected, SWIGTYPE)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
For the typemap to be used in all type wrapper classes, all the different types that type wrapper classes could be used for should be targeted:
|
||||
</p>
|
||||
|
|
@ -5568,7 +5570,7 @@ For the typemap to be used in all type wrapper classes, all the different types
|
|||
%typemap(javabody) SWIGTYPE *, SWIGTYPE &, SWIGTYPE [], SWIGTYPE (CLASS::*) %{
|
||||
private long swigCPtr;
|
||||
|
||||
public $javaclassname(long cPtr, boolean bFutureUse) {
|
||||
protected $javaclassname(long cPtr, boolean bFutureUse) {
|
||||
swigCPtr = cPtr;
|
||||
}
|
||||
|
||||
|
|
@ -5576,7 +5578,7 @@ For the typemap to be used in all type wrapper classes, all the different types
|
|||
swigCPtr = 0;
|
||||
}
|
||||
|
||||
public static long getCPtr($javaclassname obj) {
|
||||
protected static long getCPtr($javaclassname obj) {
|
||||
return (obj == null) ? 0 : obj.swigCPtr;
|
||||
}
|
||||
%}
|
||||
|
|
@ -5587,7 +5589,30 @@ For the typemap to be used in all type wrapper classes, all the different types
|
|||
Again this is the same that is in "<tt>java.swg</tt>", barring the method modifier for <tt>getCPtr</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_directors_typemaps"></a>23.9.10 Director specific typemaps</H3>
|
||||
<p>
|
||||
When using <a href="Modules.html">multiple modules</a> or the <a href="#Java_namespaces">nspace feature</a> it is common to invoke SWIG with a different <tt>-package</tt>
|
||||
command line option for each module.
|
||||
However, by default the generated code may not compile if
|
||||
generated classes in one package use generated classes in another package.
|
||||
The visibility of the
|
||||
<tt>getCPtr()</tt> and pointer constructor generated from the <tt>javabody</tt> typemaps needs changing.
|
||||
The default visibility is <tt>protected</tt> but it needs to be <tt>public</tt> for access from a different package.
|
||||
Just changing 'protected' to 'public' in the typemap achieves this.
|
||||
Two macros are available in <tt>java.swg</tt> to make this easier and using them is the preferred approach
|
||||
over simply copying the typemaps and modifying as this is forward compatible with any changes in
|
||||
the <tt>javabody</tt> typemap in future versions of SWIG.
|
||||
The macros are for the proxy and typewrapper classes and can respectively be used to
|
||||
to make the method and constructor public:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
SWIG_JAVABODY_PROXY(public, public, SWIGTYPE)
|
||||
SWIG_JAVABODY_TYPEWRAPPER(public, public, public, SWIGTYPE)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Java_directors_typemaps"></a>24.9.10 Director specific typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5812,7 +5837,7 @@ The basic strategy here is to provide a default package typemap for the majority
|
|||
|
||||
</div>
|
||||
|
||||
<H2><a name="Java_typemap_examples"></a>23.10 Typemap Examples</H2>
|
||||
<H2><a name="Java_typemap_examples"></a>24.10 Typemap Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5822,7 +5847,7 @@ the SWIG library.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_simpler_enum_classes"></a>23.10.1 Simpler Java enums for enums without initializers</H3>
|
||||
<H3><a name="Java_simpler_enum_classes"></a>24.10.1 Simpler Java enums for enums without initializers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5901,7 +5926,7 @@ This would be done by using the original versions of these typemaps in "enums.sw
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_exception_typemap"></a>23.10.2 Handling C++ exception specifications as Java exceptions</H3>
|
||||
<H3><a name="Java_exception_typemap"></a>24.10.2 Handling C++ exception specifications as Java exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6026,7 +6051,7 @@ We could alternatively have used <tt>%rename</tt> to rename <tt>what()</tt> into
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_nan_exception_typemap"></a>23.10.3 NaN Exception - exception handling for a particular type</H3>
|
||||
<H3><a name="Java_nan_exception_typemap"></a>24.10.3 NaN Exception - exception handling for a particular type</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6181,7 +6206,7 @@ If we were a martyr to the JNI cause, we could replace the succinct code within
|
|||
If we had, we would have put it in the "in" typemap which, like all JNI and Java typemaps, also supports the 'throws' attribute.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_converting_java_string_arrays"></a>23.10.4 Converting Java String arrays to char ** </H3>
|
||||
<H3><a name="Java_converting_java_string_arrays"></a>24.10.4 Converting Java String arrays to char ** </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6281,7 +6306,7 @@ public class runme {
|
|||
|
||||
static {
|
||||
try {
|
||||
System.loadLibrary("example");
|
||||
System.loadLibrary("example");
|
||||
} catch (UnsatisfiedLinkError e) {
|
||||
System.err.println("Native code library failed to load. " + e);
|
||||
System.exit(1);
|
||||
|
|
@ -6325,7 +6350,7 @@ Lastly the "jni", "jtype" and "jstype" typemaps are also required to specify
|
|||
what Java types to use.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_expanding_java_object"></a>23.10.5 Expanding a Java object to multiple arguments</H3>
|
||||
<H3><a name="Java_expanding_java_object"></a>24.10.5 Expanding a Java object to multiple arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6407,7 +6432,7 @@ example.foo(new String[]{"red", "green", "blue", "white"});
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Java_using_typemaps_return_arguments"></a>23.10.6 Using typemaps to return arguments</H3>
|
||||
<H3><a name="Java_using_typemaps_return_arguments"></a>24.10.6 Using typemaps to return arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6500,7 +6525,7 @@ public class runme {
|
|||
|
||||
static {
|
||||
try {
|
||||
System.loadLibrary("example");
|
||||
System.loadLibrary("example");
|
||||
} catch (UnsatisfiedLinkError e) {
|
||||
System.err.println("Native code library failed to load. " + e);
|
||||
System.exit(1);
|
||||
|
|
@ -6525,7 +6550,7 @@ $ java runme
|
|||
1 12.0 340.0
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Java_adding_downcasts"></a>23.10.7 Adding Java downcasts to polymorphic return types</H3>
|
||||
<H3><a name="Java_adding_downcasts"></a>24.10.7 Adding Java downcasts to polymorphic return types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6731,7 +6756,7 @@ SWIG usually generates code which constructs the proxy classes using Java code a
|
|||
Note that the JNI code above uses a number of string lookups to call a constructor, whereas this would not occur using byte compiled Java code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_adding_equals_method"></a>23.10.8 Adding an equals method to the Java classes</H3>
|
||||
<H3><a name="Java_adding_equals_method"></a>24.10.8 Adding an equals method to the Java classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6775,7 +6800,7 @@ System.out.println("foo1? " + foo1.equals(foo2));
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Java_void_pointers"></a>23.10.9 Void pointers and a common Java base class</H3>
|
||||
<H3><a name="Java_void_pointers"></a>24.10.9 Void pointers and a common Java base class</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6834,7 +6859,7 @@ This example contains some useful functionality which you may want in your code.
|
|||
<li> It also has a function which effectively implements a cast from the type of the proxy/type wrapper class to a void pointer. This is necessary for passing a proxy class or a type wrapper class to a function that takes a void pointer.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Java_struct_pointer_pointer"></a>23.10.10 Struct pointer to pointer</H3>
|
||||
<H3><a name="Java_struct_pointer_pointer"></a>24.10.10 Struct pointer to pointer</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7014,7 +7039,7 @@ The C functional interface has been completely morphed into an object-oriented i
|
|||
the Butler class would behave much like any pure Java class and feel more natural to Java users.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_memory_management_member_variables"></a>23.10.11 Memory management when returning references to member variables</H3>
|
||||
<H3><a name="Java_memory_management_member_variables"></a>24.10.11 Memory management when returning references to member variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7137,7 +7162,7 @@ public class Bike {
|
|||
Note the <tt>addReference</tt> call.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_memory_management_objects"></a>23.10.12 Memory management for objects passed to the C++ layer</H3>
|
||||
<H3><a name="Java_memory_management_objects"></a>24.10.12 Memory management for objects passed to the C++ layer</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7253,7 +7278,7 @@ The 'javacode' typemap simply adds in the specified code into the Java proxy cla
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Java_date_marshalling"></a>23.10.13 Date marshalling using the javain typemap and associated attributes</H3>
|
||||
<H3><a name="Java_date_marshalling"></a>24.10.13 Date marshalling using the javain typemap and associated attributes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7430,7 +7455,7 @@ A few things to note:
|
|||
|
||||
|
||||
|
||||
<H2><a name="Java_directors_faq"></a>23.11 Living with Java Directors</H2>
|
||||
<H2><a name="Java_directors_faq"></a>24.11 Living with Java Directors</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7611,10 +7636,10 @@ public abstract class UserVisibleFoo extends Foo {
|
|||
</li>
|
||||
</ol>
|
||||
|
||||
<H2><a name="Java_odds_ends"></a>23.12 Odds and ends</H2>
|
||||
<H2><a name="Java_odds_ends"></a>24.12 Odds and ends</H2>
|
||||
|
||||
|
||||
<H3><a name="Java_javadoc_comments"></a>23.12.1 JavaDoc comments</H3>
|
||||
<H3><a name="Java_javadoc_comments"></a>24.12.1 JavaDoc comments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7670,7 +7695,7 @@ public class Barmy {
|
|||
|
||||
|
||||
|
||||
<H3><a name="Java_functional_interface"></a>23.12.2 Functional interface without proxy classes</H3>
|
||||
<H3><a name="Java_functional_interface"></a>24.12.2 Functional interface without proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7731,7 +7756,7 @@ All destructors have to be called manually for example the <tt>delete_Foo(foo)</
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_using_own_jni_functions"></a>23.12.3 Using your own JNI functions</H3>
|
||||
<H3><a name="Java_using_own_jni_functions"></a>24.12.3 Using your own JNI functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7781,7 +7806,7 @@ This directive is only really useful if you want to mix your own hand crafted JN
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Java_performance"></a>23.12.4 Performance concerns and hints</H3>
|
||||
<H3><a name="Java_performance"></a>24.12.4 Performance concerns and hints</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7802,7 +7827,7 @@ However, you will have to be careful about memory management and make sure that
|
|||
This method normally calls the C++ destructor or <tt>free()</tt> for C code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Java_debugging"></a>23.12.5 Debugging</H3>
|
||||
<H3><a name="Java_debugging"></a>24.12.5 Debugging</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7824,7 +7849,7 @@ The -verbose:jni and -verbose:gc are also useful options for monitoring code beh
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Java_examples"></a>23.13 Examples</H2>
|
||||
<H2><a name="Java_examples"></a>24.13 Java Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -682,8 +682,12 @@ pointer.
|
|||
|
||||
<div class="indent"><p>
|
||||
Copies all of the string data in <tt>s</tt> into the memory pointed to by
|
||||
<tt>ptr</tt>. The string may contain embedded NULL bytes. The length of
|
||||
the string is implicitly determined in the underlying wrapper code.
|
||||
<tt>ptr</tt>. The string may contain embedded NULL bytes.
|
||||
This is actually a wrapper to the standard C library <tt>memmove</tt> function, which is
|
||||
declared as
|
||||
<b><tt>void memmove(void *ptr, const void *src, size_t n)</tt></b>.
|
||||
The <tt>src</tt> and length <tt>n</tt> parameters are
|
||||
extracted from the language specific string <tt>s</tt> in the underlying wrapper code.
|
||||
</p></div>
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Lisp"></a>24 SWIG and Common Lisp</H1>
|
||||
<H1><a name="Lisp"></a>25 SWIG and Common Lisp</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -41,7 +41,7 @@
|
|||
Lisp, Common Foreign Function Interface(CFFI), CLisp and UFFI
|
||||
foreign function interfaces.
|
||||
</p>
|
||||
<H2><a name="Lisp_nn2"></a>24.1 Allegro Common Lisp</H2>
|
||||
<H2><a name="Lisp_nn2"></a>25.1 Allegro Common Lisp</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -50,7 +50,7 @@
|
|||
<a href="Allegrocl.html#Allegrocl">here</a>
|
||||
</p>
|
||||
|
||||
<H2><a name="Lisp_nn3"></a>24.2 Common Foreign Function Interface(CFFI)</H2>
|
||||
<H2><a name="Lisp_nn3"></a>25.2 Common Foreign Function Interface(CFFI)</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -77,7 +77,7 @@ swig -cffi -module <i>module-name</i> <i>file-name</i>
|
|||
files and the various things which you can do with them.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lisp_nn4"></a>24.2.1 Additional Commandline Options </H3>
|
||||
<H3><a name="Lisp_nn4"></a>25.2.1 Additional Commandline Options </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -118,7 +118,7 @@ swig -cffi -help
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lisp_nn5"></a>24.2.2 Generating CFFI bindings</H3>
|
||||
<H3><a name="Lisp_nn5"></a>25.2.2 Generating CFFI bindings</H3>
|
||||
|
||||
|
||||
As we mentioned earlier the ideal way to use SWIG is to use interface
|
||||
|
|
@ -392,7 +392,7 @@ The feature <i>intern_function</i> ensures that all C names are
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lisp_nn6"></a>24.2.3 Generating CFFI bindings for C++ code</H3>
|
||||
<H3><a name="Lisp_nn6"></a>25.2.3 Generating CFFI bindings for C++ code</H3>
|
||||
|
||||
|
||||
<p>This feature to SWIG (for CFFI) is very new and still far from
|
||||
|
|
@ -568,7 +568,7 @@ If you have any questions, suggestions, patches, etc., related to CFFI
|
|||
module feel free to contact us on the SWIG mailing list, and
|
||||
also please add a "[CFFI]" tag in the subject line.
|
||||
|
||||
<H3><a name="Lisp_nn7"></a>24.2.4 Inserting user code into generated files</H3>
|
||||
<H3><a name="Lisp_nn7"></a>25.2.4 Inserting user code into generated files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -608,7 +608,7 @@ Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Lisp_nn8"></a>24.3 CLISP</H2>
|
||||
<H2><a name="Lisp_nn8"></a>25.3 CLISP</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -638,7 +638,7 @@ swig -clisp -module <i>module-name</i> <i>file-name</i>
|
|||
interface file for the CLISP module. The CLISP module tries to
|
||||
produce code which is both human readable and easily modifyable.
|
||||
</p>
|
||||
<H3><a name="Lisp_nn9"></a>24.3.1 Additional Commandline Options </H3>
|
||||
<H3><a name="Lisp_nn9"></a>25.3.1 Additional Commandline Options </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -671,7 +671,7 @@ and global variables will be created otherwise only definitions for<br/>
|
|||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lisp_nn10"></a>24.3.2 Details on CLISP bindings</H3>
|
||||
<H3><a name="Lisp_nn10"></a>25.3.2 Details on CLISP bindings</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -795,7 +795,7 @@ struct bar {
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lisp_nn11"></a>24.4 UFFI </H2>
|
||||
<H2><a name="Lisp_nn11"></a>25.4 UFFI </H2>
|
||||
|
||||
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -6,13 +6,14 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Lua"></a>25 SWIG and Lua</H1>
|
||||
<H1><a name="Lua"></a>26 SWIG and Lua</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#Lua_nn2">Preliminaries</a>
|
||||
<li><a href="#Lua_nn3">Running SWIG</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_commandline">Additional command line options</a>
|
||||
<li><a href="#Lua_nn4">Compiling and Linking and Interpreter</a>
|
||||
<li><a href="#Lua_nn5">Compiling a dynamic module</a>
|
||||
<li><a href="#Lua_nn6">Using your module</a>
|
||||
|
|
@ -31,32 +32,33 @@
|
|||
<li><a href="#Lua_nn17">C++ overloaded functions</a>
|
||||
<li><a href="#Lua_nn18">C++ operators</a>
|
||||
<li><a href="#Lua_nn19">Class extension with %extend</a>
|
||||
<li><a href="#Lua_nn20">C++ templates</a>
|
||||
<li><a href="#Lua_nn21">C++ Smart Pointers</a>
|
||||
<li><a href="#Lua_nn22">C++ Exceptions</a>
|
||||
<li><a href="#Lua_nn20">Using %newobject to release memory</a>
|
||||
<li><a href="#Lua_nn21">C++ templates</a>
|
||||
<li><a href="#Lua_nn22">C++ Smart Pointers</a>
|
||||
<li><a href="#Lua_nn23">C++ Exceptions</a>
|
||||
</ul>
|
||||
<li><a href="#Lua_nn23">Typemaps</a>
|
||||
<li><a href="#Lua_nn24">Typemaps</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_nn24">What is a typemap?</a>
|
||||
<li><a href="#Lua_nn25">Using typemaps</a>
|
||||
<li><a href="#Lua_nn26">Typemaps and arrays</a>
|
||||
<li><a href="#Lua_nn27">Typemaps and pointer-pointer functions</a>
|
||||
<li><a href="#Lua_nn25">What is a typemap?</a>
|
||||
<li><a href="#Lua_nn26">Using typemaps</a>
|
||||
<li><a href="#Lua_nn27">Typemaps and arrays</a>
|
||||
<li><a href="#Lua_nn28">Typemaps and pointer-pointer functions</a>
|
||||
</ul>
|
||||
<li><a href="#Lua_nn28">Writing typemaps</a>
|
||||
<li><a href="#Lua_nn29">Writing typemaps</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_nn29">Typemaps you can write</a>
|
||||
<li><a href="#Lua_nn30">SWIG's Lua-C API</a>
|
||||
<li><a href="#Lua_nn30">Typemaps you can write</a>
|
||||
<li><a href="#Lua_nn31">SWIG's Lua-C API</a>
|
||||
</ul>
|
||||
<li><a href="#Lua_nn31">Customization of your Bindings</a>
|
||||
<li><a href="#Lua_nn32">Customization of your Bindings</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_nn32">Writing your own custom wrappers</a>
|
||||
<li><a href="#Lua_nn33">Adding additional Lua code</a>
|
||||
<li><a href="#Lua_nn33">Writing your own custom wrappers</a>
|
||||
<li><a href="#Lua_nn34">Adding additional Lua code</a>
|
||||
</ul>
|
||||
<li><a href="#Lua_nn34">Details on the Lua binding</a>
|
||||
<li><a href="#Lua_nn35">Details on the Lua binding</a>
|
||||
<ul>
|
||||
<li><a href="#Lua_nn35">Binding global data into the module.</a>
|
||||
<li><a href="#Lua_nn36">Userdata and Metatables</a>
|
||||
<li><a href="#Lua_nn37">Memory management</a>
|
||||
<li><a href="#Lua_nn36">Binding global data into the module.</a>
|
||||
<li><a href="#Lua_nn37">Userdata and Metatables</a>
|
||||
<li><a href="#Lua_nn38">Memory management</a>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
|
|
@ -67,13 +69,17 @@
|
|||
<p>
|
||||
Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in clean C (that is, in the common subset of ANSI C and C++). Its also a <em>really</em> tiny language, less than 6000 lines of code, which compiles to <100 kilobytes of binary code. It can be found at <a href="http://www.lua.org">http://www.lua.org</a>
|
||||
</p>
|
||||
<H2><a name="Lua_nn2"></a>25.1 Preliminaries</H2>
|
||||
<p>
|
||||
eLua stands for Embedded Lua (can be thought of as a flavor of Lua) and offers the full implementation of the Lua programming language to the embedded world, extending it with specific features for efficient and portable software embedded development. eLua runs on smaller devices like microcontrollers and provides the full features of the regular Lua desktop version. More information on eLua can be found here: <a href="http://www.eluaproject.net">http://www.eluaproject.net</a>
|
||||
</p>
|
||||
|
||||
<H2><a name="Lua_nn2"></a>26.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
The current SWIG implementation is designed to work with Lua 5.0.x and Lua 5.1.x. It should work with later versions of Lua, but certainly not with Lua 4.0 due to substantial API changes. ((Currently SWIG generated code has only been tested on Windows with MingW, though given the nature of Lua, is should not have problems on other OS's)). It is possible to either static link or dynamic link a Lua module into the interpreter (normally Lua static links its libraries, as dynamic linking is not available on all platforms).
|
||||
The current SWIG implementation is designed to work with Lua 5.0.x and Lua 5.1.x. It should work with later versions of Lua, but certainly not with Lua 4.0 due to substantial API changes. ((Currently SWIG generated code has only been tested on Windows with MingW, though given the nature of Lua, is should not have problems on other OS's)). It is possible to either static link or dynamic link a Lua module into the interpreter (normally Lua static links its libraries, as dynamic linking is not available on all platforms). SWIG also supports eLua and works with eLua 0.8. SWIG generated code for eLua has been tested on Stellaris ARM Cortex-M3 LM3S and Infineon TriCore.
|
||||
</p>
|
||||
<H2><a name="Lua_nn3"></a>25.2 Running SWIG</H2>
|
||||
<H2><a name="Lua_nn3"></a>26.2 Running SWIG</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -105,7 +111,56 @@ This creates a C/C++ source file <tt>example_wrap.c</tt> or <tt>example_wrap.cxx
|
|||
<p>
|
||||
The name of the wrapper file is derived from the name of the input file. For example, if the input file is <tt>example.i</tt>, the name of the wrapper file is <tt>example_wrap.c</tt>. To change this, you can use the -o option. The wrappered module will export one function <tt>"int luaopen_example(lua_State* L)"</tt> which must be called to register the module with the Lua interpreter. The name "luaopen_example" depends upon the name of the module.
|
||||
</p>
|
||||
<H3><a name="Lua_nn4"></a>25.2.1 Compiling and Linking and Interpreter</H3>
|
||||
<p>
|
||||
To build an eLua module, run SWIG using <tt>-lua</tt> and add either <tt>-elua</tt> or <tt>-eluac</tt>.
|
||||
</p>
|
||||
<div class="shell"><pre>
|
||||
$ swig -lua -elua example.i
|
||||
</pre></div>
|
||||
<p>
|
||||
or
|
||||
</p>
|
||||
<div class="shell"><pre>
|
||||
$ swig -lua -eluac example.i
|
||||
</pre></div>
|
||||
<p>
|
||||
The <tt>-elua</tt> option puts all the C function wrappers and variable get/set wrappers in rotables. It also generates a metatable which will control the access to these variables from eLua. It also offers a significant amount of module size compression. On the other hand, the <tt>-eluac</tt> option puts all the wrappers in a single rotable. With this option, no matter how huge the module, it will consume no additional microcontroller SRAM (crass compression). There is a catch though: Metatables are not generated with <tt>-eluac</tt>. To access any value from eLua, one must directly call the wrapper function associated with that value.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_commandline"></a>26.2.1 Additional command line options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The following table list the additional commandline options available for the Lua module. They can also be seen by using:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
swig -lua -help
|
||||
</pre></div>
|
||||
|
||||
<table summary="Lua specific options">
|
||||
<tr>
|
||||
<th>Lua specific options</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-elua</td>
|
||||
<td>Generates LTR compatible wrappers for smaller devices running elua.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-eluac</td>
|
||||
<td>LTR compatible wrappers in "crass compress" mode for elua.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>-nomoduleglobal</td>
|
||||
<td>Do not register the module name as a global variable but return the module table from calls to require.</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
|
||||
<H3><a name="Lua_nn4"></a>26.2.2 Compiling and Linking and Interpreter</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -151,8 +206,33 @@ $ gcc -I/usr/include/lua -c example_wrap.c -o example_wrap.o
|
|||
$ gcc -c example.c -o example.o
|
||||
$ gcc -I/usr/include/lua -L/usr/lib/lua min.o example_wrap.o example.o -o my_lua
|
||||
</pre></div>
|
||||
<p>
|
||||
For eLua, the source must be built along with the wrappers generated by SWIG. Make sure the eLua source files <tt>platform_conf.h</tt> and <tt>auxmods.h</tt> are updated with the entries of your new module. Please note: <tt>"mod"</tt> is the module name.
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
/* Sample platform_conf.h */
|
||||
#define LUA_PLATFORM_LIBS_ROM\
|
||||
_ROM( AUXLIB_PIO, luaopen_pio, pio_map )\
|
||||
_ROM( AUXLIB_TMR, luaopen_tmr, tmr_map )\
|
||||
_ROM( AUXLIB_MOD, luaopen_mod, mod_map )\
|
||||
....
|
||||
</pre></div>
|
||||
<p>
|
||||
</p>
|
||||
<div class="code"><pre>
|
||||
/* Sample auxmods.h */
|
||||
#define AUXLIB_PIO "pio"
|
||||
LUALIB_API int ( luaopen_pio )(lua_State *L );
|
||||
|
||||
<H3><a name="Lua_nn5"></a>25.2.2 Compiling a dynamic module</H3>
|
||||
#define AUXLIB_MOD "mod"
|
||||
LUALIB_API int ( luaopen_mod )(lua_State *L );
|
||||
....
|
||||
</pre></div>
|
||||
<p>
|
||||
More information on building and configuring eLua can be found here: <a href="http://www.eluaproject.net/doc/v0.8/en_building.html">http://www.eluaproject.net/doc/v0.8/en_building.html</a>
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn5"></a>26.2.3 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -220,7 +300,7 @@ Is quite obvious (Go back and consult the Lua documents on how to enable loadlib
|
|||
|
||||
|
||||
|
||||
<H3><a name="Lua_nn6"></a>25.2.3 Using your module</H3>
|
||||
<H3><a name="Lua_nn6"></a>26.2.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -238,19 +318,19 @@ $ ./my_lua
|
|||
>
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_nn7"></a>25.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Lua_nn7"></a>26.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
By default, SWIG tries to build a very natural Lua interface to your C/C++ code. This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
<H3><a name="Lua_nn8"></a>25.3.1 Modules</H3>
|
||||
<H3><a name="Lua_nn8"></a>26.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The SWIG module directive specifies the name of the Lua module. If you specify `module example', then everything is wrapped into a Lua table 'example' containing all the functions and variables. When choosing a module name, make sure you don't use the same name as a built-in Lua command or standard module name.
|
||||
</p>
|
||||
<H3><a name="Lua_nn9"></a>25.3.2 Functions</H3>
|
||||
<H3><a name="Lua_nn9"></a>26.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -288,7 +368,7 @@ It is also possible to rename the module with an assignment.
|
|||
24
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn10"></a>25.3.3 Global variables</H3>
|
||||
<H3><a name="Lua_nn10"></a>26.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -361,8 +441,22 @@ nil
|
|||
> print(example.PI)
|
||||
3.142
|
||||
</pre></div>
|
||||
<p>
|
||||
If you have used the <tt>-eluac</tt> option for your eLua module, you will have to follow a different approach while manipulating global variables. (This is not applicable for wrappers generated with <tt>-elua</tt>)
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> -- Applicable only with -eluac. (num is defined)
|
||||
> print(example.num_get())
|
||||
20
|
||||
> example.num_set(50) -- new value added
|
||||
> print(example.num_get())
|
||||
50
|
||||
</pre></div>
|
||||
<p>
|
||||
In general, functions of the form <tt>"variable_get()"</tt> and <tt>"variable_set()"</tt> are automatically generated by SWIG for use with <tt>-eluac</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn11"></a>25.3.4 Constants and enums</H3>
|
||||
<H3><a name="Lua_nn11"></a>26.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -385,7 +479,18 @@ example.SUNDAY=0
|
|||
<p>
|
||||
Constants are not guaranteed to remain constant in Lua. The name of the constant could be accidentally reassigned to refer to some other object. Unfortunately, there is no easy way for SWIG to generate code that prevents this. You will just have to be careful.
|
||||
</p>
|
||||
<H3><a name="Lua_nn12"></a>25.3.5 Pointers</H3>
|
||||
<p>
|
||||
If you're using eLua and have used <tt>-elua</tt> or <tt>-eluac</tt> to generate your wrapper, macro constants and enums should be accessed through a rotable called <tt>"const"</tt>. In eLua, macro constants and enums are guaranteed to remain constants since they are all contained within a rotable. A regular C constant is accessed from eLua just as if it were a regular global variable, just that the property of value immutability is demonstrated if an attempt at modifying a C constant is made.
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> print(example.ICONST)
|
||||
10
|
||||
> print(example.const.SUNDAY)
|
||||
0
|
||||
> print(example.const.SCONST)
|
||||
Hello World
|
||||
</pre></div>
|
||||
<H3><a name="Lua_nn12"></a>26.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -423,7 +528,7 @@ Lua enforces the integrity of its userdata, so it is virtually impossible to cor
|
|||
nil
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn13"></a>25.3.6 Structures</H3>
|
||||
<H3><a name="Lua_nn13"></a>26.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -508,8 +613,26 @@ Because the pointer points inside the structure, you can modify the contents and
|
|||
> x = b.f
|
||||
> x.a = 3 -- Modifies the same structure
|
||||
</pre></div>
|
||||
<p>
|
||||
For eLua with the <tt>-eluac</tt> option, structure manipulation has to be performed with specific structure functions generated by SWIG. Let's say you have the following structure definition:
|
||||
</p>
|
||||
<div class="code"><pre>struct data {
|
||||
int x, y;
|
||||
double z;
|
||||
};
|
||||
|
||||
<H3><a name="Lua_nn14"></a>25.3.7 C++ classes</H3>
|
||||
> --From eLua
|
||||
> a = example.new_data()
|
||||
> example.data_x_set(a, 10)
|
||||
> example.data_y_set(a, 20)
|
||||
> print(example.data_x_get(a), example.data_y_get(a))
|
||||
10 20
|
||||
</pre></div>
|
||||
<p>
|
||||
In general, functions of the form <tt>"new_struct()"</tt>, <tt>"struct_member_get()"</tt>, <tt>"struct_member_set()"</tt> and <tt>"free_struct()"</tt> are automatically generated by SWIG for each structure defined in C. (Please note: This doesn't apply for modules generated with the <tt>-elua</tt> option)
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn14"></a>26.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -570,7 +693,7 @@ It is not (currently) possible to access static members of an instance:
|
|||
-- does NOT work
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn15"></a>25.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Lua_nn15"></a>26.3.8 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -595,7 +718,7 @@ then the function <tt>spam()</tt> accepts a Foo pointer or a pointer to any clas
|
|||
<p>
|
||||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
<H3><a name="Lua_nn16"></a>25.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Lua_nn16"></a>26.3.9 Pointers, references, values, and arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -626,7 +749,7 @@ Foo spam7();
|
|||
<p>
|
||||
then all three functions will return a pointer to some Foo object. Since the third function (spam7) returns a value, newly allocated memory is used to hold the result and a pointer is returned (Lua will release this memory when the return value is garbage collected). The other two are pointers which are assumed to be managed by the C code and so will not be garbage collected.
|
||||
</p>
|
||||
<H3><a name="Lua_nn17"></a>25.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Lua_nn17"></a>26.3.10 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -712,7 +835,7 @@ Please refer to the "SWIG and C++" chapter for more information about overloadin
|
|||
<p>
|
||||
Dealing with the Lua coercion mechanism, the priority is roughly (integers, floats, strings, userdata). But it is better to rename the functions rather than rely upon the ordering.
|
||||
</p>
|
||||
<H3><a name="Lua_nn18"></a>25.3.11 C++ operators</H3>
|
||||
<H3><a name="Lua_nn18"></a>26.3.11 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -824,7 +947,7 @@ It is also possible to overload the operator<tt>[]</tt>, but currently this cann
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn19"></a>25.3.12 Class extension with %extend</H3>
|
||||
<H3><a name="Lua_nn19"></a>26.3.12 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -879,7 +1002,32 @@ true
|
|||
<p>
|
||||
Extend works with both C and C++ code, on classes and structs. It does not modify the underlying object in any way---the extensions only show up in the Lua interface. The only item to take note of is the code has to use the '$self' instead of 'this', and that you cannot access protected/private members of the code (as you are not officially part of the class).
|
||||
</p>
|
||||
<H3><a name="Lua_nn20"></a>25.3.13 C++ templates</H3>
|
||||
|
||||
<H3><a name="Lua_nn20"></a>26.3.13 Using %newobject to release memory</H3>
|
||||
|
||||
|
||||
<p> If you have a function that allocates memory like this,</p>
|
||||
<div class="code">
|
||||
<pre>char *foo() {
|
||||
char *result = (char *) malloc(...);
|
||||
...
|
||||
return result;
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
<p> then the SWIG generated wrappers will have a memory leak--the
|
||||
returned data will be copied into a string object and the old contents
|
||||
ignored.</p>
|
||||
<p> To fix the memory leak, use the <a href="Customization.html#Customization_ownership">%newobject directive</a>.</p>
|
||||
<div class="code">
|
||||
<pre>%newobject foo;
|
||||
...
|
||||
char *foo();
|
||||
</pre>
|
||||
</div>
|
||||
<p> This will release the allocated memory.</p>
|
||||
|
||||
<H3><a name="Lua_nn21"></a>26.3.14 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -914,7 +1062,7 @@ In Lua:
|
|||
<p>
|
||||
Obviously, there is more to template wrapping than shown in this example. More details can be found in the SWIG and C++ chapter. Some more complicated examples will appear later.
|
||||
</p>
|
||||
<H3><a name="Lua_nn21"></a>25.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Lua_nn22"></a>26.3.15 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -966,7 +1114,7 @@ If you ever need to access the underlying pointer returned by <tt>operator->(
|
|||
> f = p:__deref__() -- Returns underlying Foo *
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn22"></a>25.3.15 C++ Exceptions</H3>
|
||||
<H3><a name="Lua_nn23"></a>26.3.16 C++ Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -985,13 +1133,13 @@ SWIG will automatically convert this to a Lua error.
|
|||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
> message()
|
||||
> message()
|
||||
I died.
|
||||
stack traceback:
|
||||
[C]: in function 'message'
|
||||
stdin:1: in main chunk
|
||||
[C]: ?
|
||||
>
|
||||
>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -1000,13 +1148,13 @@ Using xpcall will allow you to obtain additional debug information (such as a st
|
|||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
> function a() b() end -- function a() calls function b()
|
||||
> function b() message() end -- function b() calls C++ function message(), which throws
|
||||
> ok,res=pcall(a) -- call the function
|
||||
> print(ok,res)
|
||||
> function a() b() end -- function a() calls function b()
|
||||
> function b() message() end -- function b() calls C++ function message(), which throws
|
||||
> ok,res=pcall(a) -- call the function
|
||||
> print(ok,res)
|
||||
false I died.
|
||||
> ok,res=xpcall(a,debug.traceback) -- call the function
|
||||
> print(ok,res)
|
||||
> ok,res=xpcall(a,debug.traceback) -- call the function
|
||||
> print(ok,res)
|
||||
false I died.
|
||||
stack traceback:
|
||||
[C]: in function 'message'
|
||||
|
|
@ -1018,7 +1166,7 @@ stack traceback:
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
SWIG is able to throw numeric types, enums, chars, char*'s and std::string's without problem. It has also written typemaps for std::exception and its derived classes, which convert the exception into and error string. </p>
|
||||
SWIG is able to throw numeric types, enums, chars, char*'s and std::string's without problem. It has also written typemaps for std::exception and its derived classes, which convert the exception into an error string. </p>
|
||||
<p>
|
||||
However its not so simple for to throw other types of objects.
|
||||
Thrown objects are not valid outside the 'catch' block. Therefore they cannot be
|
||||
|
|
@ -1041,13 +1189,13 @@ SWIG will just convert it (poorly) to a string and use that as its error. (Yes i
|
|||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
> throw_A()
|
||||
> throw_A()
|
||||
object exception:A *
|
||||
stack traceback:
|
||||
[C]: in function 'unknown'
|
||||
stdin:1: in main chunk
|
||||
[C]: ?
|
||||
>
|
||||
>
|
||||
</pre></div>
|
||||
<p>
|
||||
To get a more useful behaviour out of SWIG you must either: provide a way to convert your exceptions into strings, or
|
||||
|
|
@ -1088,14 +1236,14 @@ void throw_exc() throw(Exc) {
|
|||
Then the following code can be used (note: we use pcall to catch the error so we can process the exception).
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
> ok,res=pcall(throw_exc)
|
||||
> print(ok)
|
||||
> ok,res=pcall(throw_exc)
|
||||
> print(ok)
|
||||
false
|
||||
> print(res)
|
||||
> print(res)
|
||||
userdata: 0003D880
|
||||
> print(res.code,res.msg)
|
||||
> print(res.code,res.msg)
|
||||
42 Hosed
|
||||
>
|
||||
>
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -1110,12 +1258,12 @@ add exception specification to functions or globally (respectively).
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Lua_nn23"></a>25.4 Typemaps</H2>
|
||||
<H2><a name="Lua_nn24"></a>26.4 Typemaps</H2>
|
||||
|
||||
|
||||
<p>This section explains what typemaps are and the usage of them. The default wrappering behaviour of SWIG is enough in most cases. However sometimes SWIG may need a little additional assistance to know which typemap to apply to provide the best wrappering. This section will be explaining how to use typemaps to best effect</p>
|
||||
<p>This section explains what typemaps are and the usage of them. The default wrapping behaviour of SWIG is enough in most cases. However sometimes SWIG may need a little additional assistance to know which typemap to apply to provide the best wrapping. This section will be explaining how to use typemaps to best effect</p>
|
||||
|
||||
<H3><a name="Lua_nn24"></a>25.4.1 What is a typemap?</H3>
|
||||
<H3><a name="Lua_nn25"></a>26.4.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>A typemap is nothing more than a code generation rule that is attached to a specific C datatype. For example, to convert integers from Lua to C, you might define a typemap like this:</p>
|
||||
|
|
@ -1143,7 +1291,7 @@ Received an integer : 6
|
|||
720
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Lua_nn25"></a>25.4.2 Using typemaps</H3>
|
||||
<H3><a name="Lua_nn26"></a>26.4.2 Using typemaps</H3>
|
||||
|
||||
|
||||
<p>There are many ready written typemaps built into SWIG for all common types (int, float, short, long, char*, enum and more), which SWIG uses automatically, with no effort required on your part.</p>
|
||||
|
|
@ -1196,7 +1344,7 @@ void swap(int *sx, int *sy);
|
|||
|
||||
<p>Note: C++ references must be handled exactly the same way. However SWIG will automatically wrap a <tt>const int&</tt> as an input parameter (since that it obviously input).</p>
|
||||
|
||||
<H3><a name="Lua_nn26"></a>25.4.3 Typemaps and arrays</H3>
|
||||
<H3><a name="Lua_nn27"></a>26.4.3 Typemaps and arrays</H3>
|
||||
|
||||
|
||||
<p>Arrays present a challenge for SWIG, because like pointers SWIG does not know whether these are input or output values, nor
|
||||
|
|
@ -1260,7 +1408,7 @@ and Lua tables to be 1..N, (the indexing follows the norm for the language). In
|
|||
|
||||
<p>Note: SWIG also can support arrays of pointers in a similar manner.</p>
|
||||
|
||||
<H3><a name="Lua_nn27"></a>25.4.4 Typemaps and pointer-pointer functions</H3>
|
||||
<H3><a name="Lua_nn28"></a>26.4.4 Typemaps and pointer-pointer functions</H3>
|
||||
|
||||
|
||||
<p>Several C++ libraries use a pointer-pointer functions to create its objects. These functions require a pointer to a pointer which is then filled with the pointer to the new object. Microsoft's COM and DirectX as well as many other libraries have this kind of function. An example is given below:</p>
|
||||
|
|
@ -1279,7 +1427,7 @@ ok=Create_Math(&ptr);
|
|||
free(ptr); // dispose of iMath
|
||||
</pre></div>
|
||||
|
||||
<p>SWIG has a ready written typemap to deal with such a kind of function in <typemaps.i>. It provides the correct wrappering as well as setting the flag to inform Lua that the object in question should be garbage collected. Therefore the code is simply:</p>
|
||||
<p>SWIG has a ready written typemap to deal with such a kind of function in <typemaps.i>. It provides the correct wrapping as well as setting the flag to inform Lua that the object in question should be garbage collected. Therefore the code is simply:</p>
|
||||
|
||||
<div class="code"><pre>%include <typemaps.i>
|
||||
%apply SWIGTYPE** OUTPUT{iMath **pptr }; // tell SWIG its an output
|
||||
|
|
@ -1294,16 +1442,16 @@ int Create_Math(iMath** pptr); // its creator (assume it mallocs)
|
|||
ptr=nil -- the iMath* will be GC'ed as normal
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Lua_nn28"></a>25.5 Writing typemaps</H2>
|
||||
<H2><a name="Lua_nn29"></a>26.5 Writing typemaps</H2>
|
||||
|
||||
|
||||
<p>This section describes how you can modify SWIG's default wrapping behavior for various C/C++ datatypes using the <tt>%typemap</tt> directive. This is an advanced topic that assumes familiarity with the Lua C API as well as the material in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter.</p>
|
||||
|
||||
<p>Before proceeding, it should be stressed that writing typemaps is rarely needed unless you want to change some aspect of the wrappering, or to achieve an effect which in not available with the default bindings.</p>
|
||||
<p>Before proceeding, it should be stressed that writing typemaps is rarely needed unless you want to change some aspect of the wrapping, or to achieve an effect which in not available with the default bindings.</p>
|
||||
|
||||
<p>Before proceeding, you should read the previous section on using typemaps, as well as read the ready written typemaps found in luatypemaps.swg and typemaps.i. These are both well documented and fairly easy to read. You should not attempt to write your own typemaps until you have read and can understand both of these files (they may well also give you a idea to base your worn on).</p>
|
||||
|
||||
<H3><a name="Lua_nn29"></a>25.5.1 Typemaps you can write</H3>
|
||||
<H3><a name="Lua_nn30"></a>26.5.1 Typemaps you can write</H3>
|
||||
|
||||
|
||||
<p>There are many different types of typemap that can be written, the full list can be found in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter. However the following are the most commonly used ones.</p>
|
||||
|
|
@ -1316,7 +1464,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
|
|||
(the syntax for the typecheck is different from the typemap, see typemaps for details).</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Lua_nn30"></a>25.5.2 SWIG's Lua-C API</H3>
|
||||
<H3><a name="Lua_nn31"></a>26.5.2 SWIG's Lua-C API</H3>
|
||||
|
||||
|
||||
<p>This section explains the SWIG specific Lua-C API. It does not cover the main Lua-C api, as this is well documented and not worth covering.</p>
|
||||
|
|
@ -1324,7 +1472,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
|
|||
<p><tt>int SWIG_ConvertPtr(lua_State* L,int index,void** ptr,swig_type_info *type,int flags);</tt></p>
|
||||
|
||||
<div class="indent">
|
||||
This is the standard function used for converting a Lua userdata to a void*. It takes the value at the given index in the Lua state and converts it to a userdata. It will then provide the neccesary type checks, confirming that the pointer is compatible with the type given in 'type'. Then finally setting '*ptr' to the pointer.
|
||||
This is the standard function used for converting a Lua userdata to a void*. It takes the value at the given index in the Lua state and converts it to a userdata. It will then provide the necessary type checks, confirming that the pointer is compatible with the type given in 'type'. Then finally setting '*ptr' to the pointer.
|
||||
If flags is set to SWIG_POINTER_DISOWN, this is will clear any ownership flag set on the object.<br>
|
||||
The returns a value which can be checked with the macro SWIG_IsOK()
|
||||
</div>
|
||||
|
|
@ -1345,7 +1493,7 @@ This function is a version of SWIG_ConvertPtr(), except that it will either work
|
|||
<p><tt>SWIG_fail</tt></p>
|
||||
|
||||
<div class="indent">
|
||||
This macro, when called within the context of a SWIG wrappered function, will jump to the error handler code. This will call any cleanup code (freeing any temp variables) and then triggers a lua_error.<br>
|
||||
This macro, when called within the context of a SWIG wrapped function, will jump to the error handler code. This will call any cleanup code (freeing any temp variables) and then triggers a lua_error.<br>
|
||||
A common use for this code is:<br><pre>
|
||||
if (!SWIG_IsOK(SWIG_ConvertPtr( .....)){
|
||||
lua_pushstring(L,"something bad happened");
|
||||
|
|
@ -1355,7 +1503,7 @@ if (!SWIG_IsOK(SWIG_ConvertPtr( .....)){
|
|||
<p><tt>SWIG_fail_arg(char* func_name,int argnum,char* type)</tt></p>
|
||||
|
||||
<div class="indent">
|
||||
This macro, when called within the context of a SWIG wrappered function, will display the error message and jump to the error handler code. The error message is of the form
|
||||
This macro, when called within the context of a SWIG wrapped function, will display the error message and jump to the error handler code. The error message is of the form
|
||||
<pre>
|
||||
"Error in <i>func_name</i> (arg <i>argnum</i>), expected '<i>type</i>' got '<i>whatever the type was</i>'"
|
||||
</pre></div>
|
||||
|
|
@ -1365,7 +1513,7 @@ This macro, when called within the context of a SWIG wrappered function, will di
|
|||
<div class="indent">
|
||||
Similar to SWIG_fail_arg, except that it will display the swig_type_info information instead.</div>
|
||||
|
||||
<H2><a name="Lua_nn31"></a>25.6 Customization of your Bindings</H2>
|
||||
<H2><a name="Lua_nn32"></a>26.6 Customization of your Bindings</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1374,11 +1522,11 @@ This section covers adding of some small extra bits to your module to add the la
|
|||
|
||||
|
||||
|
||||
<H3><a name="Lua_nn32"></a>25.6.1 Writing your own custom wrappers</H3>
|
||||
<H3><a name="Lua_nn33"></a>26.6.1 Writing your own custom wrappers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Sometimes, it may be neccesary to add your own special functions, which bypass the normal SWIG wrappering method, and just use the native Lua API calls. These 'native' functions allow direct adding of your own code into the module. This is performed with the <tt>%native</tt> directive as follows:
|
||||
Sometimes, it may be necessary to add your own special functions, which bypass the normal SWIG wrapper method, and just use the native Lua API calls. These 'native' functions allow direct adding of your own code into the module. This is performed with the <tt>%native</tt> directive as follows:
|
||||
</p>
|
||||
<div class="code"><pre>%native(my_func) int native_function(lua_State*L); // registers native_function() with SWIG
|
||||
...
|
||||
|
|
@ -1390,10 +1538,10 @@ int native_function(lua_State*L) // my native code
|
|||
%}
|
||||
</pre></div>
|
||||
<p>
|
||||
The <tt>%native</tt> directive in the above example, tells SWIG that there is a function <tt>int native_function(lua_State*L);</tt> which is to be added into the module under the name '<tt>my_func</tt>'. SWIG will not add any wrappering for this function, beyond adding it into the function table. How you write your code is entirely up to you.
|
||||
The <tt>%native</tt> directive in the above example, tells SWIG that there is a function <tt>int native_function(lua_State*L);</tt> which is to be added into the module under the name '<tt>my_func</tt>'. SWIG will not add any wrapper for this function, beyond adding it into the function table. How you write your code is entirely up to you.
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn33"></a>25.6.2 Adding additional Lua code</H3>
|
||||
<H3><a name="Lua_nn34"></a>26.6.2 Adding additional Lua code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1431,18 +1579,18 @@ Good uses for this feature is adding of new code, or writing helper functions to
|
|||
See Examples/lua/arrays for an example of this code.
|
||||
</p>
|
||||
|
||||
<H2><a name="Lua_nn34"></a>25.7 Details on the Lua binding</H2>
|
||||
<H2><a name="Lua_nn35"></a>26.7 Details on the Lua binding</H2>
|
||||
|
||||
|
||||
<p>
|
||||
In the previous section, a high-level view of Lua wrapping was presented. Obviously a lot of stuff happens behind the scenes to make this happen. This section will explain some of the low-level details on how this is achieved.
|
||||
</p>
|
||||
<p>
|
||||
<i>If you just want to use SWIG and don't care how it works, then stop reading here. This is going into the guts of the code and how it works. Its mainly for people who need to know whats going on within the code.
|
||||
<i>If you just want to use SWIG and don't care how it works, then stop reading here. This is going into the guts of the code and how it works. It's mainly for people who need to know what's going on within the code.
|
||||
</i>
|
||||
</p>
|
||||
|
||||
<H3><a name="Lua_nn35"></a>25.7.1 Binding global data into the module.</H3>
|
||||
<H3><a name="Lua_nn36"></a>26.7.1 Binding global data into the module.</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1502,7 +1650,7 @@ end
|
|||
<p>
|
||||
That way when you call '<tt>a=example.Foo</tt>', the interpreter looks at the table 'example' sees that there is no field 'Foo' and calls __index. This will in turn check in '.get' table and find the existence of 'Foo' and then return the value of the C function call 'Foo_get()'. Similarly for the code '<tt>example.Foo=10</tt>', the interpreter will check the table, then call the __newindex which will then check the '.set' table and call the C function 'Foo_set(10)'.
|
||||
</p>
|
||||
<H3><a name="Lua_nn36"></a>25.7.2 Userdata and Metatables</H3>
|
||||
<H3><a name="Lua_nn37"></a>26.7.2 Userdata and Metatables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1577,16 +1725,16 @@ So when 'p:Print()' is called, the __index looks on the object metatable for a '
|
|||
In theory, you can play with this usertable & add new features, but remember that it is a shared table between all instances of one class, and you could very easily corrupt the functions in all the instances.
|
||||
</p>
|
||||
<p>
|
||||
Note: Both the opaque structures (like the FILE*) and normal wrappered classes/structs use the same 'swig_lua_userdata' structure. Though the opaque structures has do not have a metatable attached, or any information on how to dispose of them when the interpreter has finished with them.
|
||||
Note: Both the opaque structures (like the FILE*) and normal wrapped classes/structs use the same 'swig_lua_userdata' structure. Though the opaque structures has do not have a metatable attached, or any information on how to dispose of them when the interpreter has finished with them.
|
||||
</p>
|
||||
<p>
|
||||
Note: Operator overloads are basically done in the same way, by adding functions such as '__add' & '__call' to the classes metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming its an operator overload.
|
||||
</p>
|
||||
<H3><a name="Lua_nn37"></a>25.7.3 Memory management</H3>
|
||||
<H3><a name="Lua_nn38"></a>26.7.3 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Lua is very helpful with the memory management. The 'swig_lua_userdata' is fully managed by the interpreter itself. This means that neither the C code nor the Lua code can damage it. Once a piece of userdata has no references to it, it is not instantly collected, but will be collected when Lua deems is necessary. (You can force collection by calling the Lua function <tt>collectgarbage()</tt>). Once the userdata is about to be free'ed, the interpreter will check the userdata for a metatable and for a function '__gc'. If this exists this is called. For all complete types (ie normal wrappered classes & structs) this should exist. The '__gc' function will check the 'swig_lua_userdata' to check for the 'own' field and if this is true (which is will be for all owned data's) it will then call the destructor on the pointer.
|
||||
Lua is very helpful with the memory management. The 'swig_lua_userdata' is fully managed by the interpreter itself. This means that neither the C code nor the Lua code can damage it. Once a piece of userdata has no references to it, it is not instantly collected, but will be collected when Lua deems is necessary. (You can force collection by calling the Lua function <tt>collectgarbage()</tt>). Once the userdata is about to be free'ed, the interpreter will check the userdata for a metatable and for a function '__gc'. If this exists this is called. For all complete types (ie normal wrapped classes & structs) this should exist. The '__gc' function will check the 'swig_lua_userdata' to check for the 'own' field and if this is true (which is will be for all owned data) it will then call the destructor on the pointer.
|
||||
</p>
|
||||
<p>
|
||||
It is currently not recommended to edit this field or add some user code, to change the behaviour. Though for those who wish to try, here is where to look.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
<link rel="stylesheet" type="text/css" href="style.css">
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
<H1><a name="Modula3"></a>26 SWIG and Modula-3</H1>
|
||||
<H1><a name="Modula3"></a>27 SWIG and Modula-3</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -54,7 +54,7 @@ especially
|
|||
<a href="Typemaps.html#Typemaps">typemaps</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_modula3_overview"></a>26.1 Overview</H2>
|
||||
<H2><a name="Modula3_modula3_overview"></a>27.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -84,7 +84,7 @@ FFTW
|
|||
</li>
|
||||
</ol>
|
||||
|
||||
<H3><a name="Modula3_motivation"></a>26.1.1 Motivation</H3>
|
||||
<H3><a name="Modula3_motivation"></a>27.1.1 Motivation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -131,10 +131,10 @@ functions), but it doesn't allow you to easily integrate a Module-3 module into
|
|||
a C/C++ project.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_conception"></a>26.2 Conception</H2>
|
||||
<H2><a name="Modula3_conception"></a>27.2 Conception</H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_cinterface"></a>26.2.1 Interfaces to C libraries</H3>
|
||||
<H3><a name="Modula3_cinterface"></a>27.2.1 Interfaces to C libraries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -283,7 +283,7 @@ and the principal type must be renamed (<tt>%typemap</tt>).
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_cppinterface"></a>26.2.2 Interfaces to C++ libraries</H3>
|
||||
<H3><a name="Modula3_cppinterface"></a>27.2.2 Interfaces to C++ libraries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -384,10 +384,10 @@ There is no C++ library I wrote a SWIG interface for,
|
|||
so I'm not sure if this is possible or sensible, yet.
|
||||
</p>
|
||||
|
||||
<H2><a name="Modula3_preliminaries"></a>26.3 Preliminaries</H2>
|
||||
<H2><a name="Modula3_preliminaries"></a>27.3 Preliminaries</H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_compilers"></a>26.3.1 Compilers</H3>
|
||||
<H3><a name="Modula3_compilers"></a>27.3.1 Compilers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -400,7 +400,7 @@ For testing examples I use Critical Mass cm3.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_commandline"></a>26.3.2 Additional Commandline Options</H3>
|
||||
<H3><a name="Modula3_commandline"></a>27.3.2 Additional Commandline Options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -477,10 +477,10 @@ Instead generate templates for some basic typemaps.
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H2><a name="Modula3_typemaps"></a>26.4 Modula-3 typemaps</H2>
|
||||
<H2><a name="Modula3_typemaps"></a>27.4 Modula-3 typemaps</H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_inoutparam"></a>26.4.1 Inputs and outputs</H3>
|
||||
<H3><a name="Modula3_inoutparam"></a>27.4.1 Inputs and outputs</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -694,7 +694,7 @@ consist of the following parts:
|
|||
</table>
|
||||
|
||||
|
||||
<H3><a name="Modula3_ordinals"></a>26.4.2 Subranges, Enumerations, Sets</H3>
|
||||
<H3><a name="Modula3_ordinals"></a>27.4.2 Subranges, Enumerations, Sets</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -746,7 +746,7 @@ that I'd like to automate.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_class"></a>26.4.3 Objects</H3>
|
||||
<H3><a name="Modula3_class"></a>27.4.3 Objects</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -759,7 +759,7 @@ is not really useful, yet.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Modula3_imports"></a>26.4.4 Imports</H3>
|
||||
<H3><a name="Modula3_imports"></a>27.4.4 Imports</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -792,7 +792,7 @@ IMPORT M3toC;
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Modula3_exceptions"></a>26.4.5 Exceptions</H3>
|
||||
<H3><a name="Modula3_exceptions"></a>27.4.5 Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -816,7 +816,7 @@ you should declare
|
|||
<tt>%typemap("m3wrapinconv:throws") blah * %{OSError.E%}</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Modula3_typemap_example"></a>26.4.6 Example</H3>
|
||||
<H3><a name="Modula3_typemap_example"></a>27.4.6 Example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -863,10 +863,10 @@ where almost everything is generated by a typemap:
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H2><a name="Modula3_hints"></a>26.5 More hints to the generator</H2>
|
||||
<H2><a name="Modula3_hints"></a>27.5 More hints to the generator</H2>
|
||||
|
||||
|
||||
<H3><a name="Modula3_features"></a>26.5.1 Features</H3>
|
||||
<H3><a name="Modula3_features"></a>27.5.1 Features</H3>
|
||||
|
||||
|
||||
<table border summary="Modula-3 features">
|
||||
|
|
@ -903,7 +903,7 @@ where almost everything is generated by a typemap:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Modula3_pragmas"></a>26.5.2 Pragmas</H3>
|
||||
<H3><a name="Modula3_pragmas"></a>27.5.2 Pragmas</H3>
|
||||
|
||||
|
||||
<table border summary="Modula-3 pragmas">
|
||||
|
|
@ -926,7 +926,7 @@ where almost everything is generated by a typemap:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
<H2><a name="Modula3_remarks"></a>26.6 Remarks</H2>
|
||||
<H2><a name="Modula3_remarks"></a>27.6 Remarks</H2>
|
||||
|
||||
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Mzscheme"></a>27 SWIG and MzScheme/Racket</H1>
|
||||
<H1><a name="Mzscheme"></a>28 SWIG and MzScheme/Racket</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
<p>
|
||||
This section contains information on SWIG's support of Racket, formally known as MzScheme.
|
||||
|
||||
<H2><a name="MzScheme_nn2"></a>27.1 Creating native structures</H2>
|
||||
<H2><a name="MzScheme_nn2"></a>28.1 Creating native structures</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -65,7 +65,7 @@ Then in scheme, you can use regular struct access procedures like
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="MzScheme_simple"></a>27.2 Simple example</H2>
|
||||
<H2><a name="MzScheme_simple"></a>28.2 Simple example</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -166,7 +166,7 @@ Some points of interest:
|
|||
<li> The above requests mzc to create an extension using the CGC garbage-collector. The alternative -- the 3m collector -- has generally better performance, but work is still required for SWIG to emit code which is compatible with it.
|
||||
</ul>
|
||||
|
||||
<H2><a name="MzScheme_external_docs"></a>27.3 External documentation</H2>
|
||||
<H2><a name="MzScheme_external_docs"></a>28.3 External documentation</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
<body bgcolor="#ffffff">
|
||||
<a name="n1"></a>
|
||||
<H1><a name="Ocaml"></a>28 SWIG and Ocaml</H1>
|
||||
<H1><a name="Ocaml"></a>29 SWIG and Ocaml</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -80,7 +80,7 @@ If you're not familiar with the Objective Caml language, you can visit
|
|||
<a href="http://www.ocaml.org/">The Ocaml Website</a>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn2"></a>28.1 Preliminaries</H2>
|
||||
<H2><a name="Ocaml_nn2"></a>29.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -99,7 +99,7 @@ file Examples/Makefile illustrate how to compile and link SWIG modules that
|
|||
will be loaded dynamically. This has only been tested on Linux so far.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn3"></a>28.1.1 Running SWIG</H3>
|
||||
<H3><a name="Ocaml_nn3"></a>29.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,7 +122,7 @@ you will compile the file <tt>example_wrap.c</tt> with <tt>ocamlc</tt> or
|
|||
the resulting .ml and .mli files as well, and do the final link with -custom
|
||||
(not needed for native link). </p>
|
||||
|
||||
<H3><a name="Ocaml_nn4"></a>28.1.2 Compiling the code</H3>
|
||||
<H3><a name="Ocaml_nn4"></a>29.1.2 Compiling the code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -158,7 +158,7 @@ the user more freedom with respect to custom typing.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Ocaml_nn5"></a>28.1.3 The camlp4 module</H3>
|
||||
<H3><a name="Ocaml_nn5"></a>29.1.3 The camlp4 module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -234,7 +234,7 @@ let b = C_string (getenv "PATH")
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn6"></a>28.1.4 Using your module</H3>
|
||||
<H3><a name="Ocaml_nn6"></a>29.1.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -248,7 +248,7 @@ When linking any ocaml bytecode with your module, use the -custom
|
|||
option is not needed when you build native code.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn7"></a>28.1.5 Compilation problems and compiling with C++</H3>
|
||||
<H3><a name="Ocaml_nn7"></a>29.1.5 Compilation problems and compiling with C++</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -259,7 +259,7 @@ liberal with pointer types may not compile under the C++ compiler.
|
|||
Most code meant to be compiled as C++ will not have problems.
|
||||
</p>
|
||||
|
||||
<H2><a name="Ocaml_nn8"></a>28.2 The low-level Ocaml/C interface</H2>
|
||||
<H2><a name="Ocaml_nn8"></a>29.2 The low-level Ocaml/C interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -360,7 +360,7 @@ is that you must append them to the return list with swig_result = caml_list_a
|
|||
signature for a function that uses value in this way.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn9"></a>28.2.1 The generated module</H3>
|
||||
<H3><a name="Ocaml_nn9"></a>29.2.1 The generated module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -394,7 +394,7 @@ it describes the output SWIG will generate for class definitions.
|
|||
</td></tr>
|
||||
</table>
|
||||
|
||||
<H3><a name="Ocaml_nn10"></a>28.2.2 Enums</H3>
|
||||
<H3><a name="Ocaml_nn10"></a>29.2.2 Enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -457,7 +457,7 @@ val x : Enum_test.c_obj = C_enum `a
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Ocaml_nn11"></a>28.2.2.1 Enum typing in Ocaml</H4>
|
||||
<H4><a name="Ocaml_nn11"></a>29.2.2.1 Enum typing in Ocaml</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -470,10 +470,10 @@ functions imported from different modules. You must convert values to master
|
|||
values using the swig_val function before sharing them with another module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn12"></a>28.2.3 Arrays</H3>
|
||||
<H3><a name="Ocaml_nn12"></a>29.2.3 Arrays</H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn13"></a>28.2.3.1 Simple types of bounded arrays</H4>
|
||||
<H4><a name="Ocaml_nn13"></a>29.2.3.1 Simple types of bounded arrays</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -494,7 +494,7 @@ arrays of simple types with known bounds in your code, but this only works
|
|||
for arrays whose bounds are completely specified.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn14"></a>28.2.3.2 Complex and unbounded arrays</H4>
|
||||
<H4><a name="Ocaml_nn14"></a>29.2.3.2 Complex and unbounded arrays</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -507,7 +507,7 @@ SWIG can't predict which of these methods will be used in the array,
|
|||
so you have to specify it for yourself in the form of a typemap.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn15"></a>28.2.3.3 Using an object</H4>
|
||||
<H4><a name="Ocaml_nn15"></a>29.2.3.3 Using an object</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -521,7 +521,7 @@ Consider writing an object when the ending condition of your array is complex,
|
|||
such as using a required sentinel, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn16"></a>28.2.3.4 Example typemap for a function taking float * and int</H4>
|
||||
<H4><a name="Ocaml_nn16"></a>29.2.3.4 Example typemap for a function taking float * and int</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -572,7 +572,7 @@ void printfloats( float *tab, int len );
|
|||
</pre></td></tr></table>
|
||||
|
||||
|
||||
<H3><a name="Ocaml_nn17"></a>28.2.4 C++ Classes</H3>
|
||||
<H3><a name="Ocaml_nn17"></a>29.2.4 C++ Classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -615,7 +615,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the
|
|||
returned value for the same object.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn18"></a>28.2.4.1 STL vector and string Example</H4>
|
||||
<H4><a name="Ocaml_nn18"></a>29.2.4.1 STL vector and string Example</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -695,7 +695,7 @@ baz
|
|||
#
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn19"></a>28.2.4.2 C++ Class Example</H4>
|
||||
<H4><a name="Ocaml_nn19"></a>29.2.4.2 C++ Class Example</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -725,7 +725,7 @@ public:
|
|||
};
|
||||
</pre></td></tr></table>
|
||||
|
||||
<H4><a name="Ocaml_nn20"></a>28.2.4.3 Compiling the example</H4>
|
||||
<H4><a name="Ocaml_nn20"></a>29.2.4.3 Compiling the example</H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -743,7 +743,7 @@ bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
|
|||
-L$QTPATH/lib -cclib -lqt
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn21"></a>28.2.4.4 Sample Session</H4>
|
||||
<H4><a name="Ocaml_nn21"></a>29.2.4.4 Sample Session</H4>
|
||||
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -770,10 +770,10 @@ Assuming you have a working installation of QT, you will see a window
|
|||
containing the string "hi" in a button.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn22"></a>28.2.5 Director Classes</H3>
|
||||
<H3><a name="Ocaml_nn22"></a>29.2.5 Director Classes</H3>
|
||||
|
||||
|
||||
<H4><a name="Ocaml_nn23"></a>28.2.5.1 Director Introduction</H4>
|
||||
<H4><a name="Ocaml_nn23"></a>29.2.5.1 Director Introduction</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -800,7 +800,7 @@ class foo {
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Ocaml_nn24"></a>28.2.5.2 Overriding Methods in Ocaml</H4>
|
||||
<H4><a name="Ocaml_nn24"></a>29.2.5.2 Overriding Methods in Ocaml</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -828,7 +828,7 @@ In this example, I'll examine the objective caml code involved in providing
|
|||
an overloaded class. This example is contained in Examples/ocaml/shapes.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn25"></a>28.2.5.3 Director Usage Example</H4>
|
||||
<H4><a name="Ocaml_nn25"></a>29.2.5.3 Director Usage Example</H4>
|
||||
|
||||
|
||||
<table border="1" bgcolor="#dddddd" summary="Director usage example">
|
||||
|
|
@ -887,7 +887,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the
|
|||
program in C++.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn26"></a>28.2.5.4 Creating director objects</H4>
|
||||
<H4><a name="Ocaml_nn26"></a>29.2.5.4 Creating director objects</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -928,7 +928,7 @@ object from causing a core dump, as long as the object is destroyed
|
|||
properly.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn27"></a>28.2.5.5 Typemaps for directors, <tt>directorin, directorout, directorargout</tt></H4>
|
||||
<H4><a name="Ocaml_nn27"></a>29.2.5.5 Typemaps for directors, <tt>directorin, directorout, directorargout</tt></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -939,7 +939,7 @@ well as a function return value in the same way you provide function arguments,
|
|||
and to receive arguments the same way you normally receive function returns.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn28"></a>28.2.5.6 <tt>directorin</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn28"></a>29.2.5.6 <tt>directorin</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -950,7 +950,7 @@ code receives when you are called. In general, a simple <tt>directorin</tt> typ
|
|||
can use the same body as a simple <tt>out</tt> typemap.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn29"></a>28.2.5.7 <tt>directorout</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn29"></a>29.2.5.7 <tt>directorout</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -961,7 +961,7 @@ for the same type, except when there are special requirements for object
|
|||
ownership, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn30"></a>28.2.5.8 <tt>directorargout</tt> typemap</H4>
|
||||
<H4><a name="Ocaml_nn30"></a>29.2.5.8 <tt>directorargout</tt> typemap</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -978,7 +978,7 @@ In the event that you don't specify all of the necessary values, integral
|
|||
values will read zero, and struct or object returns have undefined results.
|
||||
</p>
|
||||
|
||||
<H3><a name="Ocaml_nn31"></a>28.2.6 Exceptions</H3>
|
||||
<H3><a name="Ocaml_nn31"></a>29.2.6 Exceptions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -8,13 +8,14 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Octave"></a>29 SWIG and Octave</H1>
|
||||
<H1><a name="Octave"></a>30 SWIG and Octave</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
<li><a href="#Octave_nn2">Preliminaries</a>
|
||||
<li><a href="#Octave_nn3">Running SWIG</a>
|
||||
<ul>
|
||||
<li><a href="#Octave_nn4">Command-line options</a>
|
||||
<li><a href="#Octave_nn5">Compiling a dynamic module</a>
|
||||
<li><a href="#Octave_nn6">Using your module</a>
|
||||
</ul>
|
||||
|
|
@ -54,14 +55,18 @@ More information can be found at <a href="http://www.gnu.org/software/octave/">O
|
|||
Also, there are a dozen or so examples in the Examples/octave directory, and hundreds in the test suite (Examples/test-suite and Examples/test-suite/octave).
|
||||
</p>
|
||||
|
||||
<H2><a name="Octave_nn2"></a>29.1 Preliminaries</H2>
|
||||
<H2><a name="Octave_nn2"></a>30.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
The SWIG implemention was first based on Octave 2.9.12, so this is the minimum version required. Testing has only been done on Linux.
|
||||
</p>
|
||||
|
||||
<H2><a name="Octave_nn3"></a>29.2 Running SWIG</H2>
|
||||
<p>
|
||||
As of SWIG 2.0.5, the Octave module should work with Octave versions 3.0.5, 3.2.4, and 3.4.0.
|
||||
</p>
|
||||
|
||||
<H2><a name="Octave_nn3"></a>30.2 Running SWIG</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -80,24 +85,44 @@ extern double Foo; </pre></div>
|
|||
To build an Octave module when wrapping C code, run SWIG using the <tt>-octave</tt> option:
|
||||
</p>
|
||||
|
||||
<div class="shell"><pre>$ swig -octave example.i </pre></div>
|
||||
<div class="shell"><pre>$ swig -octave -o example_wrap.cpp example.i </pre></div>
|
||||
|
||||
<p>
|
||||
The <tt>-c++</tt> option is also required when wrapping C++ code:
|
||||
</p>
|
||||
|
||||
|
||||
<div class="shell"><pre>$ swig -octave -c++ example.i </pre></div>
|
||||
<div class="shell"><pre>$ swig -octave -c++ -o example_wrap.cpp example.i </pre></div>
|
||||
|
||||
<p>
|
||||
This creates a C++ source file <tt>example_wrap.cxx</tt>. A C++ file is generated even when wrapping C code as Octave is itself written in C++ and requires wrapper code to be in the same language. The generated C++ source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application (in this case, the gcd implementation) to create an extension module.
|
||||
This creates a C++ source file <tt>example_wrap.cpp</tt>. A C++ file is generated even when wrapping C code as Octave is itself written in C++ and requires wrapper code to be in the same language. The generated C++ source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application (in this case, the gcd implementation) to create an extension module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn4"></a>30.2.1 Command-line options</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The swig command line has a number of options you can use, like to redirect it's output. Use <tt>swig --help</tt> to learn about these.
|
||||
The swig command line has a number of options you can use, like to redirect its output. Use <tt>swig -help</tt> to learn about these.
|
||||
Options specific to the Octave module are:
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn5"></a>29.2.1 Compiling a dynamic module</H3>
|
||||
<div class="shell">
|
||||
<pre>$ swig -octave -help
|
||||
...
|
||||
Octave Options (available with -octave)
|
||||
-global - Load all symbols into the global namespace [default]
|
||||
-globals <em>name</em> - Set <em>name</em> used to access C global variables [default: 'cvar']
|
||||
-noglobal - Do not load all symbols into the global namespace
|
||||
-opprefix <em>str</em> - Prefix <em>str</em> for global operator functions [default: 'op_']
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The <em>-global</em> and <em>-noglobal</em> options determine whether the Octave module will load all symbols into the global namespace in addition to the global namespace.
|
||||
The <em>-globals</em> option sets the name of the variable which is the namespace for C global variables exported by the module.
|
||||
The <em>-opprefix</em> options sets the prefix of the names of global/friend <a href="#Octave_nn18">operator</a> functions.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn5"></a>30.2.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -106,8 +131,8 @@ Building an oct file is usually done with the mkoctfile command (either within O
|
|||
</p>
|
||||
|
||||
<div class="shell"><pre>
|
||||
$ swig -octave -c++ example.i -o example_wrap.cxx
|
||||
$ mkoctfile example_wrap.cxx example.c
|
||||
$ swig -octave -c++ -o example_wrap.cpp example.i
|
||||
$ mkoctfile example_wrap.cpp example.c
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -124,7 +149,7 @@ $ mkoctfile example_wrap.cxx example.c
|
|||
|
||||
<div class="targetlang"><pre>octave:1> example</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn6"></a>29.2.2 Using your module</H3>
|
||||
<H3><a name="Octave_nn6"></a>30.2.3 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -142,10 +167,10 @@ octave:4> example.cvar.Foo=4;
|
|||
octave:5> example.cvar.Foo
|
||||
ans = 4 </pre></div>
|
||||
|
||||
<H2><a name="Octave_nn7"></a>29.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Octave_nn7"></a>30.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<H3><a name="Octave_nn8"></a>29.3.1 Modules</H3>
|
||||
<H3><a name="Octave_nn8"></a>30.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -157,37 +182,73 @@ When Octave is asked to invoke <tt>example</tt>, it will try to find the .m or .
|
|||
</p>
|
||||
|
||||
<p>
|
||||
Giving this function a parameter "global" will cause it to load all symbols into the global namespace in addition to the <tt>example</tt> namespace. For example:
|
||||
An Octave module takes three options, <em>-global</em>, <em>-noglobal</em>, and <em>-globals</em>, which behave the same as the corresponding swig <a href="#Octave_nn4">command-line options</a>.
|
||||
Here are some example usages:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>$ octave -q
|
||||
octave:1> example("global")
|
||||
octave:2> gcd(4,6)
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> example -help
|
||||
usage: example [-global|-noglobal] [-globals <name>]
|
||||
octave:2> example -global
|
||||
octave:3> gcd(4,6)
|
||||
ans = 2
|
||||
octave:3> cvar.Foo
|
||||
octave:4> cvar.Foo
|
||||
ans = 3
|
||||
octave:4> cvar.Foo=4;
|
||||
octave:5> cvar.Foo
|
||||
ans = 4
|
||||
octave:5> cvar.Foo=4;
|
||||
octave:6> cvar.Foo
|
||||
ans = 4
|
||||
</pre></div>
|
||||
<br>
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> example -noglobal
|
||||
octave:2> gcd(6,9)
|
||||
ans = 3
|
||||
octave:3> cvar.Foo
|
||||
error: `cvar' undefined near line 3 column 1
|
||||
octave:3> example.cvar.Foo
|
||||
ans = 3
|
||||
</pre></div>
|
||||
<br>
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> example -globals mycvar
|
||||
octave:2> cvar.Foo
|
||||
error: `cvar' undefined near line 2 column 1
|
||||
octave:2> mycvar.Foo
|
||||
ans = 3
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
It is also possible to rename the module namespace with an assignment, as in: <br>
|
||||
<div class="targetlang"><pre>octave:1> example;
|
||||
It is also possible to rename the module / global variables namespaces with an assignment, as in: <br>
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> example
|
||||
octave:2> c=example;
|
||||
octave:3> c.gcd(10,4)
|
||||
ans = 2 </pre></div>
|
||||
|
||||
<p>
|
||||
All global variables are put into the cvar namespace object. This is accessible either as <tt>my_module.cvar</tt>, or just <tt>cvar</tt> (if the module is imported into the global namespace).
|
||||
</p>
|
||||
<p>
|
||||
One can also rename it by simple assignment, e.g.,
|
||||
</p>
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> some_vars = cvar;
|
||||
ans = 2
|
||||
octave:4> some_vars = cvar;
|
||||
octave:5> some_vars.Foo
|
||||
ans = 3
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn9"></a>29.3.2 Functions</H3>
|
||||
<p>
|
||||
Modules can also be loaded from within functions, even before being loaded in the base context.
|
||||
If the module is also used in the base context, however, it must first be loaded again:
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
octave:1> function l = my_lcm(a,b)
|
||||
> example
|
||||
> l = abs(a*b)/example.gcd(a,b);
|
||||
> endfunction
|
||||
octave:2> my_lcm(4,6)
|
||||
ans = 12
|
||||
octave:3> example.gcd(4,6)
|
||||
error: can't perform indexing operations for <unknown type> type
|
||||
octave:3> example;
|
||||
octave:4> example.gcd(4,6)
|
||||
ans = 2
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn9"></a>30.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -204,7 +265,7 @@ int fact(int n); </pre></div>
|
|||
<div class="targetlang"><pre>octave:1> example.fact(4)
|
||||
24 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn10"></a>29.3.3 Global variables</H3>
|
||||
<H3><a name="Octave_nn10"></a>30.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -257,7 +318,7 @@ octave:2> example.PI=3.142;
|
|||
octave:3> example.PI
|
||||
ans = 3.1420 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn11"></a>29.3.4 Constants and enums</H3>
|
||||
<H3><a name="Octave_nn11"></a>30.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -279,7 +340,7 @@ example.SCONST="Hello World"
|
|||
example.SUNDAY=0
|
||||
.... </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn12"></a>29.3.5 Pointers</H3>
|
||||
<H3><a name="Octave_nn12"></a>30.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -326,7 +387,7 @@ octave:2> f=example.fopen("not there","r");
|
|||
error: value on right hand side of assignment is undefined
|
||||
error: evaluating assignment expression near line 2, column 2 </pre></div>
|
||||
|
||||
<H3><a name="Octave_nn13"></a>29.3.6 Structures and C++ classes</H3>
|
||||
<H3><a name="Octave_nn13"></a>30.3.6 Structures and C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -461,7 +522,7 @@ ans = 1
|
|||
Depending on the ownership setting of a <tt>swig_ref</tt>, it may call C++ destructors when its reference count goes to zero. See the section on memory management below for details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn15"></a>29.3.7 C++ inheritance</H3>
|
||||
<H3><a name="Octave_nn15"></a>30.3.7 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -470,7 +531,7 @@ This information contains the full class hierarchy. When an indexing operation (
|
|||
the tree is walked to find a match in the current class as well as any of its bases. The lookup is then cached in the <tt>swig_ref</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn17"></a>29.3.8 C++ overloaded functions</H3>
|
||||
<H3><a name="Octave_nn17"></a>30.3.8 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -480,7 +541,7 @@ The dispatch function selects which overload to call (if any) based on the passe
|
|||
<tt>typecheck</tt> typemaps are used to analyze each argument, as well as assign precedence. See the chapter on typemaps for details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn18"></a>29.3.9 C++ operators</H3>
|
||||
<H3><a name="Octave_nn18"></a>30.3.9 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -580,7 +641,11 @@ On the C++ side, the default mappings are as follows:
|
|||
%rename(__brace) *::operator[];
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn19"></a>29.3.10 Class extension with %extend</H3>
|
||||
<p>
|
||||
Octave can also utilise friend (i.e. non-member) operators with a simple %rename: see the example in the Examples/octave/operator directory.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn19"></a>30.3.10 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -610,7 +675,7 @@ octave:3> printf("%s\n",a);
|
|||
octave:4> a.__str()
|
||||
4
|
||||
</pre></div>
|
||||
<H3><a name="Octave_nn20"></a>29.3.11 C++ templates</H3>
|
||||
<H3><a name="Octave_nn20"></a>30.3.11 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -687,14 +752,14 @@ ans =
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Octave_nn21"></a>29.3.12 C++ Smart Pointers</H3>
|
||||
<H3><a name="Octave_nn21"></a>30.3.12 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
C++ smart pointers are fully supported as in other modules.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn22"></a>29.3.13 Directors (calling Octave from C++ code)</H3>
|
||||
<H3><a name="Octave_nn22"></a>30.3.13 Directors (calling Octave from C++ code)</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -775,14 +840,14 @@ c-side routine called
|
|||
octave-side routine called
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Octave_nn23"></a>29.3.14 Threads</H3>
|
||||
<H3><a name="Octave_nn23"></a>30.3.14 Threads</H3>
|
||||
|
||||
|
||||
<p>
|
||||
The use of threads in wrapped Director code is not supported; i.e., an Octave-side implementation of a C++ class must be called from the Octave interpreter's thread. Anything fancier (apartment/queue model, whatever) is left to the user. Without anything fancier, this amounts to the limitation that Octave must drive the module... like, for example, an optimization package that calls Octave to evaluate an objective function.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn24"></a>29.3.15 Memory management</H3>
|
||||
<H3><a name="Octave_nn24"></a>30.3.15 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -816,14 +881,14 @@ The %newobject directive may be used to control this behavior for pointers retur
|
|||
In the case where one wishes for the C++ side to own an object that was created in Octave (especially a Director object), one can use the __disown() method to invert this logic. Then letting the Octave reference count go to zero will not destroy the object, but destroying the object will invalidate the Octave-side object if it still exists (and call destructors of other C++ bases in the case of multiple inheritance/<tt>subclass()</tt>'ing).
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn25"></a>29.3.16 STL support</H3>
|
||||
<H3><a name="Octave_nn25"></a>30.3.16 STL support</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Various STL library files are provided for wrapping STL containers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Octave_nn26"></a>29.3.17 Matrix typemaps</H3>
|
||||
<H3><a name="Octave_nn26"></a>30.3.17 Matrix typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Perl5"></a>30 SWIG and Perl5</H1>
|
||||
<H1><a name="Perl5"></a>31 SWIG and Perl5</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -82,12 +82,12 @@
|
|||
This chapter describes SWIG's support of Perl5. Although the Perl5
|
||||
module is one of the earliest SWIG modules, it has continued to evolve
|
||||
and has been improved greatly with the help of SWIG users. For the
|
||||
best results, it is recommended that SWIG be used with Perl5.003 or
|
||||
later. Earlier versions are problematic and SWIG generated extensions
|
||||
may not compile or run correctly.
|
||||
best results, it is recommended that SWIG be used with Perl 5.8 or
|
||||
later. We're no longer testing regularly with older versions, but
|
||||
Perl 5.6 seems to mostly work, while older versions don't.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn2"></a>30.1 Overview</H2>
|
||||
<H2><a name="Perl5_nn2"></a>31.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -108,7 +108,7 @@ described. Advanced customization features, typemaps, and other
|
|||
options are found near the end of the chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn3"></a>30.2 Preliminaries</H2>
|
||||
<H2><a name="Perl5_nn3"></a>31.2 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -133,7 +133,7 @@ To build the module, you will need to compile the file
|
|||
<tt>example_wrap.c</tt> and link it with the rest of your program.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn4"></a>30.2.1 Getting the right header files</H3>
|
||||
<H3><a name="Perl5_nn4"></a>31.2.1 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -165,7 +165,7 @@ loaded, an easy way to find out is to run Perl itself.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn5"></a>30.2.2 Compiling a dynamic module</H3>
|
||||
<H3><a name="Perl5_nn5"></a>31.2.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -198,7 +198,7 @@ the target should be named `<tt>example.so</tt>',
|
|||
`<tt>example.sl</tt>', or the appropriate dynamic module name on your system.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn6"></a>30.2.3 Building a dynamic module with MakeMaker</H3>
|
||||
<H3><a name="Perl5_nn6"></a>31.2.3 Building a dynamic module with MakeMaker</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -232,7 +232,7 @@ the preferred approach to compilation. More information about MakeMaker can be
|
|||
found in "Programming Perl, 2nd ed." by Larry Wall, Tom Christiansen,
|
||||
and Randal Schwartz.</p>
|
||||
|
||||
<H3><a name="Perl5_nn7"></a>30.2.4 Building a static version of Perl</H3>
|
||||
<H3><a name="Perl5_nn7"></a>31.2.4 Building a static version of Perl</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -301,7 +301,7 @@ added to it. Depending on your machine, you may need to link with
|
|||
additional libraries such as <tt>-lsocket, -lnsl, -ldl</tt>, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn8"></a>30.2.5 Using the module</H3>
|
||||
<H3><a name="Perl5_nn8"></a>31.2.5 Using the module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -456,7 +456,7 @@ system configuration (this requires root access and you will need to
|
|||
read the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn9"></a>30.2.6 Compilation problems and compiling with C++</H3>
|
||||
<H3><a name="Perl5_nn9"></a>31.2.6 Compilation problems and compiling with C++</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -599,7 +599,7 @@ have to find the macro that conflicts and add an #undef into the .i file. Pleas
|
|||
any conflicting macros you find to <a href="http://www.swig.org/mail.html">swig-user mailing list</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn10"></a>30.2.7 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Perl5_nn10"></a>31.2.7 Compiling for 64-bit platforms</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -626,7 +626,7 @@ also introduce problems on platforms that support more than one
|
|||
linking standard (e.g., -o32 and -n32 on Irix).
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn11"></a>30.3 Building Perl Extensions under Windows</H2>
|
||||
<H2><a name="Perl5_nn11"></a>31.3 Building Perl Extensions under Windows</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -637,7 +637,7 @@ section assumes you are using SWIG with Microsoft Visual C++
|
|||
although the procedure may be similar with other compilers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn12"></a>30.3.1 Running SWIG from Developer Studio</H3>
|
||||
<H3><a name="Perl5_nn12"></a>31.3.1 Running SWIG from Developer Studio</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -700,7 +700,7 @@ print "$a\n";
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn13"></a>30.3.2 Using other compilers</H3>
|
||||
<H3><a name="Perl5_nn13"></a>31.3.2 Using other compilers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -708,7 +708,7 @@ SWIG is known to work with Cygwin and may work with other compilers on Windows.
|
|||
For general hints and suggestions refer to the <a href="Windows.html#Windows">Windows</a> chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn14"></a>30.4 The low-level interface</H2>
|
||||
<H2><a name="Perl5_nn14"></a>31.4 The low-level interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -718,7 +718,7 @@ can be used to control your application. However, it is also used to
|
|||
construct more user-friendly proxy classes as described in the next section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn15"></a>30.4.1 Functions</H3>
|
||||
<H3><a name="Perl5_nn15"></a>31.4.1 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -741,7 +741,7 @@ use example;
|
|||
$a = &example::fact(2);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn16"></a>30.4.2 Global variables</H3>
|
||||
<H3><a name="Perl5_nn16"></a>31.4.2 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -811,7 +811,7 @@ extern char *path; // Declared later in the input
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn17"></a>30.4.3 Constants</H3>
|
||||
<H3><a name="Perl5_nn17"></a>31.4.3 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -851,7 +851,7 @@ print example::FOO,"\n";
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn18"></a>30.4.4 Pointers</H3>
|
||||
<H3><a name="Perl5_nn18"></a>31.4.4 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -960,7 +960,7 @@ as XS and <tt>xsubpp</tt>. Given the advancement of the SWIG typesystem and the
|
|||
SWIG and XS, this is no longer supported.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn19"></a>30.4.5 Structures</H3>
|
||||
<H3><a name="Perl5_nn19"></a>31.4.5 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1094,7 +1094,7 @@ void Bar_f_set(Bar *b, Foo *val) {
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn20"></a>30.4.6 C++ classes</H3>
|
||||
<H3><a name="Perl5_nn20"></a>31.4.6 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1159,7 +1159,7 @@ provides direct access to C++ objects. A higher level interface using Perl prox
|
|||
can be built using these low-level accessors. This is described shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn21"></a>30.4.7 C++ classes and type-checking</H3>
|
||||
<H3><a name="Perl5_nn21"></a>31.4.7 C++ classes and type-checking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1195,7 +1195,7 @@ If necessary, the type-checker also adjusts the value of the pointer (as is nece
|
|||
multiple inheritance is used).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn22"></a>30.4.8 C++ overloaded functions</H3>
|
||||
<H3><a name="Perl5_nn22"></a>31.4.8 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1239,7 +1239,7 @@ example::Spam_foo_d($s,3.14);
|
|||
Please refer to the "SWIG Basics" chapter for more information.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn23"></a>30.4.9 Operators</H3>
|
||||
<H3><a name="Perl5_nn23"></a>31.4.9 Operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1266,7 +1266,7 @@ The following C++ operators are currently supported by the Perl module:
|
|||
<li>operator or </li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Perl5_nn24"></a>30.4.10 Modules and packages</H3>
|
||||
<H3><a name="Perl5_nn24"></a>31.4.10 Modules and packages</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1361,7 +1361,7 @@ print Foo::fact(4),"\n"; # Call a function in package FooBar
|
|||
</pre></div>
|
||||
-->
|
||||
|
||||
<H2><a name="Perl5_nn25"></a>30.5 Input and output parameters</H2>
|
||||
<H2><a name="Perl5_nn25"></a>31.5 Input and output parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1580,7 +1580,7 @@ print "$c\n";
|
|||
<b>Note:</b> The <tt>REFERENCE</tt> feature is only currently supported for numeric types (integers and floating point).
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn26"></a>30.6 Exception handling</H2>
|
||||
<H2><a name="Perl5_nn26"></a>31.6 Exception handling</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1745,7 +1745,7 @@ This is still supported, but it is deprecated. The newer <tt>%exception</tt> di
|
|||
functionality, but it has additional capabilities that make it more powerful.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn27"></a>30.7 Remapping datatypes with typemaps</H2>
|
||||
<H2><a name="Perl5_nn27"></a>31.7 Remapping datatypes with typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1762,7 +1762,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Perl interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn28"></a>30.7.1 A simple typemap example</H3>
|
||||
<H3><a name="Perl5_nn28"></a>31.7.1 A simple typemap example</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1866,7 +1866,7 @@ example::count("e","Hello World");
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn29"></a>30.7.2 Perl5 typemaps</H3>
|
||||
<H3><a name="Perl5_nn29"></a>31.7.2 Perl5 typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1971,7 +1971,7 @@ Return of C++ member data (all languages).
|
|||
Check value of input parameter.
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn30"></a>30.7.3 Typemap variables</H3>
|
||||
<H3><a name="Perl5_nn30"></a>31.7.3 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2042,7 +2042,7 @@ properly assigned.
|
|||
The Perl name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Perl5_nn31"></a>30.7.4 Useful functions</H3>
|
||||
<H3><a name="Perl5_nn31"></a>31.7.4 Useful functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2111,7 +2111,7 @@ int sv_isa(SV *, char *0;
|
|||
</div>
|
||||
|
||||
|
||||
<H2><a name="Perl5_nn32"></a>30.8 Typemap Examples</H2>
|
||||
<H2><a name="Perl5_nn32"></a>31.8 Typemap Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2120,7 +2120,7 @@ might look at the files "<tt>perl5.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn33"></a>30.8.1 Converting a Perl5 array to a char **</H3>
|
||||
<H3><a name="Perl5_nn33"></a>31.8.1 Converting a Perl5 array to a char **</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2212,7 +2212,7 @@ print @$b,"\n"; # Print it out
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Perl5_nn34"></a>30.8.2 Return values</H3>
|
||||
<H3><a name="Perl5_nn34"></a>31.8.2 Return values</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2241,7 +2241,7 @@ can be done using the <tt>EXTEND()</tt> macro as in :
|
|||
}
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn35"></a>30.8.3 Returning values from arguments</H3>
|
||||
<H3><a name="Perl5_nn35"></a>31.8.3 Returning values from arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2295,7 +2295,7 @@ print "multout(7,13) = @r\n";
|
|||
($x,$y) = multout(7,13);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn36"></a>30.8.4 Accessing array structure members</H3>
|
||||
<H3><a name="Perl5_nn36"></a>31.8.4 Accessing array structure members</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2358,7 +2358,7 @@ the "in" typemap in the previous section would be used to convert an
|
|||
to copy the converted array into a C data structure.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn37"></a>30.8.5 Turning Perl references into C pointers</H3>
|
||||
<H3><a name="Perl5_nn37"></a>31.8.5 Turning Perl references into C pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2423,7 +2423,7 @@ print "$c\n";
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn38"></a>30.8.6 Pointer handling</H3>
|
||||
<H3><a name="Perl5_nn38"></a>31.8.6 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2502,7 +2502,7 @@ For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Perl5_nn39"></a>30.9 Proxy classes</H2>
|
||||
<H2><a name="Perl5_nn39"></a>31.9 Proxy classes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2518,7 +2518,7 @@ to the underlying code. This section describes the implementation
|
|||
details of the proxy interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn40"></a>30.9.1 Preliminaries</H3>
|
||||
<H3><a name="Perl5_nn40"></a>31.9.1 Preliminaries</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2540,7 +2540,7 @@ SWIG creates a collection of high-level Perl wrappers. In your scripts, you wil
|
|||
high level wrappers. The wrappers, in turn, interact with the low-level procedural module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn41"></a>30.9.2 Structure and class wrappers</H3>
|
||||
<H3><a name="Perl5_nn41"></a>31.9.2 Structure and class wrappers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2666,7 +2666,7 @@ $v->DESTROY();
|
|||
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn42"></a>30.9.3 Object Ownership</H3>
|
||||
<H3><a name="Perl5_nn42"></a>31.9.3 Object Ownership</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2753,7 +2753,7 @@ counting, garbage collection, or advanced features one might find in
|
|||
sophisticated languages.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn43"></a>30.9.4 Nested Objects</H3>
|
||||
<H3><a name="Perl5_nn43"></a>31.9.4 Nested Objects</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2806,7 +2806,7 @@ $p->{f}->{x} = 0.0;
|
|||
%${$p->{v}} = ( x=>0, y=>0, z=>0);
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Perl5_nn44"></a>30.9.5 Proxy Functions</H3>
|
||||
<H3><a name="Perl5_nn44"></a>31.9.5 Proxy Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2840,7 +2840,7 @@ This function replaces the original function, but operates in an
|
|||
identical manner.
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn45"></a>30.9.6 Inheritance</H3>
|
||||
<H3><a name="Perl5_nn45"></a>31.9.6 Inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2916,7 +2916,7 @@ particular, inheritance of data members is extremely tricky (and I'm
|
|||
not even sure if it really works).
|
||||
</p>
|
||||
|
||||
<H3><a name="Perl5_nn46"></a>30.9.7 Modifying the proxy methods</H3>
|
||||
<H3><a name="Perl5_nn46"></a>31.9.7 Modifying the proxy methods</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2944,7 +2944,7 @@ public:
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Perl5_nn47"></a>30.10 Adding additional Perl code</H2>
|
||||
<H2><a name="Perl5_nn47"></a>31.10 Adding additional Perl code</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Php"></a>31 SWIG and PHP</H1>
|
||||
<H1><a name="Php"></a>32 SWIG and PHP</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -49,19 +49,23 @@
|
|||
|
||||
|
||||
<p>
|
||||
SWIG supports generating wrappers for PHP5. Support for PHP4 has been removed
|
||||
as of SWIG 1.3.37. The PHP developers are no longer making new PHP4 releases,
|
||||
SWIG supports generating wrappers for PHP5. Support for PHP4 was removed
|
||||
in SWIG 1.3.37. The PHP developers are no longer making new PHP4 releases,
|
||||
and won't even be patching critical security issues after 2008-08-08, so it
|
||||
doesn't make much sense for SWIG to continue to support PHP4 at this point.
|
||||
If you need to continue to use PHP4, stick with SWIG 1.3.36.
|
||||
doesn't make much sense for SWIG to continue to support PHP4 now. If you
|
||||
really need to continue to use PHP4, just stick with SWIG 1.3.36.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Currently any PHP5 release should work, but we don't regularly test with
|
||||
PHP < 5.3.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this chapter, we discuss SWIG's support of PHP. The PHP module
|
||||
was extensively rewritten in release 1.3.26, and support for generating
|
||||
OO wrappers for PHP5 was added in 1.3.30. The PHP module works fairly
|
||||
well, but currently does not implement all the
|
||||
features available in some of the other languages.
|
||||
OO wrappers for PHP5 was added in 1.3.30. The PHP module now supports most
|
||||
of the features available in some of the other languages.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -75,7 +79,7 @@ your extension into php directly, you will need the complete PHP source tree
|
|||
available.
|
||||
</p>
|
||||
|
||||
<H2><a name="Php_nn1"></a>31.1 Generating PHP Extensions</H2>
|
||||
<H2><a name="Php_nn1"></a>32.1 Generating PHP Extensions</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -122,7 +126,7 @@ and it doesn't play nicely with package system. We don't recommend
|
|||
this approach, or provide explicit support for it.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn1_1"></a>31.1.1 Building a loadable extension</H3>
|
||||
<H3><a name="Php_nn1_1"></a>32.1.1 Building a loadable extension</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -137,7 +141,7 @@ least work for Linux though):
|
|||
gcc -shared example_wrap.o -o example.so
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Php_nn1_3"></a>31.1.2 Using PHP Extensions</H3>
|
||||
<H3><a name="Php_nn1_3"></a>32.1.2 Using PHP Extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -168,21 +172,22 @@ attempts to do the <tt>dl()</tt> call for you:
|
|||
include("example.php");
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Php_nn2"></a>31.2 Basic PHP interface</H2>
|
||||
<H2><a name="Php_nn2"></a>32.2 Basic PHP interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
It is important to understand that PHP uses a single global namespace
|
||||
into which all symbols from extension modules are loaded. It is quite
|
||||
possible for names of symbols in one extension module to clash with
|
||||
other symbols unless care is taken to <tt>%rename</tt> them.
|
||||
other symbols unless care is taken to <tt>%rename</tt> them. At present
|
||||
SWIG doesn't have support for the namespace feature added in PHP 5.3.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_1"></a>31.2.1 Constants</H3>
|
||||
<H3><a name="Php_nn2_1"></a>32.2.1 Constants</H3>
|
||||
|
||||
|
||||
<p>
|
||||
These work in much the same way as in C/C++, constants can be defined
|
||||
These work in much the same way as in C/C++. Constants can be defined
|
||||
by using either the normal C pre-processor declarations, or the
|
||||
<tt>%constant</tt> SWIG directive. These will then be available from
|
||||
your PHP script as a PHP constant, (i.e. no dollar sign is needed to
|
||||
|
|
@ -199,7 +204,7 @@ access them.) For example, with a swig interface file like this,
|
|||
</div>
|
||||
|
||||
<p>
|
||||
you can access the constants in your php script like this,
|
||||
you can access the constants in your PHP script like this,
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -213,9 +218,16 @@ echo "E = " . E . "\n";
|
|||
</div>
|
||||
|
||||
<p>
|
||||
There are two peculiarities with using constants in PHP. The first is that
|
||||
if you try to use an undeclared constant, it will evaluate to a string
|
||||
set to the constant's name. For example,
|
||||
There's one peculiarity of how constants work in PHP which it is useful
|
||||
to note (this is not specific to SWIG though) - if you try to use an undeclared
|
||||
constant, PHP will issue a warning and then expand the constant to a string
|
||||
version of the constant's name. The warning will often be missed though as
|
||||
if you're using PHP in a webserver, it will probably end up in error.log or
|
||||
similar.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example,
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -243,67 +255,12 @@ if(EASY_TO_MISPEL) {
|
|||
</div>
|
||||
|
||||
<p>
|
||||
will issue a warning about the undeclared constant, but will then
|
||||
evaluate it and turn it into a string ('EASY_TO_MISPEL'), which
|
||||
evaluates to true, rather than the value of the constant which would
|
||||
be false. This is a feature!
|
||||
The mis-spelled constant will become the string 'EASY_TO_MISPEL', which
|
||||
is treated as true by the if test, when the value of the intended constant
|
||||
would be treated as false!
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The second 'feature' is that although constants are case sensitive (by
|
||||
default), you cannot declare a constant twice with alternative
|
||||
cases. E.g.,
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%module example
|
||||
|
||||
#define TEST Hello
|
||||
#define Test World
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
accessed from PHP,
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
include("example.php");
|
||||
|
||||
echo TEST, Test;
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
will output "Hello Test" rather than "Hello World". This is because
|
||||
internally, all constants are stored in a hash table by their lower
|
||||
case name, so 'TEST' and 'Test' will map to the same hash element
|
||||
('Test'). But, because we declared them case sensitive, the Zend
|
||||
engine will test if the case matches with the case the constant was
|
||||
declared with first.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
So, in the example above, the TEST constant was declared first, and
|
||||
will be stored under the hash element 'test'. The 'Test' constant will
|
||||
also map to the same hash element 'test', but will not overwrite
|
||||
it. When called from the script, the TEST constant will again be
|
||||
mapped to the hash element 'test' so the constant will be
|
||||
retrieved. The case will then be checked, and will match up, so the
|
||||
value ('Hello') will be returned. When 'Test' is evaluated, it will
|
||||
also map to the same hash element 'test'. The same constant will be
|
||||
retrieved, this time though the case check will fail as 'Test' !=
|
||||
'TEST'. So PHP will assume that Test is a undeclared constant, and as
|
||||
explained above, will return it as a string set to the constant name
|
||||
('Test'). Hence the script above will print 'Hello Test'. If they were
|
||||
declared non-case sensitive, the output would be 'Hello Hello', as
|
||||
both point to the same value, without the case test taking place. (
|
||||
Apologies, this paragraph needs rewriting to make some sense. )
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_2"></a>31.2.2 Global Variables</H3>
|
||||
<H3><a name="Php_nn2_2"></a>32.2.2 Global Variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -352,7 +309,7 @@ undefined.
|
|||
At this time SWIG does not support custom accessor methods.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_3"></a>31.2.3 Functions</H3>
|
||||
<H3><a name="Php_nn2_3"></a>32.2.3 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -405,7 +362,7 @@ print $s; # The value of $s was not changed.
|
|||
-->
|
||||
|
||||
|
||||
<H3><a name="Php_nn2_4"></a>31.2.4 Overloading</H3>
|
||||
<H3><a name="Php_nn2_4"></a>32.2.4 Overloading</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -461,7 +418,7 @@ taking the integer argument.
|
|||
</p>
|
||||
-->
|
||||
|
||||
<H3><a name="Php_nn2_5"></a>31.2.5 Pointers and References</H3>
|
||||
<H3><a name="Php_nn2_5"></a>32.2.5 Pointers and References</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -593,13 +550,15 @@ PHP in a number of ways: by using <tt>unset</tt> on an existing
|
|||
variable, or assigning <tt>NULL</tt> to a variable.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn2_6"></a>31.2.6 Structures and C++ classes</H3>
|
||||
<H3><a name="Php_nn2_6"></a>32.2.6 Structures and C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG defaults to wrapping C++ structs and classes with PHP classes
|
||||
unless "-noproxy" is specified. For PHP5, a PHP wrapper
|
||||
class is generated which calls a set of flat functions wrapping the C++ class.
|
||||
SWIG defaults to wrapping C++ structs and classes with PHP classes - this
|
||||
is done by generating a PHP wrapper script which defines proxy classes
|
||||
which calls a set of flat functions which actually wrap the C++ class.
|
||||
You can disable this wrapper layer by passing the command-line option
|
||||
"-noproxy" in which case you'll just get the flat functions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -652,7 +611,7 @@ Would be used in the following way from PHP5:
|
|||
Member variables and methods are accessed using the <tt>-></tt> operator.
|
||||
</p>
|
||||
|
||||
<H4><a name="Php_nn2_6_1"></a>31.2.6.1 Using <tt>-noproxy</tt></H4>
|
||||
<H4><a name="Php_nn2_6_1"></a>32.2.6.1 Using <tt>-noproxy</tt></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -678,7 +637,7 @@ Complex_im_set($obj,$d);
|
|||
Complex_im_get($obj);
|
||||
</pre></div>
|
||||
|
||||
<H4><a name="Php_nn2_6_2"></a>31.2.6.2 Constructors and Destructors</H4>
|
||||
<H4><a name="Php_nn2_6_2"></a>32.2.6.2 Constructors and Destructors</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -719,7 +678,7 @@ the programmer can either reassign the variable or call
|
|||
<tt>unset($v)</tt>
|
||||
</p>
|
||||
|
||||
<H4><a name="Php_nn2_6_3"></a>31.2.6.3 Static Member Variables</H4>
|
||||
<H4><a name="Php_nn2_6_3"></a>32.2.6.3 Static Member Variables</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -762,7 +721,7 @@ Ko::threats(10);
|
|||
echo "There has now been " . Ko::threats() . " threats\n";
|
||||
|
||||
</pre></div>
|
||||
<H4><a name="Php_nn2_6_4"></a>31.2.6.4 Static Member Functions</H4>
|
||||
<H4><a name="Php_nn2_6_4"></a>32.2.6.4 Static Member Functions</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -784,7 +743,7 @@ Ko::threats();
|
|||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Php_nn2_7"></a>31.2.7 PHP Pragmas, Startup and Shutdown code</H3>
|
||||
<H3><a name="Php_nn2_7"></a>32.2.7 PHP Pragmas, Startup and Shutdown code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -872,7 +831,7 @@ The <tt>%rinit</tt> and <tt>%rshutdown</tt> statements are very similar but inse
|
|||
into the request init (PHP_RINIT_FUNCTION) and request shutdown (PHP_RSHUTDOWN_FUNCTION) code respectively.
|
||||
</p>
|
||||
|
||||
<H2><a name="Php_nn3"></a>31.3 Cross language polymorphism</H2>
|
||||
<H2><a name="Php_nn3"></a>32.3 Cross language polymorphism</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -907,7 +866,7 @@ wrapper functions takes care of all the cross-language method routing
|
|||
transparently.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_1"></a>31.3.1 Enabling directors</H3>
|
||||
<H3><a name="Php_nn3_1"></a>32.3.1 Enabling directors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -999,7 +958,7 @@ class MyFoo extends Foo {
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Php_nn3_2"></a>31.3.2 Director classes</H3>
|
||||
<H3><a name="Php_nn3_2"></a>32.3.2 Director classes</H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -1079,7 +1038,7 @@ so there is no need for the extra overhead involved with routing the
|
|||
calls through PHP.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_3"></a>31.3.3 Ownership and object destruction</H3>
|
||||
<H3><a name="Php_nn3_3"></a>32.3.3 Ownership and object destruction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1135,7 +1094,7 @@ In this example, we are assuming that FooContainer will take care of
|
|||
deleting all the Foo pointers it contains at some point.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_4"></a>31.3.4 Exception unrolling</H3>
|
||||
<H3><a name="Php_nn3_4"></a>32.3.4 Exception unrolling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1194,7 +1153,7 @@ Swig::DirectorMethodException is thrown, PHP will register the exception
|
|||
as soon as the C wrapper function returns.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_5"></a>31.3.5 Overhead and code bloat</H3>
|
||||
<H3><a name="Php_nn3_5"></a>32.3.5 Overhead and code bloat</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1227,7 +1186,7 @@ optimized by selectively enabling director methods (using the %feature
|
|||
directive) for only those methods that are likely to be extended in PHP.
|
||||
</p>
|
||||
|
||||
<H3><a name="Php_nn3_6"></a>31.3.6 Typemaps</H3>
|
||||
<H3><a name="Php_nn3_6"></a>32.3.6 Typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1241,7 +1200,7 @@ need to be supported.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Php_nn3_7"></a>31.3.7 Miscellaneous</H3>
|
||||
<H3><a name="Php_nn3_7"></a>32.3.7 Miscellaneous</H3>
|
||||
|
||||
|
||||
<p> Director typemaps for STL classes are mostly in place, and hence you
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Pike"></a>32 SWIG and Pike</H1>
|
||||
<H1><a name="Pike"></a>33 SWIG and Pike</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -46,10 +46,10 @@ least, make sure you read the "<a href="SWIG.html#SWIG">SWIG Basics</a>"
|
|||
chapter.<br>
|
||||
</p>
|
||||
|
||||
<H2><a name="Pike_nn2"></a>32.1 Preliminaries</H2>
|
||||
<H2><a name="Pike_nn2"></a>33.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<H3><a name="Pike_nn3"></a>32.1.1 Running SWIG</H3>
|
||||
<H3><a name="Pike_nn3"></a>33.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -94,7 +94,7 @@ can use the <tt>-o</tt> option:
|
|||
<div class="code">
|
||||
<pre>$ <b>swig -pike -o pseudonym.c example.i</b><br></pre>
|
||||
</div>
|
||||
<H3><a name="Pike_nn4"></a>32.1.2 Getting the right header files</H3>
|
||||
<H3><a name="Pike_nn4"></a>33.1.2 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -114,7 +114,7 @@ You're looking for files with the names <tt>global.h</tt>, <tt>program.h</tt>
|
|||
and so on.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn5"></a>32.1.3 Using your module</H3>
|
||||
<H3><a name="Pike_nn5"></a>33.1.3 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -129,10 +129,10 @@ Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
|
|||
(1) Result: 24
|
||||
</pre></div>
|
||||
|
||||
<H2><a name="Pike_nn6"></a>32.2 Basic C/C++ Mapping</H2>
|
||||
<H2><a name="Pike_nn6"></a>33.2 Basic C/C++ Mapping</H2>
|
||||
|
||||
|
||||
<H3><a name="Pike_nn7"></a>32.2.1 Modules</H3>
|
||||
<H3><a name="Pike_nn7"></a>33.2.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -143,7 +143,7 @@ concerned), SWIG's <tt>%module</tt> directive doesn't really have any
|
|||
significance.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn8"></a>32.2.2 Functions</H3>
|
||||
<H3><a name="Pike_nn8"></a>33.2.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -168,7 +168,7 @@ exactly as you'd expect it to:
|
|||
(1) Result: 24
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Pike_nn9"></a>32.2.3 Global variables</H3>
|
||||
<H3><a name="Pike_nn9"></a>33.2.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -197,7 +197,7 @@ will result in two functions, <tt>Foo_get()</tt> and <tt>Foo_set()</tt>:
|
|||
(3) Result: 3.141590
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Pike_nn10"></a>32.2.4 Constants and enumerated types</H3>
|
||||
<H3><a name="Pike_nn10"></a>33.2.4 Constants and enumerated types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -205,7 +205,7 @@ Enumerated types in C/C++ declarations are wrapped as Pike constants,
|
|||
not as Pike enums.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn11"></a>32.2.5 Constructors and Destructors</H3>
|
||||
<H3><a name="Pike_nn11"></a>33.2.5 Constructors and Destructors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -213,7 +213,7 @@ Constructors are wrapped as <tt>create()</tt> methods, and destructors are
|
|||
wrapped as <tt>destroy()</tt> methods, for Pike classes.
|
||||
</p>
|
||||
|
||||
<H3><a name="Pike_nn12"></a>32.2.6 Static Members</H3>
|
||||
<H3><a name="Pike_nn12"></a>33.2.6 Static Members</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Python"></a>33 SWIG and Python</H1>
|
||||
<H1><a name="Python"></a>34 SWIG and Python</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -38,7 +38,7 @@
|
|||
<li><a href="#Python_nn25">C++ namespaces</a>
|
||||
<li><a href="#Python_nn26">C++ templates</a>
|
||||
<li><a href="#Python_nn27">C++ Smart Pointers</a>
|
||||
<li><a href="#Python_nn27a">C++ Reference Counted Objects (ref/unref)</a>
|
||||
<li><a href="#Python_nn27a">C++ reference counted objects</a>
|
||||
</ul>
|
||||
<li><a href="#Python_nn28">Further details on the Python class interface</a>
|
||||
<ul>
|
||||
|
|
@ -98,6 +98,8 @@
|
|||
<ul>
|
||||
<li><a href="#Python_nn68">%feature("autodoc", "0")</a>
|
||||
<li><a href="#Python_nn69">%feature("autodoc", "1")</a>
|
||||
<li><a href="#Python_autodoc2">%feature("autodoc", "2")</a>
|
||||
<li><a href="#Python_autodoc3">%feature("autodoc", "3")</a>
|
||||
<li><a href="#Python_nn70">%feature("autodoc", "docstring")</a>
|
||||
</ul>
|
||||
<li><a href="#Python_nn71">%feature("docstring")</a>
|
||||
|
|
@ -133,7 +135,7 @@ very least, make sure you read the "<a href="SWIG.html#SWIG">SWIG
|
|||
Basics</a>" chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn2"></a>33.1 Overview</H2>
|
||||
<H2><a name="Python_nn2"></a>34.1 Overview</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -160,10 +162,10 @@ described followed by a discussion of low-level implementation
|
|||
details.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn3"></a>33.2 Preliminaries</H2>
|
||||
<H2><a name="Python_nn3"></a>34.2 Preliminaries</H2>
|
||||
|
||||
|
||||
<H3><a name="Python_nn4"></a>33.2.1 Running SWIG</H3>
|
||||
<H3><a name="Python_nn4"></a>34.2.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -261,7 +263,7 @@ The following sections have further practical examples and details on
|
|||
how you might go about compiling and using the generated files.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn6"></a>33.2.2 Using distutils</H3>
|
||||
<H3><a name="Python_nn6"></a>34.2.2 Using distutils</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -353,7 +355,7 @@ This same approach works on all platforms if the appropriate compiler is install
|
|||
can even build extensions to the standard Windows Python using MingGW)
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn7"></a>33.2.3 Hand compiling a dynamic module</H3>
|
||||
<H3><a name="Python_nn7"></a>34.2.3 Hand compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -401,7 +403,7 @@ module actually consists of two files; <tt>socket.py</tt> and
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn8"></a>33.2.4 Static linking</H3>
|
||||
<H3><a name="Python_nn8"></a>34.2.4 Static linking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -480,7 +482,7 @@ If using static linking, you might want to rely on a different approach
|
|||
(perhaps using distutils).
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn9"></a>33.2.5 Using your module</H3>
|
||||
<H3><a name="Python_nn9"></a>34.2.5 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -637,7 +639,7 @@ system configuration (this requires root access and you will need to
|
|||
read the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn10"></a>33.2.6 Compilation of C++ extensions</H3>
|
||||
<H3><a name="Python_nn10"></a>34.2.6 Compilation of C++ extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -729,7 +731,7 @@ erratic program behavior. If working with lots of software components, you
|
|||
might want to investigate using a more formal standard such as COM.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn11"></a>33.2.7 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Python_nn11"></a>34.2.7 Compiling for 64-bit platforms</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -766,7 +768,7 @@ and -m64 allow you to choose the desired binary format for your python
|
|||
extension.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn12"></a>33.2.8 Building Python Extensions under Windows</H3>
|
||||
<H3><a name="Python_nn12"></a>34.2.8 Building Python Extensions under Windows</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -875,7 +877,7 @@ SWIG Wiki</a>.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn13"></a>33.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Python_nn13"></a>34.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -884,7 +886,7 @@ to your C/C++ code. Functions are wrapped as functions, classes are wrapped as
|
|||
This section briefly covers the essential aspects of this wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn14"></a>33.3.1 Modules</H3>
|
||||
<H3><a name="Python_nn14"></a>34.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -897,7 +899,7 @@ module name, make sure you don't use the same name as a built-in
|
|||
Python command or standard module name.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn15"></a>33.3.2 Functions</H3>
|
||||
<H3><a name="Python_nn15"></a>34.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -921,7 +923,7 @@ like you think it does:
|
|||
>>>
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Python_nn16"></a>33.3.3 Global variables</H3>
|
||||
<H3><a name="Python_nn16"></a>34.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1059,7 +1061,7 @@ that starts with a leading underscore. SWIG does not create <tt>cvar</tt>
|
|||
if there are no global variables in a module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn17"></a>33.3.4 Constants and enums</H3>
|
||||
<H3><a name="Python_nn17"></a>34.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1099,7 +1101,7 @@ other object. Unfortunately, there is no easy way for SWIG to
|
|||
generate code that prevents this. You will just have to be careful.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn18"></a>33.3.5 Pointers</H3>
|
||||
<H3><a name="Python_nn18"></a>34.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1240,7 +1242,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
|
|||
<tt>None</tt> if the conversion can't be performed.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn19"></a>33.3.6 Structures</H3>
|
||||
<H3><a name="Python_nn19"></a>34.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1429,7 +1431,7 @@ everything works just like you would expect. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn20"></a>33.3.7 C++ classes</H3>
|
||||
<H3><a name="Python_nn20"></a>34.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1518,7 +1520,7 @@ they are accessed through <tt>cvar</tt> like this:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn21"></a>33.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Python_nn21"></a>34.3.8 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1573,7 +1575,7 @@ then the function <tt>spam()</tt> accepts <tt>Foo *</tt> or a pointer to any cla
|
|||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn22"></a>33.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Python_nn22"></a>34.3.9 Pointers, references, values, and arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1634,7 +1636,7 @@ treated as a returning value, and it will follow the same
|
|||
allocation/deallocation process.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn23"></a>33.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Python_nn23"></a>34.3.10 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1757,7 +1759,7 @@ first declaration takes precedence.
|
|||
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn24"></a>33.3.11 C++ operators</H3>
|
||||
<H3><a name="Python_nn24"></a>34.3.11 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1846,7 +1848,7 @@ Also, be aware that certain operators don't map cleanly to Python. For instance
|
|||
overloaded assignment operators don't map to Python semantics and will be ignored.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn25"></a>33.3.12 C++ namespaces</H3>
|
||||
<H3><a name="Python_nn25"></a>34.3.12 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1913,7 +1915,7 @@ utilizes thousands of small deeply nested namespaces each with
|
|||
identical symbol names, well, then you get what you deserve.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn26"></a>33.3.13 C++ templates</H3>
|
||||
<H3><a name="Python_nn26"></a>34.3.13 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1967,7 +1969,7 @@ Some more complicated
|
|||
examples will appear later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn27"></a>33.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Python_nn27"></a>34.3.14 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2051,151 +2053,16 @@ simply use the <tt>__deref__()</tt> method. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn27a"></a>33.3.15 C++ Reference Counted Objects (ref/unref)</H3>
|
||||
<H3><a name="Python_nn27a"></a>34.3.15 C++ reference counted objects</H3>
|
||||
|
||||
|
||||
<p>
|
||||
Another usual idiom in C++ is the use of reference counted
|
||||
objects. Consider for example:
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
class RCObj {
|
||||
// implement the ref counting mechanism
|
||||
int add_ref();
|
||||
int del_ref();
|
||||
int ref_count();
|
||||
|
||||
public:
|
||||
virtual ~RCObj() = 0;
|
||||
|
||||
int ref() const {
|
||||
return add_ref();
|
||||
}
|
||||
|
||||
int unref() const {
|
||||
if (ref_count() == 0 || del_ref() == 0 ) {
|
||||
delete this;
|
||||
return 0;
|
||||
}
|
||||
return ref_count();
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
class A : RCObj {
|
||||
public:
|
||||
A();
|
||||
int foo();
|
||||
};
|
||||
|
||||
|
||||
class B {
|
||||
A *_a;
|
||||
|
||||
public:
|
||||
B(A *a) : _a(a) {
|
||||
a->ref();
|
||||
}
|
||||
|
||||
~B() {
|
||||
a->unref();
|
||||
}
|
||||
};
|
||||
|
||||
int main() {
|
||||
A *a = new A();
|
||||
a->ref(); // 'a' is ref here
|
||||
|
||||
B *b1 = new B(a); // 'a' is ref here
|
||||
if (1 + 1 == 2) {
|
||||
B *b2 = new B(a); // 'a' is ref here
|
||||
delete b2; // 'a' is unref, but not deleted
|
||||
}
|
||||
|
||||
delete b1; // 'a' is unref, but not deleted
|
||||
a->unref(); // 'a' is unref and deleted
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In the example above, the 'A' class instance 'a' is a reference counted
|
||||
object, which can't be deleted arbitrarily since it is shared between
|
||||
the objects 'b1' and 'b2'. 'A' is derived from an Reference Counted
|
||||
Object 'RCObj', which implements the ref/unref idiom.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To tell SWIG that 'RCObj' and all its derived classes are reference
|
||||
counted objects, you use the "ref" and "unref" features.
|
||||
For example:
|
||||
The <a href="SWIGPlus.html#SWIGPlus_ref_unref">C++ reference counted objects</a> section contains
|
||||
Python examples of memory management using referencing counting.
|
||||
</p>
|
||||
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%module example
|
||||
...
|
||||
|
||||
%feature("ref") RCObj "$this->ref();"
|
||||
%feature("unref") RCObj "$this->unref();"
|
||||
|
||||
%include "rcobj.h"
|
||||
%include "A.h"
|
||||
...
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
where the code passed to the "ref" and "unref" features will be
|
||||
executed as needed whenever a new object is passed to python, or when
|
||||
python tries to release the shadow object instance, respectively.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the python side, the use of a reference counted object is not
|
||||
different than any other regular instance:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
def create_A():
|
||||
a = A() # SWIG ref 'a' (new object is passed to python)
|
||||
b1 = B(a) # C++ ref 'a'
|
||||
if 1 + 1 == 2:
|
||||
b2 = B(a) # C++ ref 'a'
|
||||
return a # 'b1' and 'b2' are released, C++ unref 'a' twice
|
||||
|
||||
a = create_A()
|
||||
exit # 'a' is released, SWIG unref 'a'
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Note that the user doesn't explicitly need to call 'a->ref()' nor 'a->unref()'
|
||||
(as neither 'delete a'). Instead, SWIG take cares of executing the "ref"
|
||||
and "unref" codes as needed. If the user doesn't specify the
|
||||
"ref/unref" features, SWIG will produce a code equivalent to define
|
||||
them as:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%feature("ref") ""
|
||||
%feature("unref") "delete $this;"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In other words, SWIG will not do anything special when a new object
|
||||
is passed to python, and it will always 'delete' the object when
|
||||
python releases the proxy instance.
|
||||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn28"></a>33.4 Further details on the Python class interface</H2>
|
||||
<H2><a name="Python_nn28"></a>34.4 Further details on the Python class interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2218,7 +2085,7 @@ the <tt>-builtin</tt> option are in the <a href="#Python_builtin_types">Built-in
|
|||
section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn29"></a>33.4.1 Proxy classes</H3>
|
||||
<H3><a name="Python_nn29"></a>34.4.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2307,7 +2174,7 @@ you can attach new Python methods to the class and you can even inherit from it
|
|||
by Python built-in types until Python 2.2).
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_builtin_types"></a>33.4.2 Built-in Types</H3>
|
||||
<H3><a name="Python_builtin_types"></a>34.4.2 Built-in Types</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2351,7 +2218,7 @@ please refer to the python documentation:</p>
|
|||
|
||||
<p><a href="http://docs.python.org/extending/newtypes.html">http://docs.python.org/extending/newtypes.html</a></p>
|
||||
|
||||
<H4><a name="Python_builtin_limitations"></a>33.4.2.1 Limitations</H4>
|
||||
<H4><a name="Python_builtin_limitations"></a>34.4.2.1 Limitations</H4>
|
||||
|
||||
|
||||
<p>Use of the <tt>-builtin</tt> option implies a couple of limitations:
|
||||
|
|
@ -2519,7 +2386,7 @@ assert(issubclass(B.Derived, A.Base))
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H4><a name="Python_builtin_overloads"></a>33.4.2.2 Operator overloads -- use them!</H4>
|
||||
<H4><a name="Python_builtin_overloads"></a>34.4.2.2 Operator overloads -- use them!</H4>
|
||||
|
||||
|
||||
<p>The entire justification for the <tt>-builtin</tt> option is improved
|
||||
|
|
@ -2620,7 +2487,7 @@ structs.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn30"></a>33.4.3 Memory management</H3>
|
||||
<H3><a name="Python_nn30"></a>34.4.3 Memory management</H3>
|
||||
|
||||
|
||||
<p>NOTE: Although this section refers to proxy objects, everything here also applies
|
||||
|
|
@ -2815,7 +2682,7 @@ It is also possible to deal with situations like this using
|
|||
typemaps--an advanced topic discussed later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn31"></a>33.4.4 Python 2.2 and classic classes</H3>
|
||||
<H3><a name="Python_nn31"></a>34.4.4 Python 2.2 and classic classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2852,7 +2719,7 @@ class itself. In Python-2.1 and earlier, they have to be accessed as a global
|
|||
function or through an instance (see the earlier section).
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_directors"></a>33.5 Cross language polymorphism</H2>
|
||||
<H2><a name="Python_directors"></a>34.5 Cross language polymorphism</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2886,7 +2753,7 @@ proxy classes, director classes, and C wrapper functions takes care of
|
|||
all the cross-language method routing transparently.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn33"></a>33.5.1 Enabling directors</H3>
|
||||
<H3><a name="Python_nn33"></a>34.5.1 Enabling directors</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2979,7 +2846,7 @@ class MyFoo(mymodule.Foo):
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn34"></a>33.5.2 Director classes</H3>
|
||||
<H3><a name="Python_nn34"></a>34.5.2 Director classes</H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -3061,7 +2928,7 @@ so there is no need for the extra overhead involved with routing the
|
|||
calls through Python.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn35"></a>33.5.3 Ownership and object destruction</H3>
|
||||
<H3><a name="Python_nn35"></a>34.5.3 Ownership and object destruction</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3128,7 +2995,7 @@ deleting all the Foo pointers it contains at some point. Note that no hard
|
|||
references to the Foo objects remain in Python.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn36"></a>33.5.4 Exception unrolling</H3>
|
||||
<H3><a name="Python_nn36"></a>34.5.4 Exception unrolling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3187,7 +3054,7 @@ Swig::DirectorMethodException is thrown, Python will register the
|
|||
exception as soon as the C wrapper function returns.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn37"></a>33.5.5 Overhead and code bloat</H3>
|
||||
<H3><a name="Python_nn37"></a>34.5.5 Overhead and code bloat</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3221,7 +3088,7 @@ directive) for only those methods that are likely to be extended in
|
|||
Python.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn38"></a>33.5.6 Typemaps</H3>
|
||||
<H3><a name="Python_nn38"></a>34.5.6 Typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3235,7 +3102,7 @@ need to be supported.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn39"></a>33.5.7 Miscellaneous</H3>
|
||||
<H3><a name="Python_nn39"></a>34.5.7 Miscellaneous</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3282,7 +3149,7 @@ methods that return const references.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn40"></a>33.6 Common customization features</H2>
|
||||
<H2><a name="Python_nn40"></a>34.6 Common customization features</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3295,7 +3162,7 @@ This section describes some common SWIG features that are used to
|
|||
improve your the interface to an extension module.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn41"></a>33.6.1 C/C++ helper functions</H3>
|
||||
<H3><a name="Python_nn41"></a>34.6.1 C/C++ helper functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3376,7 +3243,7 @@ hard to implement. It is possible to clean this up using Python code, typemaps,
|
|||
customization features as covered in later sections.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn42"></a>33.6.2 Adding additional Python code</H3>
|
||||
<H3><a name="Python_nn42"></a>34.6.2 Adding additional Python code</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3525,7 +3392,7 @@ public:
|
|||
|
||||
|
||||
|
||||
<H3><a name="Python_nn43"></a>33.6.3 Class extension with %extend</H3>
|
||||
<H3><a name="Python_nn43"></a>34.6.3 Class extension with %extend</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3614,7 +3481,7 @@ Vector(12,14,16)
|
|||
in any way---the extensions only show up in the Python interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn44"></a>33.6.4 Exception handling with %exception</H3>
|
||||
<H3><a name="Python_nn44"></a>34.6.4 Exception handling with %exception</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3740,7 +3607,7 @@ The language-independent <tt>exception.i</tt> library file can also be used
|
|||
to raise exceptions. See the <a href="Library.html#Library">SWIG Library</a> chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn45"></a>33.7 Tips and techniques</H2>
|
||||
<H2><a name="Python_nn45"></a>34.7 Tips and techniques</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3750,7 +3617,7 @@ strings, binary data, and arrays. This chapter discusses the common techniques
|
|||
solving these problems.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn46"></a>33.7.1 Input and output parameters</H3>
|
||||
<H3><a name="Python_nn46"></a>34.7.1 Input and output parameters</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3963,7 +3830,7 @@ void foo(Bar *OUTPUT);
|
|||
may not have the intended effect since <tt>typemaps.i</tt> does not define an OUTPUT rule for <tt>Bar</tt>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn47"></a>33.7.2 Simple pointers</H3>
|
||||
<H3><a name="Python_nn47"></a>34.7.2 Simple pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4032,7 +3899,7 @@ If you replace <tt>%pointer_functions()</tt> by <tt>%pointer_class(type,name)</t
|
|||
See the <a href="Library.html#Library">SWIG Library</a> chapter for further details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn48"></a>33.7.3 Unbounded C Arrays</H3>
|
||||
<H3><a name="Python_nn48"></a>34.7.3 Unbounded C Arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4094,7 +3961,7 @@ well suited for applications in which you need to create buffers,
|
|||
package binary data, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn49"></a>33.7.4 String handling</H3>
|
||||
<H3><a name="Python_nn49"></a>34.7.4 String handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4163,7 +4030,7 @@ If you need to return binary data, you might use the
|
|||
also be used to extra binary data from arbitrary pointers.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn53"></a>33.8 Typemaps</H2>
|
||||
<H2><a name="Python_nn53"></a>34.8 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4180,7 +4047,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Python interface or if you want to elevate your guru status.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn54"></a>33.8.1 What is a typemap?</H3>
|
||||
<H3><a name="Python_nn54"></a>34.8.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4296,7 +4163,7 @@ parameter is omitted):
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn55"></a>33.8.2 Python typemaps</H3>
|
||||
<H3><a name="Python_nn55"></a>34.8.2 Python typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4337,7 +4204,7 @@ a look at the SWIG library version 1.3.20 or so.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn56"></a>33.8.3 Typemap variables</H3>
|
||||
<H3><a name="Python_nn56"></a>34.8.3 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4408,7 +4275,7 @@ properly assigned.
|
|||
The Python name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn57"></a>33.8.4 Useful Python Functions</H3>
|
||||
<H3><a name="Python_nn57"></a>34.8.4 Useful Python Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4536,7 +4403,7 @@ write me
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Python_nn58"></a>33.9 Typemap Examples</H2>
|
||||
<H2><a name="Python_nn58"></a>34.9 Typemap Examples</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4545,7 +4412,7 @@ might look at the files "<tt>python.swg</tt>" and "<tt>typemaps.i</tt>" in
|
|||
the SWIG library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn59"></a>33.9.1 Converting Python list to a char ** </H3>
|
||||
<H3><a name="Python_nn59"></a>34.9.1 Converting Python list to a char ** </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4625,7 +4492,7 @@ memory allocation is used to allocate memory for the array, the
|
|||
the C function.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn60"></a>33.9.2 Expanding a Python object into multiple arguments</H3>
|
||||
<H3><a name="Python_nn60"></a>34.9.2 Expanding a Python object into multiple arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4704,7 +4571,7 @@ to supply the argument count. This is automatically set by the typemap code. F
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn61"></a>33.9.3 Using typemaps to return arguments</H3>
|
||||
<H3><a name="Python_nn61"></a>34.9.3 Using typemaps to return arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4793,7 +4660,7 @@ function can now be used as follows:
|
|||
>>>
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Python_nn62"></a>33.9.4 Mapping Python tuples into small arrays</H3>
|
||||
<H3><a name="Python_nn62"></a>34.9.4 Mapping Python tuples into small arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4842,7 +4709,7 @@ array, such an approach would not be recommended for huge arrays, but
|
|||
for small structures, this approach works fine.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn63"></a>33.9.5 Mapping sequences to C arrays</H3>
|
||||
<H3><a name="Python_nn63"></a>34.9.5 Mapping sequences to C arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4931,7 +4798,7 @@ static int convert_darray(PyObject *input, double *ptr, int size) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn64"></a>33.9.6 Pointer handling</H3>
|
||||
<H3><a name="Python_nn64"></a>34.9.6 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5028,7 +4895,7 @@ class object (if applicable).
|
|||
|
||||
|
||||
|
||||
<H2><a name="Python_nn65"></a>33.10 Docstring Features</H2>
|
||||
<H2><a name="Python_nn65"></a>34.10 Docstring Features</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5056,7 +4923,7 @@ of your users much simpler.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn66"></a>33.10.1 Module docstring</H3>
|
||||
<H3><a name="Python_nn66"></a>34.10.1 Module docstring</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5090,7 +4957,7 @@ layout of controls on a panel, etc. to be loaded from an XML file."
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn67"></a>33.10.2 %feature("autodoc")</H3>
|
||||
<H3><a name="Python_nn67"></a>34.10.2 %feature("autodoc")</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5114,14 +4981,15 @@ introspection, then life is good once more.
|
|||
which when attached to a node in the parse tree will cause a docstring
|
||||
to be generated that includes the name of the function, parameter
|
||||
names, default values if any, and return type if any. There are also
|
||||
three options for autodoc controlled by the value given to the
|
||||
feature, described below.
|
||||
four levels for autodoc controlled by the value given to the
|
||||
feature, <tt>%feature("autodoc", "<i>level</i>")</tt>.
|
||||
The four values for <i>level</i> are covered in the following sub-sections.
|
||||
|
||||
<H4><a name="Python_nn68"></a>33.10.2.1 %feature("autodoc", "0")</H4>
|
||||
<H4><a name="Python_nn68"></a>34.10.2.1 %feature("autodoc", "0")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
When the "0" option is given then the types of the parameters will
|
||||
When level "0" is used then the types of the parameters will
|
||||
<em>not</em> be included in the autodoc string. For example, given
|
||||
this function prototype:
|
||||
</p>
|
||||
|
|
@ -5146,18 +5014,19 @@ def function_name(*args, **kwargs):
|
|||
</div>
|
||||
|
||||
|
||||
<H4><a name="Python_nn69"></a>33.10.2.2 %feature("autodoc", "1")</H4>
|
||||
<H4><a name="Python_nn69"></a>34.10.2.2 %feature("autodoc", "1")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
When the "1" option is used then the parameter types <em>will</em> be
|
||||
When level "1" is used then the parameter types <em>will</em> be
|
||||
used in the autodoc string. In addition, an attempt is made to
|
||||
simplify the type name such that it makes more sense to the Python
|
||||
user. Pointer, reference and const info is removed,
|
||||
<tt>%rename</tt>'s are evaluated, etc. (This is not always
|
||||
successful, but works most of the time. See the next section for what
|
||||
to do when it doesn't.) Given the example above, then turning on the
|
||||
parameter types with the "1" option will result in Python code like
|
||||
user. Pointer, reference and const info is removed if the associated type
|
||||
is has an associated Python type (<tt>%rename</tt>'s are thus shown correctly).
|
||||
This works most of the time, otherwise a C/C++ type will be used.
|
||||
See the next section for the "docstring" feature for tweaking the docstrings to your liking.
|
||||
Given the example above, then turning on the
|
||||
parameter types with level "1" will result in Python code like
|
||||
this:
|
||||
</p>
|
||||
|
||||
|
|
@ -5170,8 +5039,92 @@ def function_name(*args, **kwargs):
|
|||
</div>
|
||||
|
||||
|
||||
<H4><a name="Python_autodoc2"></a>34.10.2.3 %feature("autodoc", "2")</H4>
|
||||
|
||||
<H4><a name="Python_nn70"></a>33.10.2.3 %feature("autodoc", "docstring")</H4>
|
||||
|
||||
<p>
|
||||
Level "2" results in the function prototype as per level "0". In addition, a line of
|
||||
documentation is generated for each parameter. Using the previous example, the generated
|
||||
code will be:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
def function_name(*args, **kwargs):
|
||||
"""
|
||||
function_name(x, y, foo=None, bar=None) -> bool
|
||||
|
||||
Parameters:
|
||||
x: int
|
||||
y: int
|
||||
foo: Foo *
|
||||
bar: Bar *
|
||||
|
||||
"""
|
||||
...
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Note that the documentation for each parameter is sourced from the "doc" typemap which by default shows the
|
||||
C/C++ type rather than the simplified Python type name described earlier for level "1".
|
||||
Typemaps can of course change the output for any particular type, for example the <tt>int x</tt> parameter:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%feature("autodoc", "2");
|
||||
%typemap("doc") int x "$1_name (C++ type: $1_type) -- Input $1_name dimension"
|
||||
bool function_name(int x, int y, Foo* foo=NULL, Bar* bar=NULL);
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
resulting in
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
def function_name(*args, **kwargs):
|
||||
"""
|
||||
function_name(x, y, foo=None, bar=None) -> bool
|
||||
|
||||
Parameters:
|
||||
x (C++ type: int) -- Input x dimension
|
||||
y: int
|
||||
foo: Foo *
|
||||
bar: Bar *
|
||||
|
||||
"""
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Python_autodoc3"></a>34.10.2.4 %feature("autodoc", "3")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
Level "3" results in the function prototype as per level "1" but also contains the same additional line of documentation for each parameter as per level "2". Using our earlier example again, the generated code will be:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
def function_name(*args, **kwargs):
|
||||
"""
|
||||
function_name(int x, int y, Foo foo=None, Bar bar=None) -> bool
|
||||
|
||||
Parameters:
|
||||
x: int
|
||||
y: int
|
||||
foo: Foo *
|
||||
bar: Bar *
|
||||
|
||||
"""
|
||||
...
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<H4><a name="Python_nn70"></a>34.10.2.5 %feature("autodoc", "docstring")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5190,7 +5143,7 @@ void GetPosition(int* OUTPUT, int* OUTPUT);
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn71"></a>33.10.3 %feature("docstring")</H3>
|
||||
<H3><a name="Python_nn71"></a>34.10.3 %feature("docstring")</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5222,7 +5175,7 @@ with more than one line.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Python_nn72"></a>33.11 Python Packages</H2>
|
||||
<H2><a name="Python_nn72"></a>34.11 Python Packages</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5249,7 +5202,7 @@ and also in base class declarations, etc. if the package name is
|
|||
different than its own.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_python3support"></a>33.12 Python 3 Support</H2>
|
||||
<H2><a name="Python_python3support"></a>34.12 Python 3 Support</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5276,7 +5229,7 @@ The following are Python 3.0 new features that are currently supported by
|
|||
SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn74"></a>33.12.1 Function annotation</H3>
|
||||
<H3><a name="Python_nn74"></a>34.12.1 Function annotation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5285,7 +5238,7 @@ SWIG is able to generate proxy method definitions like this:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
def foo(self, bar : "int" = 0) -> "void" : ...
|
||||
def foo(self, bar : "int"=0) -> "void" : ...
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -5294,7 +5247,7 @@ still could be generated:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
def foo(self, bar = 0): ...
|
||||
def foo(self, bar=0): ...
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -5309,7 +5262,7 @@ For detailed usage of function annotation, see
|
|||
<a href="http://www.python.org/dev/peps/pep-3107/">PEP 3107</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn75"></a>33.12.2 Buffer interface</H3>
|
||||
<H3><a name="Python_nn75"></a>34.12.2 Buffer interface</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5461,7 +5414,7 @@ modify the buffer.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn76"></a>33.12.3 Abstract base classes</H3>
|
||||
<H3><a name="Python_nn76"></a>34.12.3 Abstract base classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="R"></a>34 SWIG and R</H1>
|
||||
<H1><a name="R"></a>35 SWIG and R</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -33,7 +33,7 @@ compile and run an R interface to QuantLib running on Mandriva Linux
|
|||
with gcc. The R bindings also work on Microsoft Windows using Visual C++.
|
||||
</p>
|
||||
|
||||
<H2><a name="R_nn2"></a>34.1 Bugs</H2>
|
||||
<H2><a name="R_nn2"></a>35.1 Bugs</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -45,7 +45,7 @@ Currently the following features are not implemented or broken:
|
|||
<li>C Array wrappings
|
||||
</ul>
|
||||
|
||||
<H2><a name="R_nn3"></a>34.2 Using R and SWIG</H2>
|
||||
<H2><a name="R_nn3"></a>35.2 Using R and SWIG</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -119,7 +119,7 @@ Without it, inheritance of wrapped objects may fail.
|
|||
These two files can be loaded in any order
|
||||
</p>
|
||||
|
||||
<H2><a name="R_nn4"></a>34.3 Precompiling large R files</H2>
|
||||
<H2><a name="R_nn4"></a>35.3 Precompiling large R files</H2>
|
||||
|
||||
|
||||
In cases where the R file is large, one make save a lot of loading
|
||||
|
|
@ -137,7 +137,7 @@ will save a large amount of loading time.
|
|||
|
||||
|
||||
|
||||
<H2><a name="R_nn5"></a>34.4 General policy</H2>
|
||||
<H2><a name="R_nn5"></a>35.4 General policy</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -146,7 +146,7 @@ wrapping over the underlying functions and rely on the R type system
|
|||
to provide R syntax.
|
||||
</p>
|
||||
|
||||
<H2><a name="R_language_conventions"></a>34.5 Language conventions</H2>
|
||||
<H2><a name="R_language_conventions"></a>35.5 Language conventions</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -155,7 +155,7 @@ and [ are overloaded to allow for R syntax (one based indices and
|
|||
slices)
|
||||
</p>
|
||||
|
||||
<H2><a name="R_nn6"></a>34.6 C++ classes</H2>
|
||||
<H2><a name="R_nn6"></a>35.6 C++ classes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -167,7 +167,7 @@ keep track of the pointer object which removes the necessity for a lot
|
|||
of the proxy class baggage you see in other languages.
|
||||
</p>
|
||||
|
||||
<H2><a name="R_nn7"></a>34.7 Enumerations</H2>
|
||||
<H2><a name="R_nn7"></a>35.7 Enumerations</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
|
||||
<body bgcolor="#ffffff">
|
||||
|
||||
<H1><a name="Ruby"></a>35 SWIG and Ruby</H1>
|
||||
<H1><a name="Ruby"></a>36 SWIG and Ruby</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -148,7 +148,7 @@
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn2"></a>35.1 Preliminaries</H2>
|
||||
<H2><a name="Ruby_nn2"></a>36.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p> SWIG 1.3 is known to work with Ruby versions 1.6 and later.
|
||||
|
|
@ -171,7 +171,7 @@ of Ruby. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn3"></a>35.1.1 Running SWIG</H3>
|
||||
<H3><a name="Ruby_nn3"></a>36.1.1 Running SWIG</H3>
|
||||
|
||||
|
||||
<p> To build a Ruby module, run SWIG using the <tt>-ruby</tt>
|
||||
|
|
@ -225,7 +225,7 @@ to compile this file and link it with the rest of your program. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn4"></a>35.1.2 Getting the right header files</H3>
|
||||
<H3><a name="Ruby_nn4"></a>36.1.2 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p> In order to compile the wrapper code, the compiler needs the <tt>ruby.h</tt>
|
||||
|
|
@ -274,7 +274,7 @@ installed, you can run Ruby to find out. For example: </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn5"></a>35.1.3 Compiling a dynamic module</H3>
|
||||
<H3><a name="Ruby_nn5"></a>36.1.3 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p> Ruby extension modules are typically compiled into shared
|
||||
|
|
@ -428,7 +428,7 @@ manual pages for your compiler and linker to determine the correct set
|
|||
of options. You might also check the <a href="http://www.dabeaz.com/cgi-bin/wiki.pl">SWIG Wiki</a>
|
||||
for additional information. </p>
|
||||
|
||||
<H3><a name="Ruby_nn6"></a>35.1.4 Using your module</H3>
|
||||
<H3><a name="Ruby_nn6"></a>36.1.4 Using your module</H3>
|
||||
|
||||
|
||||
<p> Ruby <i>module</i> names must be capitalized,
|
||||
|
|
@ -488,7 +488,7 @@ begins with: </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn7"></a>35.1.5 Static linking</H3>
|
||||
<H3><a name="Ruby_nn7"></a>36.1.5 Static linking</H3>
|
||||
|
||||
|
||||
<p> An alternative approach to dynamic linking is to rebuild the
|
||||
|
|
@ -509,7 +509,7 @@ finally rebuilding Ruby. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn8"></a>35.1.6 Compilation of C++ extensions</H3>
|
||||
<H3><a name="Ruby_nn8"></a>36.1.6 Compilation of C++ extensions</H3>
|
||||
|
||||
|
||||
<p> On most machines, C++ extension modules should be linked
|
||||
|
|
@ -561,7 +561,7 @@ extension, e.g. </p>
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn9"></a>35.2 Building Ruby Extensions under Windows 95/NT</H2>
|
||||
<H2><a name="Ruby_nn9"></a>36.2 Building Ruby Extensions under Windows 95/NT</H2>
|
||||
|
||||
|
||||
<p> Building a SWIG extension to Ruby under Windows 95/NT is
|
||||
|
|
@ -600,7 +600,7 @@ files. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn10"></a>35.2.1 Running SWIG from Developer Studio</H3>
|
||||
<H3><a name="Ruby_nn10"></a>36.2.1 Running SWIG from Developer Studio</H3>
|
||||
|
||||
|
||||
<p> If you are developing your application within Microsoft
|
||||
|
|
@ -742,7 +742,7 @@ directory, then run the Ruby script from the DOS/Command prompt: </p>
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn11"></a>35.3 The Ruby-to-C/C++ Mapping</H2>
|
||||
<H2><a name="Ruby_nn11"></a>36.3 The Ruby-to-C/C++ Mapping</H2>
|
||||
|
||||
|
||||
<p> This section describes the basics of how SWIG maps C or C++
|
||||
|
|
@ -752,7 +752,7 @@ declarations in your SWIG interface files to Ruby constructs. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn12"></a>35.3.1 Modules</H3>
|
||||
<H3><a name="Ruby_nn12"></a>36.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p> The SWIG <tt>%module</tt> directive specifies
|
||||
|
|
@ -921,7 +921,7 @@ Ruby's built-in names. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn13"></a>35.3.2 Functions</H3>
|
||||
<H3><a name="Ruby_nn13"></a>36.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p> Global functions are wrapped as Ruby module methods. For
|
||||
|
|
@ -984,7 +984,7 @@ module that can be used like so: </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn14"></a>35.3.3 Variable Linking</H3>
|
||||
<H3><a name="Ruby_nn14"></a>36.3.3 Variable Linking</H3>
|
||||
|
||||
|
||||
<p> C/C++ global variables are wrapped as a pair of singleton
|
||||
|
|
@ -1084,7 +1084,7 @@ effect until it is explicitly disabled using <tt>%mutable</tt>.
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn15"></a>35.3.4 Constants</H3>
|
||||
<H3><a name="Ruby_nn15"></a>36.3.4 Constants</H3>
|
||||
|
||||
|
||||
<p> C/C++ constants are wrapped as module constants initialized
|
||||
|
|
@ -1128,7 +1128,7 @@ constant values, e.g. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn16"></a>35.3.5 Pointers</H3>
|
||||
<H3><a name="Ruby_nn16"></a>36.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p> "Opaque" pointers to arbitrary C/C++ types (i.e. types that
|
||||
|
|
@ -1180,7 +1180,7 @@ the Ruby <tt>nil</tt> object. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn17"></a>35.3.6 Structures</H3>
|
||||
<H3><a name="Ruby_nn17"></a>36.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p> C/C++ structs are wrapped as Ruby classes, with accessor
|
||||
|
|
@ -1355,7 +1355,7 @@ pointers. For example, </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn18"></a>35.3.7 C++ classes</H3>
|
||||
<H3><a name="Ruby_nn18"></a>36.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p> Like structs, C++ classes are wrapped by creating a new Ruby
|
||||
|
|
@ -1441,7 +1441,7 @@ class. </li>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn19"></a>35.3.8 C++ Inheritance</H3>
|
||||
<H3><a name="Ruby_nn19"></a>36.3.8 C++ Inheritance</H3>
|
||||
|
||||
|
||||
<p> The SWIG type-checker is fully aware of C++ inheritance.
|
||||
|
|
@ -1672,7 +1672,7 @@ Typing"</a>). </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn20"></a>35.3.9 C++ Overloaded Functions</H3>
|
||||
<H3><a name="Ruby_nn20"></a>36.3.9 C++ Overloaded Functions</H3>
|
||||
|
||||
|
||||
<p> C++ overloaded functions, methods, and constructors are
|
||||
|
|
@ -1872,7 +1872,7 @@ and C++"</a> chapter for more information about overloading. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn21"></a>35.3.10 C++ Operators</H3>
|
||||
<H3><a name="Ruby_nn21"></a>36.3.10 C++ Operators</H3>
|
||||
|
||||
|
||||
<p> For the most part, overloaded operators are handled
|
||||
|
|
@ -1953,7 +1953,7 @@ on operator overloading</a>. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn22"></a>35.3.11 C++ namespaces</H3>
|
||||
<H3><a name="Ruby_nn22"></a>36.3.11 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p> SWIG is aware of C++ namespaces, but namespace names do not
|
||||
|
|
@ -2029,7 +2029,7 @@ identical symbol names, well, then you get what you deserve. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn23"></a>35.3.12 C++ templates</H3>
|
||||
<H3><a name="Ruby_nn23"></a>36.3.12 C++ templates</H3>
|
||||
|
||||
|
||||
<p> C++ templates don't present a huge problem for SWIG. However,
|
||||
|
|
@ -2073,7 +2073,7 @@ directive. For example: </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn23_1"></a>35.3.13 C++ Standard Template Library (STL)</H3>
|
||||
<H3><a name="Ruby_nn23_1"></a>36.3.13 C++ Standard Template Library (STL)</H3>
|
||||
|
||||
|
||||
<p> On a related note, the standard SWIG library contains a
|
||||
|
|
@ -2326,7 +2326,7 @@ chapter.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_C_STL_Functors"></a>35.3.14 C++ STL Functors</H3>
|
||||
<H3><a name="Ruby_C_STL_Functors"></a>36.3.14 C++ STL Functors</H3>
|
||||
|
||||
|
||||
<p>Some containers in the STL allow you to modify their default
|
||||
|
|
@ -2526,7 +2526,7 @@ b<br style="font-weight: bold;">
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_C_Iterators"></a>35.3.15 C++ STL Iterators</H3>
|
||||
<H3><a name="Ruby_C_Iterators"></a>36.3.15 C++ STL Iterators</H3>
|
||||
|
||||
|
||||
<p>The STL is well known for the use of iterators. There
|
||||
|
|
@ -2737,7 +2737,7 @@ i<br>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn24"></a>35.3.16 C++ Smart Pointers</H3>
|
||||
<H3><a name="Ruby_nn24"></a>36.3.16 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p> In certain C++ programs, it is common to use classes that
|
||||
|
|
@ -2862,7 +2862,7 @@ method. For example: </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn25"></a>35.3.17 Cross-Language Polymorphism</H3>
|
||||
<H3><a name="Ruby_nn25"></a>36.3.17 Cross-Language Polymorphism</H3>
|
||||
|
||||
|
||||
<p> SWIG's Ruby module supports cross-language polymorphism
|
||||
|
|
@ -2875,7 +2875,7 @@ using this feature with Ruby. </p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn26"></a>35.3.17.1 Exception Unrolling</H4>
|
||||
<H4><a name="Ruby_nn26"></a>36.3.17.1 Exception Unrolling</H4>
|
||||
|
||||
|
||||
<p> Whenever a C++ director class routes one of its virtual
|
||||
|
|
@ -2913,7 +2913,7 @@ caught here and a C++ exception is raised in its place. </p>
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn27"></a>35.4 Naming</H2>
|
||||
<H2><a name="Ruby_nn27"></a>36.4 Naming</H2>
|
||||
|
||||
|
||||
<p>Ruby has several common naming conventions. Constants are
|
||||
|
|
@ -3009,7 +3009,7 @@ planned to become the default option in future releases.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn28"></a>35.4.1 Defining Aliases</H3>
|
||||
<H3><a name="Ruby_nn28"></a>36.4.1 Defining Aliases</H3>
|
||||
|
||||
|
||||
<p> It's a fairly common practice in the Ruby built-ins and
|
||||
|
|
@ -3101,7 +3101,7 @@ Features"</a>) for more details).</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn29"></a>35.4.2 Predicate Methods</H3>
|
||||
<H3><a name="Ruby_nn29"></a>36.4.2 Predicate Methods</H3>
|
||||
|
||||
|
||||
<p> Ruby methods that return a boolean value and end in a
|
||||
|
|
@ -3190,7 +3190,7 @@ Features"</a>) for more details). </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn30"></a>35.4.3 Bang Methods</H3>
|
||||
<H3><a name="Ruby_nn30"></a>36.4.3 Bang Methods</H3>
|
||||
|
||||
|
||||
<p> Ruby methods that modify an object in-place and end in an
|
||||
|
|
@ -3254,7 +3254,7 @@ Features"</a>) for more details). </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn31"></a>35.4.4 Getters and Setters</H3>
|
||||
<H3><a name="Ruby_nn31"></a>36.4.4 Getters and Setters</H3>
|
||||
|
||||
|
||||
<p> Often times a C++ library will expose properties through
|
||||
|
|
@ -3324,7 +3324,7 @@ methods to be exposed in Ruby as <tt>value</tt> and <tt>value=.
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn32"></a>35.5 Input and output parameters</H2>
|
||||
<H2><a name="Ruby_nn32"></a>36.5 Input and output parameters</H2>
|
||||
|
||||
|
||||
<p> A common problem in some C programs is handling parameters
|
||||
|
|
@ -3575,10 +3575,10 @@ of <tt>%apply</tt> </p>
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn33"></a>35.6 Exception handling </H2>
|
||||
<H2><a name="Ruby_nn33"></a>36.6 Exception handling </H2>
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn34"></a>35.6.1 Using the %exception directive </H3>
|
||||
<H3><a name="Ruby_nn34"></a>36.6.1 Using the %exception directive </H3>
|
||||
|
||||
|
||||
<p>The SWIG <tt>%exception</tt> directive can be
|
||||
|
|
@ -3673,7 +3673,7 @@ Features</a> for more examples.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn34_2"></a>35.6.2 Handling Ruby Blocks </H3>
|
||||
<H3><a name="Ruby_nn34_2"></a>36.6.2 Handling Ruby Blocks </H3>
|
||||
|
||||
|
||||
<p>One of the highlights of Ruby and most of its standard library
|
||||
|
|
@ -3854,7 +3854,7 @@ RUBY_YIELD_SELF );<br>
|
|||
<p>For more information on typemaps, see <a href="#Ruby_nn37">Typemaps</a>.</p>
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn35"></a>35.6.3 Raising exceptions </H3>
|
||||
<H3><a name="Ruby_nn35"></a>36.6.3 Raising exceptions </H3>
|
||||
|
||||
|
||||
<p>There are three ways to raise exceptions from C++ code to
|
||||
|
|
@ -4615,7 +4615,7 @@ the built-in Ruby exception types.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn36"></a>35.6.4 Exception classes </H3>
|
||||
<H3><a name="Ruby_nn36"></a>36.6.4 Exception classes </H3>
|
||||
|
||||
|
||||
<p>Starting with SWIG 1.3.28, the Ruby module supports the <tt>%exceptionclass</tt>
|
||||
|
|
@ -4673,7 +4673,7 @@ providing for a more natural integration between C++ code and Ruby code.</p>
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn37"></a>35.7 Typemaps</H2>
|
||||
<H2><a name="Ruby_nn37"></a>36.7 Typemaps</H2>
|
||||
|
||||
|
||||
<p> This section describes how you can modify SWIG's default
|
||||
|
|
@ -4696,7 +4696,7 @@ of the primitive C-Ruby interface.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn38"></a>35.7.1 What is a typemap?</H3>
|
||||
<H3><a name="Ruby_nn38"></a>36.7.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p> A typemap is nothing more than a code generation rule that is
|
||||
|
|
@ -4958,7 +4958,7 @@ to be used as follows (notice how the length parameter is omitted): </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_Typemap_scope"></a>35.7.2 Typemap scope</H3>
|
||||
<H3><a name="Ruby_Typemap_scope"></a>36.7.2 Typemap scope</H3>
|
||||
|
||||
|
||||
<p> Once defined, a typemap remains in effect for all of the
|
||||
|
|
@ -5006,7 +5006,7 @@ where the class itself is defined. For example:</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_Copying_a_typemap"></a>35.7.3 Copying a typemap</H3>
|
||||
<H3><a name="Ruby_Copying_a_typemap"></a>36.7.3 Copying a typemap</H3>
|
||||
|
||||
|
||||
<p> A typemap is copied by using assignment. For example:</p>
|
||||
|
|
@ -5108,7 +5108,7 @@ rules as for <tt>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_Deleting_a_typemap"></a>35.7.4 Deleting a typemap</H3>
|
||||
<H3><a name="Ruby_Deleting_a_typemap"></a>36.7.4 Deleting a typemap</H3>
|
||||
|
||||
|
||||
<p> A typemap can be deleted by simply defining no code. For
|
||||
|
|
@ -5160,7 +5160,7 @@ typemaps immediately after the clear operation.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_Placement_of_typemaps"></a>35.7.5 Placement of typemaps</H3>
|
||||
<H3><a name="Ruby_Placement_of_typemaps"></a>36.7.5 Placement of typemaps</H3>
|
||||
|
||||
|
||||
<p> Typemap declarations can be declared in the global scope,
|
||||
|
|
@ -5244,7 +5244,7 @@ string</tt>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn39"></a>35.7.6 Ruby typemaps</H3>
|
||||
<H3><a name="Ruby_nn39"></a>36.7.6 Ruby typemaps</H3>
|
||||
|
||||
|
||||
<p>The following list details all of the typemap methods that
|
||||
|
|
@ -5254,7 +5254,7 @@ can be used by the Ruby module: </p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_in_typemap"></a>35.7.6.1 "in" typemap</H4>
|
||||
<H4><a name="Ruby_in_typemap"></a>36.7.6.1 "in" typemap</H4>
|
||||
|
||||
|
||||
<p>Converts Ruby objects to input
|
||||
|
|
@ -5497,7 +5497,7 @@ arguments to be specified. For example:</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_typecheck_typemap"></a>35.7.6.2 "typecheck" typemap</H4>
|
||||
<H4><a name="Ruby_typecheck_typemap"></a>36.7.6.2 "typecheck" typemap</H4>
|
||||
|
||||
|
||||
<p> The "typecheck" typemap is used to support overloaded
|
||||
|
|
@ -5538,7 +5538,7 @@ on "Typemaps and Overloading."</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_out_typemap"></a>35.7.6.3 "out" typemap</H4>
|
||||
<H4><a name="Ruby_out_typemap"></a>36.7.6.3 "out" typemap</H4>
|
||||
|
||||
|
||||
<p>Converts return value of a C function
|
||||
|
|
@ -5770,7 +5770,7 @@ version of the C datatype matched by the typemap.</td>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_arginit_typemap"></a>35.7.6.4 "arginit" typemap</H4>
|
||||
<H4><a name="Ruby_arginit_typemap"></a>36.7.6.4 "arginit" typemap</H4>
|
||||
|
||||
|
||||
<p> The "arginit" typemap is used to set the initial value of a
|
||||
|
|
@ -5795,7 +5795,7 @@ applications. For example:</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_default_typemap"></a>35.7.6.5 "default" typemap</H4>
|
||||
<H4><a name="Ruby_default_typemap"></a>36.7.6.5 "default" typemap</H4>
|
||||
|
||||
|
||||
<p> The "default" typemap is used to turn an argument into a
|
||||
|
|
@ -5837,7 +5837,7 @@ default argument wrapping.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_check_typemap"></a>35.7.6.6 "check" typemap</H4>
|
||||
<H4><a name="Ruby_check_typemap"></a>36.7.6.6 "check" typemap</H4>
|
||||
|
||||
|
||||
<p> The "check" typemap is used to supply value checking code
|
||||
|
|
@ -5861,7 +5861,7 @@ arguments have been converted. For example:</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_argout_typemap_"></a>35.7.6.7 "argout" typemap</H4>
|
||||
<H4><a name="Ruby_argout_typemap_"></a>36.7.6.7 "argout" typemap</H4>
|
||||
|
||||
|
||||
<p> The "argout" typemap is used to return values from arguments.
|
||||
|
|
@ -6019,7 +6019,7 @@ some function like SWIG_Ruby_AppendOutput.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_freearg_typemap_"></a>35.7.6.8 "freearg" typemap</H4>
|
||||
<H4><a name="Ruby_freearg_typemap_"></a>36.7.6.8 "freearg" typemap</H4>
|
||||
|
||||
|
||||
<p> The "freearg" typemap is used to cleanup argument data. It is
|
||||
|
|
@ -6055,7 +6055,7 @@ abort prematurely.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_newfree_typemap"></a>35.7.6.9 "newfree" typemap</H4>
|
||||
<H4><a name="Ruby_newfree_typemap"></a>36.7.6.9 "newfree" typemap</H4>
|
||||
|
||||
|
||||
<p> The "newfree" typemap is used in conjunction with the <tt>%newobject</tt>
|
||||
|
|
@ -6086,7 +6086,7 @@ ownership and %newobject</a> for further details.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_memberin_typemap"></a>35.7.6.10 "memberin" typemap</H4>
|
||||
<H4><a name="Ruby_memberin_typemap"></a>36.7.6.10 "memberin" typemap</H4>
|
||||
|
||||
|
||||
<p> The "memberin" typemap is used to copy data from<em> an
|
||||
|
|
@ -6119,7 +6119,7 @@ other objects.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_varin_typemap"></a>35.7.6.11 "varin" typemap</H4>
|
||||
<H4><a name="Ruby_varin_typemap"></a>36.7.6.11 "varin" typemap</H4>
|
||||
|
||||
|
||||
<p> The "varin" typemap is used to convert objects in the target
|
||||
|
|
@ -6130,7 +6130,7 @@ This is implementation specific.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_varout_typemap_"></a>35.7.6.12 "varout" typemap</H4>
|
||||
<H4><a name="Ruby_varout_typemap_"></a>36.7.6.12 "varout" typemap</H4>
|
||||
|
||||
|
||||
<p> The "varout" typemap is used to convert a C/C++ object to an
|
||||
|
|
@ -6141,7 +6141,7 @@ This is implementation specific.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_throws_typemap"></a>35.7.6.13 "throws" typemap</H4>
|
||||
<H4><a name="Ruby_throws_typemap"></a>36.7.6.13 "throws" typemap</H4>
|
||||
|
||||
|
||||
<p> The "throws" typemap is only used when SWIG parses a C++
|
||||
|
|
@ -6200,7 +6200,7 @@ handling with %exception</a> section.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_directorin_typemap"></a>35.7.6.14 directorin typemap</H4>
|
||||
<H4><a name="Ruby_directorin_typemap"></a>36.7.6.14 directorin typemap</H4>
|
||||
|
||||
|
||||
<p>Converts C++ objects in director
|
||||
|
|
@ -6454,7 +6454,7 @@ referring to the class itself.</td>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_directorout_typemap"></a>35.7.6.15 directorout typemap</H4>
|
||||
<H4><a name="Ruby_directorout_typemap"></a>36.7.6.15 directorout typemap</H4>
|
||||
|
||||
|
||||
<p>Converts Ruby objects in director
|
||||
|
|
@ -6517,49 +6517,16 @@ typemap.
|
|||
|
||||
|
||||
<tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">$symname </td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;"> Name of
|
||||
function/method being wrapped</td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">$input</td>
|
||||
<td style="font-family: monospace;">Ruby object being sent to the function</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="font-family: monospace;">$symname </td>
|
||||
<td style="font-family: monospace;">Name of function/method being wrapped</td>
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">$1...n </td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;"> Argument being
|
||||
sent to the function</td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">Argument being sent to the function</td>
|
||||
</tr>
|
||||
|
||||
|
||||
|
|
@ -6714,7 +6681,7 @@ exception.<br>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_directorargout_typemap"></a>35.7.6.16 directorargout typemap</H4>
|
||||
<H4><a name="Ruby_directorargout_typemap"></a>36.7.6.16 directorargout typemap</H4>
|
||||
|
||||
|
||||
<p>Output argument processing in director
|
||||
|
|
@ -6763,80 +6730,21 @@ $result = output_helper( $result, NUM2INT($1) );</tt><br>
|
|||
|
||||
|
||||
<tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">$result</td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">Result that the
|
||||
director function returns</td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">Result that the director function returns</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="font-family: monospace;">$input</td>
|
||||
<td style="font-family: monospace;">Ruby object being sent to the function</td>
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">$symname</td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">name of the
|
||||
function/method being wrapped</td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">name of the function/method being wrapped</td>
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">$1...n</td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">Argument being
|
||||
sent to the function</td>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<td style="font-family: monospace;">Argument being sent to the function</td>
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
|
||||
|
||||
|
|
@ -6954,7 +6862,7 @@ referring to the instance of the class itself</td>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_ret_typemap"></a>35.7.6.17 ret typemap</H4>
|
||||
<H4><a name="Ruby_ret_typemap"></a>36.7.6.17 ret typemap</H4>
|
||||
|
||||
|
||||
<p>Cleanup of function return values
|
||||
|
|
@ -6964,7 +6872,7 @@ referring to the instance of the class itself</td>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_globalin_typemap"></a>35.7.6.18 globalin typemap</H4>
|
||||
<H4><a name="Ruby_globalin_typemap"></a>36.7.6.18 globalin typemap</H4>
|
||||
|
||||
|
||||
<p>Setting of C global variables
|
||||
|
|
@ -6974,7 +6882,7 @@ referring to the instance of the class itself</td>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn40"></a>35.7.7 Typemap variables</H3>
|
||||
<H3><a name="Ruby_nn40"></a>36.7.7 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -7084,7 +6992,7 @@ being created. </div>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn41"></a>35.7.8 Useful Functions</H3>
|
||||
<H3><a name="Ruby_nn41"></a>36.7.8 Useful Functions</H3>
|
||||
|
||||
|
||||
<p> When you write a typemap, you usually have to work directly
|
||||
|
|
@ -7108,7 +7016,7 @@ across multiple languages.</p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn42"></a>35.7.8.1 C Datatypes to Ruby Objects</H4>
|
||||
<H4><a name="Ruby_nn42"></a>36.7.8.1 C Datatypes to Ruby Objects</H4>
|
||||
|
||||
|
||||
<div class="diagram">
|
||||
|
|
@ -7164,7 +7072,7 @@ SWIG_From_float(float)</td>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn43"></a>35.7.8.2 Ruby Objects to C Datatypes</H4>
|
||||
<H4><a name="Ruby_nn43"></a>36.7.8.2 Ruby Objects to C Datatypes</H4>
|
||||
|
||||
|
||||
<p>Here, while the Ruby versions return the value directly, the SWIG
|
||||
|
|
@ -7253,7 +7161,7 @@ Ruby_Format_TypeError( "$1_name", "$1_type","$symname", $argnum, $input
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn44"></a>35.7.8.3 Macros for VALUE</H4>
|
||||
<H4><a name="Ruby_nn44"></a>36.7.8.3 Macros for VALUE</H4>
|
||||
|
||||
|
||||
<p> <tt>RSTRING_LEN(str)</tt> </p>
|
||||
|
|
@ -7316,7 +7224,7 @@ Ruby_Format_TypeError( "$1_name", "$1_type","$symname", $argnum, $input
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn45"></a>35.7.8.4 Exceptions</H4>
|
||||
<H4><a name="Ruby_nn45"></a>36.7.8.4 Exceptions</H4>
|
||||
|
||||
|
||||
<p> <tt>void rb_raise(VALUE exception, const char *fmt,
|
||||
|
|
@ -7483,7 +7391,7 @@ arguments are interpreted as with <tt>printf()</tt>. </div>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn46"></a>35.7.8.5 Iterators</H4>
|
||||
<H4><a name="Ruby_nn46"></a>36.7.8.5 Iterators</H4>
|
||||
|
||||
|
||||
<p> <tt>void rb_iter_break()</tt> </p>
|
||||
|
|
@ -7585,7 +7493,7 @@ VALUE), VALUE value)</tt></p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn47"></a>35.7.9 Typemap Examples</H3>
|
||||
<H3><a name="Ruby_nn47"></a>36.7.9 Typemap Examples</H3>
|
||||
|
||||
|
||||
<p> This section includes a few examples of typemaps. For more
|
||||
|
|
@ -7596,7 +7504,7 @@ directory. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn48"></a>35.7.10 Converting a Ruby array to a char **</H3>
|
||||
<H3><a name="Ruby_nn48"></a>36.7.10 Converting a Ruby array to a char **</H3>
|
||||
|
||||
|
||||
<p> A common problem in many C programs is the processing of
|
||||
|
|
@ -7651,7 +7559,7 @@ after the execution of the C function. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn49"></a>35.7.11 Collecting arguments in a hash</H3>
|
||||
<H3><a name="Ruby_nn49"></a>36.7.11 Collecting arguments in a hash</H3>
|
||||
|
||||
|
||||
<p> Ruby's solution to the "keyword arguments" capability of some
|
||||
|
|
@ -7930,7 +7838,7 @@ directory of the SWIG distribution. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn50"></a>35.7.12 Pointer handling</H3>
|
||||
<H3><a name="Ruby_nn50"></a>36.7.12 Pointer handling</H3>
|
||||
|
||||
|
||||
<p> Occasionally, it might be necessary to convert pointer values
|
||||
|
|
@ -8029,7 +7937,7 @@ For example: </p>
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn51"></a>35.7.12.1 Ruby Datatype Wrapping</H4>
|
||||
<H4><a name="Ruby_nn51"></a>36.7.12.1 Ruby Datatype Wrapping</H4>
|
||||
|
||||
|
||||
<p> <tt>VALUE Data_Wrap_Struct(VALUE class, void
|
||||
|
|
@ -8080,7 +7988,7 @@ and assigns that pointer to <i>ptr</i>. </div>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn52"></a>35.7.13 Example: STL Vector to Ruby Array</H3>
|
||||
<H3><a name="Ruby_nn52"></a>36.7.13 Example: STL Vector to Ruby Array</H3>
|
||||
|
||||
|
||||
<p>Another use for macros and type maps is to create a Ruby array
|
||||
|
|
@ -8189,7 +8097,7 @@ the<a href="#Ruby_nn23_1"> C++ Standard Template Library</a>.<br>
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn65"></a>35.8 Docstring Features</H2>
|
||||
<H2><a name="Ruby_nn65"></a>36.8 Docstring Features</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -8250,7 +8158,7 @@ generate ri documentation from a c wrap file, you could do:</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn66"></a>35.8.1 Module docstring</H3>
|
||||
<H3><a name="Ruby_nn66"></a>36.8.1 Module docstring</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -8301,7 +8209,7 @@ macro. For example:
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn67"></a>35.8.2 %feature("autodoc")</H3>
|
||||
<H3><a name="Ruby_nn67"></a>36.8.2 %feature("autodoc")</H3>
|
||||
|
||||
|
||||
<p>Since SWIG does know everything about the function it wraps,
|
||||
|
|
@ -8330,7 +8238,7 @@ feature, described below.
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn68"></a>35.8.2.1 %feature("autodoc", "0")</H4>
|
||||
<H4><a name="Ruby_nn68"></a>36.8.2.1 %feature("autodoc", "0")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -8378,7 +8286,7 @@ Then Ruby code like this will be generated:
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_autodoc1"></a>35.8.2.2 %feature("autodoc", "1")</H4>
|
||||
<H4><a name="Ruby_autodoc1"></a>36.8.2.2 %feature("autodoc", "1")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -8410,7 +8318,7 @@ this:
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_autodoc2"></a>35.8.2.3 %feature("autodoc", "2")</H4>
|
||||
<H4><a name="Ruby_autodoc2"></a>36.8.2.3 %feature("autodoc", "2")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -8426,7 +8334,7 @@ this:
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_feature_autodoc3"></a>35.8.2.4 %feature("autodoc", "3")</H4>
|
||||
<H4><a name="Ruby_feature_autodoc3"></a>36.8.2.4 %feature("autodoc", "3")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -8454,7 +8362,7 @@ this:
|
|||
|
||||
|
||||
|
||||
<H4><a name="Ruby_nn70"></a>35.8.2.5 %feature("autodoc", "docstring")</H4>
|
||||
<H4><a name="Ruby_nn70"></a>36.8.2.5 %feature("autodoc", "docstring")</H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -8482,7 +8390,7 @@ generated string. For example:
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn71"></a>35.8.3 %feature("docstring")</H3>
|
||||
<H3><a name="Ruby_nn71"></a>36.8.3 %feature("docstring")</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -8497,10 +8405,10 @@ docstring and they are output together. </p>
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn53"></a>35.9 Advanced Topics</H2>
|
||||
<H2><a name="Ruby_nn53"></a>36.9 Advanced Topics</H2>
|
||||
|
||||
|
||||
<H3><a name="Ruby_operator_overloading"></a>35.9.1 Operator overloading</H3>
|
||||
<H3><a name="Ruby_operator_overloading"></a>36.9.1 Operator overloading</H3>
|
||||
|
||||
|
||||
<p> SWIG allows operator overloading with, by using the <tt>%extend</tt>
|
||||
|
|
@ -9517,7 +9425,7 @@ parses the expression <i>a != b</i> as <i>!(a == b)</i>.
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn55"></a>35.9.2 Creating Multi-Module Packages</H3>
|
||||
<H3><a name="Ruby_nn55"></a>36.9.2 Creating Multi-Module Packages</H3>
|
||||
|
||||
|
||||
<p> The chapter on <a href="Modules.html#Modules">Working
|
||||
|
|
@ -9698,7 +9606,7 @@ initialized: </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn56"></a>35.9.3 Specifying Mixin Modules</H3>
|
||||
<H3><a name="Ruby_nn56"></a>36.9.3 Specifying Mixin Modules</H3>
|
||||
|
||||
|
||||
<p> The Ruby language doesn't support multiple inheritance, but
|
||||
|
|
@ -9796,7 +9704,7 @@ Features"</a>) for more details). </p>
|
|||
|
||||
|
||||
|
||||
<H2><a name="Ruby_nn57"></a>35.10 Memory Management</H2>
|
||||
<H2><a name="Ruby_nn57"></a>36.10 Memory Management</H2>
|
||||
|
||||
|
||||
<p>One of the most common issues in generating SWIG bindings for
|
||||
|
|
@ -9843,7 +9751,7 @@ understanding of how the underlying library manages memory.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn58"></a>35.10.1 Mark and Sweep Garbage Collector </H3>
|
||||
<H3><a name="Ruby_nn58"></a>36.10.1 Mark and Sweep Garbage Collector </H3>
|
||||
|
||||
|
||||
<p>Ruby uses a mark and sweep garbage collector. When the garbage
|
||||
|
|
@ -9891,7 +9799,7 @@ this memory. </p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn59"></a>35.10.2 Object Ownership</H3>
|
||||
<H3><a name="Ruby_nn59"></a>36.10.2 Object Ownership</H3>
|
||||
|
||||
|
||||
<p>As described above, memory management depends on clearly
|
||||
|
|
@ -10149,7 +10057,7 @@ public:
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn60"></a>35.10.3 Object Tracking</H3>
|
||||
<H3><a name="Ruby_nn60"></a>36.10.3 Object Tracking</H3>
|
||||
|
||||
|
||||
<p>The remaining parts of this section will use the class library
|
||||
|
|
@ -10400,7 +10308,7 @@ methods.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn61"></a>35.10.4 Mark Functions</H3>
|
||||
<H3><a name="Ruby_nn61"></a>36.10.4 Mark Functions</H3>
|
||||
|
||||
|
||||
<p>With a bit more testing, we see that our class library still
|
||||
|
|
@ -10518,7 +10426,7 @@ test suite.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn62"></a>35.10.5 Free Functions</H3>
|
||||
<H3><a name="Ruby_nn62"></a>36.10.5 Free Functions</H3>
|
||||
|
||||
|
||||
<p>By default, SWIG creates a "free" function that is called when
|
||||
|
|
@ -10768,7 +10676,7 @@ been freed, and thus raises a runtime exception.</p>
|
|||
|
||||
|
||||
|
||||
<H3><a name="Ruby_nn63"></a>35.10.6 Embedded Ruby and the C++ Stack</H3>
|
||||
<H3><a name="Ruby_nn63"></a>36.10.6 Embedded Ruby and the C++ Stack</H3>
|
||||
|
||||
|
||||
<p>As has been said, the Ruby GC runs and marks objects before
|
||||
|
|
|
|||
|
|
@ -57,6 +57,7 @@
|
|||
<li><a href="#SWIGPlus_catches">Exception handling with %catches</a>
|
||||
<li><a href="#SWIGPlus_nn33">Pointers to Members</a>
|
||||
<li><a href="#SWIGPlus_smart_pointers">Smart pointers and operator->()</a>
|
||||
<li><a href="#SWIGPlus_ref_unref">C++ reference counted objects - ref/unref feature</a>
|
||||
<li><a href="#SWIGPlus_nn35">Using declarations and inheritance</a>
|
||||
<li><a href="#SWIGPlus_nested_classes">Nested classes</a>
|
||||
<li><a href="#SWIGPlus_const">A brief rant about const-correctness</a>
|
||||
|
|
@ -3356,7 +3357,7 @@ public:
|
|||
|
||||
<p>
|
||||
In this case, the <tt>%extend</tt> directive is not needed, and
|
||||
<tt>%template</tt> does the exactly same job, i.e., it adds two new
|
||||
<tt>%template</tt> does exactly the same job, i.e., it adds two new
|
||||
methods to the Foo class.
|
||||
</p>
|
||||
|
||||
|
|
@ -4618,8 +4619,179 @@ p = f.__deref__() # Raw pointer from operator->
|
|||
<b>Note:</b> Smart pointer support was first added in SWIG-1.3.14.
|
||||
</p>
|
||||
|
||||
<H2><a name="SWIGPlus_ref_unref"></a>6.25 C++ reference counted objects - ref/unref feature</H2>
|
||||
|
||||
<H2><a name="SWIGPlus_nn35"></a>6.25 Using declarations and inheritance</H2>
|
||||
|
||||
<p>
|
||||
Another similar idiom in C++ is the use of reference counted objects. Consider for example:
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
class RCObj {
|
||||
// implement the ref counting mechanism
|
||||
int add_ref();
|
||||
int del_ref();
|
||||
int ref_count();
|
||||
|
||||
public:
|
||||
virtual ~RCObj() = 0;
|
||||
|
||||
int ref() const {
|
||||
return add_ref();
|
||||
}
|
||||
|
||||
int unref() const {
|
||||
if (ref_count() == 0 || del_ref() == 0 ) {
|
||||
delete this;
|
||||
return 0;
|
||||
}
|
||||
return ref_count();
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
class A : RCObj {
|
||||
public:
|
||||
A();
|
||||
int foo();
|
||||
};
|
||||
|
||||
|
||||
class B {
|
||||
A *_a;
|
||||
|
||||
public:
|
||||
B(A *a) : _a(a) {
|
||||
a->ref();
|
||||
}
|
||||
|
||||
~B() {
|
||||
a->unref();
|
||||
}
|
||||
};
|
||||
|
||||
int main() {
|
||||
A *a = new A(); // (count: 0)
|
||||
a->ref(); // 'a' ref here (count: 1)
|
||||
|
||||
B *b1 = new B(a); // 'a' ref here (count: 2)
|
||||
if (1 + 1 == 2) {
|
||||
B *b2 = new B(a); // 'a' ref here (count: 3)
|
||||
delete b2; // 'a' unref, but not deleted (count: 2)
|
||||
}
|
||||
|
||||
delete b1; // 'a' unref, but not deleted (count: 1)
|
||||
a->unref(); // 'a' unref and deleted (count: 0)
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In the example above, the 'A' class instance 'a' is a reference counted
|
||||
object, which can't be deleted arbitrarily since it is shared between
|
||||
the objects 'b1' and 'b2'. 'A' is derived from a <i>Reference Counted
|
||||
Object</i> 'RCObj', which implements the ref/unref idiom.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To tell SWIG that 'RCObj' and all its derived classes are reference
|
||||
counted objects, use the "ref" and "unref" <a href="Customization.html#Customization_features">features</a>.
|
||||
These are also available as <tt>%refobject</tt> and <tt>%unrefobject</tt>, respectively.
|
||||
For example:
|
||||
</p>
|
||||
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%module example
|
||||
...
|
||||
|
||||
%feature("ref") RCObj "$this->ref();"
|
||||
%feature("unref") RCObj "$this->unref();"
|
||||
|
||||
%include "rcobj.h"
|
||||
%include "A.h"
|
||||
...
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
where the code passed to the "ref" and "unref" features will be
|
||||
executed as needed whenever a new object is passed to python, or when
|
||||
python tries to release the proxy object instance, respectively.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
On the python side, the use of a reference counted object is no
|
||||
different to any other regular instance:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
def create_A():
|
||||
a = A() # SWIG ref 'a' - new object is passed to python (count: 1)
|
||||
b1 = B(a) # C++ ref 'a (count: 2)
|
||||
if 1 + 1 == 2:
|
||||
b2 = B(a) # C++ ref 'a' (count: 3)
|
||||
return a # 'b1' and 'b2' are released and deleted, C++ unref 'a' twice (count: 1)
|
||||
|
||||
a = create_A() # (count: 1)
|
||||
exit # 'a' is released, SWIG unref 'a' called in the destructor wrapper (count: 0)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Note that the user doesn't explicitly need to call 'a->ref()' nor 'a->unref()'
|
||||
(and neither 'delete a'). Instead, SWIG takes cares of executing the "ref"
|
||||
and "unref" calls as needed. If the user doesn't specify the
|
||||
"ref/unref" feature for a type, SWIG will produce code equivalent to defining these
|
||||
features:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%feature("ref") ""
|
||||
%feature("unref") "delete $this;"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In other words, SWIG will not do anything special when a new object
|
||||
is passed to python, and it will always 'delete' the underlying object when
|
||||
python releases the proxy instance.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="Customization.html#Customization_ownership">%newobject feature</a> is designed to indicate to
|
||||
the target language that it should take ownership of the returned object.
|
||||
When used in conjunction with a type that has the "ref" feature associated with it, it additionally emits the
|
||||
code in the "ref" feature into the C++ wrapper.
|
||||
Consider wrapping the following factory function in addition to the above:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%newobject AFactory;
|
||||
A *AFactory() {
|
||||
return new A();
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The <tt>AFactory</tt> function now acts much like a call to the <tt>A</tt> constructor with respect to memory handling:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
a = AFactory() # SWIG ref 'a' due to %newobject (count: 1)
|
||||
exit # 'a' is released, SWIG unref 'a' called in the destructor wrapper (count: 0)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
<H2><a name="SWIGPlus_nn35"></a>6.26 Using declarations and inheritance</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4782,7 +4954,7 @@ public:
|
|||
</div>
|
||||
</ul>
|
||||
|
||||
<H2><a name="SWIGPlus_nested_classes"></a>6.26 Nested classes</H2>
|
||||
<H2><a name="SWIGPlus_nested_classes"></a>6.27 Nested classes</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4926,7 +5098,7 @@ Nested class warnings could also not be suppressed using %warnfilter.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="SWIGPlus_const"></a>6.27 A brief rant about const-correctness</H2>
|
||||
<H2><a name="SWIGPlus_const"></a>6.28 A brief rant about const-correctness</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4984,7 +5156,7 @@ using another tool if maintaining constness is the most important part
|
|||
of your project.
|
||||
</p>
|
||||
|
||||
<H2><a name="SWIGPlus_nn42"></a>6.28 Where to go for more information</H2>
|
||||
<H2><a name="SWIGPlus_nn42"></a>6.29 Where to go for more information</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -33,7 +33,8 @@ Last update : SWIG-2.0.5 (in progress)
|
|||
<H3>Language Module Documentation</H3>
|
||||
|
||||
<ul>
|
||||
<li><a href="Allegrocl.html#Allegrocl">Allegro CL support</a></li>
|
||||
<li><a href="Allegrocl.html#Allegrocl">Allegro Common Lisp support</a></li>
|
||||
<li><a href="Android.html#Android">Android support</a></li>
|
||||
<li><a href="CSharp.html#CSharp">C# support</a></li>
|
||||
<li><a href="Chicken.html#Chicken">Chicken support</a></li>
|
||||
<li><a href="D.html#D">D support</a></li>
|
||||
|
|
@ -43,7 +44,7 @@ Last update : SWIG-2.0.5 (in progress)
|
|||
<li><a href="Lisp.html#Lisp">Common Lisp support</a></li>
|
||||
<li><a href="Lua.html#Lua">Lua support</a></li>
|
||||
<li><a href="Modula3.html#Modula3">Modula3 support</a></li>
|
||||
<li><a href="Mzscheme.html#Mzscheme">MzScheme support</a></li>
|
||||
<li><a href="Mzscheme.html#Mzscheme">MzScheme/Racket support</a></li>
|
||||
<li><a href="Ocaml.html#Ocaml">Ocaml support</a></li>
|
||||
<li><a href="Octave.html#Octave">Octave support</a></li>
|
||||
<li><a href="Perl5.html#Perl5">Perl5 support</a></li>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Tcl"></a>36 SWIG and Tcl</H1>
|
||||
<H1><a name="Tcl"></a>37 SWIG and Tcl</H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -83,7 +83,7 @@ Tcl 8.0 or a later release. Earlier releases of SWIG supported Tcl 7.x, but
|
|||
this is no longer supported.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn2"></a>36.1 Preliminaries</H2>
|
||||
<H2><a name="Tcl_nn2"></a>37.1 Preliminaries</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -109,7 +109,7 @@ build a Tcl extension module. To finish building the module, you
|
|||
need to compile this file and link it with the rest of your program.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn3"></a>36.1.1 Getting the right header files</H3>
|
||||
<H3><a name="Tcl_nn3"></a>37.1.1 Getting the right header files</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -127,7 +127,7 @@ this is the case, you should probably make a symbolic link so that <tt>tcl.h</tt
|
|||
header file.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn4"></a>36.1.2 Compiling a dynamic module</H3>
|
||||
<H3><a name="Tcl_nn4"></a>37.1.2 Compiling a dynamic module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -162,7 +162,7 @@ The name of the module is specified using the <tt>%module</tt> directive or the
|
|||
<tt> -module</tt> command line option.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn5"></a>36.1.3 Static linking</H3>
|
||||
<H3><a name="Tcl_nn5"></a>37.1.3 Static linking</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -228,7 +228,7 @@ minimal in most situations (and quite frankly not worth the extra
|
|||
hassle in the opinion of this author).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn6"></a>36.1.4 Using your module</H3>
|
||||
<H3><a name="Tcl_nn6"></a>37.1.4 Using your module</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -356,7 +356,7 @@ to the default system configuration (this requires root access and you will need
|
|||
the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn7"></a>36.1.5 Compilation of C++ extensions</H3>
|
||||
<H3><a name="Tcl_nn7"></a>37.1.5 Compilation of C++ extensions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -439,7 +439,7 @@ erratic program behavior. If working with lots of software components, you
|
|||
might want to investigate using a more formal standard such as COM.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn8"></a>36.1.6 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Tcl_nn8"></a>37.1.6 Compiling for 64-bit platforms</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -466,7 +466,7 @@ also introduce problems on platforms that support more than one
|
|||
linking standard (e.g., -o32 and -n32 on Irix).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn9"></a>36.1.7 Setting a package prefix</H3>
|
||||
<H3><a name="Tcl_nn9"></a>37.1.7 Setting a package prefix</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -485,7 +485,7 @@ option will append the prefix to the name when creating a command and
|
|||
call it "<tt>Foo_bar</tt>".
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn10"></a>36.1.8 Using namespaces</H3>
|
||||
<H3><a name="Tcl_nn10"></a>37.1.8 Using namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -507,7 +507,7 @@ When the<tt> -namespace</tt> option is used, objects in the module
|
|||
are always accessed with the namespace name such as <tt>Foo::bar</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn11"></a>36.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
|
||||
<H2><a name="Tcl_nn11"></a>37.2 Building Tcl/Tk Extensions under Windows 95/NT</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -518,7 +518,7 @@ covers the process of using SWIG with Microsoft Visual C++.
|
|||
although the procedure may be similar with other compilers.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn12"></a>36.2.1 Running SWIG from Developer Studio</H3>
|
||||
<H3><a name="Tcl_nn12"></a>37.2.1 Running SWIG from Developer Studio</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -576,7 +576,7 @@ MSDOS > tclsh80
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn13"></a>36.2.2 Using NMAKE</H3>
|
||||
<H3><a name="Tcl_nn13"></a>37.2.2 Using NMAKE</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -639,7 +639,7 @@ to get you started. With a little practice, you'll be making lots of
|
|||
Tcl extensions.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn14"></a>36.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Tcl_nn14"></a>37.3 A tour of basic C/C++ wrapping</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -650,7 +650,7 @@ classes. This section briefly covers the essential aspects of this
|
|||
wrapping.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn15"></a>36.3.1 Modules</H3>
|
||||
<H3><a name="Tcl_nn15"></a>37.3.1 Modules</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -684,7 +684,7 @@ To fix this, supply an extra argument to <tt>load</tt> like this:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn16"></a>36.3.2 Functions</H3>
|
||||
<H3><a name="Tcl_nn16"></a>37.3.2 Functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -709,7 +709,7 @@ like you think it does:
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn17"></a>36.3.3 Global variables</H3>
|
||||
<H3><a name="Tcl_nn17"></a>37.3.3 Global variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -789,7 +789,7 @@ extern char *path; // Read-only (due to %immutable)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn18"></a>36.3.4 Constants and enums</H3>
|
||||
<H3><a name="Tcl_nn18"></a>37.3.4 Constants and enums</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -873,7 +873,7 @@ When an identifier name is given, it is used to perform an implicit hash-table l
|
|||
conversion. This allows the <tt>global</tt> statement to be omitted.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn19"></a>36.3.5 Pointers</H3>
|
||||
<H3><a name="Tcl_nn19"></a>37.3.5 Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -969,7 +969,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
|
|||
<tt>None</tt> if the conversion can't be performed.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn20"></a>36.3.6 Structures</H3>
|
||||
<H3><a name="Tcl_nn20"></a>37.3.6 Structures</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1251,7 +1251,7 @@ Note: Tcl only destroys the underlying object if it has ownership. See the
|
|||
memory management section that appears shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn21"></a>36.3.7 C++ classes</H3>
|
||||
<H3><a name="Tcl_nn21"></a>37.3.7 C++ classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1318,7 +1318,7 @@ In Tcl, the static member is accessed as follows:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn22"></a>36.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Tcl_nn22"></a>37.3.8 C++ inheritance</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1367,7 +1367,7 @@ For instance:
|
|||
It is safe to use multiple inheritance with SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn23"></a>36.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Tcl_nn23"></a>37.3.9 Pointers, references, values, and arrays</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1421,7 +1421,7 @@ to hold the result and a pointer is returned (Tcl will release this memory
|
|||
when the return value is garbage collected).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn24"></a>36.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Tcl_nn24"></a>37.3.10 C++ overloaded functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1544,7 +1544,7 @@ first declaration takes precedence.
|
|||
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn25"></a>36.3.11 C++ operators</H3>
|
||||
<H3><a name="Tcl_nn25"></a>37.3.11 C++ operators</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1646,7 +1646,7 @@ There are ways to make this operator appear as part of the class using the <tt>%
|
|||
Keep reading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn26"></a>36.3.12 C++ namespaces</H3>
|
||||
<H3><a name="Tcl_nn26"></a>37.3.12 C++ namespaces</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1710,7 +1710,7 @@ utilizes thousands of small deeply nested namespaces each with
|
|||
identical symbol names, well, then you get what you deserve.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn27"></a>36.3.13 C++ templates</H3>
|
||||
<H3><a name="Tcl_nn27"></a>37.3.13 C++ templates</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1762,7 +1762,7 @@ More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</
|
|||
examples will appear later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn28"></a>36.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Tcl_nn28"></a>37.3.14 C++ Smart Pointers</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1846,7 +1846,7 @@ simply use the <tt>__deref__()</tt> method. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn29"></a>36.4 Further details on the Tcl class interface</H2>
|
||||
<H2><a name="Tcl_nn29"></a>37.4 Further details on the Tcl class interface</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1859,7 +1859,7 @@ of low-level details were omitted. This section provides a brief overview
|
|||
of how the proxy classes work.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn30"></a>36.4.1 Proxy classes</H3>
|
||||
<H3><a name="Tcl_nn30"></a>37.4.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1924,7 +1924,7 @@ function. This allows objects to be encapsulated objects that look a lot like
|
|||
as shown in the last section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn31"></a>36.4.2 Memory management</H3>
|
||||
<H3><a name="Tcl_nn31"></a>37.4.2 Memory management</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2112,7 +2112,7 @@ typemaps--an advanced topic discussed later.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Tcl_nn32"></a>36.5 Input and output parameters</H2>
|
||||
<H2><a name="Tcl_nn32"></a>37.5 Input and output parameters</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2300,7 +2300,7 @@ set c [lindex $dim 1]
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn33"></a>36.6 Exception handling </H2>
|
||||
<H2><a name="Tcl_nn33"></a>37.6 Exception handling </H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2434,7 +2434,7 @@ Since SWIG's exception handling is user-definable, you are not limited to C++ ex
|
|||
See the chapter on "<a href="Customization.html#Customization">Customization Features</a>" for more examples.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn34"></a>36.7 Typemaps</H2>
|
||||
<H2><a name="Tcl_nn34"></a>37.7 Typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2451,7 +2451,7 @@ Typemaps are only used if you want to change some aspect of the primitive
|
|||
C-Tcl interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn35"></a>36.7.1 What is a typemap?</H3>
|
||||
<H3><a name="Tcl_nn35"></a>37.7.1 What is a typemap?</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2568,7 +2568,7 @@ parameter is omitted):
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn36"></a>36.7.2 Tcl typemaps</H3>
|
||||
<H3><a name="Tcl_nn36"></a>37.7.2 Tcl typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2706,7 +2706,7 @@ Initialize an argument to a value before any conversions occur.
|
|||
Examples of these methods will appear shortly.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn37"></a>36.7.3 Typemap variables</H3>
|
||||
<H3><a name="Tcl_nn37"></a>37.7.3 Typemap variables</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2777,7 +2777,7 @@ properly assigned.
|
|||
The Tcl name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn38"></a>36.7.4 Converting a Tcl list to a char ** </H3>
|
||||
<H3><a name="Tcl_nn38"></a>37.7.4 Converting a Tcl list to a char ** </H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2839,7 +2839,7 @@ argv[2] = Larry
|
|||
3
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn39"></a>36.7.5 Returning values in arguments</H3>
|
||||
<H3><a name="Tcl_nn39"></a>37.7.5 Returning values in arguments</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2881,7 +2881,7 @@ result, a Tcl function using these typemaps will work like this :
|
|||
%
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Tcl_nn40"></a>36.7.6 Useful functions</H3>
|
||||
<H3><a name="Tcl_nn40"></a>37.7.6 Useful functions</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2958,7 +2958,7 @@ int Tcl_IsShared(Tcl_Obj *obj);
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn41"></a>36.7.7 Standard typemaps</H3>
|
||||
<H3><a name="Tcl_nn41"></a>37.7.7 Standard typemaps</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3042,7 +3042,7 @@ work)
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Tcl_nn42"></a>36.7.8 Pointer handling</H3>
|
||||
<H3><a name="Tcl_nn42"></a>37.7.8 Pointer handling</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3118,7 +3118,7 @@ For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Tcl_nn43"></a>36.8 Turning a SWIG module into a Tcl Package.</H2>
|
||||
<H2><a name="Tcl_nn43"></a>37.8 Turning a SWIG module into a Tcl Package.</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3190,7 +3190,7 @@ As a final note, most SWIG examples do not yet use the
|
|||
to use the <tt>load</tt> command instead.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn44"></a>36.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
|
||||
<H2><a name="Tcl_nn44"></a>37.9 Building new kinds of Tcl interfaces (in Tcl)</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3289,7 +3289,7 @@ danger of blowing something up (although it is easily accomplished
|
|||
with an out of bounds array access).
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn45"></a>36.9.1 Proxy classes</H3>
|
||||
<H3><a name="Tcl_nn45"></a>37.9.1 Proxy classes</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3410,7 +3410,7 @@ short, but clever Tcl script can be combined with SWIG to do many
|
|||
interesting things.
|
||||
</p>
|
||||
|
||||
<H2><a name="Tcl_nn46"></a>36.10 Tcl/Tk Stubs</H2>
|
||||
<H2><a name="Tcl_nn46"></a>37.10 Tcl/Tk Stubs</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -73,6 +73,7 @@
|
|||
<li><a href="#Typemaps_nn43">Typemaps for multiple target languages</a>
|
||||
<li><a href="#Typemaps_optimal">Optimal code generation when returning by value</a>
|
||||
<li><a href="#Typemaps_multi_argument_typemaps">Multi-argument typemaps</a>
|
||||
<li><a href="#Typemaps_warnings">Typemap warnings</a>
|
||||
<li><a href="#Typemaps_fragments">Typemap fragments</a>
|
||||
<ul>
|
||||
<li><a href="#Typemaps_fragment_type_specialization">Fragment type specialization</a>
|
||||
|
|
@ -3597,7 +3598,16 @@ with non-consecutive C/C++ arguments; a workaround such as a helper function re-
|
|||
the arguments to make them consecutive will need to be written.
|
||||
</p>
|
||||
|
||||
<H2><a name="Typemaps_fragments"></a>10.10 Typemap fragments</H2>
|
||||
<H2><a name="Typemaps_warnings"></a>10.10 Typemap warnings</H2>
|
||||
|
||||
|
||||
<p>
|
||||
Warnings can be added to typemaps so that SWIG generates a warning message whenever the typemap is used.
|
||||
See the information in the <a href="Warnings.html#Warnings_nn5">issuing warnings</a> section.
|
||||
</p>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_fragments"></a>10.11 Typemap fragments</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3846,7 +3856,7 @@ fragment usage unless a desire to really get to grips
|
|||
with some powerful but tricky macro and fragment usage that is used in parts of the SWIG typemap library.
|
||||
</p>
|
||||
|
||||
<H3><a name="Typemaps_fragment_type_specialization"></a>10.10.1 Fragment type specialization</H3>
|
||||
<H3><a name="Typemaps_fragment_type_specialization"></a>10.11.1 Fragment type specialization</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3879,7 +3889,7 @@ struct A {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Typemaps_automatic_specialization"></a>10.10.2 Fragments and automatic typemap specialization</H3>
|
||||
<H3><a name="Typemaps_automatic_specialization"></a>10.11.2 Fragments and automatic typemap specialization</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3925,7 +3935,7 @@ The interested (or very brave) reader can take a look at the fragments.swg file
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_runtime_type_checker"></a>10.11 The run-time type checker</H2>
|
||||
<H2><a name="Typemaps_runtime_type_checker"></a>10.12 The run-time type checker</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3951,7 +3961,7 @@ language modules.</li>
|
|||
<li>Modules can be unloaded from the type system.</li>
|
||||
</ul>
|
||||
|
||||
<H3><a name="Typemaps_nn45"></a>10.11.1 Implementation</H3>
|
||||
<H3><a name="Typemaps_nn45"></a>10.12.1 Implementation</H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4137,7 +4147,7 @@ structures rather than creating new ones. These <tt>swig_module_info</tt>
|
|||
structures are chained together in a circularly linked list.
|
||||
</p>
|
||||
|
||||
<H3><a name="Typemaps_runtime_type_checker_usage"></a>10.11.2 Usage</H3>
|
||||
<H3><a name="Typemaps_runtime_type_checker_usage"></a>10.12.2 Usage</H3>
|
||||
|
||||
|
||||
<p>This section covers how to use these functions from typemaps. To learn how to
|
||||
|
|
@ -4231,7 +4241,7 @@ probably just look at the output of SWIG to get a better sense for how types are
|
|||
managed.
|
||||
</p>
|
||||
|
||||
<H2><a name="Typemaps_overloading"></a>10.12 Typemaps and overloading</H2>
|
||||
<H2><a name="Typemaps_overloading"></a>10.13 Typemaps and overloading</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4542,7 +4552,7 @@ Subsequent "in" typemaps would then perform more extensive type-checking.
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H2><a name="Typemaps_nn48"></a>10.13 More about <tt>%apply</tt> and <tt>%clear</tt></H2>
|
||||
<H2><a name="Typemaps_nn48"></a>10.14 More about <tt>%apply</tt> and <tt>%clear</tt></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4628,7 +4638,7 @@ example:
|
|||
</div>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_nn47"></a>10.14 Passing data between typemaps</H2>
|
||||
<H2><a name="Typemaps_nn47"></a>10.15 Passing data between typemaps</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4665,7 +4675,7 @@ sure that the typemaps sharing information have exactly the same types and names
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Typemaps_nn52"></a>10.15 C++ "this" pointer</H2>
|
||||
<H2><a name="Typemaps_nn52"></a>10.16 C++ "this" pointer</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4725,7 +4735,7 @@ will also match the typemap. One work around is to create an interface file tha
|
|||
the method, but gives the argument a name other than <tt>self</tt>.
|
||||
</p>
|
||||
|
||||
<H2><a name="Typemaps_nn51"></a>10.16 Where to go for more information?</H2>
|
||||
<H2><a name="Typemaps_nn51"></a>10.17 Where to go for more information?</H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -257,16 +257,23 @@ Warning messages can be associated with typemaps using the
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%typemap(in, warning="901:You are really going to regret this") blah * {
|
||||
%typemap(in, warning="901:You are really going to regret this usage of $1_type $1_name") blah * {
|
||||
...
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
In this case, the warning message will be printed whenever the typemap is actually used.
|
||||
In this case, the warning message will be printed whenever the typemap is actually used and the <a href="Typemaps.html#Typemaps_special_variables">special variables</a> will be expanded as appropriate, for example:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
example.i:23: Warning 901: You are really going to regret this usage of blah * self
|
||||
example.i:24: Warning 901: You are really going to regret this usage of blah * stuff
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Warnings_symbolic_symbols"></a>14.5 Symbolic symbols</H2>
|
||||
|
||||
|
||||
|
|
@ -501,7 +508,7 @@ example.i(4) : Syntax error in input.
|
|||
<li>501. Overloaded declaration ignored. <em>decl</em>. Previous declaration is <em>decl</em>.
|
||||
<li>502. Overloaded constructor ignored. <em>decl</em>. Previous declaration is <em>decl</em>.
|
||||
<li>503. Can't wrap '<em>identifier</em>' unless renamed to a valid identifier.
|
||||
<li>504. Function <em>name</em> must have a return type.
|
||||
<li>504. Function <em>name</em> must have a return type. Ignored.
|
||||
<li>505. Variable length arguments discarded.
|
||||
<li>506. Can't wrap varargs with keyword arguments enabled.
|
||||
<li>507. Adding native function <em>name</em> not supported (ignored).
|
||||
|
|
@ -518,6 +525,7 @@ example.i(4) : Syntax error in input.
|
|||
<li>518. Portability warning: File <em>file1</em> will be overwritten by <em>file2</em> on case insensitive filesystems such as Windows' FAT32 and NTFS unless the class/module name is renamed.
|
||||
<li>519. %template() contains no name. Template method ignored: <em>declaration</em>
|
||||
<li>520. <em>Base/Derived</em> class '<em>classname1</em>' of '<em>classname2</em>' is not similarly marked as a smart pointer.
|
||||
<li>521. Illegal destructor name <em>name</em>. Ignored.
|
||||
</ul>
|
||||
|
||||
<H3><a name="Warnings_nn15"></a>14.9.6 Language module specific (700-899) </H3>
|
||||
|
|
|
|||
|
|
@ -313,6 +313,18 @@ If you want to check out SWIG to a different folder to the proposed
|
|||
the autotools will fail miserably on those.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The PCRE third party library needs to be built next.
|
||||
Download the latest PCRE source tarball, such as <tt>pcre-8.10.tar.bz2</tt>, from
|
||||
<a href=http://www.pcre.org>PCRE</a> and place in the <tt>/usr/src/swig</tt> directory.
|
||||
Build PCRE as a static library using the Tools/pcre-build.sh script as follows:
|
||||
|
||||
<div class="shell"><pre>
|
||||
cd /usr/src/swig
|
||||
Tools/pcre-build.sh
|
||||
</pre></div>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
You are now ready to build SWIG. Execute the following commands to build swig.exe:
|
||||
<div class="shell"><pre>
|
||||
|
|
|
|||
BIN
Doc/Manual/android-class.png
Normal file
BIN
Doc/Manual/android-class.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
Doc/Manual/android-simple.png
Normal file
BIN
Doc/Manual/android-simple.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.7 KiB |
|
|
@ -15,6 +15,7 @@ Warnings.html
|
|||
Modules.html
|
||||
CCache.html
|
||||
Allegrocl.html
|
||||
Android.html
|
||||
CSharp.html
|
||||
Chicken.html
|
||||
D.html
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
# certain packages have been installed. Set the prefixes
|
||||
# accordingly.
|
||||
#
|
||||
# 2. To use this makefile, set required varibles, eg SRCS, INTERFACE,
|
||||
# 2. To use this makefile, set required variables, eg SRCS, INTERFACE,
|
||||
# INTERFACEDIR, INCLUDES, LIBS, TARGET, and do a
|
||||
# $(MAKE) -f Makefile.template.in SRCS='$(SRCS)' \
|
||||
# INCLUDES='$(INCLUDES) LIBS='$(LIBS)' INTERFACE='$(INTERFACE)' \
|
||||
|
|
@ -333,6 +333,7 @@ python_clean:
|
|||
# Make sure these locate your Octave installation
|
||||
OCTAVE_INCLUDE= $(DEFS) @OCTAVEEXT@
|
||||
OCTAVE_LIB =
|
||||
OCTAVE = @OCTAVE@ -qf
|
||||
|
||||
# Extra Octave specific dynamic linking options
|
||||
OCTAVE_DLNK = @OCTAVEDYNAMICLINKING@
|
||||
|
|
@ -358,6 +359,17 @@ octave_cpp: $(SRCS)
|
|||
$(CXX) -g -c $(CCSHARED) $(CFLAGS) $(ICXXSRCS) $(SRCS) $(CXXSRCS) $(INCLUDES) -I$(OCTAVE_INCLUDE)
|
||||
$(CXXSHARED) -g $(CFLAGS) $(OBJS) $(IOBJS) $(OCTAVE_DLNK) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)$(TARGET)$(OCTAVE_SO)
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Running an Octave example
|
||||
# -----------------------------------------------------------------
|
||||
|
||||
OCTSCRIPT = runme.m
|
||||
|
||||
octave_run: $(OCTSCRIPT)
|
||||
for file in $(OCTSCRIPT); do \
|
||||
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH OCTAVEPATH=$(srcdir):$$OCTAVEPATH $(OCTAVE) $$file >/dev/null || break; \
|
||||
done
|
||||
|
||||
# -----------------------------------------------------------------
|
||||
# Cleaning the octave examples
|
||||
# -----------------------------------------------------------------
|
||||
|
|
@ -1298,11 +1310,6 @@ else
|
|||
DCOMPILER = @D1COMPILER@
|
||||
endif
|
||||
|
||||
ifeq (dmd,$(DCOMPILER))
|
||||
# DMD is 32bit only by now
|
||||
DCFLAGS = -m32
|
||||
endif
|
||||
|
||||
# ----------------------------------------------------------------
|
||||
# Build a dynamically loadable D wrapper for a C module
|
||||
# ----------------------------------------------------------------
|
||||
|
|
|
|||
3
Examples/android/check.list
Normal file
3
Examples/android/check.list
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# see top-level Makefile.in
|
||||
class
|
||||
simple
|
||||
15
Examples/android/class/AndroidManifest.xml
Normal file
15
Examples/android/class/AndroidManifest.xml
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
package="org.swig.classexample"
|
||||
android:versionCode="1"
|
||||
android:versionName="1.0">
|
||||
<application android:label="@string/app_name" >
|
||||
<activity android:name="SwigClass"
|
||||
android:label="@string/app_name">
|
||||
<intent-filter>
|
||||
<action android:name="android.intent.action.MAIN" />
|
||||
<category android:name="android.intent.category.LAUNCHER" />
|
||||
</intent-filter>
|
||||
</activity>
|
||||
</application>
|
||||
</manifest>
|
||||
29
Examples/android/class/Makefile
Normal file
29
Examples/android/class/Makefile
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
TOP = ../..
|
||||
SWIG = $(TOP)/../preinst-swig
|
||||
TARGET = example
|
||||
INTERFACE = example.i
|
||||
PACKAGEDIR = src/org/swig
|
||||
PACKAGENAME= org.swig.classexample
|
||||
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/classexample
|
||||
PROJECTNAME= SwigClass
|
||||
TARGETID = 1
|
||||
|
||||
all:: android
|
||||
|
||||
android::
|
||||
android update project --target $(TARGETID) --name $(PROJECTNAME) --path .
|
||||
$(SWIG) -c++ -java $(SWIGOPT) -o jni/$(TARGET)_wrap.cpp jni/$(INTERFACE)
|
||||
ndk-build
|
||||
ant debug
|
||||
|
||||
install::
|
||||
-adb uninstall $(PACKAGENAME)
|
||||
adb install bin/$(PROJECTNAME)-debug.apk
|
||||
|
||||
clean::
|
||||
ant clean
|
||||
rm -f jni/$(TARGET)_wrap.cpp
|
||||
rm -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
|
||||
|
||||
|
||||
check: all
|
||||
17
Examples/android/class/ant.properties
Normal file
17
Examples/android/class/ant.properties
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# This file is used to override default values used by the Ant build system.
|
||||
#
|
||||
# This file must be checked in Version Control Systems, as it is
|
||||
# integral to the build system of your project.
|
||||
|
||||
# This file is only used by the Ant script.
|
||||
|
||||
# You can use this to override default values such as
|
||||
# 'source.dir' for the location of your java source folder and
|
||||
# 'out.dir' for the location of your output folder.
|
||||
|
||||
# You can also use it define how the release builds are signed by declaring
|
||||
# the following properties:
|
||||
# 'key.store' for the location of your keystore and
|
||||
# 'key.alias' for the name of the key to use.
|
||||
# The password will be asked during the build when you use the 'release' target.
|
||||
|
||||
85
Examples/android/class/build.xml
Normal file
85
Examples/android/class/build.xml
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project name="SwigClass" default="help">
|
||||
|
||||
<!-- The local.properties file is created and updated by the 'android' tool.
|
||||
It contains the path to the SDK. It should *NOT* be checked into
|
||||
Version Control Systems. -->
|
||||
<loadproperties srcFile="local.properties" />
|
||||
|
||||
<!-- The ant.properties file can be created by you. It is only edited by the
|
||||
'android' tool to add properties to it.
|
||||
This is the place to change some Ant specific build properties.
|
||||
Here are some properties you may want to change/update:
|
||||
|
||||
source.dir
|
||||
The name of the source directory. Default is 'src'.
|
||||
out.dir
|
||||
The name of the output directory. Default is 'bin'.
|
||||
|
||||
For other overridable properties, look at the beginning of the rules
|
||||
files in the SDK, at tools/ant/build.xml
|
||||
|
||||
Properties related to the SDK location or the project target should
|
||||
be updated using the 'android' tool with the 'update' action.
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems.
|
||||
|
||||
-->
|
||||
<property file="ant.properties" />
|
||||
|
||||
<!-- The project.properties file is created and updated by the 'android'
|
||||
tool, as well as ADT.
|
||||
|
||||
This contains project specific properties such as project target, and library
|
||||
dependencies. Lower level build properties are stored in ant.properties
|
||||
(or in .classpath for Eclipse projects).
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems. -->
|
||||
<loadproperties srcFile="project.properties" />
|
||||
|
||||
<!-- quick check on sdk.dir -->
|
||||
<fail
|
||||
message="sdk.dir is missing. Make sure to generate local.properties using 'android update project'"
|
||||
unless="sdk.dir"
|
||||
/>
|
||||
|
||||
|
||||
<!-- extension targets. Uncomment the ones where you want to do custom work
|
||||
in between standard targets -->
|
||||
<!--
|
||||
<target name="-pre-build">
|
||||
</target>
|
||||
<target name="-pre-compile">
|
||||
</target>
|
||||
|
||||
/* This is typically used for code obfuscation.
|
||||
Compiled code location: ${out.classes.absolute.dir}
|
||||
If this is not done in place, override ${out.dex.input.absolute.dir} */
|
||||
<target name="-post-compile">
|
||||
</target>
|
||||
-->
|
||||
|
||||
<!-- Import the actual build file.
|
||||
|
||||
To customize existing targets, there are two options:
|
||||
- Customize only one target:
|
||||
- copy/paste the target into this file, *before* the
|
||||
<import> task.
|
||||
- customize it to your needs.
|
||||
- Customize the whole content of build.xml
|
||||
- copy/paste the content of the rules files (minus the top node)
|
||||
into this file, replacing the <import> task.
|
||||
- customize to your needs.
|
||||
|
||||
***********************
|
||||
****** IMPORTANT ******
|
||||
***********************
|
||||
In all cases you must update the value of version-tag below to read 'custom' instead of an integer,
|
||||
in order to avoid having your file be overridden by tools such as "android update project"
|
||||
-->
|
||||
<!-- version-tag: 1 -->
|
||||
<import file="${sdk.dir}/tools/ant/build.xml" />
|
||||
|
||||
</project>
|
||||
10
Examples/android/class/jni/Android.mk
Normal file
10
Examples/android/class/jni/Android.mk
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.cpp example.cpp
|
||||
LOCAL_CFLAGS := -frtti
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
28
Examples/android/class/jni/example.cpp
Normal file
28
Examples/android/class/jni/example.cpp
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
/* File : example.cpp */
|
||||
|
||||
#include "example.h"
|
||||
#define M_PI 3.14159265358979323846
|
||||
|
||||
/* Move the shape to a new location */
|
||||
void Shape::move(double dx, double dy) {
|
||||
x += dx;
|
||||
y += dy;
|
||||
}
|
||||
|
||||
int Shape::nshapes = 0;
|
||||
|
||||
double Circle::area(void) {
|
||||
return M_PI*radius*radius;
|
||||
}
|
||||
|
||||
double Circle::perimeter(void) {
|
||||
return 2*M_PI*radius;
|
||||
}
|
||||
|
||||
double Square::area(void) {
|
||||
return width*width;
|
||||
}
|
||||
|
||||
double Square::perimeter(void) {
|
||||
return 4*width;
|
||||
}
|
||||
34
Examples/android/class/jni/example.h
Normal file
34
Examples/android/class/jni/example.h
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
/* File : example.h */
|
||||
|
||||
class Shape {
|
||||
public:
|
||||
Shape() {
|
||||
nshapes++;
|
||||
}
|
||||
virtual ~Shape() {
|
||||
nshapes--;
|
||||
};
|
||||
double x, y;
|
||||
void move(double dx, double dy);
|
||||
virtual double area(void) = 0;
|
||||
virtual double perimeter(void) = 0;
|
||||
static int nshapes;
|
||||
};
|
||||
|
||||
class Circle : public Shape {
|
||||
private:
|
||||
double radius;
|
||||
public:
|
||||
Circle(double r) : radius(r) { };
|
||||
virtual double area(void);
|
||||
virtual double perimeter(void);
|
||||
};
|
||||
|
||||
class Square : public Shape {
|
||||
private:
|
||||
double width;
|
||||
public:
|
||||
Square(double w) : width(w) { };
|
||||
virtual double area(void);
|
||||
virtual double perimeter(void);
|
||||
};
|
||||
9
Examples/android/class/jni/example.i
Normal file
9
Examples/android/class/jni/example.i
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%{
|
||||
#include "example.h"
|
||||
%}
|
||||
|
||||
/* Let's just grab the original header file here */
|
||||
%include "example.h"
|
||||
10
Examples/android/class/local.properties
Normal file
10
Examples/android/class/local.properties
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must *NOT* be checked in Version Control Systems,
|
||||
# as it contains information specific to your local configuration.
|
||||
|
||||
# location of the SDK. This is only used by Ant
|
||||
# For customization when using a Version Control System, please read the
|
||||
# header note.
|
||||
sdk.dir=/home/william/android/android-sdk-linux_x86
|
||||
40
Examples/android/class/proguard.cfg
Normal file
40
Examples/android/class/proguard.cfg
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
-optimizationpasses 5
|
||||
-dontusemixedcaseclassnames
|
||||
-dontskipnonpubliclibraryclasses
|
||||
-dontpreverify
|
||||
-verbose
|
||||
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*
|
||||
|
||||
-keep public class * extends android.app.Activity
|
||||
-keep public class * extends android.app.Application
|
||||
-keep public class * extends android.app.Service
|
||||
-keep public class * extends android.content.BroadcastReceiver
|
||||
-keep public class * extends android.content.ContentProvider
|
||||
-keep public class * extends android.app.backup.BackupAgentHelper
|
||||
-keep public class * extends android.preference.Preference
|
||||
-keep public class com.android.vending.licensing.ILicensingService
|
||||
|
||||
-keepclasseswithmembernames class * {
|
||||
native <methods>;
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet);
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet, int);
|
||||
}
|
||||
|
||||
-keepclassmembers class * extends android.app.Activity {
|
||||
public void *(android.view.View);
|
||||
}
|
||||
|
||||
-keepclassmembers enum * {
|
||||
public static **[] values();
|
||||
public static ** valueOf(java.lang.String);
|
||||
}
|
||||
|
||||
-keep class * implements android.os.Parcelable {
|
||||
public static final android.os.Parcelable$Creator *;
|
||||
}
|
||||
11
Examples/android/class/project.properties
Normal file
11
Examples/android/class/project.properties
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must be checked in Version Control Systems.
|
||||
#
|
||||
# To customize properties used by the Ant build system use,
|
||||
# "ant.properties", and override values to adapt the script to your
|
||||
# project structure.
|
||||
|
||||
# Project target.
|
||||
target=android-8
|
||||
25
Examples/android/class/res/layout/main.xml
Normal file
25
Examples/android/class/res/layout/main.xml
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
android:orientation="vertical"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<Button
|
||||
android:id="@+id/RunButton"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
android:text="Run..."
|
||||
android:onClick="onRunButtonClick"
|
||||
/>
|
||||
<ScrollView
|
||||
android:id="@+id/Scroller"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<TextView
|
||||
android:id="@+id/OutputText"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
/>
|
||||
</ScrollView>
|
||||
</LinearLayout>
|
||||
4
Examples/android/class/res/values/strings.xml
Normal file
4
Examples/android/class/res/values/strings.xml
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<resources>
|
||||
<string name="app_name">SwigClass</string>
|
||||
</resources>
|
||||
106
Examples/android/class/src/org/swig/classexample/SwigClass.java
Normal file
106
Examples/android/class/src/org/swig/classexample/SwigClass.java
Normal file
|
|
@ -0,0 +1,106 @@
|
|||
package org.swig.classexample;
|
||||
|
||||
import android.app.Activity;
|
||||
import android.os.Bundle;
|
||||
import android.view.View;
|
||||
import android.widget.Button;
|
||||
import android.widget.TextView;
|
||||
import android.widget.ScrollView;
|
||||
import android.text.method.ScrollingMovementMethod;
|
||||
|
||||
public class SwigClass extends Activity
|
||||
{
|
||||
TextView outputText = null;
|
||||
ScrollView scroller = null;
|
||||
|
||||
/** Called when the activity is first created. */
|
||||
@Override
|
||||
public void onCreate(Bundle savedInstanceState)
|
||||
{
|
||||
super.onCreate(savedInstanceState);
|
||||
setContentView(R.layout.main);
|
||||
|
||||
outputText = (TextView)findViewById(R.id.OutputText);
|
||||
outputText.setText("Press 'Run' to start...\n");
|
||||
outputText.setMovementMethod(new ScrollingMovementMethod());
|
||||
|
||||
scroller = (ScrollView)findViewById(R.id.Scroller);
|
||||
}
|
||||
|
||||
public void onRunButtonClick(View view)
|
||||
{
|
||||
outputText.append("Started...\n");
|
||||
nativeCall();
|
||||
outputText.append("Finished!\n");
|
||||
|
||||
// Ensure scroll to end of text
|
||||
scroller.post(new Runnable() {
|
||||
public void run() {
|
||||
scroller.fullScroll(ScrollView.FOCUS_DOWN);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// ----- Object creation -----
|
||||
|
||||
outputText.append( "Creating some objects:\n" );
|
||||
Circle c = new Circle(10);
|
||||
outputText.append( " Created circle " + c + "\n");
|
||||
Square s = new Square(10);
|
||||
outputText.append( " Created square " + s + "\n");
|
||||
|
||||
// ----- Access a static member -----
|
||||
|
||||
outputText.append( "\nA total of " + Shape.getNshapes() + " shapes were created\n" );
|
||||
|
||||
// ----- Member data access -----
|
||||
|
||||
// Notice how we can do this using functions specific to
|
||||
// the 'Circle' class.
|
||||
c.setX(20);
|
||||
c.setY(30);
|
||||
|
||||
// Now use the same functions in the base class
|
||||
Shape shape = s;
|
||||
shape.setX(-10);
|
||||
shape.setY(5);
|
||||
|
||||
outputText.append( "\nHere is their current position:\n" );
|
||||
outputText.append( " Circle = (" + c.getX() + " " + c.getY() + ")\n" );
|
||||
outputText.append( " Square = (" + s.getX() + " " + s.getY() + ")\n" );
|
||||
|
||||
// ----- Call some methods -----
|
||||
|
||||
outputText.append( "\nHere are some properties of the shapes:\n" );
|
||||
Shape[] shapes = {c,s};
|
||||
for (int i=0; i<shapes.length; i++)
|
||||
{
|
||||
outputText.append( " " + shapes[i].toString() + "\n" );
|
||||
outputText.append( " area = " + shapes[i].area() + "\n" );
|
||||
outputText.append( " perimeter = " + shapes[i].perimeter() + "\n" );
|
||||
}
|
||||
|
||||
// Notice how the area() and perimeter() functions really
|
||||
// invoke the appropriate virtual method on each object.
|
||||
|
||||
// ----- Delete everything -----
|
||||
|
||||
outputText.append( "\nGuess I'll clean up now\n" );
|
||||
|
||||
// Note: this invokes the virtual destructor
|
||||
// You could leave this to the garbage collector
|
||||
c.delete();
|
||||
s.delete();
|
||||
|
||||
outputText.append( Shape.getNshapes() + " shapes remain\n" );
|
||||
outputText.append( "Goodbye\n" );
|
||||
}
|
||||
|
||||
/** static constructor */
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
}
|
||||
15
Examples/android/simple/AndroidManifest.xml
Normal file
15
Examples/android/simple/AndroidManifest.xml
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
package="org.swig.simple"
|
||||
android:versionCode="1"
|
||||
android:versionName="1.0">
|
||||
<application android:label="@string/app_name" >
|
||||
<activity android:name="SwigSimple"
|
||||
android:label="@string/app_name">
|
||||
<intent-filter>
|
||||
<action android:name="android.intent.action.MAIN" />
|
||||
<category android:name="android.intent.category.LAUNCHER" />
|
||||
</intent-filter>
|
||||
</activity>
|
||||
</application>
|
||||
</manifest>
|
||||
29
Examples/android/simple/Makefile
Normal file
29
Examples/android/simple/Makefile
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
TOP = ../..
|
||||
SWIG = $(TOP)/../preinst-swig
|
||||
TARGET = example
|
||||
INTERFACE = example.i
|
||||
PACKAGEDIR = src/org/swig
|
||||
PACKAGENAME= org.swig.simple
|
||||
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/simple
|
||||
PROJECTNAME= SwigSimple
|
||||
TARGETID = 1
|
||||
|
||||
all:: android
|
||||
|
||||
android::
|
||||
android update project --target $(TARGETID) --name $(PROJECTNAME) --path .
|
||||
$(SWIG) -java $(SWIGOPT) -o jni/$(TARGET)_wrap.c jni/$(INTERFACE)
|
||||
ndk-build
|
||||
ant debug
|
||||
|
||||
install::
|
||||
-adb uninstall $(PACKAGENAME)
|
||||
adb install bin/$(PROJECTNAME)-debug.apk
|
||||
|
||||
clean::
|
||||
ant clean
|
||||
rm -f jni/$(TARGET)_wrap.c
|
||||
rm -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
|
||||
|
||||
|
||||
check: all
|
||||
17
Examples/android/simple/ant.properties
Normal file
17
Examples/android/simple/ant.properties
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# This file is used to override default values used by the Ant build system.
|
||||
#
|
||||
# This file must be checked in Version Control Systems, as it is
|
||||
# integral to the build system of your project.
|
||||
|
||||
# This file is only used by the Ant script.
|
||||
|
||||
# You can use this to override default values such as
|
||||
# 'source.dir' for the location of your java source folder and
|
||||
# 'out.dir' for the location of your output folder.
|
||||
|
||||
# You can also use it define how the release builds are signed by declaring
|
||||
# the following properties:
|
||||
# 'key.store' for the location of your keystore and
|
||||
# 'key.alias' for the name of the key to use.
|
||||
# The password will be asked during the build when you use the 'release' target.
|
||||
|
||||
85
Examples/android/simple/build.xml
Normal file
85
Examples/android/simple/build.xml
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project name="SwigSimple" default="help">
|
||||
|
||||
<!-- The local.properties file is created and updated by the 'android' tool.
|
||||
It contains the path to the SDK. It should *NOT* be checked into
|
||||
Version Control Systems. -->
|
||||
<loadproperties srcFile="local.properties" />
|
||||
|
||||
<!-- The ant.properties file can be created by you. It is only edited by the
|
||||
'android' tool to add properties to it.
|
||||
This is the place to change some Ant specific build properties.
|
||||
Here are some properties you may want to change/update:
|
||||
|
||||
source.dir
|
||||
The name of the source directory. Default is 'src'.
|
||||
out.dir
|
||||
The name of the output directory. Default is 'bin'.
|
||||
|
||||
For other overridable properties, look at the beginning of the rules
|
||||
files in the SDK, at tools/ant/build.xml
|
||||
|
||||
Properties related to the SDK location or the project target should
|
||||
be updated using the 'android' tool with the 'update' action.
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems.
|
||||
|
||||
-->
|
||||
<property file="ant.properties" />
|
||||
|
||||
<!-- The project.properties file is created and updated by the 'android'
|
||||
tool, as well as ADT.
|
||||
|
||||
This contains project specific properties such as project target, and library
|
||||
dependencies. Lower level build properties are stored in ant.properties
|
||||
(or in .classpath for Eclipse projects).
|
||||
|
||||
This file is an integral part of the build system for your
|
||||
application and should be checked into Version Control Systems. -->
|
||||
<loadproperties srcFile="project.properties" />
|
||||
|
||||
<!-- quick check on sdk.dir -->
|
||||
<fail
|
||||
message="sdk.dir is missing. Make sure to generate local.properties using 'android update project'"
|
||||
unless="sdk.dir"
|
||||
/>
|
||||
|
||||
|
||||
<!-- extension targets. Uncomment the ones where you want to do custom work
|
||||
in between standard targets -->
|
||||
<!--
|
||||
<target name="-pre-build">
|
||||
</target>
|
||||
<target name="-pre-compile">
|
||||
</target>
|
||||
|
||||
/* This is typically used for code obfuscation.
|
||||
Compiled code location: ${out.classes.absolute.dir}
|
||||
If this is not done in place, override ${out.dex.input.absolute.dir} */
|
||||
<target name="-post-compile">
|
||||
</target>
|
||||
-->
|
||||
|
||||
<!-- Import the actual build file.
|
||||
|
||||
To customize existing targets, there are two options:
|
||||
- Customize only one target:
|
||||
- copy/paste the target into this file, *before* the
|
||||
<import> task.
|
||||
- customize it to your needs.
|
||||
- Customize the whole content of build.xml
|
||||
- copy/paste the content of the rules files (minus the top node)
|
||||
into this file, replacing the <import> task.
|
||||
- customize to your needs.
|
||||
|
||||
***********************
|
||||
****** IMPORTANT ******
|
||||
***********************
|
||||
In all cases you must update the value of version-tag below to read 'custom' instead of an integer,
|
||||
in order to avoid having your file be overridden by tools such as "android update project"
|
||||
-->
|
||||
<!-- version-tag: 1 -->
|
||||
<import file="${sdk.dir}/tools/ant/build.xml" />
|
||||
|
||||
</project>
|
||||
9
Examples/android/simple/jni/Android.mk
Normal file
9
Examples/android/simple/jni/Android.mk
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
# File: Android.mk
|
||||
LOCAL_PATH := $(call my-dir)
|
||||
|
||||
include $(CLEAR_VARS)
|
||||
|
||||
LOCAL_MODULE := example
|
||||
LOCAL_SRC_FILES := example_wrap.c example.c
|
||||
|
||||
include $(BUILD_SHARED_LIBRARY)
|
||||
17
Examples/android/simple/jni/example.c
Normal file
17
Examples/android/simple/jni/example.c
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
/* File : example.c */
|
||||
|
||||
/* A global variable */
|
||||
double Foo = 3.0;
|
||||
|
||||
/* Compute the greatest common divisor of positive integers */
|
||||
int gcd(int x, int y) {
|
||||
int g;
|
||||
g = y;
|
||||
while (x > 0) {
|
||||
g = x;
|
||||
x = y % x;
|
||||
y = g;
|
||||
}
|
||||
return g;
|
||||
}
|
||||
|
||||
7
Examples/android/simple/jni/example.i
Normal file
7
Examples/android/simple/jni/example.i
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
/* File : example.i */
|
||||
%module example
|
||||
|
||||
%inline %{
|
||||
extern int gcd(int x, int y);
|
||||
extern double Foo;
|
||||
%}
|
||||
10
Examples/android/simple/local.properties
Normal file
10
Examples/android/simple/local.properties
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must *NOT* be checked in Version Control Systems,
|
||||
# as it contains information specific to your local configuration.
|
||||
|
||||
# location of the SDK. This is only used by Ant
|
||||
# For customization when using a Version Control System, please read the
|
||||
# header note.
|
||||
sdk.dir=/home/william/android/android-sdk-linux_x86
|
||||
40
Examples/android/simple/proguard.cfg
Normal file
40
Examples/android/simple/proguard.cfg
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
-optimizationpasses 5
|
||||
-dontusemixedcaseclassnames
|
||||
-dontskipnonpubliclibraryclasses
|
||||
-dontpreverify
|
||||
-verbose
|
||||
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*
|
||||
|
||||
-keep public class * extends android.app.Activity
|
||||
-keep public class * extends android.app.Application
|
||||
-keep public class * extends android.app.Service
|
||||
-keep public class * extends android.content.BroadcastReceiver
|
||||
-keep public class * extends android.content.ContentProvider
|
||||
-keep public class * extends android.app.backup.BackupAgentHelper
|
||||
-keep public class * extends android.preference.Preference
|
||||
-keep public class com.android.vending.licensing.ILicensingService
|
||||
|
||||
-keepclasseswithmembernames class * {
|
||||
native <methods>;
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet);
|
||||
}
|
||||
|
||||
-keepclasseswithmembers class * {
|
||||
public <init>(android.content.Context, android.util.AttributeSet, int);
|
||||
}
|
||||
|
||||
-keepclassmembers class * extends android.app.Activity {
|
||||
public void *(android.view.View);
|
||||
}
|
||||
|
||||
-keepclassmembers enum * {
|
||||
public static **[] values();
|
||||
public static ** valueOf(java.lang.String);
|
||||
}
|
||||
|
||||
-keep class * implements android.os.Parcelable {
|
||||
public static final android.os.Parcelable$Creator *;
|
||||
}
|
||||
11
Examples/android/simple/project.properties
Normal file
11
Examples/android/simple/project.properties
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
# This file is automatically generated by Android Tools.
|
||||
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
|
||||
#
|
||||
# This file must be checked in Version Control Systems.
|
||||
#
|
||||
# To customize properties used by the Ant build system use,
|
||||
# "ant.properties", and override values to adapt the script to your
|
||||
# project structure.
|
||||
|
||||
# Project target.
|
||||
target=android-8
|
||||
25
Examples/android/simple/res/layout/main.xml
Normal file
25
Examples/android/simple/res/layout/main.xml
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
android:orientation="vertical"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<Button
|
||||
android:id="@+id/RunButton"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
android:text="Run..."
|
||||
android:onClick="onRunButtonClick"
|
||||
/>
|
||||
<ScrollView
|
||||
android:id="@+id/Scroller"
|
||||
android:layout_width="fill_parent"
|
||||
android:layout_height="fill_parent"
|
||||
>
|
||||
<TextView
|
||||
android:id="@+id/OutputText"
|
||||
android:layout_width="wrap_content"
|
||||
android:layout_height="wrap_content"
|
||||
/>
|
||||
</ScrollView>
|
||||
</LinearLayout>
|
||||
4
Examples/android/simple/res/values/strings.xml
Normal file
4
Examples/android/simple/res/values/strings.xml
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<resources>
|
||||
<string name="app_name">SwigSimple</string>
|
||||
</resources>
|
||||
75
Examples/android/simple/src/org/swig/simple/SwigSimple.java
Normal file
75
Examples/android/simple/src/org/swig/simple/SwigSimple.java
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
package org.swig.simple;
|
||||
|
||||
import android.app.Activity;
|
||||
import android.os.Bundle;
|
||||
import android.view.View;
|
||||
import android.widget.Button;
|
||||
import android.widget.TextView;
|
||||
import android.widget.ScrollView;
|
||||
import android.text.method.ScrollingMovementMethod;
|
||||
|
||||
public class SwigSimple extends Activity
|
||||
{
|
||||
TextView outputText = null;
|
||||
ScrollView scroller = null;
|
||||
|
||||
/** Called when the activity is first created. */
|
||||
@Override
|
||||
public void onCreate(Bundle savedInstanceState)
|
||||
{
|
||||
super.onCreate(savedInstanceState);
|
||||
setContentView(R.layout.main);
|
||||
|
||||
outputText = (TextView)findViewById(R.id.OutputText);
|
||||
outputText.setText("Press 'Run' to start...\n");
|
||||
outputText.setMovementMethod(new ScrollingMovementMethod());
|
||||
|
||||
scroller = (ScrollView)findViewById(R.id.Scroller);
|
||||
}
|
||||
|
||||
public void onRunButtonClick(View view)
|
||||
{
|
||||
outputText.append("Started...\n");
|
||||
nativeCall();
|
||||
outputText.append("Finished!\n");
|
||||
|
||||
// Ensure scroll to end of text
|
||||
scroller.post(new Runnable() {
|
||||
public void run() {
|
||||
scroller.fullScroll(ScrollView.FOCUS_DOWN);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/** Calls into C/C++ code */
|
||||
public void nativeCall()
|
||||
{
|
||||
// Call our gcd() function
|
||||
|
||||
int x = 42;
|
||||
int y = 105;
|
||||
int g = example.gcd(x,y);
|
||||
outputText.append("The greatest common divisor of " + x + " and " + y + " is " + g + "\n");
|
||||
|
||||
// Manipulate the Foo global variable
|
||||
|
||||
// Output its current value
|
||||
double foo = example.getFoo();
|
||||
outputText.append("Foo = " + foo + "\n");
|
||||
|
||||
// Change its value
|
||||
example.setFoo(3.1415926);
|
||||
|
||||
// See if the change took effect
|
||||
outputText.append("Foo = " + example.getFoo() + "\n");
|
||||
|
||||
// Restore value
|
||||
example.setFoo(foo);
|
||||
}
|
||||
|
||||
/** static constructor */
|
||||
static {
|
||||
System.loadLibrary("example");
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -1,99 +1,99 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "Callback.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Caller.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "Callback.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Caller.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,158 +1,158 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -1,104 +1,104 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "Circle.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Shape.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Square.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "Circle.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Shape.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Square.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,158 +1,158 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -1,99 +1,99 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "color.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Foo.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "color.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Foo.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,158 +1,158 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -1,104 +1,104 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "Employee.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "EmployeeList.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Manager.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "Employee.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "EmployeeList.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Manager.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,158 +1,158 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -1,94 +1,94 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_f_int_int__int.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_f_int_int__int.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,160 +1,160 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath=".\example.c">
|
||||
</File>
|
||||
<File
|
||||
RelativePath=".\example_wrap.c">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath=".\example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.c"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.c"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath=".\example.c">
|
||||
</File>
|
||||
<File
|
||||
RelativePath=".\example_wrap.c">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath=".\example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.c"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.c"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -1,99 +1,99 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Vector.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "VectorArray.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "Vector.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "VectorArray.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,158 +1,158 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example.cxx">
|
||||
</File>
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -1,89 +1,89 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,222 +1,222 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="8.00"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj"
|
||||
>
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"
|
||||
/>
|
||||
</Platforms>
|
||||
<ToolFiles>
|
||||
</ToolFiles>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
|
||||
CharacterSet="2"
|
||||
>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="true"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="true"
|
||||
DebugInformationFormat="4"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCManagedResourceCompilerTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="true"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCALinkTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCManifestTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCXDCMakeTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCBscMakeTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCFxCopTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCAppVerifierTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"
|
||||
/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
|
||||
CharacterSet="2"
|
||||
>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="true"
|
||||
DebugInformationFormat="3"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCManagedResourceCompilerTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="true"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCALinkTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCManifestTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCXDCMakeTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCBscMakeTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCFxCopTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCAppVerifierTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"
|
||||
/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
|
||||
>
|
||||
<File
|
||||
RelativePath=".\example.c"
|
||||
>
|
||||
</File>
|
||||
<File
|
||||
RelativePath=".\example_wrap.c"
|
||||
>
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
|
||||
>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i"
|
||||
>
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32"
|
||||
>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -csharp "$(InputPath)"
@echo off
"
|
||||
Outputs="$(InputName)_wrap.c"
|
||||
/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32"
|
||||
>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -csharp "$(InputPath)"
@echo off
"
|
||||
Outputs="$(InputName)_wrap.c"
|
||||
/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="8.00"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj"
|
||||
>
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"
|
||||
/>
|
||||
</Platforms>
|
||||
<ToolFiles>
|
||||
</ToolFiles>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
|
||||
CharacterSet="2"
|
||||
>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="true"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="true"
|
||||
DebugInformationFormat="4"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCManagedResourceCompilerTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="true"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCALinkTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCManifestTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCXDCMakeTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCBscMakeTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCFxCopTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCAppVerifierTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"
|
||||
/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
InheritedPropertySheets="$(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops"
|
||||
CharacterSet="2"
|
||||
>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="true"
|
||||
DebugInformationFormat="3"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCManagedResourceCompilerTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="true"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCALinkTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCManifestTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCXDCMakeTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCBscMakeTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCFxCopTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCAppVerifierTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"
|
||||
/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"
|
||||
/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
|
||||
>
|
||||
<File
|
||||
RelativePath=".\example.c"
|
||||
>
|
||||
</File>
|
||||
<File
|
||||
RelativePath=".\example_wrap.c"
|
||||
>
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
|
||||
>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i"
|
||||
>
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32"
|
||||
>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -csharp "$(InputPath)"
@echo off
"
|
||||
Outputs="$(InputName)_wrap.c"
|
||||
/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32"
|
||||
>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
echo on
..\..\..\swig.exe -csharp "$(InputPath)"
@echo off
"
|
||||
Outputs="$(InputName)_wrap.c"
|
||||
/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,26 +1,26 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 9.00
|
||||
# Visual C++ Express 2005
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfigurationPlatforms) = preSolution
|
||||
Debug|Win32 = Debug|Win32
|
||||
Release|Win32 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfigurationPlatforms) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.ActiveCfg = Debug|Any CPU
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.ActiveCfg = Release|Any CPU
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(SolutionProperties) = preSolution
|
||||
HideSolutionNode = FALSE
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 9.00
|
||||
# Visual C++ Express 2005
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfigurationPlatforms) = preSolution
|
||||
Debug|Win32 = Debug|Win32
|
||||
Release|Win32 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfigurationPlatforms) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug|Win32.ActiveCfg = Debug|Any CPU
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release|Win32.ActiveCfg = Release|Any CPU
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug|Win32.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release|Win32.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(SolutionProperties) = preSolution
|
||||
HideSolutionNode = FALSE
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -1,109 +1,109 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_double.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_int.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "vecdouble.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "vecint.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_double.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_int.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "vecdouble.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "vecint.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,157 +1,157 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath="example_wrap.cxx">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
<File
|
||||
RelativePath="example.h">
|
||||
</File>
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -c++ -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.cxx"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -1,99 +1,99 @@
|
|||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_int.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_Point.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
<VisualStudioProject>
|
||||
<CSHARP
|
||||
ProjectType = "Local"
|
||||
ProductVersion = "7.10.3077"
|
||||
SchemaVersion = "2.0"
|
||||
ProjectGuid = "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
>
|
||||
<Build>
|
||||
<Settings
|
||||
ApplicationIcon = ""
|
||||
AssemblyKeyContainerName = ""
|
||||
AssemblyName = "runme"
|
||||
AssemblyOriginatorKeyFile = ""
|
||||
DefaultClientScript = "JScript"
|
||||
DefaultHTMLPageLayout = "Grid"
|
||||
DefaultTargetSchema = "IE50"
|
||||
DelaySign = "false"
|
||||
OutputType = "Exe"
|
||||
PreBuildEvent = ""
|
||||
PostBuildEvent = ""
|
||||
RootNamespace = "runme"
|
||||
RunPostBuildEvent = "OnBuildSuccess"
|
||||
StartupObject = ""
|
||||
>
|
||||
<Config
|
||||
Name = "Debug"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "DEBUG;TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "true"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "false"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
<Config
|
||||
Name = "Release"
|
||||
AllowUnsafeBlocks = "false"
|
||||
BaseAddress = "285212672"
|
||||
CheckForOverflowUnderflow = "false"
|
||||
ConfigurationOverrideFile = ""
|
||||
DefineConstants = "TRACE"
|
||||
DocumentationFile = ""
|
||||
DebugSymbols = "false"
|
||||
FileAlignment = "4096"
|
||||
IncrementalBuild = "false"
|
||||
NoStdLib = "false"
|
||||
NoWarn = ""
|
||||
Optimize = "true"
|
||||
OutputPath = ".\"
|
||||
RegisterForComInterop = "false"
|
||||
RemoveIntegerChecks = "false"
|
||||
TreatWarningsAsErrors = "false"
|
||||
WarningLevel = "4"
|
||||
/>
|
||||
</Settings>
|
||||
<References/>
|
||||
</Build>
|
||||
<Files>
|
||||
<Include>
|
||||
<File
|
||||
RelPath = "example.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "examplePINVOKE.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "runme.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_int.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
<File
|
||||
RelPath = "SWIGTYPE_p_Point.cs"
|
||||
SubType = "Code"
|
||||
BuildAction = "Compile"
|
||||
/>
|
||||
</Include>
|
||||
</Files>
|
||||
</CSHARP>
|
||||
</VisualStudioProject>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,157 +1,157 @@
|
|||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example-vc"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example-vc.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example-vc.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath=".\example.c">
|
||||
</File>
|
||||
<File
|
||||
RelativePath=".\example_wrap.c">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.c"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.c"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
<?xml version="1.0" encoding="Windows-1252"?>
|
||||
<VisualStudioProject
|
||||
ProjectType="Visual C++"
|
||||
Version="7.10"
|
||||
Name="example"
|
||||
ProjectGUID="{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
Keyword="Win32Proj">
|
||||
<Platforms>
|
||||
<Platform
|
||||
Name="Win32"/>
|
||||
</Platforms>
|
||||
<Configurations>
|
||||
<Configuration
|
||||
Name="Debug|Win32"
|
||||
OutputDirectory="Debug"
|
||||
IntermediateDirectory="Debug"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
Optimization="0"
|
||||
PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
MinimalRebuild="TRUE"
|
||||
BasicRuntimeChecks="3"
|
||||
RuntimeLibrary="1"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="4"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="2"
|
||||
GenerateDebugInformation="TRUE"
|
||||
ProgramDatabaseFile="$(OutDir)/example.pdb"
|
||||
SubSystem="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
<Configuration
|
||||
Name="Release|Win32"
|
||||
OutputDirectory="Release"
|
||||
IntermediateDirectory="Release"
|
||||
ConfigurationType="2"
|
||||
CharacterSet="2">
|
||||
<Tool
|
||||
Name="VCCLCompilerTool"
|
||||
PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;EXAMPLEVC_EXPORTS"
|
||||
RuntimeLibrary="0"
|
||||
UsePrecompiledHeader="0"
|
||||
WarningLevel="3"
|
||||
Detect64BitPortabilityProblems="TRUE"
|
||||
DebugInformationFormat="3"/>
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"/>
|
||||
<Tool
|
||||
Name="VCLinkerTool"
|
||||
OutputFile="example.dll"
|
||||
LinkIncremental="1"
|
||||
GenerateDebugInformation="TRUE"
|
||||
SubSystem="2"
|
||||
OptimizeReferences="2"
|
||||
EnableCOMDATFolding="2"
|
||||
ImportLibrary="$(OutDir)/example.lib"
|
||||
TargetMachine="1"/>
|
||||
<Tool
|
||||
Name="VCMIDLTool"/>
|
||||
<Tool
|
||||
Name="VCPostBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreBuildEventTool"/>
|
||||
<Tool
|
||||
Name="VCPreLinkEventTool"/>
|
||||
<Tool
|
||||
Name="VCResourceCompilerTool"/>
|
||||
<Tool
|
||||
Name="VCWebServiceProxyGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCXMLDataGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCWebDeploymentTool"/>
|
||||
<Tool
|
||||
Name="VCManagedWrapperGeneratorTool"/>
|
||||
<Tool
|
||||
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
|
||||
</Configuration>
|
||||
</Configurations>
|
||||
<References>
|
||||
</References>
|
||||
<Files>
|
||||
<Filter
|
||||
Name="Source Files"
|
||||
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
|
||||
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
|
||||
<File
|
||||
RelativePath=".\example.c">
|
||||
</File>
|
||||
<File
|
||||
RelativePath=".\example_wrap.c">
|
||||
</File>
|
||||
</Filter>
|
||||
<Filter
|
||||
Name="Header Files"
|
||||
Filter="h;hpp;hxx;hm;inl;inc;xsd"
|
||||
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
|
||||
</Filter>
|
||||
<File
|
||||
RelativePath=".\example.i">
|
||||
<FileConfiguration
|
||||
Name="Debug|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.c"/>
|
||||
</FileConfiguration>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32">
|
||||
<Tool
|
||||
Name="VCCustomBuildTool"
|
||||
CommandLine="echo Invoking SWIG...
|
||||
echo on
|
||||
..\..\..\swig.exe -csharp "$(InputPath)"
|
||||
@echo off
|
||||
"
|
||||
Outputs="$(InputName)_wrap.c"/>
|
||||
</FileConfiguration>
|
||||
</File>
|
||||
</Files>
|
||||
<Globals>
|
||||
</Globals>
|
||||
</VisualStudioProject>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
Microsoft Visual Studio Solution File, Format Version 8.00
|
||||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "example-cs", "example-cs.csproj", "{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6} = {C2302635-D489-4678-96B4-70F5309DCBE6}
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "example-vc", "example-vc.vcproj", "{C2302635-D489-4678-96B4-70F5309DCBE6}"
|
||||
ProjectSection(ProjectDependencies) = postProject
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfiguration) = preSolution
|
||||
Debug = Debug
|
||||
Release = Release
|
||||
EndGlobalSection
|
||||
GlobalSection(ProjectConfiguration) = postSolution
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.ActiveCfg = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Debug.Build.0 = Debug|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.ActiveCfg = Release|.NET
|
||||
{C17D27DF-4C57-4625-AEE0-A40C4F48FF1A}.Release.Build.0 = Release|.NET
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.ActiveCfg = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Debug.Build.0 = Debug|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.ActiveCfg = Release|Win32
|
||||
{C2302635-D489-4678-96B4-70F5309DCBE6}.Release.Build.0 = Release|Win32
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityGlobals) = postSolution
|
||||
EndGlobalSection
|
||||
GlobalSection(ExtensibilityAddIns) = postSolution
|
||||
EndGlobalSection
|
||||
EndGlobal
|
||||
|
|
|
|||
|
|
@ -66,6 +66,7 @@ void main() {
|
|||
example.pt = example.ptptr;
|
||||
|
||||
write( "The new value is " );
|
||||
stdout.flush();
|
||||
example.pt_print();
|
||||
writefln( "You should see the value %s", example.Point_print(example.ptptr) );
|
||||
}
|
||||
|
|
|
|||
|
|
@ -24,7 +24,6 @@ func main() {
|
|||
fmt.Println("Just call her \"", e.GetTitle(), "\"")
|
||||
fmt.Println("----------------------")
|
||||
|
||||
|
||||
// Create a new EmployeeList instance. This class does not
|
||||
// have a C++ director wrapper, but can be used freely with
|
||||
// other classes that do.
|
||||
|
|
|
|||
|
|
@ -19,3 +19,4 @@ clean::
|
|||
rm -f $(TARGET).py
|
||||
|
||||
check: all
|
||||
$(MAKE) -f $(TOP)/Makefile octave_run
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ funcptr
|
|||
funcptr2
|
||||
functor
|
||||
operator
|
||||
module_load
|
||||
pointer
|
||||
reference
|
||||
simple
|
||||
|
|
|
|||
|
|
@ -19,3 +19,4 @@ clean::
|
|||
rm -f $(TARGET).py
|
||||
|
||||
check: all
|
||||
$(MAKE) -f $(TOP)/Makefile octave_run
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue