Mail Archives: cygwin/2007/10/24/15:25:33
> Can you post the bug{1,2}.cpp files? I would guess that its not a bug,
> but rather you are relying on an undefined order of static
> initialization that happens to do what you want sometimes but not
> others. It's impossible to say for sure without seeing the source files,
> though.
Oh I see, you did attach them, in the shell script. So the issue is that
you are declaring a local static variable in an inline function, which
is then referenced in multiple translation units. As far as I can
remember, this is supposed to work OK, but I know a lot of compilers,
not just gcc, get it wrong, because the standard is different than the
ARM on this point. The bug was probably fixed in gcc 4.0, which is not
yet available on cygwin. (You can verify that a lot of things will
change this behavior, for instance if you just add a default constructor
to Element() with an empty body, your example will work as you expect.)
Anyway, for portability, you are probably better off not relying on any
compiler getting this right, and you should just define the root()
function non-inline in its own translation unit. That being said, gcc is
clearly messing up here, as you would expect its most likely failure to
be generating multiple copies of the static variable, not too few.
This isn't really cygwin-specific, you will get the same thing if you
use the native windows MinGW compiler (ie, by using g++ -mno-cygwin).
You're probably better off asking around in comp.lang.c++, comp.std.c++,
or a gcc-specific mailing list, as those people will know more.
-Lewis
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -