|defining unique symbols firstname.lastname@example.org.OZ.AU (1997-07-13)|
|Re: defining unique symbols email@example.com (1997-07-16)|
|Re: defining unique symbols firstname.lastname@example.org (Jerry Leichter) (1997-07-16)|
|Re: defining unique symbols email@example.com (Pieter Schoenmakers) (1997-07-16)|
|Re: defining unique symbols michael.ball@Sun.COM (MICHAEL BALL) (1997-07-22)|
|Re: defining unique symbols firstname.lastname@example.org (1997-07-27)|
|From:||MICHAEL BALL <michael.ball@Sun.COM>|
|Date:||22 Jul 1997 20:51:23 -0400|
Jerry Leichter wrote:
> If there are no non-inlined members, the you have to fall back on
> having multiple vtable's. I don't know what these compilers do if no
> module ever defines the first non-inlined member function - if it's
> never called, that's certainly legal. I've seen error messages from
> some C++ compilers that seem to indicate that they don't recover
> gracefully in this situation.
The usual algorithm is to use the first VIRTUAL non-inline member
function. This must be defined or the program won't link.
> I suspect C++ compilers are using the same algorithm for deciding who
> defines the RTTI data structures. This can have nasty side-effects:
You have to fall back on some other form of uniqueness for this.
For example, on Solaris, within a single executable or non-shared
library it is sufficient to make the name weak. In that case the
linker will pick the first one encountered. It wastes some
space, but that's usually minor. With shared objects it's more
difficult, but you can use the linkers interposition rules to
achieve the same effect. (Only with functions though, so you have
to use functions as proxies to get at the data structures.) The
current SunSoft compilers use this. The template instantiatian
scheme provides another (expensive) solution
We decided that this was all horrible enough that we would get
our uniqueness by unique spellings and avoid all this mess for the
next ABI. This reduces the question to one of wasted space, just
as for vtables.
Sun MicroSystems Inc.
Return to the
Search the comp.compilers archives again.