Hi, I'm currently enjoying using Program_options, and I have a few questions/comments about it. Is it necessary to create and use a variable_map for parsing program options? Is there a way to forgo this if I've already used value<T>(T*) to bind the options to other storage locations? What is notify() for, exactly? This is not really described in the documentation. It may be worth mentioning bool_switch somewhere in the documentation. (I dug this up from the header files.) Can I access positional arguments without going through the positional_options_description? My program is "variadic" and takes either 1 or 2 arguments (where the first has a completely different meaning depending on the number of args). I realize I can assign meaningless names in the positional_options_description, like "arg0," "arg1," etc., but I'm just wondering if there's already a way to access the raw positional arguments without going through the positional_options_description boilerplate. Is there a way to specify a *hierarchy* of command-line parameters, such as those found in svn (a two-layer hierarchy), git, etc.? If not, consider this a feature request! In svn, for instance, there are global options, there's the exact command, and then there are sub-options associated with the command. See the Python argparse module for an example of such a library design: http://argparse.python-hosting.com/ Thanks in advance for any answers. -- Yang Zhang http://www.mit.edu/~y_z/