Prev: The noexcept keyword, deprecated exception specifications and compilers
Next: Microsoft chooses to leave C++ compiler broken
From: Murthy on 21 Mar 2010 15:04
> Shouln't Index default to 0, not 1?
Can be what ever you choose :). if you keep the default to 0, change
the if condition as
int func(E e) {
int arr[]={3,4};
int Index = 0;
if(e==e2)
{
Index = 1;
}
return arr[Index];
}


> 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];
>
> }

bool index = ( e == e1 );
return arr[index];

this is no different from return arr[e == e1];

but if you use the check as if(e == e2)
and then assign an int value to index, then the subscript is surely
int. so it should work.
Please check it works for you :)





--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Hakusa on 21 Mar 2010 15:03
On Mar 21, 4:09 am, "Daniel T." <danie...(a)earthlink.net> wrote:
> "Hak...(a)gmail.com" <hak...(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.)

I believe so, but what i was inquiring about was if storing the value
into a named bool would prevent the compiler from making the 1-e
optimization that was noted above.

Yes, the == operator should return a bool, but the compiler is allowed
to make any optimization it wants, as long as it doesn't change the
output. Since the code that causes the bug in the program is wrong, i
think the compiler is ignoring the possibility of it. This all assumes
that specific optimization is the cause.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jens Schmidt on 21 Mar 2010 15:04
Balog Pal wrote:

> "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.

Or even, as arr[] is local to func():

int func(E e) {
int arr[]={4,3};
return arr[e];
}

with similar problems. Further optimization to

int func(E e) {
return 4-e;
}

is free of access problems, but may still return "interesting" values.
--
Greetings,
Jens Schmidt


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3
Prev: The noexcept keyword, deprecated exception specifications and compilers
Next: Microsoft chooses to leave C++ compiler broken