On 07/31/2011 03:57 PM, Mark Murphy wrote: > On Sun, Jul 31, 2011 at 9:45 AM, Olivier Guilyardi <[email protected]> wrote: >> I know it's 32bit, but using a signed int to hold a value higher that >> 0x7FFFFFFF >> seems like perverting the sign bit IMO. It can lead to subtle bugs. > > That ship sailed about two decades ago. > > http://stackoverflow.com/questions/430346/why-doesnt-java-support-unsigned-ints
I don't see anyone argumenting in favor of storing an unsigned value into a signed int on this thread. I mean, I'm all for removing unsigned types if that simplify the language, but then you have to play nice with the rules, as @starblue mentions "If your values are somewhat arbitrary size and don't fit into int, use long." >> Maybe it's a >> common case for Java programmers but it would be cleaner to use a long I >> think, >> since there is no unsigned integers available. > > A long will perform worse than an int, except on 64-bit CPUs, none of > which power Android devices AFAIK. But it's just a color value, I don't see how that's involved in heavy computations. It's just storage, it's like like using two ints, which is still lighter than say a dedicated class. > > Java developers have survived this long having to deal with this, and > it's not like the Internet has brok.........CARRIER LOST lol ;) Ok, yet another good reason to port my Java code to C++ :p -- Olivier -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
