learning Boost

[BubbaT]

What is the best way to pick up Boost?
Thanks
BubbaT

 

[Gennaro Prota]

What is the best way to pick up Boost?
Thanks

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.

 

[James Kanze]

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; I'd
actually trust something from Boost more than I would extensions
and additional libraries from some compilers.

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. 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.)

 

[Gennaro Prota]

>
>
> 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.

 

[Roland Pibinger]

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.

This is probably by design. Boost abhors virtual functions calls and
OOP in general.

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.

The myth that surrounds Boost mostly stems from the intimidating
complexity they produce with C++ templates: "it's so complex therefore
it must be good". Library design for real-world applications is, first
and foremost, about usability. From the beginning Boost tried to push
the limits of 'template programming' (not C++ programming) but never
cared about ease of use and real-world applicability.

 

[Hendrik Schober]

]

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.

The myth that surrounds Boost mostly stems from the intimidating
complexity they produce with C++ templates: "it's so complex therefore
it must be good". Library design for real-world applications is, first
and foremost, about usability. From the beginning Boost tried to push
the limits of 'template programming' (not C++ programming) but never
cared about ease of use and real-world applicability.

My POV is that boost code is hard to read because it works with
so many different compilers. Whenever I look at the code my eyes
water because there are almost more workarounds than actual code...

Oh, and I think, while application code has to be only as good
as necessary, library code has to be as good as possible. For me,
a very important measurement for code quality is the question
how many problems it catches at compile-time. And there, boost
code often shines.

Schobi

 

[coal]

]

  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.

The myth that surrounds Boost mostly stems from the intimidating
complexity they produce with C++ templates: "it's so complex therefore
it must be good". Library design for real-world applications is, first
and foremost, about usability. From the beginning Boost tried to push
the limits of 'template programming' (not C++ programming) but never
cared about ease of use and real-world applicability.

  My POV is that boost code is hard to read because it works with
  so many different compilers. Whenever I look at the code my eyes
  water because there are almost more workarounds than actual code...

Yes, this is a problem for Boost, but I think it can be addressed
with an on line C++ compiler that produces fully instantiated
source code. If the output from that compiler is correct, then
it's up to the (simpler) platform specific compilers to accept it.
Such an approach would result in Boost being able to clean up some
of the code. Compiler vendors are slow to move in this direction
though. They tried to milk the status quo too much. I've been
saying this for a number of years. Meanwhile the boost authors
struggle to keep their libraries building on a large number of
configurations.

For me,
  a very important measurement for code quality is the question
  how many problems it catches at compile-time. And there, boost
  code often shines.

Good point.


Brian Wood
http://www.webEbenezer.net