• Matches implementation used by modules and godot itself
• Apply same to GDEXTENSION_CLASS, setup with same diff-friendly spacers as GDCLASS
(cherry picked from commit 6eb5d450bd)
Rename __* to _gde_*
https://timsong-cpp.github.io/cppwp/n3337/global.nameshttps://en.cppreference.com/w/cpp/language/identifiers
Identifiers appearing as a token or preprocessing token (i.e., not in user-defined-string-literal like operator ""id) (since C++11) of one of the following forms are reserved:
- identifiers with a double underscore anywhere;
- identifiers that begin with an underscore followed by an uppercase letter;
- in the global namespace, identifiers that begin with an underscore.
Non-exhaustive list of case-sensitive renames:
GDExtension -> GDNative
GDNATIVE -> GDEXTENSION
gdextension -> gdnative
ExtensionExtension -> Extension (for where there was GDNativeExtension)
EXTENSION_EXTENSION -> EXTENSION (for where there was GDNATIVE_EXTENSION)
gdnlib -> gdextension
gdn_interface -> gde_interface
gdni -> gde_interface
The `GDCLASS` macro should not assume to be called inside the `godot`
namespace and should thus prefix function calls for that namespace with
`::godot::` to ensure proper namespace referencing.
The unqualified ClassDB friending was causing (at least for me on
VS2022) an implicit forward declaration of ClassDB in the namespace
of my class, instead of using the godot namespaced one. By qualifying
the namespace, this compiles for me.
Test-Information:
My project builds now.
This is an attempt to make the lifecycle of wrapped objects clearer.
Godot keeps track of bindings' userdata for each object it creates.
This allows allocating the memory of the wrapper only once per object
even if that object is passed multiple times between binding code and
godot code.
The binding information is composed of multiple functions, this includes
a callback for when the userdata is to be allocated (called once) and
for when the userdata is to be deallocated (again, called once).
When allocating data with "memnew" we set the object bindings during the
postinitialize phase, but surely we shouldn't do that when allocating
the userdata as a result of bindings callback themselves.
Additionally, since we let Godot handle (and track) raw memory
allocation and de-allocation, we need to manually call the deconstructor
of the wrapper class during the free callback, to ensure that its
non-trivial members are correctly de-initialized.