From: Patrick Guio (patrick.guio_at_[hidden])
Date: 2002-01-15 08:44:20
On Tue, 15 Jan 2002, Vladimir Prus wrote:
> Patrick Guio wrote:
> Okay. Going back to parsing '-I' options, I think that implementing
> 'ParseOptions' is something that doesn't looks good to me. It is possible to
> allow more flexible solution, where each types decides for itself how it
> deals with each arguments. For example, validator for vector just appends new
> element each time it's called. Isn't it more general?
That could easily be done actually. Separating with a predefined separator
sign (':' as for PATH variable)
> > > 2) parsing arbitrary class and thowing if the value given for it is
> > > incorrect
> > I guess anyone could extend its own parser by inheriting this one and
> > write its own Convert(string, value) routine where value is a class object.
> > The Parser::ParseOption functions are template member function that
> > parse the command line arguments for a special option and feeds the rest
> > of the string (or the next arg) to the Convert function
> Well, actually Convert looks a bit like lexical_cast, so you might use it.
> Secondly, I don't think that inheritance is good in this case. After all, all
> you do is tell how to handle some time.
I haven't looked at lexical_cast but it sounds good. How can you easily
provide extension to Convert or lexical_cast ?
> > > Okay. Then the next question is: why you requires that options are first
> > > registered and then parsed by calling a function for each options. It
> > > means that dealing with any single option is performed in two different
> > > places. Is it convenient enough to write down multiple 'ParseOption'
> > > calls?
> > That's right but I wanted to have help / version / template-creation for
> > the options. Therefore I choose to first register all the options and then
> > parse them.
> Why can't you have special processing from help/version/template-creation and
> then a single method that will parse the remaining options?
That could be a possibility but so long I have used individual fields in
classes with long and descriptive names so that each field is parsed
separately. A single method to parse the remaining options is of interest
when the values are to be parsed in a unique vector (a class any would
be nice but it does not contain so long input method) but then you miss
clarity of the code. Do you see what I mean or am I wrong?
> > > > > ii) Is there low-level access to parsed options, such as in form of
> > > > > vector< pair<string,/*option*/ string /*value*/> >
> > > >
> > > > No but I guess it should not be a heavy task to provide.
> > >
> > > Yes, and I think it's very needed. I think that separation between the
> > > part which actually parses the command line and the part which performs
> > > assignments to program variables is important to make a library usable.
> > >
> > > I have also to remark that support for multiple option styles was a
> > > popular desire in previous discussions on the subject.
> > This is supported in the form of aliases registration.
> Which are not mentioned in any of your posts, unless I've missed it :-)
Yes they actually were mentionned.
> Is it possible to support the following syntaxes (due Gennadiy Rozental, see
> the thread called "arguments parsing, wildcard matcher")
> 1. command line argument formats
> a. -<one letter key> <value>
> b. -<one letter key><value>
> c. -<key> <value>
> d. -<option> - any length
> e. /<key> <value> - and all other cases like a,b,c but with /
> g. --<key> <value>
> h. -<key substring> <value>
So long the option and aliases are registered by the Parser so the option
name and aliases can be whatever you want. The two rules I use to
* either the argument is in the same element but separated by =
* or the argument is the next element list
But I guess it could be possible to tune these settings
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk