[boost] command line parser review

From: Tanton Gibbs (thgibbs_at_[hidden])
Date: 2003-05-27 22:03:02

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.

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.

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 :)
Of course, that is assuming that by "custom parser" you mean write the
custom parsing function that can be used by your library.

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

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.

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.

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.

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.

Tanton