Add Options Should Be Able To Parse Arguments - Program Options Suggestion

add_options() should be able to parse arguments (also, implement %args%)

Back to Suggestions - program options library

It should be possible to parse arguments in the same way as regular command-line options, perhaps with an empty command string:

        desc.add_options()
        ("", parameter<int>("value", &magic), "<magicValue>")
        ;

Or maybe better, with a symbol, like:

        (cmdline_arg, parameter<int>("value", &magic), "<magicValue>")

For one thing, it would yield a consistent interface. As it is, the only way to access the arguments is through arguments(), e.g.:

        po::options_and_arguments opts = po::parse_command_line(ac, av, desc);
        ...
        copy(opts.arguments().begin(), opts.arguments().end(),
             ostream_iterator<string>(cout, "\n   "));

What if my argument is an int? Or a vector of ints? It would be nice if argument parsing had access to the powerful facilities provided for commandline options.

(Or, if it already does -- then add a corresponding example to the sample code).

Another advantage would be to consolidate error processing. You'd typically do:

    try {
        desc.add_options()
            ...
            ;

        ...
    } catch (exception& e) {
        // Process errors
    }

What to do if you find an error in the commandline arguments? I suppose you could always throw one of program_option's exceptions. But it would be more natural for the program_option lib to do this for you.

Another benefit is that it could simplify maintaining a correct usage message (assuming another new feature). You could have:

    options_description desc("Usage: %progname% %args% OPTIONS\n"
                             "        OPTIONS");

Here, %progname% gets replaced by the unadorned program name -- path stripped off, no .exe on Windows, and lowercase on Windows. Then, %args% gets replaced by the arguments string -- in this case, "<magicValue>". So, we'd have:

    Usage: someprogram <magicValue> OPTIONS
            OPTIONS:
        -o Option 1: some option
        -p Option 2: some other option

    - People/Chuck Messenger

I need to consider how to implement this. I see some appeal in idea that arguments are validated by the same code, but since in my practice arguments are almost always file name, I did not feel this to be very important.

    - People/Vladimir Prus

In my practice, args are sometimes numbers - either integer or floating point. In general, they could be any value which an option might be.

    - People/Chuck Messenger

Ok, I understand your motivation. Need to design an approach.

   - People/Vladimir Prus

If have ever used Perl's Getopt::Long you have seen how powerful it is. Being able to use vectors or even callback functions to collect command line args is really simple. Would that sort of thing be possible?

   - People/Caleb Epstein