section 3.7.1 says
The keyword static applied to a class data member in a class
definition gives the data member static storage duration.
(does not cover those static members in a namespace scope!)

But aren't global variables static by default? static for a global
variable just reduces the visibility scope of the global variable to
that particular compilation unit, isn't it?

Salt_Peter schrieb:

Could anyone tell if the initialization sequence is specified
by the standard in such a case or if I cannot rely on the
initialization sequence even when everything is in the same translation
unit?

section 3.6.2
The storage for objects with static storage duration shall be zero
initialized before any other initilization takes place

ok, but in my case, both variables are explicitly initialized to
non-zero values.

section 3.7.1 says
The keyword static applied to a class data member in a class
definition gives the data member static storage duration.
(does not cover those static members in a namespace scope!)

What I really like to know is if I usually could rely on having
my global variables being initialized in the same sequence as
they appear in the source code, i.e. whether the old gcc-2.95
compiler is buggy because it initializes d _before_ t or if this
is an implementation detail that is not defined by the standard.

James Kanze schrieb:

The standard guarantees that object definitions requiring
dynamic initialization occur in the order of the definitions
within a given translation unit. Note, however, that a static
member of a template is only "defined" if it is
instantiated---each instantiation is a separate definition (and
the template definition is *not* a definition of an object).
Because the point of instantiation will vary if the static
member is instantiated in several different translation units,
the standard simply says that the order in this case is
unspecified.

1 #include <stdio.h>
2 struct X {
3 X() {printf("X constructor\n");}
4 };
5 template<typename T> struct A {
6 static T t;
7 };
8 template<typename T> T A<T>::t;

Note that the above is a declaration, not a definition.

You are right, this is a declaration. And my initial posting was
off by one line: I meant to talk about lines 9 and 10 respectively,
which _are_ both definitions.
But anyway, as I introduced line 9 only to instantiate the template
to run the X constructor, it should be replaced by
template struct A<X>;

But anyway, the result is still the same with the two compiler
versions.

9 X &x =3D A<X>::t;
10 int d =3D printf("initialized d\n");
11 int main() {}

Just curious, but what do you expect to happen if A<X>::t is
also implicitely initialized in another translation unit?

Well, this is an interesting question, as I was paying arround
with this just exactly because I intentionally wanted to
instantiate it within other translation units: When I do this,
the linker seems to silently through away all instantiations
but the very first it finds in any of the translation units
that it links.

Thus, this (together with the improvement that I've described
above) seems to be a method to _define_ variables in header
files, even if they are included into multiple translation
units.

This may be useful for libraries like the STL that entirely
live in header files, as it allows to work around the need for
a separate translation unit just because the library needs
some global variables. I'd be very interested to get some
feedback on this idea!> I think you've got a case of
unspecified behavior here.

Well, as I said, lines 9 and 10 are the ones of interest, with
line 9 replaced as suggested above. And I still hope that the
sequence of these lines define the sequence of construction of
the related variables.