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 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