Difference between 'int' and 'long int'

Okay so here's the description for 'int' and 'long int':

They both take up 4 bytes. The signed and unsigned values of 'int' AND 'long int' is:

int = -2147483648 to 2147483647; and 0 to 4294967295.
long int = -2147483648 to 2147483647; and 0 to 4294967295.

Both 'int' and 'long int' have the same properties for signed and unsigned. So what makes them different, and when should I replace 'int' with 'long int'..?

You could refer to the standard:

Quote:

---

Originally Posted by C++11 Clause 3.9.1 Paragraph 2-3a

There are five standard 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. There may also be implementation-defined extended signed integer types. The standard and extended signed integer types are collectively called signed integer types. 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.

For each of the standard signed integer types, there exists a corresponding (but different) standard unsigned integer type: "unsigned char", "unsigned short int", "unsigned int", "unsigned long int", and "unsigned long long int", each of which occupies the same amount of storage and has the same alignment requirements as the corresponding signed integer type; that is, each signed integer type has the same object representation as its corresponding unsigned integer type.

---

Also, C++11 refers to C99 on certain points, including the minimum limits for these integer types:

Code:

---

#define INT_MAX +32767
#define INT_MIN -32767
#define LONG_MAX +2147483647
#define LONG_MIN -2147483647
#define UINT_MAX 65535
#define ULONG_MAX 4294967295

---

> They both take up 4 bytes.
On YOUR machine.

The standard only requires ints to be stored in at least 16 bits, and longs in 32 bits.

You should use a long int if you want to make your code super portable, and you want to store integers larger than 16 bits.

That's answer 1 of the c-faq: Question 1.1

Quote:

---

Originally Posted by Salem

>
You should use a long int if you want to make your code super portable...

---

I've heard people say that, but what are you meaning by "portable".. Not the definition ofcourse, but WHAT is portable - the program?- and where would it be going?- Someone else's computer?

Not just "someone else's computer" but a system (computer, OS & compiler) that is different from the one you compiled the program with. So if someone made a computer out of tinkertoys and implemented a conformant C compiler for it, your program would work there as well.

Quote:

---

Originally Posted by cplusplusnoob

I've heard people say that, but what are you meaning by "portable".. Not the definition ofcourse, but WHAT is portable - the program?- and where would it be going?- Someone else's computer?

---

Code being portable means that you can take that code and run it through a compiler for any system and end up with an executable, without any modifications.
That is, it is both system and architecture independent. Compile your code and it just runs. Everywhere. Anytime.

Quote:

---

Originally Posted by oogabooga

Not just "someone else's computer" but a system (computer, OS & compiler) that is different from the one you compiled the program with. So if someone made a computer out of tinkertoys and implemented a conformant C compiler for it, your program would work there as well.

---

Oh okay!

Sorry I guess what I'm not understanding is why would 'long int' be more portable than 'int'? Are we going into the bits and bytes?

Quote:

---

Originally Posted by cplusplusnoob

Oh okay!

Sorry I guess what I'm not understanding is why would 'long int' be more portable than 'int'? Are we going into the bits and bytes?

---

What Salem is trying to say is that IF you need an integer > 16 bits AND you want your code to be (super) portable, THEN use long int.
An int is not guaranteed to be larger than 16 bits, hence this may not hold true on some machines.
Of course, on many machines, an int really is larger than 16 bits, hence the (super) clause.

Thank you for you clarification, but how would you know how many bits your integer is?

You can experimentally measure it at runtime with the sizeof operator.
Or you can consult the compiler manual for the given platform.
EDIT: Clarification: sizeof is a compile time operator, so you can use it to make compile-time decisions, but that easiest way to know the size of something is just to print it out using sizeof at runtime!

You read the system's specification, I guess.

Well thank you for your help! And ofcourse thank you everyone else who helped! All of you are awesome, and very knowledgable, at what you do!

So before I go let me get everything straight:

Standardly, an int holds atleast 16-bits, although other OS or compiliers may find it different. And if your integer is larger than 16-bits and you transport your source code, or programs exe. file and compile it or run it on a different OS/ or compilier it may not run because their system doesn't pass the integer as an 'int' because its bits are over the, if I may, "limit"?

The standard specifies an int shall be at least 16 bits. Essentially, it tells compiler vendors that they may define the size of an int to be whatever they want, so long as it isn't less than 16 bits.
If you use an int and assume it is larger than 16 bits, then you may get unexpected results on other platforms (because they define it to be 16 bits). Yes, it will run. But it might not run in the way you expect it to (example, overflows).
Also, you can't take an exe file and drop it on another architecture or platform. It won't work. You need to take the source and compile it on the other platform.

OH I SEE!

Can the programmer himself manually define how many bits an int can hold (e.g. 6 bits, although that makes no sense and a waste of space, is that possible? Or is 'long' and 'short' the only way to define the int.