djones@megatest.UUCP (Dave Jones) (01/31/89)
From article <348@twwells.uucp>, by bill@twwells.uucp (T. William Wells): > In article <1626@csuna.UUCP> abcscagz@csuna.csun.edu (Jeff Boeing) writes: > : ... a C "for" loop is superfluous > : because it can be replaced by an equivalent "while" loop, NOT an > : equivalent "do ... while" loop: > > C is superfluous because it can be replaced by an equivalent assembly > program. > Nice try, but this reductio ad absurdum doesn't stand up under scrutiny. I got the same response once when I observed that the functions of C++ are largely bookkeeping and keystroke-saving mechanisms, and that for the most part, one could write the C++ program in C, by keeping to some naming conventions. (Inline procedure calls are an exception. There the compiler is doing some semantic munging that would be impossible to emulate in straight C.) This mortified some of the object-orientation guys who like to use phrases like "sort-lattice inheritance polymorhism" to describe kinds of lookup-tables. (I just made that one up. How do you like it? ) One fellow replied that one could simply not write object-oriented code without an object-oriented language, and C was not an "OOL". I pointed out that most C++ compilers translate into C anyway, and said, "So there." He rejoined that if C++ were "only" a bookkeeping program, then so was C, because C compilers translate into assembly language. "So there. Ha!" Indeed, many C-compilers translate to assembly language, but -- and this is important -- not always the same one. Thus C is a mechanism for machine-independence. The "reductio" by analogy to replacing C-code with an "equivalent" assembly language program just doesn't hold up. Dave J. P.S. I kind of like C++, although I think the class-initialization and cleanup mechanisms are a little strained. The "bookkeeping" it does is useful, and programs with fewer characters can be easier to read. It also kind of encourages programmers to design around data-structures rather than algorithms, and to limit access to data-structure internals to a few easily identified procedures. I look forward to the day when it is available on one particular kind of machine that doesn't support it now. If and when that happens, I'll probably switch over. D. J. P.P.S. I also like the C for-loop.
bill@twwells.uucp (T. William Wells) (02/02/89)
In article <1315@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: : From article <348@twwells.uucp>, by bill@twwells.uucp (T. William Wells): : > In article <1626@csuna.UUCP> abcscagz@csuna.csun.edu (Jeff Boeing) writes: : : > : ... a C "for" loop is superfluous : > : because it can be replaced by an equivalent "while" loop, NOT an : > : equivalent "do ... while" loop: : > : > C is superfluous because it can be replaced by an equivalent assembly : > program. : > : : Nice try, but this reductio ad absurdum doesn't stand up under scrutiny. : ... : Indeed, many C-compilers translate to assembly language, but -- and : this is important -- not always the same one. Thus C is a mechanism for : machine-independence. The "reductio" by analogy to replacing : C-code with an "equivalent" assembly language program just doesn't hold up. Oh, I agree. But my point was just that the argument: "The for loop is superfluous because..." is just as relevant to the importance of the for loop as my "C is superfluous because..." is relevant to the importance of C. Which is to say, not at all. --- Bill { uunet!proxftl | novavax } !twwells!bill
shankar@hpclscu.HP.COM (Shankar Unni) (02/07/89)
> I guess it is obvious to me, not to others: If the increment that the user > wrote was 0.1, with one digit to the right of the decimal point, the > compiler should obviously use 10 as the denominator because 0.1 = 1/10. If > the user wrote a loop that incremented by 0.127, the compiler writer should > use 1000 for the divisor, because the user had 3 digits to the right of the > decimal. Any increment the user can type into their program can be exactly What you want is BCD (blecchh!!). Be sure you want to ask for this. Because the programmer could just as well have written: float f = 1.27; /* LOTS OF STATEMENTS */ for (g = 0.0; g < 100.0; g += f) { /* ... */ } What? you want to treat *your* case specially, but not this more general one? Like: IF, in the for loop, the increment statement is a single statement of the form LOOP_INDEX += INCREMENT, and the INCREMENT is a floating-point constant, THEN do your special fiddling... Really! --- Shankar.