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.

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.

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! ;)

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.

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

• 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.

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.

update
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.

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!

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.

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.

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.

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

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.