On 4/5/2014 9:13 PM, Frank Kolmann wrote:
Did not K&R design C? Why have macros in C at all?
Hi Frank,
As a fellow RPG programmer, I think you'll appreciate this analogy. In
RPG II, we had columns in the I specifications for Field Record Relation
Indicators. A picture is worth a thousand words:
IDISKET AA 01 1 CH
I OR 02 1 CD
I 1 50CUST
I 6 35 NAME 01
I 36 65 ADD1 01
I 66 95 ADD2 01
I 6 100INVOICE 02
I 11 182AMOUNT 02
The indicators are in columns 63-64. When indicator 01 is on, the
compiler fills in the fields with 01 specified. When indicator 02 is
on, the compiler fills in the fields with 02 specified. What the heck?
Why on earth would you not do this:
IDISKET AA 01 1 CH
I 1 50CUST
I 6 35 NAME
I 36 65 ADD1
I 66 95 ADD2
I AA 02 1 CD
I 1 50CUST
I 6 100INVOICE
I 11 182AMOUNT
Count the cards... er I mean specification statements. The definition
for the common fields (in this case, only one: CUST) needs to be
repeated. Cards cost actual money, and it is measurably cheaper to use
field record relation indicators that it is to punch the common fields
repeated times.
I wish I were making it up, but this was an actual thing back in the
1970s; important enough that the compiler people made it an integral
part of the language.
C macros have a very similar heritage. Back in the days before the
dinosaurs were turned into oil, hardware was slow and the macro was a
way for the compiler to generate inline code instead of generating the
overhead to do a far CALL. I do a fair bit of C programming on PIC
microprocessors, and in this decade, all of them are fast enough that I
no longer use macros to force inlining; I pretty much always define and
use a function instead. If I think the micro is slow enough that I'm
tempted to force the compiler to generate inline code, I switch to
assembler.
That might be a long way to go to say that K & R put macros into the
language for a reason, but that reason has faded with the decades.
--buck
midrange.com
