Re: Idea for export Implemnation

[Joe Buck <jbuck at synopsys dot com>]

> Idea for export Implementation
> 
> Here is my idea for implanting the export keyword.  I am I bit foggy of
> how it works so please bear with me if I overlook something.
> 
> 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.

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.

> 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.

An extra file could be produced that contains the exported templates in
some easy-to-process form.  Or I suppose you could do something evil,
like store template code as string data in the object file.  But if you
have ordinary .o files, you can link them with an ordinary linker, and
only try an extra pass if you have undefined symbols.

> g++ main.o foo.o -o main

One nice feature of what you suggest is that the user can ignore the
fact that there is template expansion going on.  This may be tricky
to achieve in practice though.

> 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, or if foo.o has a mixture of ordinary
code and other code.  You try to work around this with special tricks for
read-only libraries, but I'm not happy with them, since I don't think they
will work reliably for multiple simultaneous users.  I don't think that
you should try to first generate foo.o, and then modify it.  That doesn't
work well with "make": I might change foo.cc but still have a newer foo.o,
if I first compile, then change foo.cc, then link.