views:

764

answers:

8

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?)

A: 

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.

Sudhir Jonathan
Uuh, Apache Ant? The build tool? What does it have to do with reading command line options in C++?
Sudhir Jonathan
A: 

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.

Craig W. Wright
+1  A: 

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)

Danalog
+2  A: 

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.

rlbond
+1 for boost::program_options, but only just! I would be careful with using program options as a singleton. We've been bitten by doing this in that we now need to add different sets of options for different files. We first need to go back and remove the singleton so that we can store the different sets of options for each individual files.
Richard Corden
Good point, Richard. I use boost::program_options for a game, and obviously 1 set of options is enough per process, but for different purposes this would be a bad idea.
rlbond
+1  A: 

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.)

siddhant3s
+5  A: 

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.

albertb
Me likes! Looks very easy to use.
milan1612
+1  A: 

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.

Cannonade
+3  A: 

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

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