5 ms·

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++

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 assumption is worth making.

Jerrrrrrry 2y ago
hindsight 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 ago
  That 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 ago
  If 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 ago
    A type called isize is some kind of size. It looks wrong for something that isn't a size.
    - pezezin 2y ago
      Then 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 ago
        Nope! 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.
        jclulow 2y ago
        Alas, it's pretty clear that we won't!
        pezezin 2y ago
        Ok, it is obvious that you are looking for something to complaint about and don't want to find a solution. That is not a productive attitude in life, but whatever floats your boat. Have a good day.
        kazinator 2y ago
        > looking for something to complaint about You know, that describes pretty much everyone who has anything to do with Rust. "My ls utility isn't written in Rust, yikes! Let's fix that!" "The comments under this C++-related HN submission aren't talking about Rust enough, yikes! Let's fix that!" I'm obviously pointing to a solution: have a standard module that any Rust program can depend on coming from the language, which has a few sanely named types. Rather than every program defining its own.
- Spivak 2y ago
  Is it any better calling it an int where it's assumed to be an i32 and 30 of the bits are wasted.
  - kazinator 2y ago
    what you call things matters, so yes, it is better.
- itishappy 2y ago
  Except defining your types with arbitrary names is still hardware dependent, it's just now something you have to remember or guess. Can you remember the name for a 128 bit integer in your preferred language off the top of your head? I can intuit it in Rust or Zig (and many others). In D it's... oh... it's int128. https://dlang.org/phobos/std_int128.html https://dlang.org/phobos/std_int128.html https://github.com/dlang/phobos/blob/master/std/int128.d https://github.com/dlang/phobos/blob/master/std/int128.d
  - WalterBright 2y ago
    It was actually supposed to be `cent` and`ucent`, but we needed a library type to stand in for it at the moment.
  - kazinator 2y ago
    In C it will almost certainly be int128_t, when standardized. 128 bit support is currently a compiler extension (found in GCC, Clang and others). A type that provides a 128 bit integer exactly should have 128 in its name. That is not the argument at all. The problem is only having types like that, and stipulating nonsense like that the primary "go to" integer type is int32.

Jerrrrrrry 2y ago

hindsight 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 ago
That 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 ago
If 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 ago
  A type called isize is some kind of size. It looks wrong for something that isn't a size.
  - pezezin 2y ago
    Then 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 ago
      Nope! 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.
      - jclulow 2y ago
        Alas, it's pretty clear that we won't!
      - pezezin 2y ago
        Ok, it is obvious that you are looking for something to complaint about and don't want to find a solution. That is not a productive attitude in life, but whatever floats your boat. Have a good day.
        kazinator 2y ago
        > looking for something to complaint about You know, that describes pretty much everyone who has anything to do with Rust. "My ls utility isn't written in Rust, yikes! Let's fix that!" "The comments under this C++-related HN submission aren't talking about Rust enough, yikes! Let's fix that!" I'm obviously pointing to a solution: have a standard module that any Rust program can depend on coming from the language, which has a few sanely named types. Rather than every program defining its own.
Spivak 2y ago
Is it any better calling it an int where it's assumed to be an i32 and 30 of the bits are wasted.
- kazinator 2y ago
  what you call things matters, so yes, it is better.
itishappy 2y ago
Except defining your types with arbitrary names is still hardware dependent, it's just now something you have to remember or guess. Can you remember the name for a 128 bit integer in your preferred language off the top of your head? I can intuit it in Rust or Zig (and many others). In D it's... oh... it's int128. https://dlang.org/phobos/std_int128.html https://dlang.org/phobos/std_int128.html https://github.com/dlang/phobos/blob/master/std/int128.d https://github.com/dlang/phobos/blob/master/std/int128.d
- WalterBright 2y ago
  It was actually supposed to be `cent` and`ucent`, but we needed a library type to stand in for it at the moment.
- kazinator 2y ago
  In C it will almost certainly be int128_t, when standardized. 128 bit support is currently a compiler extension (found in GCC, Clang and others). A type that provides a 128 bit integer exactly should have 128 in its name. That is not the argument at all. The problem is only having types like that, and stipulating nonsense like that the primary "go to" integer type is int32.