What should be added to C
Walter Bright
bright at dataioDataio.UUCP
Thu May 29 03:35:10 AEST 1986
In article <2823 at utcsri.UUCP> greg at utcsri.UUCP (Gregory Smith) writes:
>In article <5498 at alice.uUCp> ark at 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.
More information about the Comp.lang.c
mailing list