franka@mmintl.UUCP (Frank Adams) (01/01/70)
In article <1022@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: >In other words, "case CR, LF:" would have the new semantics, whereas >"case (CR, LF):" would be equivalent to "case LF:". This is no more >problematic than the current overloading of comma for function calls. I always thought of the use of the comma to separate function arguments as the primary use, and the "ignore the first argument" operator as being the overloading. All in all, not one of the better features of the language. (The overloading, that is; I do *not* want to reopen the debate about the value of that operator.) One other possibility would be to use a semicolon: "case CR; LF:". This would not cause any direct parsing problems, but might be confusing for compiler error recovery routines and people. -------------------------------------------------------------------- One occasional problem with C, which does not fit with the overall language philosophy, is that a range check is always[1] implicit in a switch statement. If the statement happens to be at a key place in the code, a not unusual occurrence, this can add significantly to running time. Does anyone have any suggestions for a good syntax to indicate to the compiler that this check is not desired; that if the discriminant is not one of the specified cases, the result of the switch is to be undefined? I am a little surprised that K&R didn't make that the result of executing a switch statement with no 'default:' label. (I should note that I think the current definition is better, and would dislike that if it were the way switch statements were defined.) It is, in any case, too late for that interpretation now. On the other hand, I can't think of any way to specify this which doesn't make me sick. [1] Well, almost always. It is possible that the discriminant is pulled from a character or a bit field, and that all possibilities are explicitly covered; but this is an exceptional case. I doubt that any compiler checks for it. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
karl@haddock.ISC.COM (Karl Heuer) (09/09/87)
In article <2347@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >One occasional problem with C, which does not fit with the overall language >philosophy, is that a range check is always[1] implicit in a switch >statement. If the statement happens to be at a key place in the code, a not >unusual occurrence, this can add significantly to running time. > >Does anyone have any suggestions for a good syntax to indicate to the >compiler that this check is not desired; that if the discriminant is not one >of the specified cases, the result of the switch is to be undefined? How about "#pragma nodefault"? I've noticed this too, but (unlike you) I don't think it would be such a bad thing if this were the default behavior. Learning to "always" add the line "default: break;" isn't any harder than remembering to "always" have break statements between cases. (Not to say that two wrongs make a right -- I'm just trying to prebut the argument that novice users wouldn't be able to cope with it.) Moreover, PASCAL -- one of the languages to which C is oft compared, and often the only previous structured language known to a new C user -- has this same attribute. (It's true that PASCAL's case statement is crippled beyond usefulness, but that's because there's no way to override this behavior. This would not be the case in the hypothetical modified C.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
john@frog.UUCP (John Woods, Software) (09/11/87)
In article <2347@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: #>In article <1022@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: P>>In other words, "case CR, LF:" would have the new semantics, whereas R>>"case (CR, LF):" would be equivalent to "case LF:". This is no more A>>problematic than the current overloading of comma for function calls. G> M>Does anyone have any suggestions for a good syntax to indicate to the A>compiler that this check is not desired; that if the discriminant is not one >of the specified cases, the result of the switch is to be undefined? This seems to be the ideal case of what the ANSI people designed #pragma for. Before the switch statement you would have the line #pragma Pretty please, Mr. Compiler, don't check the range on this switch! and voila! code that's quick if the compiler recognizes the pragma, code that's correct even if it doesn't. Perhaps the ANSI committee should give some thought to standardizing certain "suggested" #pragmas. (Note: my general feeling about #pragma is similar to that of the writers of the GNU C compiler, who have the compiler run hack if it encounters a #pragma line... If one has to have a 69-way #elseif sequence to trick innumerable compilers into doing the same thing, what good is it?) (As it happens, the Greenhills C compiler has a command-line switch to turn off range checking of switch statements, but it is on a per-file basis, which seems a tad extreme.) -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw@eddie.mit.edu Maybe it's the sound of a WET RAG hitting a smooth WEASEL!
cowan@marob.masa.com (John Cowan) (07/27/89)
In article <18729@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <24CB9E07.9547@marob.masa.com> cowan@marob.masa.com (John Cowan) >writes: >>... As someone (Chris Torek?) said earlier in this group, "all 'struct' >>pointers must 'smell' the same." If this behavior is not guaranteed, >>forward references to structs would be unimplementable in one pass. > >It was Doug Gwyn, but this is otherwise correct. Sorry about that. I, like Usenet, tend to lose my memory every six months. :-) >>Ufcawss, if you talk to the people who wrote VMS C, they'll tell you that >>all one-pass implementations of C are unacceptable! (This has something to >>do with generating good code for the 'switch' statement.) > >They are both right and wrong. One-pass code generation means there >are few opportunities for optimsiation; but generating good switches >is easy. Simply emit a branch at the top of the switch... I looked up the complaint, and they don't like this unconditional branch. It involves jumping around the whole of a potentially large switch statement, and then back up to somewhere within the code. In a paging architecture with small pages (like VMS: 512 bytes/page), this may involve an unnecessary page fault just to get to the jump table. A two-pass compiler allows putting the jump table at the top. The VMS compiler actually emits most code on the first pass, watching in the mean time for switch statements and a few other constructs, and then runs a second pass to fix these constructs only if they were detected. He who eschews 'switch' wins fast compiles under VMS. -- Internet/Smail: cowan@marob.masa.com Dumb: uunet!hombre!marob!cowan Fidonet: JOHN COWAN of 1:107/711 Magpie: JOHN COWAN, (212) 420-0527 Charles li reis, nostre emperesdre magnes Set anz toz pleins at estet in Espagne.