Boost advocacy - help needed

Question

Possible duplicates
Is there a reason to not use Boost?
What are the advantages of using the C++ BOOST libraries?

Answer 1

It seems to me you're doing this the wrong way around. Since proposals to add new libraries are going to be met with a lot of resistance, don't even bother trying to argue for boost as a whole. Choose your battles instead.

Find the specific Boost libraries which you know (with your knowledge of the application it's to be used in) will be useful and save time and money. And then propose adding those.

I could easily list the Boost libs I've found useful, and why I think they're great, but I don't know if they'll be of any use in your application.

Push for individual boost libraries to be included, and then perhaps, over time, so many of them will be included that it'll be simpler for everyone to just include all of Boost.

Answer 2

Boost is a great tool and an invaluable part of our product development (we'd be lost without smart_ptr)... but because it is changing so fast the stability of releases can be effected.

For example, we were happily introducing new versions of Boost as soon as they came out without thinking twice. That is until we were stung with a bug in the 1.35 threading library that produced occassional (ie difficult to debug) but critical errors. Fortunately we identified the issue before anything was released to the public and could move back to 1.34.

Ever since then we've taken a specific version, extensively tested it, and not updated without a compelling reason to do so.

Answer 3

1. It's an open standard not controlled by a specific company ( no licensing costs )
2. It's cross platform
3. It's expertly designed / written and very fast / efficient extensively tested
4. There are open source implementations which your team can compile themselves.
5. Boost will soon become part of the standard C++ STL

Here is a slightly oldish 2005 article on Dr. Dobbs discussing the upcoming C++0x standard.

http://www.ddj.com/cpp/184401958

Answer 4

Here are two suggestions for advocating boost:

Who's Using Boost? (http://www.boost.org/users/uses.html)

lots of major projects use boost: (e.g., adobe photoshop, CERN)

Boost Project Cost (http://www.boost.org/development/index.html)

How much it would cost to hire a team to write boost from scratch? There's a nifty (somewhat gimmicky) calculator there that helps to put it in perspective.

Answer 5

Wherever I worked in the last decade, when they had their own smart pointer class, I found bugs in that - usually within a few weeks. And, no, I never went and looked at it hoping to find errors.

I got into the habit of posting the following quote from the TR1 smart pointer proposal:

The Boost developers found a shared-ownership smart pointer exceedingly difficult to implement correctly. Others have made the same observation. For example, Scott Meyers [Meyers01] says:

"The STL itself contains no reference-counting smart pointer, and writing a good one - one that works correctly all the time - is tricky enough that you don't want to do it unless you have to. I published the code for a reference-counting smart pointer in More Effective C++ in 1996, and despite basing it on established smart pointer implementations and submitting it to extensive pre- publication reviewing by experienced developers, a small parade of valid bug reports has trickled in for years. The number of subtle ways in which reference-counting smart pointers can fail is remarkable."

This plus a detailed analysis of the bug(s) I found usually got me the job of incorporating the boost libs into the code base. :)

Answer 6

I had to maintain a component using that old vintage Tools.h++ from Roguewave, on a Solaris system.

On Solaris, if we want to use boost, we need to use either gcc, or SunStudio with STLport implementation of the standard (instead of Roguewave one). And as Tools.h++ requires the old Roguewave pre-standard implementation of the standard -- on Solaris --, I had to give up on boost.

In the end I rewrote a simplified version of a few boost-like features I needed.

If you are in that same situation (*) , you would not be able to move from Roguewave library to boost that easily. There is a non negligible cost in this operation, as for instance pointer containers from both libraries have quite different interfaces.

(*) Where we can't slowly change bits by bits of the old code to progressively use boost. In that situation, the migration has to be radical and to change simultaneously every occurrence of Tools.h++ by something more trendy, or even better.

NB: Most people are able to progressively use boost in old projects, and may miss a very important, and yes technical, point. Hence my negative answer.