Subject: Re: Which libraries in Boost are mature enough to be used in real applications?
From: Wil Evers <[email-masked]>
To: (Usenet)
Date: 8 May 2006 15:15:39 -0400
Newsgroups: comp.lang.c++.moderated

David Abrahams wrote:

> Wil Evers <[email-masked]> writes:
>
>> At the place where I work, we used to reach for Boost for almost  
>> anything
>> not (yet) available in the standard library.  We don't do that any  
>> more,
>> because in quite a few cases, we ran into real portability and API
>> stability issues.
>
> Could you be more specific, please?
>
> "Portability issues" could mean a lot of things, some of which might
> mean nothing to the OP.  For example, if your "portability issue" was
> that some Boost library didn't work on a particular pre-standard (or
> highly nonconformant) C++ compiler, it might not matter at all to
> someone not interested in targeting such compilers.

Absolutely.  For all our target platforms, we're either using vc-7.1, or
something between gcc-3.3.* and gcc-4.0.*.  In other words, the target
compiler should not be a problem.

> I'd also like to hear more about what you're calling API stability
> issues.

Well, that's easy. Either a particular call is no longer available in
the next official Boost release, or its semantics have changed.

>> Instead, we now evaluate each Boost library separately before  
>> using it in
>> production code.  For some of the Boost libraries, we've actually  
>> decided
>> to phase out their use at the first available opportunity.  These  
>> are:
>>
>> filesystem
>> program_options
>> serialization
>> test
>
> Because of portability and API stability issues, or for other reasons?

I'll be specific (all targeted at the official boost-1.33.1 release) :

1) filesystem:

- Major problems interfacing with the native API on one our targets (the
Alpha); unmaintainable Boost source, so we couldn't implement any
reasonable workaround
- Uses inherently thread-unsafe function-local statics

2) program_options:

-  Some functions in the public API, used in the examples in the  
official
documentation, dropped without any explanation

3) serialization

- A header race; doesn't tolerate including <boost/shared_ptr.hpp>  
before
<boost/serialization/shared_ptr.hpp>
- Yet another header race involving headers in both boost/archive and
boost/serialization; details on request

4) test (please don't get me started)

- Way too intimate with its developer's apparently native platform  
(WIN32)
for any reasonable degree of portability (takes over main(), maps OS
signals to C++ exceptions, continues to run after failing assert()s,  
etc.)
- Lots of construction/destruction ordering issues - major changes here
between boost-1.32 and boost-1.33.1

Regards,

- Wil

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]