Hello everybody its a pretty dumb question 
but why do we use int not long. Thus long can store bigger numbers and small numbers. I think long covers the range of integer range. I couldn't find any results about this problem. I am not a beginner but I am not pro :). I know java too. But I never worked with long type in java .
Thank you very much
Berathan
Hello and welcome,
Long take twice more memory than int, on devices with limited memory you have to consider using the smallest variable possible 
For example if you are sure your number will range between 0 and 255, then you should use a variable of type byte (or "uint8_t", same thing) which take one byte. An int take 2 bytes, a long take 4 bytes.
unsigned long is used with millis() and micros().
So you use it when it's needed.
As well as using more RAM, long calculations take more time to execute. The arduino is an 8 bit processor so every time you add two long numbers together it has to load and unload bytes 16 times.
If you want to use longs, get a 32 bit processor.
Lots of times we can get by with byte, but the use of int is almost reflexive.
Thanks for fast reply 
Then why dont we use byte ledPin=13; instead of int ledPin=13; ?
Who "we"? Bad practice from the examples on the playground and on the forum.
I always use the appropriate variable type, even if I use an Arduino Mega 2560. Even then, I try to optimize as much as possible, such as using bitwise operations to store for example 2 numbers ranging between 0 to 15 in a single byte, or 8 booleans in a single byte...
berathan90:
Thanks for fast reply
Then why dont we use byte ledPin=13; instead of int ledPin=13; ?
Because large parts of the Arduino core and many of the examples supplied are either badly written or hacked together without consideration for efficiency.
berathan90:
Thanks for fast reply
Then why dont we use byte ledPin=13; instead of int ledPin=13; ?
If the sketch doesn't use all memory and meet its speed requirements you can even say
unsigned long ledPin = 13;
but if sketches grow bigger you don't have that luxury.
Note: never use
float ledPin = 13;
as the float can be truncated to 12 when used.
And even better, assuming you aren't going to change it is
const byte ledPin = 13;
Traditionally, the "int" type is the "natural" type for the processor - i.e., it's the size of the processor's registers. This can be 4, 8, 16, 32... bits, but usually the processor can handle it as fast as possible.
Type "long" is for when you need more precision, even at the expense of slower code. Type "byte" is good when you need to control the size, regardless of the processor's register size, or if memory space is at a premium. In classic C, type "char" is usually 8 bits long and hence is used a a form of "byte".
Then there's type "short"....
Logically, many things would actually be well suited to type "bool" --- i.e., only two possible values. I don't know how type "bool" is implemented, but I expect it takes one byte of storage per variable.
bobmon:
Traditionally, the "int" type is the "natural" type for the processor - i.e., it's the size of the processor's registers. This can be 4, 8, 16, 32... bits, but usually the processor can handle it as fast as possible.Type "long" is for when you need more precision, even at the expense of slower code. Type "byte" is good when you need to control the size, regardless of the processor's register size, or if memory space is at a premium. In classic C, type "char" is usually 8 bits long and hence is used a a form of "byte".
Then there's type "short"....
Logically, many things would actually be well suited to type "bool" --- i.e., only two possible values. I don't know how type "bool" is implemented, but I expect it takes one byte of storage per variable.
However with avr-gcc, and int isn't the native size for 8bit uCs, its 16bit (presumably because a byte was considered too small, not sure). A short is the same size as an int in this environment.
Also, a long doesn't really give more 'precision' per say, it gives a greater 'range'. All of the integer types have a precision of 1, hence they are integers.
Now if you were doing fixed point maths with them, then yes you could use greater precision, or greater range, or a bit of both.
Also, a long doesn't really give more 'precision' per say, it gives a greater 'range'. All of the integer types have a precision of 1, hence they are integers.
Now if you were doing fixed point maths with them, then yes you could use greater precision, or greater range, or a bit of both.
You're right, I misspoke. I'm thinking of "precision" in the sense of dividing up the full range of minimum to maximum, but better to just call it the range.
bools use a whole byte also.
Can use bit manipulation on a byte to "compress" 8 bits into 1 byte.
if ( (0b0000001 & maskedByte) >=1 ){
// bit being tested is not 0, so do something
}
if ( (0b0000010 & maskedByte) >=1 ){
// bit being tested is not 0, so do something
}
if ( (0b0000100 & maskedByte) >=1 ){
// bit being tested is not 0, so do something
}
etc.
I often forget when I mask that the result is something besides 0 & 1, so I've been trying to test for 0 and >=0 (i.e. 1,2,4,6,16,32,64,128 , or 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80).
The C standard mandates that the minimum size of an int is 16 bits.
For portability and optimization is best to NOT use native types like,
unsigned char, int, long for etc... for integers because they vary between environments.
Use the types in stddef.h
That gives you the ability to specify things like
give me a unsigned 8 bit integer
give me a 16 bit integer
give me a 32 bit unsigned integer.
give me the fastest integer that is at least 8 bits.
give me the fastest unsigned integer that is at least 16 bits
etc...
That value of this is that it lets the compiler optimize the type
when possible.
So many times people are being too specific on the types they use.
For example, while an 8 bit value might be more efficient on the AVR
so unsigned char is used, however that might be less efficient on some other processor.
If the code runs on multiple processors it is best to specify what is
really needed in terms of minimum bits, speed etc rather than try
to guess or figure out the native type.
Use exact bit width types when that matters, and when it doesn't,
which is often the case, give the compiler the freedom to pick something larger if it can better
optimize the code using a larger type.
Here is a link to the stdint page for the AVR:
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html
Since stdint is part of the C standard, so it should work on all implementations
and processors.
--- bill
CrossRoads:
bools use a whole byte also.Can use bit manipulation on a byte to "compress" 8 bits into 1 byte.
if ( (0b0000001 & maskedByte) >=1 ){
// bit being tested is not 0, so do something
}
if ( (0b0000010 & maskedByte) >=1 ){
// bit being tested is not 0, so do something
}if ( (0b0000100 & maskedByte) >=1 ){
// bit being tested is not 0, so do something
}etc.
I often forget when I mask that the result is something besides 0 & 1, so I've been trying to test for 0 and >=0 (i.e. 1,2,4,6,16,32,64,128 , or 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80).
The ">=1" is redundant and unnecessary, anything not 0 is evaluated as true.
And if you want to test for falseness, you can use the ! operator.
The arduino is an 8 bit processor so every time you add two long numbers together it has to load and unload bytes 16 times.
That seems like a misleading statement. To handle a (32-bit) long, it takes approximately 4 times as many instructions as it does to do the same operation on an 8-bit operation. For an add, that does end up being about 16 instructions, but the similar 8-bit add would have used 4. ("loadA, loadB, add, storeC" vs "loadA0, loadA1, loadA2, loadA3, loadB0, loadB1, loadB2, loadB3, add0, adc1, adc2, adc3, storeC0, storeC1, storeC2, storeC3")
Question on the AVR is why "we" use int instead of byte (aka unsigned char).
UNO has 2048 bytes RAM for heap and stack. Wasteful habits will lead to crashes sooner.
Is there a platform that uses byte/char that is not 8 bit? And wchar (2 byte wide char) is not char.
When the hardware that I am working on is so different as AVR is to a PC, I would rather know and code to the differences and make the changes than to play dumb and be ignorant for the sake of portability that as often won't work out so simple and easy as winks and wishes would have.
If you don't like my choices, find&replace is right there in the IDE. Just don't blame me if it crashes.
For computers that had 9 bit 'bytes'
Also crays could only work with 32 bit values, so 8 bit characters were stuffed into the 4 byte word.
DEC ran 12 bit words. As the EE guys that I got "go for smoke" from used to say "either 4 too many or 4 too few".