This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/47861] static variables inside member functions
- From: "michal.t at tiscali dot it" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 24 Feb 2011 09:44:55 +0000
- Subject: [Bug c++/47861] static variables inside member functions
- Auto-submitted: auto-generated
- References: <bug-47861-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861
--- Comment #7 from Michal Turlik <michal.t at tiscali dot it> 2011-02-24 09:44:53 UTC ---
Well guys it is probably silly but you need to consider a more specific
case.
Base*
MyClass::next(bool reset)
{
static Bases::iterator it
= m_bases.begin();
if(reset)
it = m_bases.begin();
Base* base
= ((it != m_bases.end()) ? (*it++) : 0);
return base;
}
void
MyClass::
init()
{
Base* base = next(true);
while(base) {
base->init();
base = next(false);
}
}
The default behaviour of
init is to recall init on each child and each child will do the same if
not specified differently.
The issue is clearly caused by having
declared static the iterator.
Obviously the same snippet code can be
replaced by a simple for each iterator construct.
As you have mentioned
before - static means static...consider only the implication of a code
written in this way...a
forced definition of the iterator being static
would probably prevent some unprapred c++ users to make similar
mistakes.
Thank you all.
----Messaggio originale----
Da: gcc-
bugzilla@gcc.gnu.org
Data: 23/02/2011 22.28
A: <michal.t@tiscali.it>
Ogg: [Bug c++/47861] static variables inside member functions
http:
//gcc.gnu.org/bugzilla/show_bug.cgi?id=47861
--- Comment #6 from
Jonathan Wakely <redi at gcc dot gnu.org> 2011-02-23 21:28:10 UTC ---
(In reply to comment #5)
> Also it is hard to produce a warning when it
comes to a failure that will only
> be diagnostic at link time.
IIUC I
think the OP wants a warning for:
struct S {
int f();
};
int S::f()
{
static int i = 0;
return ++i;
}
which doesn't require a
definition and can't produce a linker error. I think
adding a warning
for this is silly.