Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!sgihub!dragon!xanadu.wpd.sgi.com!pal
From: pal@xanadu.wpd.sgi.com (Anil Pal)
Newsgroups: comp.lang.c++
Subject: Re: Need help, missing virtual tables, Sun C++ 2.0
Message-ID: <1991May13.171559.1313@dragon.wpd.sgi.com>
Date: 13 May 91 17:15:59 GMT
References: <1991May9.173442.5946@dragon.wpd.sgi.com> <1991May10.182759.28323@neon.Stanford.EDU> <1991May11.005908.22236@dragon.wpd.sgi.com> <5507@lupine.NCD.COM>
Sender: news@dragon.wpd.sgi.com (CNews Account)
Reply-To: pal@wpd.sgi.com
Organization: Silicon Graphics, Inc.
Lines: 24

In article <5507@lupine.NCD.COM>, rfg@NCD.COM (Ron Guilmette) writes:
|> Something sounds wrong here. [ re: multiple copies of vtables ]
|> 
|> If vtables have extern linkage (which they must if they are going to end
|> up being sharde in some cases across compilation units) and if you have
|> several of them (all presemably with the same name) then your going to
|> get "multiply defined" errors at link time, right?

In the case where multiple vtables are generated, the generated vtable
name includes the name of the source file being compiled.  If you have
a cfront-based system, take a look at the generated code for a simple
case like:

	class foo {
	    virtual int f1()	{ return 1; }
	};

The possible existence of multiple virtual function tables makes using
vtable addresses as unique identifiers for a class (to provide runtime
type information, for example) a triccky problem.

-- 
Anil A. Pal,	Silicon Graphics, Inc.
pal@wpd.sgi.com	(415)-335-7279