How do you handle command line options and config files?

Question

What packages do you use to handle command line options, settings and config files?

I'm looking for something that reads user-defined options from the command line and/or from config files.

The options (settings) should be dividable into different groups, so that I can pass different (subsets of) options to different objects in my code.

I know of boost::program_options, but I can't quite get used to the API. Are there light-weight alternatives?

(BTW, do you ever use a global options object in your code that can be read from anywhere? Or would you consider that evil?)

Answer 1

At Google, we use gflags. It doesn't do configuration files, but for flags, it's a lot less painful than using getopt.

#include <gflags/gflags.h>
DEFINE_string(server, "foo", "What server to connect to");
int main(int argc, char* argv[]) {
    google::ParseCommandLineFlags(&argc, &argv, true);
    if (!server.empty()) {
        Connect(server);
    }
}

You put the DEFINE_foo at the top of the file that needs to know the value of the flag. If other files also need to know the value, you use DECLARE_foo in them. There's also pretty good support for testing, so unit tests can set different flags independently.

Answer 2

For command lines and C++, I've been a fan of TCLAP: Templatized Command Line Argument Parser.

http://sourceforge.net/projects/tclap/

Answer 3

Well, you're not going to like my answer. I use boost::program_options. The interface takes some getting used to, but once you have it down, it's amazing. Just make sure to do boatloads of unit testing, because if you get the syntax wrong you will get runtime errors.

And, yes, I store them in a singleton object (read-only). I don't think it's evil in that case. It's one of the few cases I can think of where a singleton is acceptable.

Answer 4

I've been using TCLAP for a year or two now, but randomly I stumbled across ezOptionParser. ezOptionParser doesn't suffer from "it shouldn't have to be this complex"-syndrome the same way that other option parsers do.

I'm pretty impressed so far and I'll likely be using it going forward, specifically because it supports config files. TCLAP is a more sophisticated library, but the simplicity and extra features from ezOptionParser is very compelling.

Other perks from its website include (as of 0.2.0):

• Pretty printing of parsed inputs for debugging.
• Auto usage message creation in three layouts (aligned, interleaved or staggered).
• Single header file implementation.
• Dependent only on STL.
• Arbitrary short and long option names (dash '-' or plus '+' prefixes not required).
• Arbitrary argument list delimiters.
• Multiple flag instances allowed.
• Validation of required options, number of expected arguments per flag, datatype ranges, user defined ranges, membership in lists and case for string lists.
• Validation criteria definable by strings or constants.
• Multiple file import with comments.
• Exports to file, either set options or all options including defaults when available.
• Option parse index for order dependent contexts.

Answer 5

If Boost is overkill for you, GNU Gengetopt is probably, too, but IMHO, it's a fun tool to mess around with.

And, I try to stay away from global options objects, I prefer to have each class read its own config. Besides the whole "Globals are evil" philosophy, it tends to end up becoming an ever-growing mess to have all of your configuration in one place, and also it's harder to tell what configuration variables are being used where. If you keep the configuration closer to where it's being used, it's more obvious what each one is for, and easier to keep clean.

(As to what I use, personally, for everything recently it's been a proprietary command line parsing library that somebody else at my company wrote, but that doesn't help you much, unfortunately)

Answer 6

GNU getopt is pretty nice. If you want a C++ feel, consider getoptpp which is a wrapper around the native getopt. As far as configuration file is concerned, you should try to make it as stupid as possible so that parsing is easy. If you are bit considerate, you might want to use yaac&lex but that would be really a big bucks for small apps.

I also would like to suggest that you should support both config files and command line options in your application. Config files are better for those options which are to be changed less frequently. Command-line options are good when you want to pass the immediate changing arguments (typically when you are creating a app, which would be called by some other program.)

Answer 7

If you are working with Visual Studio 2005 on x86 and x64 Windows there is some good Command Line Parsing utilities in the SimpleLibPlus library. I have used it and found it very useful.

Answer 8

Not sure about command line argument parsing. I have not needed very rich capabilities in that area and have generally rolled my own to save adding more dependencies to my software. Depending upon what your needs are you may or may not want to try this route. The C++ programs I have written are generally not invoked from the command line.

On the other hand, for a config file you really can't beat an XML based format. It's readable, extensible, structured, etc... :) Plus there are lots of XML parsers out there. Despite the fact it is a C library, I tend to use libxml2 from xmlsoft.org.

Answer 9

Try Apache Ant. Its primary usage is Java projects, but there isn't anything Java about it, and its usable for almost anything.

Usage is fairly simple and you've got a lot of community support too. It's really good at doing things the way you're asking.

As for global options in code, I think they're quite necessary and useful. Don't misuse them, though.