From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2005-04-17 11:22:36
At Sunday 2005-04-17 06:02, you wrote:
>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
>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
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
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"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk