martin@mwtech.UUCP (Martin Weitzel) (06/28/90)
In article <5282@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: [most of old answer deleted] >A -- There is no ANSI requirement that requires the ability to get at >the output from the cpp. Exact! >Unfortunately, ANSI C (also K&R C) is very weak as far as macros are >concerned. It would be nice to be able to define macros within >macros, ... >I've heard that m4 does a decent job as a macro processor (but haven't It does. >used it). If you want to be portable, I think you'll have to add >another tool to your chain. I stumbled over m4 about two years ago, when I had to fight against the deficiencies of Informix 4GL. Can you imagine: If you need an array of several items and a loop bound, you have to use explicit constants(!) in both places. No way to #define such a thing. A nightmare if you have to maintain large software systems. My first plans were to only use "m4" to solve the just mentioned problem, but it soon evolved in some kind of "template language", in which I could express large parts of similar programs by designing appropiate templates that were filled by "m4". There are several advantages that would make "m4" preferable as (pre-)preprocessor even for C (if you are working in a Unix environment). Here some of "m4"-s key-features ("m4" afficionados be patient, I'm working just out of memory, not from the reference manual): - Several kinds of arithmetic and string processing within macros (including what ANSI-C calls "stringizing") - Conditianally expanded macros - Expanding macros in a loop, ie. you can specify through an argument how many expansions you get. (This is a bit tricky - you must use conditional expansion and tail recursion; Lisp programmers will like this, others like me have to work hard :-)) - Conditional inclusion (basically you have two sorts of what C calls #include; one *doesn't* complain if the #included file doesn't exist, so you can build in some "hooks", that you may later fill by creating the included files. Before getting enthusiastic about "m4": Be prepared for some time to learn and to gather experience. It's sometimes hard to trace and understand how several nested macros get expanded, especially if arguments are involved. Though there are (IMHO) far less "grey areas" than the C-preprocessor leaves (at least if you include what major pre-ANSI-C implementations delivered), you sometimes may feel a little "wummerig(%)" in your brains, until you finally get all the quotes in the right place. %: Excuse my german slang here - I know no english word for this state of mind though I'm sure there is one; just imagine you tried for some hours to analize some example program from the latest "Obfuscasted C Code Contest" :-). -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
seindal@skinfaxe.diku.dk (Rene' Seindal) (07/03/90)
martin@mwtech.UUCP (Martin Weitzel) writes: > Before getting enthusiastic about "m4": Be prepared for some time > to learn and to gather experience. It's sometimes hard to trace > and understand how several nested macros get expanded, especially > if arguments are involved. The GNU m4 distribution from prep.ai.mit.edu contains a manual, that is somewhat more detailed the normal reference manuals. Rene' Seindal (seindal@diku.dk)