Sender: crough45 AT amc DOT de
Message-Id: <97May1.163817gmt+0100.16679@internet01.amc.de>
Date: Thu, 1 May 1997 15:42:13 +0100
From: Chris Croughton <crough45 AT amc DOT de>
Mime-Version: 1.0
To: tgrand AT canvaslink DOT com
Cc: djgpp AT delorie DOT com
Subject: Re: ints vs. shorts
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Tom Grandgent wrote:

>> int may be same size as long
>> int may be same size as short
>> short may be same size as long
>> short may not be smaller than long.
>
>Interesting..  Didn't know short could = long.. :)  But how can
>short not be smaller than long?  Under DJGPP, short is 16 bits and
>long is 32 bits.  Correct?

I think he got that last part the wrong way round.

  short <= int <= long

which implies that short can be the same size as long (and if
so then int is the same size as both).  There are also some minima
- short has to be at least 16 bits and long at least 32 bits.

>> Never read or write ints from your program to files, network, etc.
>> Use short or long.
>
>Ok, this is the answer to the question I was trying to ask.
>So, on the PC, short is always 16 bits and long is always 32 bits?

At the moment, on all compilers we know, yes.  But don't
complain if a future compiler makes

  short = 16
  int   = 32
  long  = 64

for instance (that's what it is on the DEC Alpha, for example) if
the next generation of PC processors has 64-bit support.

>That's what it seems like to me.  So you're saying to use short
>and long for I/O purposes but use int for internal things..

In fact, don't use any predefined type for external transfers.  If
you mean to write a two-byte integer, use something like:

  putc(val/256, fo);
  putc(val%256, fo);

for output and:

  int val;
  val = getc(fi) * 256;
  val += getc(fi);

for input (don't try to combine them, because the order of evaluation 
isn't fixed so in getc(fi)*256+getc(fi) either byte might be read first,
depending on what the compiler thought was best).

That way, it doesn't matter what your variable sizes are in either the 
writing or reading system.  It also means that it's portable to any
other system whether it uses 'big-endian' or 'little-endian' to store
numbers.

For complete generality, use ASCII for hex (printf("%.4X", val), for 
example) - it takes up more space in the file but any system can read
it.

>For example, I have a structure that contains the information
>for a ship in my game.  Coordinates, health, fuel, all kinds of
>things like that.  I am trying to determine whether it would
>be better to use ints or shorts for these sorts of things, as
>well as others.

If you're short of memory, use short.  If you want faster execution, use 
int.  But remember the size limitations as well - will your 'fuel'
quantities fit into 16 bits, or might you at some point want them
bigger?  Even more so with coordinates - 65535 might sound like a
big number now, but will you want either longer distances or more
precision in the future?

(For reference, a lightyear is about 1e16 metres, which is about 53
bits; a "long long" can therefore represent about 1000 lightyears in
metres (if signed; 2000 ly if unsigned).  How far does your game
range?)

Chris