Output anonymous enums defined inside C structs in the global scope, this
doesn't change the semantics as the constants defined inside a struct still
have global scope in C, but avoids gcc warnings given when compiling the
generated code.
Don't force the caller to pass firstChild() of the struct node to this
function, just pass it the struct node itself and iterate over all of its
children inside it.
Don't try to export the variables whose type can't be represented in C
directly, this can't work.
Instead, just let use the default implementation to generate wrapper functions
for them.
Update "cpp_basic_global_var_class" unit test accordingly and remove it from
the list of the failing tests.
We just copied the function prototype without any changes from the original C
function to the wrappers header when in C mode, but this wasn't correct, e.g.
the original function could use typedefs not available in the wrapper.
Fix this by applying the typemaps in C mode too, but without the C++-specific
parts.
This also makes C and C++ code paths slightly less different from each other,
the long-term goal is to make them identical.
Enum element somehow lose the single quotes around them, compensate for it in
C module code (other modules use module-specific constvalue feature to work
around it, but it seems better to do it in SWIG itself rather than leaving the
user code to deal with it).
This finally makes the "enums" unit test pass.
Declare the variable as int as this is how variables of enum types are stored
(although this would have to be revised when support for C++11 base enum type
is added) and, although ugly, this at least allows the generated code to
compile.
This fixes some (but not all yet) errors in the "enums" and "cpp_enum" unit
tests.
Define enum type and enum values as the elements of this enum instead of using
preprocessor #defines for them.
This fixes a couple of enum-related unit tests.
Instead of hard coding two spaces, use "cindent" constant to make it more
clear what is the intended indentation of the generated code and also to make
it possible to change it later easily if desired.
Implement the check for duplicate SWIG_derives_from<> specializations which
could happen if a template type with default parameters was exported both with
implicit default values used for these parameters and the same values
specified explicitly.
This makes the code more complicated and is very rarely needed (in addition to
the above, the template class must also have a base class to trigger the bug),
but it does happen and used to work, so restore this after breaking it in the
last commit and reenable the template_default2 unit test.
Don't populate the typenames array for each and every created object and don't
search it when deleting every object, this is O(N) in number of classes and is
completely impractical for any big library where N can easily be several
thousands. Use destructor function which will correctly destroy the object
instead.
Also don't store each created objects in the global registry, there doesn't
seem to be any point in it.
And, in fact, don't bother with the typenames at all, just use another
pseudo-virtual function for checking whether a class inherits from a class
with the given name.
There is unfortunately one problem with the new approach: it doesn't work when
the same C++ type is wrapped under different names as this results in multiple
specializations of SWIG_derives_from<> for this type. But this is a relatively
rare situation (but which does arise in template_default2 unit test, which had
to be disabled) and could be fixed in the future by completely resolving the
type, including the default template parameters values, and checking if
SWIG_derives_from had been already specialized for it. In the meanwhile, this
regression is not a big deal compared to the advantages of the new approach.
The proxy layer, and all the extra complexity associated with it, seemed to be
only necessary in order to try to allow using the same name for the wrapped
global functions as were used for them in the original C or C++ code being
wrapped. However this could simply never work in all cases, notably it didn't
work at all when using ELF shared libraries under Unix as the functions with
the same name defined in the main program were interposed and replaced the
functions defined in the shared library, meaning that the proxy function foo()
called wrapper function _wrap_foo() which called back into proxy function
foo() itself again, resulting in guaranteed stack overflow. The only possible
way to fix this would be to use "protected" ELF visibility for the original
functions, but this is not always possible (e.g. if the sources of the
original library are not available) and not simple even when it is and,
besides, protected visibility has its own problems -- notably by making it
impossible to hook the library functions when you actually want to do it.
Besides, proxy-based approach simply couldn't work at all when using static
linking as it resulted in two copies of the function with the same name
Most importantly, however, the main task of this module is to wrap C++
classes, not C functions, and renaming them in the wrapper is not necessary at
all in this case as there is no conflict with the original names in this case.
So simply drop the idea of generating a separate proxy header and generate a
header declaring the functions declared in the wrapper instead and, also, do
not give them "_wrap_" prefix whenever possible, i.e. only do it for the
global functions.
This simplifies SWIG code itself and makes it simpler to use its output as
it's not necessary to link both with the wrapper (dynamically) and with the
proxy (statically) and it's not enough to link with the wrapper only and it
can be done in any way (i.e. either statically or dynamically).
As a side effect of this change, Swig_name_proxy() is not necessary any more
and was removed, eliminating the only difference with the master branch in any
source file other than c.cxx itself.
It doesn't make any sense to use protected visibility for the symbols in the
proxy code, the only use for it would be if it could be applied to the
original functions being wrapped, to prevent them from being shadowed by the
proxy versions, but this cannot be done, in general.
Apparently this was already understood as the code using SWIGPROTECT was
commented out, but ef85d0d43f didn't give any
reason for doing this, nor for leaving this code.
Assume there was none and just remove it completely now to avoid confusion.
