leonard@bucket.UUCP (Leonard Erickson) (07/27/89)
ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >While I'm on the soapbox, let me note that before I bought TC, I bought >a number of magazines and read a number of reviews of it. NOT ONE REVIEW >noted any of the BRAIN-DEAD FEATURES of TC 1.0/1.5 (I can say they were >brain-dead with certainity because they were eliminated in TC 2.0), most >of which were stupid, arbitrary deviations from **IX norms. Sorry to burst your bubble, but in the MS-DOS world, **IX compatibility is not going to be a review criterion. Very few of the magazines that review MS-DOS software are likely to even be aware of these **IX "norms". Compiler reviews generally assume that you are going to be *writing* code, not *porting* it. BTW, I'm not a much of a C programmer, so I'm curious, how well does ANSI C conform to these "norms"? -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I'm all in favor of keeping dangerous weapons out of the hands of fools. Let's start with typewriters." -- Solomon Short
caromero@phoenix.Princeton.EDU (C. Antonio Romero) (07/28/89)
In article <1583@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: >ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >>While I'm on the soapbox, let me note that before I bought TC, I bought >>a number of magazines and read a number of reviews of it. NOT ONE REVIEW >>noted any of the BRAIN-DEAD FEATURES of TC 1.0/1.5 (I can say they were >>brain-dead with certainity because they were eliminated in TC 2.0), most >>of which were stupid, arbitrary deviations from **IX norms. As a general rule, most reviews, especially early reviews, of software should be taken with enormous quantities of salt. (Not to defend Borland's early bugs or arbitrary changes...) >Sorry to burst your bubble, but in the MS-DOS world, **IX compatibility >is not going to be a review criterion. Very few of the magazines that >review MS-DOS software are likely to even be aware of these **IX "norms". >Compiler reviews generally assume that you are going to be *writing* >code, not *porting* it. Given that the largest arguement in favor of coding in C (apart from efficiency) is portability across platforms, especially including Unix, I think that this _is_ an issue. If MS-DOS was looked at as a ghetto of sorts, where little or no code travelled in or out, this attitude might be reasonable; but with more different kinds of machines interacting more closely every day (the recent new-line controversy arose because a Sun was providing file service for PC's) both small deviations from de facto standards like the Unix library and failures to be flexible about things like end-of-line conventions in source code (as I recall a programmer with Turbo 1.5, at least, could with a bit of cleverness get the end-of-line, for example, to behave any way they wanted) are inexcusable. At any rate, the complaint was not about how Turbo's file I/O works, but rather that the compiler itself can't compile a file with line-feeds between lines. >BTW, I'm not a much of a C programmer, so I'm curious, how well does >ANSI C conform to these "norms"? Well, given that ANSI C is an attempt to move from the de facto norms established by the Unix community, and more or less closely followed by those outside of it, to an official, formal standard... there's no reason why it _should_ follow the old norms. It won't change things arbitrarily, though; and any compiler claiming ANSI compatibility should be capable of handling the same files. Has the ANSI considered including something in the standard about end-of-line conventions? If not, someone who knows how to get input to them (if it's not too late) might pass it on... -Antonio Romero romero@confidence.princeton.edu