This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Idea for export Implemnation


Hi,

> 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.
> 
Apart from the linker problems pointed out by Joe Buck, you also have
to take care of some semantic trickery with templates: The standard
distinguishes between bound and unbound symbols. The tricky part
about the separation model is to get these right: The bound symbols
are those not depending on the template arguments. These are bound
in the context of the template definition. The unbound ones are bound
in the context of the template instantiation.

Thus, it is not sufficient to simply put the template code literally into
an object file. Instead, you have at least to preprocess it to get the
bound symbols right. Even then, you still need to establish the correct
context for the instantiation.

I think a "smallest impact" implementation would in fact use some
sort of database (this can be a very simple one) where exported
templates are collected in some preprocessed from. Then, when an
instantiation is needed, the definition is looked up in this database
together with the currently available instantiations. If necessary, it
is instantiated. The definition can than go either into the current object
file or some other special object file or library.

To support exported templates in libraries, there would be a database
for each of the libraries. Potentially, this can be a member of the
library itself.

dk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]