Re: arguments parsing, wildcard matcher

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-11-19 17:04:02

Hi,

We should be really careful when implementating such generic 
component as command line parser. We should find a REASONABLE level 
of complexity vs. flexibility. The command line arguments parsing 
does not require to be efficient. So it should be implemented mostly 
offline (maybe with exclusion of user defined argument classes). We 
just should keep in mind that the library could be used for EVERY 
program. Can you imagine that all your programs will require Spirit 
Framework to compile and run? I think we could use the following 
criteria: if equivalent amount of code allows phrase the same 
statement without introducing additional feature to parser - do not 
introduce it.
  For example to register an action for particular argument presence 
you will need somethink like:
     new argument( ..., do_this_action_if_present() );
While the same logic could be implemented like this:
   if( argument.is_present() )
     do_somethink();

The second version is also more stable because you now know in which 
order events will ocure.

Regards,

Gennadiy.

--- In boost_at_y..., "David A. Greene" <greened_at_e...> wrote:
> williamkempf_at_h... wrote:
> 
> > A good parser should allow multiple arguments per option 
> > as well as allowing free arguments to be interspersed within the 
> > options.  This isn't an easy thing to do and is nearly impossible 
> > with the simpler APIs.
> 
> I seem to have lost/not received the beginning of this thread so
> 
> apologies if this has already been discussed.
> 
> 
> I've written an argument parser for my currect project that
> 
> has some features I've found to be essential for what I do:
> 
> - Sub-options.  These work something like this:
> 
>    ./program "--option1={--variant1=value --variant2}"
> 
>    (Quoting is necessary for shell reasons, obviously)
> 
> - Registration of option actions.  When an individual option
>    is created, it is passed an object describing what to do
>    when the option name is parsed.  There are many pre-built
>    actions such as "set this variable to the option's value,"
>    "toggle this flag" and "execute this function object."
>    Sub-options are implemented with the "function object"
>    action where the action object just points to a
>    functor/function that reinvokes the argument parser on
>    the option value.
> 
> The above implies that the option database is structured
> as a tree, so that the option object for an argument with
> sub-options contains all of the registration info for that
> argument.  Thus when the parser is reinvoked it is passed
> a small branch of the full option tree.
> 
> Is this making any sense at all?
> 
> I was planinng on reimplementing the package using the
> Spirit C++ parser framework, which I believe will eventually
> be submitted to Boost.  The package itself could be coded
> much better than it is -- it began way back before g++ had
> good template support, so it really needs an overhaul.
> I just wanted to throw out some ideas from my experience
> developing and using it.
> 
>                              -Dave
> 
> -- 
> 
> "Some little people have music in them, but Fats, he was all music,
>   and you know how big he was."  --  James P. Johnson