At Sunday 2005-04-17 06:02, you wrote:

In-Reply-To: <000a01c542df$a4807770$0500000a@Hagrid> bjorn@4roald.org (=?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"