Thanks for doost.program_options

[Bill Baxter]

Just wanted to say thanks to Marcin Kuszczak for doost.program_options.

Works like a charm.  Sadly I'm finding I'm running into the same problem 
I always seem to run into with Boost libraries (one of the two problems 
anyway) -- which is documentation.  The Boost documentation is quite 
impressive at first glance: nicely formatted, well-organized, but on 
closer inspection the docs are often totally incomplete.  They tend to 
document one or two common usage patterns on the one hand and then a 
scatter shot of library minutia on the other.  But totally missing the 
huge middle ground.

Sorry, just had to vent after spending way too long trying to figure out 
how to get program_options to tell me the dang name of the program.

For those interested answer is you have to use the magic, undocumented 
option specifier of the form:

       ("progdir",value!(string),"progname",value!(string))

That is, it treats a specifier with args (string,value,string,value) 
specially, as a name for the program directory and program basename.

Totally not Doost's fault that Boost libraries are poorly documented, of 
course.  Just annoying.  I don't really understand why everyone is so 
wild about Boost.  I've yet to meet a Boost library that didn't waste 
hours of my time just in trying to accomplish the most basic thing.

One enhancement request -- it would be nice if there were a keys() 
method on VariablesMap.  Just this in variables_map.d is all that's needed:

     string[] keys() {
         return m_variables_map.keys;
     }

Maybe a values method too -- but I don't really see a good use case for 
that.

--bb