jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Movable and move-only types supported in "out" typemaps.

Browse source 
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 #999
Closes #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 commit is contained in:
William S Fulton 2022-06-22 12:52:06 +01:00
commit bf36bf7d8a
34 changed files with 508 additions and 138 deletions
Download patch file Download diff file Expand all files Collapse all files

10
Doc/Manual/Typemaps.html
View file

@ -3364,7 +3364,7 @@ Consider running the following code through SWIG:
<div class="code">
<pre>
%typemap(out) SWIGTYPE %{
$result = new $1_ltype((const $1_ltype &amp;)$1);
$result = new $1_ltype($1);
%}
%inline %{
@ -3414,7 +3414,7 @@ If the typemap code is kept the same and just the "optimal" attribute specified
<div class="code">
<pre>
%typemap(out, optimal="1") SWIGTYPE %{
$result = new $1_ltype((const $1_ltype &amp;)$1);
$result = new $1_ltype($1);
%}
</pre>
</div>
@ -3441,7 +3441,7 @@ SWIGEXPORT void * SWIGSTDCALL CSharp_XX_create() {
void * jresult ;
XX result;
result = XX::create();
jresult = new XX((const XX &amp;)result);
jresult = new XX(result);
return jresult;
}
@ -3456,7 +3456,7 @@ With the "optimal" attribute, the code is:
<pre>
SWIGEXPORT void * SWIGSTDCALL CSharp_XX_create() {
void * jresult ;
jresult = new XX((const XX &amp;)XX::create());
jresult = new XX(XX::create());
return jresult;
}
</pre>
@ -3513,7 +3513,7 @@ It should be clear that the above code cannot be used as the argument to the cop
</p>
<p>
Secondly, if the typemaps uses <tt>$1</tt> more than once, then multiple calls to the wrapped function
Secondly, if the typemap uses <tt>$1</tt> more than once, then multiple calls to the wrapped function
will be made. Obviously that is not very optimal.
In fact SWIG attempts to detect this and will issue a warning something like:
</p>