What do you do with RTTR?

[acki-m]

I am curious to see where RTTR is used and what task are you solving with it? Please post in which projects you are using it, closed or open source doesn't matter. On which platform are you using it? What do you like about RTTR? What could be improved? What feature is missing?

[ForgeMistress]

I use it for general reflection in my project that I call Firestorm (repo is up on my github if anyone wants to take a look), where I modified the registration macros to make the registration logic scoped to each object I'm tying to the system (This has the upside of allowing multiple separated registrations in the implementation files). The downside is that I have to manually call the registration functions, but I've worked around it so that it's not as much of an issue. This arose because I separate my project into discrete static libraries that contain classes for each purpose (libUI will contain IMGUI integration, libIO wraps physics FS for file IO, libHarnessed has the test harness classes, etc...). Because the Visual Studio compiler likes to discard symbols and code that aren't actively used by the program, I was having problems with ensuring that objects were being registered when I needed their rttr::type to do some object construction.

One of the things I would like to see is the ability to pass construction policies into the rttr::type::make function so that I can decide at runtime how I want an object to be constructed and returned, rather than defining the policy in the reflection definition. It would be a huge boon and increase code clarity when so.eone goes to look at it, because the factory capabilities of rttr are very good. They could be even better this way.

Another potential issue I have is memory footprint. I did some memory profiling and a snapshot shows that there are some classes that could have their footprint reduced and in a library that relies on defining static data, care should definitely be taken when it comes to this. I'm going to be making a separate issue about this in particular, but I thought I'd mention it here.

All in all, it's a great multi-purpose reflection library that you can do a lot with. There are just a lot of rough edges and quirks that need to be worked around. I'll make issues about those quirks as I encounter them.

[enci]

My plan is to use RTTR for some game tech as well. In particular to expose variables for tweaking, serialization and potentially exposing to script. At current, I am using imgui for the UI and cereal for serialization; and I need to manually expose my variables.

My current project is in production, so I would not jump on RTTR till the next one. For me, it needs to compile and work on consoles, which can be challenge. Adding attributes to variables, a bit like C#'s attributes would be fantastic, but I assume it could bloat the library quickly.

[enci]

I took a deeper look and it the attributes (metadata) work well for me already. RTTR builds on both consoles that I am developing for. It also plays ok with cereal, but I would not mind having serialization straight in RTTR. Other than that, great job and I hope it stays alive for long time.

[ForgeMistress]

@enci If I may, which console platforms did you build for?

[amerkoleci]

I would like to use rttr as reflection library for my game engine, my plan is to have loading/saving and usage into my ECS system (https://github.com/amerkoleci/alimer), will provide more info later.

[dand-oss]

Used throughout our 3,000 class, 300K line application

• expose C++ ctors/attribs/methods and conversions to our scripting language
• used to automate QT, around 90 panels and graphs
• Called via python C API interface to run machine learning programs and user scripts
• extend the python "c extension" via plugin dlls - load new C++ dls, and use RTTR instrumented C++ classes from python (no need for swig, boost python, C wrappers, etc)
• "redirect" C++ wrapper classes to call RTTR instrumented "has a" member without any wrapper code (just a few lines)

The Python interface, python C extension for plugins, QT converter, and scripting lex/yacc/stack machine VM might be useful to upstream to RTTR.

Used in windows 32/64 with Visual Studio, and gcc/clang on Linux.

I like that we don't have to maintain our own ctor/prop/method wrappers any longer.

The type engine/inference is very useful, better than what we did - clever. RTTR type conversions were very necessary for our code base.

Compile times decline if too much RTTR is used. We had to remove ctors because the objects grew too large.

A clear way to associate "dirty" state with data would be useful.

[SheldonSir]

This Game Engine use RTTR https://github.com/volcoma/EtherealEngine.git

[btgoodwin]

I realize this is an old thread, but I've been using this in my organization to setup a conversion library for various types that our service-facing interfaces use, like JsonGLIB and the SocketIO-Client-CPP "message" structure (which itself gets built by interpreting JsonGLIB objects). I'm working to get the library released publicly so others can make use of it.

[YongchaoWangg]

Used throughout our 3,000 class, 300K line application

• expose C++ ctors/attribs/methods and conversions to our scripting language
• used to automate QT, around 90 panels and graphs
• Called via python C API interface to run machine learning programs and user scripts
• extend the python "c extension" via plugin dlls - load new C++ dls, and use RTTR instrumented C++ classes from python (no need for swig, boost python, C wrappers, etc)
• "redirect" C++ wrapper classes to call RTTR instrumented "has a" member without any wrapper code (just a few lines)

The Python interface, python C extension for plugins, QT converter, and scripting lex/yacc/stack machine VM might be useful to upstream to RTTR.

Used in windows 32/64 with Visual Studio, and gcc/clang on Linux.

I like that we don't have to maintain our own ctor/prop/method wrappers any longer.

The type engine/inference is very useful, better than what we did - clever. RTTR type conversions were very necessary for our code base.

Compile times decline if too much RTTR is used. We had to remove ctors because the objects grew too large.

A clear way to associate "dirty" state with data would be useful.

Similar usage. Everything works. Just one drawback: building whole project on 4 cores takes 30 min.