public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: nathan@gcc.gnu.org To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, neu@iis.fhg.de, nobody@gcc.gnu.org Subject: Re: c++/7538: Constructors of static members are not called always Date: Wed, 25 Sep 2002 03:52:00 -0000 [thread overview] Message-ID: <20020925105210.673.qmail@sources.redhat.com> (raw) Synopsis: Constructors of static members are not called always State-Changed-From-To: analyzed->closed State-Changed-By: nathan State-Changed-When: Wed Sep 25 03:52:09 2002 State-Changed-Why: 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. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7538
next reply other threads:[~2002-09-25 10:52 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-09-25 3:52 nathan [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-09-16 6:26 Christian Neubauer 2002-09-16 6:08 nathan 2002-09-16 4:56 Nathan Sidwell 2002-09-16 1:46 Christian Neubauer 2002-09-13 16:15 nathan 2002-08-08 3:16 neu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020925105210.673.qmail@sources.redhat.com \ --to=nathan@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ --cc=gcc-gnats@gcc.gnu.org \ --cc=gcc-prs@gcc.gnu.org \ --cc=neu@iis.fhg.de \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).