in the %array_functions and %array_class macros.
Affects C#, D, Go, Guile, Java, Javascript, Lua, Ocaml, R, Racket.
Closes#1680
If the old types are required for backwards compatibility, use %apply to
restore the old types as follows:
%include "carrays.i"
%apply int { size_t nelements, size_t index }
... %array_functions and %array_class ...
%clear size_t nelements, size_t index; # To be safe in case used elsewhere
* issue/2625:
Enhanced std::map for non-default constructible types changes entry
Add missing exception.i for std::map wrappers for MzScheme and Guile
std::map wrappers and non-default constructible
Fixed make file ordering
Fixed line endings
Added unit test
Using #ifdef instead of #if to prevent warnings
Fix for #2625 Using c++17 insert_or_assign for std::map when available.
Conflicts:
CHANGES.current
Fix deprecation warnings about ANYARGS when compiling C++ code for
SWIG-generated Ruby wrappers with Ruby 3.x.
This is a recurrence of a problem fixed in 4.0.2. Our fix was
conditional on RB_METHOD_DEFINITION_DECL being defined, but Ruby
3.0 stopped defining this.
We aim to produce code that works with C90 or C++98 so we can't
assume snprintf() is available, but it almost always is (even
on systems from before it was standardised) so having a way to
use it is helpful.
Enable this automatically if the compiler claims conformance
with at least C90 or C++98 and check SWIG_HAVE_SNPRINTF to allow
turning on manually, but disable if SWIG_NO_SNPRINTF if defined.
The fallback is to call sprintf() without a buffer size check -
checking after the call is really shutting the stable door after
the horse has bolted, and most of our uses either have a fixed maximum
possible size or dynamically allocate a buffer that's large enough.
Fixes: #2502 (sprintf deprecation warnings on macos)
Fixes: #2548
For implementing full move semantics when passing parameters by value.
Based on SWIGTYPE && and std::unique_ptr typemaps which implement move
semantics.
Added for all languages, but untested for: Go, Ocaml, R, Scilab (and
unlikely to be fully functional for same reasons as for std::unique_ptr
support).
Issue #999
The directorin typemaps in the director methods now use std::move on the
input parameter when copying the object from the stack to the heap prior
to the callback into the target language, thereby taking advantage of
move semantics if available.
Enhance SWIGTYPE "out" typemaps to use std::move when copying
objects, thereby making use of move semantics when wrapping a function returning
by value if the returned type supports move semantics.
Wrapping functions that return move only types 'by value' now work out the box
without having to provide custom typemaps.
The implementation removed all casts in the "out" typemaps to allow the compiler to
appropriately choose calling a move constructor, where possible, otherwise a copy
constructor. The implementation alsoand required modifying SwigValueWrapper to
change a cast operator from:
SwigValueWrapper::operator T&() const;
to
#if __cplusplus >=201103L
SwigValueWrapper::operator T&&() const;
#else
SwigValueWrapper::operator T&() const;
#endif
This is not backwards compatible for C++11 and later when using the valuewrapper feature
if a cast is explicitly being made in user supplied "out" typemaps. Suggested change
in custom "out" typemaps for C++11 and later code:
1. Try remove the cast altogether to let the compiler use an appropriate implicit cast.
2. Change the cast, for example, from static_cast<X &> to static_cast<X &&>, using the
__cplusplus macro if all versions of C++ need to be supported.
Issue #999Closes#1044
More about the commit:
Added some missing "varout" typemaps for Ocaml which was falling back to
use "out" typemaps as they were missing.
Ruby std::set fix for SwigValueWrapper C++11 changes.
Ruby 3.2 (still in development) started warning about this, see
https://bugs.ruby-lang.org/issues/18007.
Note that the extension docs mention it in
https://ruby-doc.org/core-3.1.1/doc/extension_rdoc.html#label-C+struct+to+Ruby+object:
> The klass argument is the class for the object. The klass should
> derive from `rb_cObject`, and the allocator must be set by calling
> `rb_define_alloc_func` or `rb_undef_alloc_func`.
So in this case we call `rb_undef_alloc_func` to fix the warning.
Verified that this works in robinst/taglib-ruby#115.
Fixes#2257.
This is necessary for regex-like renames (where you can't use the #define trick
as is done in many of the %keywordwarn directives). It's now unnecessary to print
the "renaming to '`x`'" code explicitly by the kw.swg files.
The Ruby C API function 'rb_funcall' is used in various places in generated
code for invoking a Ruby method without parameters. The C function uses a
variadic parameter list for the arguments passed to Ruby, therefore in these
cases the list of variadic parameters is empty.
As an optimization Ruby may implement the 'rb_funcall' function as a macro
which however will not accept an empty list of arguments for '...' as of
C99 and C++11.
In order to prevent compiler warnings, this commit replaces all such
occurrences with a call to 'rb_funcall2' (which in its current name
'rb_funcallv' is invoked by the 'rb_funcall' macro anyway, at least for
Ruby 2.6.6).
When wrapping STL containers, remove a shared_ptr reference count
increment when an upcast is needed when checking type conversion
in traits_check::check.
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.
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
Olly Betts