Author: Robert Hyatt
Date: 18:34:38 01/10/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. You pointed out the problem. I want a 64 bit value. Do I use long or long long? Impossible to answer unless I know the machine I am running on, which is a real _problem_. btw, "int" won't work for a 16 bit index. IE I expect that to have values between 0 and 65535. And wrap around as any 16 bit counter would do. Dropping that into an int won't fly unless I am running on a 286. > >>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. By that logic, all that would be safe to use is "long long" which is, in itself, a problem. If I only need values that fit in 32 bits, I want to be able to use 32 bits, and the same for 64 bits... I want to be able to say what I need, and then let the compiler complain if it can't deliver that. Which will let me know I have a problem, rather than the present scheme of the compiler assuming something that very well could be wrong... > >>>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. Actually it doesn't show that. C was developed 30+ years ago on a very simple architecture. The basic language structure has survived for a long time, but the data types (particularly integer) have really lagged behind, and kludges like "long long" are the result of short-sightedness... > >BTW, there is no problem in using a 32 bit integer if you only need 16. Sure there is if I am intentionally doing 16 bit arithmetic... Not to mention doing I/O, which is another set of problems caused by the same thing... > >Miguel > >> >> >> >>> >>>Of course you have to make a decision if you want portable code or faster code. >>>You can always use a typedef for a particular variable and have the best >>>compromise in C. >>>You cannot have 100% portable and optimal code in any scheme, even in the one >>>you suggest. >>> >>>Miguel >>> >>> >>> >>> >>>>64. I _know_ the precision I need, I'd prefer to be able to specify it >>>>_precisely_ rather than >>>>letting the compiler assume something.
This page took 0.01 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.