Over the past years, every project that I have been involved with has tried and then either abandoned boost or highly restricted its use. As a long time boost user, I can't tell you how much debate we've had about this. I want boost to succeed, grow and be successful. Its sad. As someone who has used boost from the beginning, and has taken far more than I have given, here are some of my observations. Many of the reasons don't have specifically to do with boost, but more have to do with a preference for one programming style versus another. I have identified 5 key issues about why boost was abandoned. 1) Boost uses exceptions. 2) Printf versus Iostream. 3) Dependencies. 4) Research Projects 5) Macros 1) Boost uses exceptions. This issue is best illustrated when you want to just do something as simple as converting a "string" to an "int". boost::numeric_cast throws an exception, which forces you to wrap it into a try-catch block. The seemingly trivial issue of how to handle exceptions causes endless grief. It seems that developers still prefer "C" style casts. The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required. int value = 0; try {value = boost::numeric_cast<int>("3.00");}catch (...){} versus int value = atoi("3.00"); I think the lesson is that there is no correct answer here. As most "C++" projects use some "C" libraries, you will need to be flexible in your approach to exception handling. A pure "C++" approach of try-catch blocks is not practical. As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code. Many developers will simply ignore this issue and end up with lots of code that is not exception safe. Small issue, but is undoubtably a source of a huge amount of problems. 2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style. This issue has been the source of many hours of needless debate. Pure C++ developers seem to have a aversion to "printf" style arguments. As there are very few pure C++ projects (if any), I dont hear about this as much as I once did. Most C/C++ developers prefer a printf style api. Boost needs to start providing printf style api's. Boost needs to be more practical. By not also providing printf style api's, boost is not meeting the needs of developers. Iostream may be preferable for purely academic reasons, but for practical reason, "printf" is the api style that is universally adopted. Is it boosts goal to meet only the needs of a small subset of its c++ users? If that is the goal, than it needs be clearly stated as such. As most developers have adopted a combined C/C++ style of development, a pure academic C++ style syntax is not practical for every day use. Boost needs to look at what the popular api styles are and adopt them and not be so dogamtic about its style of so-called pure "C++". 3) Dependencies. Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't. What does this mean? Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't. Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all. This issue may seem trivial, but it is the cause endless hourse of grief. It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost. For obvious reasons, project leads prefer to have control over which libraries are used in a given project. Few will just give blanket approval to all boost libraries. The way boost was developed makes this practically impossible. Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community. Currently, boost provides the best place to do that, but it needs to be honest with its users. 4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible. This is universally considered a good thing and it is always interesting to see what the best and brightest are up too. Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs. Experience proves otherwise. The practical needs of large scale active projects are in conflict. Boost is very dogmatic and encourages a particalular style of development, which is very template based. In the right hands, a heavy templated based project can work. In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design. It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear. That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly. 5) Macros. Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable. I know there are practical reasons to use them. The main reason being compiler inadequacies. However, many developers question the value of a cutting-edge template library that is full of macros. What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath? What is the practical value of a library that can only be maintained by the original developer(s)? This issue has surprised many, but has comes up often. If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries. Tom Brinkman