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


Groups > comp.lang.c > #12871

Re: A variation of #

From Thad Smith <ThadSmith@acm.org>
Newsgroups comp.lang.c
Subject Re: A variation of #
Date 2011-11-07 19:51 -0700
Organization Aioe.org NNTP Server
Message-ID <j9a5g0$5b0$1@speranza.aioe.org> (permalink)
References <8f2cadb2-614d-4754-8bc3-bb7c063524ae@c16g2000pre.googlegroups.com> <9hqo41F4bgU2@mid.individual.net> <73822171-7a92-4420-9eea-e74bbeda1ff8@x28g2000prb.googlegroups.com> <4EB83A82.1080100@verizon.net> <v44mo8-lfm.ln1@jones.homeip.net>

Show all headers | View raw


On 11/7/2011 3:53 PM, lawrence.jones@siemens.com wrote:
> James Kuyper<jameskuyper@verizon.net>  wrote:
>>
>> #include<stdlib.h>
>> #define TRICAT(a, b, c) a ## b ## c
>> #define CHAR(a, b, c) TRICAT(a, b, c)
>>
>> #define CASE1 x
>>
> ...
>>      case CHAR('
>>          , CASE1, '
>>          ): break;
>
> Nice try, but no cigar.  The ## operator requires that the result be a
> valid pp-token and, depending on the order in which the operators are
> evaluated, you either end up with 'x or x', neither of which are valid
> pp-tokens.

So if we are concatenating 3 pp-tokens, not only do the individual items (a,b,c) 
and the final concatenation need to be valid pp-tokens, but also all potential 
_intermediates_, as determined by the unspecified processor order. That seems a 
needless and complicating restriction.

If I understand correctly, CHAR(<,<,=) will work because both << and <= are 
valid pp-tokens, but CHAR(., ., .) will not because .. isn't.

Finally the result of CHAR(%:, %, :) is undefined/unspecified, since order of 
concatenation determines whether the intermediate is %:% ## : or %: ## %: where 
%:% is not a pp-token.  I noticed that CHAR(C,3,_) is only required to work 
because 3_ is a valid pp-number!

It seems that the rule could be replaced by a greedy algorithm that concatenates 
all ##-connected pp-tokens before requiring a pp-token result.  As far as I can 
see such replacement would have no incompatibility with the current standard and 
would add little additional wording and processing.  It would simplify the 
concept by not relying on happenstance intermediates as noted above.

Thad

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

A variation of # Andrey Vul <andrey.vul@gmail.com> - 2011-11-07 10:53 -0800
  Re: A variation of # Ian Collins <ian-news@hotmail.com> - 2011-11-08 07:59 +1300
    Re: A variation of # Andrey Vul <andrey.vul@gmail.com> - 2011-11-07 11:11 -0800
      Re: A variation of # James Kuyper <jameskuyper@verizon.net> - 2011-11-07 15:07 -0500
        Re: A variation of # lawrence.jones@siemens.com - 2011-11-07 17:53 -0500
          Re: A variation of # James Kuyper <jameskuyper@verizon.net> - 2011-11-07 18:31 -0500
            Re: A variation of # lawrence.jones@siemens.com - 2011-11-08 09:16 -0500
          Re: A variation of # Thad Smith <ThadSmith@acm.org> - 2011-11-07 19:51 -0700
          Re: A variation of # Harald van Dijk <truedfx@gmail.com> - 2011-11-08 09:01 -0800
            Re: A variation of # James Kuyper <jameskuyper@verizon.net> - 2011-11-08 12:15 -0500
        Re: A variation of # Andrey Vul <andrey.vul@gmail.com> - 2011-11-07 17:32 -0800
          Re: A variation of # James Kuyper <jameskuyper@verizon.net> - 2011-11-07 21:17 -0500
    Re: A variation of # Andrey Vul <andrey.vul@gmail.com> - 2011-11-07 11:08 -0800
  Re: A variation of # Peter Nilsson <airia@acay.com.au> - 2011-11-07 16:46 -0800

csiph-web