Re: 'if' statement to control switch case
On Apr 12, 11:54 pm, "Old Wolf" <oldw...@inspire.net.nz> wrote:
On Apr 13, 12:17 am, "James Kanze" <james.ka...@gmail.com> wrote:
The switch is effectively a goto, so as you say, the if is never
executed (and the switch can reach any of the case labels,
regardless of the state of m_bLATLON). As for falling through
from `case _T('W'):', you encounter an else. It's hard to
imagine an implementation where you didn't then jump around the
else part.
Output of the following code:
g++,gcc 3.4.1: 1 2 1 2
g++,gcc 4.0.1: 1 1
Should this be considered a bug in the earlier version (or both)?
I don't think the standard is actually that clear about it, see
my response to Greg. At any rate, I wouldn't send in a bug
report until the question has been discussed in comp.std.c++.
Frankly, I wouldn't send in a bug report even then. I don't
care what it does in such cases:-). But once, in the distant
past, I did write code which expected the behavior of g++ 4.0.1;
it seems the most "intuitive", at least for someone familiar
with machine code, and how the basic flow control structures map
to it.
#include <stdio.h>
void foo(int x)
{
switch(1)
{
if (x) {
case 1: printf("1 ");
}
else
case 2: printf("2 ");
}
}
int main()
{
foo(1);
foo(0);
puts("");
return 0;
}
It's an interesting example. Apparently, g++ 3.x recognizes
that the if will never be executed, and removes it (and all
associated code). Change the switch argument to a variable, and
put an additional case label in front of it, and g++ 3.x (3.4.0,
anyway) also outputs "1 1 ", even though the switch control
variable is always 1.
I wouldn't be surprised if the difference between 3.x and 4.x
here isn't the result of a bug fix; that someone complained, and
that the authors of g++ considered it an error, and added a
check to inhibit the optimization, or do it slightly
differently, so as to get "1 1 ". Intuitively, it does seem
rather "wrong" that a single pass through can execute code from
both the then and the else branch. (I suppose one could argue
that the standard doesn't really say what should happen, and in
cases where the standard doesn't specify the behavior, it is
undefined behavior. But that seems a bit over the limit to me.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34