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

Groups > comp.lang.c > #109163 > unrolled thread

Tiny question

Back to article view | Back to comp.lang.c

Contents

  Tiny question David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 20:45 -0700
    Re: Tiny question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-04 20:37 +0100
      Re: Tiny question David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 19:45 -0700
    Re: Tiny question Barry Schwarz <schwarzb@dqel.com> - 2017-05-04 23:14 -0700
      Re: Tiny question mark.bluemel@gmail.com - 2017-05-05 01:08 -0700
      Re: Tiny question David Kleinecke <dkleinecke@gmail.com> - 2017-05-05 12:36 -0700

#109163 — Tiny question

Would there be any downside were I to realize character
constants in the preprocessor rather than in the parser?
That is, for example, the pre-processor changes the three
characters 'a' to 0x61. and so on for other characters 
including the wise ones.

[toc] | [next] | [standalone]

#109254

David Kleinecke <dkleinecke@gmail.com> writes:

> Would there be any downside were I to realize character
> constants in the preprocessor rather than in the parser?
> That is, for example, the pre-processor changes the three
> characters 'a' to 0x61. and so on for other characters 
> including the wise ones.

(assuming s/wise/wide/)

For 'plain' characters it would depend on when in the PP the conversion
happens.  For example

  #define s(x) #x
  s('a')

must generate "'a'" so you can't change 'a' to 0x61 when reading tokens.

For the wide characters you are likely to have more trouble.  L'a' is an
expression of type wchar_t and u'a' and U'a' are of type char16_t and
char32_t.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#109287

On Thursday, May 4, 2017 at 12:38:00 PM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
> > Would there be any downside were I to realize character
> > constants in the preprocessor rather than in the parser?
> > That is, for example, the pre-processor changes the three
> > characters 'a' to 0x61. and so on for other characters 
> > including the wise ones.
> 
> (assuming s/wise/wide/)
> 
> For 'plain' characters it would depend on when in the PP the conversion
> happens.  For example
> 
>   #define s(x) #x
>   s('a')
> 
> must generate "'a'" so you can't change 'a' to 0x61 when reading tokens.
> 
> For the wide characters you are likely to have more trouble.  L'a' is an
> expression of type wchar_t and u'a' and U'a' are of type char16_t and
> char32_t.

Thank You. I missed that point. I can avoid it successfully
by reading the source token by token so that when I see the
'a' I already know it will be stringized so I avoid converting
it to an integer.

I am sticking to the C89 POV so unsigned wide characters don't
enter into the picture. But it seems possible to label the wide
character number as type wchar_because I can make all constants
values (that is type plus address) in the preprocessor rather
than waiting for that in the parser. Complicates things somewhat
but not hopelessly.

The tiny practical gain is a small saving of effort in the parser
- but an increase in the preprocessor. Might not be worth the
effort.

PS: Of course, some integer constants might well be optimized out
of value form. I would just ignore the old value assignment leaving
a few holes in the final executable.

> 
> -- 
> Ben.

[toc] | [prev] | [next] | [standalone]

#109296

On Wed, 3 May 2017 20:45:57 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>Would there be any downside were I to realize character
>constants in the preprocessor rather than in the parser?
>That is, for example, the pre-processor changes the three
>characters 'a' to 0x61. and so on for other characters 
>including the wise ones.

For one thing, 'a' is not 0x61 on all systems.  It happens to be 0x81
on my system.

For another, you cannot define a macro named 'a'.  How would you tell
the preprocessor to accomplish this?

And finally, what is the advantage of what you plan to do?  Do you
really think 0x61 conveys the intent of the code to a reader better
than 'a'?  (Quick, what is the intent of 0x74?)

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#109300

On Friday, 5 May 2017 07:13:46 UTC+1, Barry Schwarz  wrote:
> On Wed, 3 May 2017 20:45:57 -0700 (PDT), David Kleinecke
> <dkleinecke@gmail.com> wrote:
> 
> >Would there be any downside were I to realize character
> >constants in the preprocessor rather than in the parser?
> >That is, for example, the pre-processor changes the three
> >characters 'a' to 0x61. and so on for other characters 
> >including the wise ones.
> 
> For one thing, 'a' is not 0x61 on all systems.  It happens to be 0x81
> on my system.

"All the world's a Vax" ...

[toc] | [prev] | [next] | [standalone]

#109370

On Thursday, May 4, 2017 at 11:13:46 PM UTC-7, Barry Schwarz wrote:
> On Wed, 3 May 2017 20:45:57 -0700 (PDT), David Kleinecke
> <dkleinecke@gmail.com> wrote:
> 
> >Would there be any downside were I to realize character
> >constants in the preprocessor rather than in the parser?
> >That is, for example, the pre-processor changes the three
> >characters 'a' to 0x61. and so on for other characters 
> >including the wise ones.
> 
> For one thing, 'a' is not 0x61 on all systems.  It happens to be 0x81
> on my system.
> 
> For another, you cannot define a macro named 'a'.  How would you tell
> the preprocessor to accomplish this?
> 
> And finally, what is the advantage of what you plan to do?  Do you
> really think 0x61 conveys the intent of the code to a reader better
> than 'a'?  (Quick, what is the intent of 0x74?)

The difference here is in compiler architecture. The user sees
exactly the same thing either way.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web