Replace global, map-based key-value store with type safe structs

[deckstose]

Is your feature request related to a problem? Please describe.

Currently configuration is stored in a weakly typed key-value store, accessed by string key. It's global it's hard to reason about where a config is written and read from.

Describe the solution you'd like

Rewrite the map-based approach into structs, and pass them where needed. Either main or an app state should hold a single config instance that is ideally split into multiple sub-configs that can be passed by const& for read only access and wrapped with a mutex for write access.

[aristocratos]

Currently configuration is stored in a weakly typed key-value store

Not sure what you mean here. How would the data types of a member of a struct differ compared to the defined data types in the maps?

Rewrite the map-based approach into structs

You can't iterate a struct, and you don't have access to the names of the members of the struct in (C++ 23).
Which is needed unless reading/writing/managing the configuration is gonna have a giant if/else conditional for every possible configuration entry.

(As I mentioned, I'm experimenting with some libraries that implement "reflection like" properties for enums that possibly can be used to improve the current "map-based approach". Using vectors instead of maps.)

passed by const& for read only access and wrapped with a mutex for write access

It's not that simple, (not currently anyways), since you also need syncing between the "collection" phase and the "drawing" phase. If the configuration differs between the phases you would in the best case get a missing value and in the worst case a crash.
Since we only collect what's specified in the configuration.

This will get "better" when I'm done with threading changes (some config changes are included in this out of necessity), since "drawing" will be moved to the main thread and instead of using the "global" configuration only have a copy of the same configuration as the "collection" thread used.

Any changes to the configuration during "collect" will be evaluated, and if needed, collection will be cancelled and a new collection cycle will be triggered.

[deckstose]

Not sure what you mean here. How would the data types of a member of a struct differ compared to the defined data types in the maps?

It's access by key name vs. compiler checked access of a struct member.

auto value = Config::get("key");
// vs.
auto value = &config.key;

And yet, it could be more than a bool/int/string type then, an enum class for example.

This is the most unlikely thing to implement due to the lack of reflection you mentioned.

[deckstose]

What reflection libraries have you looked at?

[aristocratos]

https://github.com/Neargye/magic_enum

[deckstose]

I will take a look at it!

I have played around with https://github.com/getml/reflect-cpp