5 ms·
As far as I can see it's just used as a counter and doesn't really relate to pointers in any way. Why is int not large enough for this use case? EDIT: Answer f
by threatripper 5y ago
As far as I can see it's just used as a counter and doesn't really relate to pointers in any way. Why is int not large enough for this use case?
EDIT: Answer from the developers here https://stackoverflow.com/a/45873222 https://stackoverflow.com/a/45873222 it's about compatibility with other types used for related purposes.
- amelius 5y agoWhat if you were counting bits instead of bytes?
- threatripper 5y agoBits don't appear in array sizes as we use bytes as smallest addressable unit on all relevant platforms.
- amelius 5y agoBut you could imagine a vector of booleans which you can subscript per boolean.
- threatripper 5y agoImaginable: Yes, Relevant: No
- hedora 5y agoCurrent intel 64 bit machines only have 57 bits of address space. The top bits of the pointers are wasted.
- smithza 5y agoI have made a point of using uint16_t, uint32_t, int16_t, int32_t, etc. to be explicit. Some don't like the look, but it is explicit and helpful for me.
- dgrunwald 5y agoThere are 64 bit systems where "long int" still is only 32 bits. (most importantly: Windows x64) In general, the C integer types cannot be relied upon; typedefs like uint32_t, size_t, ptrdiff_t should always be preferred.
- threatripper 5y agoYes, i see this as a shortcoming of C. Too many assumptions were crammed into the "int" size.
- mpfundstein 5y agoso why not use uint64_t ? makes semantically more sense, doesn't it?
- ncmncm 5y agostd::uint64_t is optionally supported. Strange but true. All actual machines do support it, but the Standard can't assume it's there.