Related articles |
---|
symbol database for C++ compiler khoury@club-internet.fr (khoury) (2001-02-23) |
Re: symbol database for C++ compiler joachim_d@gmx.de (Joachim Durchholz) (2001-02-25) |
Re: symbol database for C++ compiler broeker@physik.rwth-aachen.de (Hans-Bernhard Broeker) (2001-02-25) |
Re: symbol database for C++ compiler s355171@student.uq.edu.au (Benjamin Johnston) (2001-02-25) |
Re: symbol database for C++ compiler ucapjab@ucl.ac.uk (Jonathan Barker) (2001-03-01) |
From: | "Jonathan Barker" <ucapjab@ucl.ac.uk> |
Newsgroups: | comp.compilers |
Date: | 1 Mar 2001 02:32:12 -0500 |
Organization: | Compilers Central |
References: | 01-02-119 01-02-126 |
Keywords: | C++, practice |
Posted-Date: | 01 Mar 2001 02:32:12 EST |
"Joachim Durchholz" <joachim_d@gmx.de> wrote in message
> The MSVC++ compiler does something like this (it uses a "program
> database"). However, this is generally difficult to do in C++:
> changing a preprocessor symbol may change the syntax of large parts of
> source, making it difficult for the compiler to decide what to
> invalidate after a change. This means either more recompilation than
> strictly necessary, or a large and complex (and thus more buggy)
> dependency tracker.
By way of illustration:
I recently used MSVC++ 6.0 on a medium sized project. A
complete build took 10 minutes before the "program database" was
built, and less than 2 minutes after. Incremental builds were
almost instantaneous if only one or two object files were involved.
However, incremental changes to some of the template-based code
caused the compiler to choke reporting an internal error(!) The
workaround for this feature is a complete rebuild.
Lest I provoke an anti-MS flame war, I should also mention that I
have encountered oddly similar behaviour with template-based code
and gcc (Linux x86); under certain circumstances (which I have not
been able to fathom) making incremental changes to template code in
a project with a large number of interdependent modules causes
internal errors or mysterious symbol naming problems at link
time - even when all dependencies have apparently been rebuilt.
Again, the solution is a complete rebuild.
Regards
Jonathan
Return to the
comp.compilers page.
Search the
comp.compilers archives again.