Re: [boost] Re: command line parser review

From: Tanton Gibbs (thgibbs_at_[hidden])
Date: 2003-05-28 00:00:13

> > 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?

Yes that is an option, but not one I would like to use.  I personally prefer
the optional header-only, but understand either way.

> > 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.

I think that exceptions are definitely superior to error codes because of
the amount of information they convey.  Therefore,
I really like the exception option.

> > 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.

Me neither.  It could be that your library is accepted into boost on the
condition that when
a real config file library is accepted, you replace yours with it.

> > 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.

The -- option would be fine for my purposes.  Just stupidity on my part.

>
> 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.

This is fine until Dolphin and Whale both use the same option (e.g., -f
filename) in which case they cannot have separate values.

Tanton