James Kanze wrote:
On Sep 27, 2:35 pm, Gennaro Prota <gennaro/pr...@yahoo.comwrote:
>BubbaT wrote:
>>What is the best way to pick up Boost?
>By using good sense. Try filtering useful stuff from "mental
experiments", and never assume anything (be it interface or
implementation) to be high-quality just because it is in
Boost.
To a certain degree, you can never assume quality, but Boost
seems to be significantly better than most in this regard;
That's a widespread opinion. I'm not sure where it comes from. What I
can say is that when I go looking at the code I rarely see anything
significantly better than other libraries. Perhaps the errors are just
less trivial. (Perhaps; it's no rocket science to avoid unnamed
namespaces in include files either, for instance). Quality depends for
most part on the author ("formal" reviews don't help: if no competent
person is interested in a proposed library you can't expect any
improvement, and all the flaws will happily remain).
[...]
What you probably can't assume is usefulness. Some parts of
Boost are very useful: you really should be using boost::regex
and boost::array if at all possible.
I don't. The code underlying most Boost components is a mess...
honestly, I avoid it like the plague. Reliability must be IMHO the first
quality in software. As I mentioned to a colleague a few months ago, I
think the only significant contribution of Boost are interfaces (when
they are valid; I've never made a mystery of the fact that e.g. I
consider dynamic_bitset is an experiment that failed).
Also, be careful: something you've used in the past may well have been
completely screwed up in subsequent releases; there's always someone who
wants to "improve"; see what lexical_cast has become, for instance (I
know that you don't use it, but just have a look). Boost.Operators,
unless it has been cleaned up recently, is another example of
unmaintainable monster. Note that changes made after acceptance are
hardly reviewed, so even a well-reviewed library may degrade beyond any
expectation once it is included in the collection.
Others less: I certainly
wouldn't spend a lot of time learning boost::crc unless I really
had to calculate CRC's. (In that particular case, I think my
class has a better designed interface. But that's not really
the point---you shouldn't waste time learning it, either, unless
you need CRC's for something. Most code doesn't.)
OTOH, all code needs testing. And Boost.Testing is one of the most
unreliable parts :-) CRC's, as you say, aren't something one uses
everyday; but iostreams... I'm still convinced of what I wrote on
c++.moderated a while ago:
I just had a quick look long ago [to Boost.Iostreams] and in the
stream class template there was neither virtual inheritance from the
streambuf nor a call to basic_ios::init() from the constructor. It
might have been fixed now, but certainly I saw the error after
acceptance of the library (so, after the review) and it is a 101
error for iostream programming. The reason why I don't recommend it,
regardless of a possible fix --and do not recommend most of boost,
anymore -- is that with the exception of a few parts the whole
collection has become an enormous, unmanageable bloat (unreadable
meta-programmed-to-perversion code and absolutely unnecessary
dependencies being probably the worst evils). I know that it has
still a high reputation but that's basically a result of the past,
IMHO; try keeping an eye at the regression reports and you'll see
that they are pretty much random number generators from a gigantic
house of cards.
--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.