6 ms·

>If you find yourself typing char or int or short or long or unsigned into new code, you're doing it wrong. int is a type that's at least 16 bits large. I can'

• officialtedleo 11y ago
  > If I specify that I want a type that's 32 bits large, my code won't run on 16 bit systems. Why not?
  • ue_ 11y ago
    Nevermind, I'm wrong. I've read that if one uses int64_t with a compiler that targets a 32 bit system, doing various operations on the int64_t variable will be much slower because more machine code instructions need to be generated. The point stands: Why not use int if one is looking to target any architecture that C will run on?
    • Gankro 11y ago
      If 16 bits is enough, use an explicitly 16-bit integer. If you want something architecture-sized (e.g. because it's dealing with pointers/addresses), use things like `size_t` which makes the intent much more clear, and which are better defined. In most places, if you're using an `int` for non-address-y stuff you're just wasting space on wider archs, or you're overflowing on less wide ones. The only exception off the top of my head is "I have an array of bytes, but want to bulk process more efficiently than u8 would allow". Things like `size_t` (or explicit SIMD types!) are still probably a better choice there, if only to simplify the rule to "just don't use int".
      • nwmcsween 11y ago
        You don't know how hardware works...
      • vardump 11y ago
        > If 16 bits is enough, use an explicitly 16-bit integer. This will often generate more code. So don't do this except when it saves a modest amount of memory.
    • lmm 11y ago
      > I've read that if one uses int64_t with a compiler that targets a 32 bit system, doing various operations on the int64_t variable will be much slower because more machine code instructions need to be generated. Yep, but presumably you picked int64_t for a reason. If you want a 32-bit variable, use int32_t. It would be an extremely rare platform on which int16_t is noticeably slower than int. The very minor platform-specific performance improvement you might get from using int rather than int16_t is very rarely worth the risk of introducing an overflow on the few platforms where int is 16 bits[1], and not noticing it because int is longer than that on the platform you develop on. [1] remember that a signed integer overflow is undefined behaviour which should be regarded as equivalent to a security flaw - the compiler is permitted to send all data your program has access to to the mafia if your program contains a signed integer overflow anywhere, and some compilers will
    • Triave 11y ago
      "int" doesn't reveal the intention of the programmer - they might just have used it because it's "int", not because it changes size based on what system you are targeting. If they used 'int_fast16_t' from <stdint.h>, you have at least an idea that they considered that it might only be 16 bits, and that it can be a larger type on systems where operations on 64-bit types are faster.
• AndyKelley 11y ago
  If 16 bits is enough, then you should be using int16_t. If 16 bits is not enough, then you should not be using int.
  • DSMan195276 11y ago
    Except not really. You should use an int_fast16_t, which is the fastest integer type that has at least 16 bits. There's no reason to force a 16-bit integer which may carry performance implications when it's not necessary.
    • AndyKelley 11y ago
      Here is an IRC log of a discussion[1] I had about this topic in the #musl IRC channel. The folks in this channel are the developers behind musl-libc[2]. The conclusion drawn is that some poor design decisions were made that make the fast types not worth using. [1]: https://gist.github.com/andrewrk/ac66b24a0a202d87cea7 https://gist.github.com/andrewrk/ac66b24a0a202d87cea7 [2]: http://www.musl-libc.org/ http://www.musl-libc.org/
      • DSMan195276 11y ago
        Thanks for that, that's pretty interesting to read about. Admittedly, I'm not sure I've ever actually used a int_fastN_t type in my code - I just kinda assumed they served their purpose. Reading that log I can see the obvious problems with those types which I never realized since I never really looked into them that much. int_least16_t seems like a perfectly fine substitute though, I don't really know why int_leastN_t and int_fastN_t would be different in the first place. That said, there's really no way to correctly pick the "perfect" integer size for every platform - There's just too many variables. IMO I much prefer to just use 'int' when I know the values are going to be small - smaller then a 16-bit value - and I don't care about the actual width. But obviously it's a hot topic for some - As long as you follow the standard in regards to it's size then it doesn't really matter what integer value you choose to use. I prefer saving the fixed-width integer types for situations when I know I need such a size.
      • 11y ago
• caf 11y ago
  You are right, and this advice is wrong. `int` is at least 16 bits, `long` is at least 32 bits, `long long` is at least 64 bits, and `size_t` is big enough to hold the size of the largest object you can allocate - and in most cases that is all you need to know. The exact width types can be useful if you're marshalling data to and from an exact-width format, like a network protocol or file format.
  • Nursie 11y ago
    I disagree. You should know the range of values that you are expecting to be holding in an integer, and choose the type accordingly.
    • caf 11y ago
      That does not contradict what I said. When choosing the type, all you need is a type that has at least the range you require, and the basic types give guaranteed minimum ranges. The only advantage to choosing an exactly-N-bit type over an at-least-N-bit type is possibly saving some space in very large allocations. In most cases this won't be important - and when it is, the mininmum-width types from stdint.h (eg int_least32_t) are more apropos than the exact-width types. The disadvantage is the impedance mis-match with all the existing libraries of code using the basic types.
• CrLf 11y ago
  Don't agree with that either. IMHO, "int" is perfectly acceptable if you just want to use the platform's preferred word size (and are fine with the possibility of it being only 16bit). Also, "char" is perfectly acceptable too if you're dealing with ASCII. This is valid for both the signed and unsigned variants. The general rule should be using the language types as long as you're not assuming something about their size, only then use "stdint.h" because it makes your assumption more explicit. Now, nobody uses "short" or "long" to mean "something smaller or shorter than the platform's int", so these are usually something to avoid.
  • xcgvgh 11y ago
    I use long when I need an int that can always represent ranges in -2^31-1 to 2^31-1, no assumptions necessary. Same goes for unsigned versions and long long.
    • lmm 11y ago
      So int32_t, but making overflow bugs intermittent and architecture-dependent? Why would you want that?
  • AndyKelley 11y ago
    Is "the platform's preferred word size" meaningful? On x86_64, pointers are 8 bytes, but it's still faster to use smaller registers if you don't need the extra bits. For this system, at least, the correct type is the smallest one that is big enough to hold the maximum value your integer could be.
    • mpu 11y ago
      Bullshit, on x64 all 32 or 64 bit base arithmetic operations have the exact same cost, except the 64 bit version is one byte longer because of a REX prefix. This is why 32 bits is the natural int size for x64.
      • amadvance 11y ago