Re: language design tradeoffs [macro mayhem]

markt@harlqn.co.uk (Mark Tillotson) writes:
>The point is that if SOME_MACRO's expansion is supposed to be a statement,...
>Thus the above I would always code as
>#define SOME_MACRO(A,B) \
> { xxx ; }
>#define SOME_MACRO(A,B) \
> { xxx ; yyy ; }


I'm surprised the moderator let this one slip past. This doesn't work any
better than the simpler version you rejected. Consider


if (condition)
SOME_MACRO(...);
else
some-other-statement;


This will cause an immediate barf due to the semicolon between the right
brace and the else. It's reasonably well known that the only way to make
a C statement macro look just like a subroutine call is


#define SOME_MACRO(A,B) \
do { xxx ; xxx; } while(0)


so that both the macro and a plain function call require a following
semicolon in all cases. (And I sure hope your compiler is smart about
constant if-conditions :-).)


The real reason that this is such a pain is not macros, it's C's
misbegotten syntax. If semicolons were statement separators (a la Pascal)
instead of statement terminators, things would work a lot more smoothly.


Incidentally, does anybody reading this list remember Bliss? IMHO no one
should be allowed to design a macro facility who hasn't studied the one
designed for Bliss/11 (and emulated in the various flavors of Bliss
written at DEC). It's amazing that twenty years after that design, we are
still putting up with half-assed macro facilities like C's.


regards, tom lane
[Mea culpa, though I note you can also write ``if(1) { stuff } else'' to
get a statement-like macros. Speaking of Bliss, it looks like it will be
possible to re-issue the classic "Design of an Optimizing Compiler" by Wulf
et al. Details forthcoming when known. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.