Implement copy and move constructors for gdxx::GodotCustomClass #2

New issue

Closed

opened 2026-10-21 00:53:32 -07:00 by queertherians.org · 2 comments

queertherians.org commented

2026-10-21 00:53:32 -07:00

Owner

Starting at line 138 in include/GodotClass.hpp:

#warning TODO: copy and move

GodotCustomClass(const GodotCustomClass&) = delete;
void operator=(const GodotCustomClass&) = delete;
GodotCustomClass(GodotCustomClass&&) = delete;
void operator=(GodotCustomClass&&) = delete;

Copying will likely involve some sort of call to gdxx::API::variant_new_copy(...) if that is compatible with our instantiated object, while updating(!) the binding¹ to the native object itself. Moving might also require updating the binding¹.

More research or discussion is required before I'll feel confident enough to tackle this one.

"binding", or whatever associates the Godot Object to the Native Object; I'm currently unsure on the nomenclature ↩︎

Starting at line 138 in [`include/GodotClass.hpp`](https://barkvr.dev/queertherians.org/gdxx/src/commit/188b63a6e5915e28418e8637cabd3aa441de3bd1/include/GodotClass.hpp#L138): ```cpp #warning TODO: copy and move GodotCustomClass(const GodotCustomClass&) = delete; void operator=(const GodotCustomClass&) = delete; GodotCustomClass(GodotCustomClass&&) = delete; void operator=(GodotCustomClass&&) = delete; ``` Copying will likely involve some sort of call to `gdxx::API::variant_new_copy(...)` if that is compatible with our instantiated object, while *updating(!)* the binding[^1] to the native object itself. Moving might also require updating the binding[^1]. More research or discussion is required before I'll feel confident enough to tackle this one. [^1]: "binding", or whatever associates the Godot Object to the Native Object; I'm currently unsure on the nomenclature

queertherians.org added the

enhancement

help wanted

labels

2026-10-21 00:53:32 -07:00

queertherians.org self-assigned this

2026-10-21 00:53:32 -07:00

queertherians.org referenced this issue

2026-10-21 01:06:18 -07:00

Implement gdxx::GodotExternClass #3

queertherians.org added a new dependency

2026-10-21 01:06:32 -07:00

#3 Implement gdxx::GodotExternClass

queertherians.org added this to the Minimum viable product milestone

2026-10-21 18:01:30 -07:00

queertherians.org commented

2026-10-22 21:29:43 -07:00

Author

Owner

Clarification received from #1 (comment link): The native object is more of a "wrapper" around the Godot object instance, and in the case of a custom class, also happens to contain the methods that are to be registered within gdxx::GodotCustomClass<...>::Register() via #5.

There shall exist one instance of the native class per instance of a CustomClass (or wrapped ExternClass) instance.

Fetching of the native object reference within Godot (or even blindly from native via a Godot Object pointer) is managed via API::object_get_instance_binding(...). Lifetime is managed via the InstanceBindingCallbacks (wrapped extern) or ClassCreationInfo (native-defined) callbacks.

As such, due to these insights gained from #1, moving or copying does not actually make any sense for native objects! This issue is to be closed as not planned once the #warning is removed; the copy and move constructors are to remain deleted.

Clarification received from #1 [(comment link)](https://barkvr.dev/queertherians.org/gdxx/issues/1#issuecomment-27): The native object is more of a "wrapper" around the Godot object instance, and in the case of a custom class, also happens to contain the methods that are to be registered within `gdxx::GodotCustomClass<...>::Register()` via #5. There shall exist one instance of the native class per instance of a CustomClass (or wrapped ExternClass) instance. Fetching of the native object reference within Godot (or even blindly from native via a Godot Object pointer) is managed via `API::object_get_instance_binding(...)`. Lifetime is managed via the InstanceBindingCallbacks (wrapped extern) or ClassCreationInfo (native-defined) callbacks. As such, due to these insights gained from #1, __moving or copying does not actually make any sense for native objects!__ This issue is to be closed as not planned once the `#warning` is removed; the copy and move constructors are to remain deleted.

queertherians.org removed the

help wanted

label

2026-10-22 21:29:51 -07:00

queertherians.org commented

2026-10-22 21:46:42 -07:00

Author

Owner

As an additional note, object copying is theoretically possible, but it should be kept in mind that doing API::variant_new_copy seems to just copy it as a reference. A true copy would involve the construction of a new object and doing a deep-copy of all elements (through a copy constructor for native objects, and/or some kind of clone(), copy(), or duplicate() method for Godot objects, in e.g. gdscript).

This type of copying, specifically the method name to be defined for cloning or copying in the Godot/gdscript side, seems to be undefined by the Godot spec, and as such, a copy constructor and cloning methodology is left as an exercise to the user of the library. Copy functionality will be left out of the base library. Move functionality still doesn't make much sense, as the lifetime of the object is tied to the Godot object's lifetime, and they are always passed by reference, and never by copy/move. Still closing.

As an additional note, object copying *is* theoretically possible, but it should be kept in mind that doing `API::variant_new_copy` seems to just copy it as a reference. A true copy would involve the construction of a new object and doing a deep-copy of all elements (through a copy constructor for native objects, and/or some kind of `clone()`, `copy()`, or `duplicate()` method for Godot objects, in e.g. gdscript). This type of copying, specifically the method name to be defined for cloning or copying in the Godot/gdscript side, seems to be undefined by the Godot spec, and as such, a copy constructor and cloning methodology is left as an exercise to the user of the library. Copy functionality will be left out of the base library. Move functionality still doesn't make much sense, as the lifetime of the object is tied to the Godot object's lifetime, and they are always passed by reference, and never by copy/move. Still closing.

queertherians.org referenced this issue from a commit

2026-10-22 21:50:09 -07:00

Remove warning for missing copy/move

queertherians.org

2026-10-22 21:51:47 -07:00