Re: language design tradeoffs [macro mayhem]

Firstly can I point out the the semicolons-in-macros debate is a problem
of people thinking of macro calls as non-terminals in the grammar, and
then failing to code them up properly (with appropriate parentheses):


> #define SOME_MACRO(A,B) \
> xxx; /* one simple C statement */
>[ causes trouble if you later write SOME_MACRO(a,b);, particularly in an
>if statment]


The point is that if SOME_MACRO's expansion is supposed to be a statement,
it should unambiguously have statement syntax. Hence my general rules for
CPP macros:


o Always wrap the expansion of an expression macro in ( and ),
o always wrap the expansion of a statement macro in { and }.


Thus the above I would always code as


#define SOME_MACRO(A,B) \
    { xxx ; }
#define SOME_MACRO(A,B) \
    { xxx ; yyy ; }


you could do the first as


#define SOME_MACRO(A,B) xxx


but then the compiler won't be as ready to warn you about using it
erroneously inside an expression!


(Of course occasionally you do want to use CPP macros to generate
expansions with mismatched brackets, but then your software tools tend not
to notice this!!)


> But the whole thing isn't a problem if an unescaped EOL is a statement
> terminator.


Oh horror of horrors! NO! I often have to write statements that stretch
to a few hundred characters because of long (descriptive) names such as:


      printf (" %s%s%s %s, ",
                      Operation_name (op),
                      (set_cond ? "cc" : ""),
                      (carry ? "x" : ""),
                      reg_name (a)) ;


I just hate the need to put all those \'s in long macros---why not have
some syntax like:


#begin_define SOME_MACRO (A, B)
    { xxxx ;
        yyy ; }
#end_define


And you can then allow spaces after `SOME_MACRO' as well?
M. Tillotson Harlequin Ltd.
markt@uk.co.harlqn Barrington Hall,
+44 223 872522 Barrington,
                                      Cambridge CB2 5RG
--

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