Re: [boost] (unknown)

From: David B. Held (dheld_at_[hidden])
Date: 2002-01-18 15:16:23

-----Original Message-----
From: rogeeff <rogeeff_at_[hidden]>
To: boost_at_[hidden] <boost_at_[hidden]>
Date: Friday, January 18, 2002 02:06 PM
Subject: [boost] (unknown)

>--- 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.  If I wanted to parse my own CLAs, why on earth am
I including a library?  To store my arguments?  What if I have a
nested option hierarchy?  Am I to handle all that complexity
myself, as an end-user, or are you going to let me specify how
options interact?

Dave