Add alternative class hierarchy registration to avoid RTTR_ENABLE

[seanmiddleditch]

As RTTR_ENABLE is intrusive to the class it cannot be used with third-party types.

An alternative approach I use is to add a .base_class<T>() member function to the registration interface. This allows a user to manually add base classes to a type when they are not able to - or don't want to - modify a class definition.

namespace thirdparty {
  class Foo : public Bar, boost::thingy {};
}

// later
registration::class_<thirdparty::Foo>("Foo")
  .base_class<thirdparty::Bar>()
  .base_class<boost::thingy>
  .constructor<>();

[acki-m]

The reason why I didn't implemented that way is, RTTR does not depend on rtti.
This macro RTTR_ENABLE adds a virtual member function to get the actual type of an object.
Furthermore, its add a type list of all base classes. So I can later during the registration process retrieve from a class this type list at compile time. I don't have to build up a base class list depending on registration order.

So the macro RTTR_ENABLE is needed anyway and it makes the registration process for base classes easier. That's why I choose this solution. It one tiny macro, like Q_OBJECT, but here at least no super base class is needed 😃.
The reason why I not use rtti is, on some platforms it is broken: https://svn.boost.org/trac/boost/ticket/754
and for some projects (game engines, browser) it might be a requirement to disable rtti or it is even not supported by the used compiler.

No question, I would like to remove the macro, but then RTTR has to use rtti to retrieve the actual type (I think with some kind of mapping type_info objects to rttr::type objects).

Or do you know a way to retrieve the actual type of a base class without rtti?

[seanmiddleditch]

No RTTI is needed for .base_class<T>() registration.

You likewise don't need the macro for type lookup in general.

There are certain features it will be needed for, but those features should be opt-in. For instance, if I don't need polymorphic type() support, I do not need the macro. You can instead achieve lookup using template specialization and a non-intrusive macro like:

namespace math {
  // absolutely cannot have a virtual function added to it!!!
  class SmallPOD { float x, y, z; };
} // namespace math

RTTR_EXTERNAL(SmallPOS);

#define RTT_EXTERNAL(T)
namespace rttr { template<> struct _type<T> { static type& get() {...} }; }

And then the actual rttr::type uses a tiny bit of SFINAE to determine if it should use T::get_type() or rttr::_type::get() for a given type or if it should emit a compile-time error.

All of this is quite possible, and very much game engine friendly, I assure you; all three of the bugs I filed are informed by ways in which RTTR falls short of the reflection engine we use in our large commercial game engine. :)

[acki-m]

Maybe I have to improve the documentation about this macro.
The macro RTTR_ENABLE is only needed when you are working with class hierarchies.
So for your case, it is NOT needed, you can leave it out.

However, when you are working with class hierarchies. You should use the macro.

That way, you can invoke properties, with the base class or whatever your current type is.
RTTR will try to cast your pointer to the class type, where the property/method was registered with.

base* b = new derived;

property prop = type::get("derived").get_property("prop1").set_value(b, 23);

Lets say prop1 was registered with the derived class, but I provide a base pointer.
So RTTR does now have to retrieve the most derived type from base. Therefore the macro adds the virtual function get_type.

I have the slight feeling that we are talking past each other.
I've never said that .base_class<T>() needs RTTI.

Btw. all your three issues are no bugs, that are future requests 😉

[seanmiddleditch]

Gotcha. Indeed, polymorphic queries are the only case it should be required, as you describe. I'm fine with this request being closed then. :)