Re: speeding up compile times in C++

Amir Michail <amichail@cs.toronto.edu> wrote:


[problem statement about recompliations in C++ deleted]


>I was thinking of a way around this problem. The motivation is that
>changing .h files should not cause any .c files to recompile unless these
>files were also changed.
>
>The idea is for the compiler to maintain a .i file along with any .h file
>that gives information about how the .o files were created. In
>particular, if I declare a structure taking x bytes, then the compiler
>generates code that gives the structure 2x bytes.


>...
>Would this idea work? Would it improve compilation times?


Why is it that the concept of a symbol file is so hard for C++ programmers
to understand? This problem has been solved for quite a long time with
languages using a real module structure yet, despite this fact, C++
programmers and writers continually propose new solutions ranging from
wrapping anonymous structure pointers (read: opaque types) in the main
header file (so the implementation can be changed at will) to the idea
proposed here.


Symbol files solve this problem, and have solved this problem for many
years -- and they are getting better at solving minor objections to the
solution! A recent thesis from ETH in Zurich [Crelier, available from
anon ftp at neptune.inf.ethz.ch] has shown that it is even possible to
have a symbol file that is not completely invalidated even though the
publicly projected module image has changed (i.e. An addition to the
module's interface invalidates no one. A deletion from the interface
invalidates only those modules which used the deleted item (an
oversimplification, but it gets the idea across)).


It's time that programmers start looking at other languages' solutions to
the problems that are plaguing C++ programmers; they might find that
their favorite hated language may promote better software development,
and in a faster time frame, with no less expressiveness and greater
maintainability.


The BF&I idea presented in the original message seems to be common among
the some in the C++ community: damn the maintenance cost of the solution
(yet another file which must be maintained somewhere), the elegance
(blindly allocating 2x the structure size for future changes to the public
projection of the class/struct?) or the existence of other solutions to
the problem (Modula-2 & Oberon symbol files, Ada packages & many others).


While it is indeed true that there are many C++ haters that wouldn't
touch it with a long stick, there are just as many C++ lovers who refuse
to look at other languages and other languages' solutions to problems
(which are no longer problems, except in C++).


Taylor Hutt
--

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