From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-18 15:51:02
> >--- 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 is a key point. This statement is false.
>
> Only in the most technical sense.
>
> >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.
In most case end-user would use predefined rich arguments set. More
over each argument could be parameterized with identification policy.
> If I wanted to parse my own CLAs, why on earth am
> I including a library? To store my arguments?
it' CLA framework. Store, validate and destroy an arguments, provide
an access and so on
> What if I have a
> nested option hierarchy?
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?
Generic framework could provide support for dependent arguments. Note
that it has nothing to do with parsing.
>
> Dave
Gennadiy.