Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Very often here on SO I see notes about boost such as
If you are fine with using Boost...
or
If you can use Boost...
And I wonder, what's that all about? What should I be weary of? When can't I use boost? What are the reasons not to use boost? In my opinion boost is a great extension to STL; sometimes very heavyweight and clumsy, but great nevertheless.
I am not really asking for opinions about boost as such. I am rather looking for some concrete examples when should I think twice before using boost.
When I can't use boost? In my opinion boost is great extension to STL,
sometimes very heavyweight and clumsy, but great nevertheless.
Boost is not a library but a collection of largely independent libraries of individual quality. With this in mind, and also taking into account that I'm personally a big fan of most of Boost, here are some reasons I can think of for not using certain Boost libraries:
- Some Boost libraries are redundant since C++11.
- Some libraries are not widely used and thus require expert knowledge in your project which might be expensive to replace when an employee leaves the company.
- Company guidelines which developers have to obey more for political than for technical reasons.
- You have no guarantee that any Boost library will be continued to be maintained in the future. Standard C++ code written for some compiler today will very likely continue to work fine with a newer compiler by the same vendor 10 years from now, for simple commercial reasons. With Boost, you have to hope that enough competent people will have any interest in long-term maintenance.
- No Boost library is documented as extensively, with so much material in countless books and on the internet, as the C++ standard library. Who will support you if you have some really exotic problem with a particular library? Surely with standard C++ your chances of finding people with the same problem (and existing solutions for the problem) are much higher.
- Debugging some Boost code can be more difficult than debugging code that uses the standard library.
Because it's not an extension to the C++ Standard Library (nor to the STL, naturally).
It is a third-party distribution, that you must download and install, locally and (for some Boost libraries, if you dynamically link) on the target system. You must manage and document the dependency.
I shan't enumerate all the scenarios in which this is not feasible, but it should be self-evident that you cannot always use non-standard code. Not everybody is working on a platform on which you can simply write yum install boost-devel, write your code and move on. The world of computers goes far beyond commodity desktop PCs.
That being said, most arguments for avoiding Boost are incredibly weak, due to its extreme portability, and the fact that the majority of Boost libraries are header-only (which reduces the packaging overhead significantly).
Seems like a lot of fuzz for nothing
I don't think writing the phrase "if you can use Boost" can be honestly described as "a lot of [fuss]".
Maintenance mostly.
Once you add boost, you have to maintain it. Either get updates (and maintain any changes mandating changes in your code), or freeze the version and fix bugs yourself.
Both are expensive and backloaded costs. For a project with a lifespan measured in decades, such costs are highly important.
In addition to @LightnessRacesInOrbit's point, I'd say there are a few reasons:
- Boost has a lot of code in
.h and .hpp files, which you need to include in every translation unit (which uses the relevant parts of Boost), and those files are laden with complex and recursive macro use and smart - but again, complex - use of templates. The combination makes your compilation a w-h-o-l-e lot slower.
- Boost isn't installed everywhere by default, so it's not always available to you just because C++ and the standard C++ library is.
- (A new reason actually) A sizeable fraction of Boost functionality has made it into C++11 (more is in C++14, and still more in C++17). So, by now, there are alternatives in the standard library or even the language itself for part of what Boost offers.
