Date: Wed, 05 Feb 1997 14:22:40 -0500 From: Bakul Shah <bakul@torrentnet.com> To: Terry Lambert <terry@lambert.org> Cc: chat@freebsd.org Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta Message-ID: <199702051922.OAA12987@chai.plexuscom.com> In-Reply-To: Your message of "Tue, 04 Feb 1997 17:05:28 MST." <199702050005.RAA13528@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Urg. As always, if it can be proven to my satisfaction that I have
> actually made a mistake, I will post a retraction; now you have me
> wondering, since you are generally reliable as a sanity-check... 8-(.
>
> Are you saying that there is a condition in which the linker
> will not be able to find a symbol that is really there? I was
> under the impression that if the template declaration was in
> scope, the function implementation would be instanced in scope:
The `scope' of a named object is the *program text* where the object
name is visible. This is strictly a compile time property for block
structured languages like C++. If there was a scoping error the
compiler would have complained, not the linker. If the linker can
not find a symbol, either the compiler did not give it the right
information or the linker is buggy. But either way, error is in
`linking' not in `scoping'.
The rest of your message indicates that you are using `scope' in a
way I am unfamiliar with (and your use is not standard. See for
example the `dragon' book on compilers).
> When a template is invoked, _Type_ will be replaced with
> a specific type value, such as _int_ or _String_.
> I was under the impression that "invocation" was not possible at
> runtime. If it were possible (it is, in theory, if you pass
> around void instances of the object and explicity invoke the copy
> constructors, etc., of the base type), it would require a working
> RTTI implementation, IMO, as well as the cooperation of the linker,
> aw well as compiler cooperation in treating a template definition
> as a two pass declaration, since RTTI only works for classes with
> pure virtual functions. The compiler would have to implictly
> provide it's own abstract interface type.
I think you are making this harder to understand that it needs
to be. Let us take an example:
template <class T> class list { ... };
typedef list<int> int_list;
Think of a template as a *type function*. `Invoking' a function
yields its value. Invoking a type function yields its value, a
type. Here `list' is a type function. `list<int>' is an invocation
of this function -- also called a template instantiation. The
result is a normal type, which we named `int_list'.
In a statically typed language there is no *need* to construct types
at runtime. Hence there is no need to invoke a type function at
runtime. Also note that you can do the same for certain normal
functions provided the compiler can deduce the value of the function
will be the same at runtime.
Just to use template instantiations you don't need the linker's
cooperation. If a source file uses functions defined on a bunch of
instantiated templates, the compiler can generate the necessary code
for these functions along with the code for the source file. No
external references are generated for any of the template instance
functions.
But this can cause code bloat. If N files reference the same
function of the same template instance, there will be N copies of
this function. To deal with that problem the compiler has to
a) not generate code but generate an external reference for
any use of a template instance function and
b) somehow separately compile these functions for each template
instance.
Then the linker can link everyone together and there is exactly one
copy of every function that was used (and may be the ones that were
not used). But you *still* don't need any linker help.
Without the -frepo patch step b) requires the user to manually
generate separate files with define the template instances and
compile them with a different flag to the compiler (since in this
case you do want to generate code).
Presumably the -frepo patch (in its correct incarnation) will (or
does) allow a special linker to perform step b) automatically.
And it is here where the linker comes in.
> If it is, tell me, and I will admit the mistake. Then I will
> point out that this probably requires the cooperation of the
> linker, and that the FreeBSD a.out linker is not being (very)
> actively maintained... and, as was pointed out, it works with
> John Polstra's "ELFKit"... consider upgrading. Otherwise, it's
> unreasonable to expect the "magic" to work elsewhere, so it's
> poor style, no matter how you cut it.
As far as I know the freebsd linker works fine. I was using
-frepo to cut down on code bloat, which is where I ran into
trouble.
> > The bad news is that it segfaults on even simple Verilog
> > module definitions. So for now this mini project has been ^Z'ed
> > (put on hold). Thanks to all the people who responded with helpful
> > hints (even if wrong:-).
>
> I have been implementing COM and DCOM objects using pure abstract
> virtual base classes for interface definitions, using the FreeBSD g++
> compiler in -current. If you could give a code fragment which
> triggers the error, I might be able to help out.
Thanks for your offer but I suspect the bug is in the simulator.
That is where I am going to look first when I have enough free time
to track this down.
If you or anyone else is interested, this is vbs-1.3.tgz -- I think
ftp://sunsite.unc.edu/pub/Linux/apps/circuits/ is where it is at.
-- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702051922.OAA12987>