Author: Matt Taylor
Date: 10:43:00 01/12/03
Go up one level in this thread
On January 12, 2003 at 02:26:25, Miguel A. Ballicora wrote: >On January 11, 2003 at 19:23:19, Robert Hyatt wrote: > >[snip] > >>>>But it is a headache that could be eliminated. IE on a PC you know that >>>>short=16, int=32, long=32 and long long=64. But _only_ on a PC. It would >>>>be nice to know something about specific types that applies to _all_ >>>>architectures... >>>>int8, int16, int32 and int64 would do just fine since the older architectures >>>>with 36, 48 and 60 bits are pretty much history... >>> >>>You assume that those architectures are history, that might be true today but C >>>was not born today. >> >>Standards were done _recently_ again. >> >>three years ago in fact.. > >Now I really don't know what this thread is about. It is about standard C in his >whole history (1) or is it about stantard C today (2)? > >If it is 1, you cannot neglect the other architectures. >It is is 2, C99 includes the types that you want, and I don't understand then >your criticism to the standard. > >Miguel It is about both. Myself and others like David have argued that those int16/int32 types could have been in from the start with no threat to implementation on machines with 36-bit words or other oddities. I have further argued that special recognition of the suffix would allow the compiler to be extensible. The only operations that are more difficult to emulate at larger lengths are multiply and divide. All your basic bitwise operations are easy because each bit is seperate. For brevity I will ignore arithmatic operations (add/sub/mul/div), though there are techniques for implementing them in straight C, and most general-purpose machines have facilities to emulate. C99 has addressed current issues, but C99 -still- lacks foresight to address future issues. A 128-bit encryption algorithm is easier to implement using 128-bits. On machines that support it, it is also optimal. Current standards make no guarantees that such a type is available. Therefore it cannot be taken advantage of unless the programmer adds #ifdef glue to support platforms where no such type is available. This is resolved easily and gracefully if you accept that the standard is not perfect. The underlying problem has -NOT- been addressed by the long long type. It has merely been postponed. You said something in another post about C not being high-level. So? Do you think this idea is any more abstract than short/int/long? Should we code loops using conditional gotos? The level of abstraction that C supports is well beyond the level of abstraction required for types of explicit size. The argument that they are difficult to implement is likewise fatally flawed. They can be difficult to implement in optimal fashion -- how is this relevant? The compiler can easily be made to generate code that is at least as efficient as the programmer's code would be. These types can even be implemented as a preprocessing stage in the compiler (much like the early days of C++). -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.