C++ registration functions called before main() - c++

Question

My program looks something like this:
map<string, function<void(const MyType&)>> callables;
int main(int argc, char *argv[]) {
string name = GetFromSomewhere();
auto iter = callables.find(name);
if (iter != callables.end()) {
MyType my_thing = GetSomeValue();
iter->second(my_thing);
}
}
In other words, I have a table of functions, and main is going to do something that produces a lookup key into that table, do the lookup, and if successful, call the function.
Now I could initialise the table in the translation unit where I define the map, but that means each new function that wants to be in that map has to modify the map's TU. That gets cumbersome.
Better to have a registration function:
void RegisterCallable(const string&, function<void(MyType)>);
and then any developer who wants to put something in the table just calls RegisterCallable():
# In foo.cc:
void NiftyCallable(const MyType& thing) { ... }
RegisterCallable("nifty", NiftyCallable);
Past experience with string vs char[] warns me that I'm asking for pain, but I've not been able to (re)find the specific C++ rule that tells me when those RegisterCallable() calls that we'll scatter about the code base will be called (in particular, if they're guaranteed to be called before main executes or if maybe the TU can load on demand later -- and so whether my memory of pain is correct or not for C++14).
Am I misremembering that this will cause pain?
Or is there a better way to do this other than asking for some TU to know about (currently 100 or so) functions that need registering?

Answer 1

Don't put the table in global scope put it in function scope (still has to be static to make sure that it lives for the length of the application). So you can force the initialization order. Then you solve the problem of initialization order across compilation units.
static std::map<std::string, std::function<void(const MyType&)& getCallables() {
static std::map<std::string, std::function<void(const MyType&)>> callables;
// ^^^^^^ Static storage duration object.
// lives as long as the application.
return callables;
}
int main(int argc, char *argv[]) {
std::string name = GetFromSomewhere();
auto iter = getCallables().find(name);
if (iter != getCallables().end()) {
MyType my_thing = GetSomeValue();
iter->second(my_thing);
}
}
When calling from any scope to register a new function it calls getCallables() which forces initialization. So you avoid the initialization order issue.
void RegisterCallable(const std::string& name, std::function<void(MyType)> f)
{
getCallables()[name] = f;
}
Unfortunately, you can not have freestanding function calls directly in a compilation unit in C++ (unlike a lot of interpreted languages).
// So this will not work
RegisterCallable("nifty", NiftyCallable);
So the way to do this is to declare objects at global scope whose constructor registers the object.
struct DoRegisterCallable {
DoRegisterCallable(std::string const& name, std::function<void(MyType)> f) {
RegisterCallable(name, f);
}
};
Now in your compilation unit the person adding the function will do:
// In foo.cc:
void NiftyCallable(const MyType& thing) { ... }
DoRegisterCallable niftyCallableRegister("nifty", NiftyCallable);
In the comments above IgorTandetnik suggests that niftyCallableRegister may not be included in the executable as the compiler may optimize the variable out. This statement is not interlay true but has merit to think about.
If the file foo.cc is compiled into a static library. Then this static library is linked against the executable, then there is a potential that it may not be included. But in normal situations most builds are done with dynamic libraries not static libraries (as static libraries have so many other issues that people have mostly stopped using them) so this is minor concern in normal operations (but is something to think about).
Additionally, it is implementation defined if file scope, static storage duration variables are initialized before main or deferred. This is easily testable via some unit tests as it is a property of the compiler and not undefined behavior (if you are compiler is doing this then you need to check the documentation to see if the behavior can be changed).
My speculation on this language in the standard is to allow delayed loading of shared libraries till after the application starts, but still guarantee that their behavior conforms to the standard. The way this is written, allows an application to dynamically load a shared library and initialize it (make sure file scope static storage duration objects are initialized) after the application main() has started. A corner case and easily tested via unit test.
I may decide that it is nice to wrap this in a class for easy usage:
#include <string>
#include <functional>
#include <map>
#include <iostream>
class MyType
{
};
using Callable = std::function<void(MyType)>;
using CallableMap = std::map<std::string, Callable>;
class Callables
{
static CallableMap& getCallables()
{
static CallableMap callables;
return callables;
}
public:
static void registerFunc(std::string name, std::function<void(MyType)>&& f)
{
getCallables()[std::move(name)] = std::move(f);
}
static void call(std::string const& name, std::function<MyType()>&& getter)
{
auto find = getCallables().find(name);
if (find != getCallables().end()) {
find->second(getter());
}
}
static void call(std::string const& name, MyType const& value)
{
call(name, [&value](){return value;});
}
};
struct RegisterCallables
{
RegisterCallables(std::string value, Callable&& f)
{
Callables::registerFunc(std::move(value), std::move(f));
}
};
void echo(MyType v)
{
std::cout << "Echo\n";
}
RegisterCallables echoRegister("echo", echo);
int main()
{
MyType d;
Callables::call("echo", d);
}