Best Practices for Storing C++ Program Parameters

Don't use volatile const, it sounds like nonsense! Instead, use a class/struct and initialize all variables in the constructor. You can still use const.

Params.h:

struct ConfigParams {

    const int param1;
    const int param2;
    // ...

    // Define a constructor that will load stuff from a configuration file.
    // Tune this to meet your needs, such as parsing the data from a startup command line.
    ConfigParams(const std::string & configFileName);
};

// The global that you will use to fetch the configurations during runtime.
extern const ConfigParams configParams;

Params.cpp:

// Declare the global configuration data table:
const ConfigParams configParams("app_configs.ini");

// The constructor:
ConfigParams::ConfigParams(const std::string & configFileName)
    : param1(getConfigFromFile(configFileName, "param1"))
    , param2(getConfigFromFile(configFileName, "param2"))
    // and so on ...
{
}

// And this function would open the file and lookup the requested parameter key, returning its value:
int getConfigFromFile(const std::string & configFileName, const std::string & key)
{
    // TODO...
}

I think you need to ask yourself some questions first, and clarify some points, then you can better decide how to solve your problem.

First: who shall have control over the servers?

• Is it a single administrator who is going to control hundreds of servers? Then you need to centralize the configuration as much as possible.

• Or is each server potentially under control of an individual admin, who does not want his settings overruled or controlled by a centralized configuration? Then you should focus on decentralized configuration. If each admin has a handful of servers to manage at maximum, this is still manageable manually.

Second: do you really need tons of configuration options, or can you keep the number down to a few? Instead of making all and everything configurable "just in case", better self-restrict yourself to the options you know your system really needs. This can be done, for example, by

• making your software a little bit smarter (for example, what can the program determine automatically by asking the environment)?

• following "convention over configuration" rigidly - for example, by establishing certain naming conventions, or by deriving some options as a default from other options

Third: do you really want a hierarchical level of configuration hardcoded into the software? Imagine you don't know beforehand how many servers there will be, if a tree-like hierarchy really is the best structure for them, or how many levels the tree needs to have. The most simple solution I can think of is by providing no centralized configuration at all, only one config file per server, and let the reponsible server administrators decide themselves how they solve the problem of managing the configurations of multiple servers.

For example, the admins might write generator scripts which distribute a central config file to a group of different servers and making some minor modifications to each copy. That way, you do not have to make any assumptions about the "server distribution topology" beforehand, the topology can be adjusted at any time to the real world requirements. The drawback is, you need administrators with some knowledge of how to write scripts in a language like Perl, Python, Bash or Powershell.