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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-15 05:13:07

Patrick Guio wrote:

> > Ah, so this is command line parser! Actually, I have been promising to
> > finish
> Actually it can be both used to parse command line and commands contained
> in a file.

True. Config file support is what I'm aiming at too.

> > I'm not sure about:
> > i) Can be have validation of input arguments
>
> I am not sure to understand what you mean. If it is to check whether an
> option was found on the command line, it is yes.

No. I mean
1) checking that what should be int is indeed int
2) parsing arbitrary class and thowing if the value given for it is incorrect
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?

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

- Volodya