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
This definition ensures the SWIG wrappers keep compiling in older versions
of Ruby given the previous change (which uses RTYPEDDATA_P and hence
requires Ruby 1.9.3). The definition of RTYPEDDATA_P is such that the
previous commit plus the definition should keep the behaviour the same
as before.
- Remove python code from octave's std_basic_string.i
- Correctly return an error to fix error handling when using std::basic_string in
overloaded methods - issue #1171.
Fixes issue #1168.
Remove a call to abort() (introduced by commit
0e725b5d9b) made when SWIG_RubyUnlinkObjects()
is called on non T_DATA objects. It can happen when the destruction of T_DATA
objects is deferred: the Ruby GC first turn them to T_ZOMBIE, then calls their
free method (SWIG_RubyUnlinkObjects()).
