|symbol database for C++ compiler firstname.lastname@example.org (khoury) (2001-02-23)|
|Re: symbol database for C++ compiler email@example.com (Joachim Durchholz) (2001-02-25)|
|Re: symbol database for C++ compiler firstname.lastname@example.org (Hans-Bernhard Broeker) (2001-02-25)|
|Re: symbol database for C++ compiler email@example.com (Benjamin Johnston) (2001-02-25)|
|Re: symbol database for C++ compiler firstname.lastname@example.org (Jonathan Barker) (2001-03-01)|
|From:||"Jonathan Barker" <email@example.com>|
|Date:||1 Mar 2001 02:32:12 -0500|
|Posted-Date:||01 Mar 2001 02:32:12 EST|
"Joachim Durchholz" <firstname.lastname@example.org> 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.
Return to the
Search the comp.compilers archives again.