Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!uwvax!umn-d-ub!umn-cs!ns!ddb
From: ddb@ns.network.com (David Dyer-Bennet)
Newsgroups: comp.lang.c
Subject: Re: C macros (was comma operator:  keep away?)
Message-ID: <1333@ns.network.com>
Date: 27 Apr 89 21:35:00 GMT
References: <19913@iuvax.cs.indiana.edu> <10092@smoke.BRL.MIL> <1317@ns.network.com> <17109@mimsy.UUCP>
Reply-To: ddb@ns.UUCP (David Dyer-Bennet)
Organization: Terrabit Software
Lines: 25

In article <17109@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
:In article <1317@ns.network.com> ddb@ns.network.com (David Dyer-Bennet) writes:
:>(one of the most light-weight macro facilities I've ever had foisted
:>on me).  Without taking a position on the general value of the comma
:>operator -- the correct solution to this one is to improve the macro
:>facility, not provide a way to kludge some (but not all) cases.
:
:C's macro preprocessor is intended to be weak.  Fancier macro expanders
:(such as m4) are available (although their syntaxes often clash with C's,
:and/or with each other's).  What is missing from C (for operations like
:getchar and putchar) is not better macros, but rather inline functions.

Yes, the correct / better solution to that particular problem is inline
functions.  I let myself follow a bad example down a dead end.  I still
think a "real" macro facility is important / very useful in and of itself,
for various things particularly including static table initialization.
(I got exposed to powerful macros in dec's MACRO-10/20, then BLISS.  Even
the stuff in MASM for a pc is pretty useful (and looks remarkably like
macro 10/20).)

-- 
David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com
or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb
or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300