Author: Miguel A. Ballicora
Date: 00:16:32 01/13/03
Go up one level in this thread
On January 12, 2003 at 13:43:00, Matt Taylor wrote: >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. Not at all, historically at that point it did not make sense. Moreover, it could have been int36 and not int32. Unix ran in 36 bit machines too. One of the several reasons why C had a tremendous success was because it has been linked to Unix, which was ported between machines of different word sizes. Another, citing Dennis Ritchie: "...C remains a simple and small language, translatable with simple and small compilers..." So the spirit was to make it fast, efficient, small and not giving too much. Very practical. Introducing int32 was probably the least of the things that D. Ritchie wanted at that time. Another reason for success: "...Although C was not originally designed with portability as a prime goal, it succeeded in expressing programs, even including operating systems, on machines ranging from the smallest personal computers through the mightiest supercomputers..." (Dennis Ritchie) >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 I think that this is not really related to the origin of the debate, which is about strict types. This is more related to the size of them in the future, not if they exist well defined (int32) or not (int). IMHO, I do not think that it is practical to _force_ compilers to deal with such numbers when still common machines do not support that at all. I guess that it is more efficient for people in this area to use their own libraries and algorithms. I guess that they would do it anyway in search for efficiency if the machines does not support them, but I here I might be wrong. Since I am not an expert on this, it is just a guess. >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 I never said that. >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. It is not that it is difficult, the point was to make compilers as simple as possible. That was one of the keys for success as Ritchie thinks. Miguel
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.