----- Original Message ----- From: "Tom Brinkman" <reportbase2007@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, March 23, 2010 10:43 PM Subject: Re: [boost] 5 Observations - My experience with the boost libraries
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.
Why?
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.
No body forbids you to use printf.
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.
Just don't use it if you don't like it.
If boost developers want to create an alternative to printf, that is fine. However, it should be just that, an alternative, not a replacement.
It is not a replacement but an alternative.
Printf style api's are easy to implement. There are reasons not to do them.
Have you some examples of Boost library API that should provide a printf like function?
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.
Could you propose an alternative that solve this issue?
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.
Ther is bcp.
And because there are no clear guidlines regarding exceptions and policies, it can be scarey to know what exactly is going on.
Please make a proposal.
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.
It is a shame people abandon Boost without trying before to improve it. Best, Vicente