The vector of pointers (just fixed) were not working correctly because the
descriptors returned from swig::type_info() were sometimes returning
zero. Zero should only be used for void * as the subsequent call to
SWIG_ConvertPtr will blindly cast the pointer without checking
descriptor.
std::vector<void *> does not work and will require further changes:
specializing traits_info<void *> to return 0 and traits_asptr<void *>.
I tried this and traits_asptr<void> also needs to be added in which
seems odd and requires further investigation...
Lib/python/pystdcommon.swg:
template <> struct traits_info<void *> {
static swig_type_info *type_info() {
static swig_type_info *info = 0;
}
};
Lib/std/std_common.i:
template <>
struct traits_asptr<void *> {
static int asptr(PyObject *obj, void ***val) {
void **p;
swig_type_info *descriptor = 0;
int res = SWIG_ConvertPtr(obj, (void **)&p, descriptor, 0);
if (SWIG_IsOK(res)) {
if (val) *val = p;
}
return res;
}
};
// this is needed, but am not sure this is expected
template <>
struct traits_asptr<void> {
static int asptr(PyObject *obj, void **val) {
void **p;
swig_type_info *descriptor = 0;
int res = SWIG_ConvertPtr(obj, (void **)&p, descriptor, 0);
if (SWIG_IsOK(res)) {
if (val) *val = p;
}
return res;
}
};
This bug was introduced in swig-3.0.8 in #146252 adding shared_ptr
support. An ObjectPreviouslyDeleted error was incorrectly thrown
when the pointer was used as a parameter after being set to zero
via a call to 'DATA_PTR(self) = 0'.
It isn't clear to me which approach is better in this corner case,
so I've gone for backwards compatibility and restored the old behaviour.
Closes#602
Adds preprocessor checks to avoid defining functions that use long long if it isn't available
Effects the following languages: javascript, octave, perl, python, r, ruby, tcl
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
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.
Move to construct on first use idiom for singleton definition,
which prevents problems with singletons between ruby swig modules
in an environment with multiple modules on MacOS 10.9 with xcode 5.1.
Before this fix, data was being shared between modules which caused
a crash on shutdown of the ruby interpreter if more than one
module was loaded at a time.
- some of the %.clean rules in the test-suite Makefiles were using a single tab
as an empty rule, dangerous! I've replaced these with the safer '@exit 0'.
