4 ms·
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
by cogman10 2y ago
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
- jltsiren 2y agoI 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 assumption is worth making.
- Jerrrrrrry 2y agohindsight has its advantages
- jonstewart 2y ago<cstdint> has int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, and uint64_t. I still go back and forth between uint64_t, size_t, and unsigned int, but am defaulting to uint64_t more and more, even if it doesn't matter.
- WalterBright 2y agoThat doesn't really fix it, because of the integral promotion rules.
- kazinator 2y ago> you have to mention the size explicitly 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.
- pezezin 2y agoIf you don't care about the size of your number, just use isize or usize. If you do care, then isn't it better to specify it explicitly than trying to guess it and having different compilers disagreeing on the size?
- kazinator 2y agoA type called isize is some kind of size. It looks wrong for something that isn't a size.
- pezezin 2y agoThen just define a type alias, which is good practice if you want your types to be more descriptive: https://doc.rust-lang.org/reference/items/type-aliases.html https://doc.rust-lang.org/reference/items/type-aliases.html
- kazinator 2y agoNope! Because then you will also define an alias, and Suzy will define an alias, and Bob will define an alias, ... We should all agree on int and uint; not some isize nonsense, and not bobint or suzyint.
- josephg 2y agoYep. 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).
- paragraft 2y agoWhat's the right way?
- WalterBright 2y agoUTF-8 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.
- Remnant44 2y agoutf8, for essentially the reasons mentioned in this manifesto: https://utf8everywhere.org/ https://utf8everywhere.org/
- josephg 2y agoYep. Notably supported by go, python3, rust and swift. And probably all new programming languages created from here on.
- josefx 2y agoI would say anyone mentioning a specific encoding / size just wants to see the world burn. Unicode is variable length on various levels, how many people want to deal with the fact that the unicode of their text could be non normalized or want the ability to cut out individual "char" elements only to get a nonsensical result because the following elements were logically connected to that char? Give developers a decent high level abstraction and don't force them to deal with the raw bits unless they ask for it.
- consteval 2y ago
- pjmlp 2y agoWhile I don't agree with not having unsigned as part of the primitive times, and look forward to Valhala fixing that, it was based on the experience most devs don't get unsigned arithmetic right. "For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that, for instance, Java isn't -- and in fact a lot of these languages end up with a lot of corner cases, things that nobody really understands. Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up." http://www.gotw.ca/publications/c_family_interview.htm http://www.gotw.ca/publications/c_family_interview.htm