From: Adam Brown <adambrown1 AT geocities DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: as internal declarations - gfx demo
Date: Sun, 30 Aug 1998 17:58:37 +0200
Organization: IP Worldcom
Lines: 20
Message-ID: <35E976AD.5068@geocities.com>
References: <E0zCSn7-0005A4-00 AT sable DOT ox DOT ac DOT uk> <35E87E2E DOT 7D5D AT geocities DOT com> <35E966DB DOT 6B6C260A AT unb DOT ca>
Reply-To: adambrown1 AT geocities DOT com
NNTP-Posting-Host: portls32.worldcom.ch
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Endlisnis wrote:
> 
> Adam Brown wrote:
> > > "long" is at least as wide as "int", which is at least as wide as
> > > "short".  In addition, "short" is at least 16 bits wide and "long" is
> > > at least 32 bits wide.
> > >
> > >     16 bits  <=  short  <=  int  <=  long  >=  32 bits
>         So how come 'long' was not set to 64-bits?  Wouldn't that have made it easier
> to use 64-bit variables without being totally ANSI un-complient?  Why make up
> 'long long's when 'long's have been wasted?  I suppose this has to do with
> UNIX compatability.  It just seems odd to have 'int' the same as 'long'.

It is not odd. The long is 32 bits because the current generation of x86
processors are all 32-bit and not 64 bit, so a 64-bit long would process
twice as slowly (4 x actually, but accounting for the fact that twice
the amount of data is being processed, it is twice). This is indeed the
case: long long operations are 4x slower. As most ppl use int in their
code, it makes sense to have it 32-bit, because long operations are in
fact far faster under djgpp that short operations.