OT: let's rag on Boost

[Bill Baxter]

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