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

Groups > comp.compilers > #739

Bison deterministic LALR parser for Java/C++

Show all headers | View raw

"BGB" <cr88192@hotmail.com> wrote in message
news:12-08-018@comp.compilers...

> On 8/22/2012 8:04 AM, BartC wrote:

>> But even given all that, there are ways of dealing with huge header files so
>> that it is not necessary to repeatedly tokenise and parse the same headers
>> over and over again (for recompiling the same module, or compiling many
>> modules all sharing the same headers).
>>
>> I've no idea whether many C compilers actually bother though; perhaps
>> it's easier to just recommend a faster computer..
>
> the problem here is that, although it isn't too hard to figure out
> possible optimizations, it is much harder to make them work in ways
> which don't violate the C standard.
>
> 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.

However the C language and the way the C compilers are typically
invoked (for example just one-time to compile one module, so it's
forgotten it's compiled the same sets of headers a moment before)
doesn't make things easy.  And it's possible that things such as
__TIME__ have been used in such a way that you are obliged to
recompile a header each time.

So it's easy to see why compilers may not bother!

Nevertheless, I think there is plenty that can be done, although I'm
not sure that creating intermediate files such as precompiled headers
is the way to go. It's better when a compiler is properly integrated
into an IDE, then the symbol tables built by a set of headers can be
made persistent much more easily.

Alternatively, it might be possible to just have a very faster parser!
And perhaps integrate the preprocessor so that it is not a separate
pass (I haven't attempted a C compiler so not sure if that's feasible;
my own source-level directives are handled by the lexer itself, or
sometimes by the parser).

>> [I've seen C compilers that keep preparsed versions of headers.  Dunno
>> what they do with #if.  Also see Microsoft's C# and other .NET languages,
>> that put all of the type info in the objects, so you can use the object
>> as a compiled include file. -John]
>
> 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.

With a new language then it's much easier to arrange matters so that
it's faster and simpler to compile. It might not even have conditional
directives, or any preprocessor at all; (C needs them because it is a
cruder, older language; I used to have conditional code, but no longer
and in any case it seemed an unsatisfactory approach).

--
Bartc

Back to comp.compilers | Previous | Next — Previous 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