There is no need to override it just to call the base class version.
Also remove the outdated comment, as %extend is supported currently
(albeit with some bugs remaining).
No real changes.
Don't mark functions not intended to be overridden (nor overriding those
in the base class) as "virtual", this is useless and confusing.
No real changes.
By delegating to the base class instead we not only save quite a few
lines of code, but gain support for ctors/dtors defined using %extend,
which didn't work before, allowing to reenable some of the previously
failing tests.
This is useless and the C-specific version didn't handle template
methods added with %extend correctly, so removing this code also fixes
some (but not all yet) failures in extend_template_method.cpptest unit
test.
This is never going to work and just results in generating uncompilable
code.
In principle, we could either generate wrappers for these functions
while still handling the struct as a plain C struct, or switch to
generating class-like wrappers for it if it's %extended with any
functions, but for now just ignore them as this is the simplest thing to
do.
Incidentally, this makes the default_args_c test pass again now, after
the last merge with master pulled in such %extend directives into it.
This didn't work correctly before because we need to override the base class
replaceSpecialVariables() method to expand $resolved_type, which appears
during the expansion, using the type supplied as $typemap() argument instead
of doing it later using it the type to which the typemap containing the macro
is attached.
This is a prerequisite for implementing smart pointers support.
This will allow implementing replaceSpecialVariables(): as it is called from
inside the typemap lookup code, we can't pass any parameters to it directly,
but we can use a class language-global member variable to it indirectly.
No real changes yet.
Don't create a new node just to delete it if we don't need it, but rather only
create it if we do need it.
Also copy as much as can be copied in copy_node() helper, it was confusing to
copy part of the attributes in it and part in the caller. And one of them
("c:inherited_from") was even copied twice, it was first created in the
function and then unconditionally overwritten by the caller -- don't do this
any more.
No real changes.
Typedefs were not resolved for non-object types in spite of
SwigType_typedef_resolve_all() call as it didn't affect "c_parm_type".
Actually it is not even clear if resolving typedefs is a good idea as using
them probably makes the generated code more clear, but at least in the case of
nested typedefs we do need to do it as "Class::Type" can't appear in C code.
For some reason, the copy of the function made in the derived class used the
"name" attribute instead of "sym:name", which means that any %renames attached
to it were lost and didn't affect the derived class version.
Fix this and also a problem uncovered by doing it in the operator_overload
unit test as the assignment operator shouldn't be inherited at all, the
compiler-generated operator is used instead if the derived class doesn't
define its own one.
This function seemed to be doing a few unnecessary things, e.g. it resolved
the typedefs which doesn't seem to be necessary and the test for member
pointer seems to be useless too.
Just add a local "cppresult" directly in the caller instead of using a
separate function to do all this.
Using "sym:name" in the wrapping code is wrong, it is different from "name" if
the function has been renamed and we need to call the original C function, not
whichever name it is exported under.
Using longjmp was incompatible with using C++ objects in the code using the
wrappers, and using this C API from C++ to avoid ABI incompatibilities between
different C++ compilers is one of the main reasons for using this module.
Also, this required using a separate SwigObj instead of just using the real
object pointer which inevitably resulted in memory leaks whenever a non owned
object was returned from anywhere, e.g. from a member accessor or any method
returning pointer or reference.
Abandon the attempts to recreate C++ exceptions in C and just use a very
simple approach allowing to pass an error message out of band after any
function call in a global variable. An alternative could be to add a special
"out" error parameter to each and every function, but this risked being too
verbose, especially for the functions which don't really throw, and the calls
to SWIG_PendingException_get() won't need to be made explicitly when using a
C++ wrapper around the generated C API in the future.
This simplifies both the module and the generated code, in particular we don't
need any runtime code at all any more and there is no need for an extra level
of indirection for every object.
It also makes a couple more tests pass.
At the very least this results in clear error messages when running SWIG if
the symbol is encountered twice instead of errors given only when compiling
the generated code later.
The only remaining use of this attribute is to test for whether we're wrapping
a ctor and it is simpler and more clear to just check the node type directly
in this case.
This attribute was pretty confusing as it was used for parameters and entire
declarations, so removing it makes things more clear and simpler.
There is no need to set c:objstruct for the first parameter of the methods now
that we take care of it for disambiguating between overloads explicitly and
this function doesn't seem to be useful for anything else, simply drop it.
When building the unique suffix for each member of the overloaded functions
set, don't use the first "this" parameter of the object methods in it as it's
the same for all of them and so is completely useless for disambiguation
purposes and just results in unnecessarily long and ugly names.
Use "_const" suffix for the methods differing by their const-ness only, this
is necessary now that we don't use "_pFoo" or "_pcFoo" in their names.
This makes it superfluous to check for c:objstruct in
functionWrapperAppendOverloaded() (and checking for it there was not enough
neither, as the changes in the test suite show, sometimes the "this" parameter
type still found its way into the generated wrappers).
Just use our custom object creation/destruction code, but let the base class
do everything else.
This uncovered complete lack of support for ctors/dtors defined using %extend,
but this is not new and will have to remain broken for now.
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.
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.
