Re: problem Boost libraries
Greg Herlihy wrote:
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.
G++ does not have a switch for compiling thread-safe local
statics; I'm not even sure what such a switch should do. By
default, recent versions of g++ will handle construction of
local statics in a thread safe manner, on some platforms. You
can turn this feature off, however, and probably should if
you're compiling for a Sparc (since in certain extreme
conditions, the generated code can block due to priority
inversion).
C++ itself is not "thread-aware" so any
solution would have to depend on the compiler.
Boost is thread-aware, and any Boost code could use
boost::threads. The question isn't there, however. The
question is rather: what guarantees does the compontent make
with regards to threads, and does it meet them. I wouldn't like
a component that documented that you cannot use multiple
instances of a class in different threads without external
synchronization, but if it documented exactly when you needed
the synchronization, it's thread-safe.
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?
I certainly do. It's part of good software engineering.
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?
Dependencies in the order of inclusion of header files are a
serious defect. Other dependencies may be unavoidable: order of
inclusion of libraries, for example.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]