Gennaro Prota wrote:
I'm sure there are many ways Boost can be improved, please focus on specific issues, and one would hope their solutions
Which is the "patches are welcome", "if you notice anything wrong you can fix it" attitude I mentioned earlier. Don't fool yourself into believing that with enough time and contributions all problems will eventually get fixed. It never happens. (If nothing else: new stuff gets added much faster than existing things fixed).
Believe me, I'm speaking in cognition of the facts: I'm not new to Boost and its code, and I find issues with it (ranging from minor to very sever ones, including undefined behavior) every time I look at anything. No strive.
Things are not perfect, and Boost is no exception and noone said it is. And, I'm sure you know it, commercial software is no exception either. The only thing you can do about it is to make it better. Spreading depression won't make you any good. So, being a bit more constructive, IMO, is the right thing to be busy with. If you have a specific problem in mind, go ahead and create a Trac ticket. And yes, "patches are welcome", really.
That's not very different from other free software. The peculiarity, actually, is elsewhere: if anything can be complicated, that's how Boost does it. If it can be overgeneralized, that's what boost does (never used a function with 15 arguments? doesn't matter... let's drag the whole pp-lib in, so that the user can choose to have up to 8589934592 of them). If it can be meta-programmed, or use conditional compilation... you got it. So, I'd bet that in addition to the obvious ones, a whole lot of very hard to spot issues lie in the Boost code. Hoare comes to mind:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. [...]
Boost comprises generic solutions for a wide variety of problems, so it has to be flexible enough. This is the key feature that I personally like about Boost, and it proved to be essential for me many many times. But if you want a local solution for your particular task, which may be more optimal in some ways than what Boost provides, you are free to write one.
Just to add a little example here, I grepped for the first thing that occurred to me: "LocalFree". Because because I remembered having seen many snippets of the kind
<code which can throw an exception> ::LocalFree( p ) ;
(would Coverity find that?). Well, I immediately ended up in a file named win32_api.hpp which has *a list of declarations of Windows API functions*, conditioned on BOOST_USE_WINDOWS_H. Terrific. A manner to have an undefined behavior, and condition it on a "user preference", I had never thought of.
If you had also searched Trac tickets related to windows.h inclusion in headers, I'm sure you'd have found quite a few problems with it. So this particular twist in the header has a good ground. Same with many other twists that you may find in the code.