Consistently put whitespace outside of <tt>...</tt> and not inside
This commit is contained in:
parent
859d65b300
commit
f541e604e8
8 changed files with 25 additions and 25 deletions
|
|
@ -547,7 +547,7 @@ Below shows the expansions for the 1st of the overloaded <tt>something</tt> wrap
|
||||||
The <tt>exception.i</tt> library file provides support for creating
|
The <tt>exception.i</tt> library file provides support for creating
|
||||||
language independent exceptions in your interfaces. To use it, simply
|
language independent exceptions in your interfaces. To use it, simply
|
||||||
put an "<tt>%include exception.i</tt>" in your interface file. This
|
put an "<tt>%include exception.i</tt>" in your interface file. This
|
||||||
provides a function<tt> SWIG_exception()</tt> that can be used to raise
|
provides a function <tt>SWIG_exception()</tt> that can be used to raise
|
||||||
common scripting language exceptions in a portable manner. For example :</p>
|
common scripting language exceptions in a portable manner. For example :</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
|
|
|
||||||
|
|
@ -358,7 +358,7 @@ more aggressive from gcc-4.0 onwards and will result in code that fails with str
|
||||||
<p>
|
<p>
|
||||||
The name of the shared library output file is important.
|
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).
|
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>
|
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>25.2.5 Using your module</H3>
|
<H3><a name="Java_using_module"></a>25.2.5 Using your module</H3>
|
||||||
|
|
||||||
|
|
@ -2441,7 +2441,7 @@ It also contains all the methods in the C++ class it is proxying plus getters an
|
||||||
member variables. These functions call the native methods in the intermediary JNI class.
|
member variables. These functions call the native methods in the intermediary JNI class.
|
||||||
The advantage of having this extra layer is the type safety that the proxy class functions offer.
|
The advantage of having this extra layer is the type safety that the proxy class functions offer.
|
||||||
It adds static type checking which leads to fewer surprises at runtime.
|
It adds static type checking which leads to fewer surprises at runtime.
|
||||||
For example, you can see that if you attempt to use the <tt> spam() </tt>
|
For example, you can see that if you attempt to use the <tt>spam()</tt>
|
||||||
function it will only compile when the parameters passed are an <tt>int</tt> and a <tt>Foo</tt>.
|
function it will only compile when the parameters passed are an <tt>int</tt> and a <tt>Foo</tt>.
|
||||||
From a user's point of view, it makes the class work as if it were a Java class:
|
From a user's point of view, it makes the class work as if it were a Java class:
|
||||||
</p>
|
</p>
|
||||||
|
|
@ -4173,8 +4173,8 @@ void *malloc(size_t nbytes);
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
If no declaration name is given to <tt>%exception</tt>, it is applied to all wrapper functions.
|
If no declaration name is given to <tt>%exception</tt>, it is applied to all wrapper functions.
|
||||||
The <tt> $action </tt> is a SWIG special variable and is replaced by the C/C++ function call being wrapped.
|
The <tt>$action</tt> is a SWIG special variable and is replaced by the C/C++ function call being wrapped.
|
||||||
The <tt> return $null; </tt> handles all native method return types, namely those that have a void return and those that do not.
|
The <tt>return $null;</tt> handles all native method return types, namely those that have a void return and those that do not.
|
||||||
This is useful for typemaps that will be used in native method returning all return types.
|
This is useful for typemaps that will be used in native method returning all return types.
|
||||||
See the section on
|
See the section on
|
||||||
<a href="#Java_special_variables">Java special variables</a> for further explanation.
|
<a href="#Java_special_variables">Java special variables</a> for further explanation.
|
||||||
|
|
@ -5579,7 +5579,7 @@ This special variable is usually used for making calls to a function in the inte
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b><tt>$null </tt></b><br>
|
<b><tt>$null</tt></b><br>
|
||||||
Used in input typemaps to return early from JNI functions that have either void or a non-void return type. Example:
|
Used in input typemaps to return early from JNI functions that have either void or a non-void return type. Example:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -194,7 +194,7 @@ int fact(int n);
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The <tt> #define SWIG_FILE_WITH_INIT </tt> line inserts a macro that specifies that the
|
The <tt>#define SWIG_FILE_WITH_INIT</tt> line inserts a macro that specifies that the
|
||||||
resulting C file should be built as a python extension, inserting the module
|
resulting C file should be built as a python extension, inserting the module
|
||||||
<tt>init</tt> code. This <tt>.i</tt> file wraps the following simple C file:
|
<tt>init</tt> code. This <tt>.i</tt> file wraps the following simple C file:
|
||||||
</p>
|
</p>
|
||||||
|
|
@ -395,7 +395,7 @@ of the module prefixed by an underscore</b>. If the name of your module is "<tt
|
||||||
name of the corresponding object file should be
|
name of the corresponding object file should be
|
||||||
"<tt>_example.so</tt>" or "<tt>_examplemodule.so</tt>".
|
"<tt>_example.so</tt>" or "<tt>_examplemodule.so</tt>".
|
||||||
The name of the module is specified using the <tt>%module</tt> directive or the
|
The name of the module is specified using the <tt>%module</tt> directive or the
|
||||||
<tt> -module</tt> command line option.
|
<tt>-module</tt> command line option.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -783,8 +783,8 @@ Building a SWIG extension to Python under Windows is roughly similar to
|
||||||
the process used with Unix. Using the distutils, it is essentially
|
the process used with Unix. Using the distutils, it is essentially
|
||||||
identical. If you have the same version of the MS compiler that Python
|
identical. If you have the same version of the MS compiler that Python
|
||||||
was built with (the python2.4 and python2.5 distributed by python.org
|
was built with (the python2.4 and python2.5 distributed by python.org
|
||||||
are built with Visual Studio 2003), the standard <tt> python setup.py
|
are built with Visual Studio 2003), the standard <tt>python setup.py
|
||||||
build </tt> should just work.
|
build</tt> should just work.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
|
||||||
|
|
@ -685,7 +685,7 @@ For example, this struct declaration: </p>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p> gets wrapped as a <tt>Vector</tt> class, with
|
<p> gets wrapped as a <tt>Vector</tt> class, with
|
||||||
Ruby instance methods <tt>x</tt>, <tt> x=</tt>,
|
Ruby instance methods <tt>x</tt>, <tt>x=</tt>,
|
||||||
<tt>y</tt> and <tt>y=</tt>. These methods can
|
<tt>y</tt> and <tt>y=</tt>. These methods can
|
||||||
be used to access structure data from Ruby as follows: </p>
|
be used to access structure data from Ruby as follows: </p>
|
||||||
|
|
||||||
|
|
@ -1313,7 +1313,7 @@ chapter.</p>
|
||||||
|
|
||||||
<p>Some containers in the STL allow you to modify their default
|
<p>Some containers in the STL allow you to modify their default
|
||||||
behavior by using so called functors or function objects.
|
behavior by using so called functors or function objects.
|
||||||
Functors are often just a very simple struct with<tt> operator()</tt>
|
Functors are often just a very simple struct with <tt>operator()</tt>
|
||||||
redefined or an actual C/C++ function. This allows you, for
|
redefined or an actual C/C++ function. This allows you, for
|
||||||
example, to always keep the sort order of a STL container to your
|
example, to always keep the sort order of a STL container to your
|
||||||
liking.</p>
|
liking.</p>
|
||||||
|
|
@ -1327,7 +1327,7 @@ this includes <tt>std::set</tt>,
|
||||||
<tt>std::multiset</tt>
|
<tt>std::multiset</tt>
|
||||||
and <tt>std::multimap</tt>.</p>
|
and <tt>std::multimap</tt>.</p>
|
||||||
|
|
||||||
<p>The functors in swig are called<tt> swig::UnaryFunction</tt>
|
<p>The functors in swig are called <tt>swig::UnaryFunction</tt>
|
||||||
and <tt>swig::BinaryFunction</tt>.
|
and <tt>swig::BinaryFunction</tt>.
|
||||||
|
|
||||||
For C++ predicates (ie. functors that must return bool as a result) <tt>swig::UnaryPredicate</tt>
|
For C++ predicates (ie. functors that must return bool as a result) <tt>swig::UnaryPredicate</tt>
|
||||||
|
|
@ -1380,8 +1380,8 @@ values they point at, while the non-const iterators can both read and
|
||||||
modify the values.</p>
|
modify the values.</p>
|
||||||
|
|
||||||
<p>The Ruby STL wrappings support both type of iterators by using
|
<p>The Ruby STL wrappings support both type of iterators by using
|
||||||
a proxy class in-between. This proxy class is <tt>swig::Iterator or
|
a proxy class in-between. This proxy class is <tt>swig::Iterator</tt> or
|
||||||
swig::ConstIterator. </tt> Derived from them are template
|
<tt>swig::ConstIterator</tt>. Derived from them are template
|
||||||
classes that need to be initialized with the actual iterator for the
|
classes that need to be initialized with the actual iterator for the
|
||||||
container you are wrapping and often times with the beginning and
|
container you are wrapping and often times with the beginning and
|
||||||
ending points of the iteration range.</p>
|
ending points of the iteration range.</p>
|
||||||
|
|
@ -1450,7 +1450,7 @@ i
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>If you'd rather have STL classes without any iterators, you should define<tt> -DSWIG_NO_EXPORT_ITERATOR_METHODS </tt>when running swig.</p>
|
<p>If you'd rather have STL classes without any iterators, you should define <tt>-DSWIG_NO_EXPORT_ITERATOR_METHODS</tt> when running swig.</p>
|
||||||
|
|
||||||
<H3><a name="Ruby_nn24"></a>38.3.16 C++ Smart Pointers</H3>
|
<H3><a name="Ruby_nn24"></a>38.3.16 C++ Smart Pointers</H3>
|
||||||
|
|
||||||
|
|
@ -4997,7 +4997,7 @@ object from its underlying C++ object.</p>
|
||||||
<p>In general, you will only need to use the <tt>SWIG_RubyInstanceFor</tt>,
|
<p>In general, you will only need to use the <tt>SWIG_RubyInstanceFor</tt>,
|
||||||
which is required for implementing mark functions as shown below.
|
which is required for implementing mark functions as shown below.
|
||||||
However, if you implement your own free functions (see below) you may
|
However, if you implement your own free functions (see below) you may
|
||||||
also have to call the<tt> SWIG_RubyRemoveTracking</tt> and <tt>RubyUnlinkObjects</tt>
|
also have to call the <tt>SWIG_RubyRemoveTracking</tt> and <tt>RubyUnlinkObjects</tt>
|
||||||
methods.</p>
|
methods.</p>
|
||||||
|
|
||||||
<H3><a name="Ruby_nn61"></a>38.10.4 Mark Functions</H3>
|
<H3><a name="Ruby_nn61"></a>38.10.4 Mark Functions</H3>
|
||||||
|
|
|
||||||
|
|
@ -1046,7 +1046,7 @@ def filecopy(source,target):
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
In this case <tt>f1</tt>,<tt> f2</tt>, and <tt>buffer</tt> are all
|
In this case <tt>f1</tt>, <tt>f2</tt>, and <tt>buffer</tt> are all
|
||||||
opaque objects containing C pointers. It doesn't matter what value
|
opaque objects containing C pointers. It doesn't matter what value
|
||||||
they contain--our program works just fine without this knowledge.</p>
|
they contain--our program works just fine without this knowledge.</p>
|
||||||
|
|
||||||
|
|
@ -1711,7 +1711,7 @@ wrapping a header file like this:
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<tt>%rename </tt>applies a renaming operation to all future
|
<tt>%rename</tt> applies a renaming operation to all future
|
||||||
occurrences of a name. The renaming applies to functions, variables,
|
occurrences of a name. The renaming applies to functions, variables,
|
||||||
class and structure names, member functions, and member data. For
|
class and structure names, member functions, and member data. For
|
||||||
example, if you had two-dozen C++ classes, all with a member function
|
example, if you had two-dozen C++ classes, all with a member function
|
||||||
|
|
|
||||||
|
|
@ -1205,7 +1205,7 @@ SWIG is unable to support kwargs when wrapping overloaded methods, so the defaul
|
||||||
<p>
|
<p>
|
||||||
SWIG wraps class members that are public following the C++
|
SWIG wraps class members that are public following the C++
|
||||||
conventions, i.e., by explicit public declaration or by the use of
|
conventions, i.e., by explicit public declaration or by the use of
|
||||||
the <tt> using</tt> directive. In general, anything specified in a
|
the <tt>using</tt> directive. In general, anything specified in a
|
||||||
private or protected section will be ignored, although the internal
|
private or protected section will be ignored, although the internal
|
||||||
code generator sometimes looks at the contents of the private and
|
code generator sometimes looks at the contents of the private and
|
||||||
protected sections so that it can properly generate code for default
|
protected sections so that it can properly generate code for default
|
||||||
|
|
@ -2800,7 +2800,7 @@ public:
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This code adds a<tt> __str__</tt> method to our class for producing a
|
This code adds a <tt>__str__</tt> method to our class for producing a
|
||||||
string representation of the object. In Python, such a method would
|
string representation of the object. In Python, such a method would
|
||||||
allow us to print the value of an object using the <tt>print</tt>
|
allow us to print the value of an object using the <tt>print</tt>
|
||||||
command.
|
command.
|
||||||
|
|
@ -2854,7 +2854,7 @@ The <a href="Customization.html#Customization_exception_special_variables">Speci
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The<tt> %extend</tt> directive follows all of the same conventions
|
The <tt>%extend</tt> directive follows all of the same conventions
|
||||||
as its use with C structures. Please refer to the <a href="SWIG.html#SWIG_adding_member_functions">Adding member functions to C structures</a>
|
as its use with C structures. Please refer to the <a href="SWIG.html#SWIG_adding_member_functions">Adding member functions to C structures</a>
|
||||||
section for further details.
|
section for further details.
|
||||||
</p>
|
</p>
|
||||||
|
|
|
||||||
|
|
@ -160,7 +160,7 @@ of the module. If the name of your SWIG module is "<tt>example</tt>", the
|
||||||
name of the corresponding object file should be
|
name of the corresponding object file should be
|
||||||
"<tt>example.so</tt>".
|
"<tt>example.so</tt>".
|
||||||
The name of the module is specified using the <tt>%module</tt> directive or the
|
The name of the module is specified using the <tt>%module</tt> directive or the
|
||||||
<tt> -module</tt> command line option.
|
<tt>-module</tt> command line option.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Tcl_nn5"></a>39.1.3 Static linking</H3>
|
<H3><a name="Tcl_nn5"></a>39.1.3 Static linking</H3>
|
||||||
|
|
@ -504,7 +504,7 @@ name, but you can override it using the <tt>-prefix</tt> option.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
When the<tt> -namespace</tt> option is used, objects in the module
|
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>.
|
are always accessed with the namespace name such as <tt>Foo::bar</tt>.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -3360,7 +3360,7 @@ list of strings like this:
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
To do this, you not only need to map a list of strings to <tt> char *argv[]</tt>, but the
|
To do this, you not only need to map a list of strings to <tt>char *argv[]</tt>, but the
|
||||||
value of <tt>int argc</tt> is implicitly determined by the length of the list. Using only simple
|
value of <tt>int argc</tt> is implicitly determined by the length of the list. Using only simple
|
||||||
typemaps, this type of conversion is possible, but extremely painful.
|
typemaps, this type of conversion is possible, but extremely painful.
|
||||||
Multi-argument typemaps help in this situation.
|
Multi-argument typemaps help in this situation.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue