3 ms·

What percentage of C and C++ programmers do you think really understand all the rules regarding integer types in C? Namely: https://www.nayuki.io/page/summary-o

by nayuki 4y ago

What percentage of C and C++ programmers do you think really understand all the rules regarding integer types in C? Namely: https://www.nayuki.io/page/summary-of-c-cpp-integer-rules https://www.nayuki.io/page/summary-of-c-cpp-integer-rules , https://en.cppreference.com/w/cpp/language/types https://en.cppreference.com/w/cpp/language/types , https://en.cppreference.com/w/c/language/conversion#Integer_conversions https://en.cppreference.com/w/c/language/conversion#Integer_... , https://en.cppreference.com/w/c/language/conversion#Usual_arithmetic_conversions https://en.cppreference.com/w/c/language/conversion#Usual_ar... Never mind the fact that the vast majority of C/C++ programmers don't appreciate the fact that signed overflow in their languages is undefined behavior and can result in anything from correct behavior to complete unpredictable garbage. It's easy to argue for adding unsigned to Java because "I want this feature"; it's harder to argue against it because "I don't want others to use this feature / I don't like how this feature interacts with existing features". Another example of not understanding types, did you know that Rust's usize can be as small as 16 bits? And that even on a 32-bit system, objects are limited to 2 GiB in size, not 4 GiB? https://stackoverflow.com/questions/32324794/maximum-size-of-an-array-in-32-bits https://stackoverflow.com/questions/32324794/maximum-size-of... > The semantics of unsigned integers in java hasn't been decided yet I think they have been decided. Java SE 8 added functions to treat bits as unsigned and perform operations (e.g. Integer.divideUnsigned(), Long.toStringUnsigned()). They might have also stated that it was a non-goal to add unsigned primitive integer types to the language. For what it's worth, I am aware that the lack of unsigned integers in Java is a very contentious topic for decades, and the loudest voices are definitely on the pro-unsigned side. My favorite example is this thread: https://stackoverflow.com/questions/430346/why-doesnt-java-support-unsigned-ints https://stackoverflow.com/questions/430346/why-doesnt-java-s...

rcoveson 4y ago
> What percentage of C and C++ programmers do you think really understand all the rules regarding integer types in C? Who cares? You could ask the same question about operator precedence, and the answer to both is similar: If it's unclear to you or those who might read your code, just be more explicit than strictly necessary. Handle or assert cases of possibly overflow. And by all means, you don't have to mimic the C/C++ implicit casting rules. If something's a potential pitfall, just make it an explicit cast (like `long` to `int` already is). The status quo has some huge pitfalls of its own. `uint64` is out there, whether certain Java folks like it or not. It's there in protobuf, it's there in your databases, it's there in your FFI. This leaves people who have to interoperate with things from Java with the choice of either using `long` and hoping beyond hope your users read the docs, or using BigInteger and taking the accompanying performance hit, plus more correctness problems if your users try to operate on the value and take it outside its range. The Java version of unsigned integers could completely disallow casting to and from signed integers and they would still be a very useful addition to the language. Instead what's going to happen is we're going to get JEP 401 and you'll have a hundred different uint64 primitive classes that are exactly the same as each other except that they have different types. That or we'll get lucky and they'll add one to the standard library, at which point everybody who confidently asserted that adding unsigned integers to Java was a bad idea will have to rationalize to themselves that it doesn't really constitute adding them to the language because they're not in the bytecode, or they're not accessible without an import, or something.

by nayuki 4y ago

rcoveson 4y ago

> What percentage of C and C++ programmers do you think really understand all the rules regarding integer types in C? Who cares? You could ask the same question about operator precedence, and the answer to both is similar: If it's unclear to you or those who might read your code, just be more explicit than strictly necessary. Handle or assert cases of possibly overflow. And by all means, you don't have to mimic the C/C++ implicit casting rules. If something's a potential pitfall, just make it an explicit cast (like `long` to `int` already is). The status quo has some huge pitfalls of its own. `uint64` is out there, whether certain Java folks like it or not. It's there in protobuf, it's there in your databases, it's there in your FFI. This leaves people who have to interoperate with things from Java with the choice of either using `long` and hoping beyond hope your users read the docs, or using BigInteger and taking the accompanying performance hit, plus more correctness problems if your users try to operate on the value and take it outside its range. The Java version of unsigned integers could completely disallow casting to and from signed integers and they would still be a very useful addition to the language. Instead what's going to happen is we're going to get JEP 401 and you'll have a hundred different uint64 primitive classes that are exactly the same as each other except that they have different types. That or we'll get lucky and they'll add one to the standard library, at which point everybody who confidently asserted that adding unsigned integers to Java was a bad idea will have to rationalize to themselves that it doesn't really constitute adding them to the language because they're not in the bytecode, or they're not accessible without an import, or something.