> > 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
