Swig

Latest version: v4.2.1

Safety actively analyzes 638452 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 11 of 13

1.3.13

==============================

06/16/2002: beazley
Fixed a bug with __FILE__ expansion in the preprocessor. On Windows,
the backslash (\) is now converted to (\\) in the string literal
used for __FILE__. Reported by Steve Glaser.

06/14/2002: beazley
Fixed warning message about 'name private in this context'. The
warning is only generated for public methods. Reported by
Scott Michel.

06/14/2002: beazley
Fixed some problems related to template instantiation
and namespaces. When SWIG expands a template, it does
so with fully resolved types. For example, if you have this:

template<class T> class foo { };
typedef double Double;
%template(foo_d) foo<Double>;

then, it is handled as foo<double> in the typesystem.
This fixes a number of subtle problems with inheritance
and templates.

06/14/2002: ljohnson (Lyle Johnson)
[Ruby] Added missing bool typemaps for INPUT, OUTPUT and
INOUT in Lib/ruby/typemaps.i.

05/29/2002: cheetah (William Fulton)
[Java] Fix for a couple of broken pragmas.

05/29/2002: cheetah (William Fulton)
Fix for unnecessary cast when wrapping global variable where
the type is not parsed by SWIG - Java variables example
failure as reported by Larry Virden.

06/10/2002: beazley
Modified %template to allow for empty instantiations.

%template() foo<int,int>;

This registers foo<int,int> with the type system, but
doesn't wrap it (same as %ignore). This may only be a
temporary measure. SWIG might be able to automatically
instantiate templates in certain cases.

06/10/2002: beazley
Fixed function prototype problems with Tcl 8.4

06/09/2002: beazley
Fixed problem with templates and location of base classes.
This one is a little mind-bending, but here is an example
that illustrates:

template <class ArgType, class ResType>
struct traits
{
typedef ArgType arg_type;
typedef ResType res_type;
};

template <class ArgType, class ResType>
struct Function
{
};

template <class AF, class AG>
struct Class : Function<typename traits<AF, AG>::arg_type,
typename traits<AF, AG>::res_type>
{
};

%template(traits_dd) traits <double, double>;
%template(Function_dd) Function <double, double>;
%template(Class_dd) Class <double, double>;


In this example, the base class of 'Class' is determined from
the Function template, but the types are obtained through typedefs.
Because of this, SWIG could not locate the wrapped base class
(Function<double,double>). Should be fixed in 1.3.13 even
though I can think of a million other things that might
also be broken.

06/07/2002: beazley
Fixed a problem with conversion operators. If you had an
operator like this,

operator double() const;

SWIG was ommitting the "const" qualifier. This affected
%rename and other directives. Reported by Zhong Ren.

06/07/2002: beazley
Lessened the strictness of abstract class checking. If
you have code like this:

class Foo {
public:
virtual int method() = 0;
};

class Bar : public Foo {
public:
Bar();
~Bar();
};

SWIG will go ahead and generate constructor/destructors
for Bar. However, it will also generate a warning message
that "Bar" might be abstract (since method() isn't defined).
In SWIG-1.3.12, SWIG refused to generate a constructor at all.

06/07/2002: beazley
Change to %template directive. If you specify something like this:

%template(vi) std::vector<int>;

It is *exactly* the same as this:

namespace std {
%template(vi) vector<int>;
}

SWIG-1.3.12 tried to instantiate the template outside of the namespace
using some trick. However, this was extremely problematic and full
holes. This version is safer.

06/07/2002: beazley
Fixed bug with scope qualification and templates. For example:

A<B::C>::DD

Before, this was separated as scopes A<B, C>, and DD. Fixed now.

06/06/2002: beazley
Allow the following syntax:

class A { };
struct B : A { ... };

A base class without a specifier is assumed to be public for a struct.

06/06/2002: beazley
Fixed syntax error with template constructor initializers.
Reported by Marcelo Matus.

06/06/2002: beazley
Fixed bug with default template arguments.
Reported by Marcelo Matus.

06/05/2002: beazley
Fixed subtle problems with %rename directive and template
expansion.

Code like this should now work:

%rename(blah) foo<double>::method;
...
template<class T> class foo {
public:
void method();
};

%template(whatever) foo<double>;

06/05/2002: beazley
Resolved some tricky issues of multi-pass compilation and
and inheritance. The following situation now generates
an error:

class Foo : public Bar {
...
};

class Bar {
...
};

The following code generates a warning about incomplete classes.

class Bar;
class Foo : public Bar { };

The following code generates a warning about an undefined class.

class Foo : public Bar { }; // Bar undefined

This fixes a failed assertion bug reported by Jason Stewart.

06/05/2002: ljohnson
[Ruby] Added a warning message for the Ruby module about the lack
of support for multiple inheritance. Only the first base class
listed is used and the others are ignored. (Reported by Craig
Files).

06/03/2002: beazley
Fixed a bug with struct declarations and typedef. For example:

typedef struct Foo Foo;
struct Foo {
...
};

A few other subtle struct related typing problems were
also resolved.

1.3.12

=============================

05/30/2002: beazley
Fixed problem related to forward template class declarations and
namespaces. Bug reported by Marcelo Matus.

05/30/2002: beazley
Added 'make uninstall' target. Contributed by Joel Reed.

05/29/2002: beazley
Fixed rather insidious bug with %rename, %feature and template specialization.
For example:

%exception vector::__getitem__ {
... some exception ...
}

template<class T> class vector {
...
T __getitem__(int index); // Fine
...
};

template<> class vector<int> {
...
T __getitem__(int index); // Oops.
...
};

Now, the %exception directive (and other features) should correctly apply to
both vector and specializations.

05/29/2002: beazley
Subtle changes to %template() directive. Template arguments are now
reduced to primitive types in template matching. For example:

template<class T> class vector<T *> {
... partial specialization ...
}

typedef int *IntPtr; // Gross typedef

// Gets the above partial specialization
%template(vectorIntPtr) vector<IntPtr>;

This change is extremely subtle, but it fixes a number of potential
holes in Luigi's STL library modules. For example:

typedef int Integer;
%template(vectori) vector<int>;

05/29/2002: beazley
Fixed rather insidious typemap bug related to const. const
was being discarded through typedefs.

05/29/2002: ljohnson (Lyle Johnson)
[Ruby] Added input typemaps for const references to primitive
types (in Lib/ruby/ruby.swg).

05/29/2002: cheetah (William Fulton)
[Java] The java arrray support functions are enclosed by
a SWIG_NOARRAYS define. Useful if not using arrays and
it is desirable to minimise the amount of compiled code.

05/29/2002: cheetah (William Fulton)
[Java] Enums were not renamed when using %name or %rename
fix.

05/28/2002: ljohnson
[Ruby] Modified the name of the wrapper functions for the
"new" singleton method and "initialize" instance method for
consistency with the other language modules. The wrapper name
for the function that implements "new" is alloc_classname and
the wrapper name for the function that implements "initialize"
is new_classname.


05/27/2002: beazley
Changes to runtime. Pointer conversion/creation functions
now almost always have an extra "flags" argument. For
example:

SWIG_ConvertPtr(obj, void **, swig_type_info *ty, int flags);
^^^^^^^^^^
This extra parameter is reserved for future expansion and will
be used for more control over pointers in future versions.

05/27/2002: beazley
Fix for C++ classes with private assignment operators. It
is now possible to safely return objects like this by value.
Caveat: the class must provide a copy constructor.

05/26/2002: beazley
-proxy option added to many language modules. This is the
same as -shadow. We are merely changing terminology.

05/26/2002: beazley
[perl] Fixed some inconsistencies in the -package option.
-package merely sets the package name to be used on the
wrappers. It does not change the name of the shared library
file or the name of the generated .pm file. This was
broken at some point, but works again now.

05/25/2002: beazley
[perl] Fixed [ 475452 ] memory leak in return-by-value.
Problem related to static member variables returning newly
allocated objects. Reported by Roy Lecates.

05/25/2002: beazley
[perl] Fixed [ 513134 ] %BLESSEDMEMBERS isn't always right.
Reported by Fleur Diana Dragan.

05/25/2002: beazley
Fixed [ 540735 ] -importall and the -I option.

05/25/2002: beazley
[guile] Fixed [ 532723 ] Default arg for char* can SegV.
Error in guile module. Reported by Brett Williams.

05/25/2002: beazley
Subtle change to typemap application code. The "freearg"
typemap must exactly match up with the "in" or "ignore"
typemap. For example:

%typemap(in) (char *data, int len) { ... }
%typemap(freearg) char *data { ... }

void foo(char *data, int len);

In this case, the "in" typemap is applied, but the
freearg typemap is not. This is because the freearg
typemap doesn't match up with the input argument sequence.

05/25/2002: beazley
Fixed [ 548272 ] Default argument code missing braces.
Reported by Brett Williams.

05/25/2002: beazley
Fixed [ 547730 ] SwigValueWrapper needed for constructors.
Reported by William Fulton.

05/25/2002: beazley
Undefined identifiers now evaluate to 0 when evaluating
preprocessor expressions. For example:

if !FOO
...
endif

where FOO is undefined or set to some non-numeric value.

Fixes [ 540868 ] if defined whatever - not parsed.
Reported by Adam Hupp.


05/24/2002: beazley
SWIG now ignores the C++ 'export' keyword.

05/23/2002: beazley
Some refinement of type-name mangling to account for pointers, arrays,
references, and other embedded type constructs.

05/23/2002: beazley
Initial attempt at supporting template partial specialization. At
the very least, it is parsed and the classes are stored. Matching
of instantiations to specialized version is more limited and based on
the SWIG default typemap rules:

SWIGTYPE *
SWIGTYPE []
SWIGTYPE &

Now, why in the world would you want to use this feature? Other
than allowing for slightly modified class APIs, this capability is
primarily used to provide advanced wrapping support for STL-like
objects. It can also be mixed with typemaps. Here is an example:


/* Generic version */
template<class T> class vector {
%typemap(in) vector<T> * {
// A container of objects
}
};
/* Partial specialization (pointers) */
template<class T> class vector<T *> {
%typemap(in) vector<T> * {
// A container of pointers to objects.
}
};
/* Specialization (integers). */
template<> class vector<int> {
%typemap(in) vector<int> * {
// A container of integers.
}
};

*** EXPERIMENTAL FEATURE ***

05/23/2002: beazley
Enhancement to typemaps. Normally, typemap variables are
renamed to avoid conflicts. For example:

%typemap(in) int * (int temp) {
$1 = &temp;
}

This results in code that creates and uses variables "temp1","temp2",
"temp3" and so forth depending on how many times the typemap is used.
Sometimes you want a single variable instead. To do that, using
the following naming scheme:

%typemap(in) int *(int _global_temp) {
}

Is this case, a single variable _global_temp is emitted in the
wrapper functions. It is shared across all typemaps. Repeated
typemaps do not replicate the variable---they use the first one
emitted.
*** NEW FEATURE ***

05/23/2002: beazley
Minor enhancement to typemaps. If you have this code,

%typemap(in) Foo (int somevar = 3) {
...
}

the default value for somevar is now emitted into the wrapper code.

05/22/2002: beazley
Fixed %extend to be better behaved in namespaces. If you have code
like this:

namespace foo {
struct bar {
%extend {
void blah();
};
};
}

SWIG matches the blah() method to a C function named
void foo_bar_blah(foo::bar *self).

This is consistent with the non-namespace version.
Bug reported by Marcelo Matus.

05/22/2002: beazley
New library files: cpointer.i, carrays.i, cmalloc.i. These
provide access to C pointers and memory allocation functions.
See Doc/Manual/Library.html for details.

05/22/2002: cheetah (William Fulton)
[Java] C type char no longer maps to Java type byte, but to Java type char.
It is now treated as a character rather than a signed number. This fits in
with the other language modules and is a more natural mapping as char* is
mapped as a string of characters. Note that the C signed char type is still
mapped to a Java byte.

*** POTENTIAL INCOMPATIBILITY FOR JAVA MODULE ***

05/22/2002: cheetah (William Fulton)
[Java] Improved constants wrapping. Constants (define and %constant) values
are now obtained through a JNI call. Previously the value was compiled as
Java code, but this didn't work for all cases, eg define 123ULL.

05/22/2002: beazley
Fixed bogus error message with %extend directive and C++
access specifiers. Reported by Marcelo Matus.

05/22/2002: beazley
Namespaces and enums now work correctly. For example:

namespace Foo {
enum Bar { A, B };
}

Bug reported by Marcelo Matus.

05/21/2002: beazley
The %types directive can now be used to specify inheritance relationships
in the runtime type system. For example,

%types(Foo = Bar);

specifies that Foo isa Bar. Using this is potentially quite dangerous.
However, this is useful in certain cases (and in the SWIG library).

05/20/2002: beazley
%nodefault and %makedefault directives now require a trailing semicolon.
For example:

%nodefault;
...
%makedefault;

In addition both directives can take a class name. For example:

%nodefault Foo;

class Foo { /* No default constructor/destructor */
};

class Bar { /* Default constructor/destructor generated */
};

*** POTENTIAL INCOMPATIBILITY ***
If you don't use the trailing semicolon, things will mysteriously break.

05/20/2002: beazley
More improvements to type system handling. SWIG now correctly handles
template names and parameters in a namespace. For example:

namespace foo {
template<class T> class bar { };
typedef int Integer;

void blah(bar<Integer> *x);
};

In the generated code, all of the typenames are properly qualified.

05/17/2002: cheetah (William Fulton)
[Java] deprecated broken -jnic and -jnicpp commandline options. The C or C++
JNI calling convention is now determined from the -c++ commandline option.

05/16/2002: cheetah (William Fulton)
[Java] The JCALL macros which exist so that the same typemaps can be used
for generating both the C and C++ JNI calling conventions no longer appear
in the generated code. This is because the output is now passed through the
SWIG preprocessor which does the macro expansion for either C or C++ (depending
on whether -c++ is passed on the SWIG commandline).

The generation of the functions used in the array typemaps have been adjusted
to take account of this. The side effect is that any typemaps which contained
JCALL macros within %{ %} brackets will have to be moved within {} brackets
so that the SWIG preprocessor can expand the macros.

*** POTENTIAL INCOMPATIBILITY FOR JAVA MODULE ***

05/13/2002: beazley
Class templates may now be used as template parameters. For example:

template<class T, template<class> class C> class Foo {
...
};
template<class T> class Bar {
...
};

%template(Fooi) Foo<int, Bar>;

SWIG doesn't really do anything special with this---it's just
another way of specifying a template parameter.

05/13/2002: beazley
Minor refinement of template support. Template parameter names are no longer
required for types. For example:

template<bool> class Foo {
};

Obviously, names are required for template<class T>;

05/12/2002: beazley
New macro expansion in typemaps. The sequence:

$descriptor(type)

Will expand into the SWIG type descriptor structor for
the given type. Type may be any abstract datatype.
For example:

$descriptor(int *)
$descriptor(int (*)(int,double))
$descriptor(vector<int> *)

Caveat: It is *NOT* currently legal to use other typemap
substitution variables in the macro. For example
$descriptor($1_type).

The primary purpose of this modification is to better
support typemaps for container objects or to allow typemaps
that might be performing type conversions.
*** NEW FEATURE ***

05/11/2002: beazley
The wrapping of references to primitive types has been
changed as follows:

Arguments of type 'const primitive &' are now passed
by value as opposed to pointers. Return values of
type 'const primitive &' are returned as values instead of
pointers.

'primitive' is any one of int, short, long, long long,
char, float, double, bool (as well as unsigned variants).

This change is being made to better support C++ wrapping--especially
code that makes use of templates and the STL.

05/11/2002: beazley
The %template directive can now be used to access templates
in a namespace. For example:

namespace std {
template<class T> class complex {
T re, im;
public:
complex(T _r = T(), T _i = T()) : re(_r), im(_i) { }
T real() { return re; }
T imag() { return im; }
};
}

%template(complex) std::complex<double>;

Note: There are some very subtle namespace/symbol table
management issues involved in the implementation of this.
It may not work in certain cases.

05/10/2002: beazley
Member template constructor support added. For example:

template<typename _T1, typename _T2>
struct pair {
_T1 first;
_T2 second;
pair() : first(_T1()), second(_T2()) { }
template<class _U1, class _U2> pair(const pair<_U1,_U2> &x);
};

To instantiate the template, use %template and %extend.
For example, this expands the constructor into a default
copy constructor:

%extend pair {
%template(pair) pair<_T1,_T2>;
}

Highly experimental. Other uses may be broken.

05/10/2002: beazley
The %extend (%addmethods) directive no longer works unless
it appears in the public section of a class. An error
message is now generated (as opposed to a segmentation fault).

05/09/2002: beazley
New %warnfilter() directive. This directive attaches a warning
filter to specific declarations and has the same semantics as
%rename, %ignore, %feature, and so forth. For example:

%warnfilter(501) foo; // Suppress overloaded warning
int foo(int);
int foo(double);

or

%warnfilter(501) Object::foo(double);
class Object {
public:
int foo(int);
int foo(double);
};

This feature only suppresses warnings in later stages of code
generation. It does not suppress warnings related to preprocessing
or parsing.
*** NEW FEATURE ***

05/09/2002: beazley
SWIG now supports C99 variadic preprocessor macros. For example:

define debugf(fmt,...) fprintf(stderr,fmt,__VA_ARGS__)

The argument "..." is used to indicate variable arguments which
are all placed into the special argument name __VA_ARGS__ in
the macro expansion.

SWIG also implements the GNU () extension for swallowing the
preceding comma when __VA_ARGS__ is empty. For example:

define debugf(fmt,...) fprintf(stderr,fmt, __VA_ARGS__)

Here is how this is expanded:

debugf("%d", 3) --> fprintf(stderr,"%d",3)
debugf("Hello") --> fprintf(stderr,"Hello" )

(notice the deleted comma).
*** NEW FEATURE ***

05/08/2002: samjam (Sam Liddicott)
Many changes to php module. Shadow classes are now implemented
entirely in native C and no need for php-code shadow wrappers
Populated template config.m4 and Makefile.in as needed by
phpize are generated.

05/08/2002: ljohnson (Lyle Johnson)
[Ruby] A copy constructor is now turned into a "clone"
instance method (see Dave's change for copy constructors
dated 4/7/2002). This seems like the appropriate thing
to do for Ruby code.

05/08/2002: ljohnson (Lyle Johnson)
[Ruby] Fixed [ 553864 ] Inline destructor code not written.

05/08/2002: beazley
%ignore behaves better with constructors, destructors, and the
type system in general. For constructors and destructors,
%ignore now suppresses the creation of a default constructor
or destructor. For example:

%ignore ~Foo;
class Foo {
public:
Foo();
~Foo();
...
};

In SWIG-1.3.11, ~Foo() simply "disappeared" and the code generator
created a wrapper for a default destructor (as if it was never
declared in the interface). In SWIG-1.3.12, %ignore suppresses
the creation of a destructor if one is actually defined.

Similarly, even though a declaration is ignored, information
may still be needed to properly handle types. For example, here
is a very subtle error that is fixed by this change:

%ignore std::string; // Prevent class wrapping
namespace std {
class string {
...
};
%typemap(in) string * {
...
}
}

void foo(std::string *s); // Broken.

Before this fix, %ignore would cause the class definition to disappear.
This, in turn, would cause the typemap to be misapplied.

05/08/2002: beazley
Minor changes to %rename, %ignore, %feature, and related directives
for better support of destructors. Destructors can now be precisely
tagged. For example:

%ignore Foo::~Foo;
%feature("action") ~Bar {
...
}

*Developer warning*
Operations such as renaming and feature attachment for classes used to
be applied to destructors as well. For instance, if you did this:

%rename(Bar) Foo;

The operation applied to the class itself, the constructor, and
the destructor. This is no longer the case. Now such operations
will only apply to the class and the constructor. Note: if you
were relying on this for class renaming, be aware that renamed
classes should really only be handled at the level of the class itself
and not the level of individual declarations in the class (although
they can be renamed individually if needed). As far as I know,
the Language class is already taking care of this case correctly.

05/07/2002: beazley
New set of tests. The Examples/test-suite/errors directory contains
tests that try to exercise all of SWIG's error and warning messages.

05/07/2002: beazley
Start of a warning framework. Warning messages are now assigned numeric values
that are shown in warning messages. These can be suppressed using the
-w option. For example:

swig -w302 example.i
swig -w302,305 example.i

Alternatively, the pragma preprocessor directive can be used to disable this:

pragma SWIG nowarn=302
pragma SWIG nowarn=302,305

Note: Since SWIG is a multi-pass compiler, this pragma should
only be used to change global settings of the warning filter. It should
not be used to selectively enable/disable warnings in an interface file.
The handling of pragma occurs in the C++ preprocoessor and affects all
subsequent stages of compilation.

The -Wall option turns on all warnings and overrides any filters that
might have been set.

Warnings can be issued from an interface using %warn. For example:

%warn "110:%section is deprecated"

The first part of a warning message is an optional warning number.
A complete set of warning numbers is found in Source/Include/swigwarn.h.
*** NEW FEATURE ***

05/07/2002: beazley
Internal parsing change. Directives to include files now use brackets [ ... ]
instead of { ... }.

%includefile "foo.i" [
...
]

The use of { ... } was a bad choice because they were included implicitly by
the preprocessor and made it impossible to properly detect legitimate missing '}'
errors.

04/16/2002-
05/02/2002: beazley
SWIG European Tour: Paris-Amsterdam-Bath.

04/23/2002: beazley
The %addmethods directive has been renamed to %extend.
For example:

class Foo {
...
};

%extend Foo {
int blah() { ... };
int bar() { ... };
...
};

Motivation: the %addmethods directive can be used for many
other tasks including adding synthesized attributes, constructors,
and typemaps. Because of this, "addmethods" is somewhat misleading.
%extend more precisely describes this operation---extension of a
class or structure.

*** POTENTIAL INCOMPATIBILITY ***
%addmethods still works via a macro definition. However,
a warning message may be generated. Errors involving %addmethods
will actually refer to the %extend directive.

04/23/2002: beazley
Further refinement of the type system. Typedef now
propagates through functions, pointers to functions,
and pointers to member functions.
For example:

typedef int Integer;
void foo(int (*x)(int), Integer (*y)(Integer));

In this case, arguments 'x' and 'y' have exactly
the same type (and would obviously accept objects
of either type).

Similarly, consider this:

class Foo {
};

typedef Foo Bar;
void bar(int (Foo::*x)(int), int (Bar::*y)(int));

In this case, arguments x and y are the same
type (via typedef).

04/22/2002: beazley
SWIG now generates a warning message if any part of
an expression involves values from a private part of a class.
For example:

class Foo {
private:
static int X;
public:
void blah(int a, int b = X); // Warning
};

In this case, the default argument is ignored. There
are workarounds, but they are rather clumsy. For instance,
you might do this:

%feature("action") blah(int,int) {
if ($nargs == 1) {
result = blah(arg1);
} else {
result = blah(arg1,arg2);
}
}
void blah(int a, int b = 0);


04/21/2002: beazley
Use of the %inline directive inside a namespace is
forbidden and now generates an error message. This is
not allowed since the inlined code that is emitted is
not placed inside a namespace. This confuses other
stages of parsing.

04/21/2002: beazley
Some bug fixes to casting operations and expression
parsing. Due to some parsing issues, it is not
currently possible to use casts for all possible
datatypes. However, the common cases work.

04/20/2002: beazley (Amsterdam)
Member templates now work. Simply use the %template
directive inside a class or %addmethods to create
instantiations (see Doc/Manual/SWIGPlus.html). Supporting
this was easy---earlier changes to templates made it
possible using only a two-line modification to the parser
and a few minor modifications elsewhere. Hmmm, come to
think of it, the smoke was rather thick in that Internet "cafe".
*** NEW FEATURE ***

04/19/2002: beazley (TGV)
Improved handling of non-type template parameters. For example:

vector<int,100>;

Simple numbers and strings can be used with the %template
directive as well. For example:

%template(vecint100) vector<int,100>;

Note: Arithmetic expressions are not currently allowed.

Default template arguments now work and do not have to
be given to %template.

04/18/2002: beazley (Paris)
Change in internal template handling. Template
parameters are now fully integrated into the type
system and are aware of typedefs, etc. This builds
upon the change below.

*** DEVELOPER WARNING ***
Word of caution to language module writers. The "name"
parameter of certain parse tree nodes (classes, functions, etc.)
may be parameterized with types. This parameterization is
done using SWIG type-strings and not the underlying C version.
For example,

int max<int *>(int *,int *)

has a name of "max<(p.int)>". If you use the name directly,
you may get syntax errors in the generated code. To fix this,
use SwigType_namestr(name) to convert a parameterized name
to a C name with valid syntax. The internal version is
used to reduce template types to a common representation
and to handle issues of typedef.

04/16/2002: beazley (somewhere over the Atlantic)
Enhancement of typedef resolution. The type system is now
aware of template arguments and typedef. For example:

typedef int Integer;

foo(vector<int> *x, vector<Integer> *y);

In this case, vector<int> and vector<Integer> are
the same type. There is some interaction between this
mechanism and the implementation of typemaps. For example,
a typemap defined for vector<int> * would apply to either type.
However, a typemap for vector<Integer> * would only apply to
that type.

Typedefs and typemaps and matched by left-most expansion.
For example:

vector<Integer,Integer> -->
vector<int, Integer> -->
vector<int, int>


04/24/2002: cheetah (William Fulton)
[Java] Changes to Java shadow classes.
Overcomes a bug where the module assumed that a pointer to a derived
class could be used in place of a pointer to a base class. Thanks
to Stephen McCaul for analysing the bug and submitting patches.

A consequence is that the getCPtr() method in each shadow class has
disappeared and has been replaced with a getCPtrXXX(), where XXX is the
shadow class name. If you have code that previously used getCPtr(),
and the associated class is wrapping a C struct or a C++ class that
is not involved in an inheritance chain, just use the new method. If
however, the class is involved in an inheritance chain, you'll have
to choose which pointer you really want. Backwards compatibility
has been broken as not using the correct pointer can lead to weird bugs
through ill-defined behaviour. If you are sure you want the old methods,
you could add them back into all shadow classes by adding this at the
beginning of your interface file:

%pragma(java) allshadowcode=%{
public long getCPtr(){
return swigCPtr;
}
%}

Please see entry dated 07/23/2002 to see how to do this after the deprecation
of the allshadowcode pragma.

*** POTENTIAL INCOMPATIBILITY FOR JAVA MODULE ***

04/13/2002: beazley
Fixed problem with default arguments and references. Declarations such
as this should now work:

void foo(const string &x = "Hello");

04/12/2002: beazley
Added typemap $* substitutions for typemaps involving arrays.
Requested by William Fulton.

04/11/2002: beazley
Template specialization is now supported. For example:

template<> class vector<int> {
...
};

When the %template directive is used, it will use a specialization
if one is defined. There are still some limitations. Partial
specialization is not supported. A template of type <void *> does
not match all pointers.
*** NEW FEATURE ***

04/11/2002: beazley
Major change to template wrapping internals. Template declarations are
no longer processed as macros but now result in real parse-tree
nodes. The %template directive expands these nodes into a
specific instantiation. This change enables a number of
new and interesting capabilities:

Directives such as %rename, %feature, and %addmethods can
now be applied to uninstantiated templates. For example:

%rename(barsize) vector::bar(char *buf, int len);
...
template<typename T> class vector {
public:
...
void bar(char *buf);
void bar(char *buf, int len); // Renamed
...
};

%template(intvector) vector<int>; // Renaming carries through


By parsing templates into an internal data structure, it will
be possible to support specialization (and maybe partial
specialization).

This is highly experimental and a work in progress.

*** POTENTIAL INCOMPATIBILITY ***
In SWIG-1.3.11, template declarations were simply processed
as weird macros. No other information was retained. This
made it impossible to support more advanced features and
complicated many other parts of the implementation.

04/09/2002: beazley
Change to template class wrapping. There were a variety of
"issues" with the old approach related to parsing, the type
system, and namespaces. These changes are meant to rectify
some of these problems:

A specific instantiation of a template can now be specified
by including the class inline like this:

class vector<int> {
public:
vector();
~vector();
... whatever ...
};

This is template specialization, but partial specialization is
not yet implemented.

The %template directive has been modified to expand roughly as
follows:

%template(vecint) vector<int>;

becomes

%rename(vecint> vector<int>;
class vector<int> {
public:
vector();
...
};

Note that this simply builds upon the code above (templates
included inline).

This modified approach to wrapping fixes some subtle type
issues. For instance, you can now define typemaps and typedefs
like this:

%typemap(in) vector<int> * {
...
}
typedef vector<int> intvector;
...
void blah(intvector *v); // Gets the above typemap

This did not work in SWIG-1.3.11 due to a peculiarity of
the template implementation.

%template(name) no longer installs the template as a class
with name "name". This might break %addmethods as described
in the manual. For example:

%template(vecint) vector<int>;
%addmethods vecint { // Fails. vecint not a class
...
};

To fix this, just use the template name instead:

%addmethods vector<int> {
...
}

Note: This technique might be a way to implement some bizarre
template specialization techniques. For example:

%addmethods vector<int> {
// Only applied if vector<int> instantiated later
%typemap(in) vector<int> * {
...
}
...
};

*** POTENTIAL INCOMPATIBILITY ***

04/08/2002: beazley
Fixed [ 540868 ] if defined whatever - not parsed. SWIG should
now correctly handle preprocessor directives like this:

if defined __cplusplus
...
endif

Note: was implemented previously, but there was a minor bug.
Reported by Adam Hupp.

04/07/2002: beazley
%readonly and %readwrite are deprecated due to a change in the
implementation. Instead of being pragmas, mutability is now
controlled as a "feature" using the following two directives:

%immutable;
int x; // read-only variable
int y; // read-only variable
%mutable;
int z; // Modifiable

%immutable and %mutable are much more powerful than their older
counterparts. They can now pinpoint a specific declaration like
this:

%immutable x; /* Any x */
%immutable Foo::x; /* x in class Foo */

In fact, the matching algorithm is the same as for %rename,
%ignore, and other directives. This means that the declaration

%immutable Foo::x;

would not only apply to class Foo but to all derived classes
as well.

*** POTENTIAL INCOMPATIBILITY ***
%immutable and %mutable must be terminated by a semi-colon. This
differs slightly from the older %readonly and %readwrite directives.
Since %immutable and %mutable can be applied to declarations the
semicolon is needed to distinguish between a global feature and
one targeted to a single declaration. Note: this incompatibility is the
primary reason for changing the name of the directive.

04/07/2002: beazley
New handling of copy constructors. If a class defines
constructors like this:

class Foo {
public:
Foo();
Foo(const Foo &); // Copy constructor
...
};

SWIG now generates a function copy_Foo() for the copy
constructor.

In previous verions, this generated a name-clash and an
error message. To preserve backwards compatibility, SWIG
does not change the behavior if %rename is used to resolve
the name conflict. However, if no name resolution is made,
this new approach is used.

Copy constructors may be handled as a special case in the
target language. However, this is up to the language module
itself.

04/07/2002: beazley
The %template directive is now namespace aware. This allows
code like this:

namespace foo {
template<typename T> max(T a, T b) { return a > b ? a : b; }
}

using namespace foo;
%template(maxint) max<int>; // Ok

namespace bar {
using foo::max;
%template(maxdouble) max<double>; // Ok
}

Caveat: the template name supplied to %template must be defined in the
same scope in which the %template directive appears. This code is
illegal:

%template(maxint) foo::max<int>;

04/07/2002: beazley
Minor enhancement to preprocessor. The preprocessor can now perform
string comparison. For example:

define A "hello"
...
if A == "hello"
...
endif

The primary use of this is in SWIG macros. For example:

%define FOO(x)
if x == "int"
/* Special handling for int */
...
endif
%enddef

Normal users can probably safely ignore this feature. However, it may
be used in parts of the SWIG library.

04/07/2002: beazley
Further refinement of default constructor/destructor wrapper generation.
SWIG is now much more aware of pure virtual methods. For instance:

class A { /* Abstract */
public:
virtual void method1() = 0;
virtual void method2() = 0;
};
class B : public A { /* Abstract */
public:
virtual void method1() { };
};

class C : public B { /* Ok */
public:
virtual void method2() { };
};

In this case, SWIG will only generate default constructors for C.
Even though B looks fine, it's missing a required method and is abstract.

04/04/2002: beazley
Subtle change to structure data member access. If you
have a structure like this:

struct Foo {
Bar b;
};

The accessor functions for b are generated as follows:

(1) If b is *not* defined as a structure or class:

Bar Foo_b_get(Foo *self) {
return self->b;
}
void Foo_b_set(Foo *self, Bar value) {
self->b = value;
}

(2) If b *is* defined as a structure or class:

Bar *Foo_b_get(Foo *self) {
return &self->b;
}
void Foo_b_set(Foo *self, Bar *value) {
self->b = *value;
}
See the "Structure data members" section of Doc/Manual/SWIG.html
for further details.

*** POTENTIAL INCOMPATIBILITY ***
This may break interfaces that relied on a lot of a undeclared
structure and class names. To get the old behavior, simply
use a forward declaration such as "struct Bar;"

04/04/2002: beazley
C++ namespace support added. SWIG supports all aspects of
namespaces including namespace, using, and namespace alias
declarations. The default behavior of SWIG is to flatten
namespaces in the target language. However, namespaces are
fully supported at the C++ level and in the type system.
See Doc/Manual/SWIGPlus.html for details on the implementation.

04/02/2002: cheetah (William Fulton)
[Java] Sun has modified javac in jdk1.4 to no longer compile
an import of an unnamed namespace. To fix this SWIG no longer
generates the import for packageless classes.
http://developer.java.sun.com/developer/bugParade/bugs/4361575.html
As reported SF 538415.

03/27/2002: ljohnson (Lyle Johnson)
[Ruby] Added support for pointer-to-member, similar to that
for the Python module. Remarkably similar. Also added a new
example for this (Examples/ruby/mpointer), which is remarkably
similar to the Python example of the same name.

03/26/2002: ljohnson (Lyle Johnson)
[Ruby] Made a few minor edits to the "Advanced Topics"
chapter of the SWIG manual and added a new major section
about how to create multi-module Ruby packages with SWIG.

03/26/2002: ljohnson (Lyle Johnson)
[Ruby] Removed all of the old Ruby pragmas. If any of this
functionality is truly missed we can resurrect it, preferably
with some kind of feature-based directive.

03/25/2002: ljohnson (Lyle Johnson)
[Ruby] Fixed SWIG exception library support for Ruby, which
has apparently been broken for some time. Luckily, no one seems
to have noticed.

03/23/2002: beazley
C++-namespace support in SWIG directives.

%addmethods:

The %addmethods directive now accepts a fully qualified classname
and can be used inside C++ namespace declarations. For example:

// Attaches to the class Foo::Bar below
%addmethods Foo::Bar {
int somemethod() { ... }
};

namespace Foo {
class Bar {
public:
...
};

// Attaches to the class Bar above
%addmethods Bar {
int othermethod() { ... };
}
}

%feature, %rename, %ignore, %exception, and related directives:

Namespaces are fully integrated into the renaming and declaration
matcher. For example:

%rename(display) Foo::print; // Rename in namespace Foo
%ignore Foo::Bar::blah; // Ignore a declaration

%rename directives can be placed inside namespace blocks as well. For
example:

namespace Foo {
%rename(display) print; // Applies to print below

void print();
};

Most other SWIG directives should work properly inside namespaces.
No other changes are needed.

03/22/2002: beazley
Some changes to internal symbol table handling. SWIG no longer
manages structures and unions in a separate namespace than normal
declarations like ANSI C. This means you can't have a structure
with the same name as a function. For example:

struct Foo {
...
}

int Foo() { ... }

This approach is more like C++. It's not clear that SWIG ever
really supported the ANSI C anyways---using the same name would
almost certainly generate a name-clash in the target language.

03/22/2002: ljohnson (Lyle Johnson)
[Ruby] Fixed [ 517302 ] for handling of renamed overloaded
constructors. Now, renamed overloaded constructors are converted
into class singleton methods (basically acting as "factory"
methods).

03/21/2002: beazley
Fixed [ 532957 ] %ignore parse error and casting operator.
Reported by William Fulton.

03/18/2002: beazley (** ADVANCED USERS ONLY **)
Added support for dynamic casting in return values. A somewhat
common problem in certain C++ programs is functions that hide
the identity of underlying objects when they are returned
from methods and functions. For example, a program might include
some generic method like this:

Node *getNode();

However, Node * may just be base class to a whole hierarchy
of different objects. Instead of returning this generic Node *,
it might be nice to automatically downcast the object into the
appropriate type using some kind dynamic cast.

Assuming you understand the peril involved, a downcast can now
be performed using the following function in the run-time type
checker:

swig_type_info *SWIG_TypeDynamicCast(swig_type_info *, void **ptr);

This function checks to see if the type can be converted to another
type. If so, a different type descriptor (for the converted type)
is returned. This type descriptor would then be used to create
a pointer in the target language.

To use this, you would write a typemap similar to this:

%typemap(out) Node * {
swig_type_info *ty = SWIG_TypeDynamicCast($1_descriptor, (void **) &$1);
$result = SWIG_NewPointerObj($1, ty);
}

Alternatively,

%typemap(out) Node * = SWIGTYPE *DYNAMIC;

To make the typemap have any effect, you have to write a supporting
function that knows how to perform downcasting. For example:

%{
static swig_type_info *
Node_dynamic_cast(void **ptr) {
Node **nptr = (Node **) ptr;
Element *e = dynamic_cast<Element *>(*nptr);
if (e) {
*ptr = (void *) e;
return SWIGTYPE_p_Element;
}
Data *d = dynamic_cast<Data *>(*nptr);
if (d) {
*ptr = (void *) d;
return SWIGTYPE_p_Data;
}
return 0;
}
%}

There is no restriction on how types are determined. dynamic_cast<>
uses C++ RTTI. However, if you had some other mechanism for determining
the type, you could use that here. Note: it is important to save
the new pointer value back into the argument as shown. When downcasting,
the value of the pointer could change.

Finally, to make the casting function available, you have to register
it with the run-time type checker. Put this macro in your interface file.

DYNAMIC_CAST(SWIGTYPE_p_Node, Node_dynamic_cast);

Note: this feature does not introduce a performance penalty on
normal SWIG operation. The feature is only enabled by writing
a new typemap that explicitly calls SWIG_TypeDynamicCast() to
make a conversion.

Examples/test-suite/dynamic_cast.i contains a simple example.
This feature is not supported in the Java module due to differences
in the type-checking implementation.

*** EXPERIMENTAL FEATURE ***

03/17/2002: beazley
Small change to type-name handling of unnamed structures and
typedef. If a structure of this form appears:

typedef struct {
...
} Foo;

Then 'Foo' is used as the proper typename for the structure.
Furthermore, Foo can now be used as a name in C++ inheritance.
SWIG was already kind of doing this, but this modification refines
the implementation to more closely follow the C++ ARM, section
7.1.3, p. 106. This fixes a couple of obscure corner cases.

03/16/2002: beazley
Modified C++ inheritance with a few enhancements. First, type information
needed for casting and type-equivalence is generated even when base-classes
aren't defined in the interface. For example:

class Foo : public Bar { /* Bar unspecified */
public:
...
};

void blah(Bar *b);

In this case, the blah() function still accepts Foo * even though nothing
is really known about Bar. Previous SWIG versions would just generate
a type error.

Inheritance has also been modified to work through typedef. For example:

class Bar {
};

typedef Bar OtherBar;
class Foo: public OtherBar {
}

In this case, the base class of OtherBar is correctly resolved back to
Bar. The use of the name OtherBar is lost in this resolution (the wrappers
will simply use Bar instead of the typedef name OtherBar).

03/13/2002: beazley
%typemap, %apply, and related directives can now appear inside
class definitions.

03/13/2002: beazley
Fixed a variety of problems related to compiling SWIG on 64-bit
platforms.

03/12/2002: beazley
Fixed problem with "ignore" and "in" typemaps. Local variables
associated with "in" were being added to the wrapper function even
though they were never used. Mostly harmless, but it would lead
to a variety of compilation warnings.

03/12/2002: beazley
Some changes to the internal type system and handling of nested C++
types. In previous versions of SWIG, if you had the following:

class Foo {
public:
typedef int Blah;
};
class Bar : public Foo {
public:
void somemethod(Blah x);
};

The argument type in somemethod() would implicitly be set to Bar::Blah.
Although this is technically allowed, it breaks typemaps. For example:

%typemap(in) Foo::Blah { ... }

doesn't match like you expect. This has been changed in SWIG-1.3.12.
Now, types are expanded using the class in which they were defined.
So, the argument type in somemethod() will be Foo::Blah---since the
type Blah was defined in Foo.

03/10/2002: beazley
Fixed some subtle type scoping problems with typedef and C++ classes.
For example:

typedef int Blah;
class Bar {
public:
typedef double Blah;
void foo(Blah x, ::Blah y);
...
}

03/10/2002: beazley
Highly experimental change to handle variable length arguments.
First, there is no portable or reliable way to wrap
a varargs function in full generality. However, you *can* change
the function signature using %varargs.

%varargs(char *) fprintf;
...
void fprintf(FILE *f, char *fmt, ...);

In this case, the variable length parameter "..." is
simply replaced by the parameters given in %varargs. This
results in a function like this:

void fprintf(FILE *f, char *fmt, char *s);

More than one argument can be used and default values
can be defined. For example, this code specifies a
maximum of four arguments.

%varargs(char *x1 = 0, char *x2 = 0, char *x3 = 0, char *x4 = 0) fprintf;

*** EXPERIMENTAL NEW FEATURE ***

03/10/2002: beazley
Change to handling of variable length arguments. varargs
is now handled as a proper parameter and is passed to the
code generator. However, it still can't be handled correctly
(and will generate a typemap warning). This change has been
made to better incorporate variable length arguments with other
directives such as %ignore, %rename, %feature, and so forth.

03/10/2002: beazley
Fixed [ 522555 ] Syntax error parsing "define" construct. SWIG
is a little more restrictive in determining define statements
that will be wrapped as constants. Also added a better parser
error rule for handling bad constants.

03/08/2002: cheetah (William Fulton)
[Java] Bug fix: Classes renamed with %rename that are derived from
another class generate more appropriate shadow class code.

03/08/2002: cheetah (William Fulton)
[Java] Fixed SF [ 523632 ] and [ 513335 ] both reported by Israel
Tanner. Support for types that are used which are in a typedef. The
appropriate shadow class name is generated. Also generated correct
shadow classname when a templated class is used within another
templated class. See the cpp_typedef.i testcase.

03/08/2002: cheetah (William Fulton)
[Java] Bug fix: No type was generated in shadow classes for types
that weren't wrapped by SWIG. The type is treated as a raw
pointer, ie no shadow class.

02/22/2002: beazley
Refined the matching algorithm used by %rename, %ignore, and
%feature. If a type signature is supplied, it must exactly
match that used in the declaration---including any use of
const. For example:

%rename(foo1) foo(int);
%rename(bar1) bar(int) const;

class Blah {
public:
void foo(int); // Matched --> foo1
void foo(int) const; // Not matched
void bar(int); // Not matched
void bar(int) const; // Matched --> bar1
}

In previous versions, a non-const specification would match
both the non-const and const declarations. However, the whole
point of %rename and related directives is that they be able
to precisely pinpoint exact declarations in an interface. This
fixes the problem.

02/21/2002: beazley
Reworked the handling of default constructor and destructors.
SWIG now makes a preliminary pass over the parse tree to discover
which classes support default allocation. This fixes a number
of very subtle issues in code generation and call/return by value.

02/18/2002: cheetah (William Fulton)
Improved support on Cygwin: Perl, Python, Tcl, Ruby and Java should
work out of the box, barring the runtime library. Removed dllwrap
and replaced with newly working gcc -shared instead for Cygwin.
All this will require the new improved binutils 20010802 and later,
but the latest Cygwin is usually the best recommendation.

02/15/2002: beazley
Fixed some problems related to wrapping of global variables
and Perl shadow classes. Reported by Chia-liang Kao.

02/15/2002: ljohnson (Lyle Johnson)
[Ruby] Made a fix to the code generation for C++ class
constructors so that we get both a "new" singleton method
and an "initialize" instance method for each class. This
change enables developers to derive new Ruby classes from
SWIG-wrapped C++ classes and then override their initialize
methods to provide subclass-specific instance initialization.

02/15/2002: ljohnson (Lyle Johnson)
[Ruby] Massive documentation update for the Ruby module,
contributed by Craig Files.

02/14/2002: ljohnson (Lyle Johnson)
[Ruby] Bug fix: An error in the SWIG runtime support for Ruby
was causing several of the examples to fail. Reported by
William Fulton.

02/14/2002: ljohnson (Lyle Johnson)
[Ruby] Bug fix: Enumerations defined within a class (such
as those seen in the Examples/ruby/enum example) were not
being exported with the correct names. Reported by William
Fulton.

02/13/2002: ljohnson (Lyle Johnson)
[Ruby] Added a warning message when we run across overloaded
class constructors for C++ code, that this is currently not
supported (even if the overloads have been %renamed). For an
example of where this doesn't work, see Examples/ruby/operator.

02/13/2002: ljohnson (Lyle Johnson)
[Ruby] Added an "ignored" warning message when the parser runs
across an operator!=() declaration for C++ code.

02/11/2002: ljohnson (Lyle Johnson)
[Ruby] Added the "import", "import_template", "operator" and
"template" examples.

02/11/2002: ljohnson (Lyle Johnson)
[Ruby] Added multi-module support.

02/09/2002: ljohnson (Lyle Johnson)
[Ruby] Added the missing "define SWIG_NOINCLUDE" at the top of
the wrapper code when the '-c' option is used.

02/09/2002: ljohnson (Lyle Johnson)
Corrected a minor off-by-one error for the size of the
swig_types[] array that's generated in the wrapper code.

02/08/2002: beazley
Fixed SF [ 515058 ] Wrong code for C++ templates.
Reported by Israel Taller.

1.3.11

=================================

01/30/2002: beazley
Fix to pass/return by value for C++ objects that define
no default constructor. Changes to the typemap system
made it impossible to wrap C++ objects with no default
constructor. This has been fixed, but the solution
involves some clever template magic contributed by
William Fulton. Please see the comments in the file
Lib/swig.swg for further details. This solution is
experimental and may be refined in a future release.

01/30/2002: beazley
Global variables and member data of type "const char *"
can be set, but the old value is silently discarded without
any garbage collection. This may generate a memory leak.
This change is needed to more safely handle variables
like this:

const char *foo = "Hello World\n";

In this case, it's not safe to free the old value. However,
SWIG can dynamically allocate a new value and make foo point
to it. To fix this memory leak, you can probably do this:

%clear const char *foo;
%apply char * {const char *foo};

*** POTENTIAL INCOMPATIBILITY ***

01/30/2002: beazley
Two minor typemap enhancements have been added. First,
typemaps can issue a warning message by including a special
warning attribute. For example:

%typemap(in,warning="I'm going to do something dangerous") ...

The warning message will show up whenever the typemap is
applied.

Second, a typemap can force a no-match by defining

%typemap(in) sometype "pass"

If this is used, the typemap system will *not* record a
typemap match for "sometype". This can be used to block
selected typemaps. For example, if you wanted to disable
a typemap feature for some type, you could do this.

// Do not allow global variables of type 'const char *' to be set.
%typemap(varin) const char * "pass"

It might also be possible to use this to do subtle and
strange things with typemaps. For example, if you wanted to
make 'blah *' an output value and 'const blah *' an input
parameter, you might do this:

%typemap(ignore) blah *(blah temp) {
$1 = &temp;
}
%typemap(argout) blah * {
... return a value ...
}
/* Block unqualified typemaps defined above */
%typemap(ignore) const blah * "pass"
%typemap(argout) const blah * "pass"
%typemap(in) const blah * {
... get input value ...
}

(This potential applications of typemaps suggested by Greg Stein).
*** NEW FEATURE ***

01/29/2002: cheetah (william fulton)
[Java] Bug fix: No enumerations were wrapped when the -shadow
commandline option was not specified. Reported by Israel Taller.

01/28/2002: cheetah (william fulton)
[Java] Global arrays are successfully wrapped. In fact they started
mostly working in SWIG-1.3.10.

01/28/2002:richardp
Added first attempt at C++ and -shadow support for PHP4 module,
please test and mail me if any problems/ideas on improving it.

There is a known problem with uninitialized member variables,
please see Examples/php4/sync/README for details.

Also more PHP documentation added to Doc/Manual/Php.html

01/27/2002:beazley
The ANSI C size_t type is now recognized as an integer by default.

01/26/2002:beazley
long long and unsigned long long support added to many language modules.
This is not a portable feature and will require compiler support
for the long long type. In target languages that do not support
long long (e.g., Tcl and Perl), numbers are converted to a string
of digits. This prevents their use in arithmetic calculations, but
still allows values to be set from a string.

long long support requires the use of the strtoll() and strtoull()
functions as well as the 'lld' and 'llu' format specifiers
of sprintf().

01/26/2002:beazley
Fixed [ 501827 ] Delete method is not called. The Tcl
module wasn't correctly calling destructors when they
were defined using %addmethods. This has been fixed.
Reported by Reinhard Fobbe.

01/26/2002: beazley
Better support for long long and unsigned long long. Typemaps
have been included in a number of modules for handling these types.
In addition, the parser has been modified to accept long long
literals such as 1234LL and 1234ULL.

01/27/2002: cheetah (william fulton)
[Java] A C char[] is mapped to a Java String which is the default
SWIG handling of char[] and char*. It used to be mapped to byte[].
Note that a C signed char[] array is mapped to byte[].

*** POTENTIAL INCOMPATIBILITY ***

01/25/2002: beazley
Fixed a problem with return-by-value, C++, and
objects that define no default constructor.
Reported by Joel Reed.

01/25/2002: cheetah (william fulton)
[Java] Overhaul of the Java module. The C code generation is now
done from typemaps.

01/24/2002: cheetah (william fulton)
[Java] Support for arrays of enum pointers

01/20/2002: cheetah (william fulton)
[Java] Error checking for null Java objects being passed to native
functions. Exception thrown now whereas before the JVM crashed.

01/18/2002: cheetah (william fulton)
[Java] Corrected behaviour for functions that take arrays. For
example, when this c function:

void arrayfn(int array[]);

is wrapped the corresponding native function

public final static native void arrayfn(int[] array);

is produced. Previously if the C function made any changes to the
array elements, these were not reflected back into the Java array.
This has now been corrected so that the changes are propogated back
to Java and the calling function will see these changes. This is
how pure Java functions work, ie arrays are passed by reference.

01/15/2002:mkoeppe
[Guile] New file cplusplus.i with C++ typemaps contributed
by Marcio Luis Teixeira <marciotholly.colostate.edu>.

01/11/2002: cheetah (william fulton)
[Java] Changed mapping of C long to Java type. Was mapped to Java
long, now mapped to Java int. If you want the previous mapping to
Java long use this approach in your interface file:

%clear long;
%typemap(jni) long "jlong"
%typemap(jtype) long "long"
%typemap(jstype) long "long"

%clear long[ANY];
%typemap(jni) long[ANY] "jlongArray"
%typemap(jtype) long[ANY] "long[]"
%typemap(jstype) long[ANY] "long[]"
%typemap(in) long[ANY] {write me for array support}
%typemap(out) long[ANY] {write me for array support}
%typemap(argout) long[ANY] {write me for array support}
%typemap(freearg) long[ANY] {write me for array support}

*** POTENTIAL INCOMPATIBILITY ***

This new mapping is more appropriate when interfacing to 32 bit
applications which are used in the current 32-bit JVMs. For future
64-bit JVMs you may have to change these mappings - eg on Unix LP64
systems, but not on Microsoft 64bit Windows which will be using a
P64 IL32 model. This may be automated in a future version of SWIG.

01/10/2002:beazley
Fixed [ 501677 ] %init block in wrong place. Reported
by Luigi Ballabio.

01/09/2002: cheetah (william fulton)
[Java] Default support for the long long type. signed long long is
mapped to a Java long. unsigned long long is mapped to BigInteger.

01/09/2002:beazley
Experimental change to parser to better support mixing of
int, long, short, unsigned, float, and double. The parser
should now support types like this:

short unsigned int
int unsigned short
unsigned short int
unsigned int short

This change also enables a type of 'long double' (previously
unsupported) to be used.
*** NEW FEATURE ***

01/05/2002: cheetah (william fulton)
[Java] Casting fix for when function return type is a pointer as
reported by Gary Pennington 2002-01-05. The upper 32bits of the
64 bit jlong will have contained junk for 32bit pointers.

01/05/2002: cheetah (william fulton)
[Java] Better pointer handling in Java is possible as the
INPUT, OUTPUT and INOUT typemaps have been added into typemaps.i.

01/05/2002: cheetah (william fulton)
[Java] $null can be used in input typemaps to return early from JNI
functions that have either void or a non-void return type. Example:

%typemap(check) int * %{
if (error) {
SWIG_exception(SWIG_IndexError, "Array element error");
return $null;
}
%}

If the typemap gets put into a function with void as return, $null
will expand to nothing:

void jni_fn(...) {
if (error) {
SWIG_exception(SWIG_IndexError, "Array element error");
return ;
}
...
}

otherwise $null expands to zero, where javareturntype is either a
pointer or a primitive type:

javareturntype jni_fn(...) {
if (error) {
SWIG_exception(SWIG_IndexError, "Array element error");
return 0;
}
...
}

01/02/2002: cheetah (william fulton)
[Java] The Java module incorrectly used argout typemaps for
strings. This is now corrected and the code now resides
in the freearg typemap. The argout array typemaps have been split into
argout and freearg typemaps. This correction may require some user
written typemaps to be modified.
*** POTENTIAL INCOMPATIBILITY ***

12/28/2001: cheetah (william fulton)
[Java] Multi typemaps now working for Java see multimap example.
[Java] Fix for recently introduced bug - freearg typemap code was appearing
before the function call.

12/28/2001: cheetah (william fulton)
[Java] JCALL macro for JNI calls that work in both C and C++ typemaps
have been replaced with JCALL0, JCALL1, JCALL2, JCALL3 and JCALL4
macros.
*** POTENTIAL INCOMPATIBILITY ***

12/22/2001:beazley
Resolved some inconsistent behavior with %rename and class renaming.
If you specify the following:

%rename(Foo) Bar;

class Bar {
public:
Bar();
~Bar();
}

Then the %rename directive applies to the class itself, the constructor,
and the destructor (all will be renamed to Foo).

If a class defines more than one constructor, the overloaded variants
can still be renamed by specifying parameters to %rename. For example:

%rename(Bar_copy) Bar(Bar &);
class Bar {
public:
Bar();
Bar(Bar &);
~Bar();
};

There are still some odd corner cases. If you specify

%rename(Foo) ::Bar;

then only the name of the class is changed and the constructor/destructor
names are left unmodified. If you specify

%rename(Foo) *::Bar;

then the names of the constructor/destructor functions are modified but
the name of the class is not.

12/21/2001: cheetah (william fulton)
[Java] jni, jtype and jstype typemaps no longer hardcoded but real
typemaps. New variable substitution, $javaclassname, can be used in
the jstype typemaps. It is replaced with the Java shadow class name
where applicable.
[Java] Fix for recently introduced bug to do with inheritance when
using %import.
[Java] A few more bug fixes, todo with %rename and using the kind
with the type, eg
void fn(union uni myuni, struct str mystr, class cl mycl);

12/20/2001:beazley
Fixed [ 494524 ] Preprocessor bug - apostrophe and subst.

12/20/2001:beazley
Added SWIG_VERSION preprocessor symbol. This is a hexadecimal
integer such as 0x010311 (corresponding to SWIG-1.3.11). This can
be used in the interface as follows:

if SWIG_VERSION >= 0x010311
/* Use some fancy new feature */
endif

Note: The version symbol is not defined in the generated SWIG
wrapper file.

*** NEW FEATURE ***

12/20/2001:mkoeppe
[MzScheme]: Renamed mzswig_make_boolean to
swig_make_boolean, as the latter is used in the typemaps.
Reported by Luigi Ballabio.

12/17/2001:mkoeppe
[Guile]: Rewrote list-vector.i using multi-dispatch
typemaps. Updated pointer-in-out.i. Make the
deprecated typemap-substitution of "$source" in "argout"
work as before.

12/16/2001:mkoeppe
[Guile]: Fixed macros %values_as_list, %values_as_vector,
%multiple_values to use the proper %pragma syntax. New
Guile example/test "multivalue"; new Guile run-test for
test-suite item "list-vector" (currently broken).

12/14/2001:mkoeppe
[Guile]: Fixed typemap-substition bug for "varin". Relaxed
valid-identifier check to allow all R5RS identifiers.

1.3.10

==================================

12/08/2001:beazley
Modified %typemap so that %{ ... %} can also be used as a
code block (mostly for completeness). For example:

%typemap(in) blah %{
...
%}

This form does not introduce a new block scope. Also, the
code enclosed in %{ ... %} is not processed by the preprocessor.

12/08/2001:beazley
Fixed [ 459614 ] SWIG with multiple TCL interpreters.

12/08/2001:beazley
Fixed [ 417141 ] rubydec.swg is wrong
Reported by Paul Brannan.

12/08/2001:beazley
Fixed [ 410557 ] Problem with %addmethods on NT.
Reported by Magnus Ljung.

12/08/2001:beazley
Fixed [ 445233 ] Enhancement: handle access change.
SWIG now parses (but ignores) C++ access changes for the
the following:

class A {
protected:
void something() { }
public:
A() {}
};

class B : private A {
public:
B() : A() { }
protected:
A::something; <---- Parsed, but ignored
};

Suggested by Krzysztof Kozminski.

12/08/2001: cheetah (william fulton)
Fix for Ruby to work using Visual C++.

12/06/2001:beazley
Fixed [ 465687 ] unsigned short parameters fail.
Reported by Gerald Williams.

12/06/2001:beazley
Fixed SF [ 489594 ] PyString_FromString can't take NULL arg.
Reported by John Merritt. SWIG now converts string values
to Python using code like this:

resultobj = result ? PyString_FromString(result) : Py_BuildValue("");

12/06/2001:beazley
Fixed SF [ 463561 ] Type conversions not generated.
Reported by Gerald Williams.

12/04/2001:beazley
Fixed SF [ 470217 ] Tcl default argument handling.
Reported by Shaun Lowry.

12/04/2001:beazley
Fixed SF [ 472088 ] defined(MACRO) expanded everywhere.
Embedded preprocessor directives such as

%if defined(FOO)

are not expanded by the SWIG preprocessor.
Reported by Gerald Williams.

12/04/2001:beazley
Fixed SF [ 476467 ] Problems with define & commas.

12/04/2001:beazley
Fixed SF [ 477547 ] wrong declaration of pointer functions.
Bad prototypes in Lib/tcl/ptrlang.i.

12/04/2001:beazley
Fixed SF [ 483182 ] Constants can take args by mistake.
When swig -perl5 -const is used, constants are declared
with a void prototype. For example:

sub ICONST () { $examplec::ICONST }

Patch submitted by Rich Wales.

12/03/2001:beazley
New %exception directive. This is intended to replace %except.
It works in exactly the same manner except it does not accept a
language specifier. For example:

%exception {
try {
$action
}
catch(SomeError) {
error
}
}

%exception is also name aware---allowing it to be applied to
specific declarations in an interface. For example:

%exception foo {
...
exception for any function/method foo
...
}

%exception Foo::bar {
...
exception for method bar in class Foo
...
}

%exception Foo::bar(double) {
...
exception for method bar(double) in class Foo
...
}

The semantics of this name matching is exactly the same as for %rename.
*** NEW FEATURE ***

12/03/2001:beazley
Substantial cleanup of the Python shadow class code. Shadow classes
used to be created in this rather complicated manner involving about
a half-dozen strings created in bits and pieces. Shadow classes
are now generated in a more straightforward manner--in the same
order that appears in the interface file.

*** POTENTIAL INCOMPATIBILITY ***
The order in which declarations appear in the shadow file may differ.

12/03/2001:beazley
The %insert directive (%{ ... %}, %runtime, %header, %wrapper, etc.)
can now be used inside of a class definition. This has potential
uses when generating shadow class code. For example:

class Foo {
...
%insert("shadow") %{
Some python code
def blah(self):
print "I'm blah!"
%}
...
};

The support for class code insertion depends on the language module.
However, the intent of this feature is to simplify the task of extending
shadow class code. In the Python module, this inserts code with the
proper level of indendation (regardless of what was used in the SWIG
interface).
*** NEW FEATURE ***

11/29/2001: cheetah (william fulton)
Modifications for Java and Python modules to work on cygwin.
Unfortunately a lot of the python module has started to produces code
which cannot be auto-imported using cygwin libtools so most of it is
still broken.

11/28/2001:beazley
The %rename and %feature directive can now be used inside
of a class definition. For example:

class Foo {
%rename(foo_i) foo(int);
%rename(foo_d) foo(double);
public:
...
void foo(int);
void foo(double);
...
};

When used in this manner, the %rename directive only applies
to members of the class in which it appears as well as all
derived classes. In fact, this is really just the same
as saying:

%rename(foo_i) Foo::foo(int);
%rename(foo_d) Foo::foo(double);
class Foo {
...
};

*** NEW FEATURE ***

11/26/2001:beazley
Added the experimental %feature directive. %feature can be
used to attach arbitrary string attributes to parse tree nodes.
For example:

%feature("except") blah {
try {
$function
} catch (Error) {
whatever;
}
}

or

%feature("set") *::x_set "x";

or

%feature("blah") Foo::bar(int,double) const "spam";

The syntax is borrowed from the %rename directive. In fact, the
exact same semantics apply (inheritance, matching, etc.).

%feature is a very powerful low-level primitive that can be used to
customize individual language modules and to provide hints to
any stage of code generation. Features are attached to
parse tree nodes as attributes with names like "feature:*" where *
is replaced by the feature name (e.g., "feature:except", "feature:set",
etc.). Language modules can then look for the features using
a simple attribute lookup.

%feature is intended to be a replacement for a number of
older SWIG directives including %except and specialized
pragmas. It is more powerful (due to its parameterized
name matching) and it provides very precise control over
how customization features are attached to individual
declarations. There are future expansion plans that will
build upon this capability as well.

It's not certain that %feature will ever be used directly
by SWIG users. Instead, it may be a low-level primitive
that is used in high-level macro definitions. For instance,
to support properties, you might define a macro like this:

%define %property(name, setf, getf)
%feature("set") setf name;
%feature("get") getf name;
%enddef

Which allows a user to specify things like this:

%property(p, get_p, set_p);

class Blah {
public:
int get_p();
void set_p(int);
};

*** EXPERIMENTAL NEW FEATURE ***

11/24/2001:beazley
The Tcl module has been expanded with some new features for
managing object ownership. For example:

set c [Circle -args 20]
$c area Invoke a method
$c -disown Releases ownership of the object
$c -acquire Acquires ownership of the object

If Tcl owns the object, its destructor is invoked when the
corresponding object command is deleted in Tcl.

To simplify the destruction of objects, the following syntax
can be used:

$c -delete Delete an object

This is an alternative for the more obscure variant of

rename $c {}

These features also add functionality at the C API level.
The following functions manage ownership from C and
can be used in typemaps.

SWIG_Acquire(void *ptr);
SWIG_Disown(void *ptr);

A new function for constructing instances is also available:

Tcl_Obj *
SWIG_NewInstanceObj(Tcl_Interp *interp, void *ptr,
swig_type_info *type, int own);

When used in a typemap, this creates a pointer object and
an interpreter command that can be used to issue methods and
access attributes as shown above.
*** NEW FEATURE ***

11/23/2001:beazley
All Python-related %pragma operations have been eliminated.
Most of these were written for older SWIG versions in order to
compensate for limitations in earlier releases. In an effort
to reduce the amount of code-clutter and potential for errors,
it is easier to simply eliminate the pragmas and to start over
(if needed). To be honest, I'm not even sure the pragmas
worked in 1.3.9 and recent releases.

Note: If you need to insert code into the shadow class file
created by SWIG, simply use the %shadow directive like this:

%shadow %{
def some_python_code():
print "blah!"
%}

*** POTENTIAL INCOMPATIBILITY ***

11/22/2001:beazley
Sweeping changes to the way in which the Python module handles
shadow classes. In early implementations, shadow classes were
merely Python wrappers around typed pointer objects. However,
some users actually wanted to receive the shadow class object in C.
To accommodate this, the dereferencing of the "this" pointer in
a shadow class was moved to C as described in CHANGES [8/8/99].
However, the process of returning pointers to Python was still
somewhat problematic. Specifically, shadow classes never worked
in situations such as these:

- Use of any kind of output typemap ('out' or 'argout')
- Global variables (broken as far as I can tell).

In the past, some users have dealt with this by manually trying
to create shadow class objects themselves from C/C++. However,
this was difficult because the C wrappers don't really know how
to get access to the corresponding Python class.

The Python module has now been modified to automatically attach
shadow class objects to pointers when they are returned to
Python. This process occurs in the function SWIG_NewPointerObj()
so the process is completely transparent to users. As a result,
shadow classes are now more seamlessly integrated with typemaps
and other features of SWIG.

This change may introduce a number of incompatibilities. The
SWIG_NewPointerObj() now takes an extra parameter "own" to
indicate object ownership. This can be used to return a pointer
to Python that Python should destroy. In addition, older code
that tries to manually construct shadow class objects or which
expects bare pointers may break---such pointers may already be
encapsulated by a shadow class.
*** POTENTIAL INCOMPATIBILITY ***

11/20/2001:beazley
Modified the %insert directive to accept single braces { ... }.
For example:

%insert("header") {
... some code ...
}

This works exactly like %{ ... %} except that the code in the
braces is processed using the preprocessor. This can be useful
in certain contexts such as low-level code generation in
language modules.
*** NEW FEATURE ***

11/20/2001:beazley
Command line options are now translated into preprocessor
symbols. For example:

./swig -python -shadow -module blah interface.i

Creates the symbols:

SWIGOPT_PYTHON 1
SWIGOPT_SHADOW 1
SWIGOPT_MODULE blah

Modules can look for these symbols to alter their code generation
if needed.
*** NEW FEATURE ***

11/20/2001:beazley
Massive overhaul of the Perl5 module. A lot of code generation is
now driven by tables and typemaps. The generated wrapper code
also makes use of tables to install constants, variables, and
functions instead of inlining a bunch of procedure calls. The
separate variable initialization function is gone. Most
code generation is controlled via the perl5.swg file in the
library.
*** POTENTIAL INCOMPATIBILITY ***

11/13/2001:beazley
Added parsing support for the C++ typename keyword. Primarily this
is added to better support templates. For example:

template<typename T> void blah(C& v) {
typename C::iterator i = v.begin();
}

Note: typename is supported in the parser in the same way as 'struct'
or 'class'. You probably shouldn't use it anywhere except in templates.
*** NEW FEATURE ***

11/11/2001:beazley
Massive overhaul of the language module API. Most functions now
use a common, very simple, API. There are also a number of
interesting semantic side-effects of how code is actually generated.
Details will be forthcoming in Doc/Manual/Extending.html.

*** POTENTIAL INCOMPATIBILITY *** Language modules written for
previous versions of SWIG will no longer work,

11/10/2001:beazley
Fixed a very subtle bug due to unnamed class wrapping. For example, if
you did this

typedef struct {
int x,y;
} gdPoint, *gdPointPtr;

void foo(gdPointPtr x);

Then the foo function would get a type-error. The problem has
to do with internal typedef handling and the fact that the typedef
declarations after the struct appear later in the parse tree.
It should work now. Problem reported by Vin Jovanovic.

11/09/2001:beazley
Subtle change to "out" typemaps (and related variations). The name
that is attached to the typemap is now the raw C identifier that
appears on a declaration. This changes the behavior of
member functions. For example:

%typemap(out) int foo {
...
}

class Blah {
public:
int foo(); // typemap gets applied
}

Previous versions never really specified how this was supposed to
work. In SWIG1.1, you could probably write a typemap for the
wrapper name like this:

%typemap(out) int Blah_foo { ... }

However, this old behavior is now withdrawn and not supported.
Just use the member name without any sort of special prefix.
*** POTENTIAL INCOMPATIBILITY ***

11/06/2001:beazley
Changes to Tcl module initialization:

(1) SWIG now automatically includes the code needed to work with
Tcl stubs. Simply compile with -DUSE_TCL_STUBS.

(2) SWIG now automatically calls Tcl_PkgProvide to register
a package name. The package name is the same as the name
specified with the %module directive. The version number is
set to "0.0" by default. To change the version number, use
swig -pkgversion 1.2 interface.i.

*** POTENTIAL INCOMPATIBILITY ***
Modules that provided stubs and Tcl_PkgProvide on their own might
break. Simply remove that code.

11/05/2001:beazley
Changed code generation of constants in the Tcl module. Constants
are now stored in a large table that get installed at module startup.
There are also no longer any static variables so it should generate
somewhat less code.

11/04/2001:beazley
The "const" typemap has been renamed to "constant" in many language
modules. "const" is a C keyword which made the handling of the typemap
directive somewhat awkward in the parser.
*** POTENTIAL INCOMPATIBILITY ***

11/04/2001:beazley
%typemap directive can now accept nearly arbitrary keyword parameters.
For example:

%typemap(in,parse="i",doc="integer") int "..."

The purpose of the keyword parameters is to supply code generation
hints to the target language module. The intepretation of the
parameters is language specific.
*** NEW FEATURE ***

11/04/2001:beazley
Slight semantic change to internal call/return by value handling.
In previous versions of SWIG, call-by-value was translated
into pointers. For example:

double dot_product(Vector a, Vector b);

turned into this:

double wrap_dot_product(Vector *a, Vector *b) {
return dot_product(*a,*b);
}

This translation was normally performed by the SWIG core, outside
of the control of language modules. However, a side effect
of this was a lot of bizarre typemap behavior. For example,
if you did something like this:

%typemap(in) int32 {
...
}

You would find that int32 was transformed into a pointer everywhere!
(needless to say, such behavior is unexpected and quite awkward to
deal with). To make matters worse, if a typedef was also used,
the pointer behavior suddenly disappeared.

To fix this, the pointer transformation is now pushed to the
language modules. This produces wrappers that look roughly
like this:

double wrap_dot_product(Vector *a, Vector *b) {
Vector arg1 = *a;
Vector arg2 = *b;
return dot_product(arg1,arg2);
}

This change also makes it easy to define typemaps for
arbitrary undefined types. For example, you can do this (and it
will work regardless what int32 is):

%typemap(in) int32 {
$1 = (int32) PyInt_AsLong($input);
}

*** POTENTIAL IMCOMPATIBILITY ***
This change may break call/return by value code generation in
some language modules.

11/03/2001:beazley
Changed the name of the default typemaps to the following:

%typemap() SWIGTYPE {
... an object ...
}
%typemap() SWIGTYPE * {
... a pointer ...
}
%typemap() SWIGTYPE & {
... a reference ...
}
%typemap() SWIGTYPE [] {
... an array ...
}
%typemap() enum SWIGTYPE {
... an enum value ...
}
%typemap() SWIGTYPE (CLASS::*) {
... pointer to member ...
}


These types are used as the default for all types that don't match
anything else. See CHANGES log entry for 8/27/2000 for the
old behavior. The role of these types is also described in
Doc/Manual/Typemaps.html

*** POTENTIAL INCOMPATIBILITY ***

10/25/2001:beazley
Modified Guile and Mzscheme modules to support
multi-argument typemaps.

10/25/2001: cheetah (william fulton)
[Java] Fix to handle pointers to arrays.

10/24/2001:beazley
Defining a typemap rule for enum SWIGENUM can now be used
to define default behavior for enum variables.

10/22/2001:beazley
Ruby module modified to support multi-argument typemaps.

10/22/2001:beazley
The Ruby module can now handle functions with an arbitrary
number of arguments. Previous versions were limited to
to functions with only 9 or 16 arguments depending on
the use of default arguments. Note: from some inspection
of the Ruby interpreter source, the new approach might be
a little faster as well.

10/18/2001:beazley
Fixed a bug with forward class declarations and
templates.

class Foo <S,T>;

Bug reported by Irina Kotlova.

10/16/2001:beazley
Support for multivalued typemaps added. The typemaps
are specified using the syntax below. Within each
typemap, variable substitution is handled as follows:

%typemap(in) (int argc, char *argv[]) {
$arg; // The input object in the target language
$1; // C local variable for first argument
$2; // C local variable for second argument

// These variables refer to either argument
$1_type, $1_ltype, $1_basetype, etc... (argc)
$2_type, $2_ltype, $2_basetype, etc... (argv[])

// Array dimension of argv
$2_dim0
}

Basically any variable that was available in normal typemaps
is available for either argument by prefacing the variable
name by '$n_' where n is the argument position.

Notes:
(1) Multi-valued typemaps can only be applied to a single
object in the target scripting language. For example,
you can split a string into a (char *, int) pair or
split a list into a (int, char []) pair. It is not
possible to map multiple objects to multiple arguments.

(2) To maintain compatibility with older SWIG versions, the
variables such as $target and $type are preserved and
are mapped onto the first argument only.

(3) This should not affect compatibility with older code.
Multi-valued typemaps are an extension to typemap handling.
Single valued typemaps can be specified in the usual
way.

The old $source and $target variables are officially
deprecated. Input variables are referenced through
$arg$ and output values are reference through $result$.

*** NEW FEATURE ***

10/16/2001:beazley
Added parsing support for multivalued typemaps. The syntax
is a little funky, but here goes:

// Define a multivalued typemap
%typemap(in) (int argc, char *argv[]) {
... typemap code ...
}

// Multivalued typemap with locals
%typemap(in) (int argc, char *argv[])(int temp) {
... typemap code ...
}

// Copy a multivalued typemap
%typemap(in) (int argcount, char **argv) = (int argc, char *argv[]);

// Apply a multivalued typemap
%apply (int argc, char *argv[]) { (int argcount, char **argv) };

Note: this extra parsing support is added for future extension.
No language modules currently support multi-valued typemaps.

10/11/2001:beazley
Modified the typemap matching code to discard qualifiers when
checking for a match. For example, if you have a declaration
like this:

void blah(const char *x);

The typemap checker checks for a match in the following order:

const char *x
const char *
char *x
char *

If typedef's are involved, qualifier stripping occurs before
typedef resolution. So if you had this,

typedef char *string;
void blah(const string x);

typemap checking would be as follows:

const string x
const string
string x
string
const char *x
const char *
char *x
char *

The primary reason for this change is to simplify the implementation
of language modules. Without qualifier stripping, one has to write
seperate typemaps for all variations of const and volatile (which
is a pain).

*** POTENTIAL INCOMPATIBILITY *** Typemaps might be applied in
places where they weren't before.


10/9/2001: beazley
SWIG now generates wrappers that properly disambiguate
overloaded methods that only vary in constness. For
example:

class Foo {
...
void blah();
void blah() const;
...
};

To handle this, the %rename directive can be used normally.

%rename(blah_const) blah() const;

In the resulting wrapper code, method calls like this
are now generated:

(obj)->blah() // Non-const version
((Foo const *)obj)->blah() // const version

This should force the right method to be invoked.
Admittedly, this is probably obscure, but we might
as well get it right.

10/8/2001: beazley
The preprocessor now ignores '\r' in the input.
This should fix the following bug:
[ 468416 ] SWIG thinks macro defs are declarations?

10/8/2001: beazley
Added support for ||, &&, and ! in constants. This
fixes SF [ 468988 ] Logical ops break preprocessor.
However, at this time, constants using these operators
are not supported (the parser will issue a warning).

10/4/2001: beazley
Added -show_templates command line option. This makes
SWIG display the code it actually parses to generate
template wrappers. Mostly useful for debugging.
*** NEW FEATURE ***

10/4/2001: beazley
Change to semantics of %template directive. When
using %template, the template arguments are handled
as types by default. For example:

%template(vecint) vector<int>;
%template(vecdouble) vector<double>;

To specify a template argument that is *not* a type, you
need to use default-value syntax. For example:

%template(vecint) vector<int,int=50>;
%template(vecdouble) vector<int,size=100>;

In this case, the type name doesn't really matter--only
the default value (e.g., 50, 100) is used during
expansion. This differs from normal C++, but I couldn't
figure out a better way to do it in the parser. Might
implement an alternative later.
*** POTENTIAL INCOMPATIBILITY ***

10/4/2001: beazley
Major changes to template handling in order to provide
better integration with the C++ type-system. The main
problem is as follows:

Suppose you have a template like this:

template<class T> void blah(const T x) { stuff };

Now suppose, that you instantiate the template on a
type like this in SWIG:

%template(blahint) blah<int *>;

In C++, this is *supposed* to generate code like this:

void blah(int *const x) { stuff };

However, in SWIG-1.3.9, the template substitution gets it wrong
and produces

void blah(const int *x) { stuff };

(notice the bad placement of the 'const' qualifier).

To fix this, the SWIG parser now generates implicit typedefs
for template type arguments that produces code roughly
equivalent to doing this:

typedef int *__swigtmpl1;
%template(blahint) blah<__swigtmpl1>;

which generates code like this:

void blah(const __swigtmpl1 x) { stuff };

Since this is correct in both C++ and SWIG, it provides the right
semantics and allows everything to compile properly. However,
to clean up the generated code a little bit, the parser keeps
track of the template types and performs back-substitution to
the original type when building the parse tree. Thus, even
though the implicit typedef is used in the input and may appear
in the generated wrapper file (for proper compilation), the parse
tree will hide a lot of these details. For example:

void blah(const __swigtmpl1 x) { stuff };

will look like it was declared as follows (which is what
you want):

void blah(int *const x) { stuff }

The only place you are likely to notice the typedef hack
is in bodies of template functions. For example, if you
did this,

template<class T> class blah {
...
%addmethods {
void spam() {
T tempvalue;
...
}
}
}

you will find that 'T tempvalue' got expanded into some
strange typedef type. This *still* compiles correctly
so it's not a big deal (other than looking kind of ugly
in the wrapper file).

10/4/2001: beazley
Fixed some inheritance problems in Tcl Object interface.

10/1/2001: beazley
Tcl module has changed to use byte-backed pointer strings. This
implementation should be safe on 64-bit platforms. However,
the order in which digits appear in pointer values no longer
directly corresponds to the actual numerical value of a
pointer (on little-endian machines, pairs of digits appear
in reverse order).

10/1/2001: beazley
Perl5 module is now driven by a configuration file 'perl5.swg'
in the SWIG library.

10/1/2001: beazley
The perl5 module no longer tries to apply the "out" typemap
in code generated for magic variables. I'm surprised that
this ever worked at all (since all of the code that was there
was wrong anyways). Use the "varout" typemap to handle
global variables.

10/1/2001: beazley
Fixed a bug related to character array members of structures.
For example:

struct Foo {
char name[32];
};

SWIG is normally supposed to return a string, but this was
broken in 1.3.9. The reason it was broken was actually
due to a subtle new feature of typemaps. When a data member
is set to an array like this, the return type of the related
accessor function is actually set to an array. This means
that you can now write typemaps like this:

%typemap(python,out) char [ANY] {
$target = PyString_FromStringAndSize($source,$dim0);
}

This functionality can be used to replace the defunct
memberout typemap in a more elegant manner.

9/29/2001: beazley
Some further refinement of qualified C++ member functions.
For example:

class Foo {
...
void foo() const;
...
};

(i) The SWIG parser was extended slightly to allow 'volatile'
and combinations of 'const' and 'volatile' to be used. This
is probably rare, but technically legal. Only added for
completeness.

(ii) For the purposes of overloading, qualified and non-qualified
functions are different. Thus, when a class has methods like this:

void foo();
void foo() const;

Two distinct methods are declared. To deal with this, %rename
and similar directives have been extended to recognize const.
Thus, one can disambiguate the two functions like this:

%rename(fooconst) Foo::foo() const;

or simply ignore the const variant like this:

%ignore Foo::foo() const;

Note: SWIG currently has no way to actually invoke the const
member since the 'const' is discarded when generating wrappers
for objects.

9/27/2001: beazley
New directive. %namewarn can be used to issue warning
messages for certain declaration names. The name
matching is the same as for the %rename directive.
The intent of this directive is to issue warnings for
possible namespace conflicts. For example:

%namewarn("print is a python keyword") print;

The name matching algorithm is performed after a name
has been resolved using %rename. Therefore, a
declaration like this will not generate a warning:

%rename("Print") print;
...
void print(); /* No warning generated */

Since the warning mechanism follows %rename semantics, it is
also to issue warnings for specific classes or just for
certain member function names.

(Dave - I've been thinking about adding something like this
for quite some time. Just never got around to it)
*** NEW FEATURE ***


9/27/2001: beazley
Enhanced the %ignore directive so that warning messages
can be issued to users. This is done using %ignorewarn
like this:

%ignorewarn("operator new ignored") operator new;

The names and semantics of %ignorewarn is exactly the
same as %ignore. The primary purpose of this directive
is for module writers who want to ignore certain types
of declarations, but who also want to alert users about it.
A user might also use this for debugging (since messages
will appear whenever an ignored declaration appears).
*** NEW FEATURE ***

9/26/2001: beazley
Super-experimental support for overloaded operators.
This implementation consists of a few different parts.

(i) Operator names such as 'operator+' are now allowed
as valid declarator names. Thus the 'operator' syntax
can appear *anyplace* a normal declarator name was used
before. On the surface, this means that operators can
be parsed just like normal functions and methods.
However, it also means that operator names can be used
in many other SWIG directives like %rename. For example:

%rename(__add__) Complex::operator+(const Complex &);

(ii) Operators are wrapped *exactly* like normal functions
and methods. Internally, the operator name is used
directly meaning that the wrapper code might contain
statements like this:

arg0->operator*((Complex const &)*arg1);

This all seems to parse and compile correctly (at least
on my machine).

(iii) SWIG will no longer wrap a declaration if its symbol
table name contains illegal identifier characters. If
illegal characters are detected, you will see an error
like this:

Warning. Can't wrap operator* unless renamed to a valid identifier.

The only way to fix this is to use %rename or %name to bind
the operator to a nice name like "add" or something. Note:
the legal identifier characters are determined by the target
language.

There are certain issues with friend functions and operators.
Sometimes, friends are used to define mixed operators such
as adding a Complex and a double together. Currently, SWIG
ignores all friend declarations in a class. A global operator
declaration can probably be made to work, but you'll have to
rename it and it probably won't work very cleanly in the
target language since it's not a class member.

SWIG doesn't know how to handle operator specifications
sometimes used for automatic type conversion. For example:

class String {
...
operator const char*();
...
};

(this doesn't parse correctly and generates a syntax error).

Also: operators no longer show up as separate parse-tree
nodes (instead they are normal 'cdecl' nodes). I may
separate them as a special case later.

See Examples/python/operator for an example.

*** SUPER-EXPERIMENTAL NEW FEATURE ***

1.3.9

==================================

9/25/2001: beazley
Fixed parsing problem with type declarations like
'char ** const'. SWIG parsed this correctly, but the
internal type was represented incorrectly (the pointers
and qualifiers were in the wrong order).

9/25/2001: beazley
Withdrew experimental feature (noted below) that was
causing serious parsing problems.

1.3.8

==================================

9/23/2001: beazley
Included improved distutils setup.py file in the Tools
directory (look for the setup.py.tmpl file). Contributed by
Tony Seward.

9/23/2001: beazley
Included two new RPM spec files in the Tools directory. Contributed
by Tony Seward and Uwe Steinmann.

9/21/2001: beazley
Fixed SF Bug [ 463635 ] Perl5.swg does not compile in Visual C++

9/21/2001: beazley
Two new directives control the creation of default
constructors and destructors:

%nodefault
%makedefault

These replace %pragma nodefault and %pragma makedefault.
(old code will still work, but documentation will only
describe the new directives).

9/21/2001: beazley
Fixed SF Bug [ 462354 ] %import broken in 1.3.7.

9/20/2001: beazley

Parser modified to ignore out-of-class constructor
and destructor declarations. For example:

inline Foo::Foo() :
Bar("foo")
{
}

inline Foo::~Foo() {
}

Suggested by Jason Stewart.
*** EXPERIMENTAL FEATURE ***

9/20/2001: beazley
Modified the parser to ignore forward template class
declarations. For example:

template <class V, long S> class MapIter;

Suggested by an email example from Irina Kotlova.

9/20/2001: beazley
Fixed problem with undeclared tcl_result variable in
the "out" typemap for Tcl. Reported by Shaun Lowry.

9/20/2001: beazley
Incorporated changes to make SWIG work with ActivePerl.
Contributed by Joel Reed.

9/20/2001: beazley
Slight change to the parsing of C++ constructor initializers.
For example:

class Foo : public Bar {
public:
Foo() : Bar(...) {...}
};

SWIG now discards the contents of the (...) regardless of
what might enclosed (even if syntactically wrong). SWIG
doesn't need this information and there is no reason to
needless add syntax rules to handle all of the possibilities
here.

9/20/2001: beazley
Change to typemaps for structure members. If you have a
structure like this:

struct Vector {
int *bar;
};

The member name 'bar' is now used in any accessor functions.
This allows the "in" typemap to be used when setting the value.
For example, this typemap

%typemap(python,in) int *bar {
...
}

now matches Vector::bar. It should be noted that this will also
match any function with an argument of "int *bar" (so you should
be careful).
*** NEW FEATURE. POTENTIAL INCOMPATIBILITY ***

9/20/2001: beazley
Fixed SF bug 462642 setting string values in structures

9/20/2001: beazley
Fixed SF bug 462398 problem with nested templates.

9/20/2001: beazley
Fixed SF bug 461626 problem with formatting and C++ comments.

9/20/2001: beazley
Fixed SF bug 462845 Wrong ownership of returned objects.

9/19/2001: beazley
Fixed SF bug 459367. Default constructors for classes
with pure virtual methods.

9/19/2001: beazley
Fixed problem with default arguments and class scope. For
example:

class Foo {
public:
enum bar { FOO, BAR };
void blah(bar b = FOO);
...
}

SWIG now correctly generates a default value of "Foo::FOO" for
the blah() method above. This used to work in 1.1, but was
broken in 1.3.7. Bug reported by Mike Romberg.

Page 11 of 13

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.