o.k. to use boolean expression as array index?
in [C++]
|
Prev: The noexcept keyword, deprecated exception specifications and compilers
Next: Microsoft chooses to leave C++ compiler broken
From: Daniel T. on 18 Mar 2010 07:30 Arno <aschoedl(a)think-cell.com> wrote: > Hello, > > is this correct C++ code? > > enum E { e1, e2 }; > > int func(E e) { > int arr[]={3,4}; > return arr[e==e1]; > } > > I have an optimized Visual C++ 8 build where arr is accessed with some > large value, neither 0 nor 1. I am wondering whether this is a > compiler bug. As I understand it, 'e == e1' must evaluate to either true or false. True must equal 1 and false must equal 0. My guess is that you have a memory overwrite in some unrelated piece of code. Whatever you do, don't jump to the assumption that the compiler is broken over such a simple issue. Very few programs would work if the compiler didn't implement the equality operator correctly. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Balog Pal on 19 Mar 2010 16:14 "Arno" <aschoedl(a)think-cell.com> > is this correct C++ code? > > enum E { e1, e2 }; > > int func(E e) { > int arr[]={3,4}; > return arr[e==e1]; > } It is. > I have an optimized Visual C++ 8 build where arr is accessed with some > large value, neither 0 nor 1. I am wondering whether this is a > compiler bug. As the only valid values in e are 0 and 1 the compiler can generate assy code equivalent to > return arr[ 1 - e ]; that may lead to negative indexes if you happen to pass illegal values in e. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Murthy on 20 Mar 2010 06:22 [excess quoting deleted. Please trim quotes, and don't quote moderation banners -- mod/hlh] On Mar 17, 9:59 pm, Arno <ascho...(a)think-cell.com> wrote: > is this correct C++ code? > > enum E { e1, e2 }; > > int func(E e) { > int arr[]={3,4}; > return arr[e==e1]; > > } > > I have an optimized Visual C++ 8 build where arr is accessed with some > large value, neither 0 nor 1. I am wondering whether this is a > compiler bug. As far as I think, VS 2005 and 2008 are strong type checked. now true and false may not necessarily be 1 or 0. just modify the code with if condition and test whether it works. code snippet below... int func(E e) { int arr[]={3,4}; int Index = 1; if(e==e1) { Index = 0; } return arr[Index]; } -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Hakusa on 20 Mar 2010 11:09 On Mar 20, 5:22 pm, Murthy <yamur...(a)gmail.com> wrote: > [excess quoting deleted. Please trim quotes, and don't quote moderation > banners -- mod/hlh] > On Mar 17, 9:59 pm, Arno <ascho...(a)think-cell.com> wrote: > > > is this correct C++ code? > > > enum E { e1, e2 }; > > > int func(E e) { > > int arr[]={3,4}; > > return arr[e==e1]; > > > } > > > I have an optimized Visual C++ 8 build where arr is accessed with some > > large value, neither 0 nor 1. I am wondering whether this is a > > compiler bug. Murthy suggested: > int func(E e) { > int arr[]={3,4}; > int Index = 1; > if(e==e1) > { > Index = 0; > } > return arr[Index]; > > } Shouln't Index default to 0, not 1? But, either way, is there any reason this one not be simpler and adequate? int f( E e ) { int arr[] = { 3, 4 }; bool index = ( e == e1 ); return arr[index]; } Or perhaps the compiler would optimize it to the original and the problem would not be fixed. I suppose, then, the compiler is not smart enough to apply this optimization on your solution? Or, would the least obfuscated solution be to add a dummy value to the enumeration type? It would prevent the compiler from making the 1-e optimization, and i doubt that's much of a bad thing. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel T. on 20 Mar 2010 17:09
"Hakusa(a)gmail.com" <hakusa(a)gmail.com> wrote: > int f( E e ) > { > int arr[] = { 3, 4 }; > bool index = ( e == e1 ); > return arr[index]; > } > > Or perhaps the compiler would optimize it to the original and the > problem would not be fixed. I suppose, then, the compiler is not smart > enough to apply this optimization on your solution? > > Or, would the least obfuscated solution be to add a dummy value to the > enumeration type? It would prevent the compiler from making the 1-e > optimization, and i doubt that's much of a bad thing. As far as I know, the compiler is required to return either 0 or 1 from op==. (Could someone double check me on this? I don't have a copy of the standard.) That said, I don't think the OP has found a compiler bug, rather I think there is something wrong with some other part of his code that is causing this side effect. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |