Re: [boost] Any interest for a parser class?

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 /
> 	instead
> 	  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
parse are
* either the argument is in the same element but separated by =
 <option>=<value>
* or the argument is the next element list
 <option> <value>

But I guess it could be possible to tune these settings

Sincerely, Patrick