learning Boost

Discussion in 'C++' started by BubbaT, Sep 27, 2008.

  1. BubbaT

    BubbaT Guest

    What is the best way to pick up Boost?
    Thanks
    BubbaT
    BubbaT, Sep 27, 2008
    #1
    1. Advertising

  2. 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.
    Gennaro Prota, Sep 27, 2008
    #2
    1. Advertising

  3. BubbaT

    James Kanze Guest

    On Sep 27, 2:35 pm, Gennaro Prota <gennaro/> 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:
    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
    James Kanze, Sep 27, 2008
    #3
  4. James Kanze wrote:
    > On Sep 27, 2:35 pm, Gennaro Prota <gennaro/> 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.
    Gennaro Prota, Sep 28, 2008
    #4
  5. 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
    Roland Pibinger, Sep 28, 2008
    #5
  6. 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
    Hendrik Schober, Sep 28, 2008
    #6
  7. BubbaT

    Guest

    On Sep 28, 3:06 pm, Hendrik Schober <> 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
    , Sep 29, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Richard Latter
    Replies:
    2
    Views:
    2,888
    Julie
    May 17, 2004
  2. Steve Knight
    Replies:
    2
    Views:
    745
    Steve Knight
    Oct 10, 2003
  3. Toby Bradshaw
    Replies:
    6
    Views:
    1,727
    Kai-Uwe Bux
    Jun 2, 2006
  4. Colin Caughie
    Replies:
    1
    Views:
    696
    Shooting
    Aug 29, 2006
  5. Misiu
    Replies:
    3
    Views:
    2,354
    Misiu
    Jan 31, 2007
Loading...

Share This Page