5 ms·
I generally agree with the author, and Google style guides generally discourages use of unsigned types (even in C++) for anything that isn't actually a bag of b
by Xorlev 4y ago
I generally agree with the author, and Google style guides generally discourages use of unsigned types (even in C++) for anything that isn't actually a bag of bits.
I don't know how many strange issues I've tracked down that amounted to "this protocol buffer has a uint32 field, and surprise now the value is negative in Java and oops there was a check that cared about that." At least five or six issues.
At least when it comes to serialization, enforce invariants above the serialization layer.
I would love an unsigned byte type in Java though. What a pain.
- BoorishBears 4y agoKotlin solves this very nicely with Uxxx types, like UByte, UInt, UShort, etc. Typing allows enforcing the boundaries where you go from signed to unsigned, and the bit fiddling is handled in the class UShort.toInt(): Int = data.toInt() and 0xFFFF They're defined as inline classes/functions that have no runtime cost so it's equivalent to the "Straightforward emulation" from the article
- Xorlev 4y agoAnother good reason to switch to Kotlin. :)