Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Naming Conventions
Keywords: renaming symbols
Message-ID: <70301@microsoft.UUCP>
Date: 29 Jan 91 21:22:56 GMT
References: <1568@tcs.tcs.com> <62211@brunix.UUCP> <70185@microsoft.UUCP> <1991Jan25.005440.27042@Solbourne.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 32

In article <1991Jan25.005440.27042@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes:
|In article <70185@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
|->I agree that a good, simple way to resolve name conflicts is going to
|->be necessary.  But, we also need to figure out some way to get to a 
|->consensus of a good, standard, base set of C++ libraries for people
|->to build on.  [However, I can imagine no way to do this.]
|
|
|Our X toolkit (OI) prefixes all of the identifiers with either a oi_
|or a OI_.  This seems to avoid many of the problems that people have
|with 2 libraries defining stuff like Base.

Yes, programmer supplied prefixes suffice in practical terms to avoid
name collisions across vendors -- assuming vendors write using the same
memory models, don't override global new, delete, etc, then presumably a 
library user has a vague possibility of getting libraries from two vendors
to coexist -- separately -- in one program.  Still, it seems silly for
programmers to have to manually provide name mangling in the program source
while simultaneously the compiler is providing automatic name mangling
to avoid collisions for the kinds of name overloading C++ supports.  Why
not just support module names in C++ as an additional factor in name 
overloading, and let the compiler do _all_ the name mangling?  The same
module::doSomething() syntax already used for nested classes should also 
suffice for module name disambiguising -- assuming a class and a module 
[library] can't have the same name.

However, if we are to have standard libraries, ratified by the ANSI-C++
committee, then for those libraries, the naming problem cannot be 
skirted.  Standard libraries must have agreed upon standard names, 
standard syntax, and standard semantics.  Today, C++ programmers  cannot
seem to agree on even one of these issues.  Thus, I don't know how the
ANSI-C++ committee is going to get agreement on all three issues.