Re: [boost] arguments parsing, wildcard matcher

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

David Abrahams 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...

Ha, found the rest of the thread.  :)

The way I've done this in my options package (described later in
this thread) is to have each option object hold a string
help field.  Then if an invalid or unknown option is seen,
the parser can traverse the option database and spit out
all the help text in a nice format.

In fact, unknown objects can be handled in a more flexible manner,
in that the programmer can pass a special action object to invoke
when an unknown option is seen.

Sub-options and action objects have _very_ nice implications
for code that uses plugin architectures, because an option
can trigger a plugin load and the plugin can dynamically insert
options into the database.  I use this a lot to parse sub-options
in my plugin objects.  -p<plugin_name>={--plugin_options}
triggers the action for option "-p" which loads the plugin
<plugin_name> (stripped from the full option value
"<plugin_name>={--plugin_options}") and the plugin (which
is passed a reference to the "-p" option object) can
insert its options and invoke the parser on the option subtree,
passing "<plugin_name>={--plugin_options}" as the option
text to parse.

Perhaps this is a bit overboard for what most people need,
but I have found it to be invaluable.  It would be neat
if Boost could support 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