From: Henrik Ravn (henrik_at_[hidden])
Date: 2001-11-19 18:21:05
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