Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c > #6422

Re: conditional macro definition also for recursive conditionally limited expansion

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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