A reflection system for MeshFreeFoam: Part 1

Discussing the very first steps of implementing a reflection system for C++ classes. Possible uses, limitations, and future plans are laid out in this post.
By Mohammed Elwardi Fadeli (@elwardi) |
Tags:

  2 minute read  

Motivation

Lazy evaluation is not the only thing I envy in .Net languages. It’s one of two things, the other being their runtime reflection systems. This feature is not exclusive to .Net languages; it’s found in all reflective languages (e.g., JavaScript, Java, Python, Go, Julia, etc.), except for C++.

The perfect implementation of a reflection system for OpenFOAM-based code will:

  1. Be fully implemented at compile-time (with zero runtime cost) but allow access to reflection information at runtime.
  2. Be compatible with the runtime selection mechanism.
  3. Support automatic serialization to JSON/XML for creating objects from a Web UI (or a TUI for that matter).
  4. Support building efficient proxy classes for objects to expose (private? protected?) fields to Web UI widgets.

Current plans

It doesn’t seem like a lot of work, but the challenges lie in meeting my specific requirements 1 and 2 above. There are few ways to achieve this:

  1. Building a C++ Reflection System in One Weekend Using Clang and LLVM demonstrates a method using compiler magic to generate reflection code. It parses the headers’ AST and generates C++ files to include in the final compilation units. This approach is not preferred due to two main reasons:

    • It requires annotating classes and fields for reflection.
    • A separate tool must run on the classes’ headers with the correct compiler flags set to generate the reflection code, adding maintenance overhead.

  2. refl-cpp implements a version without parsing the AST, which is the preferred approach. It will serve as the main inspiration for developing the reflection system.

  3. C++ Reflection TS can be option for future projects. But as, at best, It’ll make into the standard by c++26, and we’ll have to wait for 1-2 years for compiler support, it’s better if we don’t rely on such experimental proposals. Currently, only clang can compile code from the proposal.

Work on this front will begin as soon as I can visualize the meshfree domain (i.e., the particles) with ParaView. Immediate issues that must be addressed include:

  • Ensuring both the reflection system and the runtime selection mechanism can coexist smoothly.
  • Exposing fields of default OpenFOAM types (e.g., List, triSurface, etc.), which may not be trivial.