This is the mail archive of the
mailing list for the GCC project.
Re: c++/7538: Constructors of static members are not called always
- From: nathan at gcc dot gnu dot org
- To: gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, neu at iis dot fhg dot de, nobody at gcc dot gnu dot org
- Date: 25 Sep 2002 10:52:10 -0000
- Subject: Re: c++/7538: Constructors of static members are not called always
- Reply-to: nathan at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, neu at iis dot fhg dot de, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: Constructors of static members are not called always
State-Changed-When: Wed Sep 25 03:52:09 2002
not a bug.
[3.6.2]/3 says dynamic initialization may be delayed, but
must be done before the first use of any function or object
defined in the same TU as the object to be initialized.
The TU which defines ClassA::m_stClass is classA.cpp. The
main program uses ClassA::ClassA, ClassA::~ClassA and
ClassA::returns_five. All those are inline functions
defined in classA.hpp. [3.2]/3 says an inline function
shall be defined in every TU in which it is used. As
those inline functions are defined in main.cpp.
Hence we never use anything defined in the TU classA.cpp,
and so never need to initialize classA::m_stClass.
The reason you see different behaviours with a library
vs explicit classA.o, is that in the latter case the linker
is forced to include classA.o in the final executable, that
pulls in the static ctor function for that object file.
With a library, classA.o is only pulled in, if something explicitly references an object/function defined within
it. Should that happen then all of classA.o is pulled in,
which will include the static ctor function.
The standard permits this.