Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site ccvaxa Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!preece From: preece@ccvaxa.UUCP Newsgroups: net.lang.c Subject: Re: Uses of "short" ? Message-ID: <2600015@ccvaxa> Date: Thu, 19-Sep-85 12:40:00 EDT Article-I.D.: ccvaxa.2600015 Posted: Thu Sep 19 12:40:00 1985 Date-Received: Sat, 21-Sep-85 03:44:25 EDT References: <486@houxh.UUCP> Lines: 69 Nf-ID: #R:houxh.UUCP:-48600:ccvaxa:2600015:000:3622 Nf-From: ccvaxa.UUCP!preece Sep 19 11:40:00 1985 > The use of "long" instead of "int" shows more attention to machine > specificity? /* Written 8:49 pm Sep 13, 1985 by guy@sun.uucp in > ccvaxa:net.lang.c */ ---------- Well, yes, to my mind. The programmer, thinking abstractly about a particular process, is likely to think of a variable quantity as an integer or as a real. Precision is a secondary consideration that, generally, only becomes a primary consideration when the simpler assumption fails. The range of an integer is not likely to be a concern until the programmer is faced with a case in which the default assumption ("it's an integer") fails. So I submit that as a default, "int" is more abstract than "short" or "long." That's why the white book says an int is "the natural size suggested by the host machine architecture." In practice, the programmer usually will have a pretty good idea when a quantity is likely to violate that default assumption on a particular machine and work around it accordingly (whether by changing "int" to "long" or by providing a specialized data type if "long" isn't long enough). Now we're going to have a C standard pretty soon, in all probability, and that may well change the default assumptions. If "int" is truly defined as a 16bit quantity, I will probably change my default working habits to use long -- otherwise my default abstraction would be violated too often. Up until the present, however, we have been working with a language in which the definition of short, int, and long were specifically machine dependent, and anyone porting software simply had to be aware of the obvious places where machine dependencies showed up. There are other languages where the purer abstraction is quite acceptable. In Common Lisp and integer can get to be any size it needs to be; the system will take care of keeping it in an appropriate kind of object for the size it currently has. On the other hand, there is a certain amount of overhead in that approach that you might not want to swallow. But it IS machine independent. ---------- > Code that uses "int" to implement objects known to have values outside > the range -32767 to 32767 is incorrect C. The ANSI standard explicitly > indicates this. Even in the absence of such an explicit indication in > an official language specification document, this information should be > imparted to all people being taught C. ---------- Now that there is a reasonably firm draft standard, this is a reasonable statement. Not very long ago it was religious dogma. ---------- > In a lot of cases, I damn well hope that the provable range is > significant to the programmer's view of the process. [gives > example of variable used as index into fixed size array] ---------- Well, yes and no. It is significant to the programmer that the value be a legal index into the array, but that may not be a fixed range in the programmer's mental model of the process. That is, it may be temporarily fixed, simply because it is necessary to provide a value for the declaration, but that size may be incidental. In such cases the well-bred programmer will have provided a #define, with a suggestive name, for the range of the array and anything that checks against it, but may not be able to provide a range for the index other than "fitting within the array," which may not be well modeled by architecturally convenient number sizes. An array with a dynamic size is another example. The point is that "fitting within the array" is a good and sufficient abstraction for the programmer's view of the process. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece