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 setitem method.
Correct definitions of const_reference to match the those in the
(C++11) standard.
Fixes two warnings in each wrapper:
warning : CA2002 : Microsoft.Reliability : 'examplePINVOKE.SWIGPendingException.Retrieve()' locks on a reference of type 'Type'. Replace this with a lock against an object with strong-identity.
warning : CA2002 : Microsoft.Reliability : 'examplePINVOKE.SWIGPendingException.Set(Exception)' locks on a reference of type 'Type'. Replace this with a lock against an object with strong-identity.
Use lock statement advice not to use typeof for locks, see
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/lock-statement
Previously just the Dispose() method was generated.
Now the Dispose() and Dispose(bool disposing) methods are generated.
Changes are required if custom "csfinalize", "csdestruct" or "csdestruct_derived"
typemaps are being used. Details in #421 on Github. SWIG will error out if one of
the "csfinalize, "csdestruct" or "csdestruct_derived" typemaps are found. Example
error message:
foo.h:60: Error: A deprecated csfinalize typemap was found for Foo, please remove
it and replace all csdestruct, csdestruct_derived and csfinalize typemaps by the
csdispose, csdispose_derived, csdisposing and csdisposing_derived typemaps.
Closes#421
Better to use the actual type rather than void* in the implementaton.
It also mean the %apply that was used in the implementation won't
inadvertently affect users other use of void* types.
Assignable fixes are based on those used by C# std::vector where the
default wrappers work if there is no operator== available in the
template type. Enhanced wrappers are obtained via a macro:
SWIG_STD_LIST_ENHANCED(SomeNamespace::Klass)
%template(ListKlass) std::list<SomeNamespace::Klass>;
Remove bool specialization (left over from the original std::vector
wrappers).
Add in missing typedefs.
These implementations are not optimized, i.e. are done in a naive way in
C#, rather than using C++ functions more efficiently, but are better
than nothing.
Create new Lib/csharp/std_set.i based on the existing std_map.i and run
li_std_set unit test for C# as well.
Notice that the set operations defined by the base ISet<> interface are
not implemented yet.
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.
* vadz-csharp-complex:
Add header to std_complex.i
Fix linkage problems in C# std::complex wrappers
C# std::complex wrappers marshalling by value
C# std::complex wrappers SwigValueWrapper fix
Use %naturalvar for C# std::complex wrappers
Allow avoiding generation of unwanted std::complex<T> typemaps
Also apply csvar{in,out} typemaps to std::complex references
Add std_complex.i for C# too
Extend C# complex support to member variables of this type
Add support for std::complex<> to C#
Use new unified Mono mcs compiler if available under Unix
Fix warnings and subsequent exception trying to use wrappers:
Warning C4190: 'CSharp_complextestNamespace_VectorStdCplx_getitemcopy'
has C-linkage specified, but returns UDT 'SwigSystemNumericsComplex'
which is incompatible with C
Rename swig_complex_typemaps macro to SWIG_COMPLEX_TYPEMAPS
The director c++ exceptions are thrown in a helper method instead of in
the director overloaded method. This circumvents compiler warnings about
throwing exceptions when the method has an exception specification or
noexcept. If the exception is thrown, abort will still be called!
In Java, the "director:noexcept" typemap can be used to do something
else. This typemap should be ported to the other languages too.
In many cases, only one of std::complex<double> and std::complex<float> is
used, so while we continue to define typemaps for both by default, for
compatibility with the other modules, add a possibility to avoid generating
the code for the unwanted specialization by predefining the corresponding
SWIG_NO_STD_COMPLEX_$TYPE before including this file.
For consistency with the other modules (Python, Ruby and JS), allow including
<std_complex.i> directly when using C# too instead of including <complex.i>
which only works in C++ mode (i.e. when using std::complex) anyhow with C# for
now.
Define csvar{in,out} typemaps needed to support properties of complex type and
apply the existing cstype and csin ones to them as well.
Add unit test verifying that this works as expected in C# and, also, in
Python, even though no changes were needed there.
The C# type corresponding to size_t may be changed by redefining its "cstype"
type typemap, but this broke compilation of the code using std::vector<> as
the typemap generating it assumed that size_t was always represented by uint
in C#. Make this work in all cases by explicitly looking up cstype of size_t
instead.
Notice that it may be quite useful, and even necessary, to map size_t to int
as when generating C# assembly for use with COM, via .NET interop, as some COM
clients, notably VBA-using ones, including all Microsoft Office applications,
don't support unsigned types and can't call methods using or returning uint in
C# at all.
Adding a constructor that accepts IEnumerable<T> avoids the boxing and unboxing overhead of the original constructor, when the type parameter is a value type. This also allows passing IList<T>, which does not implement ICollection (ironically the generated type implements IList<T>).
Kept the original constructor for backward compatibility, but replaced ICollection with IEnumerable for added flexibility.
1) The %extend directive can now optionally support one of the 'class', 'struct' or 'union'.
2) The SWIG library no longer uses the javatype, dtype or cstype typemaps, thereby
completely freeing them up for users to use without having to replicate the library
code that they previously added
Tested by changes to test: java_lib_arrays
* myd7349-master:
Convert the Java runtime testcase cpp11_li_std_array_runme to C#
Add C++11 std::array interface file for C#
SWIG_STD_VECTOR_ENHANCED for std::wstring
