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.
PyObject_CallFunction has the potential to silently drop the active
exception. In cases where the user just finished iterating a
generator, StopIteration will be active. Most of the time this
is fine because destroy() won't raise an exception. On Python 3
however, and with a debug interpreter, you will get an assertion
failure inside of Python. And in the worst case scenario, if
destroy() does throw an exception, the intepreter probably won't
be able to correctly detect the end of the iteration.
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.
Updated Doxygen error numbers yet again, as Python errors got added in the
meanwhile, pushing the Doxygen ones further off.
And re-merged PEP8/whitespace-related conflicts in autodoc_runme.py once again
(if anybody is looking for a motivating example about why significant
whitespace is bad, here is a great use case).
* 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