View mode: basic / threaded / horizontal-split · Log in · Help
May 25, 2007
Thanks for doost.program_options
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 25, 2007
Re: Thanks for doost.program_options
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 25, 2007
OT: let's rag on Boost
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 25, 2007
Re: Thanks for doost.program_options
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 25, 2007
Re: Thanks for doost.program_options
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
Re: Thanks for doost.program_options
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
Top | Discussion index | About this forum | D home