Re: arguments parsing, wildcard matcher

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-11-19 21:40:08

--- In boost_at_y..., "Henrik Ravn" <henrik_at_r...> wrote:
> 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? 
> No, this is clearly overkill and this is why I suggest a tool that 
sits
> between a description of the command line and the code that ends up
> parsing it in the actual app. The tool would use a parsing 
framework,
> such as Spirit or whatever.
> 
> Using such a tool the developer would write the spec for the 
commandline
> in some format (dare I say xml?) and save it in a file, e.g. 
myapp.cld.
> At build time, myapp.cld is run through the tool, parsed and the
> relevant hpp/cpp files are generated for the project.
> 
> Such a tool would bring a lot of flexibility without adding 
complexity
> to the apps that use it. Not only can usage statements be 
generated, but
> man-pages or other usage documentation can be generated this way. 
In a
> far distant future, you can even imagine that GUI apps can benefit 
from
> this. In a GUI environment, instead of simply generating a usage 
message
> dialog, why not generate a dialog box that enables the user to 
actively
> set the options via standard GUI widgets?
> 
> My point is not to argue for xml (I'll do that some other time :-), 
but
> mainly that by not specifying the command line syntax in C++ we 
gain a
> whole lot of future possibilies and can still keep the user code 
fairly
> simple.
> 
> be well
> Henrik

If we factor GUI out documntation isuues whi are totally separate 
(For example, if you ever want to use tool for documentation 
generation you would use it for all the components of the software. 
So you will need some kind of generic utility that is not connected 
with any specific one - CLA in our case) I do not see any advantages 
in using stand alone tool. Your framework will still need to provide 
all the functionallity that will be compiled with program. You still 
need algorithms for parsing all kind of argument identification. I 
need an aceees methods and other staff. The onle differenceis that in 
one case you define arguments in a nexternal file something like this:
<argument>
   <name>port</name>
   <description>bla-bla-bla</description>
   <type>int</type>
   <identification>option --</identification>
   <optional></optional>
</argument>

vs.

new argument<int>( "--port", "bla-bla-bla", true, /*optional*/,
                   KeyIdentifcationPolicy( "--" ) );

I think the rationalle is to use external definitions only fot things 
that are (though your tool is not exactly the case):
  1. End-user configurable
  2. Frequently or dynamically changed.
  3. Widely shared information
IMHO reusable and flexible enough command line argument parser could 
be implemented without involving any external tools.

Regards,

Gennadiy.