Documentation patches from Mark Goodman
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@7154 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
parent
7bb7e6d19d
commit
c4dc892c23
7 changed files with 27 additions and 25 deletions
|
|
@ -656,7 +656,7 @@ The following are all equivalent:
|
|||
</div>
|
||||
|
||||
<p>
|
||||
The syntax in the first variation will generate the <tt>{ }</tt> delimeters used whereas the other variations will not.
|
||||
The syntax in the first variation will generate the <tt>{ }</tt> delimiters used whereas the other variations will not.
|
||||
The <tt>%feature</tt> directive also accepts XML style attributes in the same way that typemaps will.
|
||||
Any number of attributes can be specified.
|
||||
The following is the generic syntax for features:
|
||||
|
|
|
|||
|
|
@ -915,7 +915,7 @@ public interface exampleConstants {
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
The <tt>%javaconst(flag)</tt> and <tt>%javaconst(value)</tt> directive introduced in the previous section on constants can also be used with enums.
|
||||
The <tt>%javaconst(flag)</tt> and <tt>%javaconstvalue(value)</tt> directive introduced in the previous section on constants can also be used with enums.
|
||||
As is the case for constants, the default is <tt>%javaconst(0)</tt> as not all C values will compile as Java code.
|
||||
However, it is strongly recommended to add in a <tt>%javaconst(1)</tt> directive at the top of your
|
||||
interface file as it is only on very rare occasions that this will produce code that won't compile under Java.
|
||||
|
|
@ -968,7 +968,7 @@ enum Beverage { ALE, LAGER=10, STOUT, PILSNER };
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>and</p>
|
||||
<p>will generate:</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
|
|
@ -2992,7 +2992,7 @@ The %feature directive can be applied globally, to specific classes, and to spec
|
|||
// generate directors for all classes that have virtual methods
|
||||
%feature("director");
|
||||
|
||||
// genarate directors for all virtual methods in class Foo
|
||||
// generate directors for all virtual methods in class Foo
|
||||
%feature("director") Foo;
|
||||
|
||||
// generate a director for just Foo::bar()
|
||||
|
|
@ -5685,7 +5685,7 @@ $ java main
|
|||
|
||||
<p>
|
||||
SWIG support for polymorphism works in that the appropriate virtual function is called. However, the default generated code does not allow for downcasting.
|
||||
Let's examine this with the follow code:
|
||||
Let's examine this with the following code:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -6033,9 +6033,9 @@ public static void MyClass_method_upcall(MyClass self, long jarg1)
|
|||
}
|
||||
</pre>
|
||||
</div>
|
||||
<p>Unfortunately, this loses the Java type information that is part of the underlying Foo director proxy class's java object pointer causing the type cast to fail.
|
||||
<p>Unfortunately, this loses the Java type information that is part of the underlying Foo director proxy class's Java object pointer causing the type cast to fail.
|
||||
The SWIG Java module's director code attempts to correct the problem, <b>but only for director-enabled classes</b>, since the director class retains a global reference to its Java object.
|
||||
Thus, for director-enabled classes <b>and only for director-enabled classes</b>, the generated proxy Java code looks somthing like:
|
||||
Thus, for director-enabled classes <b>and only for director-enabled classes</b>, the generated proxy Java code looks something like:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -6121,7 +6121,7 @@ public class MyClassDerived extends MyClass {
|
|||
/* ... */
|
||||
public void method_upcall(Foo foo_object)
|
||||
{
|
||||
FooDerived derived = FooDerived.downcastFooDerived(foo_object) : null);
|
||||
FooDerived derived = FooDerived.downcastFooDerived(foo_object);
|
||||
/* rest of your code here */
|
||||
}
|
||||
}
|
||||
|
|
@ -6326,7 +6326,7 @@ and as usual this function is wrapped by another which for a global C function w
|
|||
<p>
|
||||
The <tt>packageName</tt> and <tt>moduleName</tt> must of course be correct else you will get linker errors when the JVM dynamically loads the JNI function.
|
||||
You may have to add in some "jtype", "jstype", "javain" and "javaout" typemaps when wrapping some JNI types.
|
||||
Here the default typemaps work for for <tt>int</tt> and <tt>char *</tt>.
|
||||
Here the default typemaps work for <tt>int</tt> and <tt>char *</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -425,13 +425,13 @@ interface is as follows:
|
|||
<div class="code">
|
||||
<pre>
|
||||
struct name {
|
||||
name(int nelements); // Create an array
|
||||
~name(); // Delete array
|
||||
type getitem(int index); // Return item
|
||||
void setitem(index, type value); // Set item
|
||||
type *cast(); // Cast to original type
|
||||
static name *frompointer(type *); // Create class wrapper from
|
||||
// existing pointer
|
||||
name(int nelements); // Create an array
|
||||
~name(); // Delete array
|
||||
type getitem(int index); // Return item
|
||||
void setitem(int index, type value); // Set item
|
||||
type *cast(); // Cast to original type
|
||||
static name *frompointer(type *); // Create class wrapper from
|
||||
// existing pointer
|
||||
};
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -731,7 +731,7 @@ Generates the following function for extracting C data for a given type.
|
|||
|
||||
<div class="code">
|
||||
<pre>
|
||||
char *cdata_<em>name</em>(int nitems)
|
||||
char *cdata_<em>name</em>(type* ptr, int nitems)
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -3196,7 +3196,7 @@ to names. For example:
|
|||
<div class="code">
|
||||
<pre>
|
||||
double x = math::sin(1.0);
|
||||
double magitude(math::Complex *c);
|
||||
double magnitude(math::Complex *c);
|
||||
math::Complex c;
|
||||
...
|
||||
</pre>
|
||||
|
|
@ -3544,7 +3544,7 @@ instance, suppose you had an interface like this:
|
|||
namespace foo {
|
||||
class bar;
|
||||
class spam {
|
||||
public;
|
||||
public:
|
||||
...
|
||||
operator bar(); // Conversion of spam -> bar
|
||||
...
|
||||
|
|
@ -4402,7 +4402,7 @@ can be used (if necessary) to address some of the more tricky memory management
|
|||
|
||||
|
||||
<p>
|
||||
Language specific details on proxy classes are contained the chapters describing each target language. This
|
||||
Language specific details on proxy classes are contained in the chapters describing each target language. This
|
||||
chapter has merely introduced the topic in a very general way.
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -259,7 +259,7 @@ Vector *new_Vector();
|
|||
void delete_Vector(Vector *v);
|
||||
double Vector_x_get(Vector *v);
|
||||
double Vector_y_get(Vector *v);
|
||||
double Vector_y_get(Vector *v);
|
||||
double Vector_z_get(Vector *v);
|
||||
void Vector_x_set(Vector *v, double x);
|
||||
void Vector_y_set(Vector *v, double y);
|
||||
void Vector_z_set(Vector *v, double z);
|
||||
|
|
@ -372,7 +372,7 @@ gcc -c example.c example_wrap.c -I/usr/local/include
|
|||
ld -G example.o example_wrap.o -o example.so
|
||||
|
||||
# Build a shared library for Linux
|
||||
agcc -fpic -c example.c example_wrap.c -I/usr/local/include
|
||||
gcc -fpic -c example.c example_wrap.c -I/usr/local/include
|
||||
gcc -shared example.o example_wrap.o -o example.so
|
||||
|
||||
# Build a shared library for Irix
|
||||
|
|
|
|||
|
|
@ -2380,6 +2380,7 @@ as shown. To work with heap allocated data, the following technique can be use
|
|||
$1[i] = (float) PyFloat_AsDouble(o);
|
||||
} else {
|
||||
PyErr_SetString(PyExc_ValueError,"Sequence elements must be numbers");
|
||||
free($1);
|
||||
return NULL;
|
||||
}
|
||||
}
|
||||
|
|
@ -2465,7 +2466,7 @@ can be set nicely, but reading the member simply returns a pointer:
|
|||
<div class="targetlang">
|
||||
<pre>
|
||||
>>> s = SomeObject()
|
||||
>>> s.x = [1, 2.5, 5. 10]
|
||||
>>> s.x = [1, 2.5, 5, 10]
|
||||
>>> print s.x
|
||||
_1008fea8_p_float
|
||||
>>>
|
||||
|
|
@ -3084,7 +3085,7 @@ descriptor name for any C datatype. For example:
|
|||
%typemap(in) Foo * {
|
||||
if ((SWIG_ConvertPtr($input, (void **) &$1, $1_descriptor)) == -1) {
|
||||
Bar *temp;
|
||||
if ((SWIG_ConvertPtr($input), (void **) &temp, <b>$descriptor(Bar *)</b>) == -1) {
|
||||
if ((SWIG_ConvertPtr($input, (void **) &temp, <b>$descriptor(Bar *)</b>) == -1) {
|
||||
return NULL;
|
||||
}
|
||||
$1 = (Foo *) temp;
|
||||
|
|
@ -3587,6 +3588,7 @@ in a tremendous amount of code bloat. For example, consider this typemap for an
|
|||
$1[i] = (float) PyFloat_AsDouble(o);
|
||||
} else {
|
||||
PyErr_SetString(PyExc_ValueError,"Sequence elements must be numbers");
|
||||
free(result);
|
||||
return NULL;
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ example:
|
|||
<pre>
|
||||
List make_list(const char *s, ...) {
|
||||
va_list ap;
|
||||
List *x = new List();
|
||||
List x;
|
||||
...
|
||||
va_start(ap, s);
|
||||
while (s) {
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue