{I posted this yesterday; apparently it got lost} John Maddock wrote:
Perhaps you shouldbt use or follow boost since it appears so fraught with ill design and poor quality. I personally have found it otherwise.
I'm afraid that if I wanted to really reply to this I'd have to question your professional skills. Significantly. Which I don't want to do.
Guys, I'm not pointing any fingers, but please don't allow this to degenerate into a flame war.
That's why I said "I don't want to".
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. 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. [...] 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. -- Genny