[boost] Re: Re: command line parser review

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-28 02:33:17

Tanton Gibbs wrote:

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

OK. I'll note your opinion.

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

Good.

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

Basically, given the little amount of time put in config_file, I'll be happy
to replace it with anything better.

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

:-)

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

Good case. I feel that multi-pass parsing will fail in this case, too. The
first parser will extract '-f' and the second one will never see it.

- Volodya