Prev
C++ VC ATL STL Concurrency Experts Index
Headers
Your browser does not support iframes.
Re: problem Boost libraries
From:
"James Kanze" <james.kanze@gmail.com>
Newsgroups:
comp.lang.c++.moderated
Date:
Mon, 29 Jan 2007 15:36:14 CST
Message-ID:
<1169986256.394902.226850@l53g2000cwa.googlegroups.com>
Greg Herlihy wrote:.
Which is the default. The switch is -fno-threadsafe-statics, to
turn it off..
Of course. And? How does this guarantee thread safety?.
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.).
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..
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?.
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..
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.
-.
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..
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.
--
--
[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Generated by PreciseInfo ™
"This country exists as the fulfillment of a promise made by
God Himself. It would be ridiculous to ask it to account for
its legitimacy."
-- Golda Meir, Prime Minister of Israel 1969-1974,
Le Monde, 1971-10-15