[boost] Re: command line parser review

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-28 00:24:18

Hi Tanton,

Tanton Gibbs wrote:

> Since there have been a few emails bouncing around, I'd like to chime in
> with my opinions on a few matters.
> 
> 1. Static vs Shared
> I would much prefer header files only instead of a shared library.  Having
> to deal with shared libraries are a pain on many systems (such as cygwin).
> Using a header file is clean and easy -- therefore much preferred by me.
> One of the biggest benefits to boost is that it is primarily header files
> only.  I don't even use the regex library because I can't get it to build
> on Tru64.

I realize that header file is easy. But that approach will bit sooner or
later. It probably would be possible to supply alternative header-only
option, but that would be a lot of work. Need to find more opinions here.

BTW, if you have problems with shared libraries on cygwin, it's still
possible to add all source files from program_options to your project and
compile them?

> 2. redundant storage
> I don't have a problem with you storing arguments in both
> options_and_arguments as well as whatever variable I pass in.  I realize
> that one will be typed and the other string.  If it is stored in a third
> place as well, well that could be annoying, but I won't balk too
> much...probably not good design though.

The true situation is: options are stored only in two places. Arguments are
indeed stored in third place to make 'cmdline' class more usable by itself.
I'm actually considering if 'cmdline' class should be moved out from public
interface, and if it happens, there will be no third place for anything.

> 3. custom parser
> I realize that no one will find shrink-wrapped solutions to everything.
> However, for a command line parser, I would hope that most common command
> line styles would be shrink-wrapped.  For example
> /o --option -o -o value -o=value --option value --option=value -o val1
> val2 val3 --option val1 val2 val3 -o val1 -o val2 -o val3
> 
> should all work right out of the box.  Other than that, make 'em write a
> custom parser :)

That was my opinion, too. BTW, all the styles above are supported.

> Of course, that is assuming that by "custom parser" you mean write the
> custom parsing function that can be used by your library.

Yes, sure.

> 4. I do like the idea of handler functions that could be called when the
> parameter was passed in.

Technically, there's 'notify' function which can be used for that purpose.
In discussion with Pavol Droba we've decided that semantic processing
('notify' is part of it) must be a bit more clearly separated from
syntactic processing, but basically, that function will be retained.

> 5. As for exceptions vs return values.  I don't really have a preference.
> Often, you can get more information from exceptions than you can from
> return
> values.  If that is the case then I fully support exceptions.  If you're
> not going to get back anything other than "it failed", then return values
> are probably the way to go.

The error message indeed carry more information than "it failed". I can also
imagine cases where the kind of error matters.

> 6. wchar_t support.
> I definitely see the need for this.  I like the idea of a template
> parameter.  However, I wonder, like another poster, if you will ever need
> both char and wchar_t support, in which case you may not need a template
> parameter.  The only question I have is if you will ever have the command
> line in char and the config file in wchar_t...then you may need them both.

Oh... that's a good question! I'm starting to feel that unicode can't be
addressed in program_options alone. Some general solution is needed.

> 7. config file.
> This is where I have the biggest problem.  I think a config file library
> should be in boost, but separate from a command line library.  Perhaps the
> two could interface through a similar facade, but I don't think they need
> to
> be intimately combined.  As another poster pointed out, the command line
> option and its associated config file or environmental parameter are often
> very different in name.

I have some problems here, too --- the config_file class is too small be
become a separate library --- and was never intended to. I've no problem
with using separate config_file, provided it can be converted into
'options_and_arguments' class, which is the common interface for command
line and config file. However, I can't comment as what the separate config
file library can do. 

> 8. I agree that multi-pass command line parsing is important.  We eat
> certain arguments and pass others to separate programs all of the time.

Could you clarify why the approach with separating option to your program
and options to another program by "--" is not appropriate? I'd be willing 
to put some though into this, but would like to understand the problem
first.

BTW, I have a use case (with program_options) where a single program accepts
two groups of command line options, which must be passed to different
applications. The problem was solved by declaring two groups of options as
'options_description' instances. After parsing, the options were stored in
two maps and passed to subprograms. Here's a simplified example:

       po::options_description desc("Allowed options");
       ....

       po::options_description wdesc("Whale-specific options");
       wdesc.add_options()
            ("generate-verbose-prints", "", "")
            ;

       po::options_description ddesc("Dolphin-specific options");
       ddesc.add_options()
            ("case-insensitive", "", "")
            ;

       desc.add(wdesc);
       desc.add(ddesc);

       po::options_and_arguments opts = parse_command_line(ac, av, desc);
     
       po::store(opts, whale_opts, wdesc);
       po::store(opts, dolphin_opts, ddesc);

Now, 'whale_opts' and 'dolphin_opts' (of type std::map<string, string>) keep
two different groups of options. I'm thinking something like that can be
used.

Thanks,
Volodya