Message-ID: <373B5AE0.C7D60DB2@unb.ca>
Date: Thu, 13 May 1999 19:06:08 -0400
From: Endlisnis <s257m AT unb DOT ca>
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
To: djgpp AT delorie DOT com
Subject: Re: Portability and size_t type related question
References: <8D53104ECD0CD211AF4000A0C9D60AE301397599 AT probe-2 DOT acclaim-euro DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Info: BrunNet, Inc.  888-278-6638
Reply-To: djgpp AT delorie DOT com

Shawn Hargreaves wrote:

> Personally, though, I've never much liked this method of defining
> your own types. As long as you make some minimal assumptions (eg.
> that you can fit at least 32 bits in an int, or assume at least 16
> bits if you want to support 16 platforms as well), and don't rely
> on any specific wrapping behaviour, I've never found a case where
> I really needed this kind of define. IMHO it is almost always
> better to let the compiler choose a good size for you, eg. if
> you naively ported a 16 bit DOS program to djgpp by defining all
> the integers as shorts, you'd end up with very inefficient code
> because of all the size prefixes, wheras if you just said "int"
> you would get whatever is the optimal integer datatype for the
> current machine.

    What happens when you need to have a program load a file with a struct
stored on it?  If you just let the compiler choose the "optimal" size of an
int, then you get screwed because the struct won't load correctly.


--
     (\/) Endlisnis (\/)
          s257m AT unb DOT ca
          Endlisnis AT HotMail DOT com
          ICQ: 32959047