Adjust the floating point constants to be 1.125 and 2.25 (which
can be exactly represented in base-2 floating point) instead of
1.1 and 2.2 (which can't). This avoids problems on platforms where
floating point calculations suffer from excess precision, the most
commonly used of which is x86 when using 387 FP instructions.
In $typemap(), the $n special variables are replaced by the appropriate
value for the type associated with the typemap calling $typemap().
The (undocumented) special variable overrides now also support
controlling what the $n special variables are replaced with from the
calling typemap, for example:
%typemap(in) std::pair<std::string, int> {
int& input_value_second = $1.second;
$typemap(in, int, 1=input_value_second);
...
}
replaces $1 in the int typemap with input_value_second instead of
whatever is the default for the target language (a variable that holds
the int value after marshalling from the target language).
This additional functionality might make it possible to replace the C++
templates used in the UTL with a much simpler system of typemaps utilising
$typemap(). See follow on commit to typemaps.c.
more than two deep and the using declarations are overloaded.
Using declarations from a base class' base were not available for use
in the target language when the using declaration was before a method
declaration.
Closes#2687
Defining SWIGWORDSIZE64 now applies the (unsigned) long long
typemaps to (unsigned) long for a better match on systems
where long is 64-bits.
Although size_t typemaps are now applied from the int typemaps instead
of the long typemaps, identical code is generated and the mapping is
still to the Java signed long type.
Closes#646Closes#649
Running the test-suite as follows on a 64-bit long system:
env SWIG_FEATURES=-DSWIGWORDSIZE64 make check-java-test-suite
passes, except for a few tests which fail where they expect the
default Java type to be int or long instead of long or BigInteger
respectively.
Also arrays_java.i results in:
invalid conversion from ‘long int*’ to ‘long long int*’ [-fpermissive]
invalid conversion from ‘long int**’ to ‘long long int**’ [-fpermissive]
Const member variables such as the following are non-assignable by
by default:
const int x[2][2];
Variable setters are not generated when wrapping these non-assignable
variables and classes containing such non-assignable variables.
Const member variables such as the following are non-assignable by
by default:
char * const x;
const int x;
const int x[1];
but not:
const char * x;
Variable setters are not generated when wrapping these non-assignable
variables and classes containing such non-assignable variables.
A struct/class that contains a non-assignable member variable is
actually assignable itself. Only non-static members, not static members,
contribute to the containing class being non-assignable.
Recent regression fix from a few commits back.
Rvalue reference variables such as the following are non-assignable by
by default:
X &&v;
Variable setters are not generated when wrapping these non-assignable
variables and classes containing such non-assignable variables.
Reference variables such as the following are non-assignable by
by default:
int &v;
Variable setters are not generated when wrapping these non-assignable
variables and classes containing such non-assignable variables.
A class that does not have an explicit assignment operator does not
have an implicit assignment operator if a member variable is not
assignable. Similarly should one of the base classes also not be
assignable. Detection of these scenarios has been fixed so that when
wrapping a variable that is not assignable, a variable setter is not
generated in order to avoid a compiler error.
Template instantiation via %template is required in order for this to
work for templates that are not assignable.
Closes#1416
Fix incorrect variable setters being generated when the type of the
variable is not assignable, due to variable type inheriting a private
assignment operator further up the inheritance chain (further up than
the immediate base).
Fix problems wrapping deleted destructors. Derived classes are not
constructible, so don't attempt to generate default constructor or
copy constructor wrappers.
struct StackOnly1 {
// Only constructible on the stack
~StackOnly1() = delete;
};
struct StackOnlyDerived1 : StackOnly1 {
// this class is not constructible due to deleted base destructor
};
Fix for when a class has a default deleted constructor and does
not have any other constructors (except implicit or explicit copy
constructors).
Closes#1644
SwigValueWrapper was not being used when the default constructor is
deleted for a type passed around by value.
Fix is only for when other constructors declarations are present,
deleted, defaulted or not.
Issue #1644
Add support for using declarations to introduce templated member
methods and for inheriting templated constructors, such as:
struct Base {
// templated constructor
template <typename T> Base(const T &t, const char *s) {}
// templated member method
template <typename T> void template_method(const T &t, const char *s) {}
};
%template(Base) Base::Base<int>;
%template(template_method) Base::template_method<double>;
struct Derived : Base {
using Base::Base;
using Base::template_method;
};
Previously the templated methods and constructors were ignored and
not introduced into the Derived class.
Fixes inheritance hierarchies more than two deep and the using
declarations are overloaded. Using declarations
from a base class' base were not available for use in the target
language. For example in the code below, Using1::usingmethod(int i)
was not wrapped for use in Using3:
struct Using1 {
protected:
void usingmethod(int i) {}
};
struct Using2 : Using1 {
protected:
void usingmethod(int i, int j) {}
using Using1::usingmethod;
};
struct Using3 : Using2 {
void usingmethod(int i, int j, int k) {}
using Using2::usingmethod;
};
Similarly for C++11 using declarations for inheriting constructors.
when a method is declared in the class along with a
using declaration and the using declaration is declared before
the method that implemented the pure virtual method, such as:
struct ConcreteDerived : AbstractBase {
ConcreteDerived() {} // was not wrapped
using AbstractBase::f;
virtual void f(int n) override {}
};
SourceForge bug: https://sourceforge.net/p/swig/bugs/932/
check_implemented in allocate.cxx was correctly finding a
non-abstract method, however, Swig_symbol_clookup_local_check, was
using the using declaration node instead of using the node returned
by check_implemented. The checkfunc is now given more control by
returning the node to use rather than Swig_symbol_clookup_local_check
always using the head of the csym linked list.
The sym:overname attribute was not being updated when templates were
included in the list of overloaded methods/constructors, leading to
duplicate target language symbols in some language like java/csharp.
Closes#2541
Constructors used to warn with:
Warning 302: Identifier 'Json' redefined (ignored)
But now warn with:
Warning 322: Redundant redeclaration of 'Json'
Note that 320 is a warning that is shown by default and 322 is a
hidden warning by default.
The warning is now consistent for both templated methods and constructors
that are deemed redefined. See cpp11_template_parameters_decltype
testcase. This testcase has been enhanced with a runtime test to check
that the workarounds for overloaded templated constructors/methods do
work.
Further removal of template parameters from the "name" attribute for
constructors and destructors.
Add test case for templated constructor instantiations - based on the
Python and Octave only li_std_pair_extra.i test which caused problems
making this change.
Recent commits for internal constructor and destructor names resulted
in destructors declared with template parameters being ignored
with warnings like:
Illegal destructor name TemplPublicBase6< int >::~TemplPublicBase6(). Ignored.
Although declaring constructors and destructors with template parameters
are rejected by modern compilers and C++20, SWIG continues to support it.
Make sure the name stored in the parse tree is the C++20 compliant name
name, that is, without the template parameters.
Fixes using declarations for templated constructors declared with
template parameters, was warning with:
Nothing known about 'TemplPublicBase6< int >::TemplPublicBase6'.
Support extended to directors.
Go protected constructors fix required for new testcase:
- Emit wrappers if director class is abstract
- If called, errors out with: accessing abstract class or protected constructor
- Now consistent with other target languages
Parser no longer checks for a declared constructor when handling a
using declaration in order to correct the name as it won't find
implicitly declared constructors. Now it checks that a using
declaration is for something that looks like a constructor instead
by checking the immediate base classes for allowed constructors.
Corner case problem fix for when the base template class was
instantiated with %template including the default arguments and
the base class had an explicitly declared constructor.
Swig_symbol_template_deftype() was sometimes incorrectly finding
a constructor instead of a template and thus failing to correctly
expand the template default args. Problem noticed since
9cf049186b where constructors are
stored simply by their name instead of name plus template args.
Probably fixes a few other subtle template problems when a template
class contains default args.
Internal using name no longer contains template parameters.
Fixes symbol table lookup for non-instantiated template constructor.
Builds on previous few commits where the internal name no longer
contains the template parameters for constructors and destructors.
which calls a function with no parameters within additional brackets.
This is more of a hack than a fix as attempts to parse properly
failed, see issue #2640.
Closes#2640
The strings from the Octave array are returned in a temporary
std::string object so we need to make a copy of them or else the
final string ends up replicated as all elements.
Unfortunately argcargvtest.i was only checking the final element's
value, so fix it to test both the elements as a regression test for
this, and to catch any similar issues with other target languages.
Fix duplicate const in generated code when template instantiation type is const
and use of template parameter is also explicitly const, such as:
template <typename T> struct Conster {
void cccc1(T const& t) {}
};
%template(ConsterInt) Conster<const int>;
Above previously led to generated code:
(arg1)->cccc1((int const const &)*arg2);
instead of
(arg1)->cccc1((int const &)*arg2);
Olly Betts