The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store.
Not true, there are no-throw versions of std::new. In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this. One of the first thing that comes up when a mixed language C/C++ project uses a C++ library is: Does this library throw exceptions? Generally and unfortunately, if the answer is yes, that library will be ignored out of hand.
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.
Boost.Format provides what you want. There's relatively little output from the various libraries, so I don't see where this issue arises in real use cases.
This is a real issue. Boost.format is not a replacement for Printf -- they have different syntaxes. Printf style arguments are the prevailing api style. No one is asking for printf style arguments to be replaced. Why replace something that is the standard and works just fine. This is just symptomatic of my larger point that boost is a research project and not relevent to day to day C/C++ programmers. Why replace something that is universally adopted and works just fine. If boost developers want to create an alternative to printf, that is fine. However, it should be just that, an alternative, not a replacement. Printf style api's are easy to implement. There are reasons not to do them.
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.
The dependencies aren't confusing so much as complex. Would you have each library in Boost reinvent rather than reuse other Boost functionality? Isn't that the point of Boost libraries: reuse functionality written by others?
It can absolutely be an issue if one of the dependent libraries throws exceptions for example. Because boost does not have clearly stated policy about exceptions, who knows what changes occured between versions.
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.
I don't see why dependencies among Boost libraries would lead to picking and choosing which are approved.
This is a key issue. Because boost does not allow you to choose only select libraries, you must use all of boost. And because there are no clear guidlines regarding exceptions and policies, it can be scarey to know what exactly is going on. Project prefer safety to features. If the risks of using boost are unclear without is clear policies about exceptions and depencies, its easier to not use boost at all so its abandoned in its entirety, no matter how much you want to use a specific library.