Re: [boost] arguments parsing, wildcard matcher

From: David A. Greene (greened_at_[hidden])
Date: 2001-11-19 15:48:21

Henrik Ravn wrote:

>>It occurs to me that even in the simplest cases, the 
>>programmer probably needs to write the "usage" output which 
>>responds to --help or incorrect options. A truly easy-to-use 
>>interface would read and interpret the "usage" text, so that 
>>the programmer hardly needs to do anything else. I have no 
>>idea how feasible that is...
>>
> Neat idea!
> 
> Perhaps it could be done via some form of xml-driven description...
> 
> Something along the lines of:
> <cmdline>
> 	<options>
> 		<option name="Verbose" match="v,verbose"
> case-sensitive="yes">
> 			Descriptive text for the usage text goes here
> 		</option>
> 	</options>
> 	<!-- etc etc -->
> </cmdline>

Here's how it looks in my package.  The first parameter is the
option name and the second is the help text.  The action object
determines whether the option takes an argument.  The parser
queries these objects to see what it should do.

cacheOptions.registerOption("--name", "cache identifier", new
   CCDev::optionDatabase::setStringValueAction(cacheName, ""));
cacheOptions.registerOption("--type", "instruction or data",
   new CCDev::optionDatabase::setStringValueAction(cacheType, ""));
cacheOptions.registerOption("--class", "traditional, blockDistribution",
   new CCDev::optionDatabase::setStringValueAction(cacheClass, ""));
cacheOptions.registerOption("--size", "cache size in KB",
   new CCDev::optionDatabase::setUintValueAction(cacheSize, 0));
cacheOptions.registerOption("--associativity", "cache associativity",
   new CCDev::optionDatabase::setUintValueAction(cacheAssociativity, 0));
cacheOptions.registerOption("--blockSize", "cache blockSize in bytes",
   new CCDev::optionDatabase::setUintValueAction(cacheBlockSize, 0));

(Note: set*ValueAction should probably be a templated class)

This is a really simple example.  cacheOptions is a leaf node
in the option tree for a trace-based simulator I developed some
time ago.  It uses the action objects to dynamically build
the simulator structure as the options are parsed.  As each
part's option is seen ("--cache" in this case) a factory
parses the suboption tree and creates the appropriate structure.
The strategy relies on unknown options being saved "off to the
side" to be re-parsed as appropriate structures are created,
so that when the simulator factory sees the --cache option,
it is saved off to the side, the simulator options such as
"--type" are parsed, the appropriate kind of simulator is
created and it is passed the extra options.  If the simulator
type supports a cache, it will have registered the "--cache"
option when it was created and won't bomb out when it sees
the cache options.

This way, there is no centralized point for registering options,
which allows simulator parts to be developed independently.

                              -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson