Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!nerds-end From: Kaz Kylheku Newsgroups: comp.compilers Subject: Re: macros, was Looking for volunteers for XL Date: Tue, 13 Dec 2011 01:39:49 +0000 (UTC) Organization: A noiseless patient Spider Lines: 68 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-12-018@comp.compilers> References: <11-11-048@comp.compilers> <11-11-061@comp.compilers> <11-11-064@comp.compilers> <11-12-002@comp.compilers> <11-12-017@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1323887196 32513 64.57.183.58 (14 Dec 2011 18:26:36 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 14 Dec 2011 18:26:36 +0000 (UTC) Keywords: macros, design, comment Posted-Date: 14 Dec 2011 13:26:36 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:390 On 2011-12-13, Joe keane 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]