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


Groups > comp.lang.c > #142601

Re: Question about #error

Newsgroups comp.lang.c
Date 2019-03-29 12:08 -0700
References <q7g72f$59q$1@news.xmission.com> <9183709e-58d4-47b5-9e2b-781600729a55@googlegroups.com> <lno95uadtm.fsf@kst-u.example.com> <167a6806-9b54-4b29-bd00-188e286d3c05@googlegroups.com> <554d9166-d9ca-4109-b40e-a79b6f14ac41@googlegroups.com>
Message-ID <d81771e5-e7af-47e7-8477-fe25eaf0734e@googlegroups.com> (permalink)
Subject Re: Question about #error
From Thiago Adams <thiago.adams@gmail.com>

Show all headers | View raw


On Friday, March 29, 2019 at 12:05:53 PM UTC-3, James Kuyper wrote:
> On Friday, March 29, 2019 at 10:10:00 AM UTC-4, Thiago Adams wrote:
> ...
> > Initially my suggestion was to add new rules for macro expansion 
> > and doing this we could have safer macros and better tools (like
> > the ones that make code refactoring).
> > 
> > However, having in mind that this could be an eternal discussion trying
> > to find what usages people want to accept or deny I think the best
> > way is to keep 100% compatibly for macro expansion and move on.
> > 
> > Token-pasting would work as it is today but in some way it needs
> > to have access to the compiler.
> > 
> > (In my C transpiler I am doing the token-pasting inside the tokenizer. 
> > When the tokenizer finds a identifier that is a macro it expands it 
> > first (internally) and the output tokens are after this internal 
> > expansion.)
> > 
> > 
> > So, I think the current definition doesn't need to change and we
> > may think in term of features first and then later to see if 
> > phases needs to be changed or not.
> > 
> > The feature I would like to have is to be able to ask in #if
> > block about the AST.
> > 
> > For instance:
> > 
> > #if sizeof(int) ... 
> > #if _IsDefined(MyFunction) ...
> > #if _IsDefined(MyVariable) ... 
> 
> #if expressions are evaluated during translation phase 4. Per the rules
> currently in effect, sizeof(int) gets converted into 0(0) before
> evaluation (6.10.1p4), resulting in a syntax error.
> sizeof and int are recognized as keywords only during phase 7, and don't
> have meanings attached to them until phase 8. I presume that _IsDefined
> would be a new keyword, and MyFunction and MyVariable are identifiers,
> so they would also be parsed out during translation phase 7, but not
> given an actual meaning until translation phase 8.
> These reprocessing directives determine which tokens get processed
> during translation phases 5, 6, and 7. What should happen to those
> tokens during those phases if you can't determine whether the condition
> of a #if is true until translation phase 8?

Thanks for pointing out the phases. These phases description should 
change to allow this implementation.


To allow macro expansion in the same way it is today I think
the macro expansion must occur before #if evaluation. At the end
#if will be like 'static if'.

For instance,
#define X

#if defined(X) && sizeof(int) > 1
..
#endif

The later phases would see something like

_If (1 && sizeof(int) > 1) {
...
}

I added this _If. _If can be used inside macros. (Similar of _Pragma)

I realized this could replace the usage of _Generic that 
seams very complicated and not so useful today.

For instance:


#define cbrt(X) _Generic((X), \
              long double: cbrtl, \
                  default: cbrt,  \
                    float: cbrtf  \
)(X)

#define cbrt(X) \
  _If (__type_is((X), "long double") \
  {\
    cbrtl(X)\
  }\
  else (__type_is((X), "float") \
  {\
    cbrtf(X)\
  }\
  else\
  {\
    cbrt(X)\
  }

(Here { and } does not introduce scope)

Having the access to the compiler other functions like
_type_is can be added and everything makes sense. 
_is_integral , _is_struct etc..

At the end, #if is just a different and alternative way
to write the 'static if' of _If.

#error could be an alternative way of writing _Error("") 
in this case _Error also would be added and be something similar of _StaticAssert(false, ).

So we can imagine that we have new keywords inside the language.

_Include,   _If, _Ifdef , _Error, _Pragma (already there) and
we also have a alternative way to use these keywords
in a forma of '#single line' #include etc..

Token expansion happens before so maybe #define and #undef
don't have equivalent _Define and _Undef.

So, we can imagine the pre-processor having only one 
feature that is #define and #undef and macro expansion.

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


Thread

Question about #error gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-27 16:06 +0000
  Re: Question about #error Chad <cdalten@gmail.com> - 2019-03-27 10:21 -0700
  Re: Question about #error scott@slp53.sl.home (Scott Lurndal) - 2019-03-27 17:35 +0000
    Re: Question about #error nobody@example.org (Scott) - 2019-03-28 04:33 +0000
      Re: Question about #error Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-07 00:15 -0700
        Re: Question about #error gazelle@shell.xmission.com (Kenny McCormack) - 2019-04-07 10:22 +0000
          Re: Question about #error nobody@example.org (Scott) - 2019-04-07 17:10 +0000
  Re: Question about #error Bart <bc@freeuk.com> - 2019-03-27 17:52 +0000
  Re: Question about #error luser droog <luser.droog@gmail.com> - 2019-03-27 12:36 -0700
    Re: Question about #error luser droog <luser.droog@gmail.com> - 2019-03-27 12:47 -0700
  Re: Question about #error John Bode <jfbode1029@gmail.com> - 2019-03-27 14:28 -0700
    Re: Question about #error David Brown <david.brown@hesbynett.no> - 2019-03-27 22:38 +0100
  Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-03-28 13:59 -0700
    Re: Question about #error Keith Thompson <kst-u@mib.org> - 2019-03-28 14:28 -0700
      Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-03-29 07:09 -0700
        Re: Question about #error James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-29 08:05 -0700
          Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-03-29 12:08 -0700
            Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-03-29 12:15 -0700
            Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-03-29 12:53 -0700
          Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-03-30 14:40 -0700
            Re: Question about #error Keith Thompson <kst-u@mib.org> - 2019-03-30 15:19 -0700
              Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-03-30 16:17 -0700
                Re: Question about #error scott@slp53.sl.home (Scott Lurndal) - 2019-03-31 19:12 +0000
                Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-04-01 04:32 -0700
              Re: Question about #error David Brown <david.brown@hesbynett.no> - 2019-03-31 20:17 +0200
                Re: Question about #error Richard Damon <Richard@Damon-Family.org> - 2019-03-31 15:09 -0400
                Re: Question about #error David Brown <david.brown@hesbynett.no> - 2019-03-31 21:46 +0200
                Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-04-01 04:36 -0700
            Re: Question about #error James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-04-02 17:47 -0700
              Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-04-03 05:31 -0700
                Re: Question about #error James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-04-03 06:46 -0700
                Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-04-03 07:44 -0700
                Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-04-03 09:46 -0700
    Re: Question about #error scott@slp53.sl.home (Scott Lurndal) - 2019-03-28 21:29 +0000
    Re: Question about #error Thiago Adams <thiago.adams@gmail.com> - 2019-03-29 07:32 -0700

csiph-web