Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!ll-xn!mit-amt!mit-eddie!genrad!decvax!tektronix!uw-beaver!uw-june!entropy!dataio!bright From: bright@dataioDataio.UUCP (Walter Bright) Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <1006@dataioDataio.UUCP> Date: Wed, 28-May-86 13:35:10 EDT Article-I.D.: dataioDa.1006 Posted: Wed May 28 13:35:10 1986 Date-Received: Sat, 31-May-86 06:48:33 EDT Reply-To: bright@dataio.UUCP (Walter Bright Organization: Data I/O Corp., Redmond WA Lines: 64 In article <2823@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >In article <5498@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: >>> o The ability to define multi-line pre-processor macros, using #begdef and >>> #enddef statements. #if and other conditionals in the body of the >>> definition would be evaluated when the macro was not interpreted, not when >>> it is encountered. I thought that multi-line macros could be done by terminating the line with a \. Such as: #define abc(d) a \ = \ d; By the way, Datalight C allows things such as: #define abc(d) a = \ #if XYZ == 47 \ 54; \ #else \ 56; \ #endif The preprocessor commands are considered as part of the macro text, and are parsed as preprocessor commands after the macro has been expanded. >>> o A typeof operator, similar to sizeof. > x = (typeof x ) malloc ( n * sizeof( *x )); The macro I always wanted to write is: #define swap(a,b) { typeof(a) temp; \ temp = (a); \ (a) = (b); \ (b) = temp; \ } >>> o := as a synonym for =. Compilers could have an option to permit := only. Clutter. It's easier to cause the compiler to generate a warning for constructs such as: if (a=b) { ... } >>> o Any sort of multi-level break statement. There is no syntacticly clean >>> way of adding this to C. >>C already has a multi-level break statement. It's spelled "goto." >>Putting a goto in a costume doesn't disguise it. >When a human reading a program sees 'break', it is immediately known >that the current loop is being abandoned. In order to determine the >effect of a goto, you have to find its destination. If you don't >believe there is a big difference, try maintaining someone else's >BAS*C code sometime. There's no problem finding where a goto goes to if you have only one or two in a function. Gotos only become a problem when you have a snarl of them. What I find confusing is four page functions, with 47 levels of ifs and {}s, and trying to figure out where control flow goes when a break happens. You have to count }s, or run a listing and connect the {}s with a pen. I've had people do greps for gotos on my code, show me an out-of- context list of the 14 they found in 10,000 lines of C, and tell me that my code was bad. Using only structured programming constructs only guarantees that the flow graph for your program will be reducible, it doesn't guarantee that your program is structured. The only purpose to having a reducible flow graph is if your optimizer can't handle irreducible ones.