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
Change these typemaps to assume that after a function call,
the parameter has been moved. The parameter's proxy class
that owns the C++ object thus has the underlying pointer set
to null so the object cannot be used again and the object is deleted.
Scrap new javarelease typemap and move contents into javabody typemap.
This works by transferring ownership of the underlying C++ memory
from the target language proxy class to an instance of the unique_ptr
which is passed to the wrapped function via std::move.
The proxy class has a new swigRelease() method which sets the
underlying C++ pointer for the proxy class to null, so working
in much the same way as std::unique_ptr::release(). Any attempt at
using the proxy class will be the same as if the delete() function
has been called on the proxy class. That is, using a C++ null pointer,
when a non-null pointer is usually expected.
This commit relies on the previous commit that uses std::move
on the temporary variable used for the wrapped function's input parameter
as std::unique_ptr is not copyable, it has move-only semantics.
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.
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.
long long[] map was using JNI type as C/C++ type. General spirit of
JAVA_ARRAYS_TYPEMAPS is to cast individual array elements, not to
rely on potentially incompatible pointer casts.
As for __int64 definition. __int64 is a non-standard Visual-C-specific
type used in win32/jni_md.h. It is defined by other Win32 compilers in
one way or another, obviously for compatibility. It's more appropriate
to give the compiler a chance to make necessary arrangements instead
of reinventing the wheel. This, giving a chance, can be achieved by
including virtually any standard header. Since jni.h includes stdio.h,
defining __int64 in javahead.swg is redundant. Since doing so actually
triggers compilation errors on MinGW if a system header is included
in the %begin section, it's arguably appropriate to omit it.
As for #undef _LP64 removal. Undefining a pre-defined macro, which
_LP64 is, is bad style, and if followed by inclusion of systems
headers, it's actually error-prone. Log suggests that it was added
to resolve a warning. I'm inclined to believe that it rather was a
misunderstanding of some kind. Or a bug in warning subsystem of
some particular compiler version, in which case it would have been
more appropriate to advise users to ignore the warning.
Add ability to change the modifiers for the C# and Java
interface generated when using the %interface macros.
For C# use the 'csinterfacemodifiers' typemap.
For Java use the 'javainterfacemodifiers' typemap.
For example:
%typemap(csinterfacemodifiers) X "internal interface"
Closes#1874
Occurs when using the director class from multiple threads - a race condition
initialising block scope static variables.
Block scope static variables are guaranteed to be thread safe in C++11,
so the fix is guaranteed when using C++11. However, most modern compilers
also fix it when using C++03/C++98.
Closes#1862
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.
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 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.
Added to the javadestruct, javadestruct_derived, ddispose, ddispose_derived
typemaps to mirror enhanced flexibility in the csdisposing and
csdisposing_derived (C#) typemaps. If provided the contents are generated
as the delete/dispose method's parameters declaration.
The std::vector wrappers have been changed to work by default for elements that are
not default insertable, i.e. have no default constructor. This has been achieved by
not wrapping:
vector(size_type n);
Previously the above had to be ignored via %ignore.
If the above constructor is still required it can be added back in again via %extend:
%extend std::vector {
vector(size_type count) { return new std::vector< T >(count); }
}
Alternatively, the following wrapped constructor could be used as it provides near-enough
equivalent functionality:
vector(jint count, const value_type& value);
The equivalent change to std::list has also been made (std::list
wrappers were not in the previous release [3.0.12] though).
* gtbX-master:
Add comment for non-const version
Don't write-back buffer into Java array when calling const-ptr c function
Prevent writeback of a const char* array through a director when using the byte[] %typemap.
Tests for std::vector of pointers added which check
std::vector<T*>::const_reference and std::vector<T*>::reference
usage which gave compilation errors in Python and Perl which had
specialized these vectors incorrectly.
