Hack to use the std::array support for boost::array.
Is limited as it currently exposes some 'using' bugs in SWIG.
For example, the type system fails to see that pointers to std::array
and pointers to boost::array are the same.
This approach saves having to maintain separate boost::array support.
The 'using' bug ought to be fixed, otherwise separate boost_array.i
files could be easily made from the std_array.i files.
Setting an STL container wrapper slice better matches the way Ruby
arrays work. The behaviour is now the same as Ruby arrays. The only
exception is the default value used when expanding a container
cannot be nil as this is not a valid type/value for C++ container
elements.
Access via ranges and slices now behave identically to Ruby arrays.
The fixes are mostly for out of range indices and lengths.
- Zero length slice requests return an empty container instead of nil.
- Slices which request a length greater than the size of the container
no longer chop off the last element.
- Ranges which used to return nil now return an empty array when the
the start element is a valid index.
Using negative indexes to set values works the same as Ruby arrays, eg
%template(IntVector) std::vector<int>;
iv = IntVector.new([1,2,3,4])
iv[-4] = 9 # => [1,2,3,9]
iv[-5] = 9 # => IndexError
These work much like any of the other STL containers except Python slicing
is somewhat limited because the array is a fixed size. Only slices of
the full size are supported.
Fix error when append on a SWIG Object with -builtin:
x.append(10)
SystemError: error return without exception set
Having append and next methods on a SWIG object by default doesn't seem
right to me though.
rb_obj_is_kind_of can no longer be used for type checking as the
smartptr feature type, eg shared_ptr<Derived> cannot be cast to
a smartptr of the base class, eg shared_ptr<Base>.
Previously Derived could be cast to Base as they were in an
inheritance chain and the call to rb_define_class_under() used
SWIGTYPE_p_Base->clientdata for all derived classes.
Now SWIG_TypeCheck is always used.
This is a patch to resolve SF bug 2034216 (Github issue #225)
The bug is that the tracking code uses a ruby hash and thus may
allocate objects (Bignum) while running the GC. This was tolerated in
1.8 but is invalid (raises an exception) in 1.9.
The patch uses a C hash (also used by ruby) instead.
With this change, generated code for golang treats char* as a string but
treats signed char* and unsigned char* as normal pointers. This seems to
fit better with the expected behavior, as the latter are more often used
as non-string data.
Notably it now works for "unsigned char*" strings.
Add a test to check that it now works in Java and also showing that it already
worked for the other languages with support for this typemap.
* appveyor-check-test-suite:
Appveyor testing expanded
Fix array overrun in li_carrays testcase
Warning fixes in generated Python code for 64bit Visual C++ on Windows.
Warning fixes in generated C# code for 64bit Visual C++ on Windows.
Warning fixes for 64bit visual c++ on Windows
Warning fixes in generated Java code for 64bit Visual C++ on Windows.
Warning fixes for 64bit visual c++ on Windows
C# gc tests failure fix
Add a space between literal and string macro
Since Lua 5.3 the "%c" format character in lua_pushfstring will produce
the string "<\XXX>" (XXX being a decimal code sequence) when
given unprintable characters.
Use lua_pushlstring instead to reproduce the old behavior.
