The macros for casting function pointers are now fully described and also
clarify why the macros act transparently for C even before Ruby 2.7.
In addition, an "if (CPlusPlus)" was removed in the code generator for
global variables in order to keep the distinction between C and C++ in
one place, which is at the definition of said macros.
This commit fixes the signatures of various callback methods
and cleans up the macro definitions used for casting callbacks.
Note that the transparent version of the macro RUBY_METHOD_FUNC
is currently masked behind RUBY_DEVEL, see commit
1d91feaf13
In order to still support strict signature checking and prevent
nasty deprecation warnings, the use of RUBY_METHOD_FUNC had to
be replaced with VALUEFUNC.
The type long may be 4 bytes but swig_this() must return the address of
the object as an integer. Using size_t ensures that the return type can
store a pointer.
With octave 4.4 the function
virtual bool octave_base_value::is_object() const
was renamed to
virtual bool octave_base_value::isobject() const
As noted in CHANGES "2012-03-26: xavier98", is_object() must return true
for swig types whereas octave_base_value::is_object returns false per
default.
The existing typemaps didn't work at all and making them work would
require defining all the typemaps needed by the Unified Typemaps
Library, which seems to be geared towards dynamic languages.
Just implement completely straightforward (and not very convenient to
use) typemaps instead.
Enable the now passing unit tests and add a runme for one of them.
Remove the code related to "_result_ref" which was confusing and plain
wrong, as it generated something that compiled but crashed during
run-time due to the use of a pointer to an already destroyed stack
object.
Instead, correct the "out" typemap to create a new copy of the object,
which mostly works fine on its own, except that it depends on using
SwigValueWrapper if necessary, so add the call to cplus_value_type()
does this. This also required removing the code resolving typedefs in
the "type" attribute because it confused the base class logic and still
needs an explicit cast to the actual return type due to the use of (and
probable bug in) get_wrapper_func_return_type().
These changes mean that "cppouttype" typemap is not used any longer, so
remove it too.
A couple more tests pass now.
Use "..." instead of "{...}" to avoid generating extra lines with
opening/closing curly braces, which are completely unnecessary.
Also remove an unnecessary "if" check in "in" typemap, which was
useless.
No real changes.
There is no need to check if the input is non-null, as the effect of
both branches of "if" is the same anyhow.
Also get rid of an extra and unnecessary block.
No real changes.
This is actually a fix to some functionality that I submitted many years ago. :) At the time I set the string conversion to output the userdata address, but since that points to an internal SWIG structure, it's way more useful to the user to point to the actual memory being wrapped in that userdata.
For such types, the generated proxy class inherited from
java.util.AbstractSet<BoxedType<T>> (where BoxedType<T> is "Integer",
for example, when T is "int"), but defined an overloaded add() taking T,
instead of overriding the base class virtual add() taking BoxedType<T>,
resulting in an exception being thrown whenever add() was called during
run-time.
Extend Java unit test to bring it to parity with C# one added in the
previous commit.
See #1568.
Notably make them work for primitive types, such as "int".
Doing this requires using "object" instead of the actual C# type of the
variable to store the current value in the iterator, as we don't
currently have a "csnullabletype" typemap that would expand to "T" for
nullable types and "T?" for the other ones. This is a bit ugly, but it
shouldn't matter much for the generated code and is already done in
std::vector<> typemaps.
Also add a simple unit test verifying the basic functionality for such
vectors.
Closes#1568.
This is just a mistake remaining from generalizing the old
string-specific typemap to any type.
Fix it now and update a unit test to test for sets of objects other than
strings.
Default marshalling for bool[] now uses 1-byte entries in the array, to
ensure array contents is as expected in C++.
When running under mono csharp_lib_arrays_bool testcase will fail
due to an apparent bug in mono. Works correctly under Microsoft's
runtime. See https://github.com/mono/mono/issues/15592
Done in order to be C++17 compliant as it uses std::unexpected_handler
which was removed in C++17. This class was intended for director
exception handling but was never used by SWIG and was never documented.
Closes#1538
Workaround clang++ 9.1.0 error not knowing std::vector<bool>::const_reference
is actually typedef to bool:
li_std_vector_wrap.cxx:1838:40: error: no matching constructor for initialization of 'std::vector<bool>::const_reference'
Workaround is use
const value_type& getitem(int index) throw (std::out_of_range) { ...
// bool specialization:
bool getitem(int index) throw (std::out_of_range) { ...
instead of
const_reference_type getitem(int index) throw (std::out_of_range) { ...
Although the following would be better, it would require a more
complicated implementation:
const_reference_type getitem(int index) throw (std::out_of_range) { ...
// bool specialization:
bool getitem(int index) throw (std::out_of_range) { ...
For users who have typemaps for the parameters in the setElement method.
Correct definitions of const_reference to match the those in the
(C++11) standard.
For users who have typemaps for the parameters in the setitem method.
Correct definitions of const_reference to match the those in the
(C++11) standard.
For users who have typemaps for the parameters in the add and set methods
(now called doAdd and doSet).
Also for users who have typemaps for the get method - revert the return
type for get (now called doGet) back to the same return type as
std::vector::at. Correct definitions of const_reference to match the
those in the (C++11) standard.
