Author: Matt Taylor
Date: 15:39:21 01/11/03
Go up one level in this thread
On January 10, 2003 at 12:26:15, Miguel A. Ballicora wrote: >On January 09, 2003 at 17:36:11, Robert Hyatt wrote: > >>On January 09, 2003 at 12:44:50, Matt Taylor wrote: >> >>>On January 08, 2003 at 16:06:38, Dieter Buerssner wrote: >>> >>>>On January 08, 2003 at 11:31:36, Miguel A. Ballicora wrote: >>>>Much snipped. >>>> >>>>>short --> not smaller than char >>>>[...] >>>>>I do not remember now whether a short can be smaller than 16 bits. >>>> >>>>No, it can't. My emphasis was on the fact, that the types were well defined, >>>>while Matt said, that the sizes were not. Not really a contradiction, also >>>>depends, on what is meant by "well defined". >>>> >>>>Regards, >>>>Dieter >>> >>>My recollections of old K&R C are similar to Miguel's. >>> >>>My definition of "well-defined" is "unambiguous without regard to machine." >>>While short, int, and long are unambiguous in the context of a -specific- >>>machine, they are very ambiguous in general. >>> >>>Anyway, C99 is 4 years after Java was introduced by Sun. The point I've made >>>stands here: Java had a 64-bit type before C standardized on it. It is more >>>likely then for people to make use of this in Java, and that spearheads >>>optimization of code generated for 64-bit types on Intel. Obviously this is >>>different for other platforms. >>> >>>As a matter of personal opinion, I find the idea of a "long long" silly. I would >>>rather use an "int64" when I want a 64-bit type and a plain "int" when I want a >>>type whose size is irrelevant (e.g. index to an array). In the spirit of K&R, >>>int should be 64-bits on a 64-bit platform. It is disappointing that this is not >>>always the case. >>> >>>-Matt >> >> >>I think the entire concept of "short", "int" and "long" are badly flawed. It >>would >>have been so much more logical and clean to simply go with int16, int32 and >>int64. > >The concept of short, int and long fits very well the spirit of C. It is a >fantastic concept that made the language as simple as posible, being as >flexible as possible to write code that is as portable as possible.. and >powerful too. You could write portable and efficient code in machines that were >1 and 2 complement, that had 8 or 9 bits per char, words of 16, 32, 48, 60, 64 >bits etc. For that reason, C survived and grew stronger through 3 decades. >The whole concept, to me, is fantastic. It was possible to easily write a C >compiler for each new hardware and OS. > >What if C would have been designed with int9, int18, int36? Ugly. > >>I don't personally like "long long" as it is a syntactical oddity in light of >>char, short, int >>and float/double. > >Yes, it could have been "huge int" or something like that, but it is a minor >detail. > >Miguel Isn't that paradoxial? C is portable, yet it has short/long? In the context of porting, short and long mean -nothing- as they can be implemented to be the same size as int. Furthermore, how will this address 128-bit machines with the ability to address 8-bits, 16-bits, 32-bits, 64-bits, 128-bits, and 256-bits? The point has already been made that the compiler can take an int8 and convert it to an int9 if it likes. There are many games you can play to ensure compatibility. As for portability, the short/long/long long are counterproductive. Code that does not need a specific sized datatype will use int, and code that does uses a series of #ifdefs with special cases for the machines it runs on to produce types of a specific size. How is this -more- portable than letting the compiler make such decisions? How would types of specific size limit portability? -Matt
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.