Header-only, non-intrusive and macro-free runtime reflection system in C++

Overview

Header-only runtime reflection system in C++

GitHub version Build Status Coverage Donate

The reflection system was born within EnTT and is developed and enriched there. This project is designed for those who are interested only in a header-only, full-featured, non-intrusive and macro free reflection system which certainly deserves to be treated also separately due to its quality and its rather peculiar features.

If you use meta and you want to say thanks or support the project, please consider becoming a sponsor.
You can help me make the difference. Many thanks to those who supported me and still support me today.

Table of Contents

Introduction

Reflection (or rather, its lack) is a trending topic in the C++ world. I looked for a third-party library that met my needs on the subject, but I always came across some details that I didn't like: macros, being intrusive, too many allocations.
In one word: unsatisfactory.

I finally decided to write a built-in, non-intrusive and macro-free runtime reflection system for my own.
Maybe I didn't do better than others or maybe yes. Time will tell me.

Build Instructions

Requirements

To be able to use meta, users must provide a full-featured compiler that supports at least C++17.
The requirements below are mandatory to compile the tests and to extract the documentation:

  • CMake version 3.2 or later.
  • Doxygen version 1.8 or later.

If you are looking for a C++14 version of meta, feel free to contact me.

Library

meta is a header-only library. This means that including the factory.hpp and meta.hpp headers is enough to include the library as a whole and use it.
It's a matter of adding the following lines to the top of a file:

#include <meta/factory.hpp>
#include <meta/meta.hpp>

Then pass the proper -I argument to the compiler to add the src directory to the include paths.

Documentation

The documentation is based on doxygen. To build it:

$ cd build
$ cmake .. -DBUILD_DOCS=ON
$ make

The API reference will be created in HTML format within the directory build/docs/html. To navigate it with your favorite browser:

$ cd build
$ your_favorite_browser docs/html/index.html

It's also available online for the latest version.

Tests

To compile and run the tests, meta requires googletest.
cmake will download and compile the library before compiling anything else. In order to build without tests set CMake option BUILD_TESTING=OFF.

To build the most basic set of tests:

  • $ cd build
  • $ cmake ..
  • $ make
  • $ make test

Crash course

Names and identifiers

The meta system doesn't force the user to use a specific tool when it comes to working with names and identifiers. It does this by offering an API that works with opaque identifiers that for example may or may not be generated by means of a hashed string.
This means that users can assign any type of identifier to the meta objects, as long as they are numeric. It doesn't matter if they are generated at runtime, at compile-time or with custom functions.

However, the examples in the following sections are all based on std::hash<std::string_view> as provided by the standard library. Therefore, where an identifier is required, it's likely that an instance of this class is used as follows:

std::hash<std::string_view> hash{};
auto factory = meta::reflect<my_type>(hash("reflected_type"));

For what it's worth, this is likely completely equivalent to:

auto factory = meta::reflect<my_type>(42);

Obviously, human-readable identifiers are more convenient to use and highly recommended.

Reflection in a nutshell

Reflection always starts from real types (users cannot reflect imaginary types and it would not make much sense, we wouldn't be talking about reflection anymore).
To reflect a type, the library provides the reflect function:

meta::factory factory = meta::reflect<my_type>(hash("reflected_type"));

It accepts the type to reflect as a template parameter and an optional identifier as an argument. Identifiers are important because users can retrieve meta types at runtime by searching for them by name. However, there are cases in which users can be interested in adding features to a reflected type so that the reflection system can use it correctly under the hood, but they don't want to allow searching the type by name.
In both cases, the returned value is a factory object to use to continue building the meta type.

A factory is such that all its member functions returns the factory itself. It can be used to extend the reflected type and add the following:

  • Constructors. Actual constructors can be assigned to a reflected type by specifying their list of arguments. Free functions (namely, factories) can be used as well, as long as the return type is the expected one. From a client's point of view, nothing changes if a constructor is a free function or an actual constructor.
    Use the ctor member function for this purpose:

    meta::reflect<my_type>(hash("reflected")).ctor<int, char>().ctor<&factory>();
  • Destructors. Free functions can be set as destructors of reflected types. The purpose is to give users the ability to free up resources that require special treatment before an object is actually destroyed.
    Use the dtor member function for this purpose:

    meta::reflect<my_type>(hash("reflected")).dtor<&destroy>();

    A function should neither delete nor explicitly invoke the destructor of a given instance.

  • Data members. Both real data members of the underlying type and static and global variables, as well as constants of any kind, can be attached to a meta type. From a client's point of view, all the variables associated with the reflected type will appear as if they were part of the type itself.
    Use the data member function for this purpose:

    meta::reflect<my_type>(hash("reflected"))
        .data<&my_type::static_variable>(hash("static"))
        .data<&my_type::data_member>(hash("member"))
        .data<&global_variable>(hash("global"));

    This function requires as an argument the identifier to give to the meta data once created. Users can then access meta data at runtime by searching for them by name.
    Data members can be set also by means of a couple of functions, namely a setter and a getter. Setters and getters can be either free functions, member functions or mixed ones, as long as they respect the required signatures.
    Refer to the inline documentation for all the details.

  • Member functions. Both real member functions of the underlying type and free functions can be attached to a meta type. From a client's point of view, all the functions associated with the reflected type will appear as if they were part of the type itself.
    Use the func member function for this purpose:

    meta::reflect<my_type>(hash("reflected"))
        .func<&my_type::static_function>(hash("static"))
        .func<&my_type::member_function>(hash("member"))
        .func<&free_function>(hash("free"));

    This function requires as an argument the identifier to give to the meta function once created. Users can then access meta functions at runtime by searching for them by name.

  • Base classes. A base class is such that the underlying type is actually derived from it. In this case, the reflection system tracks the relationship and allows for implicit casts at runtime when required.
    Use the base member function for this purpose:

    meta::reflect<derived_type>(hash("derived")).base<base_type>();

    From now on, wherever a base_type is required, an instance of derived_type will also be accepted.

  • Conversion functions. Actual types can be converted, this is a fact. Just think of the relationship between a double and an int to see it. Similar to bases, conversion functions allow users to define conversions that will be implicitly performed by the reflection system when required.
    Use the conv member function for this purpose:

    meta::reflect<double>().conv<int>();

That's all, everything users need to create meta types and enjoy the reflection system. At first glance it may not seem that much, but users usually learn to appreciate it over time.
Also, do not forget what these few lines hide under the hood: a built-in, non-intrusive and macro-free system for reflection in C++. Features that are definitely worth the price, at least for me.

Any as in any type

The reflection system comes with its own meta any type. It may seem redundant since C++17 introduced std::any, but it is not.
In fact, the type returned by an std::any is a const reference to an std::type_info, an implementation defined class that's not something everyone wants to see in a software. Furthermore, the class std::type_info suffers from some design flaws and there is even no way to convert an std::type_info into a meta type, thus linking the two worlds.

A meta any object provides an API similar to that of its most famous counterpart and serves the same purpose of being an opaque container for any type of value.
It minimizes the allocations required, which are almost absent thanks to SBO techniques. In fact, unless users deal with fat types and create instances of them though the reflection system, allocations are at zero.

A meta any object can be created by any other object or as an empty container to initialize later:

// a meta any object that contains an int
meta::any any{0};

// an empty meta any object
meta::any empty{};

It takes the burden of destroying the contained instance when required.
Moreover, it can be used as an opaque container for unmanaged objects if needed:

int value;
meta::any any{std::ref(value)};

In other words, whenever any intercepts a reference_wrapper, it acts as a reference to the original instance rather than making a copy of it. The contained object is never destroyed and users must ensure that its lifetime exceeds that of the container.

A meta any object has a type member function that returns the meta type of the contained value, if any. The member functions try_cast, cast and convert are used to know if the underlying object has a given type as a base or if it can be converted implicitly to it.

Enjoy the runtime

Once the web of reflected types has been constructed, it's a matter of using it at runtime where required.

To search for a reflected type there are two options: by type or by name. In both cases, the search can be done by means of the resolve function:

// search for a reflected type by type
meta::type by_type = meta::resolve<my_type>();

// search for a reflected type by name
meta::type by_name = meta::resolve(hash("reflected_type"));

There exits also a third overload of the resolve function to use to iterate all the reflected types at once:

resolve([](meta::type type) {
    // ...
});

In all cases, the returned value is an instance of type. This type of objects offer an API to know the runtime identifier of the type, to iterate all the meta objects associated with them and even to build or destroy instances of the underlying type.
Refer to the inline documentation for all the details.

The meta objects that compose a meta type are accessed in the following ways:

  • Meta constructors. They are accessed by types of arguments:

    meta::ctor ctor = meta::resolve<my_type>().ctor<int, char>();

    The returned type is ctor and may be invalid if there is no constructor that accepts the supplied arguments or at least some types from which they are derived or to which they can be converted.
    A meta constructor offers an API to know the number of arguments, the expected meta types and to invoke it, therefore to construct a new instance of the underlying type.

  • Meta destructor. It's returned by a dedicated function:

    meta::dtor dtor = meta::resolve<my_type>().dtor();

    The returned type is dtor and may be invalid if there is no custom destructor set for the given meta type.
    All what a meta destructor has to offer is a way to invoke it on a given instance. Be aware that the result may not be what is expected.

  • Meta data. They are accessed by name:

    meta::data data = meta::resolve<my_type>().data(hash("member"));

    The returned type is data and may be invalid if there is no meta data object associated with the given identifier.
    A meta data object offers an API to query the underlying type (ie to know if it's a const or a static one), to get the meta type of the variable and to set or get the contained value.

  • Meta functions. They are accessed by name:

    meta::func func = meta::resolve<my_type>().func(hash("member"));

    The returned type is func and may be invalid if there is no meta function object associated with the given identifier.
    A meta function object offers an API to query the underlying type (ie to know if it's a const or a static function), to know the number of arguments, the meta return type and the meta types of the parameters. In addition, a meta function object can be used to invoke the underlying function and then get the return value in the form of meta any object.

  • Meta bases. They are accessed through the name of the base types:

    meta::base base = meta::resolve<derived_type>().base(hash("base"));

    The returned type is base and may be invalid if there is no meta base object associated with the given identifier.
    Meta bases aren't meant to be used directly, even though they are freely accessible. They expose only a few methods to use to know the meta type of the base class and to convert a raw pointer between types.

  • Meta conversion functions. They are accessed by type:

    meta::conv conv = meta::resolve<double>().conv<int>();

    The returned type is conv and may be invalid if there is no meta conversion function associated with the given type.
    The meta conversion functions are as thin as the meta bases and with a very similar interface. The sole difference is that they return a newly created instance wrapped in a meta any object when they convert between different types.

All the objects thus obtained as well as the meta types can be explicitly converted to a boolean value to check if they are valid:

meta::func func = meta::resolve<my_type>().func(hash("member"));

if(func) {
    // ...
}

Furthermore, all meta objects with the exception of meta destructors can be iterated through an overload that accepts a callback through which to return them. As an example:

meta::resolve<my_type>().data([](meta::data data) {
    // ...
});

A meta type can also be used to construct or destroy actual instances of the underlying type.
In particular, the construct member function accepts a variable number of arguments and searches for a match. It returns a any object that may or may not be initialized, depending on whether a suitable constructor has been found or not. On the other side, the destroy member function accepts instances of any as well as actual objects by reference and invokes the registered destructor if any.
Be aware that the result of a call to destroy may not be what is expected. The purpose is to give users the ability to free up resources that require special treatment and not to actually destroy instances.

Meta types and meta objects in general contain much more than what is said: a plethora of functions in addition to those listed whose purposes and uses go unfortunately beyond the scope of this document.
I invite anyone interested in the subject to look at the code, experiment and read the official documentation to get the best out of this powerful tool.

Policies: the more, the less

Policies are a kind of compile-time directives that can be used when recording reflection information.
Their purpose is to require slightly different behavior than the default in some specific cases. For example, when reading a given data member, its value is returned wrapped in a any object which, by default, makes a copy of it. For large objects or if the caller wants to access the original instance, this behavior isn't desirable. Policies are there to offer a solution to this and other problems.

There are a few alternatives available at the moment:

  • The as-is policy, associated with the type meta::as_is_t.
    This is the default policy. In general, it should never be used explicitly, since it's implicitly selected if no other policy is specified.
    In this case, the return values of the functions as well as the properties exposed as data members are always returned by copy in a dedicated wrapper and therefore associated with their original meta types.

  • The as-void policy, associated with the type meta::as_void_t.
    Its purpose is to discard the return value of a meta object, whatever it is, thus making it appear as if its type were void.
    If the use with functions is obvious, it must be said that it's also possible to use this policy with constructors and data members. In the first case, the constructor will be invoked but the returned wrapper will actually be empty. In the second case, instead, the property will not be accessible for reading.

    As an example of use:

    meta::reflect<my_type>(hash("reflected"))
        .func<&my_type::member_function, meta::as_void_t>(hash("member"));
  • The as-alias policy, associated with the type meta::as_alias_t
    It allows to build wrappers that act as aliases for the objects used to initialize them. Modifying the object contained in the wrapper for which the aliasing was requested will make it possible to directly modify the instance used to initialize the wrapper itself.
    This policy works with constructors (for example, when objects are taken from an external container rather than created on demand), data members and functions in general (as long as their return types are lvalue references).

    As an example of use:

    meta::reflect<my_type>(hash("reflected"))
        .data<&my_type::data_member, meta::as_alias_t>(hash("member"));

Some uses are rather trivial, but it's useful to note that there are some less obvious corner cases that can in turn be solved with the use of policies.

Named constants and enums

A special mention should be made for constant values and enums. It wouldn't be necessary, but it will help distracted readers.

As mentioned, the data member function can be used to reflect constants of any type among the other things.
This allows users to create meta types for enums that will work exactly like any other meta type built from a class. Similarly, arithmetic types can be enriched with constants of special meaning where required.
Personally, I find it very useful not to export what is the difference between enums and classes in C++ directly in the space of the reflected types.

All the values thus exported will appear to users as if they were constant data members of the reflected types.

Exporting constant values or elements from an enum is as simple as ever:

meta::reflect<my_enum>()
        .data<my_enum::a_value>(hash("a_value"))
        .data<my_enum::another_value>(hash("another_value"));

meta::reflect<int>().data<2048>(hash("max_int"));

It goes without saying that accessing them is trivial as well. It's a matter of doing the following, as with any other data member of a meta type:

my_enum value = meta::resolve<my_enum>().data(hash("a_value")).get({}).cast<my_enum>();
int max = meta::resolve<int>().data(hash("max_int")).get({}).cast<int>();

As a side note, remember that all this happens behind the scenes without any allocation because of the small object optimization performed by the meta any class.

Properties and meta objects

Sometimes (for example, when it comes to creating an editor) it might be useful to be able to attach properties to the meta objects created. Fortunately, this is possible for most of them.
To attach a property to a meta object, no matter what as long as it supports properties, it is sufficient to provide an object at the time of construction such that std::get<0> and std::get<1> are valid for it. In other terms, the properties are nothing more than key/value pairs users can put in an std::pair. As an example:

meta::reflect<my_type>(hash("reflected"), std::make_pair(hash("tooltip"), "message"));

The meta objects that support properties offer then a couple of member functions named prop to iterate them at once and to search a specific property by key:

// iterate all the properties of a meta type
meta::resolve<my_type>().prop([](meta::prop prop) {
    // ...
});

// search for a given property by name
meta::prop prop = meta::resolve<my_type>().prop(hash("tooltip"));

Meta properties are objects having a fairly poor interface, all in all. They only provide the key and the value member functions to be used to retrieve the key and the value contained in the form of meta any objects, respectively.

Unregister types

A type registered with the reflection system can also be unregistered. This means unregistering all its data members, member functions, conversion functions and so on. However, the base classes won't be unregistered, since they don't necessarily depend on it. Similarly, implicitly generated types (as an example, the meta types implicitly generated for function parameters when needed) won't be unregistered.

To unregister a type, users can use the unregister function from the global namespace:

meta::unregister<my_type>();

This function returns a boolean value that is true if the type is actually registered with the reflection system, false otherwise.
The type can be re-registered later with a completely different name and form.

Contributors

Requests for features, PR, suggestions ad feedback are highly appreciated.

If you find you can help me and want to contribute to the project with your experience or you do want to get part of the project for some other reasons, feel free to contact me directly (you can find the mail in the profile).
I can't promise that each and every contribution will be accepted, but I can assure that I'll do my best to take them all seriously.

If you decide to participate, please see the guidelines for contributing before to create issues or pull requests.
Take also a look at the contributors list to know who has participated so far.

License

Code and documentation Copyright (c) 2018-2019 Michele Caini.

Code released under the MIT license. Documentation released under CC BY 4.0.

Support

If you want to support this project, you can offer me an espresso.
If you find that it's not enough, feel free to help me the way you prefer.

Comments
  • emplace any

    emplace any

    emplace ctor and modifier for meta::any (similar to std::any) it eliminates extra moves in meta::type::construct

    WARNING: it incorporates and relies on my previous PR #5

    enhancement 
    opened by beppemarazzi 45
  • Return values by reference

    Return values by reference

    First of all: great work! The interface provided by this library is amazing! I am considering integrating it into my toy c++ game engine to provide reflection for serialization of the engine components.

    However, it seems that functions that return by-reference are not supported and will always return a copy. See the following snippet:

        struct MyValue {
            int value = 0;
            int& get() {
                return value;
            }
        };
    
        meta::reflect<MyValue>("MyValue")
                .func<&MyValue::get>("get");
    
        MyValue value;
        meta::any i = meta::resolve("MyValue")
                .func("get")
                .invoke(value);
        value.value = 1;
        std::cout << i.cast<int>() << std::endl;
    

    The output would be expected to be 1. This code, however, outputs 0. This both unintuitive and significantly limits the possibilities of the library:

    • you can't return non-copyable types by reference
    • you can't mutate any returned member
    enhancement 
    opened by Rogiel 15
  • Support to unregister a type

    Support to unregister a type

    Hi I'm using the library in the context of a plugin system which support hot reloading. Each plugin can register new types. In the context of a hot reload, the host unloads the previous version of the plugin and loads the new one which can register a new version of the type. I need to unregister the original type to be able to register the potentially new version of the type.

    Right now I wrote a small function which works for me

    template<typename Type>
    bool unregister() noexcept {
      auto type_to_unregister = meta::internal::type_info<Type>::resolve();
      auto* addr_t = &meta::internal::info_node<>::type;
      while( addr_t && *addr_t ) {
        auto t = *addr_t;
        if( t == type_to_unregister ) {
          *addr_t = t->next;
          return true;
        }
        addr_t = (meta::internal::type_node **) &t->next;
        t = t->next;
      }
      return false;
    }
    
    good first issue 
    opened by yabadabu 12
  • Documentation of properties could be improved

    Documentation of properties could be improved

    There are a couple of issues in the documentation of properties. First, the following example is provided:

    meta::reflect<my_type>("reflected", std::make_pair("tooltip", "message"));

    In this case, the first element of the pair, which is used to identify the property, will decay to a const char* and then stored in a meta::any object. Subsequently, properties are found applying operator == on meta::any instances, which is implemented by comparing the value of the pointers. This is a problem, because string literals potentially all have unique addresses, so the property cannot be portably and reliably be retrieved at later time.

    The retrieval example is also problematic:

    meta::prop prop = meta::resolve<my_type>().prop("tooltip");

    since this doesn't compile on at least one compiler (Visual Studio 2019). The problem is that in this case the literal string does not decay to a pointer and apparently the meta::any constructor is not able to accept a const char (&)[8].

    These two issues could be solved by using std::string as the type of the property key. However, the use case described in the documentation seems legit and useful, so if that's the intent, we should fix the code instead so that it works as described. There may be multiple ways to achieve this, for example, we could add the following non-template overload of the meta::type::prop method:

           const auto* curr = internal::find_if<&internal::type_node::prop>([key](auto* candidate) {
              auto ptr = candidate->key().try_cast<const char*>();
              return ptr && strcmp(*ptr, key) == 0;
           }, node);
    
           return curr ? curr->clazz() : meta::prop{};
        }```
    triage 
    opened by gamecentric 10
  • Serialization of meta::any

    Serialization of meta::any

    Hi @skypjack, Thank you for the library, it is great!

    I just couldn't figure out a way to serialize meta::any. May be somehow access the underlying data and extract it?

    Something like:

    // **** Init
    MyType obj;
    meta::reflect<MyType >(hash("MyType "))
           .data<&MyType::some_variable>(hash("some_variable"));
    
    auto data = meta::resolve<MyType>().data(hash("some_variable"));
    
    // **** Write
    std::cout << data(&obj).name() << ":" << data(&obj).toString();
    
    // **** Read
    std::string str; // or const char * or something else readable from file
    data.set(&obj, meta::any{str});
    

    Do you think it can be possible?

    question 
    opened by avkudr 9
  • fix ctor overload resolution

    fix ctor overload resolution

    Ciao Michele @skypjack,

    first of all my compliments for your great work!!! I've a lot to learn from your code....

    I found a minor problem with constructors: when more ctors are reflected all of them actually run, so the any returned is the one from the last ctor reflected. My fix stops to apply them when the first "valid" one has done.

    There was also issues when the default constructor is in the overload candidates because in this case nullptr was passed to can_cast<>() and can_convert()

    I wrote also a test to check the bug. There is a macro defined at the beginning of test file. you can comment out it to reproduce the issue.

    bug 
    opened by beppemarazzi 5
  • Is it possible to use library for [de]serialization?

    Is it possible to use library for [de]serialization?

    As I see, all meta mapping performed in integers. So, after meta is created, I could only test if member exist, not iterate through all mapped methods and save values (Imagine struct => json) Am I wrong or library is not created for this?

    Please tell what I'm missing

    question 
    opened by mapron 4
  • Detection of cast to meta::any type

    Detection of cast to meta::any type

    Hello, First, thank you for this high quality library, it is very pleasant to read your code !

    After playing a bit with the meta system, I found that I couldn't call meta-functions using meta::any as parameter (due to bad cast).

    This patch check in the 'try_cast' implementation if the target type is a meta::any and if so, returns it.

    This allows me to use your beautiful meta::any to create reflected containers of any type for my script language :)

    Edit: The patch is now in meta::internal::invoke because it'd cause a crash (dangling reference) in try_cast if the passed parameter type isn't matching meta::any.

    wontfix 
    opened by MatthieuMv 4
  • WIP: Add support for reference types on meta::any

    WIP: Add support for reference types on meta::any

    Hello @skypjack, this is a possible implementation for #2. This is very WIP and breaks a lot of things.

    • [x] Fix broken existing tests (some are now broken, haven't looked deep into why yet)
    • [ ] Implement casting from T& to const T&
    • [x] Implement conversion from T& and const T& to T
    • [ ] Implement more tests
    • [ ] How to handle functions that return a reference, should it default to a meta::any holding a reference?
    • [ ] Remove duplicated code
    enhancement 
    opened by Rogiel 4
  • Add support for invocation and node iteration on pointer types

    Add support for invocation and node iteration on pointer types

    This allows a meta::any or meta::handle to be invoked using the same syntax as a regular plain type. The conversion is performed automatically using type_node::ptr that converts a void* into a canonical form of T* for all types. handle now always stores the pointer in its canonical form.

    What a type for a pointer does:

    • inherits ctor, dtor, func, data and prop from T
    • has it's own separate conv definitions (see note 2) although still not implemented, it should allow conversions from T* into T or T* into T** (this could be tricky since it might create an infinite recurring in template specializations).

    What a handle for a pointer does:

    • Converts the void* into the canonical form and node is set to clazz (type T). Handles
    1. This DOES NOT support automatic conversion from T* to T for argument types as that should be implemented as a conv definition for the pointer types.
    2. T* and T conversions are not merged, since the rules for conversion of these types are different (a user-defined conversion operator that convert A -> B cannot convert A* -> B*).
    enhancement 
    opened by Rogiel 3
  • The default ctor of meta::factory should be public.

    The default ctor of meta::factory should be public.

    Fixes a compilation issue in C++20, where the factory{} initializer used by the meta::reflect helper function (and possibly elsewher) invokes the default costructor instead of using aggregate initialization as it does in C++17 and earlier.

    bug 
    opened by gamecentric 2
Owner
Michele Caini
I'm a freelancer and a senior software engineer. What else?
Michele Caini
C++ Reflection Parser / Runtime Skeleton

C++ Reflection Preface I worked on a complete reflection pipeline starting in the summer of 2015 for a game project / editor. My intent by creating th

Austin Brunkhorst 551 Nov 28, 2022
Customizable C++17 Runtime Reflection Library

Refureku Check the Wiki for more documentation and use examples! Refureku is a powerful C++17 RTTI free runtime reflection library based on Kodgen. It

Julien SOYSOUVANH 178 Nov 22, 2022
C++ reflection library with Lua binding, and JSON and XML serialisation.

Ponder Linux & OSX: - Windows: Currents status: 3.2-alpha. API is unstable as features added/changed. New: Version 3 V1 replaced Boost with C++11. V2

Bill Quith 568 Nov 21, 2022
Nameof operator for modern C++, simply obtain the name of a variable, type, function, macro, and enum

_ _ __ _____ | \ | | / _| / ____|_ _ | \| | __ _ _ __ ___ ___ ___ | |_ | | _| |

Daniil Goncharov 1.5k Dec 2, 2022
A modern compile-time reflection library for C++ with support for overloads, templates, attributes and proxies

refl-cpp v0.12.1 Documentation refl-cpp encodes type metadata in the type system to allow compile-time reflection via constexpr and template metaprogr

Veselin Karaganev 756 Dec 1, 2022
std::tuple like methods for user defined types without any macro or boilerplate code

Boost.PFR This is a C++14 library for very basic reflection that gives you access to structure elements by index and provides other std::tuple like me

Antony Polukhin 140 Nov 22, 2022
C++ Reflection Library

!New Release - 0.9.6! RTTR C++ Reflection Library RTTR stands for Run Time Type Reflection. It describes the ability of a computer program to introspe

rttr.org 2.5k Nov 22, 2022
A miniature library for struct-field reflection in C++

visit_struct A header-only library providing structure visitors for C++11 and C++14. Motivation In C++ there is no built-in way to iterate over the me

null 388 Nov 25, 2022
A miniature library for struct-field reflection in C++

visit_struct A header-only library providing structure visitors for C++11 and C++14. Motivation In C++ there is no built-in way to iterate over the me

null 389 Nov 27, 2022
A compiling time static reflection framework for C++

static_reflect This is a fully compiling time static reflection lightweight framework for C++. It provides a very rich compile-time reflection functio

null 14 Oct 18, 2022
C++ compile-time enum to string, iteration, in a single header file

Better Enums Reflective compile-time enum library with clean syntax, in a single header file, and without dependencies. In C++11, everything can be us

Anton Bachin 1.3k Nov 23, 2022
Non-intrusive CMake dependency management

cmodule Non-intrusive CMake dependency management. Normally CMake's find_package() looks for packages installed on host system (and compiled for host

scapix.com 14 Sep 29, 2022
Reactive - Simple, non intrusive reactive programming library for C++. (Events + Observable Properties + Reactive Properties)

Header only reactive C++ library. Thread-safe, memory-safe. Concsists from: Event (C# like Event, but thread-safe, does not block while event occurs,

null 63 Nov 23, 2022
match(it): A lightweight header-only pattern-matching library for C++17 with macro-free APIs.

match(it): A lightweight header-only pattern-matching library for C++17 with macro-free APIs. Features Easy to get started. Single header library. Mac

Bowen Fu 429 Nov 26, 2022
Gesture-Detecting-Macro-Keyboard - Glorified Bluetooth macro keyboard with machine learning (TensorFlow Lite for Microcontrollers) running on an ESP32.

Gesture detection tldr; Glorified Bluetooth macro keyboard with machine learning (TensorFlow Lite for Microcontrollers) running on an ESP32. Main feat

Jakob Krantz 69 Oct 26, 2022
Blend between two non-concentric non-circular cones for use in a Pose Space system

BlurRelax Why does maya not have a smooth or relax deformer? They've got brushes, sure, but no deformers. This one is pretty fast. I've got it working

Tyler Fox 2 Dec 27, 2021
C++ Reflection Parser / Runtime Skeleton

C++ Reflection Preface I worked on a complete reflection pipeline starting in the summer of 2015 for a game project / editor. My intent by creating th

Austin Brunkhorst 551 Nov 28, 2022
Customizable C++17 Runtime Reflection Library

Refureku Check the Wiki for more documentation and use examples! Refureku is a powerful C++17 RTTI free runtime reflection library based on Kodgen. It

Julien SOYSOUVANH 178 Nov 22, 2022