c++/9881: Incorrect address calculation for static class member
Peter A. Buhr
pabuhr@plg2.math.uwaterloo.ca
Thu Feb 27 22:51:00 GMT 2003
> Finally, your suggestion is not even
> a work-around, because the original problem occurred in separate compilation
> units, so the notion of moving the constructor in this case does not apply.
At which point you are out of luck in any case, since the standard does
not give any guarantee about the order of initialization in case there are
more than one translation units.
I think it does. All static variables in all translation units must be
initialized before any global constructors in any translation unit. The static
initialization is usually done by reading constants from the .data section or by
the linker/loader. So if I initialize a static variable in one translation
unit, it must be initialized before a constructor is run in any another
translation unit. I think you are referring to the order of evaluation of
global constructors across translation units, which is undefined.
May other language lawyers decide this case, regards
Let me change the program slightly and see if this clarifies the situation.
#include <iostream>
using namespace::std;
struct bar {
double p;
}; // bar
struct module {
static double *b;
static double storage;
};
class foo {
public:
foo() {
// the output for both values should be the same
cout << &module::storage << " " << module::b << endl;
}
};
foo f; // print output
bar v;
double *module::b = &(((bar *)(&v))->p); // LINE X
//double *module::b = &(((bar *)(&module::storage))->p); // LINE Y
double module::storage = 0.0;
int main() {
}
If you run this with gcc3.3, the output is:
@awk[5]% a.out
0x8049a50 0x8049a48
Now comment out LINE X, and uncomment LINE Y and run again getting output:
@awk[6]% a.out
0x8049a78 0
Zero (0) is not an acceptable address. BUT, the only different between these 2
lines is the chunk of storage for the object. Notice this has nothing to do
with the constructor. One case works and one doesn't. Is this not compelling?
More information about the Gcc-bugs
mailing list