I have taught my students about casting and they did an exercise on casting. RobotC version 3.04 worked great, but version 3.5 would not cast correctly. ??????????????

Perhaps you could supply an example piece of code that demonstrates this issue. You're not giving us a whole lot to go on here and the question marks aren't helping.

- Xander

Hey mightor,

Sorry for the short original post. I only had a couple minutes between classes. I am using the NXT to teach different topics. When talking about casting we typed the following program in.


task main()
{
float x =5;
float y = 10;
float z;
z=(int)(x/y);
}

version 3.04 gives z a value of 0 which I think is correct
version 3.05 and 3.5 give z a value of .5

Can you explain what is causing the same program to give different values on different versions?

Thanks for the help

One of the things that 3.5x does was to improve compiler warnings/errors. z = (int)(x/y) is not syntactically correct. z is declared as a float and your type cast resulted to an integer. You can't assign an integer to a float. I think the previous RobotC was tolerant of that and automatically promote the type to float for you. But strictly speaking, the code is incorrect. If you do this instead z = (float)((int)(x/y)) then it should compile fine. I checked this with Visual Studio and your code was giving a compiler error:
error C4244: '=' : conversion from 'int' to 'float', possible loss of data
So even though the code compiled fine with 3.04 does not mean it was correct.

No, casting is allowed at any time, and there are often good reasons to cast something to a smaller/shorter/less accurate data type. Try the above code out in any standard C compiler, and it should not complain. (Verified locally using clang on my Mac..)

This is definitely a bug..


Nate

After re-reading the original post carefully, I have misread it the first time. I thought the issue was the compiler either should or should not compile the code without error. But after rereading it, if (int) cast does not lose the 0.5 (which is the intention), then I agree it's a RobotC bug. I think it is a bug in the optimization that RobotC thinks since you are type casting a float to int and then assigning to float, it must be a NOP.