Thread: Loading a bitmap

> But that doesn't work for 64-bit machines - many 64-bit systems have a int that is 32-bit,
> and a long that is 64-bit. Or both being 32-bit.
But is that more for transitional reasons to prevent breakage of existing code, and still claim "64-bit" on the box?

Though with only 2 widths to play with (16 or 32), int had to be the same as either short or long. But with 16/32/64, the compiler writers now have the freedom to make distinct choices.

Originally Posted by Salem

> But that doesn't work for 64-bit machines - many 64-bit systems have a int that is 32-bit,
> and a long that is 64-bit. Or both being 32-bit.
But is that more for transitional reasons to prevent breakage of existing code, and still claim "64-bit" on the box?

Not really. It's practical to have a basic integer type that takes "several million" as a count. If you want MUCH more than that, you have 64-bit "long" numbers. Obviously, choosing a 32-bit long would be a matter of "make the least amount of changes to the current software" approach. But a 32-bit "int" is perfectly adequate for almost any software. How often do you use "long long" or "__int64" [as appropriate] in your code?

Though with only 2 widths to play with (16 or 32), int had to be the same as either short or long. But with 16/32/64, the compiler writers now have the freedom to make distinct choices.

Exactly, a 32-bit int is "big enough for most things". It takes half the space of a 64-bit integer, and whilst RAM-space may not matter much when you have many gigabytes, it's still important to keep the caches filled with useful stuff, and if the upper 32 bits are always filled with either all ones or all zeros, it's a bit of a waste to stuff this in the cache - and caches, even the largest ones, is still only up to a few gigabytes.

Edit: Aside from fixing a broken quote tag, I would like to add that Windows and Linux have taken a different approach to the above choices:
In windows, a long is 32 bits. In Linux, a long is 64 bits.

--
Mats