6 ms·

This is why I never ever use size_t over int. I’m a newbie C++ programmer tho, wrote less than 10kloc of C++ code, but my both feet are bleeding cause of exactl

This is why I never ever use size_t over int. I’m a newbie C++ programmer tho, wrote less than 10kloc of C++ code, but my both feet are bleeding cause of exactly this.

mikeash 8y ago
Be careful, int is usually 32-bit even on 64-bit systems. Using int all over is a good way to experience mysterious failures when dealing with chunks of data larger than 2GB, which is definitely a real possibility these days. Consider ssize_t, intptr_t, or int64_t any time you’re not absolutely sure you’ll never exceed 2^31-1.
- marcosdumay 8y ago
  Int is only 32 bits on 64-bit Windows, that for some reason didn't go along with the times. Every other mainstream 64 bits environment has 64 bits ints, even on ARM. But it's only guaranteed to be 16 bits anyway, the same guarantee you have for size_t.
  - ChrisSD 8y ago
    I think the point being made is that size_t is guaranteed to be large enough to hold the size of any object. The other integer types don't have this guarantee.
    - marcosdumay 8y ago
      Size_t is guaranteed to hold values up to 65535. That's twice as long as int and much smaller than long.
      - mikeash 8y ago
        size_t is guaranteed to hold values large enough to index into any array you can allocate. On a 64-bit system with an allocator that supports allocations larger than 4GB, that means size_t has to be larger than 32 bits. If it's an LLP64 system, size_t will be larger than long. If the value represents an index or size of something in memory, use size_t. Consider ssize_t if you need negative values and are certain you never need the larger half of the size_t range.
  - tedunangst 8y ago
    That's long, not int. Approximately nobody has 64 bit int.
    - nwmcsween 8y ago
      That's a good approximation :)
  - mikeash 8y ago
    Huh? Linux and Darwin both have 32-bit int. I’m sure there are some where it’s 64-bit, but the only one I’m aware of is old Cray systems. C makes it hard to have anything bigger than 32-bit int. The standard integer types are char, short, int, long, and long long, and if int is 64-but then you’ll lack a standard type for 8, 16, or 32 bit integers, which is inconvenient. Nothing says you have to have those, or that you can’t make some implementation-specific type to fill the gap, but it’s messy.
    - ChrisSD 8y ago
      With C99 I think it's better to use the fixed (or minimum) sized types from stdint.h when my requirements differ from what C guarantees. I prefer to be as explicit as possible in code (when appropriate) so as to to avoid this sort of confusion.
      - mikeash 8y ago
        I generally agree. I'm speaking more from the implementor's side: if you do ILP64, then you either won't have one of 8, 16, or 32-bit integers, or you'll have to make some non-standard type to cover the gap. LP64 and LLP64 let you cover all the sizes you typically want with the standard types. That is, I assume, why 32-bit int on 64-bit systems is so common.
  - blattimwind 8y ago
    The split is LP64 (long is 64 bits, typically Unix) and LLP64 (long long is 64 bits, Windows).
bsder 8y ago
Overflow and underflow on signed types is undefined behavior in C. You should almost always use unsigned types unless you must use a signed type. And you need to think about these kinds of overflow and underflow cases.
scott_s 8y ago
Standard library operations such as length() on a string are defined to return to return a size_type, which is usually going to be an unsigned integer (https://en.cppreference.com/w/cpp/string/basic_string https://en.cppreference.com/w/cpp/string/basic_string). So, you don't always have the option of avoiding it. You could convert to a signed integer, but that's usually going to be a narrowing conversion, which will introduce different subtle behavior. Unfortunately, in C and C++, there's no silver bullet for avoiding subtleties with integers.

This is why I never ever use size_t over int. I’m a newbie C++ programmer tho, wrote less than 10kloc of C++ code, but my both feet are bleeding cause of exactly this.

mikeash 8y ago

Be careful, int is usually 32-bit even on 64-bit systems. Using int all over is a good way to experience mysterious failures when dealing with chunks of data larger than 2GB, which is definitely a real possibility these days. Consider ssize_t, intptr_t, or int64_t any time you’re not absolutely sure you’ll never exceed 2^31-1.

marcosdumay 8y ago
Int is only 32 bits on 64-bit Windows, that for some reason didn't go along with the times. Every other mainstream 64 bits environment has 64 bits ints, even on ARM. But it's only guaranteed to be 16 bits anyway, the same guarantee you have for size_t.
- ChrisSD 8y ago
  I think the point being made is that size_t is guaranteed to be large enough to hold the size of any object. The other integer types don't have this guarantee.
  - marcosdumay 8y ago
    Size_t is guaranteed to hold values up to 65535. That's twice as long as int and much smaller than long.
    - mikeash 8y ago
      size_t is guaranteed to hold values large enough to index into any array you can allocate. On a 64-bit system with an allocator that supports allocations larger than 4GB, that means size_t has to be larger than 32 bits. If it's an LLP64 system, size_t will be larger than long. If the value represents an index or size of something in memory, use size_t. Consider ssize_t if you need negative values and are certain you never need the larger half of the size_t range.
- tedunangst 8y ago
  That's long, not int. Approximately nobody has 64 bit int.
  - nwmcsween 8y ago
    That's a good approximation :)
- mikeash 8y ago
  Huh? Linux and Darwin both have 32-bit int. I’m sure there are some where it’s 64-bit, but the only one I’m aware of is old Cray systems. C makes it hard to have anything bigger than 32-bit int. The standard integer types are char, short, int, long, and long long, and if int is 64-but then you’ll lack a standard type for 8, 16, or 32 bit integers, which is inconvenient. Nothing says you have to have those, or that you can’t make some implementation-specific type to fill the gap, but it’s messy.
  - ChrisSD 8y ago
    With C99 I think it's better to use the fixed (or minimum) sized types from stdint.h when my requirements differ from what C guarantees. I prefer to be as explicit as possible in code (when appropriate) so as to to avoid this sort of confusion.
    - mikeash 8y ago
      I generally agree. I'm speaking more from the implementor's side: if you do ILP64, then you either won't have one of 8, 16, or 32-bit integers, or you'll have to make some non-standard type to cover the gap. LP64 and LLP64 let you cover all the sizes you typically want with the standard types. That is, I assume, why 32-bit int on 64-bit systems is so common.
- blattimwind 8y ago
  The split is LP64 (long is 64 bits, typically Unix) and LLP64 (long long is 64 bits, Windows).

bsder 8y ago

Overflow and underflow on signed types is undefined behavior in C. You should almost always use unsigned types unless you must use a signed type. And you need to think about these kinds of overflow and underflow cases.

scott_s 8y ago

Standard library operations such as length() on a string are defined to return to return a size_type, which is usually going to be an unsigned integer (https://en.cppreference.com/w/cpp/string/basic_string https://en.cppreference.com/w/cpp/string/basic_string). So, you don't always have the option of avoiding it. You could convert to a signed integer, but that's usually going to be a narrowing conversion, which will introduce different subtle behavior. Unfortunately, in C and C++, there's no silver bullet for avoiding subtleties with integers.