4 ms·

I'd rather say having such ambiguous adjectives for types was a bad idea to begin with. And it falls apart when something longer than the original long comes ou

by tagrun 8y ago

I'd rather say having such ambiguous adjectives for types was a bad idea to begin with. And it falls apart when something longer than the original long comes out. I'm not blaming them for not being explicit about the # of bits back then, though, because back then memory addressing unit (byte) wasn't universally 8-bits and word size wasn't a multiple of 8 either (and some archs weren't even binary): https://en.wikipedia.org/wiki/Word_(computer_architecture)#Table_of_word_sizes https://en.wikipedia.org/wiki/Word_(computer_architecture)#T... It seems a naming convention in units of bytes could've been possible though (with the exception of a few archs).

int_19h 8y ago
The original design doesn't fall apart, because it allowed multiple prefixes - LONG INT, LONG LONG INT etc - from the get go, specifically so that the list of types could be extended arbitrarily. It's not the most concise or descriptive way to name them, but that's an issue distinct from extensibility. Personally, I think that rather than focusing on number of bits for numeric types, type systems should focus on the valid range of values, more along the lines of Pascal and Ada.
- tagrun 8y ago
  "long long" is proof that it falls apart. Short/long were descriptive, meaningful adjectives, and in the context of 3 integers of different sizes, it made sense. "long long" isn't a descriptive or meaningful adjective. It's not even a real word. Luckily, there are signs that this will stop. Non-standard 128-bit integers are called __int128_t rather than "long long long".