Boost logo

Boost :

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
> > of complexity vs. flexibility. The command line arguments parsing
> > does not require to be efficient. So it should be implemented
> > offline (maybe with exclusion of user defined argument classes).
> > just should keep in mind that the library could be used for EVERY
> > program. Can you imagine that all your programs will require
> > Framework to compile and run?
> No, this is clearly overkill and this is why I suggest a tool that
> 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
> such as Spirit or whatever.
> Using such a tool the developer would write the spec for the
> in some format (dare I say xml?) and save it in a file, e.g.
> 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
> 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
> this. In a GUI environment, instead of simply generating a usage
> dialog, why not generate a dialog box that enables the user to
> set the options via standard GUI widgets?
> My point is not to argue for xml (I'll do that some other time :-),
> 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
> 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:
   <identification>option --</identification>


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.



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