steve@taumet.com (Stephen Clamage) (10/30/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >I don't think I've ever used an enum. Why not? Because they aren't in >the language I think of as C. The result? My code is more portable. >Would this be true if I used H&S as a reference? I doubt it. Sounds like you have never actually read H&S. They are careful to describe what was in old versions of C, common extensions, and what to do for the most portable code in cases where compilers have diverged (as with enums). So the answer to your last question, your code is likely to be very portable among pre-ANSI compilers if you read and follow the advice in H&S. (If you are fortunate enough to be able to use ANSI compilers, you can be sure of code portability with a much wider range of language features.) -- Steve Clamage, TauMetric Corp, steve@taumet.com
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/31/90)
In article <493@taumet.com> steve@taumet.com (Stephen Clamage) writes: > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >I don't think I've ever used an enum. Why not? Because they aren't in > >the language I think of as C. The result? My code is more portable. > >Would this be true if I used H&S as a reference? I doubt it. > Sounds like you have never actually read H&S. They are careful to > describe what was in old versions of C, common extensions, and what > to do for the most portable code in cases where compilers have > diverged (as with enums). You don't understand. I don't *want* to have to wade through all that stuff about newer C. The language described by the original K&R isn't defined precisely---but it's the language I use, and the language that compilers understand. And that's exactly what I want. I first learned C by writing code in it and asking people when I didn't know how to do something. I didn't read any references, so I didn't hear about enums. Then I found out about K&R. I read it. I still use it as a reference. Maybe I would agree with Chris that H&S is the best reference if I ever needed more precise interpretations than there are in K&R. But I don't. I look at C code with enums the same way as I look at ANSI C, Ada, or any other language I'm familiar with but don't write new code in. When I'm programming in C, I use K&R. > So the answer to your last question, your > code is likely to be very portable among pre-ANSI compilers if you > read and follow the advice in H&S. Your code is likely to be even more portable if you use K&R as your reference. That's all I'm saying. ---Dan Difference between Multics and Ada: Multics was ten years *ahead* of its time.
eager@ringworld.Eng.Sun.COM (Michael J. Eager) (11/03/90)
In article <27203:Oct3103:49:2290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >You don't understand. I don't *want* to have to wade through all that >stuff about newer C. The language described by the original K&R isn't >defined precisely---but it's the language I use, and the language that >compilers understand. And that's exactly what I want. > > >Your code is likely to be even more portable if you use K&R as your >reference. That's all I'm saying. > I have to throw my 2 cents in. Here's the hypothetical question: If K&R was so clear and wonderful why did H&S write their book and why did the ANSI committee form to standardize the language? The answer is that K&R is not clear, it doesn't match the implementations, and doesn't completely describe the language as used or implemented. Part of the impetus to standardize C was problems writing portable code. For example, different integer promotions. Or the different collection of library routines supplied with different compilers. Or the different operation of identically named functions. Or the various interpretations of multiple external variable definitions. Porting C code which is ANSI conformant is easier than code which works on some version of C, but only on that version. And, naturally, that version is not available, so you have no idea what the program was supposed to do when it doesn't work correctly. There you have it. Flame off. -- Mike Eager