What is the difference between an int and a long in C++?

Question

Correct me if I am wrong,

int is 4 bytes, with a range of values from -2,147,483,648 to 2,147,483,647 (2^31)
long is 4 bytes, with a range of values from -2,147,483,648 to 2,147,483,647 (2^31)

What is the difference in C++? Can they be used interchangeably?

Relive

In my VS2005 running on 32 bit processor, default size of int is 4 bytes. – Gylys

Related: is long guaranteed to be at least 32 bits? – Knoxville

If you want to write portable code, consider using #include <stdint.h> and then the types which tell the size. E.g. uint32_t. On a new platform, then you only need to make sure stdint.h gets it right for that particular platform and your code works as intended. – Fertilizer

Answer 1

It is implementation dependent.

For example, under Windows they are the same, but for example on Alpha systems a long was 64 bits whereas an int was 32 bits. This article covers the rules for the Intel C++ compiler on variable platforms. To summarize:

  OS           arch           size
Windows       IA-32        4 bytes
Windows       Intel 64     4 bytes
Windows       IA-64        4 bytes
Linux         IA-32        4 bytes
Linux         Intel 64     8 bytes
Linux         IA-64        8 bytes
Mac OS X      IA-32        4 bytes
Mac OS X      Intel 64     8 bytes  

Creath

I think we should consider combining this answer (an answer by example) with some of the details below regarding the C++ standard. The draft for C++0x is at open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2798.pdf and it is marked up so you can see the differences between it and the last rev. – Boulevard

Including something on the relative size-wise order of the types yields way more information than enumerating sizes for different platforms - like @Kevin states so nicely. (-1vote) – Litmus

Some compilers even have flags that allow you to modify the default size of int and long ie force them to 8 or 16 etc. See you compiler documentation for details. – Cymatium

NB that these are the sizes of long – Ora

Please include the sizes of int as well. – Breaux

A brilliant feature of gcc is that even when "int" and "long" have the same representation, that doesn't mean an "int*" can update a "long", or a "long*" can update an "int", even if the pointers are cast through void*. – Tiro

Answer 2

The only guarantee you have are:

sizeof(char) == 1
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)

// FROM @KTC. The C++ standard also has:
sizeof(signed char)   == 1
sizeof(unsigned char) == 1

// NOTE: These size are not specified explicitly in the standard.
//       They are implied by the minimum/maximum values that MUST be supported
//       for the type. These limits are defined in limits.h
sizeof(short)     * CHAR_BIT >= 16
sizeof(int)       * CHAR_BIT >= 16
sizeof(long)      * CHAR_BIT >= 32
sizeof(long long) * CHAR_BIT >= 64
CHAR_BIT         >= 8   // Number of bits in a byte

Also see: Is long guaranteed to be at least 32 bits?

Cymatium

your comment should read sizeof(int) * CHAR_BIT >= 16 , since one byte is not necassarily only 8bit. same for sizeof(long long) mate. other than that, alright as far as i can see. – Treasonable

Hmm, this doesn't hold, if sizeof(short) >= sizeof(char) we only know that sizeof(short) >= 1 (not >= 2), which btw goes for all of the types. According to this sizeof(any integral type) >= 1. Which is true, e.g. I remember sizeof(int) == 1 on the Z80, but is there no stronger guarantee for long? – Round

3.9.1.2 of the C++ standard specify that sizeof(long) >= sizeof(int) >= sizeof(short) >= sizeof(char) 5.3.3.1 of the C++ standard specify that sizeof(char), sizeof(unsigned char), and sizeof(signed char) equals to 1. (cont...) – Lithomarge

(...cont) The maximum and minimum values representable by the integral types are defined as macros in <limits.h> (and hence <climits>). Annex E of the C (1990) standard, which are included by reference from the C++ standard, specify the minimum magnitudes of these macros. (cont...) – Lithomarge

(...cont) and they are (2^15)-1, (2^15)-1, (2^31)-1, for short, int, and long respectively, which works out to be the value as posted by Martin York in his response here if CHAR_BIT is 8 (which is also its minimum value). – Lithomarge

@Andreas Magnusson: These values are not explicitly defined. But are implied by the minimum range of each type that must be supported in limits.h – Cymatium

Technically, the guarantee is that short has at least 16 significant bits, and so on. This is stronger on the (very rare) implementations that have padding bits (i.e. bits that are stored in the object, so they count for sizeof, but are not part of the value). – Redundancy

@Giles: Is that not what I said above? sizeof(short) * CHAR_BITS >= 16. Plust a few other things. :-) – Cymatium

Please note that the macro is CHAR_BIT, not CHAR_BITS. – Whole

Fair enough. Comment deleted. – Knoxville

@JohnDibling: You should still leave a link to your answer though. Cross-linking these discussions is useful in a Wiki type ways. – Cymatium

Answer 3

When compiling for x64, the difference between int and long is somewhere between 0 and 4 bytes, depending on what compiler you use.

GCC uses the LP64 model, which means that ints are 32-bits but longs are 64-bits under 64-bit mode.

MSVC for example uses the LLP64 model, which means both ints and longs are 32-bits even in 64-bit mode.

Peruzzi

possibly 0 bytes? hmm – Ora

Answer 4

The C++ specification itself (old version but good enough for this) leaves this open.

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* ;

[Footnote: that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>. --- end foonote]

Heshum

Answer 5

As Kevin Haines points out, ints have the natural size suggested by the execution environment, which has to fit within INT_MIN and INT_MAX.

The C89 standard states that UINT_MAX should be at least 2^16-1, USHRT_MAX 2^16-1 and ULONG_MAX 2^32-1 . That makes a bit-count of at least 16 for short and int, and 32 for long. For char it states explicitly that it should have at least 8 bits (CHAR_BIT). C++ inherits those rules for the limits.h file, so in C++ we have the same fundamental requirements for those values. You should however not derive from that that int is at least 2 byte. Theoretically, char, int and long could all be 1 byte, in which case CHAR_BIT must be at least 32. Just remember that "byte" is always the size of a char, so if char is bigger, a byte is not only 8 bits any more.

Treasonable

I didn't think a byte data type exists in C++. It doesn't, does it? If it does, and a byte can have other sizes than 8 bits, it is just purely stupid. Why would they call it a byte unless it absolutely necessarily is 8 bits? – Romie

Answer 6

It depends on your compiler. You are guaranteed that a long will be at least as large as an int, but you are not guaranteed that it will be any longer.

Shurlocke

Answer 7

For the most part, the number of bytes and range of values is determined by the CPU's architecture not by C++. However, C++ sets minimum requirements, which litb explained properly and Martin York only made a few mistakes with.

The reason why you can't use int and long interchangeably is because they aren't always the same length. C was invented on a PDP-11 where a byte had 8 bits, int was two bytes and could be handled directly by hardware instructions. Since C programmers often needed four-byte arithmetic, long was invented and it was four bytes, handled by library functions. Other machines had different specifications. The C standard imposed some minimum requirements.

Politic

Answer 8

Relying on the compiler vendor's implementation of primitive type sizes WILL come back to haunt you if you ever compile your code on another machine architecture, OS, or another vendor's compiler .

Most compiler vendors provide a header file that defines primitive types with explict type sizes. These primitive types should be used when ever code may be potentially ported to another compiler (read this as ALWAYS in EVERY instance). For example, most UNIX compilers have int8_t uint8_t int16_t int32_t uint32_t. Microsoft has INT8 UINT8 INT16 UINT16 INT32 UINT32. I prefer Borland/CodeGear's int8 uint8 int16 uint16 int32 uint32. These names also give a little reminder of the size/range of the intended value.

For years I have used Borland's explicit primitive type names and #include the following C/C++ header file (primitive.h) which is intended to define the explicit primitive types with these names for any C/C++ compiler (this header file might not actually cover every compiler but it covers several compilers I have used on Windows, UNIX and Linux, it also doesn't (yet) define 64bit types).

#ifndef primitiveH
#define primitiveH
// Header file primitive.h
// Primitive types
// For C and/or C++
// This header file is intended to define a set of primitive types
// that will always be the same number bytes on any operating operating systems
// and/or for several popular C/C++ compiler vendors.
// Currently the type definitions cover:
// Windows (16 or 32 bit)
// Linux
// UNIX (HP/US, Solaris)
// And the following compiler vendors
// Microsoft, Borland/Imprise/CodeGear, SunStudio,  HP/UX
// (maybe GNU C/C++)
// This does not currently include 64bit primitives.
#define float64 double
#define float32 float
// Some old C++ compilers didn't have bool type
// If your compiler does not have bool then add   emulate_bool
// to your command line -D option or defined macros.
#ifdef emulate_bool
#   ifdef TVISION
#     define bool int
#     define true 1
#     define false 0
#   else
#     ifdef __BCPLUSPLUS__
      //BC++ bool type not available until 5.0
#        define BI_NO_BOOL
#        include <classlib/defs.h>
#     else
#        define bool int
#        define true 1
#        define false 0
#     endif
#  endif
#endif
#ifdef __BCPLUSPLUS__
#  include <systypes.h>
#else
#  ifdef unix
#     ifdef hpux
#        include <sys/_inttypes.h>
#     endif
#     ifdef sun
#        include <sys/int_types.h>
#     endif
#     ifdef linux
#        include <idna.h>
#     endif
#     define int8 int8_t
#     define uint8 uint8_t
#     define int16 int16_t
#     define int32 int32_t
#     define uint16 uint16_t
#     define uint32 uint32_t
#  else
#     ifdef  _MSC_VER
#        include <BaseTSD.h>
#        define int8 INT8
#        define uint8 UINT8
#        define int16 INT16
#        define int32 INT32
#        define uint16 UINT16
#        define uint32 UINT32
#     else
#        ifndef OWL6
//          OWL version 6 already defines these types
#           define int8 char
#           define uint8 unsigned char
#           ifdef __WIN32_
#              define int16 short int
#              define int32 long
#              define uint16 unsigned short int
#              define uint32 unsigned long
#           else
#              define int16 int
#              define int32 long
#              define uint16 unsigned int
#              define uint32 unsigned long
#           endif
#        endif
#      endif
#  endif
#endif
typedef int8   sint8;
typedef int16  sint16;
typedef int32  sint32;
typedef uint8  nat8;
typedef uint16 nat16;
typedef uint32 nat32;
typedef const char * cASCIIz;    // constant null terminated char array
typedef char *       ASCIIz;     // null terminated char array
#endif
//primitive.h

Benevolent

C99 mandates that typdefs that look like int32_t, uint64_t, etc are defined by the compiler and have exactly as many bits as the name suggests. Most C++ compilers (including g++) will allow you to use these constants in C++ code. – Companionable

Answer 9

The C++ Standard says it like this :

3.9.1, §2 :

There are five signed integer types : "signed char", "short int", "int", "long int", and "long 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 (44); the other signed integer types are provided to meet special needs.

(44) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>.

The conclusion : it depends on which architecture you're working on. Any other assumption is false.

Ladonna