Re: [boost] Command line option handling - Interest?

From: Sven M. Hallberg (pesco_at_[hidden])
Date: 2001-05-11 15:39:37

On Fri, May 11, 2001 at 12:21:44PM -0700, Gary Powell wrote:
> The question was more of should we be able to handle things like
> 
> -IntegerRangeValues 0 99999
> where I would need the parser to grab the next two integer arguments.
> I could live with
> -IntegerRangeValues (0,9999)
> As it does a space denote the end of an argument or does the flag "-"
> constrain it.

I'm definately voting for the latter, because letting the handler parse
options is too blurry. A major part of the design relies on the fact that an
option has exactly one string argument (which might be empty in cases).
Loosening that rule would also intermangle parsing with processing which I
have a feeling would be a Bad Thing.

> Also I've seen arguments that used a "+" (Not that I'm advocating it but, it
> might make it more general purpose if the flag character was user definable.
> On the otherside my KISS is kicking me to say no, you get "-" and that's it.

Agreed. The only point I see is that under MS-DOS "/" is (kind of) common. I
am absolutely _not_ familiar with DOS/Windows programs, but as far as I
remember most serious apps use "-" while "--" is never seen, right? That way I
don't even see support for "/" as important, comments?

BTW, what is KISS anyway?

> The issue was whether we should provide an interface which allows the
> programmer to query the help list, as in
> 
>  int mfNumberOfFlags() const;
>  string mfGetHelpDescription(int) const;
> 
> which would let the user do the help output.

Right, I've already thought about this. The best way would probably be an
accessor to a container of help strings.

> Also is "help" a fixed keyword? Or is it necessary to register it?
> 
>  option_processor op;
> 
>  op.reg(bind(op, &option_processor::info), "this help", '?', "help");

A help option must be registered seperately, because no-one would know how to
implement the handler for it if it were built-in.

> Also in the option struct, it would probably be a good idea to return a
> pointer to the help message, so that if the argument is in error, the
> programmer could use the help message to help the user correct it.

Good point. Currently the exceptions thrown contain a copy of the option
struct that caused the error. Maybe they should additionally contain a
reference to the option's entire optentry (the structure used to store all
info about the option inside the processor). That way the user could get any
info they originally put into the processor back upon an error.

Regards,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]