Thanks for doost.program_options
Bill Baxter
dnewsgroup at billbaxter.com
Fri May 25 01:22:10 PDT 2007
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
More information about the Digitalmars-d
mailing list