common bugs in C programs
Matthew Waugh
waugh at dg-rtp.dg.com
Fri Jan 5 08:34:55 AEST 1990
In article <1990Jan3.095204.6979 at gdt.bath.ac.uk> exspes at gdr.bath.ac.uk (P E Smee) writes:
>In article <5860 at umd5.umd.edu> lgollub at umd5.umd.edu (Lewis R. Gollub) writes:
>> They propose using the preprocessor to define various substitutions
>>of standard C code for more easily read programmer's code.
>> In this case you would include a line
>>
>>#define EQ ==
>> if (a EQ b)
>>
>I keep a copy of their 'easy_c.h' lying around as an example of what
>the preprocessor can do, but I don't actually approve of the use of
>this technique. While it can make reading the code easier for the
>person who is accustomed to using it, it suffers from several
>shortcomings, which are in my opinion fairly major.
I once had the "privilege" of working with someone who successfully,
via the use of the pre-processor, turned C into Pascal, including
such fascinating additions as
#define then
#define do
#define begin {
#define end }
I personally hated it, but I used to take a perverse delight in
generating programs that would either completly blow out of
the water with wierd and wonderful error messages due to these
translations, or inter-mix C and "pseudo-Pascal" to produce
programs with a truly awful readability factor.
Ho Hum, to each his/her own I guess.
Mat
------------------------------------------------------------------------
Matthew Waugh waugh at dg-rtp.dg.com
RTP Network Services {world}!mcnc!rti!dg-rtp!waugh
Data General Corp.
RTP, NC. (919)-248-6344
More information about the Comp.lang.c
mailing list