Hacker News Reader

Comment by Google234 | Hacker News Reader

Int is not large enough for 64 bit system. ptrdiff Is always the correct size and is signed unlike size_t

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 it's about compatibility with other types used for related purposes.

There 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.

Yes, i see this as a shortcoming of C. Too many assumptions were crammed into the "int" size.

so why not use uint64_t ? makes semantically more sense, doesn't it?

std::uint64_t is optionally supported. Strange but true. All actual machines do support it, but the Standard can't assume it's there.

What if you were counting bits instead of bytes?

I 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.

Bits don't appear in array sizes as we use bytes as smallest addressable unit on all relevant platforms.

But you could imagine a vector of booleans which you can subscript per boolean.

Current intel 64 bit machines only have 57 bits of address space. The top bits of the pointers are wasted.

Imaginable: Yes, Relevant: No

I'm surprised that negative numbers are needed here. But I don't know C++ and my knowledge about latches in Java is spotty at best. Don't know anything about barriers.

The ptrdiff doesn't have to be signed. I'm pretty sure negative numbers aren't used in this context.

Reply on news.ycombinator.com