Notably make them work for primitive types, such as "int".
Doing this requires using "object" instead of the actual C# type of the
variable to store the current value in the iterator, as we don't
currently have a "csnullabletype" typemap that would expand to "T" for
nullable types and "T?" for the other ones. This is a bit ugly, but it
shouldn't matter much for the generated code and is already done in
std::vector<> typemaps.
Also add a simple unit test verifying the basic functionality for such
vectors.
Closes#1568.
This is just a mistake remaining from generalizing the old
string-specific typemap to any type.
Fix it now and update a unit test to test for sets of objects other than
strings.
Default marshalling for bool[] now uses 1-byte entries in the array, to
ensure array contents is as expected in C++.
When running under mono csharp_lib_arrays_bool testcase will fail
due to an apparent bug in mono. Works correctly under Microsoft's
runtime. See https://github.com/mono/mono/issues/15592
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.
