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