Re: macros, was Looking for volunteers for XL

On 2011-12-13, Joe keane <jgk@panix.com> wrote:
> #2. Don't use function-like macros.
>
> Make the result one of the parameters (unless it is really simple, then
> some day in the future your 'really simple' macro is not so really
> simple).
>
> e.g.
>
> #define GET_FORDO_BIT(FOP) \
> ...
>
> int f(int x)
> {
> ...
> if (GETFORDO_BIT(fop))
> {
> ...
> }
> ...
> }
>
> versus
>
> #define GET_FORDO_BIT(FOP, FOB) \
> ...
>
> int f(int x)
> {
> ...
> GET_FORDO_BIT(fop, fob);
> if (fob)
> {
> ...
> }
> ...
> }
>
> How hard is that?


It's not hard to make, just hard to use.


Problem is, you're creating something akin to an assembly language,
with instructions that have source and destination operands.


GET_FORDO_BIT(FOP, FOB) cannot be used as a subexpression in a larger
expression.


If you have any complex computation going on made up of macros of this
type, you have to declare lots of temporary variables, and lay these
instructions in sequence, like a machine language program.


Now you need a compiler to generate that cruft for you.


The need for generating temporary variables has not gone away.
We've just given up doing it in the macro and shifted it onto the
programmer, who would rather now shift it back onto the machine.


Sure, if these macros are few and far between, that may be acceptable. In that
situation, you have nice code, whose structure is just broken up here and there
with an ugly imperative macro like this. It's intractable if you have many of
them, and want to write programs that are mostly made up of those macros.


Real macros let you do that: make robust languages that make heavy, dense use
of those macros, not only some syntactic sugar that is to be sprinkled very
sparingly.
[Seems to me that what you really want here is in-line functions. Macros are
useful for other stuff, too. -John]

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