As I've learned recently, a long in C/C++ is the same length as an int. To put it simply, why? It seems almost pointless to even include the datatype in the language. Does it have any uses specific to it that an int doesn't have? I know we can declare a 64-bit int like so:
long long x = 0;
But why does the language choose to do it this way, rather than just making a long well...longer than an int? Other languages such as C# do this, so why not C/C++?
When writing in C or C++, every datatype is architecture and compiler specific. On one system int is 32, but you can find ones where it is 16 or 64; it's not defined, so it's up to compiler.
As for long and int, it comes from times, where standard integer was 16bit, where long was 32 bit integer - and it indeed was longer than int.
int and short were the same size on many platforms. If int were still 16 bits, then that would be a 'legacy' thing. int is basically meant to represent a very efficient size for integers on whatever platform you happen to be on. –
Ene uintNN_t etc types to clear things up. –
Gall int and long of different size. –
Bisayas int is 16 bits on AVR microcontrollers, which are common teaching tools in university CS courses. –
Detriment long and int are different sizes, and the future shows no signs of not having such platforms. You don't describe the actual rules governing the sizes of types in C at all. –
Bisayas int and 64-bit long are very common. (I'm typing this comment on such a system.) –
Involucre The specific guarantees are as follows:
char is at least 8 bits (1 byte by definition, however many bits it is)short is at least 16 bitsint is at least 16 bitslong is at least 32 bitslong long (in versions of the language that support it) is at least 64 bitsThus it makes sense to use long if you need a type that's at least 32 bits, int if you need a type that's reasonably fast and at least 16 bits.
Actually, at least in C, these lower bounds are expressed in terms of ranges, not sizes. For example, the language requires that INT_MIN <= -32767, and INT_MAX >= +32767. The 16-bit requirements follows from this and from the requirement that integers are represented in binary.
C99 adds <stdint.h> and <inttypes.h>, which define types such as uint32_t, int_least32_t, and int_fast16_t; these are typedefs, usually defined as aliases for the predefined types.
(There isn't necessarily a direct relationship between size and range. An implementation could make int 32 bits, but with a range of only, say, -2**23 .. +2^23-1, with the other 8 bits (called padding bits) not contributing to the value. It's theoretically possible (but practically highly unlikely) that int could be larger than long, as long as long has at least as wide a range as int. In practice, few modern systems use padding bits, or even representations other than 2's-complement, but the standard still permits such oddities. You're more likely to encounter exotic features in embedded systems.)
int is at least 32 bits if you're on an implementation that makes that guarantee; all POSIX-conforming systems do so. If you make that assumption, your code won't be portable to systems with 16-bit int. That may or may not be a good tradeoff. (And being "politically correct" is irrelevant.) –
Involucre long is not the same length as an int. According to the specification, long is at least as large as int. For example, on Linux x86_64 with GCC, sizeof(long) = 8, and sizeof(int) = 4.
long is not the same size as int, it is at least the same size as int. To quote the C++03 standard (3.9.1-2):
There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment); the other signed integer types are provided to meet special needs.
My interpretation of this is "just use int, but if for some reason that doesn't fit your needs and you are lucky to find another integral type that's better suited, be our guest and use that one instead". One way that long might be better is if you 're on an architecture where it is... longer.
long might be better if you write portable code and you need integer of at least 32-bits. long is guaranteed to be not less than 32-bits by C standard. int is not guaranteed (it may be 16-bits). –
Chapen looking for something completely unrelated and stumbled across this and needed to answer. Yeah, this is old, so for people who surf on in later...
Frankly, I think all the answers on here are incomplete.
The size of a long is the size of the number of bits your processor can operate on at one time. It's also called a "word". A "half-word" is a short. A "doubleword" is a long long and is twice as large as a long (and originally was only implemented by vendors and not standard), and even bigger than a long long is a "quadword" which is twice the size of a long long but it had no formal name (and not really standard).
Now, where does the int come in? In part registers on your processor, and in part your OS. Your registers define the native sizes the CPU handles which in turn define the size of things like the short and long. Processors are also designed with a data size that is the most efficient size for it to operate on. That should be an int.
On todays 64bit machines you'd assume, since a long is a word and a word on a 64bit machine is 64bits, that a long would be 64bits and an int whatever the processor is designed to handle, but it might not be. Why? Your OS has chosen a data model and defined these data sizes for you (pretty much by how it's built). Ultimately, if you're on Windows (and using Win64) it's 32bits for both a long and int. Solaris and Linux use different definitions (the long is 64bits). These definitions are called things like ILP64, LP64, and LLP64. Windows uses LLP64 and Solaris and Linux use LP64:
Model ILP64 LP64 LLP64 int 64 32 32 long 64 64 32 pointer 64 64 64 long long 64 64 64
Where, e.g., ILP means int-long-pointer, and LLP means long-long-pointer
To get around this most compilers seem to support setting the size of an integer directly with types like int32 or int64.
long is still required to be at least 32 bits. There is no requirement that short is half the width of long, or that long long is twice the width of long -- and neither is true on the system I'm using (16-bit short, 64-bit long, 64-bit long long). –
Involucre int32_t and int64_t in <stdint.h> (introduced in C in 1999 and later adopted by C++). That's assuming the implementation has types that support the requirements; not all do. –
Involucre © 2022 - 2024 — McMap. All rights reserved.
intbe the "natural" size for the processor, which may not always be as big as along. The standard also guarantees that alongis at least as long as anint, so the fact that they are equal sizes are not always guaranteed. – Summarizeintandlongalways being the same size; I am currently fixing a ton of portability issues in one of our C++ static libraries as we transition to a 64-bit architecture – Fourteenthsizeof(long) == sizeof(int)only on 32-bit architectures or 64-bit Windows, where it comes as a shock to programmers who are used tosizeof(long) == sizeof(void *). – Onachar,short,long, andlong long.intis just a "typedef" for whichever is fastest on my system. – Stanleighlongdoes not meanlonger than int(It means that it's at least the size ofintand possibly longer - Usually not the case). However, C does guarantee that, at a minimum,unsigned intcan hold at least65,535, whilesigned longis2,147,483,647. Though I'd argue you should know more about the architecture of where you're building, this at least guarantees that you'll always be able to hold up to2,147,483,647number if you uselong. – Topercharis 8-bits,shortis 16-bits,intis 16-bits, andlongis 32-bits. So in this caseshortandintare identical, whilelongtruly is longer. – Scevour