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

From: Patrick Guio (patrick.guio_at_[hidden])
Date: 2002-01-15 06:06:39

On Tue, 15 Jan 2002, Vladimir Prus wrote:

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

> 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

> 3) possibly checking that int in some range
>
> > > ii) How such thing as '-I' option to a compiler may be implemented
> > > (example please).
> >
> > I have added a new member function ParseOption, actually a template
> > member function that do the job,
> >
> > template<class T>
> > bool ParseOptions(int key, vector<T> &values) const;
> >
> > So the option -I is added as I explained and every occurences of -Idir
> > will be parsed in a vector<string> for example.
>
> 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.

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

Sincerely, Patrick