learning Boost

[BubbaT]

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

[utab]

Re: learning Boost

On Sat, 27 Sep 2008 02:38:33 -0500, BubbaT wrote:

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

See

http://www.amazon.com/Beyond-Standard-Library-Introduction-Boost/

dp/0321133544

[Gennaro Prota]

Re: learning Boost

BubbaT wrote:

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.

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

[James Kanze]

Re: learning Boost

On Sep 27, 2:35 pm, Gennaro Prota <gennaro/pr...@yahoo.com wrote:

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

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Gennaro Prota]

Re: learning Boost

James Kanze wrote:

On Sep 27, 2:35 pm, Gennaro Prota <gennaro/pr...@yahoo.com wrote:

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

[Roland Pibinger]

Re: learning Boost

On Sun, 28 Sep 2008 13:39:15 +0200, Gennaro Prota wrote:

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.


--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Hendrik Schober]

Re: learning Boost

Roland Pibinger wrote:

On Sun, 28 Sep 2008 13:39:15 +0200, Gennaro Prota wrote:
[...]

> 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@mailvault.com]

Re: learning Boost

On Sep 28, 3:06 pm, Hendrik Schober <spamt...@gmx.d ewrote:

Roland Pibinger wrote:

On Sun, 28 Sep 2008 13:39:15 +0200, Gennaro Prota wrote:
[...]

  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