Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!teklds!copper!stevesu From: stevesu@copper.UUCP Newsgroups: comp.lang.c Subject: Re: Standard int sizes Message-ID: <983@copper.TEK.COM> Date: Wed, 15-Apr-87 03:44:12 EST Article-I.D.: copper.983 Posted: Wed Apr 15 03:44:12 1987 Date-Received: Fri, 17-Apr-87 00:15:25 EST References: <6759@brl-adm.ARPA> <230@ems.UUCP> <170@vianet.UUCP> <832@viper.UUCP> Organization: Tektronix Inc., Beaverton, Or. Lines: 80 Summary: just say "int" Slavishly coding an entire program with things like int16 and int32 does nothing to improve the overall portability, readability, or efficiency of the program. (In fact, all three attributes can be significantly diminished.) Wanton use of such types is a perfect example of blindly doing something that somebody you thought knew what he was talking about said to, without really understanding what it is (or isn't) good for. The vast majority of the time, what you really, really want is a simple int. A long would unnecessarily waste space, a char or short would risk overflow or sign-extension problems, and any of the alternatives could waste time. (Remember that an int ought to be the "natural" size for the machine, and presumably the fastest and easiest to generate compact code for.) 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. Code strewn with undifferentiated int16's and int32's is just as hard to understand as code littered with shorts and longs. Say what you mean! You probably don't need a type that can hold a 32-bit value just because it can hold a 32-bit value. You probably have a more abstract quantity in mind, like "distance" or "temperature" or "furlongs per fortnight." Then you can say typedef long int Distance; /* distance in millimeters */ typedef int Temperature; /* temperatures in degrees C */ typedef char FurlongsPerFortnight; /* velocity ad absurdium */ Not only have you guaranteed that the "Distance" type can hold something over 2,000 miles, and that the type is easily changeable on a machine where a long int somehow isn't appropriate, but you have also made the code much easier to read and verify (is this int a temperature or a distance?) and you have additionally simplified any type modifications required by changes in the program (as opposed to changes in the implementation). Suppose one day you decide you need a completely different type for distances -- a floating point value, perhaps, or a structure containing feet and inches. If distances have their own typedef name, this change is easy. If all distances are "int32" (which you thought was going to make the program "portable") you can't change the distances without changing everything else that happens to be an int32, or examining every int32 in the program and trying to remember if it's a distance or not. To consider a previously-posted example (so artificial it should probably be ignored), if for some reason you really need a 16-bit, signed value, say typedef long int funnyvalue; /* 16 bits PLUS sign */ If that ends up being unacceptably inefficient on your hypothetical Queer Machine for C, where longs are 36 bits and slow, you can say #ifndef QMC typedef long int funnyvalue; /* 16 bits PLUS sign */ #else typedef int funnyvalue; /* ints are 18 bits on QM/C */ #endif If what you want to do is stamp your foot and demand 16 (or 32 or 27 or whatever) bits, and let somebody else be totally responsible for figuring out how to do it, then use PL/I or ADA. I say again, though, that the number of cases where you even care is small. When I'm writing things like for(i = 1; i <= 12; i++) days += monthsize[i]; I declare i as an int. Not a char, not an int16, not a typedef MonthCounter. Steve Summit stevesu@copper.tek.com