Re: [Off-Topic] int/long/short

From: d. hall (dhall@OOI.NET)
Date: 09/05/98


>>>>>> thus on Sat, 5 Sep 1998 20:38:25 EDT, I wrote:

> okay, sorry for the totally unrelated topic, but what's the ranges for
> long, int, short, etc?

This is architecture independant.

On Linux x86 (gcc), Solaris x86 (gcc) and Irix (cc and gcc) running in 32
bit mode, the following are true.

char    = 1 byte        2 ^ 8 (2 to the 8th power) 0 - 256
short   = 2 bytes       2 ^ 16 (2 to the 16th power) 0 - 65,536
int     = 4 bytes       2 ^ 32 (2 to the 32nd power) 0 - 4,294,967,296
long    = 4 bytes        ''
pointer = 4 bytes        ''

If it's signed, one of those bits holds the 'signedness' of the number, so
you have to chop off a bit to save the + or -.  That divides the numbers in
half.

signed char,    2 ^ 7 (2 to the 7th power)      -128 to + 128
signed short,   2 ^ 15 (2 to the 15th power)    -32,768 to +32,768

In C, the only definite for any architecture is:

        char < short <= int <= long

> like int goes from -x to x, and unsigned is like 0 - 2x or something like
> that, but i'm not sure what the ranges are, and i wanted to minimize the
> memory of some structs i'm adding...thanks in advance

The best way to minimize struct sizes is to group like typed items together
from largest to smallest in the structure.

You start off with all your pointers, then longs, then ints, shorts, and
finally char's.

Dynamically sized and arrays will disrupt this, since the compiler will
align your stuctures along memory alignments.  Shaving a couple bits in
your structures doesn't do THAT much for memory usage.  Unless you can
reduce the size of a structure by nearly half, it's not always good to
limit yourself by using smaller sizes, especially for bit fields.

d.


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
     +------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/15/00 PST