Would using a library like Boost be acceptable at work? (C++)

Question

Possible Duplicate:
Is there a reason to not use Boost?

In my distaste for over-re-using small libraries that I had designed for different purposes (filesystem, network etc) for each project I had become to like the taste of using a larger general purpose library such as Boost.

If it saves time (and money depending on the general task at hand) would you think it would be a viable option to be used in place of my "tried-and-true" ones if it provides more functionality?

What are your general thoughts/experiences of doing something such as this? I would say the worst would be if someone else would maintain code that did not have experience with the library then it would be confusing, and etc.

Answer 1

Depends on your workplace. Most sane companies would jump at the chance to get free code of the quality in the official Boost libraries.

The problem with maintenance by inexperienced people is the same regardless of whether you use libs or build your own. Using Boost should actually help here because it reduces the surface area you have to worry about. With Boost you have to worry about interface - roll your own and you also have to worry about the implementation.

Answer 2

As long as the library's license requirements are ok with your work policy (some may be free but require some form of attribution (your boss may not want that in the help->about screen), and some companies just don't trust open source.) I see no problem. Just check that your workplace policy allows outside libraries with the license restrictions you are are going to use.

Answer 3

In general I think it is a good idea. Boost has a great reputation.

I do tend to avoid adding a library to the codebase for just one purpose. It can get overwhelming for your new colleages if you keep around 30+ different libraries with overlapping functionality. If everybody has a different favorite container type from a different library, the code will get heavy with glue/conversion code, you don't what that.

Answer 4

This question is inevitably going to lead to highly opinionated answers - so I'll give you my opinion. Boost is, by and large, an excellent library. It's so excellent, some of it has been standardized into the std namespace in C++1x.

That said, just dumping all of Boost into your roster of available libraries is somewhat dangerous. Firstly, many of the best and most widely used Boost libraries, such as boost::shared_ptr, boost::thread, boost::function, etc. are being made standard in C++1x anyway, making the Boost versions superfluous in the near future.

Secondly, many of the Boost libraries require a large time investment to become familiar with, and can be quite jarring to people who have to maintain such code without having spent time studying the library. Boost.Phoenix is an obvious example - it basically introduces an entirely different programming style into C++, and if you're not familiar with it (or the various hilariously obtuse compiler errors it will throw your way) it can be daunting to maintain code which uses it. (Also, arguably, things like Boost.Lambda and Boost.Phoenix are somewhat superfluous after C++1x built-in lambda support.)

Also, despite the fact that Boost is open-source, a lot of the source code may as well be a black box. It's incredibly difficult to understand without putting in some serious time studying it, largely due to all of the preprocessor hacks it uses to get older compilers to behave. (Only in Boost do you find macros used to make templates.) You might not care about the source, but believe it or not I have found valid bugs in Boost before, and I was only able to issue a bug-report after carefully examining the source code for a few days.

The best approach is to use Boost selectively. For example, if you need to do some linear algebra or matrix manipulation, Boost.UBLAS is an excellent choice. Boost also provides some useful small libraries which provide you with convenient syntactic sugar, like boost::lexical_cast. But you and your team really need to sit down and carefully decide which libraries in Boost will help you out, and which should be avoided. In my opinion, it's a bad idea to simply tell developers that they can just use any Boost library they feel like at the moment.

Answer 5

Well it all depends on the company policy and projects requirements.

On my spare time projects, I almost alwyays use boost like a second STL (or maybe POCO for future projects, just to play with it a bit). I have unconditional choice of tools, don't have restricting requirements from hardware or project features and those tools makes me write code faster as I don't have to reinvent the wheel. It's helpful because you don't have a lot of spare time each day...

However, when I worked in game companies, Boost was almost banished. For good (hardware restrictions - on consoles like NDS; hard to fix bugs in libs if you can't understand it - makes loose time if you rely on cryptic and wrong code) and bad (uses templates, makes the app slow) reasons.

In other companies, they didn't rely on boost because they worked with C with classes, so it was hard for them to understand any concept from the boost lib. Usage of some libs looked weird to them and what don't seem familiar and isn't vital should be avoided.

In some companies (the one I'm in right now) we use boost for performance and flexibility purpose. The main goal of our projects is to make flexible applications on the coding side and on other side, making boost and metaprogramming important tools to achieve the requirements.

So it's like with every tool : you'll use it if you see that need it and it's good enough for the job.

Answer 6

In any development shop, there needs to be control over what libraries and frameworks can be used; having a menagerie of different libraries doing especially the same thing is not good. Having said that, targeting excellent general purpose third party libraries is a good idea. Boost can certainly be seen as a natural extensions of C++.

You should develop standards of which libraries can be used for which tasks. For example, you might want to discourage use of a library like Qt for non-GUI tasks to improve portability.

All this should be seen as part of your teams coding standard.