Re: High Level Assemblers vs. High Level Language Compilers

Fergus Henderson wrote in message 02-03-154...


>I think part of the problem is that debugger support for C macros in
>most existing systems varies from weak to non-existent.
>
>A really good debugger would allow the "step" command to step through
>macro expansion.


I've used various compiler options (usually something like "-E" to get the
CPP output and then I compile that if I have to step through the macro.
Though you're absolutely right that debugger support would be nice.


>--
>[Seems to me that inline functions are better than macros for executable
>stuff. With inlines available, I'd only use macros for
declarations. -John]


The semantics of macros and inline procedures are different.
Sometimes inline procedures just won't do the job. A classic example
is the "RatC" macro package I wrote about four or five years ago that
expands statements like _if.._endif into the corresponding if(){..}
sequence.


Now before you barf at such syntactical nonsense, the purpose of RatC
was not simply to let me eliminate braces in C/C++ (though that's not
such a bad idea). What RatC allows is a transparent implementation of
program instrumentation. By defining a single symbol (sorta like
NDEBUG) I can turn on and off (off, as in eliminate the code, just
like ASSERT) tracing of the control statements in a program. Stuff
like that just isn't possible with inline procedures. (RatC
reference: http://webster.cs.ucr.edu/Page_ratc/ratc.html )


Cool things like true (CLU-like) iterators would be possible as well
with a really good macro processor (okay, plus a little in-line
assembly).


Randy Hyde

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