3 ms·

> To operate on two uint32_t values, we need to widen them to Java long using val & 0xFFFFFFFFL. Unfortunately this technique does not allow us to operate on tw

by zokier 4y ago

> To operate on two uint32_t values, we need to widen them to Java long using val & 0xFFFFFFFFL. Unfortunately this technique does not allow us to operate on two uint64_t values because there is no wider signed type in Java > I argue that signed bytes make programming needlessly annoying, and that only unsigned bytes should have been implemented in the first place: Java’s signed byte type is a mistake. > None of these alternatives is as correct as using uint32_t in C/C++, but I don’t think this situation comes up often enough to matter. Never mind that the supposed benefits are extremely slim, and mostly due other weaknesses in Java

nayuki 4y ago
> > To operate on two uint32_t values, we need to widen them to Java long [...] Unfortunately this technique does not allow us to operate on two uint64_t This was filed under the heading "Straightforward emulation". In the next section titled "Efficient emulation", I show that operating on two 64-bit values in unsigned mode is easily doable. > other weaknesses in Java Please explain. Keep in mind that Java is a simpler C++, and consciously chose to remove features that would be confusing or dangerous (e.g. unsigned integers, pointer arithmetic, destructors, multiple inheritance, operator overloading). > when a file/network format specifies an unsigned data field – how should we represent it in Java? [...] None of these alternatives is as correct as using uint32_t in C/C++ Types like uint32_t don't buy you as much functionality as you think. In the last few projects I worked on, the domain of allowed values was a weird range. For example, 1 <= QrCode.version <= 40 ( https://github.com/nayuki/QR-Code-generator/blob/2643e824eb15064662e6c4d99b010740275a0be1/rust/src/lib.rs#L1268-L1271 https://github.com/nayuki/QR-Code-generator/blob/2643e824eb1... ). For example, 1 <= Png.Ihdr.width < 2^31 ( https://github.com/nayuki/PNG-library/blob/536acb238f9c000e297a71f749a240e73cc86833/src/io/nayuki/png/chunk/Ihdr.java#L38-L39 https://github.com/nayuki/PNG-library/blob/536acb238f9c000e2... ). Neither Java int nor C uint32_t capture these constraints properly.

by zokier 4y ago

nayuki 4y ago

> > To operate on two uint32_t values, we need to widen them to Java long [...] Unfortunately this technique does not allow us to operate on two uint64_t This was filed under the heading "Straightforward emulation". In the next section titled "Efficient emulation", I show that operating on two 64-bit values in unsigned mode is easily doable. > other weaknesses in Java Please explain. Keep in mind that Java is a simpler C++, and consciously chose to remove features that would be confusing or dangerous (e.g. unsigned integers, pointer arithmetic, destructors, multiple inheritance, operator overloading). > when a file/network format specifies an unsigned data field – how should we represent it in Java? [...] None of these alternatives is as correct as using uint32_t in C/C++ Types like uint32_t don't buy you as much functionality as you think. In the last few projects I worked on, the domain of allowed values was a weird range. For example, 1 <= QrCode.version <= 40 ( https://github.com/nayuki/QR-Code-generator/blob/2643e824eb15064662e6c4d99b010740275a0be1/rust/src/lib.rs#L1268-L1271 https://github.com/nayuki/QR-Code-generator/blob/2643e824eb1... ). For example, 1 <= Png.Ihdr.width < 2^31 ( https://github.com/nayuki/PNG-library/blob/536acb238f9c000e297a71f749a240e73cc86833/src/io/nayuki/png/chunk/Ihdr.java#L38-L39 https://github.com/nayuki/PNG-library/blob/536acb238f9c000e2... ). Neither Java int nor C uint32_t capture these constraints properly.