Re: symbol database for C++ compiler

"Jonathan Barker" <>
1 Mar 2001 02:32:12 -0500

          From comp.compilers

Related articles
symbol database for C++ compiler (khoury) (2001-02-23)
Re: symbol database for C++ compiler (Joachim Durchholz) (2001-02-25)
Re: symbol database for C++ compiler (Hans-Bernhard Broeker) (2001-02-25)
Re: symbol database for C++ compiler (Benjamin Johnston) (2001-02-25)
Re: symbol database for C++ compiler (Jonathan Barker) (2001-03-01)
| List of all articles for this month |

From: "Jonathan Barker" <>
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" <> 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.



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.