It stands for Run Time Type Reflection and is a word creation derived from RTTI (Run Time Type Information).
Minimal compile times, when modifying the registration. Everything is done in the cpp
files.
Furthermore, you can work with types, where you don't even have the headers available. Just think about plugins,
where it is not necessary anymore to derive from some common base class and implement standard interfaces.
struct base { RTTR_ENABLE() }; struct derived : base { RTTR_ENABLE(base) };
RTTR_REGISTRATION
{
rttr::registration::class_<base>("base");
rttr::registration::class_<derived>("derived");
}
array_range<type> base_list = rttr::type::get<base>().get_derived_classes();
for (auto& t : base_list)
std::cout << t.get_name() << std::endl; // prints 'derived'
In my oppinion, yes, because:
Because that would be an additional feature. I wanted to avoid that the class is stuttered with custom attributes or lot of macros to retrieve the reflection information. RTTR should be easily implemented in an existing code base. With that approach the programmer has full control over the reflection information. So it is even possible at runtime to decide to register the information or not.
Because RTTR is just a C++ library with no additional library dependencies, you can easily try it out within your existing and huge code base. It might have some unique features which not every reflection libraries/system have.
For instance invoking a property or method from any arbitrary class hierachy level:
std::shared_ptr<base_class> base_obj = std::make_shared<derived_class>();
type t = type::get(*base_obj.get()); // returns the type 'derived_class'
// will look up the whole class hierarchy from 'derived_class' to 'base_class' for a property named 'visibility'
property prop = t.get_property("visibility");
// it's possible to invoke the property, from every arbitrary class hierarchy level,
// it also doesn't matter, when its wrapped in a shared_ptr
prop.set_value(base_obj, false);
Uses a modern and easy to use interface, no raw pointers in the API! It has a very permissive license.
Of course, because with RTTR you can introspect types, which are not known at compile time. Which is of course not possible with compile time reflection. However, RTTR can be benefit from this features, with an semi automatic register process. Something like this:
// will introspect all types at compile time and create wrappers for it automatically.
rttr::registration::auto_register_all_members<MyClass>();
Nevertheless, when you want to do fine tune the properties and metadata you want to reflect, you have to do it manually anyway.