Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!decwrl!sgi!shinobu!odin!sgi.com!linton
From: linton@sgi.com (Mark Linton)
Newsgroups: comp.lang.c++
Subject: Re: Let's write a new linker!  (Was: Re: Naming Conventions)
Keywords: name mangling linking symbol clashes
Message-ID: <1991Jan28.221437.26273@odin.corp.sgi.com>
Date: 28 Jan 91 22:14:37 GMT
References: <60352@microsoft.UUCP> <CIMSHOP!DAVIDM.91Jan9105408@uunet.UU.NET> <278D1767.505@tct.uucp> <61785@brunix.UUCP> <556@taumet.com> <1568@tcs.tcs.com> <62211@brunix.UUCP> <70185@microsoft.UUCP> <1604@tcs.tcs.com>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: linton@sgi.com (Mark Linton)
Organization: sgi
Lines: 9

I don't see how the global-class-name problem can be solved at link time.
Suppose you two class libraries, L1 and L2.  Suppose that they both have
String classes.  Suppose that your file a.c wants to use class A from L1 and
class B from L2.  Suppose both A and B have member functions that take
L1::String and L2::String parameters, respectively.  How is the compiler
to understand what is going on?  This problem arises regardless of whether
a.c uses the member functions in question.  Seems to me that class scoping has to be
solved during compilation.  Once it is fixed there, I think fixing link-time
is straightforward.