Re: [boost] Command line parser

From: Daniel Heck (dheck_at_[hidden])
Date: 2000-05-04 19:03:20

On Thu, May 04, 2000 at 11:31:00PM +0200, Jens Maurer wrote:

> In general, I think a boost command-line parser would be
> helpful.  However, command-line options are usually a once-only
> thing, so using POSIX getopt (with its global state) may not
> be that inconvenient.

Sure; it may not be inconvenient, but vanilla POSIX getopt doesn't
even support long options.

> Here is what I had in mind before Daniel's post came up:
>  - Iterator for iterating through the arguments

I played with several different designs before settling with my "bool
getopt(option&)" approach.  My reasons were: (a) an argument parser is
just that and not a container, so a "get" interface a la iostreams seemed 
more natural to me and (b) writing a option_iterator class should be 
trivial.

>  - Possibly transparent redirection support for operating
> systems with limited command-line length. (i.e. read your
> command-line options from a file) (not a high priority)

This is already supported since the "feed" method takes a range.  You
could use something like

    ifstream ifs(...);
    ap.feed(istream_iterator<string>(ifs), istream_iterator<string>());

>  - Error reporting with exceptions

See below.

>  - Possibly a wrapper around all this for mapping
> options to lambda-expressions. (cf. signal/slot library)
> Usage vision for this:
> opt.define("-o", "--output", bind(&set_output_filename, free1))

This looks nice, but unfortunately I have no experience with boost's
lambda library (I think this is what you were referring to).  It would
be nice to include this as an optional feature -- I will look into
this asap.

> Here are a few comments regarding your argp.hh. Please don't
> be disappointed, but do pursue this matter.

No problem; That's why I posted the source in the first place...

> > #ifndef __ARGP_HH
> > #define __ARGP_HH
> 
> Identifiers starting with two underscores are reserved
> for the implementation (of C++), so don't use them as
> include guards (popular misfeature).

Hm; Sounds reasonable.  It's a convention I adopted from some other
project, but it seems to be not that good a convention after
all... will be fixed.

> I'm unsure whether problems with the command line should be
> reported by a return value or by an exception.

So am I.  Exceptions would make the code a bit clearer, but there seems
to be a lot of disagreement in the C++ community whether ot not
exceptions are a good thing after all.  Any opinions?

> Btw, I don't think your getopt handles command-lines such as
> "-hvo file.txt", i.e. merging of bool one-char options.
> This would be useful.

It *does* handle these kinds of options, although the code is a bit
hidden (the last else clause in getshortopt()).

> Jens Maurer

Thanks for your feedback!

Daniel