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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-15 08:14:11

Patrick Guio wrote:

> > No. I mean
> > 1) checking that what should be int is indeed int
>
> This is handled as you say. For now I have a specialised
> Parser::Convert(string, value) for each intrinsic C++ type and the
> conversion is done using the C strto* family routines. The errno (cerrno)
> is used and exception is thrown. I must say that I have actually two
> versions of the Parser one making use of char* (more C-style) and another
> one make use of string and I am planing to replace C strto* family
> routines by istringstream class.

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?

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

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

> > > > 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 :-) 
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>

- Volodya