Re: boost usage

Discussion in 'C++' started by DeMarcus, Jun 9, 2010.

  1. DeMarcus

    DeMarcus Guest

    On 2010-06-07 21:25, Lynn McGuire wrote:
    > I was wondering how many people here use boost in their c++
    > implementations ?
    >


    I'm very reluctant to use third party libraries in my code for various
    reasons like

    * licensing
    * quality (documentation, easy to use, clean, etc.)
    * future maintenance
    * portability
    * replaceability

    Right now, the only library I use in my code is boost since I find it
    professional and fulfills most of the criteria above. One may wonder
    what library on earth is replaceable in an easy manner, but I added that
    point since quite many of boost's features go straight into the C++0x
    standard. Knowing that your library features in the future may be easy
    replaceable with the C++ standard is comforting to know.

    If there is any library that you would use in your code, boost would
    probably be the most professional. (You can also check out Loki by
    Alexandrescu)
     
    DeMarcus, Jun 9, 2010
    #1
    1. Advertising

  2. On Jun 9, 6:08 pm, DeMarcus <> wrote:
    > On 2010-06-07 21:25, Lynn McGuire wrote:
    >
    > > I was wondering how many people here use boost in their c++
    > > implementations ?

    >
    > I'm very reluctant to use third party libraries in my code for various
    > reasons like
    >
    > * licensing
    > * quality (documentation, easy to use, clean, etc.)
    > * future maintenance
    > * portability
    > * replaceability
    >
    > Right now, the only library I use in my code is boost since I find it
    > professional and fulfills most of the criteria above. One may wonder
    > what library on earth is replaceable in an easy manner, but I added that
    > point since quite many of boost's features go straight into the C++0x
    > standard. Knowing that your library features in the future may be easy
    > replaceable with the C++ standard is comforting to know.
    >
    > If there is any library that you would use in your code, boost would
    > probably be the most professional. (You can also check out Loki by
    > Alexandrescu)


    Once I worked at a shop where there were great reservations to
    bringing Boost in. The two primary objections were:

    1) Having a legacy system (20 years) we already have internal
    alternatives to some of the Boost components we are thinking
    of using such as hash containers, smart pointers, regex, etc.
    Yes Boost is clearly more STL-like and newly hired programmers
    might actually know some of them in advance, but:

    a) if we start adding in the Boost alternatives we will
    have a mixture and that will require learning two libraries
    instead of one and possibly degrade maintenance.

    b) our proprietary solutions have been thoroughly tested
    under OUR conditions and are known to meet OUR requirements.
    While Boost has been thoroughly tested by a large community
    we have no way of knowing whether it has been extensively
    tested under the conditions we are targeting.

    2) Boost is large and diverse library. While there are many
    components we like and certainly would use, there are some
    components that we absolutely do not want used regularly in
    our code. For example we don't want to see the few meta-
    programming aficionados among us spreading MPL code throughout
    "just because they can". While we do have a review process,
    the mere existence of those libraries increases review burden
    and makes it more likely components that are not widely
    understood will be used in our code.

    Ultimately the approach we chose was four-fold:

    1) only a small, carefully selected and approved subset of
    Boost would be installed and only a subset of components
    would be approved for use.

    2) for now, Boost is approved only for new code or refactoring
    as part of implementing new code. In other words, no Boostifying
    solely for the purpose of entering the 21st century of C++.
    If it ain't broke don't "fix" it.

    3) only the approved components were "marketed" to the
    developers. Ie we avoiding even talking about the non-
    approved components unless we were confident the people
    listening would not try to submit them for review ;-)

    4) anyone attempting to use non-approved components would
    get a smack-down ;-)

    The above worked well with the exception of 1) which turned out
    to be a lot of manual work. In addition, the dependencies within
    Boost itself forced us to install some components (especially
    MPL components) that we did not want exposed for common use.

    KHD
     
    Keith H Duggar, Jun 9, 2010
    #2
    1. Advertising

  3. DeMarcus

    DeMarcus Guest

    Keith H Duggar wrote:
    > On Jun 9, 6:08 pm, DeMarcus <> wrote:
    >> On 2010-06-07 21:25, Lynn McGuire wrote:
    >>
    >>> I was wondering how many people here use boost in their c++
    >>> implementations ?

    >> I'm very reluctant to use third party libraries in my code for various
    >> reasons like
    >>
    >> * licensing
    >> * quality (documentation, easy to use, clean, etc.)
    >> * future maintenance
    >> * portability
    >> * replaceability
    >>
    >> Right now, the only library I use in my code is boost since I find it
    >> professional and fulfills most of the criteria above. One may wonder
    >> what library on earth is replaceable in an easy manner, but I added that
    >> point since quite many of boost's features go straight into the C++0x
    >> standard. Knowing that your library features in the future may be easy
    >> replaceable with the C++ standard is comforting to know.
    >>
    >> If there is any library that you would use in your code, boost would
    >> probably be the most professional. (You can also check out Loki by
    >> Alexandrescu)

    >
    > Once I worked at a shop where there were great reservations to
    > bringing Boost in. The two primary objections were:
    >
    > 1) Having a legacy system (20 years) we already have internal
    > alternatives to some of the Boost components we are thinking
    > of using such as hash containers, smart pointers, regex, etc.
    > Yes Boost is clearly more STL-like and newly hired programmers
    > might actually know some of them in advance, but:
    >
    > a) if we start adding in the Boost alternatives we will
    > have a mixture and that will require learning two libraries
    > instead of one and possibly degrade maintenance.
    >


    I agree that mixing makes mess.

    > b) our proprietary solutions have been thoroughly tested
    > under OUR conditions and are known to meet OUR requirements.
    > While Boost has been thoroughly tested by a large community
    > we have no way of knowing whether it has been extensively
    > tested under the conditions we are targeting.
    >


    The problem, as I see it, is that one has to make a design decision when
    starting a new project. The decision is; "how long will this application
    live?". If one can put a budget allowing to rewrite the code from
    scratch when the lifetime is out, new features and libraries can be
    considered. However, it is /very/ hard to make such lifetime decision,
    hence we have to rely on refactoring.

    In that case I find boost a good option since if a new feature shows up
    in the C++ standard it is likely to be similar to the boost version and
    a refactoring may be less hard.

    > 2) Boost is large and diverse library. While there are many
    > components we like and certainly would use, there are some
    > components that we absolutely do not want used regularly in
    > our code. For example we don't want to see the few meta-
    > programming aficionados among us spreading MPL code throughout
    > "just because they can". While we do have a review process,
    > the mere existence of those libraries increases review burden
    > and makes it more likely components that are not widely
    > understood will be used in our code.
    >


    This is also a good point and difficult decision. Shall one start to use
    a new feature before it's been around for a couple of years so one knows
    the pros and cons?


    > Ultimately the approach we chose was four-fold:
    >
    > 1) only a small, carefully selected and approved subset of
    > Boost would be installed and only a subset of components
    > would be approved for use.
    >
    > 2) for now, Boost is approved only for new code or refactoring
    > as part of implementing new code. In other words, no Boostifying
    > solely for the purpose of entering the 21st century of C++.
    > If it ain't broke don't "fix" it.
    >
    > 3) only the approved components were "marketed" to the
    > developers. Ie we avoiding even talking about the non-
    > approved components unless we were confident the people
    > listening would not try to submit them for review ;-)
    >
    > 4) anyone attempting to use non-approved components would
    > get a smack-down ;-)
    >
    > The above worked well with the exception of 1) which turned out
    > to be a lot of manual work. In addition, the dependencies within
    > Boost itself forced us to install some components (especially
    > MPL components) that we did not want exposed for common use.
    >
    > KHD


    All in all; it's tricky with all the design decisions. Right now I'm
    facing the decision what GUI library to use! Which one shall I take?
    Shall I wrap it? What lifespan shall I give the frontend? etc. etc.
     
    DeMarcus, Jun 10, 2010
    #3
  4. On 6/10/2010 8:26 AM, DeMarcus wrote:
    > [..] Right now I'm
    > facing the decision what GUI library to use! Which one shall I take?
    > Shall I wrap it? What lifespan shall I give the frontend? etc. etc.


    <offtopic betterNG="comp.software-eng">
    Not to barge in, but since you mentioned it, two boilerplate answers
    spring to mind. First, do spend time separating UI from the rest of the
    application. Your business logic has to be functional regardless what
    UI drives it. Second, you probably need a wrapper of some kind. Just
    like any other subsystem, UI needs to be tested, and the more you can
    automate that, the better, and wrappers allow hooks to be installed and
    without hooks automated testing is at the mercy of somebody else's tools
    (which as we know can come and go, and they do come buggy, and
    platform-specific, etc. etc.)
    </offtopic>

    Best of luck in your design decisions, they are crucial.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jun 10, 2010
    #4
  5. DeMarcus

    Jeff Flinn Guest

    Keith H Duggar wrote:
    > On Jun 9, 6:08 pm, DeMarcus <> wrote:
    >> On 2010-06-07 21:25, Lynn McGuire wrote:
    >>
    >>> I was wondering how many people here use boost in their c++
    >>> implementations ?

    >> I'm very reluctant to use third party libraries in my code for various
    >> reasons like
    >>
    >> * licensing
    >> * quality (documentation, easy to use, clean, etc.)
    >> * future maintenance
    >> * portability
    >> * replaceability
    >>
    >> Right now, the only library I use in my code is boost since I find it
    >> professional and fulfills most of the criteria above. One may wonder
    >> what library on earth is replaceable in an easy manner, but I added that
    >> point since quite many of boost's features go straight into the C++0x
    >> standard. Knowing that your library features in the future may be easy
    >> replaceable with the C++ standard is comforting to know.
    >>
    >> If there is any library that you would use in your code, boost would
    >> probably be the most professional. (You can also check out Loki by
    >> Alexandrescu)

    >
    > Once I worked at a shop where there were great reservations to
    > bringing Boost in. The two primary objections were:
    >
    > 1) Having a legacy system (20 years) we already have internal
    > alternatives to some of the Boost components we are thinking
    > of using such as hash containers, smart pointers, regex, etc.
    > Yes Boost is clearly more STL-like and newly hired programmers
    > might actually know some of them in advance, but:
    >
    > a) if we start adding in the Boost alternatives we will
    > have a mixture and that will require learning two libraries
    > instead of one and possibly degrade maintenance.
    >
    > b) our proprietary solutions have been thoroughly tested
    > under OUR conditions and are known to meet OUR requirements.
    > While Boost has been thoroughly tested by a large community
    > we have no way of knowing whether it has been extensively
    > tested under the conditions we are targeting.


    By making your proprietary code simply forward to the boost or std
    equivalents, you get your existing test coverage plus that of boost and
    your standard library vendor. You can then migrate to boost/std as you
    touch areas of code using them.

    Jeff
     
    Jeff Flinn, Jun 10, 2010
    #5
  6. DeMarcus

    Jorgen Grahn Guest

    On Wed, 2010-06-09, DeMarcus wrote:
    > On 2010-06-07 21:25, Lynn McGuire wrote:
    >> I was wondering how many people here use boost in their c++
    >> implementations ?
    >>

    >
    > I'm very reluctant to use third party libraries in my code for various
    > reasons like
    >
    > * licensing
    > * quality (documentation, easy to use, clean, etc.)
    > * future maintenance
    > * portability
    > * replaceability
    >
    > Right now, the only library I use in my code is boost since I find it
    > professional and fulfills most of the criteria above.


    In a way I can understand that. But:

    Something people often forget when talking "libraries": special-purpose
    libraries. For example, I target Unix exclusively. If I need support
    for handling PNG images or ZLIB compression, I'll do what everyone
    else does and use libpng and zlib, respecively.

    Although these are definitely third-party, noone in his sane mind
    would say "to hell with those, I'll use my own implementation, which
    will be ready in a few years".

    > One may wonder
    > what library on earth is replaceable in an easy manner, but I added that
    > point since quite many of boost's features go straight into the C++0x
    > standard. Knowing that your library features in the future may be easy
    > replaceable with the C++ standard is comforting to know.


    So you added a criterion because you knew only Boost met it?

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jun 10, 2010
    #6
  7. DeMarcus

    DeMarcus Guest

    >> I'm very reluctant to use third party libraries in my code for various
    >> reasons like
    >>
    >> * licensing
    >> * quality (documentation, easy to use, clean, etc.)
    >> * future maintenance
    >> * portability
    >> * replaceability
    >>


    [...]

    >> One may wonder
    >> what library on earth is replaceable in an easy manner, but I added that
    >> point since quite many of boost's features go straight into the C++0x
    >> standard. Knowing that your library features in the future may be easy
    >> replaceable with the C++ standard is comforting to know.

    >
    > So you added a criterion because you knew only Boost met it?
    >
    > /Jorgen
    >


    No, and yes in a way. I'm very reluctant to use proprietary code, no
    matter how good it is, if I can't replace it in an easy manner. Boost is
    free /and/ replaceable with new features in C++0x.

    The best solution, with for instance GUI libraries, would be to have the
    interface non-proprietary and free. Then I would have no problem paying
    for implementations of that interface as long as I can just switch a
    file when I want to change the implementation.

    Therefore, open standardized interfaces and implementation
    replaceability is the way to go for proprietary libraries in the future!
     
    DeMarcus, Jun 13, 2010
    #7
  8. DeMarcus

    Brian Guest

    On Jun 13, 10:45 am, DeMarcus <> wrote:
    > >> I'm very reluctant to use third party libraries in my code for various
    > >> reasons like

    >
    > >> * licensing
    > >> * quality (documentation, easy to use, clean, etc.)
    > >> * future maintenance
    > >> * portability
    > >> * replaceability

    >
    > [...]
    >
    > >> One may wonder
    > >> what library on earth is replaceable in an easy manner, but I added that
    > >> point since quite many of boost's features go straight into the C++0x
    > >> standard. Knowing that your library features in the future may be easy
    > >> replaceable with the C++ standard is comforting to know.

    >
    > > So you added a criterion because you knew only Boost met it?

    >
    > > /Jorgen

    >
    > No, and yes in a way. I'm very reluctant to use proprietary code, no
    > matter how good it is, if I can't replace it in an easy manner.


    Many companies are losing control of their operations --
    BP is a good example. Three months ago BP wouldn't have
    blinked an eye at spending millions to compensate for
    choosing a low-quality approach that appeared to give them
    more control. Now that their future is in jeopardy,
    perhaps their decision-making process will improve.


    Brian Wood
    http://webEbenezer.net
    (651) 251-9384

    "Pride goeth before destruction, and an haughty spirit
    before a fall." Proverbs 16:18
     
    Brian, Jun 14, 2010
    #8
  9. DeMarcus

    Öö Tiib Guest

    On Jun 14, 2:53 am, Brian <> wrote:
    > On Jun 13, 10:45 am, DeMarcus <> wrote:
    >
    > > >> One may wonder
    > > >> what library on earth is replaceable in an easy manner, but I added that
    > > >> point since quite many of boost's features go straight into the C++0x
    > > >> standard. Knowing that your library features in the future may be easy
    > > >> replaceable with the C++ standard is comforting to know.
    > > > So you added a criterion because you knew only Boost met it?

    > > No, and yes in a way. I'm very reluctant to use proprietary code, no
    > > matter how good it is, if I can't replace it in an easy manner.

    >
    > Many companies are losing control of their operations --
    > BP is a good example.  Three months ago BP wouldn't have
    > blinked an eye at spending millions to compensate for
    > choosing a low-quality approach that appeared to give them
    > more control.  Now that their future is in jeopardy,
    > perhaps their decision-making process will improve.


    What is BP? British Petroleum? What it has to do with boost (or other
    libs) usage when developing software?
     
    Öö Tiib, Jun 14, 2010
    #9
  10. DeMarcus

    Brian Wood Guest

    On Jun 14, 5:18 pm, Öö Tiib <> wrote:
    > On Jun 14, 2:53 am, Brian <> wrote:
    >
    >
    > > Many companies are losing control of their operations --
    > > BP is a good example.  Three months ago BP wouldn't have
    > > blinked an eye at spending millions to compensate for
    > > choosing a low-quality approach that appeared to give them
    > > more control.  Now that their future is in jeopardy,
    > > perhaps their decision-making process will improve.

    >
    > What is BP? British Petroleum?


    Yes, British Petroleum.

    Brian Wood
     
    Brian Wood, Jun 15, 2010
    #10
  11. DeMarcus

    Öö Tiib Guest

    On Jun 15, 4:04 pm, "Eric J. Holtman" <> wrote:
    > Brian Wood <> wrote in news:275eceac-42c1-4eb0-8847-
    > :
    >
    >
    >
    > >> What is BP? British Petroleum?

    >
    > > Yes, British Petroleum.

    >
    > BP hasn't been British Petroleum for sme time.
    >
    > It's just "BP".


    Two letter acronyms are good signal of closing downfall. People want
    to get done with that nonsense quick even when naming it. When there
    is "General Motors" it makes sense. When there is "GM", it is nonsense
    that no one cares about and it will be soon flushed by history. So ...
    if you care, use terms that make sense (like "Best Practice") and do
    not tell about soon-to-be-ruins (like that "BP"). ;)
     
    Öö Tiib, Jun 15, 2010
    #11
  12. DeMarcus

    red floyd Guest

    On Jun 15, 7:33 am, Öö Tiib <> wrote:

    > Two letter acronyms are good signal of closing downfall. People want
    > to get done with that nonsense quick even when naming it. When there
    > is "General Motors" it makes sense. When there is "GM", it is nonsense
    > that no one cares about and it will be soon flushed by history. So ...
    > if you care, use terms that make sense (like "Best Practice") and do
    > not tell about soon-to-be-ruins (like that "BP"). ;)


    What about (pre-Carly) HP? They were known simply as HP for years,
    and were considered THE BEST equipment until Carly decided she'd
    rather
    get rich selling ink.
     
    red floyd, Jun 15, 2010
    #12
  13. DeMarcus

    Brian Guest

    On Jun 15, 9:33 am, Öö Tiib <> wrote:
    > On Jun 15, 4:04 pm, "Eric J. Holtman" <> wrote:
    >
    > > Brian Wood <> wrote in news:275eceac-42c1-4eb0-8847-
    > > :

    >
    > > >> What is BP? British Petroleum?

    >
    > > > Yes, British Petroleum.

    >
    > > BP hasn't been British Petroleum for sme time.

    >
    > > It's just "BP".

    >
    > Two letter acronyms are good signal of closing downfall. People want
    > to get done with that nonsense quick even when naming it. When there
    > is "General Motors" it makes sense. When there is "GM", it is nonsense
    > that no one cares about and it will be soon flushed by history.


    I'm not sure if I agree or disagree with this. I hope it isn't
    true as all of the US states have two letter abbreviations.
    I live in Minnesota but don't like using the MN abbreviation.
    I write Minn. or the whole name.

    > So ...
    > if you care, use terms that make sense (like "Best Practice") and do
    > not tell about soon-to-be-ruins (like that "BP"). ;)


    There's a lot to learn or remember from BP's mistakes so disagree
    with that. I'm reminded of the "be careful what you wish for"
    saying. I bet a lot of people wished they could get a job with
    BP. Now those that did are collectively responsible for the
    destruction of a big chunk of the world. The only responsible
    action at this point may be to liquidate the company. Kind of
    ironic that an oil company has to liquidate itself in order to
    do the right thing.

    Brian Wood
     
    Brian, Jun 15, 2010
    #13
  14. DeMarcus

    Öö Tiib Guest

    On Jun 15, 6:36 pm, red floyd <> wrote:
    > On Jun 15, 7:33 am, Öö Tiib <> wrote:
    >
    > > Two letter acronyms are good signal of closing downfall. People want
    > > to get done with that nonsense quick even when naming it. When there
    > > is "General Motors" it makes sense. When there is "GM", it is nonsense
    > > that no one cares about and it will be soon flushed by history. So ...
    > > if you care, use terms that make sense (like "Best Practice") and do
    > > not tell about soon-to-be-ruins (like that "BP"). ;)

    >
    > What about (pre-Carly) HP?  They were known simply as HP for years,
    > and were considered THE BEST equipment until Carly decided she'd
    > rather
    > get rich selling ink.


    Yes Hewlett-Packard used HP brand from start i think. Some people
    manage to make a strong brand even from a ugly abbreviation. The
    markets they initially targeted were science, economics and business
    that do not care about aesthetics as much as efficiency and they were
    good at it.
     
    Öö Tiib, Jun 15, 2010
    #14
    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,927
    Julie
    May 17, 2004
  2. Steve Knight
    Replies:
    2
    Views:
    806
    Steve Knight
    Oct 10, 2003
  3. Toby Bradshaw
    Replies:
    6
    Views:
    1,812
    Kai-Uwe Bux
    Jun 2, 2006
  4. Colin Caughie
    Replies:
    1
    Views:
    764
    Shooting
    Aug 29, 2006
  5. Misiu
    Replies:
    3
    Views:
    2,451
    Misiu
    Jan 31, 2007
Loading...

Share This Page