std::default_delete<> is originally defined as struct, not class.
This does not really make much of a difference, but some compilers
complain when the struct/class tag is not consistent across all
declarations of the type.
Make the Python and Java bindings use the same set of preprocessor
macros for the SWIG parsing stage, taken from a make variable. Add
G_GNUC_{BEGIN,END}_IGNORE_DEPRECATIONS to that set.
Writing to an object through a pointer of incompatible type is
really evil. Even when the data size matches, it is still a
violation of strict aliasing rules.
Replace all instances by direct casts of the value, without the
unnecessary and dangerous indirection.
The Java bindings currently have some weird problem with function
arguments passed by const reference. Not all types are affected,
but the collection types that involve custom typemaps are.
For now, revert back to pass-by-value for the problematic types.
Looks like SWIG silently ignores default arguments specified via
aggregate initialization. This is rather unfortunate, especially
if the argument types are complex.
Replace custom Deleter classes with std::default_delete<>, declared
as friend so it can invoke the private destructor. Inexplicably,
std::shared_ptr<> does not use default_delete<> by default, so it
is still necessary to explicitly specify the deleter when creating
shared_ptr instances.
With this, unique_ptr and shared_ptr instances now use the same
default delete mechanism.
Make use of std::unique_ptr<> to manage the lifetime of members
or container elements, so that manual invocations of delete can
be avoided. This also provides for exception safety.
Since std::unique_ptr<> is only movable but not copyable, adapt
the code to avoid copies and assignments of these pointers.
Reduce needless over-generalization. There is no design need
for the ParentOwned and UserOwned classes to contain the C base
struct pointer. Instead, just make the _structure pointer a
private member of each class that needs one.
Apparently this problem has been fixed in SWIG 3.0.6. However,
until we can require that version, define "private" as "protected"
when running the SWIG parser.
Declare accessor methods that return value members const. For now,
skip all cases where constness would have to be applied transitively
to shared objects.
Context::package_version() and Context::lib_version() do not access
context state and should be static. However, leave the logging
related methods alone for now, as making them static would entail
making the callback data a global static, since the C API lacks
destroy notification callbacks.
If one of these functions does throw an exception, std::terminate()
will be called. Without this, the behavior is undefined since the C
stack is not prepared to deal with exceptions.
The SWIG 2.0.12 on my system bails out with a syntax error on the
"noexcept" keyword in C++11 code. Define "noexcept" to nothing (for
the SWIG parser only) to work around this problem.
Make use of std::move() to transfer arguments passed in by value.
Take complex container arguments by const reference, as passing
those by value is rather unorthodox even for C++11 style code.
Using the attribute mechanism results in badly named wrappers like
getLog_level(), as well as incompletely applied typemaps for templated
container types. If we just avoid this mechanism entirely, we get the
same foo() and set_foo() accessors as we have in the C++ API.
If we're going to %extend these methods, we need to firstly ignore the
originals, and secondly implement all possible argument combinations.
This fixes the rest of bug #417.
Without this we get:
/usr/include/python2.7/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning
"Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API
NPY_1_7_API_VERSION" [-Wcpp]
As far as I'm aware we're not using any deprecated NumPy C API features.
This fixes part of bug #417.
Marcus Comstedt
Martin Ling
Daniel Elstner
Uwe Hermann