mirror of https://github.com/swig/swig
Fix assorted comment and documentation typos
This commit is contained in:
Olly Betts
parent
894de07c3d
commit
2f3bf144c6
6
CHANGES
6
CHANGES
|
|
@ -5684,7 +5684,7 @@ Version 1.3.28 (February 12, 2006)
|
|||
|
||||
%rename("%(utitle)s",%$isfunction,%$ismember) "";
|
||||
|
||||
to avoid clashings with other swig macros/directives.
|
||||
to avoid clashes with other swig macros/directives.
|
||||
|
||||
01/14/2006: cfisavage
|
||||
[Ruby]
|
||||
|
|
@ -11787,7 +11787,7 @@ Version 1.3.20 (December 17, 2003)
|
|||
|
||||
11/30/2003: cheetah (William Fulton)
|
||||
[Java] Fixed [ 766409 ] missing symbol SWIG_JavaThrowException during module load
|
||||
SWIGs internal functions are all static as there is no need for different SWIG
|
||||
SWIG's internal functions are all static as there is no need for different SWIG
|
||||
generated modules to share any code at runtime.
|
||||
|
||||
11/30/2003: beazley
|
||||
|
|
@ -21368,7 +21368,7 @@ Version 1.1 Patch 4 (January 4, 1998)
|
|||
12/29/97: Fixed configure script and a few makefiles to support Python 1.5
|
||||
|
||||
12/29/97: Added 'embed15.i' library file. This file should be used to
|
||||
staticly link versions of Python 1.5. To make it the default,
|
||||
statically link versions of Python 1.5. To make it the default,
|
||||
simply copy 'swig_lib/python/embed15.i' to 'swig_lib/python/embed.i'
|
||||
|
||||
Version 1.1 Patch 3 (November 24, 1997)
|
||||
|
|
|
|||
|
|
@ -347,7 +347,7 @@ Delete(a); /* Destroy a */
|
|||
|
||||
All objects are referenced counted and given a reference count of 1 when initially created. The
|
||||
<tt>Delete()</tt> function only destroys an object when the reference count reaches zero. When
|
||||
an object is placed in a list or hash table, it's reference count is automatically increased. For example:
|
||||
an object is placed in a list or hash table, its reference count is automatically increased. For example:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
|
|
@ -844,7 +844,7 @@ Returns a type object corresponding to the type string produced by the Swig_cloc
|
|||
<li><tt>char *Swig_clocal_deref(DataType *t, char *name)</tt><br>
|
||||
This function is the inverse of the <tt>clocal()</tt> function. Given a type and a name,
|
||||
it produces a string containing the code needed to cast/convert the type produced by
|
||||
<tt>Swig_clocal()</tt> back into it's original type.
|
||||
<tt>Swig_clocal()</tt> back into its original type.
|
||||
|
||||
<p>
|
||||
<li><tt>char *Swig_clocal_assign(DataType *t, char *name)</tt><br>
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ this function merely records that those attributes did not exist in the original
|
|||
<blockquote>
|
||||
This function is similar to <tt>Swig_save()</tt> except that adds additional attribute checking. There are different interpretations
|
||||
of the attribute names. A name of "attr" merely requests that the function check for the presence of an attribute. If the attribute is missing, SWIG will exit with a failed assertion. An attribute name of "?attr" specifies that the attribute "attr" is optional and
|
||||
that it's old value must be saved (if any). An attribute name of "*attr" specifies that the attribute is required and that
|
||||
that its old value must be saved (if any). An attribute name of "*attr" specifies that the attribute is required and that
|
||||
its value must be saved. The saving of attributes is performed in the same manner as with <tt>Swig_save()</tt>. Here is an example:
|
||||
|
||||
<pre>
|
||||
|
|
|
|||
|
|
@ -748,7 +748,7 @@ namespace car {
|
|||
|
||||
<p>
|
||||
Constants, as declared by the preprocessor #define macro or SWIG
|
||||
<tt>%constant</tt> directive, are included in SWIGs parse tree
|
||||
<tt>%constant</tt> directive, are included in SWIG's parse tree
|
||||
when it can be determined that they are, or could be reduced to,
|
||||
a literal value. Such values are translated into defconstant
|
||||
forms in the generated lisp wrapper when the -nocwrap command-line
|
||||
|
|
@ -887,7 +887,7 @@ globalvar> (globalvar.nnn::glob_float)
|
|||
<p>
|
||||
In C, an enumeration value is an integer value, while in C++ an
|
||||
enumeration value is implicitly convertible to an integer value,
|
||||
but can also be distinguished by it's enum type. For each enum
|
||||
but can also be distinguished by its enum type. For each enum
|
||||
declaration a def-foreign-type is generated, assigning the enum
|
||||
a default type of :int. Users may adjust the foreign type of
|
||||
enums via SWIG <tt>typemaps</tt>.
|
||||
|
|
@ -901,7 +901,7 @@ globalvar> (globalvar.nnn::glob_float)
|
|||
of it not being necessary to probe into foreign space to retrieve enum
|
||||
values. When generating a .cxx wrapper file, a more general solution is
|
||||
employed. A wrapper variable is created in the module_wrap.cxx file, and
|
||||
a ff:def-foreign-variable call is generated to retrieve it's value into lisp.
|
||||
a ff:def-foreign-variable call is generated to retrieve its value into lisp.
|
||||
</p>
|
||||
|
||||
<p>For example, the following header file
|
||||
|
|
@ -1131,7 +1131,7 @@ namespace BAR {
|
|||
inheritance of the classes in foreign code, with the
|
||||
ff:foreign-pointer class at its root. ff:foreign-pointer is a thin
|
||||
wrapper for pointers that is made available by the foreign function
|
||||
interface. It's key benefit is that it may be passed as an argument
|
||||
interface. Its key benefit is that it may be passed as an argument
|
||||
to any ff:def-foreign-call that is expecting a pointer as the
|
||||
parameter.
|
||||
</p>
|
||||
|
|
@ -1617,7 +1617,7 @@ opoverload>
|
|||
directive. This directive allows you to specify a (finite)
|
||||
argument list which will be inserted into the wrapper in place
|
||||
of the variable length argument indicator. As an example,
|
||||
consider the function <tt>printf()</tt>. It's declaration would
|
||||
consider the function <tt>printf()</tt>. Its declaration would
|
||||
appear as follows:
|
||||
</p>
|
||||
|
||||
|
|
@ -1735,7 +1735,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
The <tt>out</tt> typemap is used to generate code to form the
|
||||
return value of the wrapper from the return value of the wrapped
|
||||
function. This code is placed in the <convert and bind result to lresult>
|
||||
section of the above code diagram. It's default mapping is as follows:
|
||||
section of the above code diagram. Its default mapping is as follows:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -1758,7 +1758,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
|
|||
<p>
|
||||
This typemap is not used for code generation, but purely for the
|
||||
transformation of types in the parameter list of the wrapper function.
|
||||
It's primary use is to handle by-value to by-reference conversion in the
|
||||
Its primary use is to handle by-value to by-reference conversion in the
|
||||
wrappers parameter list. Its default settings are:
|
||||
</p>
|
||||
|
||||
|
|
@ -2093,7 +2093,7 @@ foreign environment.
|
|||
|
||||
<p>
|
||||
The :type keyword argument provides more information on the type of
|
||||
identifier. It's value is a symbol. This allows the
|
||||
identifier. Its value is a symbol. This allows the
|
||||
identifier-converter to apply different heuristics when mapping
|
||||
different types of identifiers to symbols. SWIG will generate calls
|
||||
to your identifier-converter using the following types.
|
||||
|
|
@ -2123,7 +2123,7 @@ scope in the specified class.
|
|||
|
||||
<p>
|
||||
The :arity keyword argument only appears in swig:swig-defmethod forms
|
||||
generated for overloaded functions. It's value is an integer
|
||||
generated for overloaded functions. Its value is an integer
|
||||
indicating the number of arguments passed to the routine indicated by
|
||||
this identifier.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -881,7 +881,7 @@ set so should only be used when a C# exception is not created.
|
|||
|
||||
|
||||
<p>
|
||||
Lets say we have the following simple C++ method:
|
||||
Let's say we have the following simple C++ method:
|
||||
</p>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2761,8 +2761,8 @@ Within SWIG wrappers, there are five main sections. These are (in order)
|
|||
<li>begin: This section is a placeholder for users to put code at the beginning of the C/C++ wrapper file.
|
||||
<li>runtime: This section has most of the common SWIG runtime code.
|
||||
<li>header: This section holds declarations and inclusions from the .i file.
|
||||
<li>wrapper: This section holds all the wrappering code.
|
||||
<li>init: This section holds the module initalisation function
|
||||
<li>wrapper: This section holds all the wrapper code.
|
||||
<li>init: This section holds the module initialisation function
|
||||
(the entry point for the interpreter).
|
||||
</ul>
|
||||
<p>
|
||||
|
|
@ -3005,7 +3005,7 @@ virtual int functionWrapper(Node *n) {
|
|||
/* write typemaps(in) */
|
||||
....
|
||||
|
||||
/* write constriants */
|
||||
/* write constraints */
|
||||
....
|
||||
|
||||
/* Emit the function call */
|
||||
|
|
|
|||
|
|
@ -449,7 +449,7 @@ to work with complicated and unusual C/C++ applications.
|
|||
|
||||
<p>
|
||||
Ironically, the freedom that SWIG provides is countered by an
|
||||
extremely conservative approach to code generation. At it's core, SWIG
|
||||
extremely conservative approach to code generation. At its core, SWIG
|
||||
tries to distill even the most advanced C++ code down to a small
|
||||
well-defined set of interface building techniques based on ANSI C
|
||||
programming. Because of this, you will find that SWIG interfaces can
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ swig -cffi -help
|
|||
|
||||
|
||||
As we mentioned earlier the ideal way to use SWIG is to use interface
|
||||
files. To illustrate the use of it, lets assume that we have a
|
||||
files. To illustrate the use of it, let's assume that we have a
|
||||
file named <i>test.h</i> with the following C code:
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@
|
|||
|
||||
|
||||
<p>
|
||||
This chapter describes SWIG's support of
|
||||
This chapter describes SWIG's support for
|
||||
<a href="http://modula3.org/">Modula-3</a>.
|
||||
You should be familiar with the
|
||||
<a href="SWIG.html#SWIG">basics</a>
|
||||
|
|
@ -109,7 +109,7 @@ into exceptions.
|
|||
|
||||
<p>
|
||||
If the library API is ill designed
|
||||
writing appropriate typemaps can be still time-consuming.
|
||||
writing appropriate typemaps can still be time-consuming.
|
||||
E.g. C programmers are very creative to work-around
|
||||
missing data types like (real) enumerations and sets.
|
||||
You should turn such work-arounds back to the Modula-3 way
|
||||
|
|
@ -120,14 +120,14 @@ otherwise you lose static safety and consistency.
|
|||
Without SWIG you would probably never consider trying to call C++ libraries
|
||||
from Modula-3, but with SWIG this is becomes feasible.
|
||||
SWIG can generate C wrappers to C++ functions and object methods
|
||||
that may throw exceptions, and then wrap these C wrappers for Module-3.
|
||||
that may throw exceptions, and then wrap these C wrappers for Modula-3.
|
||||
To make it complete you can then hide the C interface with Modula-3 classes and
|
||||
exceptions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
SWIG allows you to call C and C++ libraries from Modula-3 (even with call back
|
||||
functions), but it doesn't allow you to easily integrate a Module-3 module into
|
||||
functions), but it doesn't allow you to easily integrate a Modula-3 module into
|
||||
a C/C++ project.
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ public:
|
|||
|
||||
<p>To create the wrapper properly, module <tt>derived_module</tt> needs to know about the
|
||||
<tt>base</tt> class and that its interface is covered in another module. The
|
||||
line <tt>%import "base_module.i"</tt> lets SWIG know exactly that. Oftentimes
|
||||
line <tt>%import "base_module.i"</tt> lets SWIG know exactly that. Often
|
||||
the <tt>.h</tt> file is passed to <tt>%import</tt> instead of the <tt>.i</tt>,
|
||||
which unfortunately doesn't work for all language modules. For example, Python requires the
|
||||
name of module that the base class exists in so that the proxy classes can fully inherit the
|
||||
|
|
|
|||
|
|
@ -163,7 +163,7 @@ the user more freedom with respect to custom typing.
|
|||
|
||||
<p>
|
||||
The camlp4 module (swigp4.ml -> swigp4.cmo) contains a simple rewriter which
|
||||
makes C++ code blend more seamlessly with objective caml code. It's use is
|
||||
makes C++ code blend more seamlessly with objective caml code. Its use is
|
||||
optional, but encouraged. The source file is included in the Lib/ocaml
|
||||
directory of the SWIG source distribution. You can checkout this file with
|
||||
<tt>"swig -ocaml -co swigp4.ml"</tt>. You should compile the file with
|
||||
|
|
@ -310,7 +310,7 @@ type c_obj =
|
|||
</li>
|
||||
<li>caml_val_ptr receives a void * and returns a c_obj.</li>
|
||||
<li>caml_val_bool receives a C int and returns a c_obj representing
|
||||
it's bool value.</li>
|
||||
its bool value.</li>
|
||||
<li>caml_val_(u)?(char|short|int|long|float|double) receives an
|
||||
appropriate C value and returns a c_obj representing it.</li>
|
||||
<li>caml_val_string receives a char * and returns a string value.</li>
|
||||
|
|
|
|||
|
|
@ -329,7 +329,7 @@ octave:4> swigexample.fclose(f);
|
|||
</pre></div>
|
||||
|
||||
<p>
|
||||
Simply printing the value of a wrapped C++ type will print it's typename. E.g.,
|
||||
Simply printing the value of a wrapped C++ type will print its typename. E.g.,
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>octave:1> swigexample;
|
||||
|
|
|
|||
|
|
@ -1098,7 +1098,7 @@ CHICKEN_GENERATED_SCHEME = $(INTERFACE:.i=.scm)
|
|||
CHICKEN_COMPILED_SCHEME = $(INTERFACE:.i=_chicken.c)
|
||||
CHICKEN_COMPILED_OBJECT = $(CHICKEN_COMPILED_SCHEME:.c=.@OBJEXT@)
|
||||
|
||||
# flags for the main chicken sources (only used when compiling staticly)
|
||||
# flags for the main chicken sources (only used when compiling statically)
|
||||
CHICKEN_COMPILED_MAIN = $(CHICKEN_MAIN:.scm=_chicken.c)
|
||||
CHICKEN_COMPILED_MAIN_OBJECT = $(CHICKEN_COMPILED_MAIN:.c=.@OBJEXT@)
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ SWIG.
|
|||
|
||||
<h2>The C++ Code</h2>
|
||||
|
||||
Lets take a templated function and a templated class as follows:
|
||||
Let's take a templated function and a templated class as follows:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ This example illustrates how C++ templates can be used from Java using SWIG.
|
|||
|
||||
<h2>The C++ Code</h2>
|
||||
|
||||
Lets take a templated function and a templated class as follows:
|
||||
Let's take a templated function and a templated class as follows:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
-- import
|
||||
-- the lua 5.0 loading mechanism is rather poor & relies upon the loadlib() fn
|
||||
-- the lua 5.1 loading mechanism is simplicity itself
|
||||
-- for now we need a bridge which will use the correct verion
|
||||
-- for now we need a bridge which will use the correct version
|
||||
|
||||
function import_5_0(module)
|
||||
-- imports the file into the program
|
||||
|
|
@ -10,7 +10,7 @@ function import_5_0(module)
|
|||
-- and look for the fn 'Example_Init()' (note the capitalisation)
|
||||
if rawget(_G,module)~=nil then return end -- module appears to be loaded
|
||||
|
||||
-- capitialising the first letter
|
||||
-- capitalising the first letter
|
||||
local c=string.upper(string.sub(module,1,1))
|
||||
local fnname=c..string.sub(module,2).."_Init"
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ function import_5_0(module)
|
|||
end
|
||||
assert(lib,"error loading module:"..module)
|
||||
|
||||
lib() -- execute the function: initalising the lib
|
||||
lib() -- execute the function: initialising the lib
|
||||
local m=rawget(_G,module) -- gets the module object
|
||||
assert(m~=nil,"no module table found")
|
||||
end
|
||||
|
|
@ -39,4 +39,4 @@ if string.sub(_VERSION,1,7)=='Lua 5.0' then
|
|||
import=import_5_0
|
||||
else
|
||||
import=import_5_1
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ print
|
|||
print "Adding and calling another Python callback"
|
||||
print "------------------------------------------"
|
||||
|
||||
# Lets do the same but use the weak reference this time.
|
||||
# Let's do the same but use the weak reference this time.
|
||||
|
||||
callback = PyCallback().__disown__()
|
||||
caller.setCallback(callback)
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ extern int count(char *bytes, int len, char c);
|
|||
/* This example shows how to wrap a function that mutates a string */
|
||||
|
||||
/* Since str is modified, we make a copy of the Python object
|
||||
so that we don't violate it's mutability */
|
||||
so that we don't violate its mutability */
|
||||
|
||||
%typemap(in) (char *str, int len) {
|
||||
%#if PY_VERSION_HEX >= 0x03000000
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
|
||||
<html>
|
||||
<head>
|
||||
<title>SWIG:Examples:ruby</title>
|
||||
</head>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
See ../README for common README file.
|
||||
|
||||
The Java implementation of the test-suite is a little different to the other languages in that all of SWIGs output goes into a subdirectory named after the individual test case. This is so that all the shadow classes can be compiled as Java classes have to go into separate files. Otherwise the Makefile wouldn't know which .java files would be relevant to the testcase. For this to work the testcase must go into a Java package.
|
||||
The Java implementation of the test-suite is a little different to the other languages in that all of SWIG's output goes into a subdirectory named after the individual test case. This is so that all the shadow classes can be compiled as Java classes which have to go into separate files. Otherwise the Makefile wouldn't know which .java files would be relevant to the testcase. For this to work the testcase must go into a Java package.
|
||||
|
||||
Any testcases which have _runme.java appended after the testcase name will be detected and run.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
-- import
|
||||
-- the lua 5.0 loading mechanism is rather poor & relies upon the loadlib() fn
|
||||
-- the lua 5.1 loading mechanism is simplicity itself
|
||||
-- for now we need a bridge which will use the correct verion
|
||||
-- for now we need a bridge which will use the correct version
|
||||
|
||||
function import_5_0(name)
|
||||
-- imports the file into the program
|
||||
|
|
@ -13,7 +13,7 @@ function import_5_0(name)
|
|||
local lib=loadlib(name..'.dll','luaopen_'..name) or loadlib(name..'.so','luaopen_'..name)
|
||||
assert(lib,"error loading module:"..name)
|
||||
|
||||
lib() -- execute the function: initalising the lib
|
||||
lib() -- execute the function: initialising the lib
|
||||
assert(rawget(_G,name)~=nil,"no module table found")
|
||||
end
|
||||
|
||||
|
|
@ -25,4 +25,4 @@ if string.sub(_VERSION,1,7)=='Lua 5.0' then
|
|||
import=import_5_0
|
||||
else
|
||||
import=import_5_1
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -313,7 +313,7 @@ SWIG_Chicken_GetModule(void *SWIGUNUSEDPARM(clientdata)) {
|
|||
swig_module_info *ret = 0;
|
||||
C_word sym;
|
||||
|
||||
/* lookup the type pointer... it is stored in it's own symbol table */
|
||||
/* lookup the type pointer... it is stored in its own symbol table */
|
||||
C_SYMBOL_TABLE *stable = C_find_symbol_table("swig_runtime_data" SWIG_RUNTIME_VERSION);
|
||||
if (stable != NULL) {
|
||||
sym = SWIG_Chicken_LookupSymbol(chicken_runtimevar_name, stable);
|
||||
|
|
@ -333,7 +333,7 @@ SWIG_Chicken_SetModule(swig_module_info *module) {
|
|||
C_word pointer;
|
||||
static C_word *space = 0;
|
||||
|
||||
/* type pointer is stored in it's own symbol table */
|
||||
/* type pointer is stored in its own symbol table */
|
||||
stable = C_find_symbol_table("swig_runtime_data" SWIG_RUNTIME_VERSION);
|
||||
if (stable == NULL) {
|
||||
stable = C_new_symbol_table("swig_runtime_data" SWIG_RUNTIME_VERSION, 16);
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ SWIGEXPORT int SWIG_init(lua_State* L) /* default Lua action */
|
|||
int i;
|
||||
/* start with global table */
|
||||
lua_pushglobaltable (L);
|
||||
/* SWIG's internal initalisation */
|
||||
/* SWIG's internal initialisation */
|
||||
SWIG_InitializeModule((void*)L);
|
||||
SWIG_PropagateClientData();
|
||||
#endif
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
// Include fundamental fragemt definitions
|
||||
// Include fundamental fragment definitions
|
||||
%include <typemaps/fragments.swg>
|
||||
|
||||
// Look for user fragments file.
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ SWIG = $(exec_prefix)/bin/swig
|
|||
SWIGOPT = -perl5
|
||||
SWIGCC = $(CC)
|
||||
|
||||
# SWIG Library files. Uncomment this to staticly rebuild Perl
|
||||
# SWIG Library files. Uncomment this to statically rebuild Perl
|
||||
#SWIGLIBS = -static -lperlmain.i
|
||||
|
||||
# Rules for creating .o files from source.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
#define SWIG_FROM_CALL_ARGS SWIG_PERL_CALL_ARGS_1
|
||||
|
||||
|
||||
/* Include fundamental fragemt definitions */
|
||||
/* Include fundamental fragment definitions */
|
||||
%include <typemaps/fragments.swg>
|
||||
|
||||
/* Look for user fragments file. */
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
#undef SWIG_TYPECHECK_BOOL
|
||||
%define SWIG_TYPECHECK_BOOL 10000 %enddef
|
||||
|
||||
/* Include fundamental fragemt definitions */
|
||||
/* Include fundamental fragment definitions */
|
||||
%include <typemaps/fragments.swg>
|
||||
|
||||
/* Look for user fragments file. */
|
||||
|
|
|
|||
|
|
@ -321,7 +321,7 @@ static int NAME(TYPE x) {
|
|||
|
||||
/*
|
||||
* Function/method overloading support. This is done through typemaps,
|
||||
* but also involve a precedence level.
|
||||
* but also involves a precedence level.
|
||||
*/
|
||||
|
||||
/* Macro for overload resolution */
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
* array with the correct data and linking the correct swig_cast_info
|
||||
* structures together.
|
||||
*
|
||||
* The generated swig_type_info structures are assigned staticly to an initial
|
||||
* The generated swig_type_info structures are assigned statically to an initial
|
||||
* array. We just loop through that array, and handle each type individually.
|
||||
* First we lookup if this type has been already loaded, and if so, use the
|
||||
* loaded structure instead of the generated one. Then we have to fill in the
|
||||
|
|
|
|||
|
|
@ -825,7 +825,7 @@ Node *Swig_cparse_template_locate(String *name, Parm *tparms, Symtab *tscope) {
|
|||
/* If not a templated class we must have a templated function.
|
||||
The template found is not necessarily the one we want when dealing with templated
|
||||
functions. We don't want any specialized templated functions as they won't have
|
||||
the default parameters. Lets look for the unspecialized template. Also make sure
|
||||
the default parameters. Let's look for the unspecialized template. Also make sure
|
||||
the number of template parameters is correct as it is possible to overload a
|
||||
templated function with different numbers of template parameters. */
|
||||
|
||||
|
|
|
|||
|
|
@ -476,7 +476,7 @@ class TypePass:private Dispatcher {
|
|||
if (unnamed && tdname && (Cmp(storage, "typedef") == 0)) {
|
||||
SwigType_typedef(unnamed, tdname);
|
||||
}
|
||||
// name of the outer class should already be patched to contain it's outer classes names, but not to contain namespaces
|
||||
// name of the outer class should already be patched to contain its outer classes names, but not to contain namespaces
|
||||
// namespace name (if present) is added after processing child nodes
|
||||
if (Getattr(n, "nested:outer") && name) {
|
||||
String *outerName = Getattr(Getattr(n, "nested:outer"), "name");
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ String *SwigType_parm(const SwigType *t) {
|
|||
/* -----------------------------------------------------------------------------
|
||||
* SwigType_split()
|
||||
*
|
||||
* Splits a type into it's component parts and returns a list of string.
|
||||
* Splits a type into its component parts and returns a list of string.
|
||||
* ----------------------------------------------------------------------------- */
|
||||
|
||||
List *SwigType_split(const SwigType *t) {
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ AH_BOTTOM([
|
|||
/* Default language */
|
||||
#define SWIG_LANG "-tcl"
|
||||
|
||||
/* Deal with Microsofts attempt at deprecating C standard runtime functions */
|
||||
/* Deal with Microsoft's attempt at deprecating C standard runtime functions */
|
||||
#if defined(_MSC_VER)
|
||||
# define _CRT_SECURE_NO_DEPRECATE
|
||||
#endif
|
||||
|
|
|
|||
Loading…
Reference in New Issue