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


Kühl, Dietmar wrote:

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

Ok then.  It knew there where things I was overlooking.  In my view
there should be a separate database for each object file which should
contain the templates for that object file only.  This database can
either be a separate file with the same name of the object file but a
different extension or part of the object file itself.  Having a
separate database for each object file would avoid the problems with
different versions of the same code that one large database might have.

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

Ok.  Is it possable to embade the database in an library on an a.out
system?

-- 
Kevin Atkinson
kevinatk@home.com
http://metalab.unc.edu/kevina/


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