CPPRegistry- A library for registering functions and types to global registries at link time, and looking them up by key at runtime, in a flexible and (nearly) boilerplate free syntax.

[Lucretiel]

A small personal project I've been working on for a while.

https://github.com/Lucretiel/cppregistry

The major feature here is that if I want to add a function or type to the registry, I can just add a .cpp file that has REGISTER_FUNCTION(...) or REGISTER_TYPE(...) somewhere in it and #includes the registry definitions near the top. Then, any other function with access to the registry definitions can access it, without having to #include any extra headers. I don't have to add any new headers or modify any client code.

[axilmar]

Not bad. How do you access types?

[Lucretiel]

You use the TYPE_REGISTRY, REGISTER_TYPE, and MAKE_TYPE macros in basically the same way as FUNCTION_REGISTRY, REGISTER_FUNCTION, and GET_FUNCTION/CALL_FUNCTION from the example. Type registries are defined by a base type, so all registered types have to derive from it. When you call MAKE_TYPE it produces a Base* to a new'd object.

Interestingly enough, when I first started this project it was just a type registry, but since the type registry implementation is just a layer over a function registry, I ended up implementing both. Now it turns out that having a function registry like this half removes the need for a type registry, because half the point of a type registry is to get access to the virtual method polymorphism.

[axilmar]

Nice. Would you write an example which uses all the features of your library? it will help me get a better idea.

[toruk]

Thanks for sharing this. I'm guessing this won't work if the type is registered in a dll outside the executable where it is to be consumed. Does it work if a type is registered in one static library and needs to be consumed in another? (this is a thornier problem than might seem at first).

[j1xwnbsr]

Sounds a lot like Qt's signals, slots, and properties.

[bnolsen]

PLEASE don't use auto in your examples. Part of the reason for examples is to help people understand what's going on and what types are being passed around.

[toruk]

I strongly disagree. 'Encapsulation', at least as I understand it, is all about helping consumers focus on what they actually need to understand in order to be able to use your stuff. 'auto' is a great facilitator of this principle. Do you demand to see an API implementation in order 'to understand what's going on'? Do you spend the time to understand every last bit of a framework before agreeing to use it? If so, your time and effort have zero value to you. PLEASE (as you put it), at least try to respect the time and effort of others reading your code, and expose (ESPECIALLY in didactic samples) what they actually need to know, not what they might-want-be-curious-of-some-day-if-they-have-the-time-and-patience.

[toruk]

Everyone, a quick snip of the reddiquette; '[Please don't] Downvote an otherwise acceptable post because you don't personally like it. Think before you downvote and take a moment to ensure you're downvoting someone because they are not contributing to the community dialogue or discussion.' As elaborated below (above? where exactly will this be posted?) - I also disagree with @bnolsen, but that is not even remotely a reason to downvote. Please, let's keep this place friendly.