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:
William S Fulton 2005-04-14 21:38:18 +00:00
commit c4dc892c23
7 changed files with 27 additions and 25 deletions

View file

@ -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:

View file

@ -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>

View file

@ -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>

View file

@ -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 -&gt; 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>

View file

@ -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

View file

@ -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>
&gt;&gt;&gt; s = SomeObject()
&gt;&gt;&gt; s.x = [1, 2.5, 5. 10]
&gt;&gt;&gt; s.x = [1, 2.5, 5, 10]
&gt;&gt;&gt; print s.x
_1008fea8_p_float
&gt;&gt;&gt;
@ -3084,7 +3085,7 @@ descriptor name for any C datatype. For example:
%typemap(in) Foo * {
if ((SWIG_ConvertPtr($input, (void **) &amp;$1, $1_descriptor)) == -1) {
Bar *temp;
if ((SWIG_ConvertPtr($input), (void **) &amp;temp, <b>$descriptor(Bar *)</b>) == -1) {
if ((SWIG_ConvertPtr($input, (void **) &amp;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;
}
}

View file

@ -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) {