* ejulien-python_operator_overload_test_suite:
Add __str__ to operator_overload testcase for python builtin
Python operator_overload runtime testcase cleanup
Work around a limitation of the Python binding generator related to the += family of operators.
Fix Python 3 division member operator when -builtin is not used.
Fix class member division operator.
Remove the PY3BUILTIN switch as its behavior can be achieved with the existing SWIG_FEATURES=-builtin switch.
Implement the operator overload test suite for Python.
Conflicts:
Examples/test-suite/operator_overload.i
This ensures that the pointer is not leaked.
Unfortunately it requires adding a dangerous, std::auto_ptr<>-like destructive
copy ctor to scoped_dohptr<>, but there is no better solution without C++11.
Reuse get_wrapper_func_proto() for the wrapper function definitions too, this
cuts down on the amount of duplicated code and also ensures that declarations
and definitions match.
Use the same ctype for wrapper declarations and definitions and just expand
$resolved_type differently in the two cases.
This simplifies the typemaps and ensures that the declarations and definitions
use the same types, at least for all non-object parameters.
We can always just use the "unconst" one because it works when the type is
used for a return value and is the same as the other one when it's used for a
parameter anyhow because top-level const is ignored in function signatures, so
don't bother defining two sets of macros when one will do.
In many (although perhaps not all, so don't suppress this warning
unconditionally) cases, there is no need for special typemaps in C, the
parameters can be just used directly, so this warning is harmless but it was
given many times during the test suite execution, distracting from more
important messages.
It is impossible to have two functions with the same name inside the same
program, but it is possible to provide a #define to allow the user code to use
the original function name for the wrapper function, so do it for convenience.
Remove the old changes adding explicit "_wrap_" prefix to the examples and the
tests and remove the few more now passing tests from the list of failing tests.
Don't give errors for the unknown types, instead wrap them using the mangled
name of the type.
This is the expected (even if not particularly useful) SWIG behaviour and
allows many more tests to pass.
The generated code, which used C++ scope operator "::" in a C header, didn't
compile and couldn't work anyhow.
Just use the accessor functions for not really global variables.
Although the default typemaps only use "resolved_type" for non-simple types,
the generic SWIGTYPE typemap can also be applied explicitly to other types as
"apply_strings" and "char_binary" unit tests do.
In this case just use the original type unchanged if we can, this is enough to
make these tests pass.
This is better than silently generating completely wrong code with
$resolved_type in it and makes it easier to understand what exactly went wrong
and where.
For some reason the test expected another bit field be changed when setting
the given one, which was just plain wrong and prevented the test from passing.
Don't refer to the typedef name (especially with a typo in it...), it is not
supposed to be exported.
Also fix the write() method call: use the right class for it and pass it the
correct arguments.
The sole reason for including this header seems to be to get size_t
declaration, so include the smallest header sufficient for this.
It would be even better to use a fragment for all size_t typemaps to only
include it if necessary, but it doesn't seem to be worth doing this right now.
Member function pointers can't possibly be represented as function pointers,
they have a strictly bigger size and attempting to do it resulted in code
which, with a lot of bad casts, compiled, but crashed during run-time.
The proper solution is to represent C++ method pointers with an appropriate
opaque type, but for now this remains broken -- just make it explicitly broken
instead of pretending that it works when it actually has no chance to.
Let "namespace_spaces" unit test pass, as it's not really related to the
function pointers, by adding an explicit SWIGC test to it.
