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.
When passing a byte array from c++ to Java using the director feature, the generated jni code does not release a temporary byte array.
This is the typemap specified in Java.swg:
%typemap(directorin, descriptor="[B") (char *STRING, size_t LENGTH) {
jbyteArray jb = (jenv)->NewByteArray($2);
(jenv)->SetByteArrayRegion(jb, 0, $2, (jbyte *)$1);
$input = jb;
}
%typemap(directorargout) (char *STRING, size_t LENGTH)
%{(jenv)->GetByteArrayRegion($input, 0, $2, (jbyte *)$1); %}
Notice that the call to NewByteArray doesn't contain a symmetric release logic as the SetByteArrayRegion/GetByteArrayRegion does.
Closes#386
