[boost] [filesystem][program_options][serialization][test] from comp.lang.c++.moderated

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-08 20:35:22

It seems as though the OP may not be totally crazy, so we should
evaluate his comments and see if the issues can be (or have been)
addressed.  The article is of course bad publicity for Boost, and I'd
like to demonstrate responsiveness if possible.


attached mail follows:

David Abrahams wrote:

> Wil Evers <bouncer_at_dev.null> 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! ]


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com