<p>Many languages have keywords <code>short</code> and <code>int</code> and <code>long</code> and <code>double</code> as their built-in primitive types. C seems to have started this and other languages such as Java followed. In C one of the reasons why this is the case is because <code>CHAR_BIT</code> is not always 8 so building in and mandating fixed-width types would get complicated. But in Java all are guaranteed to be a certain width as far as I can tell. Though removing ambiguity is an advantage of having the width in the type names, so are there other reasons why I would have: <code>short</code> <code>int</code> <code>long</code> <code>float</code> <code>double</code> instead of <code>int16</code> <code>int32</code> <code>int64</code> <code>float32</code> or <code>float64</code>?</p>

<types><integers>
Why short and long and double and similar instead of unambigous width types such as int16 or int64 or float64?
<p>Believe it or not, the original idea in C was that you <em>weren't</em> supposed to worry about the size, and other languages made shortly thereafter followed suit. The idea was &quot;use <code>int</code> for integers, <code>float</code> for decimals, and let the compiler decide the side&quot;. Obviously, that hasn't been the reality. Everybody is constantly working around this, most large C programs use typedefs to get precise sizes, and the terminology is largely considered a misfeature.</p>

CC BY-SA 4.0
2023-05-20T02:41:09.243Z
2023-05-20T02:41:09.243Z
Silvio Mayolo
<p>C's choice to make integer widths depend on the hardware (or, strictly speaking, the compiler's choice ─ but in practice, compilers choose based on the hardware) means these types are &quot;<a href="https://en.wikipedia.org/wiki/Leaky_abstraction" rel="noreferrer">leaky abstractions</a>&quot;. They don't save the user from having to think about the lower-level details.</p>
<p>In contrast, Java's primitive types are &quot;safe abstractions&quot; ─ you get the same behaviour regardless of the machine architecture that will end up running your program. But you still need to know the number of bits for each type, because these aren't included in the type names. Probably Java's reason for keeping the names <code>int</code>, <code>long</code> and so on is because the designers were explicitly trying to keep their language familiar to C programmers, in order to encourage adoption. (Java has the same motivation for borrowing other things from C's syntax, including that you can declare array variables like <code>int x[];</code> instead of <code>int[] x;</code>.)</p>
<p>A downside of type names like <code>uint32</code> or <code>float64</code> is that they are longer, and take up more space; this particularly matters for the fundamental primitive types of the language, which users will have to type and read over and over again. Rust's solution here is a good one: the primitive types <code>u32</code>, <code>i32</code>, <code>f32</code>, <code>u64</code>, <code>i64</code>, <code>f64</code> and so on have explicit bit-widths in their names, while also being short; and if the programmer <em>wants</em> a platform-dependent integer they can use <code>usize</code> or <code>isize</code>. Sure, this means the programmer needs to know that <code>i</code> means integer and <code>f</code> means floating-point number, but that's less to remember than the widths of every type, and it's an abbreviation rather than an arbitrary name like &quot;short&quot; or &quot;long&quot;.</p>

CC BY-SA 4.0
2023-05-20T04:25:51.307Z
2023-05-20T04:25:51.307Z
kaya3
CC BY-SA 4.0
2023-05-20T04:29:00.397Z
So in Java `int x[];` is valid?
CPlus
CC BY-SA 4.0
2023-05-20T04:31:06.573Z
@user16217248 [It sure is](https://tio.run/##JY0xDoMwFEN3TuExkWgk2rHq0KUXYEQMv4BQaEii5INAiLOnlE4enp890EwX5zs7tJ@UGkMx4uUctgzw09voBpGJj5idbjGStqLkoG0PCn2sanlWAW0ZS1Xjga3Icc1x2@8nKNfI3ajcxMofHhsrhuNUTayNeoZAa1Ts/ptikfJn7dme0hc)!
kaya3
# Why short and long and double and similar instead of unambigous width types such as int16 or int64 or float64?
Posted by: username_0 on 2023-05-20
Many languages have keywords `short` and `int` and `long` and `double` as their built-in primitive types. C seems to have started this and other languages such as Java followed. In C one of the reasons why this is the case is because `CHAR_BIT` is not always 8 so building in and mandating fixed-width types would get complicated. But in Java all are guaranteed to be a certain width as far as I can tell. Though removing ambiguity is an advantage of having the width in the type names, so are there other reasons why I would have: `short` `int` `long` `float` `double` instead of `int16` `int32` `int64` `float32` or `float64`?
**Tags:** types integers
---
## 2 answers
### Answer by username_1 on 2023-05-20. Score: 9 | Accepted answer
Believe it or not, the original idea in C was that you *weren't* supposed to worry about the size, and other languages made shortly thereafter followed suit. The idea was "use `int` for integers, `float` for decimals, and let the compiler decide the side". Obviously, that hasn't been the reality. Everybody is constantly working around this, most large C programs use typedefs to get precise sizes, and the terminology is largely considered a misfeature.
---
### Answer by username_2 on 2023-05-20. Score: 6
C's choice to make integer widths depend on the hardware (or, strictly speaking, the compiler's choice ─ but in practice, compilers choose based on the hardware) means these types are "[leaky abstractions](https://en.wikipedia.org/wiki/Leaky_abstraction)". They don't save the user from having to think about the lower-level details.

In contrast, Java's primitive types are "safe abstractions" ─ you get the same behaviour regardless of the machine architecture that will end up running your program. But you still need to know the number of bits for each type, because these aren't included in the type names. Probably Java's reason for keeping the names `int`, `long` and so on is because the designers were explicitly trying to keep their language familiar to C programmers, in order to encourage adoption. (Java has the same motivation for borrowing other things from C's syntax, including that you can declare array variables like `int x[];` instead of `int[] x;`.)

A downside of type names like `uint32` or `float64` is that they are longer, and take up more space; this particularly matters for the fundamental primitive types of the language, which users will have to type and read over and over again. Rust's solution here is a good one: the primitive types `u32`, `i32`, `f32`, `u64`, `i64`, `f64` and so on have explicit bit-widths in their names, while also being short; and if the programmer *wants* a platform-dependent integer they can use `usize` or `isize`. Sure, this means the programmer needs to know that `i` means integer and `f` means floating-point number, but that's less to remember than the widths of every type, and it's an abbreviation rather than an arbitrary name like "short" or "long".
> **Comments:**
> **username_0** (2023-05-20): So in Java `int x[];` is valid?  
> **username_2** (2023-05-20): @user16217248 [It sure is](https://tio.run/##JY0xDoMwFEN3TuExkWgk2rHq0KUXYEQMv4BQaEii5INAiLOnlE4enp890EwX5zs7tJ@UGkMx4uUctgzw09voBpGJj5idbjGStqLkoG0PCn2sanlWAW0ZS1Xjga3Icc1x2@8nKNfI3ajcxMofHhsrhuNUTayNeoZAa1Ts/ptikfJn7dme0hc)!  
---
