1. What does RTTR means?

It stands for Run Time Type Reflection and is a word creation derived from RTTI (Run Time Type Information).

2. What is the advantage of runtime reflection with RTTR over compile time reflection?

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.

3. How can I get a list of all derived classes from a certain type?

struct base { RTTR_ENABLE() }; struct derived : base { RTTR_ENABLE(base) };

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'

4. Is the library ready to use in production environment?

In my oppinion, yes, because:

  • There is a CI Server which test every commit for every supported compiler and architecture.
  • There are more than thousand unit tests with a pretty good code coverage of over 90%.
  • You find online an extensive documentation, with tutorial, API reference and examples.
  • The code is open source, when you find a bug, open up an issue or send a pull request via GitHub. There is no overcomplicated development process.

5. Why is there no automatically registration of the reflection information?

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.

6. Why should I use RTTR, when I already use my reflection library/tool ?

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.

7. When compile time reflection will come in a next C++ standard, will this library still be necessary?

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.

Nevertheless, when you want to do fine tune the properties and metadata you want to reflect, you have to do it manually anyway.