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
> - 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
> - Error reporting with exceptions
> - 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
> 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk