Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!milton!ogicse!qiclab!percy!m2xenix!quagga!alpha!cspw
From: cspw@alpha.cs.ru.ac.za (Peter Wentworth)
Newsgroups: comp.lang.c
Subject: Re: Should I use macros to inline code?
Message-ID: <cspw.670414897@alpha>
Date: 31 Mar 91 10:21:37 GMT
Article-I.D.: alpha.cspw.670414897
References: <1991Mar27.024602.21399@visix.com>
Sender: usenet@quagga.ru.ac.za (Rhodes University NNTP server)
Organization: Rhodes University, Grahamstown, South Africa
Lines: 34

In <1991Mar27.024602.21399@visix.com> adam@visix.com writes:


>Given today's C compilers, is there any reason at all to explicitly
>inline code with macros?

>The only thing I could think of was there might be cases where you
>want explicit control of the space/time tradeoff (but surely the
>benefit is small).

I find macros provide a level of abstraction that is 
often more flexible than using functions, and it does so at
no cost.   In pariticular, say I'm writing a program to manipulate
Lisp-like cells, with three fields - a head, a tail, and a tag.
I generally like the following  ...
   #define head(p)      p->head  or  head[p]  or   cells[p].head
   #define tail(p)      p->tail  or  tail[p]  or   cells[p].tail
   #define tag(p)  ...

Now I can write 
      tail(p) =  head(tail(q))

Notice that I cannot use functions to generate L-values like this, and
I have the freedom to change the data structure without having to 
change all my code.   (I am a functional programmer at heart, so the
notion that all accesses to "substructures" should have the same syntax,
independent of whether they are arrays, records, pointers appeals to
me.  The fact that I can make all these accesses look like function
calls appeals even more!)

Pete
--
EP Wentworth - Dept. of Computer Science - Rhodes University - Grahamstown.
cspw@alpha.ru.ac.za