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?

OK, the high-level question is "Please provide me with what you consider to be the most effective arguments of why entire Boost, or some specific parts of it, should be compiled on our company's system and endorsed in software engineering standards".

Details of what I need:

• Would gladly accept both positive arguments (why install), as well as proposed rebuttals of likely counter-arguments I might hear (see question context below).

• Arguments should be made aimed at both technical Software Engineering team members and/or very technical senior managers - in other words, for the latter, the details of the argument may/should be technical, but the thrust of the argument should be "how would this make/save the company X money vs losing the company Y money as a cost of adding it to our toolset".

Context of the question:

• I'm a developer in a company with several hundred developers, many dosens of whom do C++.

• I had the (mis)fortune of being reassigned from my beloved Perl development spot to a team where I am also doing C++ development. So far I found numerous things that I could easily have done in Perl that are very hard/cumbersome to do in C++ (foreach loop as an example), and anytime I hit one of these, the answer 50% likely ends up being "You can't do this in standard C++ but you can do it with Boost"

• Our toolkit includes some legacy RogeWave libraries, and VERY limited number of Boost libraries (e.g. no regex, no foreach), of very old vintage.

• Any development must use libraries compiled and vetted by Software Engineering team. That is a hard and fast rule.

• SE team is somewhat resistant to adding new libraries, for a variety of reasons (e.g. effort to do this; functionality conflicts with RogeWave, for example for RegEx; the risk of installing and using any new software; cost of educating developers, etc...). They will add the libraries if presented with sufficient business need or majorly convincing cost/benefit ratio argument, but they have pretty tough threshold.

So, I'm looking for examples of which parts of Boost are so wonderful (with exact cost/benefit estimates) that installing them would be an Obviously Worth It Effort for Software Engineering.

Thanks in advance for any ideas/suggestions/examples.

Please don't mark this question as subjective as I am looking for measurable answers, not merely wonderful feelings :)

Answer 1

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 2

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.

Answer 3

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 4

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 5

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 6

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.