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.
> > to deal with shared libraries are a pain on many systems (such as
> > 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
> > only. I don't even use the regex library because I can't get it to
> > 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
> > 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
> > are probably the way to go.
> The error message indeed carry more information than "it failed". I can
> 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
> > two could interface through a similar facade, but I don't think they
> > to
> > be intimately combined. As another poster pointed out, the command line
> > option and its associated config file or environmental parameter are
> > 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
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
> 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");
> ("generate-verbose-prints", "", "")
> po::options_description ddesc("Dolphin-specific options");
> ("case-insensitive", "", "")
> 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>)
> two different groups of options. I'm thinking something like that can be
This is fine until Dolphin and Whale both use the same option (e.g., -f
filename) in which case they cannot have separate values.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk