Re: problem Boost libraries
On 1/25/07 1:33 AM, in article
1169686751.981552.142230@s48g2000cws.googlegroups.com,
"n.torrey.pines@gmail.com" <n.torrey.pines@gmail.com> wrote:
A few months ago, in comp.lang.c++.moderated, Wil Evers pointed out
some problems in a few Boost libraries (below). Since we are
considering using all of the libraries mentioned (and also
Boost.Threads and Boost.uBlas), I wonder if these problems have been
fixed.
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
At least one C++ compiler, gcc, has a switch for compiling thread-safe local
statics, so workarounds do exist. C++ itself is not "thread-aware" so any
solution would have to depend on the compiler.
3) serialization
- A header race; doesn't tolerate including <boost/shared_ptr.hpp>
before
<boost/serialization/shared_ptr.hpp>
Why would the fact that one header needs to be included before another be a
"race" condition? Do you expect to be able to include headers in any order?
Or do you believe that the compiler may include a set of header files in any
order it chooses? (it may not).
- Yet another header race involving headers in both boost/archive and
boost/serialization; details on request
I think it is reasonable to expect that a serialization library would have
very specific dependencies (probably more than most libraries) owing to the
nature of its operation. But dependencies by themselves are not some kind of
defect. After all, how would one go about implementing a serialization
library completely free of dependencies?
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.)
I did not find the "test" library at all Windows-centric. On the contrary, I
compiled and ran it on OS X. The test library makes extensive use of UNIX
facilities - such as signals, timers and so forth as part of its testing
apparatus. (For example, the library uses a signal timer to detect a hung
program). None of these techniques would be reasonable to include in a
shipping application - but test is not designed to be shipped in a program -
so I would not fault these techniques because they are effective.
The purpose of the "test" library is to run the program's unit tests in a
controlled, and closely-monitored environment. Therefore test does a lot of
unorthodox things (as noted) to create this environment. But these changes
are strictly part of the testing environment - they do not affect the
program itself once it is outside of this special testing environment.
One way to measure the state of a program under development is to subject
the program to a series of tests and see how many tests pass and how many
fail. For that reason it makes sense to continue testing a program, after a
test failure - since the subsequent tests are likely to be independent.
Nonetheless, test does offer a mechanism to indicate that a test is
dependent on another test, so if that test should fail, the dependent test
will be skipped.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]