Re: symbol database for C++ compiler

"Jonathan Barker" <ucapjab@ucl.ac.uk>
1 Mar 2001 02:32:12 -0500

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

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