Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.std.c |
| Subject | Re: conditional macro definition also for recursive conditionally limited expansion |
| Date | 2022-01-17 07:13 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <86zgnus8dx.fsf@linuxsc.com> (permalink) |
| References | <723aa6f8-0994-4b1d-b2d2-59abe33906ban@googlegroups.com> <srghc4$hsn$1@dont-email.me> |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 1/9/22 7:52 PM, Marco Munari wrote: > >> I thought it could be nice to introduce condition inside macro >> definition, to produce less jumping code (so compiler can output >> bigger but more efficient code with concise definition) >> >> a syntax could be defined by adding an optional #defif (due to the >> late time this could be introduced to C, that would be my preference >> reminding to who would learn by seeing it that the if is part of the >> macro definition) as >> #define macro(#N,x) #defif (#N>0) macro(#N-1,?) #defelse ? >> >> usable with macro(5,x) > > The committee decided long ago to not allow recursive macros. The > relevant wording is: > > 2 If the name of the macro being replaced is found during this scan of > the replacement list (not including the rest of the source file's > preprocessing tokens), it is not replaced. Furthermore, if any nested > replacements encounter the name of the macro being replaced, it is not > replaced. These nonreplaced macro name preprocessing tokens are no > longer available for further replacement even if they are later > (re)examined in contexts in which that macro name preprocessing token > would otherwise have been replaced." (6.10.3.4p2). > > The Rationale explains: "A problem faced by many pre-C89 preprocessors > is how to use a macro name in its expansion without suffering 'recursive > death.' The C89 Committee agreed simply to turn off the definition of a > macro for the duration of the expansion of that macro." IMO this conclusion is unwarranted. The earlier decision was about how to deal with unexpected and infinite recursion. What is being proposed does involve recursion, but recursion of a form that is neither unexpected nor infinite. There is no reason to expect comments about unexpected and infinite recursion to apply to macro definitions that are explicitly and finitely recursive. (Of course there does need to be some sort of limit because any actual compiler cannot accommodate recursion that is arbitrarily deep even if still finite, but that is a separate issue.)
Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
conditional macro definition also for recursive conditionally limited expansion Marco Munari <allerta.it@gmail.com> - 2022-01-09 16:52 -0800
Re: conditional macro definition also for recursive conditionally limited expansion James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-10 00:48 -0500
Re: conditional macro definition also for recursive conditionally limited expansion Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 07:13 -0800
Re: conditional macro definition also for recursive conditionally limited expansion Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 07:51 -0800
Re: conditional macro definition also for recursive conditionally limited expansion Marco Munari <allerta.it@gmail.com> - 2022-01-18 04:24 -0800
Re: conditional macro definition also for recursive conditionally limited expansion Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-19 06:53 -0800
csiph-web