From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30534 invoked by alias); 19 Sep 2005 07:33:13 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 30481 invoked by uid 22791); 19 Sep 2005 07:33:07 -0000 Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (199.232.76.164) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 19 Sep 2005 07:33:07 +0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1EHG9B-0004Wo-Lw for gcc-help@gnu.org; Mon, 19 Sep 2005 03:33:05 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1EHFk1-00057N-Rv for gcc-help@gnu.org; Mon, 19 Sep 2005 03:07:06 -0400 Received: from [217.72.192.225] (helo=smtp07.web.de) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EHFk1-00056t-F3 for gcc-help@gnu.org; Mon, 19 Sep 2005 03:07:05 -0400 Received: from [83.135.170.151] (helo=ask-c-system.hopto.org) by smtp07.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.105 #317) id 1EHFjx-0007SO-00; Mon, 19 Sep 2005 09:07:01 +0200 From: Ingo Krabbe To: corey.taylor@gmail.com Subject: Re: Reasonable static initialization assurance Date: Mon, 19 Sep 2005 07:33:00 -0000 User-Agent: KMail/1.8.1 Cc: gcc-help@gnu.org References: <2e393d080509171015ac28a39@mail.gmail.com> <200509190827.51191.ikrabbe.ask@web.de> <2e393d080509182337a269a30@mail.gmail.com> In-Reply-To: <2e393d080509182337a269a30@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1191667.FZkRUvmyhg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509190906.51583.ikrabbe.ask@web.de> X-Sender: ikrabbe.ask@web.de X-SW-Source: 2005-09/txt/msg00112.txt.bz2 --nextPart1191667.FZkRUvmyhg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-length: 1422 No I'm telling you that the compiler type plays no part in your problem wit= h=20 variable initializations. Am Montag, 19. September 2005 08:37 schrieb corey taylor: > > 1. Your question is of general nature not specific to gcc. As such it > > doesn't belong onto the gcc-help list. > > You're telling me that the compiler plays no part in the variable > initializations? > > 2. I'm trying to find the difference between the code specifically. > It also currently only happens on OSX gcc and not linux. Perhaps I > can reproduce in linux, but as I've finally tracked the error down to > a std::string object being assigned to during another part of the > static initialization period I'm sure that case has happened before. > > > 3. Static values are contained in the program text at any execution time > > and are loaded into their own memory section never changing their place. > > Yes of course, exactly. I'm asking if there is any "reasonable" way > to use non-POD types for static global variables and use them before > the initalization period is over. > > Of course, you can replace objects like std::string with character > arrays -- but the question still remains. > > > I assume you access not initialized contents of the variables or you > > write into const sections of constant values. > > Well, even without an assignment made. Just a non-POD object sitting > in memory initialized properly. > > Corey --nextPart1191667.FZkRUvmyhg Content-Type: application/pgp-signature Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDLmOLNfy3Nhj961oRAlflAJ0Q4/3gHs0Avh98bZOsfHESfMmRaQCfRhUT 2UcR/W7pLRnd/qxY2k0ywwo= =uv3v -----END PGP SIGNATURE----- --nextPart1191667.FZkRUvmyhg--