This is also not specific to class wrappers, but can, and will be, used
for the global functions, so move it to a place where it can be reused.
No changes yet.
This is much more convenient and allows checking if the shared pointer
is empty easily, unlike before, when it couldn't be done and adding
support for it would have required adding extra functions.
Also add a way to check whether an object is null in C++ wrappers of the
classes handled via shared pointers and static null() method for
creating null objects of such classes.
This makes the typemap much more useful, as it can now reference the
name of the class it is being expanded for and the type of the C pointer
used by it (in principle, the latter could be recovered by using
decltype(), but this results in rather verbose code inside static
methods where a dummy pointer to the type must be constructed first, so
using another special variable seems like a simpler solution).
This makes using returning strings much simpler to use from C++ code as
the returned pointers don't have to be deleted manually -- although, of
course, this does require an extra allocation and copy and so should be
avoided for the very long strings.
Add a new runtime test showing how simple and convenient it is to use
the functions working with string using the C++ wrappers now.
This is similar to the last two commits for cxx_rtype_desc and uses a
more appropriate and more specific class for holding parameter type
description.
This is just a refactoring, no real changes yet.
Instead of using ad hoc terminology, just call the string used here a
typemap because this is what it actually is.
Also keep just a single function and prepend "$result =" to it
automatically if necessary, as this is more convenient.
Still no real changes, but this will make it simpler to add support for
user-specified cxxout typemap.
Maintaining just wrapper start/end fragments is too limiting, at least
for the return type, so allow making the "return action" a formatted
string in which the return value can be inserted at any place.
This will allow making return types more customizable in the upcoming
commits, but there are no changes yet, this is just a refactoring.
Add typecheck typemaps for primitive types and string and call
Swig_overload_check() to ensure that we don't generate two wrappers
functions taking the same "const char*" type if we have overloads taking
it and "std::string" (or a reference) in the original code.
Avoid unnecessary heap allocations, just use temporary variables.
Actually update the string parameters passed by pointer/non-const
reference. This requires the pointers passed to actually be non-const,
so update the C-specific unit test runme to use a char buffer instead of
a literal string.
Also simplify the code copying the string contents to just use strdup()
(if there are ever any platforms where this POSIX functions is not
available, we could just define it ourselves once instead of using
strlen() + malloc() + memcpy() manually twice).
This function doesn't do anything currently so these missing calls are a
latent issue. It could be used for e.g. memory leak checking in the
future though, and it's potentially a useful place to add code when
debugging.
Classes not deriving from another class in the hierarchy must take care
of freeing their current pointer before reassigning it.
This should have been part of 3f3438093 (Define move ctor and assignment
operator for C++ wrappers, 2021-11-24).
Only take ownership of the objects returned from functions that are
explicitly annotated with %newobject or from functions returning objects
by value -- as in this case nothing else can own the returned object
anyhow.
This required changing the code slightly to let do_resolve_type() access
the function node pointer, as the information we need is only available
in it and not in the dummy node passed to us when we're called from
inside Swig_typemap_lookup() due to $typemap() expansion.
We only support v8 5.0 and later now.
libv8-dev is no longer packaged in newer Ubuntu releases, so it
seems there isn't an easy way to update this to test a supported
v8 version, but really v8 via node is the configuration people will
actually use anyway.
Test the documented minimum version 6 and some later versions
as was done on Travis.
Using ubuntu-18.04 as I couldn't get these versions to work on newer
ubuntu-20.04 (some horrid c++ compilation errors)
Fixes#2101. There are 3 related changes made here:
1. Move the SWIG_globals() singleton into pyrun from pyint so it
is visible to SWIG_Python_DestroyModule(). The static globals
varlink has been extracted out of the function so that it can
be set to NULL in SWIG_Python_DestroyModule(), which fixes the
issue described in #2101. (Now when the second interpreter
starts up, the Swig_Globals_global pointer will be NULL, so it
knows it has to create a new one.)
2. Remove a Py_DECREF on the globals varlink. The decrement is now
performed by DestroyModule(), so there's no need to do it in
SWIG_init().
3. Fixed similar issue with SWIG_Python_TypeCache().
Use enum types instead of int for the enum-valued parameters and
function return values, this is more type-safe and clear for the users
of the library.
Change cpp_enum unit test to use C++ to check that C++ enum wrappers
can at least be compiled, but still use C API in it.
Note that enum whose underlying type is bigger than int still don't
work, but this is no different from what it was before, so just document
this limitation but don't do anything else about it for now.
This commit is best viewed ignoring whitespace-only changes.
Also use sym:name even for typedefs for enums themselves, as they can
%renamed as well.
Note that this means that "tdname" itself should probably be never used
at all at this level, but it's still used for structs in C mode, which
is almost certainly wrong.
Ever since fb4d70027 (Represent enums as themselves in generated code,
2016-04-14) the code used "name" attribute for the enums themselves
instead of "sym:name". The reason for this was documented in the comment
added in f4ee8e536 (Fix names of enums and their elements, 2021-11-04),
but this explanation was only half-correct: although we indeed shouldn't
use sym:name for typedefs, we should use it for the enums themselves, as
otherwise renaming them didn't work and enums were generated in the
wrappers with the wrong names.
Fix this by using sym:name for non typedef'd enums.
