Problem
Within the section on registering a signal a helper function is defined which states afterwards:
At the end we need to destruct the Variants we created. While technically the
Vector2 one does not require destructing, it is clearer to cleanup everything.
There are two issues:
- This message is misleading, as it makes me think it has been cleaned up.
- Nothing explains why Vector2 doesn't need to be destroyed but other things do.
|
void call_2_args_stringname_vector2_no_ret_variant(GDExtensionMethodBindPtr p_method_bind, GDExtensionObjectPtr p_instance, const GDExtensionTypePtr p_arg1, const GDExtensionTypePtr p_arg2) |
|
{ |
|
// Set up the arguments for the call. |
|
Variant arg1; |
|
constructors.variant_from_string_name_constructor(&arg1, p_arg1); |
|
Variant arg2; |
|
constructors.variant_from_vector2_constructor(&arg2, p_arg2); |
|
GDExtensionConstVariantPtr args[] = {&arg1, &arg2}; |
|
|
|
// Add dummy return value storage. |
|
Variant ret; |
|
|
|
// Call the function. |
|
api.object_method_bind_call(p_method_bind, p_instance, args, 2, &ret, NULL); |
|
|
|
// Destroy the arguments that need it. |
|
destructors.variant_destroy(&arg1); |
|
destructors.variant_destroy(&ret); |
|
} |
|
|
|
This helper function has some boilerplate code but is quite straightforward. It sets up the |
|
two arguments inside stack allocated Variants, then creates an array with |
|
pointers to those. It also sets up another Variant to keep the return value, |
|
which we don't need to construct since the call expects it to be uninitialized. |
|
|
|
Then it actually calls the MethodBind using the instance we provided and the |
|
arguments. The ``NULL`` at the end would be a pointer to a |
|
``GDExtensionCallError`` struct. This can be used to treat potential errors when |
|
calling the functions (such as wrong arguments). For the sake of simplicity |
|
we're not gonna handle that here. |
|
|
|
At the end we need to destruct the Variants we created. While technically the |
|
Vector2 one does not require destructing, it is clearer to cleanup everything. |
Solution
Make it clear that it hasn't been cleaned up but could be (presumably at the expense of more writing more boilerplate).
Alternatively, actually destroy it in the code (if it doesn't expand the docs much).
Ideally, it would be nice to know why Vector2 doesn't need to be destroyed, I noticed in an earlier step it wasn't destroyed either and this was a point of confusion for me.
