Author: Matt Taylor
Date: 16:22:57 01/11/03
Go up one level in this thread
On January 10, 2003 at 18:14:09, Miguel A. Ballicora wrote: >On January 10, 2003 at 17:26:52, Robert Hyatt wrote: > >>On January 10, 2003 at 15:58:29, Miguel A. Ballicora wrote: >> >>>On January 10, 2003 at 15:06:58, Robert Hyatt wrote: >>> >>>>On January 10, 2003 at 12:37:20, Miguel A. Ballicora wrote: >>>> >>>>>On January 10, 2003 at 11:10:07, Robert Hyatt wrote: >>>>> >>>>>>On January 10, 2003 at 05:12:04, David Rasmussen wrote: >>>>>> >>>>>>>On January 09, 2003 at 17:36:11, Robert Hyatt wrote: >>>>>>> >>>>>>>>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. >>>>>>>> >>>>>>>>I don't personally like "long long" as it is a syntactical oddity in light of >>>>>>>>char, short, int >>>>>>>>and float/double. >>>>>>> >>>>>>>There is a reasonable explanation for this at least. The idea is that "int" >>>>>>>should be whatever is the most natural entity of integer calculalation on a >>>>>>>machine. In many cases, you don't care how many bits a type can store. The lower >>>>>>>limits given by the standards is enough. You just want to know that by writing >>>>>>>"int" you get something that on every platform is supposed to be simple, fast, >>>>>>>signed (no weird problems with subtraction etc.), >>>>>> >>>>>>But _not_ for "real codes". Do I _really_ want to use int, when it _might_ be a >>>>>>16 bit value that won't hold the counter I need? >>>>>> >>>>>>No. >>>>> >>>>>You can use long, as you say below, if you really need bigger values than the >>>>>ones provided by 16 bits. I do not think this is a big deal. >>>>> >>>>>Miguel >>>> >>>> >>>>That's the point. On a Cray, I want to use "int" and get 32 bits, vs using long >>>>and getting >>> >>>Just use int :-) >> >>Won't work. >> >>I need a 32 bit counter. I need a 64 bit bitboard. I need a 16 bit index. > >Use int, long (or long long) and int, respectively. I fail to see the the >problem. > >>What works on the Cray will fail on the PC, because "long" works for the >>Cray/Alpha but not for the PC if I want a 64 bit integer... > >If you want portable code, use long long for both. If it is a very important >variable use typedef. > >>>If you have int16, int32, int64, you never know which one is more suitable for >>>another processor. Suppose that int16 is enough and you use it, maybe int32 was >>>faster! >> >>However, IO do know which is most suitable for _my_ application. If I need 64, >>I >>want 64, not whatever the compiler says is "best"... > >Then you sacrifice performance. Particularly for machines that do not have >8 bit chars and weird configurations! The performance hit in those cases is must >be huge. You cannot have 100% portability and best performance at the same time. >C gives, IMHO, the best compromise. History showed that. > >BTW, there is no problem in using a 32 bit integer if you only need 16. > >Miguel Perhaps you should reread what you posted. If there is no harm in casting a 16-bit integer up to 32-bits for efficiency, why not have a second form of int16 that allows the compiler to cast upward? This is better than making assumptions about short. If you have a machine able to do efficient 16-bit arithmetic, wouldn't it be better to let the compiler use 16-bit arithmetic rather than hope that short is 16-bits? If you fail to see a problem with short/int/long scheme, then you've also failed to look into the future. For instance, the current x86 architecture can address 1-byte, 2-bytes, 4-bytes, 8-bytes, or 16-bytes. Current implementations do not allow 128-bit (16-byte) types because sizeof(long) == sizeof(int). Even if they did, what would we do when the machine becomes capable of even longer datatypes? -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.