Re: [boost] Re: Boost to the rescue

From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2005-04-17 11:22:36

At Sunday 2005-04-17 06:02, you wrote:
>In-Reply-To: <000a01c542df$a4807770$0500000a_at_Hagrid>
>bjorn_at_[hidden] (=?iso-8859-1?Q?Bj=F8rn_Roald?=) wrote (abridged):
> > So what are the real obstacles:
> > 1. Managers acceptance of introducing a new tool
> > 2. Convincing other developers on your team
> > 3. Lack of consistant documentation
> > 4. Lack of consistant support of all platforms (to me Sun CC support
> > has been a problem)
> > 5. Lack of a good measure of the stability of the API of various boost
> > libraries
> >
> > I feel like no. 5 is a real concern the boost team could do something
> > about with little effort.  You do not feel secure that the next
> > version of boost will support your code, thus you feel like it may
> > be risky to stick your neck out.
>
>Really? As a new user I kinda took stability for granted, at least as much
>as for any other 3rd party library. Are you sure this isn't only an issue
>for people who are already using some parts of Boost?
>
>I'd say the first problem is shear ignorance that the library exists at
>all, followed by ignorance of the first 3 paragraphs of the website's
>current front page. Boost is special.
>
>The second problem is of finding useful stuff in Boost. A lot of it is
>quite esoteric. The bits which aren't esoteric many programmers will
>already have invented for themselves. For example, shared_ptr can be in
>both categories. Many programmers don't see the need for smart pointers at
>all, and those who do probably have written their own.
>
>The third problem is a perception that the library is more academic than
>useful. The emphasis is on strict standard conformance, portability to
>compilers I don't care about, and language corner cases I don't care about
>(eg multiple virtual inheritance). This is often reflected in library code
>which is hard to read and understand, and often based on esoteric
>implementation techniques.
>
>The fourth problem is that as with any 3rd party library, boost will often
>not be exactly what one wants. If you write it yourself you can customise
>it. The shear size of boost bothers me in that I don't want to burden my
>source code control system unnecessarily.

21 meg isn't that much (for the headers) and in any rational development 
system there's one copy that everyone references... across the network

>  The dependency issue bothers me
>too.

You'd seriously rather that people copy/paste code to reduce 
dependencies?  Do you allow this practice in your commercial code?

>  I've had code break because a boost header somewhere redefined min
>and max.

where? when?  the real problem is that MicroSloth (leave it alone Dave, 
they're _more_ than a "little slow") #define min and max as a result of 
using windows.h !!!!  even if you're using C++.  Of course, they haven't 
fixed the "debug_new" problem in 4 revisions, I don't know why anyone would 
expect them to fix anything else important.

>Linking issues may be a problem; I don't know. I have extracted a small
>subset of boost that was header-only. I never touched bjam.

unfortunately, date-time MUST be built (I'm not complaining, just 
commenting), perhaps if the Committee got its head out and started 
considering _real_ problems we'd all be ahead of the game.

>-- Dave Harris, Nottingham, UK.
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law"