This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Idea for export Implemnation
- To: Kühl at cygnus dot com, Dietmar <Dietmar dot Kuehl at IZB-SOFT dot de>
- Subject: Re: Idea for export Implemnation
- From: Kevin Atkinson <kevinatk at home dot com>
- Date: Wed, 02 Dec 1998 10:12:59 -0500
- CC: egcs at cygnus dot com
- References: <199812021305.OAA27277@firewall.izb-soft.de>
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/