Re: Templates in C++

The essential problem with templates is that they address a high
level concept (polymorphism) addressed with a low level implementation
model (macros).


The two implementation problems we have been talking about:
    - a code bloat problem
    - a compile time problem
are symptomatic of another problem: that of implementation flexibility.


The "single copy" object model section solution Jan Gray mentioned
works fine until you start to have many small files which include
large numbers of template headers. The resulting huge compile time
to instantiate all those functions for every file has cause some
members of this group to propose compiling the entire program as
a single file. While I am a proponent of global optimization, I
would like to believe that it would be required for speed of the
final executable while seperate compilation could be used for
speed of development. The "single copy" solution turns this
idea on its head.


The alternative is the program database which can change the
development environment dramatically. One might then be tempted
to add interfaces and implementations to C++ and form a more complex
notion of when implementations require recompilation than that
the file's date has changed.


The real problem here is that the memory maps and code generated are
determined by a combination of the template definitions and the
instantiation parameters. Many of these dependencies can be eliminated
by reorganizing your code as Marc Shepherd suggested. However, the
real question is "should this be the concern of the programmer"?
Certainly, the programmer would like to have control over memory map
of some of their structures (as has been pointed out, C++ does not
provide total control). But in many cases, the compiler, especially
with the benefit of profiling information, could make much more
informed tradeoffs... tradeoffs which would not be burned into the
structure of the program but could be tweaked during development or as
the project changed.


Unfortunately, these tradeoffs are best handled by enabling the compiler
to choose whether to allocate an object in line or out of line.
Aliasing, memory allocation, bitwise copying etc. all complicate
implementing these tradeoffs.


The ML solution is to use indirection in the implementation for
nominally inline data and to handle memory allocation itself. While
this give the programmer less control there is every indication
that, combined with global data inlining optimizations, it will
eventually yield smaller, faster executables. For large programs
with very complex data structures, the compiler has better information
and more time to balance code size and program speed.


Given the trend to global optimization and the overspecification of
data layout required by C++, as well as the size, speed and complexity
of many C++ compilers and the code they generate (large, slow and high
respectively), I would not be surprised if, in the future, a good
implementation of a much simpler language could not beat the pants
off a C++ compiler on any reasonable size pair of codes written by
average programmers.


I have been working on ways to select the versions of polymorphic
methods and data structures for duplication based on criteria of
speed and code size. A paper on the subject can be found at:


      http://www-csag.cs.uiuc.edu/papers/clone-submit.ps


--
John Plevyak (plevyak@uiuc.edu) 2233 Digital Computer Lab, (217) 244-7116
                          Concurrent Systems Architecture Group
                          University of Illinois at Urbana-Champaign
                          1304 West Springfield
                          Urbana, IL 61801
<A HREF="http://www-csag.cs.uiuc.edu/individual/jplevyak">My Home Page</A>
--

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