Thanks for doost.program_options

[Bill Baxter]

Aarti_pl wrote:
> Bill Baxter pisze:
>> Just wanted to say thanks to Marcin Kuszczak for doost.program_options.
>>
> 
> You are welcome! It's always nice to hear encouraging words :-)
> 
> 
>>
> 
> I have to agree with you - few features of program options are even not 
> mentioned in documentation (e.g. specifying long and short version of 
> option: "version,v" - you can find it out only from examples)
> 
>> 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.
>>
> 
> ... this part is not necessarily Boost fault :-) In fact this syntax is 
> my extension to library, as the original doesn't have such a feature. 
> It's documented here: http://dsource.org/projects/doost/wiki/ProgramOptions
> 
> Not very extensive information, but something at least... :-]

Ohh... I see.  Well I'm still gonna blame that on boost, because it's 
all too common in my experience for Boost libraries to come with a 
bazillion super-duper advanced never-use-it-in-a-million-years features, 
but to forget something trivial like getting the program name, which 
everyone would want to use.  :-)


> IMHO the main problem with Boost libraries is that they are very 
> difficult to extend and maintain. I would say that where possibilities 
> are already finishing in Boost(due to overwhelming complexity) they are 
> just beginning in D...

Indeed.  But after spending most of the day trying to find good D 
alternatives for std::list and std::multiset, I'm not feeling so happy 
about D at the moment. :-(

> And the cake for finish ;-)
> 
> I am currently working on completely refactored version of program 
> options. Planned features include:
> 
> - Tango compatibility (I am slowly creeping to Tango camp too :-) )

Eh, just use Tangobos.  :-)

> - possibility to store options in backends (I will create Database 
> backend (using DDBI) and extend config files backend / environment 
> variables backend to enable storing variables)

Probably wouldn't use that one myself.

> - custom value types (I couldn't translate it from Boost when making 
> original translation)

Not sure if I'd use that either.  For the infrequent cases where I'd 
need that I think it would be easier to just get the arg as a string, 
then parse it into a variable myself afterwards.

> - changing implementation style to be more D-ish

I hope that includes keys() for the VariablesMap!

> - Extended documentation and tests

Always good.

--bb