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

From: Antonio Piccolboni (piccolbo_at_[hidden])
Date: 2006-01-26 12:20:46

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 <smb_at_[hidden]> 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 <http://
> www.cs.aau.dk/~olau/commandoptions/>
>
> Regards,
> -Steve
> --------
> Steve Byan <smb_at_[hidden]>
> Software Architect
> Egenera, Inc.
> 165 Forest Street
> Marlboro, MA 01752
> [phone]
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>