Re: [Boost-users] Comments on the usability of program_options

If I can add my 2c, before switching to program_options I was using TCLAP (tclap.sourceforge.net/). The main reason for swtiching was to avoid relying on one-man-show libraries, so it's not a technical one and I am not in a position to do thorough comparison. One thing I noticed though, is that with program_options I have to specify the type of an argument twice, first with po::value<type>, then with vm["optname"].as<type>(). Not only it is verbose, but it is checked only runtime. In TCLAP I would declare ValueArg<string> myopt (...) and then do a myopt.getValue() which would have the correct type and type checking is done at compile time. While there might be advantages in delaying type checks to run time that I ignore, my preference goes to a more statically typed solution. I also concur with Steve's observations. As to the handling of non-option args, TCLAP uses the following solution (http://tclap.sourceforge.net/manual.html#UNLABELED_VALUE_ARG , which is pretty much like specifying an option but without one arg, the switch label). I am also cc-ing to TCLAP's author to hear his comments. Thanks Antonio On 1/26/06, Steve Byan wrote:

First let me mention that I greatly appreciate all the work done by the contributors to Boost. The library has been extremely helpful to me both as a class and template library and as a learning tool for template meta-programming.

In the spirit of constructive criticism, I'd like to offer a few usability observations arising from my first attempt to use program_options. I appreciate the flexibility, extensive feature set, and the extensibility of the library. I particularly like the unification of command-line options with configuration files; this is a very handy feature. However, I think the unification of program arguments with program options is less successful. I think the library would be better if arguments were a separate concept.

Unifying program arguments with program options has these consequences:

1) The error message produced by an excessive number of arguments is opaque to most users. The error message produced is "Error: unknown option foo", which I think would be better phrased as something along the lines of "Error: too many arguments". Since program_options doesn't distinguish options from arguments, it can't easily produce a better diagnostic message.

2) The usage description by default describes command-line arguments as options. E.g. the usage message is something like this:

Supported options: -h [ --help ] produce this help message --device-file arg scsi pass-thru device special file

To hide the "argument options" in the help message, program_options supports multiple options_descriptions, but puts the responsibility for hiding the "argument options" on the user of the library, and, unlike normal options, does not automatically provide a description of the argument in the help message. If arguments were instead treated as first-class concept instead of a mutant form of an option, the library could automatically handle these issues.

3) Somewhat related to issue #2, program_options doesn't generate a concise usage description help-message from the grammar. For example, it would be nice if options_desciption could provide a string like this:

Usage: scsi_tool [-h | --help] [-v | --verbose] <device-file> [<output-file>]

Additionally, it would be nice if program_options handled more of the validation and error reporting. Currently the user is responsible for checking for required arguments and generating an error if they are not supplied, and for coding the generation of a usage message when the options and arguments don't conform to the specified grammar.

An example of an alternative design which addresses these concerns (but which lacks many of the more sophisticated features of program_options) is Ole Laursen's commandoptions

Regards, -Steve -------- Steve Byan Software Architect Egenera, Inc. 165 Forest Street Marlboro, MA 01752 (508) 858-3125

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users