Stack OverflowIs there a reason to not use Boost?
[+150] [13] asyncwait
[2009-08-04 07:59:49]
[ c++ boost ]

I had this discussion with my colleague today about using Boost in our new C++ project. He did not agreed to use Boost as he thinks that Boost is huge and another point he added was that Why did Chrome team chose to not to use Boost? I am not sure what to answer ... His whole point is none of the modern day C++ projects make use of Boost other than its libs like SmartPointers.

I like use to Boost and love to code using Boost library, but got no point to prove that Boost is the best bet to be used in any C++ project like desktop application or server applications.

Any thoughts?

(11) no, don't. I really don't see what that's supposed to gain anyone. - jalf
(10) If your colleague accepts the use of boost's smart pointers, then he is using boost too. There's no law that you have to use all of it. ;) - jalf
(4) That would be some app... - Steve Jessop
(5) I'd hesitate to call any C++ project that doesn't use something from boost 'modern'. - Joseph Garvin
(3) Here is Google's policy on Boost including rationale. The reason against is "Some Boost libraries encourage coding practices which can hamper readability, such as metaprogramming and other advanced template techniques, and an excessively "functional" style of programming.". - Andrew Tomazos
(5) 8 delete votes?! Please don't delete this highly relevant question, and with it Steve Jessop's masterpiece of an answer. - j_random_hacker
[+254] [2009-08-04 08:10:07] Steve Jessop [ACCEPTED]

Whether to "use Boost" or "not use Boost" is a false dichotomy. Boost is deliberately designed to have many components, and relatively few dependencies among them. If your project needs a particular Boost feature then you should evaluate the component against your needs, and allow it into the project or not.

If the question is, "why don't projects all just allow the whole of Boost to be used as though it were part of the standard libraries?", the the answer is a general discussion of why a software project might want to limit its dependencies on non-standard code, and in particular on libraries whose APIs are still under development. Some parts of Boost are stable, others not. Some projects are intended to be ultra-portable, in which case you generally do not want to rely on Boost libraries which contain any platform-specific code, because you will then have to fork Boost in order to port to your next platform. Some projects don't want one coder off in a corner using Boost.Spirit when everybody else is creating their parsers with Bison. And so on.

Smart pointers are near-ubiquitous because the Boost implementation is (1) extremely useful, filling a need which many projects have; (2) extremely portable; (3) almost standard (shared_ptr is in TR1); (4) small; (5) recommended by all experts, meaning that all C++ programmers are familiar with it. This counters almost all reasons not to use it. But not all Boost components have all of those properties.

A comment on Chrome in particular: there is a very brief discussion of Boost [1] in Google's C++ style guide. Google seems to have very stringent rules for admitting external C++ library dependencies. I speculate that this is because Google has many programmers and many products, so for them the economics of re-inventing the wheel in-house, to meet their precise needs, are different from most companies. Google can afford to invent things well and use them a lot, whereas most companies are much smaller, and need to do fewer things in order to do them well. So for example Google can afford to maintain its own browser, and its own web UI toolkit (GWT), and its own server technology (MapReduce, GFS), and build data centres itself out of CPUs and bits of string. Much as I hate marketing-speak, most companies do need to focus on core competencies, not go both vertical and horizontal.

So you can't necessarily use Google as an example of why not to use Boost, unless you're prepared also to use it as an example of why not to buy commodity motherboards. This is not to say there aren't plenty of reasons why your project might want to avoid any given library, or that your company can't have confidence in its ability to get things done. Just that there's a good chance Google's reasons do not apply to you, and that the things you do will not be the things Google does.


Thanks, its very good point! - asyncwait
(69) Thanks. You might be more likely to get more answers if you don't accept one so quickly - I get the impression some people when they're scanning the question list are less likely to look at questions that "have been answered already", but in this case there could be thousands of reasons for and against Boost that apply in different situations. - Steve Jessop
(4) +1 onebyone for taking one for the cause! - Skilldrick
Oh yes!! but however I am getting enlightened by your answers .. - asyncwait
I have removed the answer mark as you suggested .. - asyncwait
+1. Clearer explanation ever. - Diego Sevilla
[+66] [2009-08-04 08:46:47] Rob Vermeulen

All previous answers aside, it generally is a huge waste of time if you do not use Boost if and where you can. You should indeed consider what parts of Boost to use, depending on several criteria mentioned before, but just rejecting it on forehand is an unprofessional approach and reveals the person's lack of experience.

Need a parser? Need control over your memory handling (e.g. shared_ptr)? Need an OS-independent framework, with threading, file handling and more? Need locking and synchronization? Need performance? Need solid data structures? It's all there, and more. And it's working. Re-inventing all that by yourself, is a waste of time thus expensive and imho plain stupid.

There are legit reasons not to use Boost. If the compiler of choice isn't supported by Boost, you're fried. If you have alternative solutions for the parts of Boost you're likely going to use, and you're more familiar with coding for those solutions, then go forth and succeed. If you hate the terribly unreadable compiler and linker errors you sometimes get with Boost, that's understandable. But if you just don't use Boost because someone else's team also didn't use it, you forgot to think for yourself. Boost is too valuable to just be set aside blindly.

[+41] [2009-08-04 08:24:38] Alan

To my shame I think I may have been like your colleague a few years ago - I was very sceptical at first of the real benefits that boost could provide. I too saw it as a huge monolithic monster that served little purpose apart from the occasional useful class.

Fortunately for me, I was eventually convinced that we really needed boost and would ultimately find more benefits as we grew to understand more about the library.

A few points to consider when trying to convince your colleague:

  1. Boost is rather large, but the installation itself is kept neatly in a single directory.
  2. You only have to go through the pain of installing once (and this in my opinion is not really a major barrier)
  3. You will gradually start to utilise more and more functionality in boost as you learn more about the framework and how it can improve you production code.
  4. Code quality is very high - people far more intelligent than me are maintaining boost and making sure bugs are minimal and performance is optimal.
  5. The CRT/MFC/Qt libraries are quite large - I'm sure he wouldn't consider writing code without these frameworks! ;)

(21) +1 - code quality is high. I'm pretty sure boost is one of the major reasons that within the last 5 years a lot of compilers have improved their template support. I don't think I'd be too wrong to say that most compiler vendors now use boost as part of their major regression suite before releasing! - Richard Corden
(2) +1 for the last point. MFC is huge but people have no problem using it -- just because they're afraid of using anything not there by default. - kizzx2
(1) Don't forget that in most Linux distributions it's just a package installation away. - thirtythreeforty
[+20] [2009-08-05 14:38:10] Rodrigo Pinho Pereira de Souza

Well, you have a lot of arguments in favor of boost:

If your boss argues that it cannot be used because of licensing issues, you could copy the Boost license, which is really clear and objective, and ask him where it's unclear?

If he says that is hard to find people that understand STL, and even harder for boost, you could say that he is probally right, but, is much more easier to learn Boost than STL, even more, Boost documentation is extremelly good, and have a lot of examples. Boost is much more easy to learn than lot of libraries like MFC, ATL, STL, QT. So, you could argue that anyone that knows MFC, ATL, STL or QT, would be able to get into boost fast.

If he says that boost is not standardised, ask him to look the boost code. All the code follows the same guideline, same guidelines of STL. Even more, the majority of boost commitee members are also part of the C++ standard. And the TR1 is implemented in the boost.

If he says that is difficult to distribute boost or they have to ensure that the client has the right version, you could just say that you would use "bcp" tool. BCP is a boost tool, used to copy all the boost dependent code direct to your application, so, your application would use only the boost files that uses.

If he says that boost would take a long way to learn, you could say that boost would save a lot of time avoiding you to reinvent the wheel. And boost is really dificult to use in wrong way, so, it forces the code quality to be good.

I would probably not ask if I can use boost, I would just simple use it. I did that a lot of times, and people that I knew that would be against it, liked it afterwards, first because they could understand the code, and the quality was high because of the usage of boost unit tests, and there was nearly none bugs.

But, in your case your boss already said NO. He probably doesn't know how to program, but you could try to make a deal, like, use only boost libraries that are in TR1, and not using the boost namespace, using the std::tr1 namespace instead. It will be in next C++ standard anyway. And If he says no, you could simple use BCP, to copy the headers to your application directory, and use as std::tr1 in your code, and tell him that you are using only the boost tr1 implementation, and if he doesn't like, he could buy a tr1, or even better, ask him to let you develop all the classes in tr1, it would take a long time to you, but for sure, would be a lot fun :)

You learned a lesson, don't ASK, USE IT. People are usual afraid of what they don't know.

(3) "don't ASK, USE IT" - unless you work for a company that literally will fire you for introducing dependencies whose licenses haven't been cleared by the lawyers. The Boost license is very permissive, but "some unknown license that we haven't even read" is potentially terrifying to lawyers, customers, investors, those kinds of people. Of course, you might be able to ask the lawyers without troubling your own managers :-) Or you could write some code to demonstrate how much better things are with Boost, prove your case, get permission, then check it in. - Steve Jessop
[+18] [2009-08-04 08:01:50] GManNickG

He's probably suffering from "Not Invented Here" syndrome. The moment he begins reinventing something in boost, point it out to him.

(2) I once began reinventing Boost.FilterIterator in the same way they did, but needed some iterator stuff, so I looked at the boost iterator's and discovered FilterIterator... - tstenner
[+11] [2009-08-04 10:43:43] Drealmer
  • It's already hard to find people who understand the STL and can use it properly, people with boost knowledge are even harder to find. Recruiting might get complicated and getting new hires up to speed might take more time.
  • For some people boost might look like a silver bullet, you might end up with unnecessary complexity.
  • If you work in a cross-platform environment, you might discover various quirks of your compilers that turn template-heavy code into a nightmare.

(13) I don't think I would trust a C++ programmer, who does not understand using standard constructs from the STL (vector, string, iterators...), and standard constructs from boost (smart pointers). - Johan
(2) If you work in a cross-platform environment, and a certain platform does not support Boost, I think that platform is not worth supporting. Exceptions could be embedded and real-time systems... - Pietro… platforms like Android and iOS for example? - Mσᶎ
[+11] [2010-11-09 00:05:55] nus

Because it just kills the concept of a lightweight portable library.

When writing code for an app that I will just compile, I readily use boost. However when writing library code, I avoid it.

Every user who will have to compile your code or use your library will have to download and build boost. It can be worth it if you write something like spririt json [1], but if you do that just in order to have boost::shared_ptr or BOOST_FOREACH, I doubt you will have many users.

Before you upvote this, you might want to read the comments by Georg below who refutes most of what I said just above.

wait, I think I need to take that back. I tried extracting the dependencies of boost/static_assert.hpp, both because it would be useful for me to have that and because I thought this must be one of those small only header libraries you speak of. Well, that results in extracting 70 files. It just feels wrong somehow to have to add 70 files to your lib just in order to do 1 static assert. On the other side admitted the size of those file together is only 388KB, which might be well acceptable for something you wouldn't easily handcraft.


You can always extract parts of Boost and deploy them with your project. If needed add a build-flag for using the users Boost installation. Doing your own shared_ptr implementation probably looks much worse. - Georg Fritzsche
@Georg That is interesting. Is it documented somewhere? I had the impression that the boost build system is quite complex and that it might be difficult to extract some parts out of it. - nus
(2) Most of Boost is header-only anyway (like the smart pointers and foreach), so you just need to extract the headers required and not build anything. To deal with more complicated extractions you can use bcp. - Georg Fritzsche
@Georg Thanks for pointing that out. I'll probably use that sometimes. What does bcp stand for, because that link is down and google doesn't show much. - nus
Oops, working link. - Georg Fritzsche
Regarding your update: a) Bcp sometimes seems to pull a bit much and you can do better with manual extraction (especially if you only mind specific platforms, remember the amount of work-arounds for obscure platforms, ...). b) 70 files aren't that many: Many parts of Boost are highly reused and thus split into seperate files. Also the meta-programming parts in C++ often can't be expressed very succinctly, so you either end up with one very long/unreadable header or you do what every good book says... - Georg Fritzsche
[+10] [2009-08-04 08:11:58] Fuzz

Adding another dependancy to your build chain can sometimes be unattractive.

It means that for distribution of your application, you have to bundle Boost, or ensure that the user has the right version already installed.

I have come along to project that have been used with Boost that were designed to work with Linux and Windows, but found there was a lot of work with pointing the build system in all the right places to get everything to work the way the user intended.

At the end of the day it is up to the end developer to make the installation of the application as easy as possible for the end user, and if the installation step means "getting the boost build right first" you are putting extra work on to the end user that they really dont want to deal with!

That said, things like smart pointers are becoming quite important!

(18) Most of boost is purely in headers, the rest can be statically linked. - Martin Beckett
[+8] [2009-08-04 08:09:09] Adriaan

Every project needs to make tradeoffs. Boost is just one of them. You use Boost when it helps you to deliver functionality faster. But when your project is not allowed to use templates (i.e. restrictive subset of C++ is used. Or if a license agreement is incompatible with your project. Or if you have already got libraries which cover much of the functionality there may be no advantage in migrating.

I think therefore that it is a non-argument to name a project that does not use it, unless you can find the rationale of that project for not using it, and find that it also applies to your project. Better find projects that do use it and look for experiences and check how this maps to your project.

There are many success stories for Boost. I suggest you collect some which can be compared with your project. If boost solves problems for your project, then you can ask your collegue on how he would like to tackle them. Agree on finding the best solutions for your project rather than fight on which technology to use.

(1) Can I ask why you say that MISRA C++ is anti-templates? If anything, I would argue that MISRA C++ is more pro templates than other coding standards in that it has added rules to help avoid some common template problems. - Richard Corden
I've corrected my answer with a more generic rationale for the example at hand. I've got extensive experience with Misra/C but limited with Misra/C++. Many of the projects I've worked with have very tight resource budget constraints and hence little room for rich C++ constructions. You're right that this does not imply that Misra/C++ is against it. - Adriaan
(1) Could you please give an example of how the boost license could be incompatible with ones project? I just cannot think of one. - vobject
Although I think the boost license is very reasonable, there can always be issues with a project. My statement was intended rather generic; I've found that organisations are often not compatible with 'free' software licenses. For instance if the organisation demands a 3rd party with warranty (can be solved, but this is not trivial). But it can also be that an organisation has a very strong 'not invented here' climate... 'incompatible' can mean many things... - Adriaan
[+5] [2009-08-04 08:06:53] anon

There are several possible reasons:

  • Boost is not standardised - this is important for people writing portable code
  • If you write FOSS, you need to distribute Boost libraries with your application, or attempt to explain to your users what they need to do to get and install them
  • It may not have anything you particularly need - my own code doesn't
  • You might think it is gigantic and bloated, and that many of the things it provides are misguided

BTW, I'm not saying these are my reasons (not all of them at least) but they are some reasons.

(12) * Boost is a cross platform library supporting many platforms, what is the problem here? * Most of boost is header only library and hence need no end user installing. For the rest, it probably can't be implemented in headers only so you'd need to link it either way. You can build boost to be statically linked to afford having to distrubute shared libraries. * * Boost is a collection of libraries, you only use what you need. - KTC
[+4] [2009-08-04 08:16:49] piotr

Your compiler may not be supported by boost, your schedule might not allow the effort to make boost build with that compiler environment.

It is not trivial to use boost in other than the supported platforms/compilers.

Also although the compiler is supported the standard library might not be. For instance the sun studio compiler is supported but its standard library is pants and some components do not work because some of the constructors to std::vector are missing or some algorithms have extra parameters. Having said that I make use of boost when ever I can, but I am aware that it can cause problems porting to new platforms. - iain
[+4] [2009-08-05 13:27:56] MachinShin

I work for a large Financial Services firm and the reason we don't use Boost is due to licensing issues. We guarantee 100% liability to all our clients (for instance, in cases like the potential a few years ago of Novell users being sued by MS because of Linux) and the license of Boost isn't sufficiently clear to our legal team. I've also been told by the developer/legal contact that there are some legal grey areas with Boost, for instance, some headers have company-specific disclaimers and legal verbiage. So the question becomes raised 'which license applies, and what does that disclaimer mean?'.

Nevertheless, the question of "why not Boost" gets raised to our legal-R&D team a couple times a year

Which financial services firm? Go on, name and shame! - Chris Huang-Leaver
Licensing issues? Boost has the most straightforward license around. Where are the "legal grey areas" in boost? Which libraries have questionable legal verbiage? - David Nehme
(7) BOOST is completely free and open. Its effectively public domain, its far more open than say GPL. That said if you have any proof of these claims "company-specific disclaimers and legal verbiage" please post them on the BOOST developer mailing list so they can be removed, as this was the case 6-7 years ago and since then all the files have been cleaned up with the new license. - Matthieu N.
(1) Boost have written this It explains what the licence does, plus the lawyer who wrote does a spot of FAQing - Chris Huang-Leaver
[+3] [2009-08-12 12:57:42] Chris Huang-Leaver

We run our system on Solaris 10, with lots of dynamic libraries all built with Sun's compiler. With Sun Studio you can only run Boost if you are using STL Port 4 or later, which in our case would mean recompiling all our libraries and everything that was linked to them, i.e. everything. I think that's a small price to pay to use such a fantastic resource, but others disagree.

Have Reuters started shipping RFA and RMS with STLPort? Your profile says you work at TR. - bruce.banner
You might say that, I couldn't possibly comment ;-) - Chris Huang-Leaver