Boost logo

Boost :

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.


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

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