131–140 of 357 posts
Earlier quoted context omitted.
Yep. Pity about getting chars / string encoding wrong though. (Java chars are 16 bits). But it’s not alone in that mistake. All the languages invented in that era made the same mistake. (C#, JavaScript, etc).
What's the right way?
When D was first implemented, circa 2000, it wasn't clear whether UTF-8, UTF-16, or UTF-32 was going to be the winner. So D supported all three.
Earlier quoted context omitted.
Yep. Pity about getting chars / string encoding wrong though. (Java chars are 16 bits). But it’s not alone in that mistake. All the languages invented in that era made the same mistake. (C#, JavaScript, etc).
What's the right way?
During an internship in 1986 I wrote C code for a machine with 10-bit bytes, the BBN C/70. It was a horrible experience, and the existence of the machine in the first place was due to a cosmic accident of the negative kind.
10-bit arithmetics are actually not uncommon on fpgas these days and are used in production in relatively modern applications. 10-bit C, however, ..........
9-bit bytes are pretty common in block RAM though, with the extra bit being used for either for ECC or user storage.
Earlier quoted context omitted.
Yeah, this is something Java got right as well. It got "unsigned" wrong, but it got standardizing primitive bits correct byte = 8 bits short = 16 int = 32 long = 64 float = 32 bit IEEE double = 64 bit IEEE
I like the Rust approach more: usize/isize are the native integer types, and with every other numeric type, you have to mention the size explicitly. On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the ass…
- CHAR_BIT cannot go away; reams of code references it.
- You still need the constant 8. It's better if it has a name.
- Neither the C nor C++ standard will be simplified if CHAR_BIT is declared to be 8. Only a few passages will change. Just, certain possible implementations will be rendered nonconforming.
- There are specialized platforms with C compilers, such as DSP chips, that are not byte addressable machines. They are in current use; they are not museum pieces.
During an internship in 1986 I wrote C code for a machine with 10-bit bytes, the BBN C/70. It was a horrible experience, and the existence of the machine in the first place was due to a cosmic accident of the negative kind.
Earlier quoted context omitted.
Yeah, this is something Java got right as well. It got "unsigned" wrong, but it got standardizing primitive bits correct byte = 8 bits short = 16 int = 32 long = 64 float = 32 bit IEEE double = 64 bit IEEE
I like the Rust approach more: usize/isize are the native integer types, and with every other numeric type, you have to mention the size explicitly. On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the ass…
It's unbelievably ugly. Every piece of code working with any kind of integer screams "I am hardware dependent in some way".
E.g. in a structure representing an automobile, the number of wheels has to be some i8 or i16, which looks ridiculous.
Why would you take a language in which you can write functional pipelines over collections of objects, and make it look like assembler.
But how many bytes are there in a word?
"Word" is an outdated concept we should try to get rid of.
Previously, in JF's "Can we acknowledge that every real computer works this way?" series: "Signed Integers are Two’s Complement" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09... >
Maybe specifying that floats are always IEEE floats should be next? Though that would obsolete this Linux kernel classic so maybe not. https://github.com/torvalds/linux/blob/master/include/math-e...
I wouldn't want to lose the Linux humor tho!