Re: [boost] Re: Boost to the rescue

From: Dave Harris (brangdon_at_[hidden])
Date: 2005-04-17 08:02:23

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. The dependency issue bothers me 
too. I've had code break because a boost header somewhere redefined min 
and max.

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.

-- Dave Harris, Nottingham, UK.