Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!brutus.cs.uiuc.edu!usc!ginosko!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Using #define to "extend" C
Message-ID: <2119@dataio.Data-IO.COM>
Date: 8 Sep 89 20:36:38 GMT
References: <7598@goofy.megatest.UUCP> <12793@pur-ee.UUCP> <1461@atanasoff.cs.iastate.edu>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 24

In article <1461@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall) writes:
<   While we are on the subject of loops, how do people feel about the
<   practice of using #define to "extend" the language?  For example:
<   #define loop     for (;;)
<   #define exitloop break

Please do yourself and us all a favor and don't do this because:
1. Simple C program analyzers (like cb and indent) won't work on it.
2. Error messages from the C compiler will be in terms of C, not your
   language.
3. After you get comfortable with C, you will no longer regard C syntax
   idioms as a legibility problem.
4. You will seriously impair your ability to read other people's code, and
   other people's ability to read yours.
5. Most programmers will treat your code as if they would be struck blind
   if they looked at it.
6. Since C is not entirely consistent in how {}, ;, and expressions are
   handled, your #defines could cause unintended flow-of-control bugs that
   only become apparent if you examine the preprocessor output.
7. This was thrashed about in this newsgroup years ago, and the consensus
   was it is a bad idea.

Expend your energies instead on an appropriate identifier naming convention,
and on commenting your algorithms.