Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.lang.c
Subject: Re: Standard int sizes
Message-ID: <6295@mimsy.UUCP>
Date: Wed, 15-Apr-87 09:10:27 EST
Article-I.D.: mimsy.6295
Posted: Wed Apr 15 09:10:27 1987
Date-Received: Fri, 17-Apr-87 00:07:26 EST
References: <6759@brl-adm.ARPA> <230@ems.UUCP> <170@vianet.UUCP> <832@viper.UUCP> <981@copper.TEK.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 30

In article <981@copper.TEK.COM> stevesu@copper.TEK.COM (Steve Summit) writes:
>If you do have a special requirement, either for range or
>compactness, and you're going to go to the trouble of defining a
>new type, don't just use something that's got the size in bits
>wired into the name or something. ...

>Say what you mean!

But `what you mean' might be just `something that holds at least
32 bits'.

>You probably don't need a type that can hold a 32-bit value just
>because it can hold a 32-bit value.

---Unless, of course, you are dealing with a pre-defined file format
which makes extensive use of 8, 16, 24 and 32 bit values.

The key concept (with which I agree) is that you must *think about
the uses* for the types you define.  Are the types properly descriptive?

There is a problem with this approach, though.  It can lead to a
profusion of types, incomprehensible due to sheer numbers.  There
is a balance point between descriptive but basic types and exact
types; that balance depends on many things, including your own
sense of aesthetics.

Whoever said programming was not an art?	:-)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu