Re: initialization sequence issue
On Jan 6, 6:45 pm, Christof Warlich <cwarl...@gmx.de> wrote:
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>;
Which I don't think changes anything.
But anyway, the result is still the same with the two compiler
versions.
9 X &x = A<X>::t;
10 int d = 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.
Well, it obviously has to throw away all but one. Which one is
unspecified.
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.
It could be. But it raises the problem you're complaining
about: the variable is defined in many different translation
units, so its order of initialization with respect to any one
translation unit is unspecified.
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.
I believe that Matt Austern used a similar trick at some time,
precisely to enable a library to be delivered as header files
only.
The order of initialization is unspecified. The rest of the
behavior is well defined. When using such a trick, I would
strongly recommend ensuring that the initialization is static.
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.
They impose the order of initialization of x and d: you can be
assured that x is initialized to refer to A<X>::t before the
initializer of d is called. You have no guarantee, however,
that A<X>::t has been constructed; as a template instantiation,
the order of initialization is unspecified. You end up with
something more or less like:
extern int a ;
int& b = a ;
int c = (std::cout << "initialized c" << std::endl, b ) ;
Initializing a reference does not guarantee that what it refers
to is already initialized.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34