www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thanks for doost.program_options

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
May 24 2007
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter wrote:

 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.


I've used boost's shared_ptr library without hassle.  In D, that library 
is unneeded because GC is built in.

I agree that using a new boost library does take a considerable amount 
of time.  In many cases, I end up saving time in the long run by not 
implementing (and debugging...) similar functionality.  I've liked the 
boost libraries because I know that after I finish learning how to use 
them, they'll work cross platform and have plenty of features I'll want 
once I realize I need them.  While the docs, ability to follow code, and 
initial debug when using the libraries isn't very appealing a guarantee 
of underlying code quality is.
May 24 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:

 Bill Baxter wrote:

 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.


 
 I've used boost's shared_ptr library without hassle.  In D, that library 
 is unneeded because GC is built in.


Yeh, I think that's the only one for me too.  But really the point of 
shared_ptr is that it should act exactly like a regular pointer without 
you having to think about it, so there's not a whole lot to learn or get 
lost in there.


 I agree that using a new boost library does take a considerable amount 
 of time.  In many cases, I end up saving time in the long run by not 
 implementing (and debugging...) similar functionality.  I've liked the 
 boost libraries because I know that after I finish learning how to use 
 them, they'll work cross platform and have plenty of features I'll want 
 once I realize I need them.  While the docs, ability to follow code, and 
 initial debug when using the libraries isn't very appealing a guarantee 
 of underlying code quality is.


In my case I generally ended up feeling like I could have implemented 
the actual subset of functionality I needed in less time, and with the 
result being easier to maintain, compile, and debug.  Maybe it wouldn't 
have had slick syntax like 
"foo()(x,+boost::coolness[frob(&a,b,c)::binder_2nd(operate,_1)])", 
(instead requiring 10 lines of code or something) and maybe it would 
lack some feature that I find I need some day, but it would be a heck of 
lot easier to maintain and add that feature than if it turned out the 
boost library doesn't have it either.

Just to be specific, my main bad experiences with Boost have been 
Serialization, Filesystem, Functional.  Good experiences include 
boost::shared_ptr.

--bb
May 24 2007
prev sibling parent James Dennett <jdennett acm.org> writes:
Jason House wrote:

 Bill Baxter wrote:

 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.


 
 I've used boost's shared_ptr library without hassle.  In D, that library
 is unneeded because GC is built in.


(Non-deterministic) GC doesn't do what shared_ptr does,
and shared_ptr is useful even in GC'd C++ code.  D does
recognize that deterministic destruction is useful,
which puts it ahead of most languages that like to
position themselves as competitors to C++.

-- James
May 24 2007
prev sibling parent reply Aarti_pl <aarti interia.pl> writes:
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 :-)



 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.
 


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... :-]



 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


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...

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 :-) )

- 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)

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

- changing implementation style to be more D-ish

- Extended documentation and tests

Unfortunately it's slow process as I can not give much of my time for 
this purpose... Anyway at the point of release I will need people to 
thoroughly review API and design. And you are first candidate to be 
reviewer ;-)

Best Regards
Marcin Kuszczak
(aarti_pl)
May 25 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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



 May 25 2007