Boost logo

Boost :

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 {
> 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
>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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at