Topic: Common compiler bug with static variable constructor (was User misunderstanding (was: More bugs in Borland C++ 4.0))
Author: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Date: Sun, 19 Jun 1994 15:53:19 GMT Raw View
mkapoor (Mukesh Kapoor) writes:
>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>|> Mukesh Kapoor writes:
[...]
>|> >Note that the call to the copy constructor in this test case can be removed
>|> >by the compiler as an optimization. ARM section 12.6.1 allows this
[...]
>|> No, 12.6.1 only allows the copy constructor to be eliminated
>|> for initializations involving an explicit `='.
[...]
>Sun C++ 4.0 is correct.
Nope, Sun C++ 4.0 is buggy.
>Here is additional information from 12.1c of ARM:
>
> "The fundamental rule is that the introduction of a temporary object and the
> calls of its constructor/destructor pair may be eliminated if the only way
> the user can detect its elimination or introduction is by observing side
> effects generated by the constructor or destructor calls."
But the constructor which is being eliminated is NOT the constructor
for the temporary. The code in question was the following:
>|> void f() {
>|> static A a(A());
>|> }
The constructor call which is being eliminated is a call to `X::X(const X&)'.
But this constructor is not the constructor for the temporary, it's
the constructor for `a'. The constructor for the temporary is `X::X()'.
Hence the optimization being made is not allowed by the commentary in ARM
12.1c.
[In fact, even if it was allowed by the commentary, this would be
irrelevant as far as conformance to the ANSI/ISO working paper goes,
Furthermore, even if you are only talking about compatibility with the
ARM, when the commentary and the main text disagree, the main text must
prevail. However this is all irrelevant since the compiler's behaviour
is not allowed by the commentary anyway.]
Followups to comp.std.c++.
--
Fergus Henderson - fjh@munta.cs.mu.oz.au