Re: Initialization of static anonymous-namespace members from a
dynamically loaded lib
On Jan 10, 12:05 am, "Alf P. Steinbach /Usenet"
<alf.p.steinbach+use...@gmail.com> wrote:
* James Kanze, on 10.01.2011 00:03:
On Jan 9, 9:00 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
+use...@gmail.com> wrote:
* m0shbear, on 09.01.2011 21:56:
[...]
Is it even possible to have file-scope non-POD statics upon
whose operations do not invoke UB, inside a d-l lib?
The C++ standard does not address or even acknowledge the
existence of dynamically loaded libraries except that one can
interpret some wording about delayed initialization as
pertaining to dynamically loaded libraries.
Yes, but most C++ compilers do permit dynamically loaded
objects.
What's that "but"?
That most C++ compilers do permit dynamically loaded objects. So
it makes sense to speak about the concept in C++. Like
threading, for example.
(I don't know of any that can dynamically load a
library. But despite the name, under Windows, a DLL is not a
library.)
Windows Dynamically Loaded Library, *nix Shared Library.
What's a Unix shared library? I've never heard the term before.
(Under Unix, the files are normally called shared objects, or
simply .so files. The header of the Posix specification of
dlopen says "dlopen -- gain access to an executable object
file".)
Neither name is particularly good: they behave like object
files, not libraries, and the significant point isn't that they
are shared, but that they are dynamically loaded.
You mean despite the names we shouldn't talk about them as
"libraries".
Ideally, no. Practically, I think DLL is to ingrained for us to
change it. But I do constantly see people getting confused
about the issue.
This terminological subtlety, where you seem to have invented
your very own terminology (confusingly using the same word as
others but with a different meaning) reminds me of a certain
person that I killfiled yesterday.
Except that I got this point of view from discussions in the
C committee. It's certainly not my own. And calling DLL's
libraries does cause problems: we see postings all the time from
people who don't understand how libraries work, because they've
been brought up to believe that the behavior of a DLL is what
a library does.
Anyway, the short of it is that in Windows you can generally
rely on techniques such as above, but not in *nix.
Under which Unix does it fail? I've used the technique a lot
under various Unices, and I've never known it to fail. (I can
guarantee that it works correctly under Solaris and Linux,
because those are the Unices I currently have access to, but I
can't remember every seeing it fail.)
Hm. I'm glad to hear that it works. Maybe what I thought
I knew is wrong. At least, googling "static initialization
problem in shared libraries in Linux" didn't find any of that,
except some mention of problems with very old version of g++
(2.95 or earlier) -- perhaps that's where I got wrong idea
from?
I think that it didn't work in some very old versions of Unix
(going back 15 or 20 years or more). But they certainly work
under Solaris and Linux, and have for a long time; I'm pretty
sure the same is true for AIX and HP-UX, although it's been some
time since I've used them.
On the other hand, Posix doesn't say anything about it, at least
not that I can find. (But then, Posix doesn't say anything
about C++ in general.)
--
James Kanze