Sign in to follow this  
Valor Knight

int or short/long?

Recommended Posts

Stupid question, I know but I remember reading that int is unreliable, is it better to use short or a long depending on expected size and ignore ints?most of the time I am using unsigned longs or shorts anyway, just would be good info to know. thanks.

Share this post


Link to post
Share on other sites
Quote:
Original post by Valor Knight
Stupid question, I know but I remember reading that int is unreliable, is it better to use short or a long depending on expected size and ignore ints?most of the time I am using unsigned longs or shorts anyway, just would be good info to know. thanks.


short [int], int, and long [int] all can have different sizes on different platforms and compilers.

Share this post


Link to post
Share on other sites
For any compiler and platform you're likely to care about (starting with GameBoy GBA, and going all the way to Windows-64), short is 2 bytes, int is 4 bytes. On most platforms (including Windows-64), long is 4 bytes, except some LP-64 systems (like Linux on 64-bit CPUs) where long is 8 bytes. "long long" is almost always 8 bytes, where supported. size_t is always the same size as void * / char *, but may be 4 or 8 bytes.

Thus, for pretty well portable code, here's a cheat-sheet:

char = 1 byte
short = 2 bytes
int = 4 bytes
long long = 8 bytes
size_t = integer the size of a pointer

Share this post


Link to post
Share on other sites
The standard makes the following guarantees about the sizes of data types:
sizeof(char) = 1
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) [<= sizeof(long long)]
Signed and unsigned do not affect the size of a variable. (The long long type is standard in C99 and supported as a C++ non-standard extension in GCC 3.x, GCC 4.x, and VC8+.)

Note that VC and GCC disagree on the size of the long data type on 64 bit architectures.

Share this post


Link to post
Share on other sites
I'm sure ints were 2 bytes when I first started programming. 'integer' in VB is still 2 bytes nowdays.
The safest way is to use some typedef (or heaven forbid a #define). e.g.
typedef unsigned char  UINT8
typedef unsigned short UINT16
typedef unsigned int UINT32
typedef signed char SINT8
typedef signed short SINT16
typedef signed int SINT32
That way if you find yourself on a platform where the sizes are different, you only have to fix it in one place. You can even use C_ASSERT (compile time assert) to check that the sizes of them are what you expect.

I believe that some libraries out there already do exactly this.[cool]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
#include or depending on which one is applicable. Then wallow in the glory of uint8_t, int8_t, uint16_t, int16_t, uint32_t, int32_t, uint64_t, int64_t.... No need for ad hoc defines anymore!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The post above is supposed to say stdint.h, but this forum is not smart enough to automatically translate what's written into a form that can later be displayed.

Edit: The board supports HTML in post but I beliebe it is disabled for AP. You should be able to use [ source ] [/ source ] or [ code ] [ /code] tags if you need to escape something.

[Edited by - Shannon Barber on April 5, 2006 11:35:21 PM]

Share this post


Link to post
Share on other sites
int is not unreliable, "Plain ints have the natural size suggested by the architecture of the execution envirorment" (taken directly from the standard). You can't be promised how big it's, it might be 1 byte or 255, but on most current architectures it will be 4 bytes, and in some cases 8. Apart from assuming stuff you can use the Boost's library for integer types, or you can create a simple little utility class yourself using template meta-programming and std::numeric_limits<T> (in case we are talking C++ and not C, you haven't said that). Generally if you need a "fast", general-purpose integer type use int.

EDIT: Check this site for more info about using Boost to solve the problem. If you for some reason can't use Boost you will have to program something like that yourself.

Share this post


Link to post
Share on other sites
If you need an integer with a specific number of bits, don't use short, int, or long. Use types with the size in the name (as suggested above).

I never use short or long, because using them means that I need a specific size.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by JohnBolton
If you need an integer with a specific number of bits, don't use short, int, or long. Use types with the size in the name (as suggested above).

I never use short or long, because using them means that I need a specific size.


I think of "short" as the integer equivalent of "float". Common wisdom for floating point is to use double unless you have a lot of them, in which case you use float to save memory access fees.

I use "short" if I need to save memory, "int" by default, and "long" if I need to guarantee the larger range.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
The post above is supposed to say stdint.h, but this forum is not smart enough to automatically translate what's written into a form that can later be displayed.


The forum is designed to allow limited use of HTML, but it is disabled for Anonymous Posters. You would need to register, and then use HTML escape entities: thus, &lt;stdint.h&gt; in your post becomes <stdint.h> on the board. (And of course to show "&lt;" I type "&amp;lt;", and so on...)

Share this post


Link to post
Share on other sites
Quote:
Original post by CTar
on most current architectures it will be 4 bytes, and in some cases 8.


We've got conflicting information here. HPlus and others seem to disagree with this.

Share this post


Link to post
Share on other sites
Actually hplus said the same thing - in some environments long will be 4 and other times it will be 8.

It seems conflicting because it's not well-defined. The C/C++ standards only specify the minimums. As several people have said if you need specific sizes then you should uses typedefs that explicitely give the size, although you may need to define those types yourself.

Share this post


Link to post
Share on other sites
Quote:
Original post by CTar
You can't be promised how big it's, it might be 1 byte or 255,

No, one byte wouldn't be enough. An int must be able to represent numbers in the range of -32767 to 32767.

Share this post


Link to post
Share on other sites
Quote:
Original post by mcfly
Quote:
Original post by CTar
You can't be promised how big it's, it might be 1 byte or 255,

No, one byte wouldn't be enough. An int must be able to represent numbers in the range of -32767 to 32767.

I'm not convinced that range is correct, but even so who's to say one byte isn't large enough to store it?

CM

Share this post


Link to post
Share on other sites
Quote:
Original post by Conner McCloud
I'm not convinced that range is correct, but even so who's to say one byte isn't large enough to store it?CM

Sorry, didn't think clearly. If CHAR_BIT happens to be 16 or higher, one byte would be able to hold it indeed. The range is covered in the standard but I can't back it up with a quote right now. The -32767 and not -32768 specification is to honour other complement implementations besides 2's.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by mcfly
Quote:
Original post by Conner McCloud
I'm not convinced that range is correct, but even so who's to say one byte isn't large enough to store it?CM

Sorry, didn't think clearly. If CHAR_BIT happens to be 16 or higher, one byte would be able to hold it indeed. The range is covered in the standard but I can't back it up with a quote right now. The -32767 and not -32768 specification is to honour other complement implementations besides 2's.


Specifically, in addition to one's and two's complement, C allows signed integers to be implemented as sign/magnitude.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this