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


Groups > comp.compilers > #742

Re: C include handling, was Bison deterministic LALR

From Marco van de Voort <marcov@toad.stack.nl>
Newsgroups comp.compilers
Subject Re: C include handling, was Bison deterministic LALR
Date 2012-09-05 08:40 +0000
Organization Stack Usenet News Service
Message-ID <12-09-006@comp.compilers> (permalink)
References (2 earlier) <12-08-009@comp.compilers> <12-08-014@comp.compilers> <12-08-015@comp.compilers> <12-08-018@comp.compilers> <12-08-020@comp.compilers>

Show all headers | View raw


On 2012-08-29, BartC <bc@freeuk.com> wrote:
>> another issue is that things like precompiled headers are non-standard,
>> and there is no real agreed-on convention for "hey, compiler, feel free
>> to use precompiled headers here".
>
> Why should how a compiler optimises its work violate the standard?
> Provided the end results are the same, the compiler can do what it
> likes.

True, but that is a complex problem, since processing a header starts
with a preprocessor state (at the point of including), then processing
it changes compiler and preprocessor state.

I'm not a C expert, but it probably depends on the state of the
compiler on inclusion too (e.g.  when you can check if a type is
already defined or not)

Both the output states are dependent on (both) the input state which
in turn depend on the point of inclusion.

So precompiled headers should probably reduce the input state to the
bare essentials, and reduce the changes to the output change
accordingly.

Then one should be able to check if the reduced input state matches the one
in the precompiled header before it is loaded.

>> AFAIK, the preparsed/precompiled headers for C generally handle #if and
>> #ifdef and similar during the preprocessor as usual. this seems to be a
>> large part of why there are many restrictions on the use of precompiled
>> headers in those compilers which support them.
>>
>> AFAICT, languages like C# delay commands like #if or #ifdef until later
>> (and impose restrictions on how they may be used). IIRC, they are
>> generally handled at linking or at JIT.

Or they use a different way of importing that zaps
preprocessor/compiler state to some known global state, and doesn't
allow code before #include, removing the dependency on compiler state.
[The preprocessor conceptually happens before the parse, so
preprocessor state doesn't depend on compiler state.  But #if means
that the sequence of includes affects both the preprocessor state and
the compiler state. -John]

Back to comp.compilers | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Bison determinis​tic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support hsad005@gmail.com - 2012-08-17 11:22 -0700
  Re: Bison determinis​tic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-18 10:13 +0100
    Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-20 01:01 +0100
      Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-20 16:14 +0100
      Re: lexer speed, was Bison BGB <cr88192@hotmail.com> - 2012-08-20 14:14 -0500
        Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-21 07:40 +0100
      Re: lexer speed, was Bison "BartC" <bc@freeuk.com> - 2012-08-21 17:39 +0100
    Re: Bison determinis​tic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-20 13:35 +0000
      Re: Bison determinis​tic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support BGB <cr88192@hotmail.com> - 2012-08-21 14:45 -0500
        Re: Bison determinis​tic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support "BartC" <bc@freeuk.com> - 2012-08-22 14:04 +0100
          Re: Bison determinis​tic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support BGB <cr88192@hotmail.com> - 2012-08-26 19:37 -0500
            Bison deterministic LALR parser for Java/C++ "BartC" <bc@freeuk.com> - 2012-08-29 22:03 +0100
              speeding up C recompilation, was Re: Bison deterministic LALR BGB <cr88192@hotmail.com> - 2012-09-04 13:45 -0500
              Re: C include handling, was Bison deterministic LALR Marco van de Voort <marcov@toad.stack.nl> - 2012-09-05 08:40 +0000
  Re: Bison determinis​tic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support hsad005@gmail.com - 2012-08-18 02:09 -0700

csiph-web