GDCLASS macro prohibits use of pure virtual functions

[Naros]

Godot version

4.2 beta3

godot-cpp version

4.2 beta3

System information

Windows 11

Issue description

When trying to create a GDExtension abstract class, the compiler fails to allow pure virtual functions, reporting:

error C2259: 'ParentClass': cannot instantiate abstract class

This is because the GDCLASS macro explicitly makes two references to where it attempts to create the class object, specifically in these two static methods:

static GDExtensionObjectPtr create(void *data) {
	m_class *new_object = memnew(m_class);
	return new_object->_owner;
}

static GDExtensionClassInstancePtr recreate(void *data, GDExtensionObjectPtr obj) {
	_GDCLASS_RECREATE(m_class, m_inherits);
}

The ability to use GDCLASS in GDNative and construct abstract classes exists. I would suggest that GDCLASS function like it does in GDNative and these two specific methods be added to either a separate macro or we introduce a new GDCLASS_ABSTRACT macro that can be used specifically for abstract class construction with all but the above 2 functions defined.

Steps to reproduce

Create a class hierarchy as follows

class ParentClass : public Resource {
  GDCLASS(ParentClass, Resource);
  static void _bind_methods() {}
  virtual void pure_virtual_method() = 0;
}

class ChildClass : public ParentClass {
  GDCLASS(ChildClass, ParentClass);
  static void _bind_methods() { }
  void pure_virtual_method() override { }
}

Minimal reproduction project

N/A

[dsnopek]

Thanks!

This is a tricky one.

Since Godot modules can register abstract classes, we want to allow godot-cpp to do so as well. However, we also want to try to mimic the module API as much as possible, and in a module, you can use GDCLASS() for both normal and abstract classes. So, ideally, we'd like the same GDCLASS() macro to be used for both in godot-cpp as well (as opposed to adding a GDCLASS_ABSTRACT() macro).

Maybe there's a way to move the generation of the create() and recreate() functions to templates that are only realized when calling ClassDB::register_class<T>()?

Something like this super incomplete psuedo code:

template<class T>
class ClassCreator {
	static GDExtensionObjectPtr create(void *data) {
		T *new_object = memnew(m_class);
		return new_object->_owner;
	}
};

template <class T>
void ClassDB::_register_class() {
	GDExtensionClassCreationInfo2 class_info = {
		// ...
		&ClassCreator<T>::create,
		// ...
	};
}	

And then when registering abstract classes, we wouldn't use that, we'd just use nullptr for the creation function.

Hopefully that idea makes sense :-)

[Naros]

@dsnopek So I see that _GDCLASS_RECREATE takes the parent class type; however, it isn't used in the macro. Are you okay with simply having the macro accept the m_class argument only?

[Zylann]

Is there some sort of if constexpr we could use to check if the class has pure virtual functions?
Otherwise I wonder why create would have to be in the class, if it can be moved out that would be better I think

[AThousandShips]

There is std::is_abstract