Re: problem Boost libraries
Greg Herlihy wrote:
On 1/27/07 4:36 AM, in article
1169893785.703213.264990@s48g2000cws.googlegroups.com, "James Kanze"
<james.kanze@gmail.com> wrote:
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:
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).
The relevant g++ switch is: -fthreadsafe-statics.
Which is the default. The switch is -fno-threadsafe-statics, to
turn it off.
This switch guarantees
that a local static object will only ever be initialized once. Otherwise,
two or more threads entering the same routine at around the same time
could
both attempt to initialize the same local static object (within that
routine) - each thread unaware that the other thread was doing the same.
Of course. And? How does this guarantee thread safety?
The important point is that this switch exists - not the value of its
default setting. As it happens g++ enables the threadsafe static switch by
default. But the fact that the programmer does have to enable this switch
explicitly only reinforces my original point that - contrary to the claim
being made - local static objects are not necessarily "inherently" unsafe
in
C++. In fact, in the case of at least one C++ compiler, the opposite holds
true: static local objects are safe in a multithreaded environment - and
are
so by default.
The presence or absence of this switch does not make a function
using local static variables thread safe. (I might also add
that the generated code on a Sparc can cause the program to
hang, 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.
The "race conditions" are not caused by other threads within the same
program - but by other processes on the same (or even on another) machine.
What race conditions? You can have race conditions between
threads, between processes, or even, on distributated systems,
between machines in different cities. I've missed something
here, but I don't know what race conditions you're talking about
in particular, and I don't see how the comment relates to my
comment immediately above it.
The file system is a globally-shared resource - so it is not possible for
a
filesystem library to eliminate race conditions on its own. If race
conditions are to be eliminated, the program will have to do so itself -
presumably by taking whatever steps are necessary (assuming such steps
exist) to prevent other processes from performing file system operations
that would conflict with the program's own.
If your point is simply that in some cases it is necessary to
use implementation dependant functions to eliminate race
conditions between processes, that's a well known fact. The
question is how is it relevant to my point, concerning the
contract offered (or not offered) by any specific Boost
component?
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.
Header file dependencies are an inescapable fact of programmin in C++. For
example, assume that a C++ program has a header file, "program.h", that
declares a class with a std::string data member. Therefore, in order to
include "program.h" the <string> header file will have to included as
well.
Now, if C++ really allowed header files to be included "in any order" then
it would not matter whether <string> was included before or after
"program.h' just as long as <string> was sure to be included.
I think you're misunderstanding the point. We're not talking
about compiler dependancies (which as you say, are a fact of
life---not just in C++, but in almost any language). If I
understood the original objection, it is a problem with user
level dependencies: something like:
#include <boost/shared_ptr.hpp>
#include <boost/serialization/shared_ptr.hpp>
doesn't work, where as inversing the includes does.
(Presumably, of course, both of these includes are hidden in
some other header files which are being included.)
Such dependancies make the library unusable in any medium to
large sized project.
In reality, C++ is quite inflexible when it comes to the order of included
header files: in this case, <string> must be included before "program.h" -
otherwise including "program.h" will not compile.
No, <string> must be included IN "program.hh", so that the user
doesn't have to worry about it. The C++ standard requires all
standard headers (except, of course <cassert>) to be idempotent,
and to be includable in any order. Any well written library
will follow the same rules.
Of course, in this case,
it makes sense for "program.h" to include <string> itself rather than rely
on the program to do so, but however <string> is included - does nothing
to
eliminate "program.h"'s dependency on <string>.
From the compiler's point of view. I, as a user, no longer have
to think about it.
The requirements for using the boost serialization library are no
different.
In this case, the program instantiates a serialization class template with
the parameterized type of the object to be serialized. Therefore the
definition of the parameterized type must be visible at the point at which
the serialization template class is instantiated. To take an example: a
program that wishes to serialize an object of class A, must first include
A.h before it includes the serialization header file that contains the
class
template definition.
Now the only between the two examples is that - unlike "program.h" the
serialization library header file cannot predict beforehand what type the
user intends to serialize - so cannot know which header file it must
include as a convenience to handle the dependency - the program simply has
to include the appropriate header file itself. But in all other aspects
the
two examples are identical - and both are constrained by the rules of the
C++ language and not by any "design defect" of their own making.
I'm not sure I understand. First, this doesn't seem related to
the problem the original poster raised. Secondly, the way
templates work doesn't require dependant names and arguments to
be defined before the template itself; there's no need to
include "A.hh" before "template.hh" in order to instantiate the
template over A.
- 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.
The C++ Standard has no notion of an include order for libraries. In
contrast, a C++ program that includes header files must specify the order
in
which they are to be included; and the program must observe strict rules
governing how various declarations and definitions have to be sequenced.
A C++ that includes header files specifies the order its headers
are included; it can't do otherwise, given that the compiler
reads the source in sequential order. What that order is,
however, shouldn't matter, if the libraries are well written and
well conceived. (Like someone else who posted, I usually use
alphabetic ordering, although I will do some grouping: all of
the standard library together, all of library X together, etc.)
It's the responsibility of the header files to be written in a
way that allows this.
Granted it would be nice if C++ were more tolerant about the order in
which
a source file brought in a set of header files. But unless and until the
C++
language is amended to allow such flexibility, the order that header files
are included by a C++ program will continue to be significant - it's
simply
a fact of programming life. And any expectation to the contrary is simply
not realistic.
Which is why the standard requires it of the standard library.
And why every library I've ever written or used has allowed
inclusion in an arbitrary order as well.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, 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! ]