c++/10112: static data member is not correctly initialised

Oliver Kullmann O.Kullmann@Swansea.ac.uk
Mon Mar 17 18:56:00 GMT 2003


The following reply was made to PR c++/10112; it has been noted by GNATS.

From: Oliver Kullmann <O.Kullmann@Swansea.ac.uk>
To: nathan@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/10112: static data member is not correctly initialised
Date: Mon, 17 Mar 2003 18:49:06 +0000

 On Mon, Mar 17, 2003 at 12:04:17PM -0000, nathan@gcc.gnu.org wrote:
 > Date: 17 Mar 2003 12:04:17 -0000
 > To: O.Kullmann@Swansea.ac.uk, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
 >    nobody@gcc.gnu.org
 > From: nathan@gcc.gnu.org
 > Reply-To: nathan@gcc.gnu.org, O.Kullmann@Swansea.ac.uk, gcc-bugs@gcc.gnu.org,
 >    gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
 > X-Mailer: gnatsweb 2.9.3
 > Subject: Re: c++/10112: static data member is not correctly initialised
 > X-Spam-Status: No, hits=-99.3 required=8.0
 > 	tests=NO_REAL_NAME,USER_IN_WHITELIST
 > 	version=2.50
 > X-Spam-Level: 
 > X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
 > 
 > Synopsis: static data member is not correctly initialised
 > 
 > State-Changed-From-To: open->analyzed
 > State-Changed-By: nathan
 > State-Changed-When: Mon Mar 17 12:04:17 2003
 > State-Changed-Why:
 >     the ordering of these two template instantiations is implementation defined. I think there's an algorithm to get
 >     the order right
 >     
 >     nathan
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10112
 
 Hi,
 
 (I hope that's the right way to reply?!)
 
 hmhm, might be. I guess the relevant sentence is
 
 in particular, the initialization (and any associated side-effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist.
 
 (section 14.7.1 of ISO/IEC 14882:1998(E)),
 
 and thus one could conclude that in Giovanni's example in the instruction
 
 assert(B<int>::p1 == B<int>::a.p);
 
 the order of initialisations depends on the order of evaluation of the equality
 expression, which is implementation defined.
 
 Is this the interpretation?!
 
 The best solution (which might also be a better design) seems to me, to put the
 static data member (in the example, of class B) into a new (local) class X (or struct),
 for which we provide a constructor guaranteeing the right order of initialisation. 
 The host class B then has one static data member of type X. When we first use this
 data member, it will be constructed using the right order of initialisation.
 
 Sounds okay to me. (Worked in my case.)
 
 Thanks for your help!
 
 Oliver
 
 -- 
 Dr. Oliver Kullmann
 Computer Science Department
 University of Wales Swansea
 Faraday Building, Singleton Park
 Swansea SA2 8PP, UK
 http://cs-svr1.swan.ac.uk/~csoliver/
 



More information about the Gcc-prs mailing list