Fix lots of typos in the manual.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@9368 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Olly Betts
parent
4b72de7d62
commit
05ff62fcc2
17 changed files with 53 additions and 53 deletions
|
|
@ -64,7 +64,7 @@ please use the <a href="Java.html#Java">Java documentation</a> as a guide to usi
|
|||
The C# module has the same major SWIG features as the Java module.
|
||||
The rest of this section should be read in conjunction with the Java documentation as it lists the main differences.
|
||||
|
||||
The most noteable differences to Java are the following:
|
||||
The most notable differences to Java are the following:
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
|
|
@ -257,7 +257,7 @@ Note that the <tt>DllImport</tt> attribute is always generated, irrespective of
|
|||
</p>
|
||||
|
||||
<p>
|
||||
These attributes are associated with the C/C++ parameter type or return type, which is subtely different to
|
||||
These attributes are associated with the C/C++ parameter type or return type, which is subtly different to
|
||||
the attribute features and typemaps covered next.
|
||||
Note that all these different C# attributes can be combined so that a method has more than one attribute.
|
||||
</p>
|
||||
|
|
@ -380,7 +380,7 @@ However anyone wishing to do this should be familiar with the contents of the se
|
|||
|
||||
<p>
|
||||
Unfortunately a C# exception cannot simply be thrown from unmanaged code for a variety of reasons.
|
||||
Most noteably being that throwing a C# exception results in exceptions being thrown across the C PInvoke interface and C does not understand exceptions.
|
||||
Most notably being that throwing a C# exception results in exceptions being thrown across the C PInvoke interface and C does not understand exceptions.
|
||||
The design revolves around a C# exception being constructed and stored as a pending exception, to be thrown only when the unmanaged code has completed.
|
||||
Implementing this is a tad involved and there are thus some unusual typemap constructs.
|
||||
Some practical examples follow and they should be read in conjunction with the rest of this section.
|
||||
|
|
|
|||
|
|
@ -321,7 +321,7 @@
|
|||
<p>
|
||||
|
||||
Primitive symbols and functions (the interface that would be presented if
|
||||
-proxy was not passed) are hidden and no longer accessable. If the -unhideprimitive
|
||||
-proxy was not passed) are hidden and no longer accessible. If the -unhideprimitive
|
||||
command line argument is passed to SWIG, then the primitive symbols will be
|
||||
available, but each will be prefixed by the string "primitive:"
|
||||
|
||||
|
|
@ -379,7 +379,7 @@ $ csc -sv example.scm example_wrap.c example_impl.c -o example.so
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>The <tt>exmaple.so</tt> file can then linked with <tt>test_script.scm</tt> when it
|
||||
<p>The <tt>example.so</tt> file can then linked with <tt>test_script.scm</tt> when it
|
||||
is compiled, in which case <tt>test_script.scm</tt> must have <code>(declare (uses example))</code>.
|
||||
Multiple SWIG modules could have been linked into <tt>example.so</tt> and each
|
||||
one accessed with a <code>(declare (uses ... ))</code>.
|
||||
|
|
@ -441,7 +441,7 @@ $ csc -sv mod_load.scm mod1.scm mod2.scm mod1_wrap.c mod2_wrap.c mod1_impl.c mod
|
|||
</div>
|
||||
|
||||
<p>Then the extension library can be loaded with <code>(require 'mod)</code>. As we can see here,
|
||||
<tt>mod_load.scm</tt> contains the code that gets exectued when the module is loaded. All this code
|
||||
<tt>mod_load.scm</tt> contains the code that gets executed when the module is loaded. All this code
|
||||
does is load both mod1 and mod2. As we can see, this technique is more useful when you want to
|
||||
combine a few SWIG modules into one chicken extension library, especially if modules are related by
|
||||
<code>%import</code></p>
|
||||
|
|
|
|||
|
|
@ -3117,7 +3117,7 @@ the code, ping me and I'll expand on this further. --ttn]
|
|||
<dd>
|
||||
|
||||
<p>
|
||||
Some of the variables AC_SUBSTitutued are essential to the
|
||||
Some of the variables AC_SUBSTituted are essential to the
|
||||
support of your language module. Fashion these into a shell script
|
||||
"test" clause and assign that to a skip tag using "-z" and "-o":
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -441,7 +441,7 @@ smart and that tools should just stay out of their way. Because of
|
|||
that, you will find that SWIG is extremely permissive in what it lets
|
||||
you get away with. In fact, you can use SWIG to go well beyond
|
||||
"shooting yourself in the foot" if dangerous programming is your goal.
|
||||
On the other hand, this kind of freedoom may be exactly what is needed
|
||||
On the other hand, this kind of freedom may be exactly what is needed
|
||||
to work with complicated and unusual C/C++ applications.
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -844,7 +844,7 @@ Be careful using the <tt>%javaconst(1)</tt> directive as not all C code will com
|
|||
The example demonstrates how you can target particular constants (<tt>BIG</tt> and <tt>LARGE</tt>) with <tt>%javaconst</tt>.
|
||||
SWIG doesn't use <tt>%javaconst(1)</tt> as the default as it tries to generate code that will always compile.
|
||||
However, using a <tt>%javaconst(1)</tt> at the top of your interface file is strongly recommended as the preferred compile time constants
|
||||
will be generated and most C constants will compile as Java code and in anycase the odd constant that doesn't can be fixed using <tt>%javaconst(0)</tt>.
|
||||
will be generated and most C constants will compile as Java code and in any case the odd constant that doesn't can be fixed using <tt>%javaconst(0)</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -2008,7 +2008,7 @@ In the previous section, a high-level view of Java wrapping was
|
|||
presented. A key component of this wrapping is that structures and
|
||||
classes are wrapped by Java proxy classes and type wrapper classes are used
|
||||
in situations where no proxies are generated. This provides a very
|
||||
natural, type safe Java interface to the C/C++ code and fits in with the Java programing paradigm.
|
||||
natural, type safe Java interface to the C/C++ code and fits in with the Java programming paradigm.
|
||||
However, a number of low-level details were omitted. This section provides a brief overview
|
||||
of how the proxy classes work and then covers the type wrapper classes.
|
||||
Finally enum classes are covered.
|
||||
|
|
@ -2194,7 +2194,7 @@ The <tt>jniclasscode</tt> pragma is quite useful for adding in a static block fo
|
|||
</div>
|
||||
|
||||
<p>
|
||||
Pragmas will take either <tt>""</tt> or <tt>%{ %}</tt> as delimeters.
|
||||
Pragmas will take either <tt>""</tt> or <tt>%{ %}</tt> as delimiters.
|
||||
For example, let's change the intermediary JNI class access to public.
|
||||
</p>
|
||||
|
||||
|
|
@ -2668,7 +2668,7 @@ Some not so ideal solutions are:
|
|||
|
||||
<ol>
|
||||
<li><p>
|
||||
Call the <tt>System.runFinalizersOnExit(true)</tt> or <tt>Runtime.getRuntime().runFinalizersOnExit(true)</tt> to ensure the finalizers are called before the program exits. The catch is that this is a deprecated function call as the documenation says: </p>
|
||||
Call the <tt>System.runFinalizersOnExit(true)</tt> or <tt>Runtime.getRuntime().runFinalizersOnExit(true)</tt> to ensure the finalizers are called before the program exits. The catch is that this is a deprecated function call as the documentation says: </p>
|
||||
<div class="code"><i>
|
||||
This method is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock.
|
||||
</i></div>
|
||||
|
|
@ -2694,7 +2694,7 @@ As the the shutdown hook is guaranteed you could also make a JNI call to clean u
|
|||
|
||||
<li>
|
||||
<p>Call the <tt>delete()</tt> function manually which will immediately invoke the C++ destructor.
|
||||
As a suggestion it may be a good idea to set the object to null so that should the object be inadvertantly used again a Java null pointer exception is thrown, the alternative would crash the JVM by using a null C pointer.
|
||||
As a suggestion it may be a good idea to set the object to null so that should the object be inadvertently used again a Java null pointer exception is thrown, the alternative would crash the JVM by using a null C pointer.
|
||||
For example given a SWIG generated class A:</p>
|
||||
<div class="code"><pre>
|
||||
A myA = new A();
|
||||
|
|
@ -3172,7 +3172,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 marshall and convert arguments between C++ and Java when needed.
|
||||
Naturally, the SWIG generated C++ code and the generated Java intermediate class marshal and convert arguments between C++ and Java when needed.
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -5394,7 +5394,7 @@ bool calculate(float first, float second);
|
|||
</div>
|
||||
|
||||
<p>
|
||||
To validate every <tt>float</tt> being passed to C++, we could preceed the code being wrapped by the following typemap which throws a runtime exception whenever the <tt>float</tt> is 'Not a Number':
|
||||
To validate every <tt>float</tt> being passed to C++, we could precede the code being wrapped by the following typemap which throws a runtime exception whenever the <tt>float</tt> is 'Not a Number':
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -5440,7 +5440,7 @@ public class example {
|
|||
|
||||
<p>
|
||||
Note that the "javain" typemap is used for every occurrence of a <tt>float</tt> being used as an input.
|
||||
Of course, we could have targetted the typemap at a particular parameter by using <tt>float first</tt>, say, instead of just <tt>float</tt>.
|
||||
Of course, we could have targeted the typemap at a particular parameter by using <tt>float first</tt>, say, instead of just <tt>float</tt>.
|
||||
If we decide that what we actually want is a checked exception instead of a runtime exception, we can change this easily enough.
|
||||
The proxy method that uses <tt>float</tt> as an input, must then add the exception class to the throws clause.
|
||||
SWIG can handle this as it supports the 'throws' <a href="#typemap_attributes">typemap attribute</a> for specifying classes for the throws clause.
|
||||
|
|
@ -6632,7 +6632,7 @@ public static void MyClass_method_upcall(MyClass self, long jarg1,
|
|||
</p>
|
||||
|
||||
<p>
|
||||
The current "type symmetry" design will work for simple C++ inheritance, but will most likely fail for anything more compicated such as tree or diamond C++ inheritance hierarchies.
|
||||
The current "type symmetry" design will work for simple C++ inheritance, but will most likely fail for anything more complicated such as tree or diamond C++ inheritance hierarchies.
|
||||
Those who are interested in challenging problems are more than welcome to hack the <code>Java::Java_director_declaration</code> method in <code>Source/Modules/java.cxx</code>.
|
||||
</p>
|
||||
<p>
|
||||
|
|
@ -6679,7 +6679,7 @@ public class FooDerived extends Foo {
|
|||
}
|
||||
|
||||
catch (ClassCastException exc) {
|
||||
// Wasn't a FooDerived object, some other sublcass of Foo
|
||||
// Wasn't a FooDerived object, some other subclass of Foo
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
|
@ -6730,7 +6730,7 @@ public abstract class UserVisibleFoo extends Foo {
|
|||
}
|
||||
|
||||
catch (ClassCastException exc) {
|
||||
// Wasn't a FooDerived object, some other sublcass of Foo
|
||||
// Wasn't a FooDerived object, some other subclass of Foo
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1645,7 +1645,7 @@ void foo(vector<int> *x, const Vector &x);
|
|||
|
||||
<p>
|
||||
<b>Note:</b> This module makes use of several advanced SWIG features including templatized typemaps
|
||||
and template partial specialization. If you are tring to wrap other C++ code with templates, you
|
||||
and template partial specialization. If you are trying to wrap other C++ code with templates, you
|
||||
might look at the code contained in <tt>std_vector.i</tt>. Alternatively, you can show them the code
|
||||
if you want to make their head explode.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ to high level scripting languages like Python.
|
|||
Although scripting languages are designed
|
||||
to make programming life easier
|
||||
by hiding machine internals from the programmer
|
||||
there are several aspects of todays scripting languages
|
||||
there are several aspects of today's scripting languages
|
||||
that are unfavourable in my opinion.
|
||||
</p>
|
||||
|
||||
|
|
@ -579,7 +579,7 @@ Disable generation of interfaces and wrappers.
|
|||
Instead generate suggestions for <tt>%rename</tt>.
|
||||
<br>
|
||||
C libraries use a naming style
|
||||
that is neither homogenous nor similar to that of Modula-3.
|
||||
that is neither homogeneous nor similar to that of Modula-3.
|
||||
C function names often contain a prefix denoting the library
|
||||
and some name components separated by underscores
|
||||
or capitalization changes.
|
||||
|
|
|
|||
|
|
@ -63,13 +63,13 @@
|
|||
support of Ocaml. Ocaml is a relatively recent addition to the ML family,
|
||||
and is a recent addition to SWIG. It's the second compiled, typed
|
||||
language to be added. Ocaml has widely acknowledged benefits for engineers,
|
||||
mostly derived from a sophistocated type system, compile-time checking
|
||||
mostly derived from a sophisticated type system, compile-time checking
|
||||
which eliminates several classes of common programming errors, and good
|
||||
native performance. While all of this is wonderful, there are well-written
|
||||
C and C++ libraries that Ocaml users will want to take advantage of as
|
||||
part of their arsenal (such as SSL and gdbm), as well as their own mature
|
||||
C and C++ code. SWIG allows this code to be used in a natural, type-safe
|
||||
way with Ocaml, by providing the necessary, but repetetive glue code
|
||||
way with Ocaml, by providing the necessary, but repetitive glue code
|
||||
which creates and uses Ocaml values to communicate with C and C++ code.
|
||||
In addition, SWIG also produces the needed Ocaml source that binds
|
||||
variants, functions, classes, etc.
|
||||
|
|
@ -264,7 +264,7 @@ Most code meant to be compiled as C++ will not have problems.
|
|||
|
||||
<p>
|
||||
In order to provide access to overloaded functions, and
|
||||
provide sensible outputs from them, all C entites are represented as
|
||||
provide sensible outputs from them, all C entities are represented as
|
||||
members of the c_obj type:
|
||||
</p>
|
||||
|
||||
|
|
@ -338,7 +338,7 @@ is that you must append them to the return list with swig_result = caml_list_a
|
|||
]). This is in order to make return values easier to handle
|
||||
when functions have only one return value, such as constructors,
|
||||
and operators. In addition, string, pointer, and object
|
||||
values are interchangable with respect to caml_ptr_val, so you can
|
||||
values are interchangeable with respect to caml_ptr_val, so you can
|
||||
allocate memory as caml strings and still use the resulting
|
||||
pointers for C purposes, even using them to construct simple objects
|
||||
on. Note, though, that foreign C++ code does not respect the garbage
|
||||
|
|
@ -518,7 +518,7 @@ since the object can provide bounds checking, etc., that prevents crashes.
|
|||
|
||||
<p>
|
||||
Consider writing an object when the ending condition of your array is complex,
|
||||
such as using a required centinel, etc.
|
||||
such as using a required sentinel, etc.
|
||||
</p>
|
||||
|
||||
<H4><a name="Ocaml_nn16"></a>25.2.3.4 Example typemap for a function taking float * and int</H4>
|
||||
|
|
@ -809,7 +809,7 @@ certain function, all you need to do is to define the function that will
|
|||
handle the method calls in terms of the public methods of the object, and
|
||||
any other relevant information. The function <tt>new_derived_object</tt>
|
||||
uses a stub class to call your methods in place of the ones provided by the
|
||||
underlying implemenation. The object you receive is the underlying object,
|
||||
underlying implementation. The object you receive is the underlying object,
|
||||
so you are free to call any methods you want from within your derived method.
|
||||
Note that calls to the underlying object do not invoke Ocaml code. You need
|
||||
to handle that yourself.
|
||||
|
|
@ -970,7 +970,7 @@ to receive a value from the called function, as well as sending one there.
|
|||
Sometimes, this is the main purpose of the argument given. <tt>directorargout</tt>
|
||||
typemaps allow your caml code to emulate this by specifying additional return
|
||||
values to be put into the output parameters. The SWIG ocaml module is a bit
|
||||
loose in order to make code eaiser to write. In this case, your return to
|
||||
loose in order to make code easier to write. In this case, your return to
|
||||
the caller must be a list containing the normal function return first, followed
|
||||
by any argout values in order. These argout values will be taken from the
|
||||
list and assigned to the values to be returned to C++ through directorargout typemaps.
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ loaded, an easy way to find out is to run Perl itself.
|
|||
<p>
|
||||
The preferred approach to building an extension module is to compile it into
|
||||
a shared object file or DLL. To do this, you will need to compile your program
|
||||
using comands like this (shown for Linux):
|
||||
using commands like this (shown for Linux):
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -275,7 +275,7 @@ The same thing can be accomplished by running SWIG as follows :</p>
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
The <tt>permain.i</tt> file inserts Perl's <tt>main()</tt> function
|
||||
The <tt>perlmain.i</tt> file inserts Perl's <tt>main()</tt> function
|
||||
into the wrapper code and automatically initializes the SWIG generated
|
||||
module. If you just want to make a quick a dirty module, this may be
|
||||
the easiest way. By default, the <tt>perlmain.i</tt> code does not
|
||||
|
|
@ -567,7 +567,7 @@ can behave strangely when working with multiple modules.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
It should be noted that you may get alot of error messages
|
||||
It should be noted that you may get a lot of error messages
|
||||
about the `<tt>bool</tt>' datatype when compiling a C++ Perl module. If
|
||||
you experience this problem, you can try the following :</p>
|
||||
|
||||
|
|
@ -1178,7 +1178,7 @@ void spam(Foo *f);
|
|||
|
||||
<p>
|
||||
then the function <tt>spam()</tt> accepts <tt>Foo *</tt> or a pointer to any class derived from <tt>Foo</tt>.
|
||||
If necesssary, the type-checker also adjusts the value of the pointer (as is necessary when
|
||||
If necessary, the type-checker also adjusts the value of the pointer (as is necessary when
|
||||
multiple inheritance is used).
|
||||
</p>
|
||||
|
||||
|
|
@ -1272,7 +1272,7 @@ print example::fact(4),"\n" # Call a function in it
|
|||
<p>
|
||||
Usually, a module consists of a collection of code that is contained
|
||||
within a single file. A package, on the other hand, is the Perl
|
||||
equivalent of a namespace. A package is alot like a module, except
|
||||
equivalent of a namespace. A package is a lot like a module, except
|
||||
that it is independent of files. Any number of files may be part of
|
||||
the same package--or a package may be broken up into a collection of
|
||||
modules if you prefer to think about it in this way.
|
||||
|
|
@ -1813,7 +1813,7 @@ int count(char c, char *str, unsigned len);
|
|||
<p>
|
||||
When a multi-argument typemap is defined, the arguments are always handled as a single
|
||||
Perl object. This allows the function to be used like this (notice how the length
|
||||
parameter is ommitted):
|
||||
parameter is omitted):
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
|
|
@ -2009,7 +2009,7 @@ When writing typemaps, it is necessary to work directly with Perl5
|
|||
objects. This, unfortunately, can be a daunting task. Consult the
|
||||
"perlguts" man-page for all of the really ugly details. A short
|
||||
summary of commonly used functions is provided here for reference. It
|
||||
should be stressed that SWIG can be usef quite effectively without
|
||||
should be stressed that SWIG can be used quite effectively without
|
||||
knowing any of these details--especially now that there are typemap
|
||||
libraries that can already been written.
|
||||
</p>
|
||||
|
|
@ -2684,7 +2684,7 @@ In fact, it will fail if you create a new C object in Perl, pass it on
|
|||
to a C function that remembers the object, and then destroy the
|
||||
corresponding Perl object (this situation turns out to come up
|
||||
frequently when constructing objects like linked lists and trees).
|
||||
When C takes possession of an object, you can change Perl's owership
|
||||
When C takes possession of an object, you can change Perl's ownership
|
||||
by simply deleting the object from the <tt>%OWNER</tt> hash. This is
|
||||
done using the <tt>DISOWN </tt>method.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ is not necessary to use include-guards in SWIG interfaces.
|
|||
By default, the <tt>#include</tt> is ignored unless you run SWIG with the
|
||||
<tt>-includeall</tt> option. The reason for ignoring traditional includes
|
||||
is that you often don't want SWIG to try and wrap everything included
|
||||
in standard header system headers and auxilliary files.
|
||||
in standard header system headers and auxiliary files.
|
||||
|
||||
<H2><a name="Preprocessor_nn3"></a>7.2 File imports</H2>
|
||||
|
||||
|
|
|
|||
|
|
@ -1285,7 +1285,7 @@ irb(main):003:0> <b>puts foo.value</b></pre>
|
|||
<H3><a name="Ruby_nn36"></a>30.6.3 Exception classes </H3>
|
||||
|
||||
|
||||
<p>Starting with SWIG 1.3.28, the Ruby module supports the <tt>%exceptionclass</tt> directive, which is used to identify C++ classes that are used as exceptions. Classes that are marked with the <tt>%exceptionclass</tt> directive are exposed in Ruby as child classes of <tt>rb_eRuntimeError</tt>. This alows C++ exceptions to be directly mapped to Ruby exceptions, providing for a more natural integration between C++ code and Ruby code.</p>
|
||||
<p>Starting with SWIG 1.3.28, the Ruby module supports the <tt>%exceptionclass</tt> directive, which is used to identify C++ classes that are used as exceptions. Classes that are marked with the <tt>%exceptionclass</tt> directive are exposed in Ruby as child classes of <tt>rb_eRuntimeError</tt>. This allows C++ exceptions to be directly mapped to Ruby exceptions, providing for a more natural integration between C++ code and Ruby code.</p>
|
||||
<div class="code">
|
||||
<pre> %exceptionclass CustomError;
|
||||
|
||||
|
|
|
|||
|
|
@ -1830,7 +1830,7 @@ constants in the target scripting language. This allows you to use them as foll
|
|||
</div>
|
||||
|
||||
<p>
|
||||
Unfortunately, by declaring the callback functions as constants, they are no longer accesible
|
||||
Unfortunately, by declaring the callback functions as constants, they are no longer accessible
|
||||
as functions. For example:
|
||||
</p>
|
||||
|
||||
|
|
@ -2335,7 +2335,7 @@ typedef struct {
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
You can make a <tt>Vector</tt> look alot like a class by writing a SWIG interface like this:
|
||||
You can make a <tt>Vector</tt> look a lot like a class by writing a SWIG interface like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -2471,7 +2471,7 @@ const double Vector_magnitude_get(Vector *v) {
|
|||
</div>
|
||||
|
||||
<p>
|
||||
Now, for all practial purposes, <tt>magnitude</tt> will appear like an attribute
|
||||
Now, for all practical purposes, <tt>magnitude</tt> will appear like an attribute
|
||||
of the object.
|
||||
</p>
|
||||
|
||||
|
|
@ -2940,7 +2940,7 @@ are several reasons why you might want to do this:
|
|||
<ul>
|
||||
<li>It is rarely necessary to access every single function in a large
|
||||
package. Many C functions might have little or no use in a scripted
|
||||
environment. Therfore, why wrap them?
|
||||
environment. Therefore, why wrap them?
|
||||
|
||||
<li>Separate interface files provide an opportunity to provide more
|
||||
precise rules about how an interface is to be constructed.
|
||||
|
|
|
|||
|
|
@ -2276,7 +2276,7 @@ also apply to <tt>%ignore</tt>. For example:
|
|||
</div>
|
||||
|
||||
<p>
|
||||
When applied to a base class, <tt>%ignore</tt> forces all definitions in derived clases
|
||||
When applied to a base class, <tt>%ignore</tt> forces all definitions in derived classes
|
||||
to disappear. For example, <tt>%ignore Spam::foo(double)</tt> will eliminate <tt>foo(double)</tt> in
|
||||
<tt>Spam</tt> and all classes derived from <tt>Spam</tt>.
|
||||
</p>
|
||||
|
|
@ -3082,7 +3082,7 @@ Don't worry--if you get the order wrong, SWIG should generate a warning message.
|
|||
</p>
|
||||
|
||||
<p>
|
||||
Occassionally, you may need to tell SWIG about base classes that are defined by templates,
|
||||
Occasionally, you may need to tell SWIG about base classes that are defined by templates,
|
||||
but which aren't supposed to be wrapped. Since SWIG is not able to automatically
|
||||
instantiate templates for this purpose, you must do it manually. To do this, simply
|
||||
use <tt>%template</tt> with no name. For example:
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ different.</p>
|
|||
<p>
|
||||
Variable linking refers to the problem of mapping a
|
||||
C/C++ global variable to a variable in the scripting
|
||||
language interpeter. For example, suppose you had the following
|
||||
language interpreter. For example, suppose you had the following
|
||||
variable:</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ header file.
|
|||
<p>
|
||||
The preferred approach to building an extension module is to compile it into
|
||||
a shared object file or DLL. To do this, you will need to compile your program
|
||||
using comands like this (shown for Linux):
|
||||
using commands like this (shown for Linux):
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
@ -167,7 +167,7 @@ The name of the module is specified using the <tt>%module</tt> directive or the
|
|||
<p>
|
||||
An alternative approach to dynamic linking is to rebuild the Tcl
|
||||
interpreter with your extension module added to it. In the past,
|
||||
this approach was sometimes necesssary due to limitations in dynamic loading
|
||||
this approach was sometimes necessary due to limitations in dynamic loading
|
||||
support on certain machines. However, the situation has improved greatly
|
||||
over the last few years and you should not consider this approach
|
||||
unless there is really no other option.
|
||||
|
|
@ -869,7 +869,7 @@ proc blah {} {
|
|||
|
||||
<p>
|
||||
When an identifier name is given, it is used to perform an implicit hash-table lookup of the value during argument
|
||||
conversion. This allows the <tt>global</tt> statement to be ommitted.
|
||||
conversion. This allows the <tt>global</tt> statement to be omitted.
|
||||
</p>
|
||||
|
||||
<H3><a name="Tcl_nn19"></a>31.3.5 Pointers</H3>
|
||||
|
|
@ -2557,7 +2557,7 @@ int count(char c, char *str, int len);
|
|||
<p>
|
||||
When a multi-argument typemap is defined, the arguments are always handled as a single
|
||||
Tcl object. This allows the function to be used like this (notice how the length
|
||||
parameter is ommitted):
|
||||
parameter is omitted):
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -3312,7 +3312,7 @@ proc new {objectType handle_r args} {
|
|||
#
|
||||
# Also creates a procedure for the object and a trace on
|
||||
# the handle variable that deletes the object when the
|
||||
# handle varibale is overwritten or unset
|
||||
# handle variable is overwritten or unset
|
||||
upvar $handle_r handle
|
||||
#
|
||||
# Create the new object
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ int wrap_printf(const char *fmt, ...) {
|
|||
</div>
|
||||
|
||||
<p>
|
||||
Athough this code might compile, it won't do what you expect. This is
|
||||
Although this code might compile, it won't do what you expect. This is
|
||||
because the call to <tt>printf()</tt> is compiled as a procedure call
|
||||
involving only two arguments. However, clearly a two-argument
|
||||
configuration of the call stack is completely wrong if your intent is
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ The required environment variables are displayed with their current values.
|
|||
<p>
|
||||
The list of required environment variables for each module language is also listed below.
|
||||
They are usually set from the Control Panel and System properties, but this depends on which flavour of Windows you are running.
|
||||
If you don't want to use environment variables then change all occurences of the environment variables in the .dsp files with hard coded values.
|
||||
If you don't want to use environment variables then change all occurrences of the environment variables in the .dsp files with hard coded values.
|
||||
If you are interested in how the project files are set up there is explanatory information in some of the language module's documentation.
|
||||
</p>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue