Re: Idea for export Implemnation

[Jason Merrill <jason at cygnus dot com>]

>>>>> Kevin Atkinson <kevinatk@home.com> writes:

 > Joe Buck wrote:

 >> > The basic idea is to have the template code (either parsed or raw) as
 >> > data blocks in the object files and have the linker compile them as
 >> > necessary.

That's what I've been planning on.  But as Dietmar points out, it's not
quite that simple; you have to bind non-dependent names when you parse the
template, and dependent names when you instantiate.  Which means that the
copy of the template you put in the object file needs to be annotated
appropriately, and the object file with the instantiation context needs to
store information about global decls.  And then there's the question of how
to handle inlines; the initial implementation probably won't inline
anything in an exported template.

 >> Depending on how the compiler is configured, we would use either the GNU
 >> linker, or collect.  Any solution would need to work with both options.
 >> Furthermore we have to have a solution that works OK with libraries.

Absolutely.  But it really only needs to work with collect, since we always
run collect.

 >> > For example:
 >> [ Example deleted: foo.hh declares templates, foo.cc defines and exports
 >>   these templates, main.cc uses the templates without including foo.cc ]
 >> 
 >> > g++ -c main.cc:  object code for main gets stored in main.o
 >> >
 >> > g++ -c foo.cc:  actual c++ code for Foo<T>::average_data() get stored in
 >> > foo.o
 >> 
 >> I'm not crazy about naming something .o if it's not an object file.  It
 >> would make it harder to use ordinary linkers.

It would be an object file.  The information would be stored in a separate
section called .template_info or some such.  The section would have flags
set such that it would be discarded by the linker.

 >> > Now things get interesting.  Where should the compiler store the new
 >> > code needed for Foo<int>::average_data() the most logical place for it
 >> > would be foo.o.  So now foo.o contains the c++ code for
 >> > Foo<T>::average_data() and the object code for Foo<int>::average_data().
 >> 
 >> I'm afraid that won't do very well when foo.o might be in a library or
 >> be included in multiple executables

Exactly.  That's the problem with the existing -frepo solution; we want to
get away from modifying object files.

 > Have a separate file the same name but different extensions that holds
 > all the instantiations and visible by all users on the system.

Congratulations, you've just reinvented the template repository.  If you go
that road, there's no reason to restrict it to libraries; the scheme Bjarne
talks about in Design & Evolution of C++ involves adding to and checking
the repository during compilation, so that the linker never has to get
involved.  But we aren't going to do that, because it violates the
principle of separate compilation.

Rather, the plan is for the prelinker to extract the necessary information
from the object files, run the compiler on that input, and link the
resulting object file into the executable.  We could do this in either of
two ways: 

1) Spit everything into one file, compile it, link it in.  Do this every
   time.
2) Compile each instantiation separately.  Allow the user to specify where
   to store these instantiation files.  Record dependency information so
   they are only regenerated when the object files they depend on change.

Again, the initial implementation will probably go with #1 for simplicity.

Jason