Re: defining unique symbols

Jerry Leichter <>
16 Jul 1997 22:55:15 -0400

          From comp.compilers

Related articles
defining unique symbols (1997-07-13)
Re: defining unique symbols (1997-07-16)
Re: defining unique symbols (Jerry Leichter) (1997-07-16)
Re: defining unique symbols (Pieter Schoenmakers) (1997-07-16)
Re: defining unique symbols michael.ball@Sun.COM (MICHAEL BALL) (1997-07-22)
Re: defining unique symbols (1997-07-27)
| List of all articles for this month |

From: Jerry Leichter <>
Newsgroups: comp.compilers
Date: 16 Jul 1997 22:55:15 -0400
Organization: System Management ARTS
References: 97-07-052
Keywords: linker, OOP

Fergus Henderson wants a method to create exactly one instance of a
type object, even when linking independently-compiled modules each of
which might contain references to type objects.

There's a trick used in C++ compilers for producing exactly on copy of
the vtable that you might be able to adapt: In a correctly formed C++
program, every module in a link must have seen an "equivalent"
declaration for each class C. ("Equivalent" is a bit messy to
describe, but means that the same members and member functions appear
in all the declarations.) Hence, there is a well-defined list of the
member functions of C - where a member function is specified by its
name and argument types - which is the same in all modules with access
to C. Define any unique ordering on member functions - say,
alphabetical by mangled name. Find the first (with respect to this
ordering) member function that is *not* declared in-line within the
body of the class. In a complete program, *some* module must provide
a definition for that member function. It gets to define the vtable,
too; all other modules simply refer to it.

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.

I suspect C++ compilers are using the same algorithm for deciding who
defines the RTTI data structures. This can have nasty side-effects:
If you have multiple vtable's, you just waste some space. But I've
seen C++ compilers in which run-time type matching (in exception
handling, for example) doesn't work correctly for classes all of whose
member functions are defined in-line. Move any one of them
out-of-line, and everything works. I'd guess that the type matching
code assumes there is exactly one copy of the RTTI data structures,
but that that's not true in the buggy case.

Anyway: If you can find any arbitrary way to uniquely distinguish one
usage of your symbol from all the others, it can serve as the defining
-- Jerry

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.