Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > learning Boost

Reply
Thread Tools

learning Boost

 
 
BubbaT
Guest
Posts: n/a
 
      09-27-2008
What is the best way to pick up Boost?
Thanks
BubbaT
 
Reply With Quote
 
 
 
 
Gennaro Prota
Guest
Posts: n/a
 
      09-27-2008
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.
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      09-27-2008
On Sep 27, 2:35 pm, Gennaro Prota <gennaro/(E-Mail Removed)> 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:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Gennaro Prota
Guest
Posts: n/a
 
      09-28-2008
James Kanze wrote:
> On Sep 27, 2:35 pm, Gennaro Prota <gennaro/(E-Mail Removed)> 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.
 
Reply With Quote
 
Roland Pibinger
Guest
Posts: n/a
 
      09-28-2008
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
 
Reply With Quote
 
Hendrik Schober
Guest
Posts: n/a
 
      09-28-2008
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
 
Reply With Quote
 
coal@mailvault.com
Guest
Posts: n/a
 
      09-29-2008
On Sep 28, 3:06*pm, Hendrik Schober <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Boost::any and boost::lambda with std::find_if Misiu C++ 3 01-31-2007 05:46 PM
#include <boost/shared_ptr.hpp> or #include "boost/shared_ptr.hpp"? Colin Caughie C++ 1 08-29-2006 02:19 PM
Problems mixing boost::lambda::bind and boost::shared_ptr.. Toby Bradshaw C++ 6 06-02-2006 04:12 PM
Any Boost Experts out there for Boost.Regex? Richard Latter C++ 2 05-17-2004 03:12 PM
Boost + Python C/API: Mixing python return types with boost return types Steve Knight Python 2 10-10-2003 10:11 AM



Advertisments