|
From: | Daniel J Sebald |
Subject: | Re: bitshift of int8, int16, etc? |
Date: | Mon, 25 Jun 2007 18:53:04 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
John W. Eaton wrote:
On 25-Jun-2007, David Bateman wrote: | The fact is that as matlab doesn't | implement this yet, whatever we choose to do will be wrong in any case | and need modifying in the long run. So simple is probably better.. In that case, the simplest (or at least "safest") thing is probably to just disable these operations and wait. But if you want to keep these operators, then I think we should definitely avoid doing anything where the behavior is dependent on the implementation of the C compiler. If you want to try to define and implement additional behavior that is not defined by the C standard, then I don't think I can be of much help because I don't normally use these operators, though I would note that in C++, the program #include <iostream> int main (void) { unsigned char x = 255; std::cerr << (x << 1) << std::endl; return 0; } prints 510, but I'm not sure that's a behavior we would want since other operations on intX types saturate.
I get your point, but that example is fraught with all kinds of compiler casts. The (x << 1) is probably cast to a regular int first and then bit shifted. Because the output is a number, the (x << 1) is clearly treated as an int, i.e., printf("%d",). Here is what I get with casting to a char: std::cerr << ((unsigned char)(x << 1)) << std::endl; address@hidden sebald]$ ./shift � That is, a blank character. If we again cast that back to an int so that the value is printed to the stream: std::cerr << ((int)((unsigned char)(x << 1))) << std::endl; address@hidden sebald]$ ./shift 254 which is what we'd expect... but doesn't saturate. What operations are you referring to that saturate? Dan
[Prev in Thread] | Current Thread | [Next in Thread] |