Are the Boost C++ libraries legitimate?

[Peter v. N.]

Hi all,

First off: consider this to be a low priority thread!

This may sound heretical: but I'd like to know what
the community thinks about using Boost extensively
in C++ projects (mainly for threads and numeric
applications).

Better reinvent the wheel (for true C++ programmers) or
depend on third party frameworks?

I know that with the upcoming release of C++ many parts of
Boost will be incorporated...Nevertheless I'm curious
about what you think.

Brgds,
Peter

 

[Gianni Mariani]

Peter v. N. wrote:
....

Better reinvent the wheel (for true C++ programmers) or
depend on third party frameworks?

The amount of effort that goes into making a good third party framework
is non-trivial.

boost has alot of good things about it, you can pick and choose what you
like.

I started writing Austria C++ before I ever knew about boost so I don't
know what I would have done had I become involved with boost from the
beginning. However, the Austria C++ goals are different to boost, I
don't care about older buggy compilers while some of the older stuff I
saw in boost was littered with MSVC6.0 compatability which made it
difficult to comprehend. (i have not looked at boost recently)

Enough digression.

Frameworks solve lots of issues and knowing how to use them is a big plus.

 

[mlimber]

This may sound heretical: but I'd like to know what
the community thinks about using Boost extensively
in C++ projects (mainly for threads and numeric
applications).

Are you saying your projects mainly for threading and numeric
applications, or is that what you are (or might) use the Boost
libraries for?

Better reinvent the wheel (for true C++ programmers) or
depend on third party frameworks?

It depends. Although the Boost libraries are all peer-reviewed, not all
are equally mature. The parts that have become part of TR1 are
generally considered very mature, and I'd have no qualms about using
those parts. Why reinvent a regular expression parser or a reference
counted smart pointer when they've done it better and tested it more
thoroughly that I could in any reasonable amount of time?

Other parts (e.g., Boost.Threads) are less stable and complete. Even
so, I prefer to use Boost.Threads for portability reasons and because
there's a good chance that it represents something like what C++
threading will look like in C++0x (but cf.
http://www.artima.com/cppsource/threads_meeting.html).

I know that with the upcoming release of C++ many parts of
Boost will be incorporated...

I'd say "a few parts of Boost."

Brgds,

Bridges? Brigands? Barge dues? Borg DOS?

Cheers! --M

 

[Dave Steffen]

This may sound heretical: but I'd like to know what the community
thinks about using Boost extensively in C++ projects (mainly for
threads and numeric applications).

My company does aerospace engineering and algorithm research; we
use Boost extensively. Our code is extraordinarily numeric, and
we're moving towards threads.

The only reason not to use Boost that I can possibly imagine is for
flight-grade embedded code, just because Boost hasn't been certified
at that level (to my knowledge). We're moving towards developing
flight grade code in the next few years, and that will be an issue.

Aside from specific situations like that, IMNSHO any C++ programmer
who doesn't use Boost is crazy.

Go look at the "Who's Using Boost" link on the Boost website.

Better reinvent the wheel (for true C++ programmers) or depend on
third party frameworks?

True C++ programmers _never_ reinvent the wheel.

True C++ programmers inherit publicly if my_wheel IS-A wheel, and
they aggregate if my_tire HAS-A wheel, and they refactor when it
becomes apparent that all wheels should have had a
my_momentOfInertia to begin with.

True C++ programmers may rebuild the wheel, if the wheel they are
provided isn't robust enough. Boost is just about as robust as
libraries come.

Good libraries, using OO | functional | generic | meta- programming
when appropriate... that's what C++ was designed for.

I know that with the upcoming release of C++ many parts of Boost
will be incorporated...Nevertheless I'm curious about what you
think.

I think that there are good reasons Boost is pushing the C++
standard, mainly that some people on the Standard C++ Library group
started Boost for exactly this purpose.

 

[Noah Roberts]

Hi all,

First off: consider this to be a low priority thread!

This may sound heretical: but I'd like to know what
the community thinks about using Boost extensively
in C++ projects (mainly for threads and numeric
applications).

Better reinvent the wheel (for true C++ programmers) or
depend on third party frameworks?

I know that with the upcoming release of C++ many parts of
Boost will be incorporated...Nevertheless I'm curious
about what you think.

I'm a strict follower of NIH so don't ever use boost or anything else
third-party.

I'm not very effective...

 

[David Harmon]

On Mon, 20 Nov 2006 21:31:38 +0100 in comp.lang.c++, "Peter v. N."

This may sound heretical: but I'd like to know what
the community thinks about using Boost extensively
in C++ projects (mainly for threads and numeric
applications).

Boost is great stuff, use it everywhere you can.
However, I can't comment specifically on threads and numerics.

 

[BobR]

mlimber wrote in message ...

Bridges? Brigands? Barge dues? Borg DOS?
Cheers! --M

Binary regards!

[ having two different parts][greetings of good wishes]

 

[Marcus Kwok]

mlimber wrote in message ...

Binary regards!

Beauregardes! (As in 'Violet')

 

[Peter v. N.]

Indeed I'm in the midst of writing an application
to interpolate GPS data from aircrafts. My company
is also set in the aerospace engineering domain...

Thank you all for your opinions.

 

[David Harmon]

On Tue, 21 Nov 2006 20:40:56 +0100 in comp.lang.c++, "Peter v. N."

Indeed I'm in the midst of writing an application
to interpolate GPS data from aircrafts. My company
is also set in the aerospace engineering domain...

It's worth noting that the Boost license was carefully designed to allow
Boost to be used in commercial projects without encumbering the user
with restrictive terms found in some other code projects.