> Right. I'm reporting that
>
> 1) gcc's behavior changed in this regard in 2.96 and 3.00 from 2.95 and
> previous, and
Why is that a problem? The compiler does not need to be consistent.
> 2) gcc sometimes uses these values directly without defining the variables,
> while other times gcc chooses not to use these values directly.
Again, why is this a problem?
> As I understand, gcc used these values directly with the described
> conditional expression in 2.95, so that there was never a need to
> define these variables.
There always was a need: Your program is ill-formed if you don't
define a static member. The compiler is not required to diagnose this
error (and it sometimes doesn't), but it is still an error.
> On this requirement, gcc is not consistent: sometimes it uses the values
> directly, while other times, it requires you define the variables. It
> should not special case :? to fail.
Actually, it must do so. In a ?: expression, if both arguments are
lvalues, the result must be an lvalue. Therefore, the compiler must
not inline the expression, but keep the reference. Consider the
program
#include <stdio.h>
class Foo {
public:
static const int erf = 0;
static const int foo = 1;
};
const int Foo::erf, Foo::foo;
void test(const int& p)
{
if(&p == &Foo::erf || &p == &Foo::foo)
printf("PASS\n");
else
printf("FAIL\n");
}
int main(int argc,char **argv) {
test(argc%2 ? Foo::erf : Foo::foo);
return 0;
}
This program prints, correctly, "PASS" with gcc 3, but prints "FAIL"
in gcc 2.95 because the compiler erroneously inlined the value (and
then found the need to bind p to a temporary). So this change in
behaviour was the result of a bug fix; since it did not introduce a
new bug, I fail to see the essence of your report.
> There are two ways gcc can be made consistent:
Why is it desirable that gcc is consistent?
> 1) disable the use of these values directly in all cases, or
That would hurt performance in the cases where the value can be taken.
> 2) re-enable the use of these values in the ?: conditional expressions.
That would violate the C++ standard.
Regards,
Martin
