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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-18 16:05:09

From:	rogeeff [SMTP:rogeeff_at_[hidden]]
> 
> > >--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> > >> [...]
> > >> Any interface that allows users to add custom argument handling 
> > >> exposes some sort of parsing implementation. 

That's my statement...

> > >That is a key point. This statement is false.

...and that's my statement...

> > Only in the most technical sense.

...but that's not mine.

The following is not mine...

> > >class argument can have interface like this:
> > >class argument {
> > >public:
> > >     virtual bool match( argv_stream_iterator it ) = 0; 
> > >     virtual void construct( argv_stream_iterator it ) = 0; 
> > >};
> > >
> > >argv_stream_iterator is an iterator over stream constructed from 
> > >argc,argv. 
> > >
> > >That's it. Framework has list of arguments and do something liek 
> this:
> > >
> > >while argv_stream is not empty
> > >
> > >for each argument 
> > >{
> > >    if ( argument match ) {
> > >         if another argument match => error
> > >         construct argument
> > >         if fail to construct => error
> > >         break 
> > >    }
> > >}
> > 
> > So instead of giving the user a way to specify the parsing
> > format, and letting the CLA framework continue to do the
> > parsing, you would rather offload the actual parsing responsibility
> > to the user. 

...the previous is not mine.

> In most case end-user would use predefined rich arguments set. More 
> over each argument could be parameterized with identification policy.

(OT: I've got to mention this here, since I've seen this repeatedly:
"moreover" is one word, not two.)

> >  If I wanted to parse my own CLAs, why on earth am
> > I including a library?  To store my arguments?  

That was not my statement.

> it' CLA framework. Store, validate and destroy an arguments, provide 
> an access and so on
> 
> > What if I have a
> > nested option hierarchy?  

That was not my question.

> Generic framework could provide support for nested arguments. Note 
> that it has nothing to do with parsing.
> 
> > Am I to handle all that complexity
> > myself, as an end-user, or are you going to let me specify how
> > options interact?

That was not my question, either.

> Generic framework could provide support for dependent arguments. Note 
> that it has nothing to do with parsing.

Unless I'm completely confused by the examples given here, the CLA design
you've shown here does no parsing at all, beyond turning argc/argv into a
collection of strings over which one can iterate. The parsing is totally up
to the client of the CLA. How does this help?

Rob
Susquehanna International Group, LLP
http://www.sig.com